Reprise du message précédent :
Perso je suis un adepte du dd.
Mais on ne peut pas dire que je soit très fin comme garçon ...

Certe c'est une technique :  
dd if=/dev/zero of=file.zero.raw ; sync  
 
Ca marche bien de ton côté ? Tu récupères bien l'espace sur la baie ?

Malheureusement, je m'en sers pour blanchir des baies classiques avant qu'elles sortent définitivement de nos locaux. Pas pour de la récup sur du thin prov ...

J'étais fan à l'époque de red hat avant les versions entreprises, leur noyau linux avec quelques 100 patch était vraiment efficace, tous bien choisis et optimisés pour le serveur dual proc que je gérais à l'époque.
dual PIII ou duel Xeon je sais plus...Pfff ma mémoire c'est du gruyère

Y'en a qui ont fait rejoindre des RHEL6 a des domaines AD nativement (sans soft externes) ? Si oui,vous classeriez ça dans "tendu" ou "trivial" ?

Par nativement, veux-tu dire Kerberos ?

Par nativement, je veux dire juste avec des packages disponibles nativement dans les différents repos officiels RHEL.

Dans ce cas oui.

 
Non jamais essayé encore vue que je n'ai que du RHEL5 sous la main en prod, mais je me tate à faire évoluer certains voir de nouvelles install...il faut que je vende ça à la hiérarchie.

comment faire en sorte que l'interface réseau (seule de la machine) ne soit pas renommée en "em1" au lieu de eth0 ?
 
J'ai essayé de modifier le fichier 70-persistent-net.rules mais il est recréé à chaque boot par le fichier /lib/udev/write_net_rules.
 
 
 
Est-ce qu'il y a un moyen simple de désactiver cette fonction de renommage sans corrompre mon install avec des modif de script à l'arrache ?

http://www.sysarchitects.com/em1_to_eth0

C'est crade ...

Absolument pas.

Quelle est la bonne façon de faire alors ?

Bon alors ça marche. Ca n'avait pas bien marché la 1ère fois sans doute parce que je n'avais pas modifié le script ifcfg-em1. Là la règle est quand même ré-écrite ("70-persistent-net.rules" ) mais elle fait un rename avec eth0.

J'ai supprimé le paquet biosdevname et je n'ai pas eu à modifier les options du kernel (heureusemment).

merci, je commençais à craquer.

Ben la bonne façon c'est de passer sur le nouveau système de nommage je pense

 
Complétement !

Sur des IBMs les interfaces sont en ethX.
Je  n'ai pas de paquets etherconftruc ni biosdevname

C'est une façon de me dénigrer, c'est ça ?! hein ? C'est du joli!

On dénigre pas. On dit que c'est crade

 
L'option biosdevname dans le grub n'est pas sale. Mais vaut mieux le prévoir d'entrée de jeu dans le kickstart ou à l'installation, ça évite d'aller bricoler des fichiers après
 

 
Exrait de la doc Red Hat : "Red Hat Enterprise Linux 6.1 introduces biosdevname, an optional convention for naming network interfaces. biosdevname assigns names to network interfaces based on their physical location. Note, however that biosdevname is disabled by default, except for a limited set of Dell systems. "
 
https://access.redhat.com/knowledge/articles/53579 mais il faut avoir un compte, désolé
 
Device                                   Old Name(s)  New biosdevname Name(s)
Embedded network interface (LOM)   eth[0123...]  em[1234...] *
PCI card network interface           eth[0123...]  p<slot>p<ethernet port> (ex: p3p4)
Virtual function                           eth[0123...]  p<slot>p<ethernet port>_<virtual interface>
 
Systems Affected
 
Consistent network device naming is enabled by default for a set of Dell PowerEdge, C Series and Precision Workstation systems.  For more details regarding the impact on Dell systems, please visit https://access.redhat.com/kb/docs/DOC-47318.
 
For all other systems, it will be disabled by default (see "How It Works" and "How To Enable/Disable" for more details.)
 
De plus, ça dépend si on veut garder un parc homogène ou pas. Car apres, trop l'éclate pour gérer 4000 machines avec des eth0, des p3p4 et autres joyeusetés. Par contre, pour identifier les interfaces quand on construit des clusters, c'est pratique

 
Si t'as un bon outil de gestion, il s'en fout que le device réseau s'appelle em1 ou eth0 ou p2p1 ...  
D'ailleurs, actuellement, quand t'as une boite avec du LOM pourri et une bonne NIC, et que tu veux du network sur la NIC, bien souvent tu te retrouves à avoir tes interfaces "utiles" en eth2/3/4/5 et le LOM non utilisé en eth0/1. Donc, à moins d'avoir un matériel parfaitement homogène (et au delà de quelques centaines de serveurs, c'est impossible !), tes interfaces n'ont pas toutes le même nom ...    
 
 

 
bien sur que si, c'est possible d'avoir un parc homogène niveau interface "utile" en eth0. Il suffit de bien configurer son ifcg-eth0, modprobe.conf et éventuellement udev. Entre les cartes broadcom intégrées de merde qu'on n'utilise pas tellement elles sont pourries, les cartes intel 1G/10G et d'autres modèles plus spécifiques, au taf on n'a aucun problème à ce que tout soit sur eth0. Et on a bien plus de 100 machines pourtant.
 
D'ailleurs, Dell a enfin compris que broadcom par défaut sur leur chassis, c'est naze. Ils proposent enfin de remplacer les cartes embarquées par des modeles Intel (4x1G ou 2x1G+2x10G) sur les poweredge de génération 12  

 
HS/Plus besoin du firmware proprio sous debian ?  

 
Du coup, est-ce que tu arrives à garder tes udev et modprobe.conf homogènes sur chaque serveur ?

 
Pour udev, perso on évite de s'en servir pour les adresses mac. Pour le modprobe.conf et la reorg des cartes, on le fait pendant le kickstart. Et les vieux bousins, ben il n'ont pas ce probleme de nouveau nommage d'interface Et dans le pire des cas, clustershell est ton ami

SystemD ("nouveau" init) qu'en pensez vous ?
 
Pour ma part j'ai peur d'une énorme usine à gaz (parallélisation, écrit en C, cgroup intégré, relance de service, lancement au besoin) pour ne résoudre aucun problème concret (vitesse de boot d'après l'auteur) ...

Si vous deviez parler de Puppet ...
"Trop de la balle. Ultimate tool"
"Sympa mais rapidement limité"
"Toopoorÿ ..."
 
?

Très bien, mais faire attention à ne pas trop en abuser, ce n'est intéressant que pour les confs "factorisables", faire un module qui ne concernerait qu'une machine/un service ça peut rapidement devenir de la perte de temps et donc contre-productif.
Sinon je trouve le démon un peu lourdeau quand même

 
Ultimate tool, une cinquantaine de serveurs puppetizés ici
 

 
Oui, faut pas lancer le démon mais le lancer en cronjob, mais c'est glouton quand même...
 
En fait, on s'est pris 3 ou 4 mois pour se faire une config puppet aux petits oignons avec des classes paramétrées, en versionnant le tout avec git.
 
Même si j'ai pas le temps de puppetizer tout, j'ai une config de base avec apt, ntp, bash, sudo, hosts, ssh, mails/exim, etc.  
C'est tout bête, mais déjà, toute la conf des serveurs est uniformisée (on a une classe base, et toutes les définitions de nodes en héritent).
 
Après, on a apache, mysql/postgresql, dhcp, bind, ldap, tftp, xen, etc.  
Donc le gros de l'infra est homogène et proprement configuré.  
Déjà, ça évite les surprises de configuration hétérogènes, c'est plus facile à comprendre.  
Ensuite, si j'ai un crash, je peux réinstaller extrêmement vite et j'ai presque la garantie que ça marchera du premier coup.
Aussi, si on a un nouveau admin, il regarde les définitions de node, et il comprend la configuration sans investiguer pendant 5 heures.
 
Je suis aussi sur un projet où on est plus de 10 admins, et on a une bonne dizaine de sites aux config très semblables, et là dessus, puppet montre vraiment toute sa puissance (avec la config puppet sous git).
 
La limite a priori, c'est que si on a plusieurs milliers de serveurs, ça scale pas trop, mais j'ai pas vu les limites personnellement...

Bon, je venais pas pour ça à la base    
 
J'ai une centos 5.7 en prod, et on me demande de la mettre à jour en 5.8 (pour la sécurité).
 
Mon soucis, c'est que dessus, j'ai un logiciel en java/tomcat que je ne maîtrise pas du tout, installé par le support d'une société extérieure.  
Je peux me permettre un downtime d'un jour (idéalement, une matinée), mais pas plus
Le support m'a dit que en théorie, je peux mettre à jour en sauvegardant tout au cas où, mais qu'ils n'avaient pas testé eux mêmes. Donc je suppose qu'ils n'ont rien fait de trop mafieux dans leur installation
 
Votre expérience des upgrade centos, ça donne quoi ? douloureux, les yeux fermés, ou pas ?

snapshot LVM, restore sur une machine de test, upgrade et test.
 
5.7 vers 5.8 j'ai pas vu de problème. par contres dès la 6 .0 c'est sportif.

+1.
Un bon backup pour la forme, mais de 5.7 à 5.8 c'est assez doux ...

La mise à jour vers une version mineur se passe en général sans problème, bien qu'il soit conseillé de faire un backup.
La mise à jour vers des versions majeures ne se passent pas très bien en général.

Puppet prend son sens sur des plates-formes importantes, avec des éléments fortement factorisables entre serveurs. Faire attention, ça peut rapidement devenir un piège à temps
Tu devrais pouvoir également trouver des dépots sur le net de personnes ayant publié des configurations : http://svnweb.mageia.org/adm/puppet/

C'est ce que j'envisage de faire pour les machines pour lesquelles je n'ai pas un besoin critique de puppet, enfin du moins j'ai pas besoin
que ça soit synchro dans l'heure, ni de pouvoir forcer depuis le master, mais pour lesquelles ce serait quand même bien pratique de gérer la
base à la main (typiquement les services que tu cites plus bas : apt / sources / preferences, ntp, clefs SSH, exim en relay SMTP...).

Le tomcat est installé à part ou depuis un package de la distrib ? (je sais pas si centos package tomcat... mais Debian le fait c'est pour ça que je demande)
Même question pour le Java.
 
Si à part, ça ne devrait pas poser de problème.
 
Sinon bah faut tester avec une maquette, selon les applis, les upgrade de tomcat peuvent tout péter ou pas
J'ai même eu une MAJ mineure (mais vraiment mineure) de Java qui a fait merder une appli tomcat (une nouvelle classe qui était apparu en standard et qui portait le même nom qu'une classe utilisée par l'appli).

 
On va enfin se lancer dans Puppet pour avoir enfin un parc homogènes (long, très long historiques...). Et avec plus de 4000 serveurs, ça va etre sport. Pour l'instant, on a beaucoup réfléchi à l'organisation de tout le bouzin, sur comment on compte le mettre en place et organiser les recettes, les facts, etc...
 
On devrait bientôt à la phase de test, ça promet !

 
Ca sent les surprises

clairement