code. grind. sleep.

samedi 12 mars 2011

pkgin adventures : conflit résolu

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 adventures : bien générer son pkg_summary

Comme indiqué dans d'autres posts, j'abuse des chroots pkg_comp pour tenir mes paquets à jour. Je suis récemment passé à l'utilisation de pkgin pour la gestion de mes paquets une fois préparés dans le chroot.

pkgin se base sur pkg_summary pour connaître toutes les informations des paquets, nécessaires à sa popotte. Il y a plusieurs façons de créer un fichier pkg_summary à donner à pkgin, mais seule une façon fonctionne correctement :

1. On génère le fichier à partir des paquets déjà installés :

# pkg_info -a -X | bzip2 > pkg_summary.bz2

2. On génère le fichier à partir des tarballs présentes dans /usr/pkgsrc/packages/All :

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

La méthode 1 n'est pas valable car l'information sur les tarballs manque. Ainsi, pkgin considère les tailles de tarball à 0 comme valables, ce qui arrive lorsqu'un dépôt est injoignable : le fetch laisse un fichier vide dans le cache que pkgin considère comme correct.

Il faut donc utiliser la méthode 2 pour fournir l'information correcte à pkgin.

Pour conclure, l'investigation autour de ce souci, à permis aux développeurs du projet d'ajouter :

  • Un mode verbose pour avoir plein d'informations utiles
  • Un message d'avertissement lorsque pkgin rencontre un paquet à avec une taille à 0

pkgin adventures : utiliser pkgin avec pkgsrc-current

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

vendredi 4 mars 2011

pkgsrc, pkg_comp et ccache

Pour utiliser ccache dans un chroot pkg_comp, on commence par installer ccache :

# pkg_comp build devel/ccache
# pkg_add /usr/pkgsrc/packages/All/ccache-3.1.4.tgz

En utilisant la cible package-install dans le chroot, ccache s'y trouve installé. On l'installe aussi sur le système pour surveiller les statistiques plus tard.

Ensuite, on édite le etc/mk.conf du chroot, par exemple /local/pkg_comp/default/etc/mk.conf, pour y définir les variables suivantes :

# ...
# fin de la conf speciale pkg_comp

CCACHE_DIR=${WRKOBJDIR}/.ccache
PKGSRC_COMPILER = ccache gcc

On créé ensuite le répertoire du cache, si le chemin du chroot est /local/pkg_comp/default, avec la variable WRKOBJDIR laissée par défaut :

# mkdir /local/pkg_comp/default/pkg_comp/obj/pkgsrc/.ccache

Ensuite, il suffit de compiler ses packages comme d'habitude.

Enfin, on peut suivre les statistiques du cache avec la commande suivante :

# CCACHE_DIR=/local/pkg_comp/default/pkg_comp/obj/pkgsrc/.ccache ccache -s
cache directory                     /local/pkg_comp/default/pkg_comp/obj/pkgsrc/.ccache
cache hit                            133
cache miss                          3053
called for link                      383
compile failed                        43
preprocessor error                    34
autoconf compile/link                388
unsupported compiler option          216
no input file                         55
files in cache                      6201
cache size                          58.7 Mbytes
max cache size                    1024.0 Mbytes

P.S. : Une doc pour mettre en place un chroot pkg_comp est disponible sur le wiki

jeudi 3 mars 2011

DNSSEC et Bind sur NetBSD

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.

samedi 26 février 2011

Accès SSH externe sur une gateway NetBSD

Pour permettre l'accès à la gateway depuis Internet avec un maximum de sécurité, j'ai configuré le serveur OpenSSH (fournit dans basesys) et PF pour :

  • N'autoriser l'accès que par clé publique
  • Empêcher les attaques par force brute sur le serveur

La configuration d'OpenSSH peut se faire de deux façon :

  1. On désactive l'authentification par mot de passe et l'utilisation de PAM pour que la méthode keyboard-ineractive ne laisse rien passer
  2. On désactive l'authentification par mot de passe et le challenge/respone pour garder l'utilisation de PAM

J'ai choisi la 2ème méthode qui permet de garder la fonctionnalité de pam_nologin (seul root peut se logguer si /etc/nologin existe, en modifiant /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePam yes

Ainsi, l'authentification par mot de passe est totalement désactivée.

Pour empêcher les attaques par force brute sur le serveur, on configure PF de cette façon :

  • Il faut une table pour enregistrer les IP à bannir
  • On utilise l'option max-src-conn-rate sur la règle qui ouvre le port de SSH : pas plus de deux connexions dans un intervalle de dix secondes par IP.
  • On ajoute une règle pour bloquer les IP présentes de la table

Les règles PF, à placer dans /etc/pf.conf :

table <ssh_bans> persist

# allow ssh on the external interface, limit to connections in ten seconds
pass in on $ext_if inet proto tcp to ($ext_if) port ssh \
    keep state (max-src-conn-rate 2/10, overload <ssh_bans> flush)

# reject banned ip from connectiong to ssh port
block return in on $ext_if inet proto tcp from <ssh_bans> to ($ext_if) port ssh

Pour surveiller, on utilise les options de manipulation des tables de pfctl :

# pfctl -t ssh_bans -T show
# pfctl -t ssh_bans -T add X.Y.Z.T
# pfctl -t ssh_bans -T delete X.Y.Z.T

Enfin, un petit thread qui explique à quoi sert le challenge/response et la méthode keyboard-interactive : http://groups.google.com/group/comp...

vendredi 25 février 2011

libedit vs. libreadline dans les packages PostgreSQL de Debian

Pour éditer sa ligne de commande dans psql, on peut soit compiler Postgres avec le support de readline, soit libedit. Pour Debian, les questions de licences sont très importantes, et ils pensent qu'il y a une incompatibilité entre la licence de libreadline (GPLv3) et celle de Postgres (BSD), c'est pourquoi ils ont décidé de compiler Postres avec la libedit. Malheureusement, la version de la libedit est vieille dans Debian et surtout limitée : on ne peut taper que des caractères ASCII, ce qui est une belle regression du point de vu du l'utilisation.

Il y avait deux solutions :

  • Ne taper que des caractères ASCII
  • Recompiler les packages Postgres avec le support de readline, c'est ce que j'ai fait.

Un workaround a été trouvé récemment, en ayant la libreadline installée, on peut s'arranger pour l'utiliser grâce à un LD_PRELOAD bien placé. C'est ce que fait pg_wrapper (le truc qui permet d'avoir plusieurs versions de Postgres en même temps sous Debian) depuis la version 114 des packages postgresql-common et postgresql-client-common.

De plus, la priorité a été mise plus haute sur cette mise à jour, qui corrige aussi d'autres problèmes, et cette version est déjà dans testing.

Enfin, j'ai refais les backports que je maintiens pour fournir diverses versions de Postgres sur Debian, non disponibles dans les dépôts officiels : c'est sur le dépôt http://debian.dalibo.org.

mardi 22 février 2011

Recréer une séquence

On peut faire ça dans 2 cas :

  • On a fait n'importe quoi, et la séquence a disparu :-(
  • On veut transformer une colonne en « SERIAL »
SET ROLE owner_de_la_table;
SELECT max(id)+1 FROM latable;
--  ?column? 
-- ----------
--       155
-- (1 row)
-- On prend donc « max(id)+1 » comme valeur de départ de la séquence
BEGIN;
CREATE SEQUENCE latable_id_seq START 155 OWNED BY latable.id;
COMMIT;

Pour lier la séquence à la table (et ainsi l'utiliser lors d'INSERT par exemple) :

BEGIN;
ALTER TABLE schema.latable ALTER COLUMN id SET DEFAULT NEXTVAL('latable_id_seq'::regclass);
COMMIT;

Back

Me voilà de retour au blog. Maintenant, faut migrer les pages du wiki qui sont du blog.

Welcome to Dotclear!

This is your first entry. When you're ready to blog, log in to edit or delete it.

jeudi 30 décembre 2010

Choisir des sources d'entropie pour /dev/[u]random

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...

lundi 29 novembre 2010

Dual boot Debian/NetBSD

L'installation d'un dual boot Linux/BSD est somme toute assez simple, on coupe le disque en deux et on installe les systèmes l'un après l'autre. La seule difficulté reste sur l'installation/configuration des bootloaders.

Voici comment j'ai installé mon laptop en dual boot Debian/NetBSD. D'abord, quelques principes/astuces:

  • Linux s'installe dans différentes partitions DOS
  • NetBSD installe ses partitions à l'intérieur d'une partition DOS qui lui est dédiée
  • On peut partager la swap entre les deux systèmes
  • On installe d'abord Linux et on utilise du LVM pour éviter de créer des partitions étendues
  • GRUB sera le boot loader principal et on chainload'era le boot loader de NetBSD

Table des partitions DOS:

  • Part 1: /boot (100Mb) - type Linux
  • Part 2: swap (taille de la RAM) - type Swap
  • Part 3: LVM (moitié du reste) - type Linux LVM
  • Part 4: NetBSD (le reste) - type NetBSD

Etapes:

  1. Installer Debian (on prend une squeeze avec grub2)
  2. Installer NetBSD
  3. Booter NetBSD et lancer: installboot -v /dev/rwd0a /usr/mdec/bootxx_ffsv1 (wd0a est la partition / et commence au début de la partition DOS allouée à NetBSD)
  4. Rebooter sur le mode Rescue de Debian:
    1. Choisir son root fs et executer un shell dedans
    2. Monter tous les FS: mount -t ext3 -a
    3. Editer /etc/grub.d/40_custom (voir plus bas) :
    4. Lancer: grub-install
  5. Rebooter et vérifier que tout est bien accessible

/etc/grub.d/40_custom :

#!/bin/sh
exec tail -n +3 $0
menuentry "NetBSD" {
      set root=(hd0,4)
      chainloader +1
}

page 2 de 2 -