Bonjour,
 
Au boulot on est en train de passer massivement nos serveurs vers des machines virtuelles proposées par le service central d'informatique de l'unversité. Ces serveurs sont des RedHat Entreprise 5.4, ma question est simple :  
Comment faites vous dans votre vie "de tous les jours" pour vous en sortir malgré la base de paquets excessivement succincte qui vient avec RHEL ? Sans compter que les versions de ces paquets sont pour le moins anté diluviennes souvent.
Est-ce que vous avez rajouter des repositories externes?
 
J'en ai vu quelques uns qui traînaient sur le net, mais par peur d'installer des programmes (ou des versions) non validés RHEL, je me suis toujours abstenu. Mais là du coup je suis souvent bloqué, et ça se fini en général avec un tour sur rpmfind ou rpm.bones pour télécharger le src.rpm et recompiler le tout, ce qui ne me semble pas vraiment indiqué non plus niveau sécurité.
 
Bref, merci pour vos astuces

l'interet de RHEL ce que les paquets proposé sont assez "éprouvés" (avec le support) donc si tu mets des sources / des paquets folkloriques tu te passes du principal atout de cette distribution

Salut,
 
Entièrement d'accord pour tout ce qui est système, mais par exemple chez nous on utilise beaucoup Ruby comme langage, et dans le repository il y a quasiment rien comme librairies.
Et pis dans le genre "ultra-éprouvé", j'ai quand même un doute J'ai récemment eu un problème avec le module pam_exec.so fourni avec la RHEL, qui ne se comporte pas comme le dit le man. J'en ai parlé avec le dev du paquet et la réponse a été :
 
"The RHEL5 version is far too old." traduisez "La version RHEL5 est bien trop vieille". C'est un bug qui était connu à l'époque et il a été corrigé dans une version successive :s
 
Bref, dans un cas comme le notre, tu ferais quoi?

Quand j'ai pas le choix, j'installe une rhel ou meme une AS4.
Sinon une debian lenny.
 

Oui à ce niveau là je fais pareil (RHEL si j'ai pas le choix, Debian stable autrement).
Ce que j'entendais plutôt c'est : Comment tu ferais si tu devais installer des soft qui ne se trouvent pas dans les repositories officielles? Est-ce que ma démarche te semble la "moins pire" ?
 
merci

Chez nous on a du Scientific Linux (c'est du RHEL recompilé depuis les sources, donc gratuit, utilisé par les univsersités surtout). Meme en desktop on a ca.
L'admin a une liste de repo supplémentaire, mais ne fait que rechercher dedans au besoin, et installe le paquet bidule si nécessaire depuis dab ou autre. Donc au cas par cas, mais au travers des repos, ce qui est somme toutes un bon équilibre entre sécurité et paquets dispos. Par contre, c'est vieux, j'en ai trop marre. Je pousse pour qu'il passe à mandriva (RPM quand meme)  

Ok,
 
je vois que je suis pas tout seul dans ma merde
Quand même, ça fait 2 heures que je bataille pour installer ruby-gnome2 ... Histoire de pouvoir lancer les GUI des programmes qu'on a écrits Quand je pense que sous Debian ça se fait avec un pauvre "apt-get"  

Sinon, je compile avec les versions des sources dont je connais bien les éventuels problèmes.
 

Perso (je suis pas admin) souvent je pose meme pas la question a l'admin. Je compile les libs dont j'ai besoin, je me tape les configuration du genre  LD_LIBRARY_PATH et autres --prefix et j'installe tout en local. C'est long, galere, mais ca marche  

Le seul truc que j'aime pas avec la compilation directe à partir des sources, c'est qu'une fois que tu l'as fait une fois, c'est chiant de retourner en arrière si tout à coup tu trouves un paquet "standard".. Au moins là, le système le verra juste comme une mise à jour d'un paquet pré-existant.
Sans compter que pour la dé-installation éventuelle, un petit yum remove et c'est parti, plutôt que de devoir se garder toutes les sources quelque part en vue d'un make uninstall éventuel ..

il faut utiliser --prefix=/usr/local/tonsoft par exemple

Oui si tu es admin. Sinon dans le home  

oui enfin n'importe hein ^^
 
Normalement sur un volume séparé du système pour pas tout perdre en cas de réinstalle.
 
Créer un /appli est une bonne idée

d'ou classiquement sur solaris le /opt    
C'est souvent celui-ci qui est utilisé sous Linux également

Hello,
 
Question : La version de PAM donnée avec RHEL5 est ultra archaïque (j'en ai parlé par mail avec un des dev de PAM, qui m'a dit qu'il comprend pas comment on peut bosser avec de telles antiquités).
Ceci me pose un problème parce que l'un des modules que j'ai besoin (pam_exec) est buggé dans cette version là.
 
Maintenant, PAM c'est quand même un truc un peu "sensible" à mon sens. J'ai vu que je peux ( = arrive) à compiler une version plus récente. Par contre si je fais mon petit make/make install , sans donner de prefix, il va bousiller tout ce qui a été posé par le package "pam.rpm" non?
Bien entendu, impossible de virer pam.rpm parce que la moitié du système a des dépendances dessus.
 
C'est quoi la solution miracle là? Packager moi même un autre RPM?
Là je suis en train de voir ce que ça donne avec un package fedora "rebuildé" à partir des sources..
 
merci bien

Le support RH, mouahhahaha

C-A-D ?

=> CentOS = Version gratuite de RHEL avec un support système de 7 ans + les màj de sécurité RH en moins de 24 heures => pas de licence ni de compilation      
 
=> Liste de dépot supplémentaire : si on gère correctement la priorité des dépôts, on ne casse pas la stabilité du système    
 
epel => priorité=5
rpmfusion => priorité=6
adobe => priorité=10
remi collet => priorité=10

Oui je sais mais malheureusement je n'y pas le choix. RHEL5 est imposé chez nous