10.09.08
Debian, ça sent la release…
Tiens, on dirait que ça accélère… mes mails ce matin :
Bon, va falloir que je remette à jour ma doc, moi…
10.03.08
Pense-bête pour migrer “sympa”, l’outil de mailing-lists
Salut,
J’ai eu à déplacer l’outil sympa - très bien pour gérer des mailings-lists avec modération - d’un serveur à un autre.
L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.
Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.
Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible - et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix
La migration classique
La base reste la même :
1) Sur la machine cible, installez l’application - même version évidemment, packagée.
2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
3) Reprenez ou adaptez /etc/sympa
4) Exportez/importez la base de données “sympa”, comme une brute, par exemple :
machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
puis
machine_cible:$> mysql -u user -p < migr_sympa.sql
5) Assurez-vous d’avoir les bons identifiants de login de l’application sympa dans les tables “mysql” de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :
use mysql ; SELECT * from user where User = ’sympa’;
La partie spécifique “sympa”
Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d’informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
Donc il vous reste à faire :
La redirection des alias mail
Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d’alias de mail dans /etc/aliases, genre :
sympa: “| /usr/lib/sympa/bin/queue sympa”
listmaster: “| /usr/lib/sympa/bin/queue listmaster”
sympa-request: postmaster
sympa-owner: postmaster
maliste1: “| /usr/lib/sympa/bin/queue maliste1″
maliste1-request: “| /usr/lib/sympa/bin/queue maliste1-request”
maliste1-owner: “| /usr/lib/sympa/bin/bouncequeue maliste1″
maliste2…..
Il faut reprendre cette configuration telle quelle sur la machine cible et s’assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu’elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
Donc dans la machine de départ, vous trafiquerez tout de la sorte :
sympa: “sympa@machinecible.com”
listmaster: “listmaster@machinecible.com”
sympa-request: postmaster (j’ai laissé tel quel, c’est un choix)
sympa-owner: postmaster (j’ai laissé tel quel, c’est un choix)
maliste1: “maliste1@machinecible.com”
maliste1-request: “maliste1-request@machinecible.com”
maliste1-owner: “maliste1-owner@machinecible.com”
maliste2…..
A la recherche du bordel éparpillé partout
Ensuite, je m’étais arrêté là - ahahah, erreur.
Sur l’interface web (la nouvelle), je ne voyais plus mes listes. La raison est que “sympa” stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
Donc, il faut reprendre tout ça sur la machine cible (des bêtes “tar” avec conservation des permissions suffisent).
Finalement, j’ai opté pour un joli :
dpkg -L sympa | less
De là, je suis passé dans tous les répertoires nommés (sauf les doc, le “man” etc - faut pas pousser) et je me suis assuré qu’il n’y ait pas de différence - attention à certains droits en setuid/setgid au nom de “sympa:sympa”.
Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu’à faire, afin de bien faire tous les tests.
Si rien n’arrive, c’est pas grave, vous avez raté un truc.
Si vous recevez la demande de modération, c’est que ça semble bien parti 
Le nettoyage
Lorsque vous ferez le DROP DATABASE sympa sur l’ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :
09.23.08
Mixer les releases Debian, sans trop de risque
Salut,
Il arrive qu’on ait besoin d’une application en “testing” sur un serveur en “stable”. Par exemple OCSInventory-NG. Il y a la bonne et la mauvaise méthode pour faire ça.
La mauvaise méthode (rapide, mais naze sur le long terme)
La méthode bourrin consiste à ajouter momentanément les lignes qui vont bien dans /etc/apt/sources.list, faire un apt-get update, l’installer et enlever les dépôts ensuite.
Ca marche mais on ne profite pas des mises à jour qui peuvent être importantes. Je dis ça car ensuite il vaut mieux enlever ces lignes qui risquent de vous faire migrer une partie de vos applis de “stable” à “testing” (si des fois vous êtes aveugles lors de votre “upgrade” régulier).
A ce propos, il ne faut pas oublier d’ajouter les lignes concernant le dépôt de sécurité.
Exemple, j’ajoute les lignes “lenny” pour donner ça :
deb ftp://ftp2.fr.debian.org/debian/ etch main contrib non-free
deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-freedeb http://security.debian.org/ etch/updates main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free
La bonne méthode (presque aussi rapide)
La méthode propre consiste à garder tout le temps les lignes concernant les 2 (4) dépôts, mais à indiquer à APT le niveau de release que l’on veut conserver par défaut. Pour ce faire, créer un fichier du genre 00release dans /etc/apt/apt.conf.d/. Exemple :
# cat /etc/apt/apt.conf.d/00Release
APT::Default-Release “stable”;
Soyez prudent les 2/3 premières fois où vous mettrez à jour vos dépôts + upgrade. Histoire d’être sûr.
Le bug qui en découle
Souvent, l’effet de bord sera ça à votre prochain “apt-get update” :
Fetched 14.6MB in 50s (292kB/s)
Reading package lists… Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing tkdiff (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/debian_debian_dists_lenny_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn’t rebuild package cache
La correction sera d’augmenter un buffer quelconque pour APT, en ajoutant/adaptant, généralement dans /etc/apt/apt.conf.d/70debconf la ligne suivante :
APT::Cache-Limit 15728640; // 15 MB
Afin de repousser un peu la limite.
Voilà, c’est tout pour cette petite astuce néanmoins bien pratique.
09.22.08
Bip, < tab >, bip, < tab >, bip, < tab >, bip……
Pense-bête tout con mais ça fait tellement de bien : pour couper les p#*_”~s de bips de votre shell ou de n’importe quelle fenêtre - je parle sous Ubuntu, allez dans Système -> Préférences -> Sons puis onglet “Bip système” et désactiver le truc qui va bien.
Je ne sais pas comment j’ai fait pour tenir si longtemps avec cette horreur.
(et avec modconf, vous pourrez virer une bonne fois le module pcspkr (”PC Speaker”), section kernerls/drivers/input/misc - yarglaaaaa)
09.18.08
Microsoft eOpen : toujours aussi merdique…
Comme ça m’arrive 2/3 fois par an, je vais sur eOpen récupérer des licences en masse de logiciels MS dûment achetés (et maintenant pour télécharger les CD car ils ne sont plus fournis).
(Pour ceux qui ne connaissent pas, eOpen est le service pour gérer tout ça)
Et comme à chaque fois, il faut :
- un clic toutes les 5 minutes tellement ça rame
- s’apercevoir que sous Firefox c’est un peu moisi ; donc recommencer la procédure sous IE
- valider 10 étapes pour dire “oui je sais c’est sensible, c’est privé, non je ne piraterai pas, oui lâchez-moi”
- enfin voir son nouveau contrat apparaitre (ouf)
- cliquer sur le bouton pour voir les numéros de licences
- revenir le lendemain et recommencer car il y a 24 heures de délai entre l’ajout et l’affichage des infos du contrat
- se dire qu’en attendant, autant lancer le téléchargement des CD, ce sera toujours ça de pris
- et une fois qu’on approche de ce Saint Graal, on obtient à chaque fois, sans mentir, ceci :
Bon, finalement, je retenterai demain… faut pas être pressé…
09.17.08
Bloquer Hamachi au niveau shorewall et squid
Sympa Hamachi, j’en parlais dans un précédent billet pour l’aspect “je joue en réseau avec mes potes”.
=> Aujourd’hui, j’en parle pour bloquer cette saloperie 
d’outil qui peut apporter de gros ennuis au boulot
Pour rappel, c’est un VPN “zero-conf” qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.
Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye - donc je dois avoir fait le tour de la question), tant au niveau shorewall - si l’accès Internet est direct - qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.
Analyse à 2 balles du comportement de hamachi pour mieux le bloquer
Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
- essayer tout un tas de ports standards
- avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins
MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier - puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.
Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :
1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -
De là, avec quelques commandes hosts, genre :
for i in `seq -f ‘%02g’ 1 40`
do
host ssl-$i.hamachi.cc
done
Ainsi que :
for i in `seq 1 255`
do
host 74.201.74.$i
done
Ce qui donne :
…
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
…
Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.
Blocage niveau shorewall
En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option “blacklist” dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans “blacklist”, ajoutez la ligne :
74.201.74.0/24
Ou, dans “rules”, ajoutez :
DROP lan net:74.201.74.0/24 all
Relancez shorewall via /etc/init.d/shorewall reload
Blocage niveau Squid
Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des “ACL”, ajoutez celles-ci - c’est un exemple à adapter.
acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi
(le tout sur 3 lignes uniquement)
Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload
Validez que ça ne marche plus
Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :
1221666080.309 0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615 0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816 5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html
En images, ça reste sur ça :
09.10.08
Wordpress Debian : attention ça bug
En Debian Lenny, wordpress est passé en 2.5.1 (2.5.1-6 précisemment). Il y avait un warning à l’upgrade (l’occasion de rappeler l’existence du paquet “apt-listbugs” qui vous indique les bugs en cours sur un paquet que vous tentez d’installer/upgrader) qui annonçait que tout était pété en 2.5.1 sur “Sid” (unstable).
Etant en “Lenny” (testing), j’y suis allé confiant, résultat, je tombe sur ce bug et un blog inutilisable, en gros.
Manque de bol, j’ai regardé trop vite la version dispo en Sid. Aussi une 2.5.1, mais la -7, j’avais pas vu. Elle corrige le truc. Donc si vous êtes dans le même cas, ajoutez les sources “sid” dans votre “apt” et faites un “aptitude install wordpress”. Supprimez les listes “sid/unstable” ensuite.
Et pour rebondir sur le post précédent de Cedynamix, incitant à passer en 2.6.2 au plus vite pour raison de sécurité, vous êtes marron si vous en restez au packaging Debian, toutes versions confondues.
09.02.08
Google/Chrome, admettons. Et l’OS c’est pour quand ?
Comme l’a très bien résumé Mr Mozilla Europe (Tristant Nitot) sur son blog, Google a tout intérêt à sortir son navigateur.
En résumé pour être plus libre et créatif dans ses services (et mieux dominer le monde ? les 2 fondateurs ont quand même parfois des idées étranges (si je ne me suis pas trompé de référence, je ne sais plus))
D’autant que vu les abonnés aux différents services Google (gmail etc), ils n’auront aucun mal à le faire répandre, contrairement à Firefox où il faut quand même chercher un peu pour l’installer (je parle des utilisateurs lambda proche du 0 en manipulation de souris - ils sont nombreux).
Là, n’importe quel utilisateur du moindre service Google pourra sûrement installer “Chrome” en un clic qui sera inmanquable sur l’interface dudit service… vous ne croyez pas ?
Bon, moi ce qui me taraude, c’est pas le navigateur, c’est l’OS. C’est pour quand ?
Qu’ils écrivent un OS depuis rien, j’en doute. C’est quand même couillu, surtout pour arriver à maturité (si la maturité d’un OS existe :). Par contre, partir d’un Linux et construire une distrib innovante, ils en ont les moyens, j’en suis sûr.
Je vois le plan d’ici : à l’install, première étape, tu donnes (ou crées) ton ID gmail et de là, ça récupère tout ton environnement OS lié à ta personne : tes applis, tes paramétrages, ton fond d’écran. Bref, tout ce que Google pourrait stocker comme ils aiment le faire.
Ca me parait réaliste :
- prendre un linux
- un système de package simple et et transparent (à la Ubuntu “ajout/suppression”) avec des applis bien senties (c’est beau d’avoir beaucoup de choix mais déroutant pour le commun des mortels à qui IE/media player suffisent puisqu’ils sont fournis)
- un look joli sans trop en faire
- évidemment un clic direct vers les services Google
Avec ça tu couvres beaucoup d’utilisateurs standards (type web/mail/mp3/msn).
Alors, votre avis ? l’OS, il viendra ? sous quelle forme ?
08.06.08
Orange Business Everywhere : pour les costards-cravates avant tout…
La loose…. pour dépanner à distance pendant mes congés (sympa le mec non ?), j’ai installé cet accès 3G-edge-++-gprs-truc-machin de chez Orange. Génial, je teste avant de quitter le bureau, c’est mieux. Lancement d’une connexion SSH….. timeout… Read the rest of this entry »
08.05.08
XUbuntu “persistante” sur USB (MAJ concernant Hardy Heron)
Pour donner suite à mon précédent article sur le sujet, voici une mise à jour depuis la sortie de Ubuntu 8.04.1.
L’article précédent donne quelques informations supplémentaires, n’hésitez pas à aller voir.
Cet article donne simplement la procédure à suivre depuis un poste Linux pour créer un XUbuntu “persistant” sur USB. Si le mot “persistant” ne vous dit rien, il s’agit d’avoir un Live OS sur USB qui se souvient des modifications (fichiers créés/modifiés), des applications installées etc. Bref, un OS vivant et… persistant.
Le principe ? une partition qui est l’image du CD Live OS, l’autre qui est un “espace de stockage” des modifications, une sorte de “/” qui va grossir avec le temps (et vos modifications).
Ce qui m’a donné envie d’en remettre une couche est le fait que sur mon PC principal, la Ubuntu 7.10 donnait un affichage pourri sous X et sur quelques portables, X ne se chargeait pas du tout.
Pour mon PC principal, Ubuntu 8 a réglé le problème. Pour les portables, je verrai plus tard.
Enfin, tenter un upgrade de Ubuntu 7 à 8 ne me paraît pas être une bonne idée : en effet, dans le cadre d’un OS persistant, il y a certes la partie variable, mais aussi toute ce qui est immuable, tout ce qui concerne le boot. J’ai pas osé “upgrader” la distrib. Surtout que c’est plus une solution de dépannage, pas vraiment pour embarquer un réel OS peaufiné aux petits soins, sinon bonjour les problèmes de drivers graphiques par exemple…..
Assez parlé, voici la manip, brutale :
1) Prenez une clef USB d’au moins 1 Go, plutôt une rapide
2) Créez 2 partitions, l’une de 600 Mo (suffisant pour un XUbuntu dont l’ISO fait 540 Mo), type FAT16 (code 6 sous fdisk), l’autre du reste de la clef, type Linux (que vous formatterez en “ext2″, n’allez pas me mettre de la journalisation sur une clef USB ! O_o). La deuxième partition doit impérativement s’appeler “casper-rw” - c’est comme ça que la partition persistante sera identifiée.
Ne pas oublier : rendez bootable la première partition !
3) Formattez les comme suit :
mkfs.vfat -F 16 -n ubuntu841 /dev/sdX1
(remplacez X) et :
mkfs.ext2 -b 4096 -L casper-rw /dev/sdX2
(remplacez X aussi).
Si vous n’avez pas l’application “mkfs.vfat”, installez le paquet “dosfstools”.
4) Copier ensuite le contenu de l’ISO de la mouture d’Ubuntu qui vous convient (XUbuntu, Ubuntu etc) à la racine de la première partition. Je recommande XUbuntu afin d’être “léger” sur tout type de PC.
5) Recopier le contenu de /isolinux à la racine de la clef.
6) Recopier /casper/vmlinuz à la racine de la clef.
7) Remplacez /casper/initrd.gz par celui fourni ici.
8 ) Copiez le fichier syslinux.cfg trouvé ici à la racine de votre clef.
9) Utilisez un “syslinux” récent (ici, version 3.71) si celui de votre distrib date un peu (qui a dit Debian Etch ?) pour rendre bootable la clef :
syslinux -sf /dev/sdX1
(remplacez X)
Démontez votre clef bien proprement, évidemment, et tentez votre chance. Ca devrait booter
Par défaut, vous bootez en mode persistant en tapant “persist”.
Amusez-vous bien.
La doc d’origine, en anglais et qui n’explique absolument rien est là. Certes j’ai été assez rapide aussi, mais mon précédent article devrait vous fournir des explications complémentaires sur le concept de clefs persistantes si vous n’avez rien compris.