Re: renommer l'interface réseau

2017-08-18 Par sujet Pierre L.
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

2017-08-18 Par sujet Pascal Hambourg

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

2017-08-18 Par sujet andre_debian
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?

2017-08-18 Par sujet Daniel Caillibaud
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

2017-08-18 Par sujet Christophe De Natale

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?

2017-08-18 Par sujet Pierre L.
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