ka.da - Tag - ligne de commande

Mercurial : faire des modifications distantes et avoir les fichiers mis à jour sur le serveur

er:k — Tue, 22 Apr 2008 17:49:00 +0200

Aujourd'hui, j'ai découvert quelque chose d'étrange en utilisant Mercurial.

J'ai donc un dépôt privé accessible via https (cf ce post), je le clone, je fais des modifications, je committe, puis je push sur le serveur

$ hg clone https://code.veiras.info/private_repo
$ vi...
$ hg commit -m "nouvelles modifs"
$ hg push
http authorization required
realm: code.veiras.info Mercurial repository
user: X
password: X
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 3 changes to 3 files

Jusque là tout va bien, c'est la façon normale de travailler et j'ai toujours fait comme ça. Sauf qu'aujourd'hui, j'étais également connecté sur mon serveur en ssh, je vais donc dans mon dépôt, un hg tip me dit bien que je viens de faire un commit, mais par contre quand je veux regarder mes fichiers... mes modifications n'y sont pas et là, je tombe des nues : qu'ai-je donc fait mal ? Encore une histoire de permissions sur les fichiers ?

<mode panique>ÇA VEUT DIRE QUE TOUT CE QUE J'AI COMMITTÉ DEPUIS TOUT CE TEMPS EST PERDU ???!!!</mode panique>

vite fait, je saute sur mon client IRC préféré^[1] et rebondit sur #mercurial (sur freenode) où l'on me rassure (?) en me disant que tout est normal.

Pour résumer :

si je veux avoir les modifs également sur les fichiers en local sur le serveur, il faut que je fasse un hg update sur le serveur;
si je veux automatiser cet update, il faut utiliser un 'hook' : plus d'informations sur le site officiel ou sur le guide non officiel;
si on utilise pas sur le serveur le dépôt, on peut même effacer tout les fichiers à l'exception du répertoire .hg/, celui-ci contenant justement tout l'historique du dépôt.
si on veut effacer ces fichiers, un rm * pouvant poser des problèmes plus tard, il est préférable d'utiliser hg update null qui permet de revenir à la révision 0
si jamais on a à nouveau besoin de ces fichiers sur le serveur, un hg update fera l'affaire.

Notes

[1] j'en profite pour signaler l'existence de mibbit.com très pratique quand on est coincé derrière un proxy et qu'on a besoin d'aide...

migration Sarge -> Etch (OCSInventory-NG)

er:k — Mon, 24 Mar 2008 23:03:00 +0100

Comme c'est le calme plat en ce moment sur ce blog^[1], je vais suivre l'exemple de Grégory Colpart et retranscrire ici une migration Sarge -> Etch^[2].

Le serveur en question est un serveur dédié au logiciel libre d'inventaire OCSInventory-NG, c'est donc tout simplement une combinaison de serveur web Apache, de serveur de base de données MySQL, de PHP et de Perl. La vraie particularité (et seule ?) de ce serveur est celle d'être un serveur virtuel Xen.

Une fois le fichier /etc/apt/sources.list édité pour y ajouter les sources de etch, un

# aptitude update
# aptitude dist-upgrade

a suffi pour lancer la migration.

Quelques petits problèmes se sont néanmoins présentés :

Apache ne voulait pas se lancer et j'avais une erreur

[Tue Mar 18 11:40:40 2008] [error] Can't locate Apache/compat.pm in @INC.....
[Tue Mar 18 11:40:40 2008] [error] Can't load Perl module Apache::Ocsinventory for server...

dans mes logs Apache. Il faut alors éditer le fichier de configuration OCS pour Apache (/etc/apache2/conf.d/ocsinventory.conf chez moi) et modifier la ligne

PerlSetEnv OCS_MODPERL_VERSION 2

Explication : la migration m'a fait passé de apache à apache2 et de libapache-mod-perl (version 1.x) à libapache2-mod-perl2 (version 2.x)

j'ai eu quelques problèmes avec MySQL qui ne voulait pas redémarrer, j'en ai donc profité pour migrer de mysql-server-4.1 à mysql-server-5.0 sans problème (à part que le serveur phpmyadmin permettant de gérer les divers serveurs mysql n'a pas le paquet mysql-client-5.0... pour l'instant)

je suis également passé de php4 à php5 sans problème non plus.

Rien de particulier donc. J'ai fait rebooter mon serveur virtuel au cas où, et j'avais, par sécurité, fait une copie de mon serveur virtuel (stocké sur LVM) avant la migration pour le cas où celle-ci se passerait mal. Au final, moins de 2h de maintenance, et moins d'une 1/2 heure - 1 heure je pense, pour ce serveur.

Notes

[1] en partie à cause d'un déménagement qui a entrainé une coupure internet mais pas seulement...

[2] migration non initialement prévue mais, afin de pouvoir utiliser un petit script de ma composition (ocs-ipinterface), j'avais besoin du paquet python-ipy non disponible sur sarge

Mercurial : partage de dépôts différents en http et https + push par https

er:k — Wed, 30 Jan 2008 19:28:00 +0100

J'ai commencé à regarder du côté des SCM^[1] (marre de la gestion CPOLD ;-) il y a quelque temps déjà, et m'était tout d'abord arrêté sur Subversion ^[2] étant novice en la matière. Il s'est vite révélé peu adapté à ma pratique : "développement" sur plusieurs machines pas toujours online, et pas de serveur dédié toujours en ligne pour stocker mes dépôts. Depuis peu, ce dernier problème s'est réglé (merci Gandi Hébergement^[3]) mais pour autant, j'ai abandonné Subversion pour Mercurial, un gestionnaire de code source distribué.

Je ne vais pas entrer ici dans les détails sur les caractéristiques d'un gestionnaire de code source distribué, ses avantages, ou même sur une présentation détaillée sur Mercurial et son mode de fonctionnement (je vous laisse visiter le site officiel pour cela). Je vais uniquement présenter des détails sur la configuration que j'ai mise en place afin de parvenir à partager aisément des dépôts différents via http et https, ainsi que comment faire pour autoriser la mise à jour de ceux-ci via https.

présentation des dépôts Mercurial sur le web

Imaginons que vos dépôts soient stockés dans /mercurial et que vous vouliez pouvoir donner un accès en lecture sur le web, à l'adresse http://hg.domain.tld. Nous allons configurer Apache et Mercurial pour ce faire.

Tout d'abord, nous allons créer un emplacement pour les fichiers web et le script CGI en Python pour Mercurial. Prenons /var/www/domain.tld/hg. Créons à cet endroit un répertoire hgweb dans lequel nous allons placer le script hgwebdir.cgi que vous pouvez trouver sur votre système (sous Debian /usr/share/doc/mercurial/examples/hgwebdir.cgi) ou sur le site de Mercurial. Éditez ce fichier pour avoir à la fin :

def make_web_app():
    return hgwebdir("/etc/mercurial/hgweb.config")

Nous allons ensuite créer le fichier /etc/mercurial/hgweb.config avec un contenu comme suit :

[paths]
depot1  =  /mercurial/depot1
depot2  =  /mercurial/depot2

On peut également utiliser la directive [collections] pour partager une hiérarchie de dépôts mais nous partons du principe que l'on veut contrôler précisément ce que l'on partage.

À partir de là, il nous reste à configurer Apache. Créez un fichier /etc/apache2/sites-available/hg.domain.tld afin de déclarez votre VirtualHost. Voici en exemple mon fichier

NameVirtualHost *:80

<VirtualHost *:80>
    ServerAdmin webmaster@hg.domain.tld

    ServerName hg.domain.tld  

    DocumentRoot /var/www/domain.tld/hg

    <Directory /var/www/domain.tld/hg/>
        Options FollowSymLinks +ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex hgweb/hgwebdir.cgi
        AllowOverride None

        RewriteEngine on
        RewriteBase /hgweb
        RewriteRule ^$ hgwebdir.cgi  [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule (.*) hgwebdir.cgi/$1  [QSA,L]
    </Directory>

    LogLevel warn
    ErrorLog /var/log/apache2/hg.domain.tld-error.log
.   CustomLog /var/log/apache2/hg.domain.tld-access.log combined
    
    ServerSignature Off
</VirtualHost>

Notez ici les règles de réécriture qui permettent de faire disparaître hgwebdir.cgi de vos URL. C'est ce qui m'a pris le plus de temps à trouver avant de tomber sur cette doc.

Activez votre nouveau "site" ainsi que les modules Apache dont vous aurez besoin

# a2ensite hg.domain.tld
# a2enmod mod_python
# a2enmod rewrite
# /etc/init.d/apache2 restart

Vous pouvez maintenant aller voir http://hg.domain.tld et parcourir vos dépôts Mercurial depot1 et depot2

partager des dépôts différents par https

Tout ça, c'est très bien, mais on aimerait également pouvoir avoir accès à certains dépôts que l'on ne veut pas donner en lecture à tout internet : des dépôts privés en somme. Nous allons donc partager ceux-ci sur un site sécurisé avec authentification.

Nous allons donc retourner dans notre répertoire /var/www/domain.tld/hg/hgweb, copier hgwebdir.cgi en hgwebdirssl.cgi et éditez ce fichier pour avoir :

def make_web_app():
    return hgwebdir("/etc/mercurial/hgwebssl.config")

Créons le fichier /etc/mercurial/hgwebssl.config avec :

[paths]
depot1  =  /mercurial/depot1
depot2  =  /mercurial/depot2
depot_prive3 = /mercurial/depot3
depot_prive4 = /mercurial/depot4

Et retournons éditer /etc/apache2/sites-available/hg.domain.tld pour y ajouter :

# en haut du fichier
NameVirtualHost *:443

# à la fin du fichier
<VirtualHost *:443>
    ServerAdmin webmaster@hg.domain.tld

    ServerName hg.domain.tld

    DocumentRoot /var/www/domain.tld/hg

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/hg.domain.tld.pem
    SSLCertificateKeyFile /etc/apache2/ssl/hg.domain.tld.key

    <Directory /var/www/domain.tld/hg/>
        Options FollowSymLinks +ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex hgweb/hgwebdirssl.cgi
        AllowOverride None

        RewriteEngine on
        RewriteBase /hgweb
        RewriteRule ^$ hgwebdirssl.cgi  [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule (.*) hgwebdirssl.cgi/$1  [QSA,L]

        AuthUserFile /etc/mercurial/hgweb.htpasswd
        AuthGroupFile /dev/null
        AuthName "hg.domain.tld Mercurial repository"
        AuthType Basic
#       <LimitExcept GET OPTIONS>
                Require valid-user
#       </LimitExcept>
    </Directory>

    ErrorLog /var/log/apache2/hg.domain.tld-error.log

    LogLevel warn

    CustomLog /var/log/apache2/hg.domain.tld-access.log combined
    ServerSignature Off

</VirtualHost>

On retrouve ici les directives rewrite que nous avons utilisé dans la première partie, à la différence qu'elles pointent vers le CGI spécifique à notre configuration SSL, et quelques directives spécifiques justement à https/SSL. Bien évidemment, il vous faudra créer un fichier de mots de passe (nommé ici hgweb.htpasswd) avec :

# htpasswd -c /etc/mercurial/hgweb.htpasswd hguser

pour autoriser l'utilisateur hguser.

Notez les directives <LimitExcept GET OPTIONS> qui, si elles sont décommentées, permettent à tout le monde de visualiser les dépôts tout en demandant une authentification pour interagir via les commandes de Mercurial (clone, pull, push...).

Rechargez la configuration d'Apache et regardez la différence entre http://hg.domain.tld et https://hg.domain.tld

autoriser la mise à jour des dépôts via https

Pour autoriser le push via https, une fois le travail ci-dessus effectué, il suffit d'éditer la configuration des dépôts en modifiant le fichier .hg/hgrc de chaque projet. Éditez-le ou créez-le et insérez les lignes suivantes :

[web]
allow_push = hguser

utilisation

Voilà c'est fait, vous pouvez maintenant interagir très simplement avec vos dépôts Mercurial. Pour cloner un dépôt public

$ hg clone http://hg.domain.tld/depot1

Pour cloner un dépôt privé

$ hg clone https://hguser@hg.domain.tld/depot_prive3

Pour mettre à jour (push) ce même dépôt

$ hg push https://hguser@hg.domain.tld/depot_prive3

J'ajouterais que le plus dur est de gérer finement les droits d'accès aux divers fichiers nécessaires au bon fonctionnement de cette configuration. Pour faire simple, comme d'habitude, laissez le minimum de droits sur les fichiers de configuration (appartenance à l'utilisateur www-data et lecture pour lui), et pour les dépôts j'ai choisi la solution un groupe devel pour mon utilisateur principal ainsi que www-data et les droits pour ce groupe.

Notes

[1] définition en français et en anglais

[2] cf cet article

[3] je sais que je n'ai pas parlé de cette nouvelle offre très intéressante de Gandi le registrar bien connu (pour sa qualité de service, son support et son engagement) alors allez voir le bar de gandi

utiliser apt-cacher pour les mises à jour de vos machines Debian

er:k — Wed, 09 Jan 2008 11:41:00 +0100

Que ce soit à la maison ou au travail, quand on commence à avoir beaucoup de machines Debian, se pose le problème de leurs mises à jour et surtout de la bande passante utilisée pour celles-ci.

Au niveau Debian, plusieurs solutions existent, comme utiliser un proxy web classique (Squid par exemple), partager le répertoire contenant les fichiers téléchargés (ce qui peut être un peu risqué), répliquer complètement l'arborescence Debian (mais ça demande à télécharger des paquets dont probablement on ne se servira jamais) ou bien encore utiliser un outil dédié à ce problème.
Plusieurs existent : apt-proxy, approx, apt-cacher.

Il semble que de ces différentes solutions aucune ne ressorte vraiment, et que des problèmes existent sur chacune d'elle. En tout cas, ici, je vais vous présenter apt-cacher.

côté serveur

L'installation est, comme d'habitude, facile sous Debian, il vous suffit de faire un

# aptitude install apt-cacher

Ensuite, un petit tour du côté de /etc/apt-cacher/apt-cacher.conf nous permet de configurer l'application, notamment le port d'écoute, le répertoire cache, les hôtes autorisés. En général, les paramètres par défaut sont corrects, je n'ai eu besoin de modifier que les paramètres pour utiliser un proxy :

http_proxy=votreproxy.lan.domain.tld:8080
use_proxy=1

Ensuite, pour permettre le lancement automatique de l'application, il faut modifier /etc/default/apt-cacher

AUTOSTART=1

Il suffit ensuite de vérifier que vos paramètres dans /etc/apt/sources.list sont bons. Il faut par exemple que toutes les distributions pouvant être utilisées par les clients soient listées.

côté client

Il suffit, sur chaque client amené à utiliser le proxy apt, de modifier /etc/apt/sources.list pour avoir au lieu de

deb http://ftp2.fr.debian.org/debian/ etch main
deb http://security.debian.org/ etch/updates main

quelque chose comme ceci pour pointer vers votre serveur apt-cacher et son port associé (3142 par défaut)

deb http://apt-cacher:3142/ftp2.fr.debian.org/debian/ etch main
deb http://apt-cacher:3142/security.debian.org/ etch/updates main

Remarquez que l'on indique à apt-cacher le miroir Debian que l'on veut utiliser, donc, afin de profiter vraiment de apt-cacher, il faut veiller à ce que tous les clients utilisent le même.^[1]

Pour faire la modification facilement, je vous propose une petite ligne de commande sed :

# sed -i -e 's!http://!http://apt-proxy:3142/!g' /etc/apt/sources.list

Pensez à vérifier que les paramètres de proxy apt sont bons, c'est-à-dire en général qu'il n'y a pas de proxy indiqué dans /etc/apt/apt.conf ou dans le répertoire /etc/apt/apt.conf.d/^[2].

Notes

[1] Si vraiment, vous avez beaucoup de clients, et que faire la modification sur chacun devient très compliqué, je vous encourage alors à aller voir du côté de Puppet ou Cfengine. Vous pouvez trouver des informations complémentaires sur debian-administration.

[2] par exemple, xen-tools écrit un fichier proxy-guess dans ce répertoire avec les paramètres proxy de l'hôte Xen dom0

réinstallation de GRUB sur le MBR avec un système sur LVM chiffré

er:k — Fri, 28 Sep 2007 16:24:00 +0200

Après réinstallation de Windows XP sur mon portable professionnel, je me retrouve comme d'habitude à chercher les commandes dont j'ai besoin pour réinstaller GRUB sur le MBR qu'a écrasé Windows et qui m'empêche d'avoir accès à Linux. Voici donc un petit mémo.

J'utilise le live-cd System Rescue CD pour ce faire. Je démarre dessus.

Une fois que j'ai accès au prompt, je déchiffre ma partition chiffrée (ici /dev/hda3) contenant mon LVM.

root@sysresccd /root % /sbin/cryptsetup luksOpen /dev/hda3 hda3_decrypt

Je rescanne les LVM et active les nouveaux volumes découverts

root@sysresccd /root % vgscan
root@sysresccd /root % vgchange -a y

Je crée ensuite un répertoire temporaire où je monte mon / et mon /boot et tous les autres partitions pouvant être nécessaires (/usr est le minimum pour avoir accès à l'exécutable grub)

root@sysresccd /root % cd /tmp
root@sysresccd /tmp % mkdir root
root@sysresccd /tmp % mount /dev/data-root root
root@sysresccd /tmp % mount /dev/hda2 root/boot
root@sysresccd /tmp % mount /dev/data-usr root/usr
root@sysresccd /tmp % mount /dev/data-var root/var

Il suffit ensuite de faire un chroot sur le système Debian et de lancer la réinstallation de GRUB

root@sysresccd /tmp % chroot /tmp/root /bin/bash
sysresccd:/# /usr/sbin/grub
grub> root (hd0,1)
grub> setup (hd0)
...
grub> quit
sysresccd:/# exit

Et voilà, je peux redémarrer et retrouver le menu me permettant d'avoir accès à Debian.

faire tourner Windows sur Xen

er:k — Wed, 26 Sep 2007 22:15:00 +0200

Pour une raison ou pour une autre^[1] vous pouvez avoir envie (?) ou besoin de faire tourner un Windows sous votre Linux. Heureusement, depuis peu Xen couplé à un processeur récent le permet.

prérequis

un processeur HVM : vous pouvez vérifier ici si le vôtre l'est
un poste/serveur Linux Debian Etch minimum^[2] avec Xen fonctionnel
un CDROM d'installation de Windows (je n'ai testé qu'avec Windows 2000 mais XP et 2003 Server semblent fonctionner également)
des petits doigts :) et ce billet

procédure
Pour utiliser les nouvelles fonctionnalités des processeurs virtualisants et donc pouvoir installer Windows^[3] il vous faut installer un package spécial qui fournit les outils utilisateurs

# aptitude install xen-ioemu-3.0.3-1

On copie ensuite le cdrom sur le disque dur

# dd if=/dev/cdrom of=/tmp/win2000pro.iso

On crée un fichier image vide appelé à contenir le système invité (6Go ici)

# dd if=/dev/zero of=Win2k.img bs=1M count=6144

On crée le fichier de configuration Xen /etc/xen/win2000.cfg pour Windows. Voici le mien, adaptez-le à votre configuration

# more /etc/xen/win2k.cfg
kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
memory = '256'
name = 'Win2000'
disk = [ 'file:/mnt/media/data/xen/domains/win2k/win2k.img,ioemu:hda,w','file:/tmp/win2000pro.iso,ioemu:hdc:cdrom,r' ]
vif = [ 'type=ioemu, bridge=xenbr0' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
memmap = '/usr/lib/xen/boot/mem-map.sxp'
boot='d'
sdl=1
vnc=0

Les directives spécifiques à un hôte HVM sont kernel, builder, device_model et memmap.
Dans la partie disk il vous faut spécifier l'image ISO pour l'installation, vous pouvez ensuite connecter votre lecteur de cd-rom en remplaçant la ligne par disk = 'file:/mnt/media/data/system/xen/do....
La directive boot indique 'd' pour booter sur le cd-rom et 'c' pour booter sur le disque dur virtuel.
sdl=1 permet, si vous êtes sous X, d'avoir une fenêtre qui s'ouvre automatiquement quand vous lancez la machine virtuelle ce qui est au moins nécessaire lors de l'installation. Vous pouvez ensuite utiliser le mode de prise à distance que vous préférez. (mise à jour : si vous voulez utilisez VNC, changez sdl=0 vnc=1 et connectez-vous avec vncviewer sur localhost:5900)

Et voilà, un petit

# xm create /etc/xen/win2000.cfg

et c'est parti !

divers
Pour pouvoir monter le fichier image Windows que vous avez un bête mount -o loop ne suffit pas, voici la commande qui va bien

# mount -o loop,offset=$((63*512)),rw /mnt/media/data/system/xen/domains/win2k/win2k.img temp/

J'ai vu également que Russell Coker a écrit un billet intitulé A support guide [for|to] Xen avec un résumé des principales commandes utiles pour Xen.

Au fait, je fais tourner un Windows 32 bits sur ma Debian en 64 bits.

copies d'écrans
Quelques screenshots pour le plaisir

PS : je suis depuis peu syndiqué sur le planète des utilisateurs francophones de Debian, planète libre et peut-être même planète APRIL alors :

bonjour à vous :-)
merci à Raphaël Hertzog, Sébastien Bilbeau et... l'APRIL
je vous invite à venir visiter mon blog
et à y laisser des commentaires si nécessaire...

PS2 : dès vendredi 1er octobre, une nouvelle taxe^[4] "copie privée" arrive sur les disques durs externes et les clés USB, alors si vous aviez un achat en tête, précipitez-vous !

Notes

[1] la mienne, c'est d'espérer pouvoir enfin rejouer à SimCity 4 Rush Hour que malheureusement je n'arrive pas à faire tourner avec Wine

[2] à vrai dire n'importe quelle distribution est valable bien évidemment mais je me base sur celle-ci

[3] en fait n'importe quel OS non modifié comme par exemple OpenBSD ou NetBSD (cf)

[4] qui a dit encore une ? qu'il se dénonce !

Flash sous Debian 64 bits

er:k — Tue, 11 Sep 2007 22:16:00 +0200

Depuis que j'ai un nouveau PC qui tourne sous 64 bits, mon gros problème était d'arriver à utiliser Flash sous Mozilla et Firefox. En effet, Flash est une technologie propriétaire^[1] et Adobe ne propose pas de version 64 bits. Plusieurs solutions existent néanmoins pour réussir à le faire mais elle sont toutes assez compliquées comme avoir un chroot 32 bits pour faire tourner les applications 32 bits^[2]. Heureusement, depuis peu existe un utilitaire appelé nspluginwrapper permettant d'utiliser des plugins sur une plateforme pour laquelle ils ne sont pas conçus, comme par exemple des plugins 32 bits sur une plateforme 64 bits qui est ce qui nous intéresse.

J'ai commencé par suivre une doc Ubuntu qui m'a permis d'avoir Flash sous Mozilla Seamonkey/Iceape mais malheureusement ça ne marchait pas pour Firefox/Iceweasel.

Heureusement cet utilitaire est arrivé dans Debian testing, et, comme depuis peu j'ai un pied dans testing/lenny^[3] j'ai alors pu l'installer tout simplement avec

# aptitude install nspluginwrapper

et là, magie ! Iceape et Iceweasel supportent le Flash... :)

update : j'ai oublié de vous dire pourquoi Flash ça pue

Notes

[1] vive les logiciels libres !

[2] cf http://debian-administration.org pour des articles traitant du problème

[3] principalement pour avoir une version de Digikam supérieure à 0.9.2 qui gère les fichiers RAW

script OpenBSD pour mise à jour DNS dynamique chez l'APINC

er:k — Thu, 06 Sep 2007 20:17:00 +0200

Je me suis enfin intéressé à la possibilité de créer des zones DNS dynamiques sur mes domaines DNS hébergés sur l'APINC, et ai créé un script shell qui marche sous OpenBSD. Le seul prérequis : avoir curl^[1]. Vous copiez ce script, remplissez les variables et le mettez dans votre cron pour qu'il s'exécute régulièrement.

#!/bin/sh

## variables
# inserer la liste des id APINC de vos zones DNS dynamiques
ids="xxxx_xxxxx xxxx_xxxxx"
# le nom de votre interface connectée à internet
interface=fxp0

export old_ip=`cat /tmp/my_ip`
export ip=`ifconfig |grep -A1 $interface|grep "inet "|cut -d " " -f 2`

if [ "$old_ip" != "$ip" ]; then
echo "changement d'ip"
echo "$ip" > /tmp/my_ip

for id in $ids
do
curl http://www.apinc.org/board/dns/dyn.php?id=$id\&ip=$ip
done
fi

[inspiré de]

update j'ai mis à jour le script pour gérer plusieurs zones dynamiques

Notes

[1] cf gestion des packages

ssh : supprimer une entrée du fichier known_hosts

er:k — Thu, 30 Aug 2007 23:46:00 +0200

pour ne pas rechercher sans fin cette astuce quand j'en ai besoin...

Sous Debian, quand on se connecte à un serveur ssh, avec les options par défaut, il y a une vérification de la signature de la clé du serveur. Ces signatures sont enregistrés dans le fichier ~/.ssh/known_hosts et lorsqu'on se connecte à un serveur auquel on s'est déjà connecté, le client vérifie si la clé du serveur n'a pas changé, cela afin d'éviter des problèmes de sécurité (connexion à un serveur usurpateur).
Le problème se pose lorsqu'on sait que la clé a changé, par exemple si c'est un serveur qu'on gère et qu'on vient de le réinstaller, et que le client ssh n'arrête pas de se plaindre que la clé est mauvaise et ne veut à aucun prix s'y connecter. Dans ce cas, il faut éditer le fichier et enlever l'entrée correspondante qui pose problème... hum... malheureusement, maintenant c'est difficile à faire le fichier étant hashé. La commande magique c'est donc

ssh-keygen -R <nom_du serveur_SSH>

[vu sur linuxfr]

le son sur la M2N

er:k — Sat, 28 Jul 2007 19:25:00 +0200

Je continue ma bataille pour tout faire marcher sur ma carte mère ASUStek M2N, et j'aborde maintenant le son. Sur Debian Etch par défaut, avec le noyau 2.6.18-adm64 (qu'il soit Xen ou pas) celui-ci ne marche pas, le driver ne semblant pas se charger correctement. Si vous faites un

# alsaconf

il ne vous détecte aucune carte son.

Il nous faut récupérer les drivers ALSA plus récents que ceux disponibles sur Etch.

Tout d'abord on désinstalle/purge^[1] tous les paquets alsa déjà installés^[2] Ensuite on installe les paquets qui nous seront nécessaires

# aptitude install alsa-utils alsa-base build-essential linux-headers-`uname -r`

On récupère les derniers drivers

# wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.14.tar.bz2

Puis on les compile et installe

# tar xvjf alsa-driver-1.0.14.tar.bz2
# ./configure --with-oss=yes --with-cards=hda-intel 
# make
# make install

On met à jour la liste des modules

# update-modules

Et enfin on détecte la carte son

# alsaconf

[vu sur]

On peut ensuite vérifier que tout fonctionne bien en utilisant par exemple les commandes indiquées sur le forum Trucs & Astuces de debian-fr.org ici.

oups, j'ai oublié d'indiquer l'essentiel : les identifiants de ma carte son

# lspci |grep -i audio
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) 
# for i in `lspci | grep [aA]udio | sed "s/ .*$//"`; do echo `lspci -n | grep $i` ; done
00:05.0 0403: 10de:03f0 (rev a2)

Notes

[1] # aptitude purge <paquet>

[2] on les trouve avec dpkg -l | grep alsa

Xen sur une ASUStek M2N

er:k — Sat, 28 Jul 2007 19:14:00 +0200

Je suis actuellement en phase "installation système" sur mon nouveau pc construit autour d'une carte mère ASUStek M2N basée sur un chipset nVidia nForce 430. Malheureusement, Xen n'a pas marché direct, et, m'étant un peu arraché les cheveux pour le faire fonctionner, je poste ici les informations importantes contenues dans le fichier /boot/grub/menu.lst^[1] afin de faire fonctionner le kernel 2.6.18-4-xen-amd64 :

title Xen 3.0.3-1-amd64 / Debian GNU/Linux, kernel 2.6.18-4-xen-amd64
root (hd0,0)
kernel /xen-3.0.3-1-amd64.gz noapic
module /vmlinuz-2.6.18-4-xen-amd64 root=/dev/mapper/vg--root-lv--root ro acpi=off noapic nolapic console=tty0
module /initrd.img-2.6.18-4-xen-amd64
savedefault

Notes

[1] les parties importantes sont les mentions 'noapic', 'acpi=off', 'nolapic'

faire du NAT avec Xen

er:k — Thu, 12 Jul 2007 13:35:00 +0200

Si vous ne disposez que d'une adresse publique et que vous voulez héberger plusieurs serveurs virtuels sous Xen, vous êtes obligé de passer par du NAT et dans ce cas voici comment configurer votre hôte dom0 Xen pour que ça marche.

Tout d'abord il faut modifier le fichier /etc/xen/xend-config.sxp pour y indiquer

(network-script network-nat)
(vif-script vif-nat)

Ensuite, pour Debian, un simple script ajouté au répertoire /etc/network/if-up.d^[1] et nommé iptables^[2] par exemple, fournit les règles pour le pare-feu iptables pour effectuer la translation d'adresse :

#!/bin/sh

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

Si ensuite vous voulez faire de la redirection de ports (ou port forwarding) il faut alors rajouter à ce fichier une règle du genre

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.3.2:80

en spécifiant correctement les ports et adresses qui correspondent à votre configuration.

Bien évidemment, ce morceau de script pour configurer le pare-feu ne suffit pas pour assurer la sécurité de vos machines Xen (dom0 et domU)

Notes

[1] le fait de placer ce fichier dans ce répertoire permet qu'il soit lancé à chaque fois que le réseau est lancé

[2] n'oubliez pas de le rendre exécutable avec un chmod u+x iptables

enregistrer vos sessions console avec script et scriptreplay

er:k — Wed, 11 Apr 2007 16:23:00 +0200

Il y a quelques semaines, Uwe Hermann nous expliquait comment enregistrer (et rejouer) une session console avec script et scriptreplay, et je pensais en parler ici... et puis j'ai oublié.

Heureusement, je viens de tomber sur la traduction en français de ce billet et cette fois-ci, je n'attends pas et j'en parle aussitôt ! ;-)

En effet, ce truc est assez énorme, puisqu'il permet non seulement d'enregistrer sa session console mais également de la rejouer, et ça marche ^[1] ! Vraiment impressionnant de revoir par exemple l'édition de fichiers avec vi se rejouer devant tes yeux...

Notes

[1] assez bien... il me semble que j'avais testé aussitôt et qu'à un moment, ça ne ressemblait plus à rien, mais c'est à vérifier !

patcher OpenBSD

er:k — Sun, 05 Nov 2006 19:04:27 +0000

À la suite de ce billet, voyons maintenant comment patcher notre serveur OpenBSD de façon plus simple, en procédant patch par patch, une fois qu'on a récupéré les sources complètes.

Sur la page d'errata de notre version (3.9 en l'occurence), on trouve les patchs par alerte de sécurité.

Prenons comme l'exemple, la dernière concernant OpenSSH, datée du 12 octobre^[1].

On récupère le patch concerné par exemple dans /tmp

# cd /tmp;
# ftp ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.9/common/015_ssh.patch

on lit l'entête du fichier pour connaître les instructions de déploiement du patch, et on les suit

# more /tmp/015_ssh.patch

on applique le patch

# cd /usr/src
# patch -p0 < /tmp/015_ssh.patch

on recompile et on installe

# cd usr.bin/ssh
# make obj
# make cleandir
# make
# make install

et, même si ce n'est pas indiqué, on arrête et redémarre le service ssh

# ps ax | grep sshd
 <pid> ??  Is      0:00.07 /usr/sbin/sshd
# kill <pid>; /usr/sbin/sshd

Notes

[1] tiens... anniversaire de la découverte de l'Amérique par Christophe Colomb en 1492 (cf Wikipedia)

Xen : problème d'allocation de mémoire pour domU

er:k — Wed, 25 Oct 2006 20:13:14 +0000

Si en lançant une machine virtuelle domU, vous vous retrouvez avec un message du genre

Error: I need 129 MiB, but dom0_min_mem is 196 and shrinking to 196 MiB would leave only 41 MiB free.

alors il faut aller éditer le fichier /etc/xen/xend-config.sxp, et modifiez la ligne avec dom0_mim_mem pour refleter la quantité minimum de mémoire que vous voulez pour votre dom0

(dom0-min-mem 128)

Hercules Webcam Deluxe sous Debian

er:k — Wed, 04 Oct 2006 09:46:51 +0000

Voici la procédure pour faire tourner cette webcam. Tout d'abord, il faut récupérer les sources du driver, celles disponibles sous Debian^[1] ne semblant pas marcher. Le projet original OV51X est ici, il en existe une version modifiée offrant la compression jpeg là. On va utiliser ces derniers.

On installe les entêtes du noyau que l'on utilise

# apt-get install linux-headers-`uname -r`

On récupère les sources du driver, les compile et les installe (en tant que root)

$ wget http://www.rastageeks.org/downloads/ov51x-jpeg/ov51x-jpeg-0.5.4.tar.gz
$ tar xvzf ov51x-jpeg-0.5.4.tar.gz
$ cd ov51x-jpeg-0.5.4/
$ make
# make install

Ensuite en root

# update-modules
# depmod
# insmod ov51x
# insmod ov519_decomp

Il suffit ensuite d'ajouter les utilisateurs susceptibles d'utiliser la webcam au groupe video

# adduser username video

Et si on veut charger automatiquement les modules au démarrage du système, on édite /etc/modules pour ajouter les deux lignes

ov51x
ov519_decomp

Voilà, vous pouvez la tester avec xawtv, camorama, camE ou encore motion pour faire de la vidéo-surveillance...

Infos obtenues sur cette page et sur le wiki Ubuntu fr

Notes

[1] et permettant d'utiliser la commande module-assistant pour les compiler

mettre à jour OpenBSD

er:k — Sun, 17 Sep 2006 00:09:58 +0000

À chaque fois que se pose cette question^[1], je me retrouve à parcourir la FAQ et autres pages de manuel avant d'être certain de la marche à suivre, voici donc une procédure qui marche^[2] :

les sources d'OpenBSD

# export CVSROOT=anoncvs@anoncvs2.de.openbsd.org:/cvs

on spécifie le serveur AnonCVS à utiliser^[3]

# cd /usr; cvs checkout -P -rOPENBSD_3_9 src

on récupère les sources de la branche OpenBSD 3.9 (version -stable) après vérification de l'empreinte RSA

le noyau

# cd /usr/src/sys/arch/i386/conf
# /usr/sbin/config GENERIC
# cd /usr/src/sys/arch/i386/compile/GENERIC
# make clean && make depend && make

compilation

# cp /bsd /bsd.old

sauvegarde de l'actuel noyau

# cp bsd /bsd

installation du nouveau

# reboot

les librairies

# rm -rf /usr/obj/*

on efface les vieux fichiers objets

# cd /usr/src
# make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
# cd /usr/src
# make build

Notes

[1] souvent parce que je suis allé voir la page errata

[2] mais ce n'est pas la plus légère... à compléter donc

[3] pas de français, alors un miroir allemand

xtermcontrol : pour changer dynamiquement les propriétés de votre terminal

er:k — Fri, 21 Jul 2006 14:28:44 +0000

Pour retrouver, et surtout différencier, facilement les nombreux terminaux que j'ouvre (que ce soit pour root, pour faire du ssh), je mets des couleurs et des titres différents.
Je me suis habitué à avoir :

texte blanc sur fond noir pour mon utilisateur;
noir sur blanc pour root;
et vert sur noir pour du ssh

Quand je suis sous gnome, j'utilise gnome-terminal qui permet d'établir des profils pour spécifier les couleurs, donc c'est ok.
Par contre, au travail, sur ma machine Xen (sur laquelle je fais tourner une Debian sarge qui me sert d'environnement de travail) j'utilise fluxbox et xterm et j'ai donc créé des raccourcis sur mon bureau (merci idesk) spécialement pour un terminal normal, un terminal root et un terminal ssh (via les options -fg couleur et -bg couleur de xterm). Malheureusement, de temps en temps, devant la prolifération de ces xterm, j'en utilise un existant pour passer root ou pour me connecter en ssh... et là ma stratégie de couleurs se retrouve mise à mal... avec le risque de faire de grosses conneries...
C'est là qu'intervient xtermcontrol qui permet dynamiquement de modifier simplement les propriétés d'un terminal en cours... et c'est vraiment cool.

ps : Tiens, je viens de tomber (ou retomber) sur la page de Multi Gnome Terminal et j'y vois deux-trois fonctionnalités qui peuvent être très intéressantes comme la possibilité de splitter horizontalement ou verticalement le terminal, la pseudo-transparence (comme aterm et Eterm), etc. Mais par contre, on dirait qu'il n'y a plus de développement...

Cowon iAudio X5L 30Go

er:k — Mon, 17 Jul 2006 19:59:00 +0000

Bon, cette fois-ci, ça y est, j'ai craqué (et claqué :) et je me suis acheté un Cowon iAudio X5L version 30Go...

Alors, pourquoi ce balladeur mp3 d'une marque que personne ne connait ? Tout d'abord, parce que c'est le meilleur baladeur mp3 existant... (il a par exemple été élu baladeur de l'année 2005 sur generationmp3.com) et :

il lit non seulement les mp3, mais également les Ogg Vorbis et FLAC (format sans perte, idéal pour ripper vos CD);
il possède un tuner FM, et peut enregistrer la radio;
il fait USB On-The-Go ce qui peut-être très pratique quand on a un appareil photo numérique;
il peut lire des fichiers image (malheureusement pas en écoutant de la musique... ce qui est con !);
il a une autonomie de 35h annoncés pour le modèle L, mais bien entendu c'est l'autonomie calculée pour des fichiers mp3 et elle descend si on lit des fichiers ogg ou flac;
il a un micro et peut donc faire office de dictaphone;
il a une entrée Line In permettant d'enregistrer depuis une source externe;
il fait horloge et réveil... ce qui peut être pratique :);
il a, selon les dires, un super son (pour l'instant mes tests d'écoute de GYBE! en flac me laisse à penser que c'est vrai, mais je n'ai pas d'autres baladeurs pour comparer...);
etc, etc, etc...
et il existe même un firmware alternatif open source, c'est Rockbox, projet à l'origine dédié aux Archos et qui ensuite c'est diversifié (iRiver, iPod...), et ça c'est le must :)
et il est UMS, c'est-à-dire qu'il ne nécessite pas un logiciel spécifique pour pouvoir transférer de la musique dessus, il est reconnu par tout système (et donc Linux) comme un disque dur amovible...

Tout ça pour dire que, quitte à dépenser de l'argent, autant le dépenser dans un produit qui fait plus, beaucoup plus que la concurrence... (par ex. iPod). De toutes façons, pratiquement aucune autre marque ne lit les ogg ou flac...

Si vous êtes convaincu, allez jeter un coup d'oeil sur le site allemand mp3-player.de qui vous permettra de l'acquérir à prix corrects^[1] (et sans risque de frais de douane puisque c'est l'Union Européenne).

Plus d'infos sur wikipedia, sur le site de Cowon ou sur cette page dont les remarques sont pertinentes.

Pour info, si ça vous intéresse de convertir des vidéos pour les mater sur votre iAudio X5 (j'ai par exemple converti Le Grand Détournement... indispensable !), voici la commande magique avec mplayer/mencoder :

mencoder video_source.avi -o video_finale.avi -ovc lavc -oac lavc -lavcopts acodec=mp3:abitrate=96 -ofps 13 -vf scale=160:108

Notes

[1] c'est-à-dire un peu moins cher qu'en France, où il est pratiquement introuvable d'ailleurs...

règles PF OpenBSD pour le Freeplayer

er:k — Mon, 22 May 2006 19:46:47 +0000

Si vous êtes vous aussi un abonné Free, vous connaissez probablement déjà le Freeplayer^[1], mais savez-vous configurer votre firewall OpenBSD (placé bien évidemment derrière la Freebox) pour laisser passer le flux nécessaire... hum, peut-être pas, alors voici les règles de base nécessaires :

on définit d'abord quelques macros dans /etc/pf.conf

net_if = "xl0"         # nom de l'interface connectée à internet via la Freebox
lan_if = "xl1"         # nom de l'interface connectée à votre LAN

free_net_host = 212.27.38.253   # c'est l'adresse de mafreebox.freebox.fr
free_lan_host = xxx.xxx.xxx.xxx # l'adresse IP du poste lançant VLC sur le réseau local
free_dst_tcp_ports = "{ 8080 }"
free_dst_udp_ports = "{ 1234 }"

on ajoute une redirection de ports

rdr on $net_if proto tcp from $free_net_host to ($net_if) port $free_dst_tcp_ports -> $free_lan_host

puis les règles de filtrage

pass in quick on $net_if proto tcp from $free_net_host to $free_lan_host port $free_dst_tcp_ports flags S/SA keep state
pass out quick on $lan_if proto tcp from $free_net_host to $free_lan_host port $free_dst_tcp_ports flags S/SA keep state

Ces règles sont bien évidemment à adapter à votre configuration, et à votre politique de sécurité^[2], mais dans l'idée c'est ça !

Notes

[1] la plus grande source d'informations se trouve sur freeplayer.org

[2] par ex. vous pouvez avoir un blocage des flux sortants, et ils vous faudra donc des règles supplémentaires pour laisser passer les flux UDP vers le port 1234