Debian - aacraid :mise à jour kernel ou modules en production? - Hardware - Linux et OS Alternatifs
Marsh Posté le 06-04-2006 à 19:33:07
Le choix d'utiliser une Debian Etch est-il proscrit ?
Y'a-t-il un backport pour Sarge ?
Marsh Posté le 06-04-2006 à 23:45:37
elpoulpo a écrit : La logique voudrait que j'installe ce noyau sur tous les serveurs mais vu que ce sont des machines déstinées a être mises en production et pour un bon moment je ne sais pas trop quoi faire (en faisant ça les mises à jour ne fonctionneront plus non?) |
Le bon sens conseille d'utiliser stable donc Sarge sur des machines destinées à la mise en production, et comme tu l'indique le problème concerne plus une issue relative à une version de noyau inadaptée dans Sarge pour le type d'usage RAID souhaité.
Donc la meilleure solution est certainement de backporter pour stable un noyau customisé depuis testing ou unstable, et de le tester un certain temps avant mise en production. Concernant ensuite les mises à jour, celles-ci fonctionneront sans le moindre problème pour tout le reste du système, le seul inconvénient est juste de devoir assurer soi-même le suivi de la sécurité pour le noyau backporté c'est tout.
Marsh Posté le 07-04-2006 à 08:24:10
Je n'ai pas une très longue expérience de debian donc vos éclaircissements ( ) soulèvent d'autres questions:
-Concernant le backport de noyau: je dois me procurer un kernel plus récent incluant les patchs debian donc chercher ses sources dans les branches testing ou unstable, puis le compiler? ou existe-t'il des packages deb? (Je n'ai rien trouvé sur backports.org, j'ai peut-être mal cherché ).
-Les "patchs/modifications debian" apporté aux noyaux sont de quel ordre: quelle différence par rapport à mon kernel récupéré et compilé depuis kernel.org?
-Pour les mises à jour, il me suffira d'exclure le kernel des cycles d'update?
-->Mirtouf: Etch n'est pas proscrit, mais cela me semblait risqué sur le long terme à vrai dire (comme confirmé par THRAK)
Merci
Marsh Posté le 08-04-2006 à 21:48:25
elpoulpo a écrit : -Concernant le backport de noyau: je dois me procurer un kernel plus récent incluant les patchs debian donc chercher ses sources dans les branches testing ou unstable, puis le compiler? ou existe-t'il des packages deb? (Je n'ai rien trouvé sur backports.org, j'ai peut-être mal cherché ). |
Tu as deux possibilités :
1 )- utiliser un noyau précompilé fourni par Debian (patché Debian) que tu installes à partir des dépôts testing ou unstable ou encore depuis backport.org (ils sont dispo, cf. http://www.backports.org/debian/pool/main/l/linux-2.6/) (je te conseille d'opter de préférence pour une version de testing ou backport.org si possible, unstable étant à employer si le noyau requiert obligatoirement une version qui est indisponible ailleurs).
Avantages : profiter d'un noyau récent et fonctionnel avec une mise en place très rapide.
Inconvénients : orienté davantage pour un usage générique (inclu un grand nombre de modules, majotitairement inutiles dans le cadre d'une utilisation serveur), les en-têtes correspondantes peuvent occasionner certains problèmes lors de l'installation/compilation de modules externes (différence de version du compilateur, des libs C).
Après avoir ajouté le dépôt nécessaire dans ton sources.list :
aptitude update && aptitude install linux-image-laversionquivabien
2) utiliser un noyau configuré et compilé par tes propres soins à partir des sources de ton choix
Avantages : tu peux utiliser les sources que tu souhaites en les récupérants au choix sur kernel.org (format .gz ou bz2) ou sur le dépôt testing ou unstable sous la forme d'un paquet .deb installable via APT (linux-source-2.6.X) ou encore sur backport.org, le noyau généré est adapté et optimisé parfaitement pour la machine concernée.
Inconvénients : compiler de façon optimale un noyau nécessite du temps et des connaissances précises sur la manière de le configurer au mieux pour la machine/l'usage concerné, les sources nécessitent un certains espace disque pour la compilation ce qui peut parfois s'avérer problématique sur des machines de type embarquées.
Après avoir ajouté le dépôt nécessaire dans ton sources.list :
aptitude update && aptitude install linux-source-laversionquivabien
elpoulpo a écrit : -Les "patchs/modifications debian" apporté aux noyaux sont de quel ordre: quelle différence par rapport à mon kernel récupéré et compilé depuis kernel.org? |
Voici la description fournie pour les paquets linux-source officiels fournis par Debian :
Citation : |
C'est en général une bonne idée d'installer les sources relatives à sa distribution car le suivi est bon (chez Debian ou Gentoo du moins, pour les autres distros je suppose que les mainteneurs font tout aussi bien leur travail) et certains patches sont intégrés et résolvent des problèmes présents dans les sources officielles.Cela étant, bien sûr rien n'empêche d'opter pour une saveur 'vanilla' et de gérer soi-même les patchs à intégrer pour un contrôle total sur le noyau qu'on souhaite compiler.
elpoulpo a écrit : |
Tout à fait, encore qu'il n'est pas toujours nécessaire d'effectuer cette opération puisque le noyau est installé localement ou dans certains cas le sources.list n'est modifié pour inclure les dépôts nécessaires qu'à l'occasion de l'installation ou des mises à jour ultérieures du noyau (on ajoute dans ce cas l'entrée dans le sources.list puis on la commente après installation des paquets voulus).
Pour plus de sûreté il est possible de marquer un paquet à maintenir via son gestionnaire de paquet. L'opération la plus simple est de passer par aptitude en mode interface de se rendre dans la section intitulée "--- Paquets obsolètes ou créés localement" de sélectionner le paquet à maintenir et d'appuyer sur la touche " = " ; le paquet est alors taggé 'hold' (maintenu), visible par la lettre 'h' ou mis en surbrillance par une ligne grise dans aptitude.
L'opération de marquage de paquet avec le drapeau 'hold' est aussi possible en ligne de commande via dpkg --set-selections (par ex. echo "kernel-image-2.6.16-maversion hold" | dpkg --set-selections).
Notes supplémentaires :
Debian fourni un utilitaire très pratique pour générer ses images de noyau personnalisées sous forme de paquet .deb installable : kernel-package (qui inclu nombre d'outils dont make-kpkg, l'outil de génération automatique de noyau empaqueté).
L'idéal est donc d'installer en supplément les paquets suivants pour disposer d'une trousse à outils complète pour la création de noyaux personnalisés façon Debian : kernel-package, fakeroot (pour compiler en simple utilisateur avec certains des droits root) et libncurses5-dev (pour le menu de configuration graphique via un terminal avec make menuconfig).
Il est possible aussi de rajouter gcc, mais celui-ci est marqué comme dépendance de linux-source et sera donc automatiquement installé si tu optes pour la compilation d'un noyau personnalisé à partir des sources patchée Debian.
Plus d'infos sur la compilation de noyau sous Debian :
---> http://people.via.ecp.fr/~alexis/f [...] noyau.html
---< http://people.via.ecp.fr/~alexis/f [...] noyau.html
Un man make-kpkg apportera aussi un lot d'informations et de précisions utiles
Marsh Posté le 12-04-2006 à 10:42:21
Merci pour cette réponse extrêmement complète
Je vais tester tout ça
Marsh Posté le 06-04-2006 à 17:21:18
Bonjour
J'ai reçu 4 serveurs dell PE 800 equipés des même cartes raid SATA: CERC 5/6S (basées sur des chipstes adaptec 2610SA)
Je dois les mettre en production sous debian sarge.
Cependant, j'ai un problème avec la gestion du RAID (raid 1): en effet ces contrôleurs fonctionnent mais, si l'on simule une panne, on a le droit directement à un kernel panic au boot ou a un serveur un lecture seule à l'utilisation.
En fait dès que la pile raid n'est pas en mode optimal le serveur ne fonctionne plus correctement.
Cette carte raid fonctionne via le module aacraid:
version 1.1.2 sous debian
-Je n 'arrive pas à compiler la dernière version du module (1.1.5)
-En installant une testing le raid fonctionne correctement
-Je viens d'installer un noyau 2.6.16 (avec module aacraid 1.1.4) et le tout fonctionne parfaitement.
La logique voudrait que j'installe ce noyau sur tous les serveurs mais vu que ce sont des machines déstinées a être mises en production et pour un bon moment je ne sais pas trop quoi faire (en faisant ça les mises à jour ne fonctionneront plus non?)
Bref j'aimerais bien vos avis : pour la résolution de ce problème et surtout le meilleur choix à long terme.
Merci