Reprise du message précédent :
Hello, quelques news Fireball ? Ca a explosé  ?

Red Hat Summit + Jboss World ... J -7.
Qui qu'y va ?

Je passe mon tour, cette année c'est un collègue qui y va  

très souvent quand j'accède au port USB, ma machine est quasi inutilisable. Pourtant je ne vois pas de message système qui puisse m'aider à dépanner. ça vous dit quelque chose ? typiquement là je fais un dd d'un disque externe via adaptateur sata/usb et ma machine saccade horriblement.

Je vois pas la cause ... Mais un petit coup d'ionice pourrait pas soulager les disques OS ?

Tu le montes comment le disque ? à la mano ou via HAL ? quelles sont les options de montages qui apparaissent alors si tu tapes mount dans un terminal ? (et surtout, y a t'il l'option "sync" dans les options de montage ?)
La copie est faite depuis une interface graphique ou en CLI ?
Est-ce que la charge augmente ou c'est juste un ressenti ?

- disque pas monté. Je voulais faire une remise à zéro
- j'ai fait le dd depuis konsole
- l'interface graphique m'a complètement lâché. en revenant avec ssh sur ma machine la charge était tout à fait normale, mais même un "init 3" ne pouvait plus killer l'interface graphique. Un moment je pouvais encore bouger la souris, puis pschiiit plus rien. J'ai dû rebooter.
 
J'avais déjà eu de très grosses lenteurs avec des générateurs de clef usb bootable qui prenaient énormément de temps à écrire sur la clef. ça peut venir du port usb ?

 
on test sur un périmètre restreint de machine et avec un nombre de recette minimum  
 
Il faut aussi qu'on déploie tout un tas de facts custom avant d'installer l'agent puppet, et qu'on écrive des scripts pour en générer certains automatiquement
 
Bref, ya encore du taf mais ça avance

Sortie de la RH 6.3 adj

http://www.redhat.com/about/news/a [...] -available

 
Comment vous faites pour gérer ces updates sur des machines en prod avec des drivers proprios, dans les cas où c'est impossible de tester et où on ne peut pas se permettre une maintenance de plus d'une demi journée tous les 2 mois (au pire) ?
 
Par exemple, j'ai des drivers proprios sur du centos 6.2 pour du multipath, et j'ai pas le matos en double pour pouvoir tester (on n'est pas encore assez riche   ).
J'ai vu un prestataire carrément désactiver les dépôts dans la conf yum pour bloquer les updates, autant dire que ça ne me convient pas trop...  
En toute logique, les fabricants/presta devrait toujours prévoir le support des mises à jour de sécurité sur les os supportés, mais ça a pas l'air d'être une mentalité très répandue...
 
Ironiquement, je me pose beaucoup moins de questions avec mes serveurs sous debian sans aucun support ni garantie, où je peux me permettre de dégager toutes les dépendances externes au profit des solutions libres intégrées à debian (par exemple, j'ai du dm-multipath sous debian qui ne me pose aucun soucis).
 
Je suis tombé sur un cas il y a peu où le seul os supporté pour la dernière version des drivers (emc powerpath) était Oracle Linux 6.1.  
Etant donné que j'ai aucun contrat de support, et aucune garantie de fonctionnement sur une centos 6.2, autant mettre du Debian \o/
 
Est-ce que je suis totalement à côté ?

 
Sans machines de test à coté, tu es mort pour valider si ça va fonctionner ou pas.
 
Et pour PowerPath, il supporte les RHEL 5.x et 6.x sans probleme depuis les dernières versions

ba tu dois pouvoir demander au support ce qu'il en est de la prise en compte de tes drivers proprios, mais l'idéal c'est de penser à l'origine à ne pas avoir besoin de drivers proprios

Pas sur que tu y gagnes sur du centos par rapport à Debian, scientific linux a un support de 5 ans pour la plupart de ses releases

(Je n'ai pas de machine "en prod", c'est juste que ma conf perso est ma machine de travail et qu'elle doit fonctionner chaque jour de façon fiable)

Se passer de drivers proprio en entreprise, c'est pratiquement de l'utopie à un certain niveau

 
On y arrive assez bien. Mais on a un parc très homogène, donc ça facilite.
Y'a bien Oracle qui a essayé de nous placer ses modules proprio pour le stockage ASM, mais ça a sauté après quelques tests

 
Tout dépend du matériel que tu utilises, c'est pour ça que j'ai précisé "à un certain niveau"   . Quand tu commences à utiliser des cartes réseaux un peu spéciales, des cartes pci-e pour le cache, des fpga maison, tu te retrouves vite embarquer dans une valse de drivers exotiques, et la, sans machines de tests pour compiler/valider que les upgrades se passent biens

Arrivé à Boston hier soir ... Prêt pour le début du Summit \o/

Un bon Summit ... Tom Cameron est vraiment un monstre de présentation.
Y'a eu pas mal de vmware et oracle bashing, mais c'est resté bon enfant.

Le seul point négatif, comme à chaque fois, j'ai qu'une envie en rentrant : faire de la R&D comme un guedin tout en sachant que j'aurai  jamais le temps

 
Le problème, c'est qu'on ne peut pas acheter en double du matos à 70 000€ pour tester...
Enfin, je ferai mon dernier upgrade avant une maintenance, puis je bloquerai la mise à jour de certains paquets systèmes...

En passant, comment auriez vous prévu de "recetter" les actions/opérations de puppet sur les serveurs cibles ? Vérifier qu'il n'y a pas eu de problèmes, que les modifications sont bien appliquées ?
 

http://docs.puppetlabs.com/guides/reporting.html
 
Couplé à foreman c'est juste top

 
 
 
Je sens qu'il va falloir que je m'y penche ......... ils ont bien prévus le déploiement puppet mais rien pour la recette/gestion ......

 
Avec le puppet dashboard
 
http://puppetlabs.com/puppet/relat [...] dashboard/
 
En plus, ça fait des beaux graphiques, donc c'est décideur-compliant \o/
Un admin a aussi codé un outil pour faire un tableau des serveurs en échec, qui ne font plus de report, etc.  
On l'utilise pendant les réunions pour passer en revue rapidement les trucs louches  

et pour vous la jouer pro-actif un peu aussi, non, comme dans les pubs pour les déodorants ?

 
Si pour toi, "pro-actif comme dans les pubs pour déo", ça veut dire réparer avant de faire perdre du temps à des utilisateurs, oui, c'est ça  

Il faut réparer/optimiser seulement quand l'utilisateur se plaint, sinon il va être mal habitué...

Merci pour les liens je vais faire remonter par ici ... avec espoir

 
Ca peu venir des contrôleur, oui, mais pas spécifique a RHEL (je pense aux contrôleurs ASMedia en général qui sont pas copain-copain avec les kernel)
lspci ou hwinfo ou étude des dmesg ou lsusb et voir les notes de compatibilité matériel avec ta distro/voir si y'a moyen d'installer un driver proprio sur ta distro (si depuis le temps tu n'avais pas trouvé la réponse)
Edit : désolée si je répond a une ancienne question et flood un peu le topic

Y'a le topic des certifs qui s'est réveillé ...  
http://forum.hardware.fr/hfr/OSAlt [...] 4561_1.htm

Pour les intéressés du chapeau rouge du sud-ouest, une entreprise cherche du monde connaissant RHEL sur le bout des doigts, depuis 6 mois.
 

Vu le salaire proposé, ça ne m'étonne pas qu'ils ne trouvent pas si en plus ils exigent des certifs

Voilà perso c'était surtout car c'était proche d'un point de chute éventuel le temps de trouver un appart/baraque à louer voire acheter sur le coin, mais bon le coup des certifs, ça m'a tué

http://www.linuxfordevices.com/c/a [...] LF-fellow/
 
Nouveau support 10 ans + GKH dans la boutique

Reculer pour mieux sauter ... Mine de crayon, il faudra bien faire la mise a jour a un moment donné : faudrait même que ça passe inaperçu pour continuer a pousser les migrations vers RHEL 6 ...

RHEL5 n'est déjà plus suffisant pour tirer pleinement parti des derniers AMD 6378. Ca va encore inciter les développeurs à ne pas migrer leurs softs vers les derniers OS et ça bride les perfs.  

 
T'as des détails ?

demain

Demain j'aurai peut être déjà acheté assez de 6378 pour remplir un datacenter. Ca sera de l'argent gaché. Je te blamerai

 
J'espère que t'as pas acheté par mégarde tout un rack de machines incompatibles.    
http://developer.amd.com/wordpress [...] SCREEN.pdf
 

Bon ça va, je suis pas dedans
Au pire, ça aurait été un poids de plus en faveur d'une migration vers RHEL6.