Header error lors d’un tar x sur une archive splitée

Hier, j’ai transféré plusieurs Go de données sur un serveur distant sous Debian 10, sous forme d’une archive tar splitée en fichiers de 4 Mo. J’avais donc dans mon répertoire de destination un peu plus de 1000 fichiers au format MonArchive.tar.001.

Je tente un merge avec cat de ces fichiers afin d’avoir une seule grosse archive tar que je peux ensuite extraire.

cat MonArchive.tar.* > MonArchive.tar

Puis je tente une extraction :

tar xvf MonArchive.tar

Et je me heurte à une erreur d’header lors de l’extraction, s’arrêtant net après le troisième fichier sur une vingtaine présente dans l’archive. Je retente un cat et un tar mais sans succès. Ayant encore les fichiers d’origine sur ma station Windows, je décide donc de faire un comparatif des checksums respectifs pour m’assurer qu’il n’y ait pas de fichier qui ait été mal transféré.

Sur mon système Debian :

sha256sum MonArchive.tar.* > MonArchiveChecksum

Sous Windows, grâce à Powershell :

Get-FileHash * -Algorithm SHA256

Je récupère donc mes extractions, ouvre un Notepad++ et compare les fichiers : aucune différence de checksum. Je suis donc un peu surpris car cela veut dire que les fichiers sont a priori identiques entre la destination et la source. En conclusion, le problème semble se situer au niveau du merge de mes multiples archives.

Au détour d’un banal ls sur mon système Debian, j’ai compris d’où venait le problème. A l’heure où j’écris cet article (il était 1 heure du matin quand je me suis penché sur le sujet 😅), je n’ai plus les archives sur mon système Debian mais je les ai régénérées sur mon système Windows, et la cause est identique. Voici le résultat d’une commande ls sur Powershell :

Les fichiers étaient nommés MonArchive.tar.001, MonArchive.tar.002 jusque MonArchive.tar.1032. On passe donc une numérotation sur 3 chiffres à 4 en arrivant au millier ; ce qui va fatalement poser problème pour cat puisqu’il fusionne les fichiers par ordre alphabétique. Or, par ordre alphabétique, il y a donc MonArchive.tar.100, MonArchive.tar.1000, MonArchive.tar.1001, MonArchive.tar.1002… avant de finalement continuer sur MonArchive.tar.101, MonArchive.tar.1010. Par conséquent, l’archive est mal constituée puisque pas concaténée dans l’ordre : cela ne serait pas arrivé si toute la numérotation avait été faite sur 4 chiffres dès le départ (7-zip pour Windows est l’outil de compression d’origine).

J’ai donc procédé en plusieurs étapes : isolation des fichiers tar à 4 chiffres, concaténation d’une première archive avec les 999 premiers fichiers tar, puis concaténation d’une deuxième archive avec les derniers fichiers, et enfin fusion des deux archives pour extraction. Ensuite, j’ai pu vérifier l’intégrité apparente de l’archive finale :

tar tvf MonArchiveFinale.tar

Tous les fichiers lisibles de l’archive sont apparus, j’ai donc pu les extraire 😊

Quelques techniques de sioux pour sécuriser un hôte Proxmox VE

Maintenant que ma nouvelle installation de Proxmox VE tourne à merveille suite aux déboires que j’ai pu avoir chez mon ancien prestataire, je vais vous dévoiler quelques-unes de mes techniques de sioux pour sécuriser un peu plus un hôte Proxmox, car en configuration par défaut ce n’est pas très excitant. Ces quelques billes ne transformeront pas votre hôte en forteresse inviolable, mais il sera déjà un peu plus blindé ! 😁

Sécuriser SSH

Un petit tour dans /etc/ssh/sshd_config rapidement, et on va procéder au changement de quelques paramètres, tout d’abord le port par défaut sur lequel SSH écoute. Le 22 étant le port par défaut, on va le changer. Naturellement, on évitera de mettre un port qui est déjà utilisé pour une autre application ou qui pourrait être bloqué par un éventuel pare-feu. Ensuite, l’option PermitRootLogin ne doit surtout pas être à yes mais à without-password, prohibit-password ou à no. Les deux premières options peuvent être utilisées avec des clefs SSH, tandis que la dernière bloquera complètement le login en root, forçant un su une fois la connexion avec un utilisateur standard établie.

Rejeter les tentatives de connexion avec une autre IP

Dans /etc/hosts.allow, on va pouvoir définir les adresses IP qui sont autorisées à communiquer avec certains services installés sur la machine. Il peut être judicieux de rejeter les connexions SSH sur toutes les IP sauf une. Par exemple, celle d’un VPN et éventuellement d’une de vos machines virtuelles si vous avez une VM dédiée à l’administration.

Dans cet exemple, je n’autorise qu’une IP à se connecter et je bloque toutes les autres.

sshd : 192.168.1.2 : allow
sshd : all : deny

Autoriser l’accès à l’interface web de Proxmox uniquement sur une adresse ou un range d’IP

Par défaut, l’interface web de Proxmox est accessible sur le port 8006 pour tout le réseau internet. Le moteur web étant basé sur Apache, il est possible d’appliquer des règles allow et deny toutes simples pour n’autoriser l’accès à l’interface web que sur les IP que l’on souhaite. Ici aussi, utiliser un VPN peut s’avérer utile car on déplace derrière une authentification supplémentaire le portail web.

On édite avec nano le fichier /etc/default/pveproxy, puis on saisit les IP qu’on souhaite autoriser ou refuser comme ceci :

ALLOW_FROM= »192.168.1.2,192.168.2.12″
DENY_FROM= »all »

POLICY= »allow »

Un redémarrage de l’interface web est nécessaire :

pveproxy restart

Installer fail2ban

fail2ban est une application tournant en tâche de fond qui écoute les divers logs système et applicatifs et repère les tentatives de brute-force et place en cas d’échecs répétés de connexion les IP dans les règles de rejet du pare-feu ; en conséquence, toutes les IP (ou plage) voient leurs connexions rejetées pendant un certain laps de temps durant la configuration. Celle par défaut suffit normalement pour le peu de services qui sont en théorie installés sur l’hôte.

apt install fail2ban

Le fichier de configuration le plus intéressant est /etc/fail2ban/jail.conf car c’est ici que l’on peut éventuellement ajouter des services à monitorer.

En dehors de ces astuces, je ne saurai que conseiller de créer des utilisateurs avec le minimum de privilège par VM, créer un compte pour l’administration du datastore, et de passer par un VPN pour vous connecter en SSH ou en web. Vous pouvez trouver plus de documentation sur ces liens concernant fail2ban, pveproxy et sshd_config.

Migration des VM d’un hôte Proxmox VE vers un autre hôte sans cluster

Suite à des déboires par rapport à l’hébergeur de mon serveur, j’ai fini par revenir chez OVH chez qui j’ai toujours été satisfait. Sur ce nouveau serveur, j’ai donc rempilé pour la même distribution que l’ancien, un Proxmox VE 5 sur base de Debian 9, pour des raisons de compatibilité principalement, et aussi car j’étais satisfait de cet hyperviseur après quelques années sous ESXi.

Le principal intérêt étant la possibilité de conserver les machines virtuelles et ne rien avoir à réinstaller à part l’hyperviseur lui-même et refaire la configuration (ou plutôt, la redéployer étant donné que j’avais tout sauvegardé), je vais expliquer dans cet article comment procéder à l’export et à l’importation des VM de l’ancien hôte vers le nouveau.

Sur l’interface de Proxmox, sélectionner la machine virtuelle que l’on souhaite sauvegarder, puis aller dans Backup, et enfin, cliquer sur Backup Now. Si le datastore est invisible, il faut activer le stockage de fichiers de sauvegarde dessus (Datacenter > Storage > Edit > Content, cocher VZDump backup file).

La fenêtre de sauvegarde d’une VM. Il faut choisir le datastore sur lequel écrire la sauvegarde, le mode (snapshot, mise en veille de la VM ou arrêt complet) et enfin, spécifier si l’on souhaite une compression de celle-ci et/ou un mail.

Un snapshot n’étant pas suffisant pour restaurer une VM sur un autre hôte sans cluster, il faut donc soit mettre en sommeil la VM le temps de la sauvegarde (option Suspend) ou l’arrêter complètement (option Stop). Dans mon cas, le mode Suspend suffit ; j’ai choisi une compression LZO pour réduire le temps de transfert vers l’autre hyperviseur.

Il se peut que la sauvegarde échoue : le message d’erreur est généralement assez clair, mais s’assurer qu’il ne reste pas un ISO de monté et inaccessible ou que la VM n’est pas en cours d’extinction déjà est un début.

Un écran apparaît alors permettant de suivre le déroulement de la sauvegarde, en fonction de la taille de la machine, de vos performances CPU et disque, il n’y a pas de vrai moyen de déterminer le temps que cela peut prendre. A titre d’exemple, une sauvegarde d’une VM avec un seul disque virtuel contenant environ 65 Go de données s’est terminée en environ 15 minutes (CPU Core i7-4770, 32 Go de RAM, disques SATA 10K).

Une fois la sauvegarde terminée, il va s’agir de la transférer. Le moyen présentant le meilleur ratio simplicité/sécurité est d’utiliser SCP. Dans un shell, nous allons donc nous placer dans le répertoire des dumps, identifier le fichier de sauvegarde, puis lancer le transfert SCP.

cd /var/lib/vz/dump/
ls

La sauvegarde est donc au format .vma.lzo puisque l’on a décidé de compresser en LZO. En cas de doute un ls -l affiche la taille, permettant de différencier le log de la sauvegarde elle-même.

Reste plus qu’à lancer le SCP :

scp vzdump-qemu-machineidtime_stamp.vma.lzo user@destination:/var/lib/vz/dump/vzdump-qemu-machineidtime_stamp.vma.lzo

A noter que machineid et time_stamp sont des variables qui changent naturellement en fonction de l’ID de la VM et de l’heure à laquelle la sauvegarde a commencé ; on utilisera bien sûr le nom récupéré plus haut. scp utilisant SSH, il peut être nécessaire de préciser le port sur lequel écoute SSH sur le serveur de destination (scp -P 2222 par exemple, si le port SSH est 2222). Il faut également que l’utilisateur spécifié soit en mesure d’écrire dans le répertoire de destination. Vous pouvez faire le transfert vers un homedirectory avec un utilisateur tout simple puis ensuite déplacer la sauvegarde vers le répertoire des dumps.

Le temps de transfert dépendant quasi-uniquement de la bande passante entre les deux hôtes, impossible de prédire celui-ci. Une fois le transfert terminé, sur le nouveau Proxmox, il suffit de se rendre sur les propriétés du datastore pour permettre de gérer les sauvegardes si cela n’est pas déjà fait  (éventuellement déjà opéré sur l’hôte d’origine pour faire les sauvegardes) :

En cochant VZDump backup file, on permet au datastore de gérer les fichiers dumps.

Puis, en se rendant dans le datastore lui-même, on aperçoit bien notre backup :

Il ne reste plus qu’à le sélectionner, cliquer sur Restore, indiquer un ID de machine virtuelle libre sur le nouvel hôte et le datastore de stockage. Puis au redémarrage, tout sera comme à l’extinction sur l’ancien hôte 😎

Si l’envie vous prend de réaliser tout en ligne de commande ou que vous ne pouvez pas utiliser l’interface web, je vous renvoie vers la documentation de vzdump et qmrestore.

Création d’un réseau interne grâce au NAT sur Proxmox VE 5

Il y a quelques semaines maintenant, j’ai repensé mon cloud personnel. Auparavant basé sur ESXi, j’ai changé de technologie pour revenir sur quelque chose de plus « léger » que je connaissais déjà : Proxmox. Cet hyperviseur basé sur Debian m’avait causé dans sa version 4 pas mal de maux de tête pour réussir à monter un réseau et donner accès à internet à mes VM sans qu’elles n’utilisent d’IP globales ; la version 5 ne fait pas vraiment mieux, c’est pourquoi je vais partager dans cet article les opérations nécessaires via l’interface de Proxmox et via la modification du fichier /etc/network/interfaces.

Sur l’hôte, dans les paramètres réseau, doivent apparaître juste après l’installation la carte physique de la machine et un bridge. Il est très important de ne pas y toucher sous peine de rendre la machine injoignable après le redémarrage ou la recharge de la configuration des cartes. L’interface web ne semblant pas traduire correctement les valeurs saisies en un fichier de configuration propre, on va donc passer par la modification en direct du fichier /etc/network/interfaces pour y créer un deuxième bridge qui sera notre réseau local.

En l’ouvrant avec nano en utilisateur root, il doit ressembler à ceci (je vais appeler dans cet exemple ma carte réseau eth0 et mon IP 26.10.19.91), en gras les paramètres qu’il faut absolument vérifier afin qu’ils soient sur cette valeur :

auto lo
iface lo inet loopback


iface eth0 inet manual


auto vmbr0
iface vmbr0 inet static
  address 26.10.19.91
  netmask 255.255.255.0
  gateway 26.10.19.1
  bridge_ports eth0
  bridge_stp off
  bridge_fd 0 


auto vmbr1
iface vmbr1 inet static
  address 192.168.2.1
  netmask 255.255.255.0
  bridge_ports none
  bridge_stp off
  bridge_fd 0

Le vmbr1 est le nouveau bridge sur lequel nous allons raccorder nos VM pour leur donner accès à internet et pouvoir faire du NAT afin de les joindre depuis l’extérieur sur la même IP que l’hôte et qu’elles puissent éventuellement communiquer entre elles.

Un redémarrage plus tard (relancer les interfaces réseaux n’est pas suffisant), le nouveau pont doit apparaître dans la section réseau de l’interface web :

Par la suite, en configurant le réseau sur les VM, on indiquera une adresse IP comprise entre 192.168.2.2 et 192.168.2.254 (si vous avez laissé le sous-réseau par défaut) et 192.168.2.1 en gateway. Concernant les serveurs DNS, il est possible d’utiliser des serveurs DNS externes ou internes ; parmi les DNS publics, on peut renseigner par exemple 1.1.1.1 qui est le DNS public CloudFlare, ou le réputé 8.8.8.8 de Google.

Maintenant que les machines peuvent avoir une IP définie, afin de les joindre via certaines applications, il ne reste plus qu’à faire le NAT dans iptables. Toujours en root, on autorise le routage des paquets venant sur l’interface vmbr0 (qui est liée à eth0, la carte physique liée à internet) vers notre sous-réseau fraîchement créé :

iptables -t nat -A POSTROUTING -s ‘192.168.2.0/24’ -o vmbr0 -j MASQUERADE

Et enfin, si l’on souhaite ouvrir le port 80 sur 192.168.2.2 :

iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

A noter que si l’on souhaite simplement retirer une règle, on remplace -A par -D. iptables ne sauvegardant pas de manière permanente les règles, elles sont perdues au redémarrage. Il est possible d’installer des applications permettant de faire des backup/restore des règles ou bien d’ajouter les règles au fichier /etc/network/interfaces en utilisant post-up pour les règles à exécuter une fois que l’interface est montée, et post-down pour celles a exécuter quand l’interface est désactivée. Par exemple :

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

Pour plus d’informations concernant iptables et ses possibilités, je vous renvoie à ce lien.