ZenTech - debian

Salut le petit soldat en plastique

hr — Mon, 03 Nov 2008 12:45:00 +0100

On dit au revoir à la sarge qui est passée la semaine dernière en archive.
Pour trouver les paquets de sarge, il faut donc maintenant se tourner vers : {http,ftp}://archive.debian.org/. Le miroir oleane a également été mis à jour, l'accès se fait par : {http|ftp}://ftp2.fr.debian.org/pub/debian-archive/.
Il ne reste donc plus que etch en stable, en attendant lenny qui devrait bientôt passer de testing en stable.

Vient du latin subvertere

hr — Wed, 22 Oct 2008 17:28:00 +0200

Lorsqu'on souhaite fournir un projet à la communauté, on doit se poser la question du gestionnaire de version. Il me semble indispensable d'utiliser un tel outil si d'autres personnes viennent à participer au projet. Je vous présente ici une solution rapide de serveur subversion avec accès svnserve sur une debian. Oui, ce post n'est pas drôle, on ne rigole pas avec les VCS, merde !

Il faut bien évidemment commencer par installer les outils nécessaire à l'utilisation de subversion.

# apt-get install subversion

J'ai choisis de créer un utilisateur système dédié aux opérations svn. Cet utilisateur est très subtilement appelé 'svn' et la racine des données subversion se trouve dans /var/lib/svn :

# addgroup --system svn
# adduser --system --disabled-login --ingroup svn --no-create-home --home /var/lib/svn --gecos "subversion" --shell /bin/false svn
# mkdir /var/lib/svn
# chown svn:svn /var/lib/svn
# chmod 755 /var/lib/svn

Le serveur d'accès est svnserve. Attention, c'est le choix le plus simple à mettre en place mais il souffre de sérieux handicaps par rapport aux alternatives. Je préfère limiter l'accès du serveur svn à un répertoire donné pour éviter d'éventuelles fuites.

$ grep svn /etc/services 
svn             3690/tcp        subversion      # Subversion protocol
svn             3690/udp        subversion
$ grep svn /etc/inetd.conf 
svn stream tcp nowait svn /usr/bin/svnserve svnserve -i -r /var/lib/svn
# /etc/init.d/openbsd-inetd restart

Maintenant que nous avons un serveur d'accès, il faut créer des données, c'est un peu le jeu ma pauv' Lucette. Un dépot pour un projet fictif appelé 'project' est un début.

# svnadmin create /var/lib/svn/project
# chown -R svn:svn /var/lib/svn/project

Dans le cas d'un dépôt ayant besoin d'un accès authentifié, il y a deux fichiers à modifier :
/var/lib/svn/project/conf/conf/svnserve.conf :

[general] 
password-db = passwd
realm = project

/var/lib/svn/project/conf/conf/passwd :

[users]
user = password

L'environnement est maintenant complètement disponible, on peut essayer de récupérer les sources du projet (vide) et y créer puis publier un fichier.

$ svn co svn://localhost/project
$ cd project
$ touch foo
$ svn add foo
$ svn ci -m 'test' foo
$ svn list
foo

Si tout se passe bien c'est gagné, sinon, il est utile de se pencher sur l'excellent livre O'Reilly traitant du sujet.

Attention, votre configuration svn est minimale et conviendra pour un petit serveur personnel. Dans le cas d'un projet plus important de gestion de code il faudra probablement se tourner vers un accès webdav grâce à apache (lighttpd ne le supporte pas encore !!) et un système d'authentification plus performant.

Bruce Schneier knows Alice and Bob's shared secret

hr — Mon, 13 Oct 2008 14:50:00 +0200

Comment faire lorsqu'on souhaite se constituer un petit espace très personnel sur une machine linux. Que faire quand on souhaite que cet espace soit conservé à l'abris des yeux indiscrets. Je vous propose une petite recette simple et efficace. Il suffit d'utiliser des ingrédients que vous trouverez dans votre cuisine !!

L'environnement système est une debian etch installée en 64bits sur une dedibox. Je vais utiliser le chiffrement de bloc avec LUKS utilisant dm-crypt. Nous ne chiffrerons pas la partition racine du système mais bien une partition de données.

Il faut tout d'abord vérifier qu'on a les outils nécessaires au chiffrement de partition.

# apt-get install cryptsetup dmsetup hashalot
[...]

Maintenant que les outils de base sont installés, on vérifie leur compatibilité avec l'utilisation qu'on souhaite en faire.

# cryptsetup --help
cryptsetup-luks 1.0.5
[...]
# dmsetup targets
zero             v1.0.0
mirror           v1.0.20
snapshot-origin  v1.6.0
snapshot         v1.6.0
crypt            v1.5.0
striped          v1.1.0
linear           v1.0.2
error            v1.0.1

# cat /proc/crypto | grep name
name         : aes
name         : sha256
name         : sha224
name         : sha1
name         : md5

la commande cryptsetup installée supporte bien LUKS et le noyau est capable de supporter le chiffrement.

Pour les architectures supportant le 64bit.

# modprobe aes-x86_64
# cat /proc/crypto
name         : aes
driver       : aes-asm
module       : aes_x86_64
priority     : 200
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
[...]

Le module peut-être éventuellement ajouté au fichier /etc/modules.

Je dois maintenant créer la partition qui va être chiffrée et la déclarer au système grâce à partprobe.

# cfdisk /dev/sda
[...]
# apt-get install parted
[...]
# partprobe /dev/sda

Pour chiffrer une partition avec LUKS, il faut la "formater" avec cryptsetup et ensuite la déclarer au système "device mapper". Il est conseillé d'utiliser une phrase de mot de passe complexe.

# cryptsetup luksFormat /dev/sda8

WARNING!
========
This will overwrite data on /dev/sda8 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
# cryptsetup luksOpen /dev/sda8 data
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.
# ls /dev/mapper/
control  data

C'est gagné, la partition est maintenant accessible grâce au chemin /dev/mapper/data.

Il faut formater la partition, ici j'utilise ext3.

# mkfs.ext3 -m 0 /dev/mapper/data

La partition peut maintenant être utilisée par le système.

Pour assurer le montage de la partition au démarrage, il faut la déclarer dans le fichier /etc/crypttab. Cette déclaration permet de faire l'ouverture LUKS et la déclaration à "dev mapper" en une opération. Ensuite /etc/fstab pourra prendre le relais.

# cat /etc/crypttab
# <target name> <source device>         <key file>      <options>
data    /dev/sda8       none            luks,timeout=1

Ps: Le titre vient des "Bruce Schneier facts".
Ps2: Le formatage de la partition peut également se faire avec un version plus longue de la commande cryptsetup :

# cryptsetup --verify-passphrase --verbose --hash=sha256 --cipher=aes-cbc-essiv:sha256 --key-size=256 luksFormat /dev/sda8
[...]

Et si je voulais devenir cuisinier moi aussi ?

hr — Mon, 13 Oct 2008 14:37:00 +0200

Si l'envie vous prenait de cuisiner sur votre système Debian, il y a un package à installer : build-essential. Ce paquet va, par dépendance, installer les outils principalement utilisés pour la compilation de sources comme un compilateur ou les librairies c standard.

Mais mon surnom c'est plus simple à écrire

hr — Wed, 08 Oct 2008 15:49:00 +0200

Si vous faites comme moi partie des gens qui ont un nick/login vraiment court (moins de quatre lettres en fait), vous avez été victime, vous aussi, des contraintes de la dedibox. En effet, le compte utilisateur doit faire entre quatre et vingt caractères. Mon login en fait deux ... maiiiiiiiis la situation n'est pas irrémédiable.

C'est finalement assez simple, mais globalement dangereux. Si une déconnexion survenait au cours de cette manipulation, le système pourrait devenir inaccessible pour ce compte utilisateur. J'ai l'habitude de ne pas donner d'accès ssh à mon utilisateur root, donc je m'autodétruis dans un nuage de fumée bleue.

On commence par passer root, ensuite il faut modifier les fichiers /etc/shadow, /etc/passwd et /etc/group. Dans les deux premiers fichiers, il suffit de modifier le login à changer en début de ligne. Il doit se trouver une fois dans chaque fichier. Par exemple :

# cat /etc/shadow
[...]
hrhr:$1$foobar$blihblahbloh:13923:0:99999:7:::
[...]
# cat /etc/passwd
[...]
hrhr:x:1000:1000:hrhr,,,:/home/hrhr:/bin/bash
[...]

Le fichier /etc/group contient aussi un certain nombre de références à ce login.

# grep hrhr /etc/group
dialout:x:20:hrhr
cdrom:x:24:hrhr
floppy:x:25:hrhr
audio:x:29:hrhr
video:x:44:hrhr
plugdev:x:46:hrhr
hrhr:x:1000:

Ensuite on s'occupe de déplacer le répertoire home de l'utilisateur. On commence par modifier le chemin du répertoire home dans /etc/passwd. Ensuite on déplace le répertoire pour refléter ces changements.

# mv /home/oldnick /home/newnick

Et voualaaaaaaaaaa. A la prochaine connexion, le nouvel utilisateur peut être utilisé.

Update: Personnellement, je fais les substitutions à grands coups de :%s/hrhr/hr/gc dans vim, ce qui me permet de faire plusieurs substitutions par ligne sur tout le fichier. Chaque substitution doit être confirmée.
On pourrait également utiliser sed :

sed -i.bak 's/hrhr/hr/g' /etc/group

All your poll are belong to us

hr — Wed, 05 Mar 2008 18:36:00 +0100

J'ai aujourd'hui besoin de tenir à l'oeil certaines valeurs sur un serveur, le plus simple semble d'utiliser net-snmp et mrtg. Ce serveur SNMP peut être très facilement étendu, mais est assez mal documenté à mon goût. Je vais donc faire un petit tour des méthodes simples d'utilisation de net-snmp pour récupérer des données non communes.

Les versions de net-snmp et mrtg installées sur ma debian etch sont snmpd (5.2.3-7etch2) et mrtg (2.14.7-2). Je suppose que vous êtes à l'aise avec le concept de SNMP et que net-snmp et mrtg sont configurés.
En faisant le tour du site web, du fichier de configuration par défaut et de goo^Winternet, j'ai pû lister les méthodes suivantes :

exec
extend
pass

Je passe sur l'utilisation de subagent qui est plus complexe.
Le script que je vais utiliser tient en 2 lignes et se trouve dans /tmp/test_snmp :

#!/bin/sh
echo 42

Pour information, le fichier /usr/share/snmp/mibs/UCD-SNMP-MIB.txt indique que l'OID 2021 correspond à ucdavis et se trouve après le noeud enterprise (ce qui donne .1.3.6.1.4.1.2021). Cet OID sera utilisé pour ajouter de nouvelles données en test, en réalité il faudrait utiliser un OID correspondant à l'environnement d'utilisation (un OID d'entreprise délivré par IANA par exemple).

`exec`

[...]
exec test1 /tmp/test_snmp
exec .1.3.6.1.4.1.2021.60 test2 /tmp/test_snmp
[...]

Après redémarrage, on vérifie que les données sont bien accessibles en SNMP :

$ snmpwalk -v 1 -c private localhost .1.3.6.1.4.1.2021
[...]
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: test_snmp
UCD-SNMP-MIB::extCommand.1 = STRING: /tmp/test_snmp
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: 42
UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:
[...]
UCD-SNMP-MIB::ucdavis.60.1.1 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.2.1 = STRING: "test_snmp"
UCD-SNMP-MIB::ucdavis.60.3.1 = STRING: "/tmp/test_snmp"
UCD-SNMP-MIB::ucdavis.60.100.1 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.60.101.1 = STRING: "42"
UCD-SNMP-MIB::ucdavis.60.102.1 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.60.103.1 = ""
[...]

La première forme est plus explicite et la deuxième forme est mieux maitrisée puisqu'on choisit l'OID destination.

Le problème est que le serveur snmp n'est pas très satisfait de l'utilisation de exec :

[...]
Mar  4 17:28:45 snmp.priv snmpd[8678]: /etc/snmp/snmpd.conf: line 363: Error: Warning: relocatable 'exec' format will change in a future release - See 'NET-SNMP-EXTEND-MIB' for an alternative
Mar  4 17:28:45 snmp.priv snmpd[8678]: net-snmp: 2 error(s) in config file(s)

`extend`

L'uilisation de extend se fait via une mib spéciale (NET-SNMP-EXTEND-MIB.txt), sur une debian elle se trouve dans /usr/share/snmp/mibs. L'utilisation de cette option permet de créer automatiquement des entrées sous l'OID .1.3.6.1.4.1.8072 par défaut.

extend test_snmp /tmp/test_snmp
extend .1.3.6.1.4.1.2021.60 test_snmp /tmp/test_snmp

Les résultats se trouvent aux 2 endroits suivants :

$ snmpwalk -v 1 -c private localhost NET-SNMP-EXTEND-MIB::nsExtendObjects
[...]
NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 = INTEGER: 3
NET-SNMP-EXTEND-MIB::nsExtendCommand."test_snmp" = STRING: /tmp/test_snmp
NET-SNMP-EXTEND-MIB::nsExtendArgs."test_snmp" = STRING: 
NET-SNMP-EXTEND-MIB::nsExtendInput."test_snmp" = STRING: 
NET-SNMP-EXTEND-MIB::nsExtendCacheTime."test_snmp" = INTEGER: 5
NET-SNMP-EXTEND-MIB::nsExtendExecType."test_snmp" = INTEGER: exec(1)
NET-SNMP-EXTEND-MIB::nsExtendRunType."test_snmp" = INTEGER: run-on-read(1)
NET-SNMP-EXTEND-MIB::nsExtendStorage."test_snmp" = INTEGER: permanent(4)
NET-SNMP-EXTEND-MIB::nsExtendStatus."test_snmp" = INTEGER: active(1)
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."test_snmp" = STRING: 42
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."test_snmp" = STRING: 42
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."test_snmp" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."test_snmp" = INTEGER: 0
NET-SNMP-EXTEND-MIB::nsExtendOutLine."test_snmp".1 = STRING: 42
[...]
$ snmpwalk -v 1 -c private localhost .1.3.6.1.4.1.2021.60
UCD-SNMP-MIB::ucdavis.60.1.0 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.2.1.2.9.116.101.115.116.95.115.110.109.112 = STRING: "/tmp/test_snmp"
UCD-SNMP-MIB::ucdavis.60.2.1.3.9.116.101.115.116.95.115.110.109.112 = ""
UCD-SNMP-MIB::ucdavis.60.2.1.4.9.116.101.115.116.95.115.110.109.112 = ""
UCD-SNMP-MIB::ucdavis.60.2.1.5.9.116.101.115.116.95.115.110.109.112 = INTEGER: 5
UCD-SNMP-MIB::ucdavis.60.2.1.6.9.116.101.115.116.95.115.110.109.112 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.2.1.7.9.116.101.115.116.95.115.110.109.112 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.2.1.20.9.116.101.115.116.95.115.110.109.112 = INTEGER: 4
UCD-SNMP-MIB::ucdavis.60.2.1.21.9.116.101.115.116.95.115.110.109.112 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.3.1.1.9.116.101.115.116.95.115.110.109.112 = STRING: "42"
UCD-SNMP-MIB::ucdavis.60.3.1.2.9.116.101.115.116.95.115.110.109.112 = STRING: "42"
UCD-SNMP-MIB::ucdavis.60.3.1.3.9.116.101.115.116.95.115.110.109.112 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.60.3.1.4.9.116.101.115.116.95.115.110.109.112 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.60.4.1.2.9.116.101.115.116.95.115.110.109.112.1 = STRING: "42"

La deuxième forme revient à peu de choses près au résultat de la commande exec avec utilisation d'un chemin.
La première forme permet d'obtenir beaucoup d'informations intéressantes comme le nombre d'éléments qui étendent la mib (NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 on remarque donc que j'ai nettoyé la réponse puisqu'il annonce 3 scripts d'extension). On peut récupérer la réponse complète NET-SNMP-EXTEND-MIB::nsExtendOutputFull."test_snmp" ou les lignes une à une NET-SNMP-EXTEND-MIB::nsExtendOutLine."test_snmp".x.

Le point faible de cette méthode subsiste dans le type de donnée renvoyé, notre script envoit un chiffre et il est considéré comme une chaine de caractère. De la même façon, si on veut générer un compteur sur 32 ou 64 bits, c'est impossible avec cette méthode.

`pass`

L'utilisation de cette option de configuration oblige à choisir un OID en dessous duquel le script est entièrement maitre. Il faut donc avoir recours à un script plus complexe qui permet de donner le type de valeur et la valeur pour un OID donné. Le script passtest donne une bonne idée d'un script basique permettant cette intégration. Je ne rentrerai pas dans les détails.

pass .1.3.6.1.4.1.2021.60 /tmp/test_snmp

Dans l'idée, le script est appelé avec les arguments <reqtype> <miboid>. Avec reqtype qui correspond à -g pour une requête GET, -n pour un GETNEXT et un -s pour un SET. le chemin OID est donné par miboid.
Dans le cas des commandes GET et GETNEXT, la réponse est constituée de 3 lignes :

l'OID de réponse;
le type de la valeur retournée, au choix dans integer, gauge, counter, timeticks, ipaddress, objectid, ou string;
la valeur.

Dans le cas de la commande SET, le script ne doit rien retourner.

Conclusion

Il faut bien en finir avec tout ce bazar, il est intéressant de jeter un coup d'oeil du côté de snmpd.conf(5) pour les détails, d'autres options de configuration comme pass_persist peuvent être utilisées. Personnellement, j'utilise la solution extend qui me semble raisonnablement simple à mettre en place et à utiliser.

Rooooooooxanne

hr — Thu, 29 Nov 2007 13:04:00 +0100

J'ai eu besoin d'installer une jolie police de caractère (font en anglois) sur une ubuntu/debian (ce sont les seules distributions que j'ai testé) récemment et je me suis rendu compte de deux choses :

C'est très simple à faire
C'est peu documenté

Donc voici la marche à suivre pour installer une police de caractère sans les droits administrateur.

Il faut, a priori, trouver un belle police à installer (à noter les "Free Fonts Of The Month" de SmashingMagazine). Après avoir téléchargé la police en question et décompressé éventuellement une archive, les fichiers .ttf sont disponible.

$ wget http://www.kottke.org/plus/type/silkscreen/download/silkscreen.tar.gz -P ~/tmp
[...]
$ tar zxvf ~/tmp/silkscreen.tar.gz -C ~/tmp/
slkscr.ttf
slkscrb.ttf
slkscre.ttf
slkscreb.ttf
readme.txt

Un fois les fichiers de police à disposition, il suffit de créer un répertoire .fonts dans son répertoire home, d'y placer les polices et rafraichir le cache de polices.

$ mkdir ~/.fonts
$ cp ~/tmp/*.ttf ~/.fonts
$ fc-cache -f -v ~/.fonts/
/home/hr/.fonts/: caching, 1 fonts, 0 dirs
/var/cache/fontconfig: not cleaning unwritable cache directory
/home/hr/.fontconfig: cleaning cache directory
fc-cache: succeeded

Et c'est parti, pas plus compliqué que ça.

Un peu d'ordre dans la maison

hr — Tue, 18 Sep 2007 19:22:00 +0200

Je viens d'installer un serveur avec plein de SATA dans le ventre, la bête a 30To de disques répartis sur 2 controleurs Areca ARC-1280ML. L'installation d'une Debian/etch se passe sans problème, noyau 2.6.18-5-686. Après avoir installé le système sur 2 disques connectés à la carte mère (contrôleur ICH5R sur pilote ata_piix), des volumes RAID5 sont créés sur les cartes Areca (pilote arcmsr). Le démarrage s'arrête sur une invite de commande initramfs, la partition racine est introuvable.

Begin: Waiting for root file system... ...
Done.
        Check root= bootarg cat /proc/cmdline
        or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/sda1 does not exist. Dropping to a shell!


Busybox v1.1.3 (Debian 1:1.1.1-4) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)

Mais qu'est-ce qu'il nous arrive madame Michu ? Tout simplement, les nouveaux volumes sont détectés par le noyau avant le disque sur lequel est installé le système. Résultat, le système n'est plus sur /dev/sda mais sur /dev/sdc. Et le plus drôle c'est qu'il est parfois sur /dev/sdb parce que les controleurs Areca mettent du temps à se déclarer.

Comment laver l'affront que nous impose ce petit impudent ? En jouant avec la partition RAM d'initialisation, j'ai nommé initramfs.

C'est extrêmement simple, on va demander à la partition de démarrage en RAM de charger les modules sata dans l'ordre qu'on souhaite. Dans notre cas, le pilote ata_piix avant arcmsr. Les outils Debian permettent de faire ça de façon très simple, il suffit d'ajouter les modules qu'on souhaite voir chargés lors du démarrage dans le fichier /etc/initramfs-tools/modules. Les modules doivent être listés, un par ligne dans l'ordre de chargement souhaité. Dans notre cas, il suffit de préciser le module qui prend en charge le disque de démarrage.

# cat /etc/initramfs-tools/modules
[...]
ata_piix

Il faut maintenant mettre à jour l'image en RAM pour propager ces modifications.

# update-initramfs -v -k 2.6.18-5-686 -t -u
Keeping /boot/initrd.img-2.6.18-5-686.dpkg-bak
update-initramfs: Generating /boot/initrd.img-2.6.18-5-686
Adding module /lib/modules/2.6.18-5-686/kernel/drivers/scsi/scsi_mod.ko
Adding module /lib/modules/2.6.18-5-686/kernel/drivers/scsi/scsi_transport_spi.ko
Adding module /lib/modules/2.6.18-5-686/kernel/drivers/scsi/aic7xxx/aic7xxx.ko
[...]
Adding binary /sbin/mdrun
Building cpio /boot/initrd.img-2.6.18-5-686 initramfs
Backup /boot/initrd.img-2.6.18-5-686.bak

Un petit redémarrage et tout est revenu en ordre. Et le plus beau, c'est que lorsque vous devrez mettre à jour votre noyau, le nouveau noyau fera automatiquement la reconstruction de l'image RAM d'initialisation.