Re: renommer l'interface réseau
Je pense que Christophe réagissait à mes anecdotes de nommages des interfaces lors de l'installation seulement ;) Qui pose effectivement souci quand on ne sait pas vraiment quelle interface on a derrière eth0 + eth1 + ethX... lors de l'étape du paramétrage du réseau ;) Le 18/08/2017 à 20:09, Pascal Hambourg a écrit : > Le 18/08/2017 à 10:56, Christophe De Natale a écrit : >> >> eth0 correspond à l'interface dont la valeur de l'adresse mac est la >> plus faible et ainsi de suite. >> C'est du moins ce que j'ai constaté sur un serveur installé sous Eole >> (base Ubuntu) dans lequel il y avait plusieurs cartes réseau. > > Pure coïncidence. > Soit elles sont numérotées dans l'ordre naturel de découverte, soit il > y a un schéma de nommage persistant. > Mais une numérotation selon l'ordre croissant des adresses MAC, c'est > tout sauf persistant : si on ajoute, retire ou change une carte > réseau, toutes les autres risqueraient d'être renommées ! > signature.asc Description: OpenPGP digital signature
Re: renommer l'interface réseau
Le 18/08/2017 à 10:56, Christophe De Natale a écrit : eth0 correspond à l'interface dont la valeur de l'adresse mac est la plus faible et ainsi de suite. C'est du moins ce que j'ai constaté sur un serveur installé sous Eole (base Ubuntu) dans lequel il y avait plusieurs cartes réseau. Pure coïncidence. Soit elles sont numérotées dans l'ordre naturel de découverte, soit il y a un schéma de nommage persistant. Mais une numérotation selon l'ordre croissant des adresses MAC, c'est tout sauf persistant : si on ajoute, retire ou change une carte réseau, toutes les autres risqueraient d'être renommées !
Re: renommer l'interface réseau
On Friday 18 August 2017 10:56:24 Christophe De Natale wrote: > eth0 correspond à l'interface dont la valeur de l'adresse mac est la > plus faible et ainsi de suite. > C'est du moins ce que j'ai constaté sur un serveur installé sous Eole > (base Ubuntu) dans lequel il y avait plusieurs cartes réseau. Le nommage des interfaces réseau se trouvent dans ce fichier : /etc/udev/rules.d/70-persistent-net.rules On peut très bien avoir eth12, wlan50, mais la logique veut que ce soit plutôt eth0 et wlan0, si on a qu'une seule interface réseau eth et wlan. André
Re: Début de la fin pour Btrfs?
Le 17/08/17 à 09:23, "Pierre L." a écrit : PL> > gparted fonctionne trés bien avec. Ne pas oubliez de mettre brfs-prog/btrfs-tools PL> > et ça roule !! PL> Ok à savoir ! PL> Dommage que Debian n'intègre pas ces paquets nativement alors ? Ils y sont : apt-cache policy btrfs-tools Table de version : 4.9.1-1~bpo9+1 100 100 http://http.debian.net/debian stretch-backports/main amd64 Packages 4.7.3-1 500 500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages J'utilise btrfs sur un serveur de backup, pour avoir plein de snapshots avec peu d'espace disque. Avant, j'utilisais ext4 et je faisais du `cp -al` pour gagner de la place (principe des hard link qu'utilise rsnapshot depuis des lustres), mais la machine était à genoux plusieurs heures pendant la rotation des snapshots. Maintenant, je fais avec btrfs - rsync de tous mes serveurs vers last/ - si on est vendredi, effacement de snapshot_friday, mv last snapshot_friday, btrfs snapshot de snapshot_friday en last - si on est dimanche, idem avec en plus un snapshot de snapshot_sunday => snapshot_week_XX Attention, l'ordre de filiation des snapshots est TRÈS important. Il ne faut pas trop écrire sur un volume source d'autres snapshots, sinon btrfs s'affole. Pendant un moment, je faisais pas le mv `last snapshot_friday` et faisais un snapshot de last en snapshot_friday, mais je me retrouvais alors avec un système qui exlosait rapidement (le rsync vers last faisait exploser btrfs qui n'arrivait pas à gérer le cow vers tous les snapshots qui dépendait de last, il bouffait à lui seul les 32Go de RAM puis y'avait du oomkill à gogo jusqu'à ce que tout soit planté). Maintenant, ça plante plus, mais le serveur est tout aussi à genoux qu'avant avec ext4 et mes `cp -al` ;-) chaque snapshot contient bcp de fichiers (qq millions, pour une vingtaine de VMs), j'ai une quinzaine de snapshots de l'ensemble pour le moment, et ça prend bcp moins de place qu'avec mes cp -al d'avant (qui demandaient au moins un bloc par hard link), mais je dois quand même de temps en temps virer des snapshots week_xx pour que ça tienne sur mes 8To dispos (j'arrive pas à conserver les 52 snapshots d'une année complète). Ceci dit, la prochaine fois je repasserai probablement en ext4, car j'aime pas du tout le coté lazy de btrfs, qui déclenche des io de malade quand il veut et fait exploser le load quand on s'y attend pas forcément (un subvolume delete va faire monter le load qq heures plus tard, 10min ou 4h on sait pas trop, mais quand btrfs va s'y mettre la machine répondra plus à grand chose d'autre, ça plante pas mais faut 30~60s pour avoir le résultat d'une autocomplétion dans un shell par ex, je vous parle pas d'une manip plus gourmande…) -- Daniel Bah oui , c'est la crise , c'est à dire qu'il va falloir que vous vous passiez de trucs dont vos parents n'avaient pas besoin ! Coluche
Re: renommer l'interface réseau
Le 16/08/2017 à 23:19, Pierre L. a écrit : Merci à vous pour les infos! Oui ca m'a déjà gonflé d'avoir ton linux qui te demande comment régler ton eth0 et ton eth1 (certes mon petit, c'est laquelle qui est quoi ??), c'est au petit bonheur-la-chance de tomber sur la bonne interface ! eth0 correspond à l'interface dont la valeur de l'adresse mac est la plus faible et ainsi de suite. C'est du moins ce que j'ai constaté sur un serveur installé sous Eole (base Ubuntu) dans lequel il y avait plusieurs cartes réseau. Idem avec les disques durs, si t'as eu le malheur de ne pas noter quel dur est ton sda pendant l'install (si plusieurs disques), et que monsieur grub te demande où se poser... :s Paff mauvais choix...! Rien de bien grave en soit, on peut toujours rattraper le tir après install, mais c'est encore une petite perte de temps et quelques cheveux qui tombent :/ Le 15/08/2017 à 19:25, Pascal Hambourg a écrit : Le nommage initial des disques et des interfaces réseau par le noyau suit le même principe : les périphériques peuvent apparaître dans n'importe quel ordre et sont nommés par le noyau dans l'ordre de leur apparition. Par contre la gestion de la situation par udev dans les deux cas est totalement différente. Dans le cas des interfaces réseau, udev les renomme avec des noms stables, alors que dans le cas des disques udev leur crée des alias stables. C'est seulement la méthode de renommage des interfaces réseau qui a changé entre Jessie et Stretch.
Re: Début de la fin pour Btrfs?
Quelques personnes dans mes alentours ont été très heureuses de retrouver les photos de famille et autres qui se trouvaient dans un disque externe qui avait bien buggé (causes inconnues à notre niveau...) ! Les utilitaires de premiers secours avaient bien fait le boulot, sans être obligatoirement un spécialiste de la chose qui va te prendre 100€ / fichier récupéré ;) J'espère imaginer que d'autres solutions de sauvegarde ont été mises en place dans ces maisons... et là ce n'est plus qu'un histoire de système de fichiers, mais de stratégie de sauvegarde. Surtout si btrfs est plutot apparemment destiné au système et moins au stockage... Cependant, ext4 pour le citer a l'air de faire un peu tout non ? (système + stock) Le 17/08/2017 à 19:46, Pascal Hambourg a écrit : > De toute façon la récupération de données effacées, dans le genre > aléatoire, ça se pose là. Il ne vaut mieux pas compter dessus quel que > soit le système de fichiers, et ce n'est certainement pas le genre de > critère sur lequel je me baserais pour choisir un système de fichiers. signature.asc Description: OpenPGP digital signature