{"id":302,"date":"2010-01-24T20:05:52","date_gmt":"2010-01-24T18:05:52","guid":{"rendered":"http:\/\/gcolpart.evolix.net\/blog21\/?p=302"},"modified":"2010-01-24T20:05:52","modified_gmt":"2010-01-24T18:05:52","slug":"autres-exemples-de-migration-etch-lenny-1","status":"publish","type":"post","link":"https:\/\/gcolpart.evolix.net\/blog21\/autres-exemples-de-migration-etch-lenny-1\/","title":{"rendered":"Autres exemples de migration Etch->Lenny [1]"},"content":{"rendered":"

La fin du support officiel de Debian Etch approchant<\/a>, il est grand temps de migrer vers Lenny pour les machines pas encore \u00e0 jour. Apr\u00e8s un premier exemple de migration Debian Etch->Lenny<\/a>, je poursuis la s\u00e9rie avec des informations tir\u00e9es de plusieurs migrations r\u00e9centes sur des serveurs en production.<\/p>\n

Je ne rappellerais pas<\/strong> toutes les pr\u00e9cautions n\u00e9cessaires (tests pr\u00e9alables, sauvegardes, d\u00e9sactivations des services, etc.) ni la classique question\u00a0 sur\u00a0 “quand faut-il migrer ?”, vous trouverez tout cela dans mes exemples pr\u00e9c\u00e9dents<\/a>. Je rappelle simplement l’id\u00e9e de base : prendre les pr\u00e9cieuses Release Notes<\/a>, mettre \u00e0 jour le fichier sources.list<\/em>, puis ex\u00e9cuter les commandes aptitude update && aptitude upgrade<\/em>x, puis mettre-\u00e0-jour les services les plus critiques via aptitude install <PACKAGE><\/em>, et enfin aptitude dist-upgrade && aptitude dist-upgrade<\/em> (r\u00e9p\u00e9ter dist-upgrade<\/em> est souvent n\u00e9cessaire).<\/p>\n

Passons d\u00e9sormais aux diff\u00e9rentes remarques sur ces migrations :<\/p>\n

– PostgreSQL : on passe de la version 8.1 \u00e0 8.3. Notez qu’il s’agit de paquets diff\u00e9rents, il est donc possible de garder la version 8.1 en Etch, et d’installer en parall\u00e8le la version 8.3, afin de faciliter encore plus la migration. Pour migrer les donn\u00e9es, on r\u00e9alisera un dump avec pg_dumpall <\/em>qui sera r\u00e9inject\u00e9 dans la nouvelle base. On pourra ensuite adapter le port dans postgresql.conf<\/em> pour passer la version 8.3 en production.<\/p>\n

– phpPgAdmin : avec PostgreSQL 8.3, on ne peut plus se connecter \u00e0 la table template1<\/em> : c’est le comportement par d\u00e9faut de phpPgAdmin, qu’on devra donc modifier en mettant postgres \u00e0 la place (pour la variable $conf[‘servers’][0][‘defaultdb’]<\/em> dans le fichier config.inc.php<\/em>)<\/p>\n

– Apache : la configuration de l’alias \/icons\/<\/em> est d\u00e9plac\u00e9 dans le fichier mods-available\/alias.conf<\/em>, il peut donc faire doublon avec la d\u00e9claration dans apache2.conf<\/em>, ce qui sera signal\u00e9 via le warning suivant : [warn] The Alias directive in \/etc\/apache2\/apache2.conf at line 240 will probably never match because it overlaps an earlier Alias<\/em>. Commenter les directives dans le fichier apache2.conf<\/em> r\u00e9soudra ce petit soucis.<\/p>\n

– OpenLDAP : on passe d’une version 2.3 \u00e0 2.4, mais le plus marquant pour la migration est que cela force le processus \u00e0 tourner avec un utilisateur\/groupe d\u00e9di\u00e9. Pour diverses raisons (dist-upgrade<\/em> interrompu par exemple), on pourra rencontrer des soucis plus ou moins alarmants. Ainsi, j’ai pu rencontrer cette erreur :
\n bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
\nbdb_db_open: database “dc=example,dc=com” cannot be opened, err -30978. Restore from backup!
\nbackend_startup_one: bi_db_open failed! (-30978)
\nslap_startup failed
\n<\/em>On veillera donc sur l’utilisateur\/groupe propri\u00e9taire des fichiers dans le r\u00e9pertoire \/var\/lib\/ldap<\/em> et, au besoin, on ajustera : chown -R openldap:openldap \/var\/lib\/ldap\/
\n<\/em>Mon conseil : mettre-\u00e0-jour le paquet slapd<\/em> de fa\u00e7on sp\u00e9cifique avant le dist-upgrade<\/em><\/p>\n

– Postfix : on passe de 2.3 \u00e0 2.5. On notera simplement la valeur par d\u00e9faut de $smtp_line_length_limit characters<\/em> qui passe \u00e0 990, ce qui coupe les lignes trop longues pour se conformer au standard SMTP. Si cela posait probl\u00e8me, on pourrait revenir \u00e0 l’ancien comportement en positionnant smtp_line_length_limit=0<\/em><\/p>\n

– SpamAssassin : l’utilisant en stockant la configuration des utilisateurs dans un annuaire LDAP, le daemon spamd s’est mis \u00e0 r\u00e2ler : cannot use –ldap-config without -u<\/em>
\nLe probl\u00e8me sera r\u00e9solu en ajoutant l’option -u nobody<\/em>, ce qui fera tourner spamd en tant que nobody (ce qui n’est pas une mauvaise chose, au contraire).<\/p>\n

– Amavis : apparemment, lors de la d\u00e9tection d’un virus, le code retourn\u00e9 n’est plus 2.7.1 mais 2.7.0 : 2.7.0 Ok, discarded, id=13735-07 – VIRUS: Eicar-Test-Signature<\/em>
\nRien de bien grave, mais cela a n\u00e9cessit\u00e9 d’adapter un plugin Nagios pour qu’il attende le bon code de retour.<\/p>\n

– Courier-imapd-ssl : apr\u00e8s une mise-\u00e0-jour gardant mon fichier \/etc\/courier\/imapd-ssl<\/em> actuel, j’obtenai des erreurs avec certains clients IMAP :
\n couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number<\/em>
\nEn regardant de plus pr\u00e8s, certaines directives changent dans ce fichier de configuration, et il est donc conseill\u00e9 de repartir du fichier propos\u00e9 par Lenny, et d’y apporter ses modifications (souvent, cela se limite \u00e0 pr\u00e9ciser le certificat).<\/p>\n

– Horde : si vous utilisez une base de donn\u00e9es pour stocker les param\u00e8tres ou autres, la paquet php-db<\/em> (d\u00e9j\u00e0 en Recommends: en Etch) est d’autant plus n\u00e9cessaire, sous peine d’obtenir l’erreur : PHP Fatal error:\u00a0 _init() [<a href=’function.require’>function.require<\/a>]: Failed opening required ‘DB.php’ (include_path=’\/usr\/share\/horde3\/lib:.:\/usr\/share\/php:\/usr\/share\/pear’) in \/usr\/share\/horde3\/lib\/Horde\/DataTree\/sql.php on line 1877<\/em><\/p>\n

– Sympa : on attaque l\u00e0 le cauchemard de mes migrations. \u00c0 chaque fois, tellement de soucis majeurs et mineurs, que j’ai l’impression d’\u00eatre le seul \u00e0 utiliser ce paquet. Voici en vrac tous les soucis rencontr\u00e9s : les accents dans les descriptions ont saut\u00e9s (une sorte de double encodage) et cela a n\u00e9cessit\u00e9 des corrections manuelles, la table logs_table doit \u00eatre cr\u00e9\u00e9e \u00e0 la main (j’utilise Sympa avec PostgreSQL), et enfin une typo surprenante un “GROUP BY” \u00e0 la place d’un “ORDER BY” (j’ai ouvert le bug #566252<\/a> \u00e0 ce sujet).<\/p>\n

– Asterisk : on passe de la version 1.2 \u00e0 la version 1.4. Lors de la migration, j’ai constat\u00e9 un bug \u00e9trange, le fichier modules.conf <\/em>qui charge les modules additionnels a disparu. Du coup, sans lui, Asterisk ne charge pas les modules n\u00e9cessaires (SIP, etc.). Il a donc fallu le restaurer.<\/p>\n

– udev : le meilleur ami des sysadmins (ou pas). Si les migrations douloureuses Sarge->Etch sont loin derri\u00e8re nous, il reste n\u00e9anmoins quelques blagues. La derni\u00e8re en date a \u00e9t\u00e9 un renommage des interfaces r\u00e9seau : eth0->eth1 et eth1->eth2. Classique mais \u00e9tonnant, ce genre d’humour est sens\u00e9 \u00eatre d\u00e9pass\u00e9 gr\u00e2ce aux “persistent rules” qui nomment les interfaces en fonction de l’adresse MAC. \u00c0 rester vigilant sur ce point avant le red\u00e9marrage donc.<\/p>\n

Voil\u00e0 pour les remarques. Vous noterez que je n’ai pas abord\u00e9 le noyau Linux. C’est parce que pour la majorit\u00e9 de nos serveurs, ils sont g\u00e9r\u00e9s de fa\u00e7ons sp\u00e9cifiques (au lieu d’utiliser les noyaux officiels Debian). Ainsi, ils restent dans leur version actuelle (2.6.31 \u00e0 cette heure) pendant la migration. Bien s\u00fbr, cela n’emp\u00eache pas d’effectuer un red\u00e9marrage de la machine suite \u00e0 la mise-\u00e0-jour : cela permet de s’assurer que tout est bien en place et le sera toujours apr\u00e8s un \u00e9ventuel red\u00e9marrage d’urgence.<\/p>\n

Rendez-vous pour de prochaines migrations !<\/p>\n","protected":false},"excerpt":{"rendered":"

La fin du support officiel de Debian Etch approchant, il est grand temps de migrer vers Lenny pour les machines pas encore \u00e0 jour. Apr\u00e8s un premier exemple de migration Debian Etch->Lenny, je poursuis la s\u00e9rie avec des informations tir\u00e9es de plusieurs migrations r\u00e9centes sur des serveurs en production. Je ne rappellerais pas toutes les […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,5,72,69],"tags":[148,84,20],"class_list":["post-302","post","type-post","status-publish","format-standard","hentry","category-debian-fr","category-evolix","category-french","category-planet-libre","tag-debian","tag-lenny","tag-migration"],"_links":{"self":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/comments?post=302"}],"version-history":[{"count":19,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/302\/revisions"}],"predecessor-version":[{"id":322,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/302\/revisions\/322"}],"wp:attachment":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/media?parent=302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/categories?post=302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/tags?post=302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}