code. grind. sleep.

Quand j'essaye de me logguer sur ma box NetBSD fraichement passé en X.org modular, j'ai ça :

orgrim@serfouette ~ $ ssh rateau 
X11 forwarding request failed on channel 0
Last login: Fri Oct 21 12:20:24 2011 from serfouette.home.orgrim.net

WTF? ça tombe en marche SSH normalement.

Et bien le souci vient de l'échange des magic cookies pour l'authentification entre serveurs X à travers SSH, c'est utilisé par le X11 forwarding et on a besoin de plusieurs choses pour ça :

• le chemin complet vers xauth sur le client
• le chemin complet vers xauth sur le serveur
• Avoir X11Forward yes sur le serveur quand on le demande sur le client (il vaut yes dans le /etc/ssh/ssh_config du client par flemme de taper -X sur la ligne de commande)

Le client est sous Linux, donc pas de soucis le chemin en dur /usr/bin/xauth dans le binaire sshd marche. Par contre pour NetBSD avec du X.org modular, il faut décommenter l'option XAuthLocation dans /etc/ssh/sshd_config et /etc/ssh/ssh_config pour donner le bon chemin vers xauth, comme indiqué en commentaire dans ces deux fichiers :

# If you use xorg from pkgsrc then uncomment the following line.
#  XAuthLocation /usr/pkg/bin/xauth

Enfin, comme le X11Forward est à no par défaut sur NetBSD, je l'ai activé. La vrai solution est de faire ça côté client en utilisant explicitement l'option -X quand on veut ouvrir des fenêtres sur le serveur.

Le pire c'est que Google ne sort rien sur le message "X11 forwarding request failed on channel 0", à part une question sans réponse sur un stackoverflow-like en Russe !

En suivant l'excellent tip de Mr GuiGui2, j'ai pu monter ma petite archi de bulk build personnelle pour fournir du package tout frais à pkgin.

J'ai donc ajouté le bloc magique suivant à mon /etc/mk.conf, qui permet de gérer la présence de commentaires dans pkgchk.conf :

# bulk build config
DEPENDS_TARGET= bulk-install
BATCH=          yes

BULK_PREREQ+=   pkgtools/lintpkgsrc
.if defined(SPECIFIC_PKGS)
PKGLIST!=               awk '$$1 !~ /^\#/ {print $$1}' ${PKGCHK_CONF}
.       for _pkg_ in ${PKGLIST}
HOST_SPECIFIC_PKGS+=    ${_pkg_}
.       endfor
.endif

Pour aller plus loin, j'ai automatisé le process au maximum pour lancer des bulk build réguliers par cron, grâce au script bulk-builder. Ce script remplace do-sandbox-build et do-sandbox-upload, il est également capable de gérer des chemins alternatifs, mettre à jour pkgsrc avant de lancer le bulk.

La procédure pour mettre ça en place est donc :

1. Ajouter le bloc montré plus haut à /etc/mk.conf et y définir PKGCHK_CONF, il s'agit du chemin vers une liste de packages au format "catetgorie/package", un par ligne, qu'on peut automatiquement créer avec pkg_chk -g.

2. Créer la sandbox :

# cd /usr/pkgsrc/mk/bulk
# sh mksandbox --without-x /usr/sandbox

3. Créer et configurer /usr/pkgsrc/mk/bulk/build.conf :

# cd /usr/pkgsrc/mk/bulk
# cp build.conf-example build.conf
# vi build.conf

4. Lancer le bulk build :

# sh bulk-builder -u -R

• -u demande de cvs up le répertoire /usr/pkgsrc avant de commencer
• -R demande de ne pas uploader le résultat (les packages)

Enfin, il suffit d'utiliser la ligne suivante pour utiliser les packages avec pkgin, dans /usr/pkg/etc/pkgin/repositories.conf :

file:///usr/pkgsrc/packages/All

Comme j'annonçais précédemment, je contribue deux machines NetBSD à la BuildFarm de PostgreSQL. La compilation ne se fait automagiquement qu'après la configuration du client (écrit en Perl). Il n'est d'ailleurs pas forcément très convi à installer, c'est pourquoi je l'ai packagé pour pkgsrc : http://pkgsrc.se/wip/pgbuildfarm.

En espérant qu'il soit ajouté à l'arbre officiel...

Voici la configuration pour lancer des builds sur NetBSD, dans /usr/pkg/etc/pgbuildfarm/build-farm.conf, en commençant par le chemin du miroir du dépôt Git :

# Modifier dans %conf
scmrepo => '/usr/pgbuildfarm/pgsql-base.git',

Le client est destiné à être lancé par cron, connu pour son environnement light, c'est pourquoi les paramètres d'environnement doivent être adaptés :

• Le make GNU s'appelle gmake chez nous
• Pas mal de programmes proviennent de pkgsrc, il faut donc que le client ait /usr/pkg/bin dans son PATH, et puisse trouver les bibliothèques issues des packages.

make => 'gmake',
aux_path => "/usr/pkg/bin",

build_env =>
{
    PATH => "/usr/pkg/bin:$ENV{PATH}",
    LD_LIBRARY_PATH => "/usr/pkg/lib",
},

config_env =>
{
    CC => 'gcc',
    PATH => "/usr/pkg/bin:$ENV{PATH}",
    LD_LIBRARY_PATH => "/usr/pkg/lib",
},

Enfin le plus important, les options du configure, la plupart nécessitent des packages supplémentaires comme python ou la libxml. Ce qui est primordial ici est d'utiliser le « template » NetBSD :

config_opts =>
[qw(
    --enable-cassert
    --enable-debug
    --enable-nls
    --enable-integer-datetimes
    --with-perl
    --with-python
    --with-tcl
    --with-krb5
    --with-includes=/usr/include/krb5:/usr/pkg/include
    --with-libraries=/usr/pkg/lib
    --with-openssl
    --with-template=netbsd
    --enable-thread-safety
)],

Pour toutes ces options, les packages suivants ont été installés :

• devel/bison
• devel/flex
• lang/python26 (et pkgtools/pkg_alternatives pour avoir le lien python)
• lang/perl5
• lang/tcl
• textproc/libxml2
• textproc/libxslt
• devel/readline

P.S. : Il n'y a que les particularités de NetBSD décrites ici, en complément du wiki de PostgreSQL.

Il y a quelques jours, il a été décidé de remplacer libungif par giflib dans pkgsrc. Pour éviter de mixer les deux et donc avoir des problèmes, les deux paquets se déclarent mutuellement en conflit. A partir de maintenant la dépendance par défaut est sur giflib, ce qui a donc fait que ma mise à jour (pkg_chk dans un pkg_comp) a tellement buté dessus que j'ai décidé qu'il serait plus simple de repartir d'un chroot pkg_comp tout neuf...

Même si j'avais oublié de retirer libungif de mon /usr/pkgsrc/pkgchk.conf au début, j'ai bien obtenu un dépôt tout neuf pour pkgin.

Et là, la magie de pkgin a opéré :

# pkgin up
processing local summary...
updating database: 100%
downloading pkg_summary.bz2:    0Bbps 100%
processing remote summary (file:///usr/pkgsrc/packages/amd64/All)...
updating database: 100%

# pkgin fug
calculating dependencies... done.
giflib-4.1.6 (to be installed) conflicts with installed package libungif-4.1.4nb1.
proceed ? [y/N] n

# pkgin srd libungif
local reverse dependency tree for libungif
        feh-1.3.4nb8
        giblib-1.2.4nb9
        python-mode-1.0nb1
        php-mode-1.4.0nb1
        mplayer-1.0rc20100913nb5
        emacs-23.2nb4
        imlib2-1.4.2nb6

# pkgin rm libungif
8 packages to delete: mplayer-1.0rc20100913nb5 php-mode-1.4.0nb1 python-mode-1.0nb1
 feh-1.3.4nb8 emacs-23.2nb4 giblib-1.2.4nb9 imlib2-1.4.2nb6 libungif-4.1.4nb1
proceed ? [y/N] y
....

# pkgin in feh emacs php-mode python-mode mplayer
...

# pkgin fug
calculating dependencies... done.

21 packages to be upgraded: epdfview-0.1.7nb10 mercurial-1.8 scmgit-base-1.7.3.5
scmgit-docs-1.7.3.5 poppler-glib-0.16.2 libgnome-2.32.0nb2 libgnomeui-2.24.4nb2
poppler-glib-0.16.2 poppler-utils-0.16.2 t1lib-5.1.2nb1 gtk2+-2.22.1nb1
tex-dvipdfm-0.13.2dnb3 curl-7.21.3 glib2-2.26.1nb2 gnutls-2.10.4 libksba-1.1.0
dialog-1.1.20110118 libidn-1.19 luatex-0.65.0nb1 web2c-2010nb6 poppler-0.16.2

21 packages to be installed: poppler-0.16.3 dialog-1.1.20110302 libidn-1.20
luatex-0.65.0nb2 web2c-2010nb7 curl-7.21.4 glib2-2.28.2 gnutls-2.10.5nb1 libksba-1.2.0
gtk2+-2.24.1 tex-dvipdfm-0.13.2dnb4 poppler-glib-0.16.3 libgnome-2.32.1
libgnomeui-2.24.5 poppler-glib-0.16.3 poppler-utils-0.16.3 t1lib-5.1.2nb2
epdfview-0.1.7nb11 mercurial-1.8.1 scmgit-base-1.7.4.1 scmgit-docs-1.7.4.1
(40M to download, 292M to install)

proceed ? [y/N] y
...

Et hop, résolution du conflit à la main, certes, mais très facilement et avec un seul outil. Sans pkgin, j'aurais du itérer à coup de pkg_info -R, pkg_delete et pkg_chk -ub... Parce pkgin ressort tout l'arbre des dépendances :

 # pkg_info -R giflib
Information for giflib-4.1.6:

Required by:
imlib2-1.4.2nb7
emacs-23.2nb5
mplayer-1.0rc20100913nb6


# pkgin srd giflib
local reverse dependency tree for giflib
        feh-1.3.4nb8
        giblib-1.2.4nb9
        python-mode-1.0nb1
        php-mode-1.4.0nb1
        mplayer-1.0rc20100913nb6
        emacs-23.2nb5
        imlib2-1.4.2nb7

pkgin est un outil de gestion de paquets binaires pour pkgsrc, le système de paquets de NetBSD. Pour pouvoir l'utiliser il faut donc des paquets binaires, sauf que les binaires ne sont officiellement disponibles que pour les releases trimestrielles de pkgsrc. Quand on suit pkgsrc-current, il faut donc compiler les paquets et fabriquer un dépôt.

La solution consiste donc à utiliser l'équipe habituelle pour compiler les paquets sans gêner le système : pkg_comp et pkg_chk. Pour le dépôt on a simplement besoin d'un serveur web pour les mettre à disposition.

Voici un petit résumé de la procédure :

1. A partir d'une machine ayant l'ensemble de ses paquets déjà installés, on met en place un chroot pkg_comp comme indiqué sur le wiki.

2. On génère la liste des paquets à construire à partir des paquets installé avec pkg_chk :

# pkg_chk -g

3. On les compile dans le chroot :

# pkg_comp build pkgtools/pkg_chk
# pkg_comp chroot pkg_chk -ua

4. On génère le fichier pkg_summary qui va bien :

# cd /usr/pkgsrc/packages/All
# pkg_info -X *.tgz | bzip2 > pkg_summary.bz2

5. On ajoute le définition du dépôt local dans la configuration de pkgin, en éditant /usr/pkg/etc/pkgin/repositories.conf :

file:///usr/pkgsrc/packages/All

On peut enfin utiliser pkgin pour ajouter et supprimer des paquets. Il suffit de regénérer le pkg_summary à chaque nouvelle compilation de paquet dans le chroot.

Pour l'upgrade, il faut pouvoir ne garder que les paquets les plus à jour dans le dépôt, pour cela l'outil pkg_tarup entre en jeu, il permet de générer les paquets binaires à partir de l'installation courante.

Après une upgrade avec pkg_chk dans le chroot, on peut mettre à jour le dépôt :

# pkg_comp build pkgtools/pkg_tarup
# rm /usr/pkgsrc/packages/All/*
# pkg_comp chroot pkg_tarup -a -d /usr/pkgsrc/packages/All \'*\'
# cd /usr/pkgsrc/packages/All
# pkg_info -X *.tgz | bzip2 > pkg_summary.bz2

Enfin, pour mettre à jour avec pkgin :

# pkgin up
# pkgin fug

En reconfigurant ma gateway sur NetBSD, le serveur Bind fournit dans « basesys » refusait de fonctionner à cause de l'activation de DNSSEC par défaut. Pour le désactiver, il suffit de modifier les paramètres suivants dans /etc/named.conf :

options {
        # ...

        dnssec-enable no;
        dnssec-validation no;
#        dnssec-lookaside auto;

        # ...
};

Mais ce n'est pas la solution idéale, sachant que DNSSEC est activé sur la zone root depuis juin 2010, autant l'utiliser. Pour avoir DNSSEC dans le Bind du basesys, il manque juste la configuration des clés. On récupère la DNSKEY de la zone root avec la commande qui va bien :

# dig +dnssec +multiline . dnskey > /chemin/vers/root_dnskey

On obtient la clé qu'il faut vérifier, on génère donc l'enregistrement DS correspondant :

# dnssec-dsfromkey -2 -f /chemin/vers/root_dnskey .
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5

Attention : le dernier espace doit être ignoré.

On compare donc à ce que fournit l'IANA (http://data.iana.org/root-anchors/root-anchors.xml) et d'autres comme Kirei (http://www.kirei.se/en/2010/06/20/root-ksk/) qui fournissent également les signatures PGP à vérifier.

Quand c'est bon (GPG dit OK), on ajoute un bloc managed-keys avec le contenu de l'enregistrement DNSKEY de la zone root dans /etc/named.conf :

options {
        # ...

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;
        managed-keys-directory "keys";

        # ...
};

managed-keys {
        "." initial-key 257 3 8 "AwEAAagAIKlVZrp...";
};

Pour bénéficier du « look aside », c'est à dire une autre source de vérification des données du DNS, il faut ajouter la clé sur service DLV de ISC (l'organisation qui code Bind), en récupérant la clé là : https://www.isc.org/solutions/dlv et après vérification des signatures PGP, on peut ajouter un bloc trusted-keys à /etc/named.conf :

trusted-keys {
        dlv.isc.org. 257 3 5 "BEAAAAP...";
};

Avant de relancer le service, on peut configurer des logs (voir le wiki pour les logs dans le chroot) pour mettre du debug sur la partie DNSSEC :

logging {
        # ...
        channel dnssec_log_file {
                file "/var/log/dnssec.log" versions 3 size 20m;
                severity debug 3;
                print-category yes;
                print-severity yes;
                print-time yes;
        };

        category dnssec { dnssec_log_file; };
        # ...
};

Et corriger quelques permissions :

# mkdir /etc/namedb/keys
# chown named:named /etc/namedb/keys

Enfin, on peut redémarrer le service et surveiller les logs :

# /etc/rc.d/named restart

Pour tester, on utilise dig sur zone signée :

# dig +dnssec +multiline net

; <<>> DiG 9.7.2-P3 <<>> +dnssec +multiline net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5595
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;net.                   IN A

;; AUTHORITY SECTION:
net.                    518 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. (
                                1299183189 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
net.                    518 IN RRSIG SOA 8 1 900 20110310201309 (
                                20110303200309 3980 net.
                                TUwUOfzcgGN/lXERU2Y+l3xMr8h6cg/t7ODOiGh8wSNq
                                8zOEvaTYeR+aKY76mY9X1d+odTcHv52ewLs0nQLlvzFb
                                iz48fxJrWoNKz5D1HxYDJGNqAsxh3usX0xxnNQoM0cIm
                                vvw5uFWxFK8cJ0Xha1s4Rpd2z2gVse3yZB3kU78= )
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 518 IN RRSIG NSEC3 8 2 86400 20110310193846 (
                                20110303192846 3980 net.
                                IhkKHupik3uQMq94xJQqaLmTeXPCeROIdcicFRh5ocsP
                                Mzfm/sO+9MpPdPpffCeCg3TtPxHhln6N0ffUa5jNoNnK
                                kmxZTqF6OUPnW7+pUm2kIysZxjOR5wK4n40IyTj8QNWZ
                                DspTJTVV7v/4RHgqnoHo2vHcZvLR744Y8PDEBH4= )
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 518 IN NSEC3 1 1 0 - A25R64HGRKT76GSK0JS1PNJ44MEELOJ6 NS SOA RRSIG DNSKEY NSEC3PARAM

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar  3 21:20:00 2011
;; MSG SIZE  rcvd: 511

Le flag ad indique que la réponse est valide selon DNSSEC.

On voit des trucs du genre dans les logs :

03-Mar-2011 18:22:12.734 dnssec: debug 3: validating @0xba5c7000: net DS: starting
03-Mar-2011 18:22:12.735 dnssec: debug 3: validating @0xba5c7000: net DS: attempting positive response validation
03-Mar-2011 18:22:12.738 dnssec: debug 3: validating @0xba5ca000: . NS: starting
03-Mar-2011 18:22:12.739 dnssec: debug 3: validating @0xba5ca000: . NS: attempting insecurity proof
03-Mar-2011 18:22:12.739 dnssec: debug 3: validating @0xba5ca000: . NS: insecurity proof failed
03-Mar-2011 18:22:12.740 dnssec: info: validating @0xba5ca000: . NS: got insecure response; parent indicates it should be secure
03-Mar-2011 18:22:12.740 dnssec: debug 3: validator @0xba5ca000: dns_validator_destroy
03-Mar-2011 18:22:12.778 dnssec: debug 3: validating @0xba5ca000: . DNSKEY: starting
03-Mar-2011 18:22:12.779 dnssec: debug 3: validating @0xba5ca000: . DNSKEY: attempting insecurity proof
03-Mar-2011 18:22:12.779 dnssec: debug 3: validating @0xba5ca000: . DNSKEY: insecurity proof failed
03-Mar-2011 18:22:12.779 dnssec: info: validating @0xba5ca000: . DNSKEY: got insecure response; parent indicates it should be secure
03-Mar-2011 18:22:12.779 dnssec: debug 3: validator @0xba5ca000: dns_validator_destroy
03-Mar-2011 18:22:12.791 dnssec: debug 3: validating @0xba5ca000: . NS: starting
03-Mar-2011 18:22:12.792 dnssec: debug 3: validating @0xba5ca000: . NS: attempting positive response validation
03-Mar-2011 18:22:12.988 dnssec: debug 3: validating @0xba5c4000: . DNSKEY: starting
03-Mar-2011 18:22:12.988 dnssec: debug 3: validating @0xba5c4000: . DNSKEY: attempting positive response validation
03-Mar-2011 18:22:13.002 dnssec: debug 3: validating @0xba5c4000: . DNSKEY: verify rdataset (keyid=19036): success
03-Mar-2011 18:22:13.002 dnssec: debug 3: validating @0xba5c4000: . DNSKEY: signed by trusted key; marking as secure
03-Mar-2011 18:22:13.002 dnssec: debug 3: validator @0xba5c4000: dns_validator_destroy
03-Mar-2011 18:22:13.003 dnssec: debug 3: validating @0xba5ca000: . NS: in fetch_callback_validator
03-Mar-2011 18:22:13.003 dnssec: debug 3: validating @0xba5ca000: . NS: keyset with trust 8
03-Mar-2011 18:22:13.003 dnssec: debug 3: validating @0xba5ca000: . NS: resuming validate
03-Mar-2011 18:22:13.006 dnssec: debug 3: validating @0xba5ca000: . NS: verify rdataset (keyid=21639): success
03-Mar-2011 18:22:13.006 dnssec: debug 3: validating @0xba5ca000: . NS: marking as secure, noqname proof not needed
03-Mar-2011 18:22:13.006 dnssec: debug 3: validator @0xba5ca000: dns_validator_destroy
03-Mar-2011 18:22:13.008 dnssec: debug 3: validating @0xba5c7000: net DS: in fetch_callback_validator
03-Mar-2011 18:22:13.008 dnssec: debug 3: validating @0xba5c7000: net DS: keyset with trust 8
03-Mar-2011 18:22:13.008 dnssec: debug 3: validating @0xba5c7000: net DS: resuming validate
03-Mar-2011 18:22:13.011 dnssec: debug 3: validating @0xba5c7000: net DS: verify rdataset (keyid=21639): success
03-Mar-2011 18:22:13.011 dnssec: debug 3: validating @0xba5c7000: net DS: marking as secure, noqname proof not needed
03-Mar-2011 18:22:13.011 dnssec: debug 3: validator @0xba5c7000: dns_validator_destroy

On voit bien, que lors de la vérification de la signature de net, Bind commence par vérifier . (la zone root) et que ça marche.

PS: ne pas oublier de (re)mettre la verbosité des logs à info après coup.

Pour monter un service DNS on a besoin de /dev/random pour générer la clé rndc. Sans collecte d'entropie, /dev/random ne crache rien. La preuve sur un domU Xen en NetBSD 5.1 (le dom0 suit 5-stable), donnée par ktruss :

fourche ~ # ktruss rndc-confgen -a -t /var/chroot/named
[...]
   519      1 rndc-confgen open("/dev/random", 0x4, 0) = 3
[...]
   519      1 rndc-confgen read(0x3, 0xbf7fe4a8, 0x10) Err#35 EAGAIN

Le read() attend gentiment que /dev/random lui fournisse du nombre aléatoire pendant que celui-ci dit de revenir plus tard. La raison est simple, aucune source d'entropie n'est configurée pour la collecte sur le domU, comme l'indique rndctl :

fourche ~ # rndctl -l
Source                 Bits Type      Flags
xennet1                   0 net  
xennet0                   0 net  
xbd0                      0 disk

Et les stats ne sont pas glorieuses :

fourche ~ # rndctl -s    
               51 bits mixed into pool
                0 bits currently stored in pool (max 4096)
                0 bits of entropy discarded due to full pool
               51 hard-random bits generated
            16749 pseudo-random bits generated

Après une lecture du man de rndctl, on active tout :

fourche ~ # rndctl -ce -d xennet1
fourche ~ # rndctl -ce -d xennet0
fourche ~ # rndctl -ce -d xbd0

Ça va tout de suite mieux, rndc-confgen termine, et on a des « bits » qui commencent à remplir le « pool » :

fourche ~ # rndctl -ls
Source                 Bits Type      Flags
xennet1                   0 net  estimate, collect
xennet0                  80 net  estimate, collect
xbd0                      0 disk estimate, collect
              133 bits mixed into pool
               80 bits currently stored in pool (max 4096)
                0 bits of entropy discarded due to full pool
               53 hard-random bits generated
            17003 pseudo-random bits generated

Pour avoir ça activé au boot, dans /etc/rc.conf :

rndctl=YES
rndctl_flags="xbd0; -c -t net" # Voir les commentaires dans /etc/rc.d/rndctl

Reste à découvrir pourquoi ce n'est pas activé par défaut en domU...