Bonjour,
depuis des années, j'utilise debian comme système d'éxploitation... Je commence donc à être un peu rôdé... Sauf que voilà, un client a acheté du red hat entreprise 4, et j'dois aller installer et configurer une série de trucs dessus en mode urgent++
D'où ma question, existe-t-il un guide de survie du debianeux en milieu hostile ? Un truc qui recenserait les différences utiles à connaitre, genre le /ets/sysconfig/network, l'organisation des fichiers rc.d, le système de package (rpm seul ? ou urpmi/apt/trucmuche ?)
Bref, comme les délais sont shorts, j'ai pas envie de passer 3 heures sur une connerie que j'avais pas prévue, genre le hostname mal réglé (en souvenir d'une bataille acharnée sur feu mandrake il y a quelques années, et un script qui me remettait l'ancien hostname à chaque reboot :)
Merci pour les eventuels liens
Forum Linux.redhat Guide Debian -> Red Hat
5
fév.
2008
# Pour faire court
Posté par madko (site web personnel) . Évalué à 2.
Tu y trouve dedans:
DEVICE=ethX
IPADDR=192.168.0.1
NETMASK=255.255.255.0
ONBOOT=yes
HWADDR=00:00:00:00:00
pour la gateway ainsi que le hostname c'est dans /etc/sysconfig/network
HOSTNAME=toto
GATEWAY=....
Bref c'est pas compliqué et c'est pas hostile :p
Tu as pas mal d'outils texte et graphique qui commence par system-config-* (genre system-config-network) mais ils sont pas forcement installé...
enfin bref:
http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-ne(...)
centos = version recompilée des RHEL (là c'est la 5 mais si tu remonte t'as les version precedente)
[^] # Re: Pour faire court, pour complèter
Posté par tguez . Évalué à 1.
Pour switcher entre le mode texte et le mode graphique, ça dépend de $DISPLAY, bien défini sur un écran autorisé ou pas.
Pour les paquetages, correspondance Debian/RedHat :
Debian <--> Redhat
dpkg <--> rpm
dselect (Front-end semi-graphique pour dpkg) <--> redhat-config-rpm ?
apt-* et aptitude <--> urpmi (RedHat/CentOS/Whitebox) - yum (Mandriva)
synaptic <--> Voir-dans-les-menus-en-mode-root !
[^] # Re: Pour faire court, pour complèter
Posté par CrEv (site web personnel) . Évalué à 3.
apt-* et aptitude <--> yum (RedHat/CentOS/whitebox) - urpmi (Mandriva)
[^] # Re: Pour faire court, pour complèter
Posté par madko (site web personnel) . Évalué à 1.
d'ailleurs ya meme apt4rpm, smart etc
[^] # Re: Pour faire court, pour complèter
Posté par tguez . Évalué à 2.
J'ai fait un peu vite là... C'est vrai aussi que maintenant j'utilise beaucoup moins du RedHat, je suis plus debian. Même si j'ai commencé tout seul il y a longtemps avec de la Mandrake puis RedHat (7.2, 9.0, RHEL) jusqu'à faire des paquets, je trouve debian plus facile, peut-être aussi grâce à l'ambiance de travail où je suis et l'aide précieuse de collègues futés.
La Rosetta stone citée par lom un peu plus loin est un trésor !
Pour mieux comprendre les installations réseau avec kickstart, RedHat magazine dans ses premiers numéros parus en France a été précieux pour moi http://www.redhatmagazine.com/.
# Rosetta Stone
Posté par lom (site web personnel) . Évalué à 3.
C'est de toute facon un lien indispensable avoir sous la main.
http://bhami.com/rosetta.html
# Les scripts d'init et rpm
Posté par madko (site web personnel) . Évalué à 3.
chkconfig --list
chkconfig service_truc_muche on (ou off)
tu peux specifier les runlevel bien sur. Pour l'ordre c'est en debut du script d'init ya un commentaire utilisé par chkconfig par ex:
#! /bin/bash
#
# network Bring up/down networking
#
# chkconfig: 2345 10 90
Pour executer un script d'init t'as la commande service
service network [start|stop|restart|status...]
ça evite de taper le chemin complet vers le script /etc/init.d/network...
Quelques commandes rpm utiles:
Avoir le contenu d'un fichier rpm:
rpm -qpl package.rpm
Pareil pour un rpm deja installé:
rpm -ql package_installé
Connaitre la version d'un package installé
rpm -q package_installé
Voir tous les rpm installés:
rpm -qa
Pour voir les dependances
rpm -qpR package.rpm
bref ya plein de trucs sympa, man rpm sinon
Installer un rpm meme s'il l'est deja par ex
rpm -ivh --force package.rpm
Ou lui dire de pas gerer les dependances
rpm -ivh --nodeps package.rpm
Si c'est pour mettre a jour
rpm -Uvh package.rpm
Pour yum c'est facile
Rechercher un nom de package
yum list "*recherche*"
Rechercher un package
yum search truc
Pour installer
yum install package
Pour mettre a jour le systeme
yum update
Pour lister les mises a jour
yum list updates
Pour upgrader un package
yum upgrade package
Les options generiques de yum sont dans /etc/yum.conf
Et les repositories sont en general dans /etc/yum.repos.d
Par contre je crois que sur les RHEL 4 et anterieur yum devait pas etre present, jdis peut etre une betise, c'etait pas uniquement de base up2date?
Apres la grosse difference entre debian et RH ça va etre la confection de package mais t'en as peut etre pas besoin.
# Merci
Posté par cho7 (site web personnel) . Évalué à 1.
Sinon pour ce qui est de créer ses paquets, pas de soucis de ce coté là, ce n'est absolument pas prévu au programme :)
Parcontre j'aurai surement à monter un serveur ftp vite fait, ainsi qu'un accès ssh bien sûr... C'est ces deux étapes qui m'inquiètent le plus, car si ils ne sont pas installés (très probable pour le ftp), je vais devoir jouer avec le gestionnaire de paquet yum/up2date/urpmi/... et j'avoue que j'en ai de mauvais souvenirs (rpm c'est le truc où faut relancer 4 fois la commande en ajoutant à chaque fois à la ligne un package supplémentaire pour satisfaire une dépendance, non ?).
Ensuite le réseau devra marcher ofcourse, sinon le ftp on le verra pas depuis l'exterieur...
Bref, dire que ce client a pris linux simplement parceque "c'est moderne il parait". Ils auraient pu prendre du debian au moins :) Plus sérieusement, et pour ouvrir une parenthèse culturelle, à l'heure actuelle les linux en prod coté serveurs, c'est essentiellement du redhat ou bien certaines sociétés prennent du debian (comme Free, il me semble... Et Ubuntu perce sur le marché peut etre désormais, comme ya une société derrière ?)
[^] # Re: Merci
Posté par Cereal Killer . Évalué à 2.
Là où je bosse (GROSSE boite), les distrib installé/installable sont sur un référentiel et les critères de choix sont uniquement "le support" ... donc redhat!
Je me suis donc retrouvé face au même problème que toi. Debianeux convaincu, j'ai du m'adapter a redhat et ce qui à été un peu déroutant la première fois, c'est la tourner de paquet installé par défaut! Xorg, gnome, le fax, l'impression, la messagerie j'en passe et des pires ...
Donc la première chose que j'ai fait, c tout viré et remettre le système à plat. Tu vire a grands coup de yum remove ou rpm -truc.
Une fois ton système à peu près propre, tu t'attaques aux services réseaux inutiles et si t'as besoin d'un serveur de messagerie, met un bon postfix des familles (c sendmail par défaut y m'semble).
Ensuite, le deuxième truc über crade, c qu'il fait du lvm par défaut (ça c bien) mais il ne créer qu'un lv et un vg ... équivalent à une partitions avec tout dedans! c déroutant pour un debianeux qui taille ses partoches proprement. Donc où tu squiz lvm et t'y fait à l'ancienne, où tu prend le temps de tout faire tes volumes logique.
Autre chose, redhat (dans la version qu'on m'a livré) avait tout un tas de trucs par défaut style logwatch, auditd et selinux d'activé ... à toi de voir s itu veux garder ou non. Les confs d'ssh sont bien différentes de debian aussi (root peut se logguer par défaut y m'semble).
Si t'as un apache à installer, finit les pt'it script sympa genre a2enmode a2ensite etc, etc ... tout est à faire a la main sur redhat.
Encore un truc que je pense, le script adduser ne fonctionne pas du tout comme debian! rtfm.
C'est tout c'qui me viens pour l'instant.
Courage, RH c'est pas la panacé, mais ça reste libre :)
Sylv
[^] # Re: Merci
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 2.
Cela permet d'installer au petit oignon, en évitant pas mal de paquets à supprimer ensuite.... et du coup on peut créer plusieurs vg, etc... aussi
bref, à regarder de près.
Là où une debian tiens très haut le dragé à une redhat c'est :
- Upgrade d'une version à une autre
- Installation à distance (le mode SSH à distance de l'installeur Debian est très très cool)
[^] # Re: Merci
Posté par madko (site web personnel) . Évalué à 0.
et le mode vnc de l'installeur RH il est pas bien? c'est sur c'est moins pratique que ssh mais bon
[^] # Re: Merci
Posté par madko (site web personnel) . Évalué à 0.
Alors que yum c'est un gestionnaire de packages, donc il sait gerer les dependances. Mais si t'as pas yum... j'ai pas assez joué avec up2date ou avec de vrai rhel4 pour savoir si ya un gestionnaire de packages correct. Et franchement yum ça vaut largement aptitude, jle trouve meme plus rapide :p
Pour ssh c'est un service installé et activé par defaut, root peut se loguer bien sur par defaut aussi.
Pour ftp, je crois que RH met en avant vsftpd il est peut etre installé par defaut. Mais bon si tu prefere proftpd ou autre sont surement dispo en package
Là où jsuis en mission j'm'occupe justement de creer leur distro basé sur une RH recompilé a partir des sources (on n'aime pas les licence ici), et j'aime bien debian mais RH ya rien a redire c'est plutot carré, enfin ça marche quoi. Là où ça peche c'est le support materiel ils trainent un peu a sortir des mises à jours.
Bref tout ça pour dire que ça va dependre de la boite où t'es ils peuvent tres bien avoir comme nous customisé leur install de RH (avec kickstart c'est tellement facile, pour avoir les services et packages qu'ils veulent, les partoches aux ptits oignons etc). ça sera la surprise :p
En tout cas courage!
[^] # Re: Merci
Posté par gaaaaaAab . Évalué à 1.
Yum, c 'est la surcouche qui connait le net, et qui sait télécharger des paquets en résolvant les problèmes de dépendance à ta place.
A noter aussi, il me semble, que rpm/yum ne gèrent pas la présence d'un même paquet dans plusieurs versions différentes aussi bien qu'apt. Du coup, une install d'un truc un peu récent peu forcer l'upgrade d'une tripotée de paquets. (genre un upgrade de python). Et quand l'espace disque est limitée sur la machine, ça peut devenir problèmatique (l'update de Fecora 3 à 5, puis de 5 à 7, c'est un peu sport :)
[^] # Re: Merci
Posté par madko (site web personnel) . Évalué à 0.
C'est donc pour ça qu'il faut lui fournir (peut importe l'ordre) tous les fichiers rpm pour resoudre les dep (rpm -ivh dep1.rpm dep2.rpm paquet.rpm etc)
Alors que yum, pas seulement parcequ'il connait le net (rpm aussi, rpm -ivh http://truc/paquet.rpm marche tres bien), interroge un repository (un depot) où des données comme les dependances, le contenu des rpm, leurs descriptions etc sont fournit pour que yum puisse calculer les dependances, faire des test de transaction avant d'installer quoi que ce soit et verifier si ya pas de conflit de fichiers etc. Le depot est par forcement sur le net il peut etre local. Les metadonnées sont dans le sous rep repodata du dépot. Avant c'etait du xml, mais comme c'etait trop lourd c'est passé en sqlite.
Tout ces merveilleux outils sont codé en python, donc ca poutre!
Yum peut gerer les exclusion ça peut aider en cas de soucis pour les grosses upgrade ;)
Ce que j'aime bien sussi dans yum c'est les hook pour programmer soi-meme des plugins, je sais pas si ya le meme truc sur apt. ça gere aussi les transactions apt? C'est pas pour finir sur un troll apt/yum c'est toujours interessant de connaitre leur difference.
[^] # Re: Merci
Posté par gaaaaaAab . Évalué à 1.
pour ma culture, tu sais si rpm connait le net depuis ses débuts ou si c'est un ajout "récent" (c-a-d post-2000 ;-) ?
(oui, j'ai la flemme de chercher sur le net. Non, ce n'est pas la peine de perdre du temps à chercher l'info si tu ne l'as pas en tête :-)
[^] # Re: Merci
Posté par madko (site web personnel) . Évalué à 0.
bon pour le net avec rpm je crois bien que c'est assez recent, ça doit bien etre post 2000 en effet. Faut dire que RPM a vachement evolué, au debut c'etait en perl, apres en C. Et maintenant avec yum et tous les outils en python autour ça devient interessant.
hop l'histoire du rpm http://www.redhatmagazine.com/2007/02/08/the-story-of-rpm/
et un lien plus en rapport avec le sujet initial
http://packman.linux.is/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.