Another Home Page Blog - NetBSD

Bind : automatiser la mise à jour d'entrées DNS

2019-07-08T09:30:00+02:00

J'ai eu récemment à configurer un accès vers une machine dont l'adresse IP n'est pas fixe (typiquement derrière une box ADSL dont l'abonnement ne propose pas d'IP fixe). J'avais déjà mis en place un accès similaire il y a quelques années, mais je n'en avais pas fait de billet, voici donc l'occasion.

Plantons un peu le décor

Je suis donc dans la situation suivante : la machine, sous NetBSD, dispose d'un accès Internet derrière une box ADSL fournissant une IPv4 dynamique. Je dispose d'un nom de domaine, d'un serveur DNS public, ainsi que d'un serveur web public. En dehors des éléments, je ne souhaite pas compter sur un service tiers supplémentaire. L'idée est donc la suivante : depuis la machine en question, réussir à obtenir son adresse IP publique de sortie, et aller la donner au serveur DNS pour qu'il mette à jour une entrée afin que la dite machine soit accessible (pour un accès SSH ou HTTPS par exemple).

Étape 1 : connaître son adresse IP publique

Pour cette première étape, j'ai choisi d'utiliser un serveur web existant, qui tourne sous Nginx. Celui-ci me permet d'afficher l'adresse IP du client, sans utiliser de script supplémentaire PHP, Python ou autre. J'ai ajouté la configuration suivante dans mon virtual host :

location /myip {
   default_type text/plain;
   return 200 "$remote_addr";
}

Une fois Nginx relancé, je peux lancer une requête via un navigateur, wget ou curl pour afficher mon adresse IP :

$ curl http://www.example.org/myip
109.XXX.YYY.ZZZ

Étape 2 : mettre à jour une entrée DNS sans les mains

Cette deuxième étape commence par la création, manuelle, d'une nouvelle entrée de type A dans la zone DNS. Je ne détaille cette création, elle est en théorie assez basique pour toute personne qui a déjà monté un serveur DNS. Par contre il va falloir mettre à jour régulièrement cet enregistrement. Pour ne pas avoir à le mettre à jour manuellement, j'ai utilisé nsupdate. Cet outil repose sur la RFC 2136, ce qui a l'avantage d'être ouvert et documenté, et de ne pas être une solution bricolée maison à base de sed dans le fichier de zone en direct.

Pour utiliser nsupdate, il faut commencer par créer une paire de clés TSIG sur le client, et ensuite autoriser la clé publique au niveau du serveur DNS. L'outil dnssec-keygen va nous aider pour la création de clés :

$ dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST dynamic.example.org
Kdynamic.example.org.+163+16284

On notera que l'option -a permet de choisir l'algorithme cryptographique, -b la taille de clé, et l'option -n spécifie le type d'entrée à laquelle se destine cette paire de clés.2 fichiers sont alors produits, dans notre exemples ils se nomment Kdynamic.example.org.+163+16284.key (la clé publique) et Kdynamic.example.org.+163+16284.private (la clé privée). La clé publique a cette tête :

$ cat Kdynamic.example.org.+163+16284.key 
dynamic.example.org. IN KEY 512 3 163 EmvYb14yJA+0qgRmqaMng02cQoCAbekP2ou9M1fNWX4=

Quant à la clé privée :

$ cat Kdynamic.example.org.+163+16284.private 
Private-key-format: v1.3
Algorithm: 163 (HMAC_SHA256)
Key: EmvYb14yJA+0qgRmqaMng02cQoCAbekP2ou9M1fNWX4=
Bits: AAA=
Created: 20181112210734
Publish: 20181112210734
Activate: 20181112210734

Note : je n'ai pas de problème à divulguer cette clé, car je l'ai volontairement générée à des fins d'exemple. Bien entendu, il ne fait pas divulguer sa clé privée ;)

Maintenant, autorisons notre clé publique au niveau du serveur DNS Bind. Cela se situe directement dans le fichier de configuration named.conf, et cela se passe en deux parties. La première consiste à déclarer la clé publique :

key "dynamic.example.org." {
       algorithm HMAC-SHA256;
       secret "EmvYb14yJA+0qgRmqaMng02cQoCAbekP2ou9M1fNWX4=";
};

Attention, il faut bien préciser le même algorithme que lors de la génération de clés.

La deuxième partie consiste à autoriser cette clé publique au niveau de la configuration de la zone DNS sur laquelle je souhaite agir :

zone "example.org" IN {
       type master;
       file "/var/named/master/example.org";
       allow-transfer {10.13.37.53; };
       allow-query { any; };
       update-policy {
               grant dynamic.anotherhomepage.org. name dynamic.anotherhomepage.org. A CNAME TXT;
               grant dynamic2.anotherhomepage.org. name dynamic2.anotherhomepage.org. A CNAME TXT;
       };
};

Il s'agit d'une déclaration relativement classique, mais on notera la présence d'une directive update-policy dans laquelle j'autorise ma clé (définie par le nom lors de la génération par dnssec-keygen) à modifier un enregistrement DNS (définie par name puis son nom) des types décrits après (ici, mon enregistrement peut être de type A, CNAME ou TXT). L'exemple ci-dessus propose même deux enregistrements modifiés par deux clés différentes.

On peut alors utiliser nsupdate. Créons un fichier qui va contenir les données à pousser vers le serveur DNS :

$ cat dnsupdate.txt
server ns0.example.org
zone example.org.
update delete dynamic.example.org.
update add dynamic.example.org. 180 A 10.13.37.92
show
send

Ensuite, lançons nsupdate :

nsupdate -k ./Kdynamic.example.org.+163+16284.private -v ./dnsupdate.txt

Si tout se passe bien, l'enregistrement DNS devrait être à jour. Pour se faciliter les tests, on peut, lors de la création de celui-ci, mettre une valeur volontairement erronée, et constater qu'une fois nsupdate lancé, la valeur est correcte.

Étape 3 : on secoue bien fort

Maintenant qu'on a tous les outils, il ne reste plus qu'à tout englober ensemble dans un script à glisser dans une tâche cron. Voici, dessous, le script que j'ai fait pour l'exemple. Bien entendu, il utilise la méthode "La Rache" et mériterait un peu plus de rigueur dans son développement. Mais c'est un début, fonctionnel et simple à comprendre.

#!/usr/pkg/bin/bash
set -x
curl_bin=$(which curl)
curl_opts="-s"
dig_bin=$(which dig)
nsupdate_bin=$(which nsupdate)
ip_check_service="http://www.example.org/myip"
keyfile="/home/nils/keys/Kdynamic.example.org.+163+16284.private"
current_ip=$(${curl_bin} ${curl_opts} ${ip_check_service})
current_reverse=$(${dig_bin} +short @ns1.fdn.org -x ${current_ip})
previous_cname=$(${dig_bin} +short @ns0.example.org dynamic.example.org)
dns_server=$(dig +short -t A ns0.example.org)

cat > /tmp/majdnscloud.txt << EOF
server ${dns_server}
zone example.org.
update delete dynamic.example.org.
update add dynamic.example.org. 180 CNAME ${current_reverse}
show
send
EOF


nsupdate -k ${keyfile} -v /tmp/majdnscloud.txt
rm -f /tmp/majdnscloud.txt

Autres possibilités ?

Il se peut qu'on ne dispose pas de ressource pour installer un serveur qui donnerait notre IP publique de sortie, il est alors possible d'utiliser un service tiers. J'en utilise occasionnellement deux : What's My IP et IP chicken.

Pour ce qui est de la mise à jour automatisée d'un enregistrement DNS, selon le registrar, il est possible que celui-ci le propose via une API, comme Gandi LiveDNS par exemple.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Jake Givens - Busy freeway traffic at night.

Commentaires

Le 08/07/2019 22:37 par cmic

Hello Cool. Je me souviens d'avoir écrit la même chose (ou presque) en Perl pour mettre ma zone à jour avec l'ajout ou la suppression d'un PC ou d'un serveur ; avec maj du reverse également. cmic, Sysadmin à la retraite...

Le 09/07/2019 19:53 par user

grant dynamic.anotherhomepage.org. name dynamic.anotherhomepage.org. A CNAME TXT; grant dynamic2.anotherhomepage.org. name dynamic2.anotherhomepage.org. A CNAME TXT;

Ça ne devrait pas être « grant dynamic.example.org. » vu le nom des clés générées au-dessus ?

Merci pour le tuto :)

Le 09/07/2019 22:05 par Nils

@user : en fait non, comme j'indique avec maladresse dans mon billet :

L'exemple ci-dessus propose même deux enregistrements modifiés par deux clés différentes.

Je cherchais à montrer qu'en mettant une deuxième clé, on pourrait avoir pour la même zone un deuxième enregistrement dynamique, mais je n'ai pas pris la peine de dupliquer toutes les autres parties. Pardon pour la confusion !

NetBSD : haute disponibilité avec CARP

2017-12-22T10:25:00+01:00

NetBSD dispose depuis la version 4.0 d'une implémentation du protocole CARP. Il s'agit d'un protocole, à l'origine prévu pour les routeurs, permettant à un groupe de machines de disposer d'une adresse IP flottante. Si la machine principale venait à être indisponible, une machine secondaire peut alors prendre le relai. CARP permet donc de mettre en place de la haute disponibilité.

Je me suis amusé à mettre en place une configuration CARP sur les deux serveurs DNS de mon LAN. Pourquoi ? J'ai remarqué que bien souvent, selon les OS, quand on spécifie deux serveurs DNS dans les paramètres réseau, même si la redondance est là, on peut sentir un ralentissement :

le client va faire du round-robin et donc régulièrement des requêtes vont échouer ;
le client va d'abord s'adresser au premier serveur DNS de sa liste, et si celui-ci est indisponible, il attendra un timeout avant de passer au suivant.

Il y a probablement d'autres moyens d'adresser ces problèmes, mais cela m'a fourni une excuse de jouer avec CARP, c'est le plus important :)

CARP se présente en fait sous forme d'une carte réseau fictive dont le pilote est disponible dans le noyau. Quand je dis disponible, c'est qu'en théorie l'option est compilée dans le noyau GENERIC, mais cela n'est pas forcément le cas sur toutes les plateformes. Ainsi, j'ai dû recompiler un noyau contenant “pseudo-device carp”.

Une fois que CARP est bien disponible, il suffit tout simplement de créer une nouvelle interface réseau sur chaque machine. La machine principale aura un poids plus fort que la machine secondaire, et portera l'adresse IP flottante en temps normal.

Sur la machine principale :

# ifconfig carp0 create
# ifconfig carp0 vhid 101 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

Sur la machine secondaire :

# ifconfig carp0 create
# ifconfig carp0 vhid 100 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

On peut alors vérifier que l'adresse IP flottante est joignable. A noter la présence d'un mot de passe permettant de limiter les cas de "vol d'IP flottante", ici positionné à "motdepassehalakon"

Pour que cela tienne au redémarrage, il faut bien entendu que la configuration soit enregistrée quelque part. En fait, en terme de configuration, il s'agit tout simplement de la configuration de la carte réseau carp0, ici sur la machine principale :

$ cat /etc/ifconfig.carp0
create
up
vhid 101 pass motdepassehalakon 10.13.37.42 255.255.255.0

Ensuite sur la machine secondaire :

$ cat /etc/ifconfig.carp0
create
up
vhid 100 pass motdepassehalakon 10.13.37.42 255.255.255.0

Maintenant, il ne reste plus qu'à tester... en débranchant la prise !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : State Library of New South Wales - Turner Twins, acrobats, 1937 / by Sam Hood.

Quelques statistiques du blog

2017-12-17T20:50:00+01:00

Suite au commentaire de Xate dans un récent billet, quelques statistiques sur les billets (blogmas ou pas) sur la première quinzaine de décembre. Pour cela, je me suis servi de mes one-liners en awk décrits ici et là.

Les billets les plus vus

Commençons par les billets les plus visités :

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/post/python-3-outils-anaylser-code     1527
/post/make-automatiser-quelques-taches-avec-un-makefile 260
/post/livre-apprendre-a-programmer-avec-python  243
/post/xz-pour-une-meilleure-compression-de-ses-fichiers 224
/post/centos-7-desactiver-firewalld-reactiver-iptables  209
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS       192
/post/livre-introduction-au-langage-c   168
/post/logrotate-exemple-vite-fait       165
/post/paris-open-source-summit-2017-jour-2      161
/post/en-retard 152
/post/paris-open-source-summit-2017     143
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 124
/post/Trouver-des-fichiers-doublons-avec-fdupes 123
/post/raspberry-pi-attention-alimentation       112
/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH  83
/post/2011/10/03/Installation-de-phpMyAdmin-sur-CentOS-6        76
/post/pbulk-aller-plus-loin-sur-les-parametres  72
/post/systemd-reconfigurer-unite-service        71
/post/2017/02/13/clamav-installation-et-scan-antivirus-sur-macos        69
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS&fromurl=redirect.asp  67

Le billet le plus populaire est donc celui sur les outils d'analyse de code Python, et de loin ! Je note que j'ai mal écrit "analyser" dans l'URL, il faudra vraiment que je fasse attention à cela à l'avenir ! Il m'arriver d'ailleurs régulièrement de dépublier puis republier un billet en m'apercevant que l'URL ne me convient pas. J'en profite pour remercier Dashie pour notre conversation sur Mastodon, sans ça je n'aurais pas eu l'idée d'écrire ce billet.

Les tag les plus vus

Quels tags sont les plus populaires ?

root@vhost2:~/tmp# grep "GET /tag/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/tag/NetBSD     73
/tag/Apache     55
/tag/CentOS     50
/tag/PHP        47
/tag/Linux/page/3       46
/tag/Linux      41
/tag/Perl       40
/tag/ssl        38
/tag/blogmas    34
/tag/Awstats    32
/tag/Mac%20OS%20X       31
/tag/RHEL       31
/tag/mp3        29
/tag/pkgsrc     29
/tag/RPM        29
/tag/macOS      28
/tag/Xen        27
/tag/ssh        27
/tag/tls        27
/tag/https      25

Visiblement, je commence à devenir populaire pour NetBSD, Apache, CentOS et PHP ! Dommage que pkgsrc soit un peu bas à mon goût. Le tag blogmas n'est pas non plus super populaire.

Les referers

D'où viennent les visites ?

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
"-"     5077
"http://www.google.co.uk/url?sa=t&source=web&cd=1"      468
"https://blog.anotherhomepage.org/"     203
"https://www.google.fr/"        196
"https://www.journalduhacker.net/"      193
"http://blog.anotherhomepage.org/"      124
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"       66
"http://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"        58
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables"        52
"https://blog.anotherhomepage.org/post/python-3-outils-anaylser-code"   45
"https://www.google.com/"       31
"https://blog.anotherhomepage.org/category/Humour"      29
""      28
"https://socialmediascanner.eset.com"   24
"https://blog.anotherhomepage.org/page/2"       22
"https://blog.anotherhomepage.org/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH"        19
"https://www.google.fr" 19
"https://www.journalduhacker.net/s/asxn1a/python_3_outils_pour_analyser_son_code"       16
"https://blog.anotherhomepage.org"      15
"https://blog.anotherhomepage.org/feed/tag/Linux/atom"  15

Pas grand-chose à dire de ce côté, si ce n'est que beaucoup n'ont pas de referer, et en creusant un peu, le lien vers Google UK est utilisé par la même IP, et toutes les visites vont sur le billet sur les outils d'analyse de code Python. J'ai par contre été cité par le Journal du Hacker, ce qui fait bien plaisir !

Des erreurs ?

Quelques trucs étranges :

root@vhost2:~/tmp# awk '{frequencies[$9]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -10
200     48038
301     17578
304     10958
404     834
"-"     716
503     464
302     229
400     143
206     22
403     17

Voyons voir les erreurs 404 :

root@vhost2:~/tmp# grep -w "404" access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' | sort -nr -k 2,2 | head -10
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 66
/pages/Welcomerobots.txt        64
/wp-login.php   45
/ads.txt        20
/tag/Apachepage/2       12
/pages/Welcomelicense.txt       12
/a2billing/common/javascript/misc.js    11
/post/2017/01/21/macOS-installer-pkgsrc-pour-beneficier-de-plus-de-logiciels    11
/apple-app-site-association     11
/post/  11

Résultat : sans doute des tentatives de bruteforce du blog, pensant qu'il s'agit d'un Wordpress ou d'autre chose. Par contre, il faudra que je regarde plus attentivement les billets à propos de firewalld et de pkgsrc sur macOS.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Bernard Spragg. NZ - Passing Time 2010 ).

Commentaires

Le 19/12/2017 19:27 par utux

Essaie goaccess pour tes stats :) (il parse les logs exactement comme tu as fait)

Le 19/12/2017 21:30 par Nils

Il est dans ma TODO. A la base, et comme certains billets en attestent, j'utilisais surtout Awstats, mais j'ai eu la flemme de le configurer lors de la dernière réinstallation du serveur web qui héberge ce blog.

NetBSD : recompilation d'un noyau pour intégrer NPF dans un domU

2017-12-15T11:55:00+01:00

Dans un billet précédent, j'abordais l'installation d'une machine virtuelle Xen NetBSD en mode paravirtuel.NetBSD, comme Linux, dispose en plus d'un noyau, de modules permettant d'étendre ses fonctionnalités. Ainsi, l'une des briques de pare-feu de NetBSD, NPF, est disponible sous forme de module. Le problème avec ce module, c'est qu'il n'est pas compatible avec un noyau domU. Il est donc nécessaire de recompiler un noyau NetBSD pour en profiter, en incluant le pilote NPF directement dedans plutôt qu'en module.

Récupération des sources

Recompiler un noyau NetBSD est assez facile. D'abord, je récupère les sources, ici celles de NetBSD 7.1 :

nils@shell2:/srv$ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
nils@shell2:/srv$ export CVS_RSH="ssh"
nils@shell2:/srv$ cvs checkout -r netbsd-7-1-RELEASE -P src

La documentation officielle le fait dans /usr/src, mais je le fais dans /srv/src, cela ne pose pas de problème.

Si vous souhaitez recompiler un système complet (et pas juste le noyau), il faudra aussi récupérer xsrc, ce que je ne ferai pas ici.

Création d'une configuration noyau personnalisée

Maintenant que les sources sont disponibles, je crée un fichier de configuration pour notre nouveau noyau. Pour cela pas besoin de repartir de zéro, je vais tout simplement copier un fichier existant, et ajouter l'option qui m'intéresse. A noter que les configurations de noyau pour NetBSD sont placées dans les sous-arborescences des différentes architectures. Dans mon cas, mes machines virtuelles sont en x86_64, ce qui correspond à amd64 côté NetBSD :

nils@shell2:/srv$ cd src
nils@shell2:/srv/src$ sys/arch/amd64/conf

Le fichier de configuration du noyau utilisé par défaut est GENERIC, et il en existe aussi un spécialisé pour un invté Xen : XEN3_DOMU. Je vais copier ce dernier au lieu de le modifier pour facilement différencier ma configuration de l'officielle :

nils@shell2:/srv/src/sys/arch/amd64/conf$ cp -vp XEN3_DOMU XEN3_DOMU_NPF

Je peux ensuite éditer mon nouveau fichier, et aller chercher cette ligne :

#pseudo-device  npf                     # NPF packet filter

Il suffit alors de commenter cette ligne, et de sauvegarder le fichier. Passons maintenant à la compilation en elle-même.

Compilation du noyau NetBSD personnalisé

La compilation d'un noyau NetBSD peut se faire de deux manières : manuellement ou via l'aide d'un script nommé build.sh. Ce script est capable, depuis n'importe quel OS compatible, de créer très simplement non seulement un noyau, mais aussi une release complète de NetBSD. Ce script est fourni dans les sources, et se trouve d'ailleurs à la racine.

D'abord, compilons les outils nécessaires :

nils@shell2:/srv/src/sys/arch/amd64/conf$
nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 tools

Autre détail intéressant, et c'est aussi la raison de la présence de l'option -U dans la commande précédente, je n'ai pas besoin d'être root pour ces opérations :)Passons donc à la compilation du noyau à proprement parler :

nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF

Selon la puissance de la machine, quelques minutes plus tard un résultat similaire au suivant devrait apparaître :

===> Kernels built from XEN3_DOMU_NPF:
  /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
===> build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> Summary of results:
         build.sh command:    ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF
         build.sh started:    Sun Jun 18 20:29:26 CEST 2017
         NetBSD version:      7.1
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 7.1 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /srv/src/obj/tooldir.NetBSD-7.1-amd64
         DESTDIR path:        /srv/src/obj/destdir.amd64
         RELEASEDIR path:     /srv/src/obj/releasedir
         Updated makewrapper: /srv/src/obj/tooldir.NetBSD-7.1-amd64/bin/nbmake-amd64
         Building kernel without building new tools
         Building kernel:     XEN3_DOMU_NPF
         Build directory:     /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF
         Kernels built from XEN3_DOMU_NPF:
          /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
         build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> .

Il me suffit donc de copier le fichier /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd sur mon dom0 et de l'utiliser dans un fichier de configuration Xen pour un domU !

Et NPF alors ?

Une fois notre domU démarré à l'aide de ce noyau, il suffit de suivre la documentation de NPF.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : D - 15 photography - GT3 RS.

Commentaires

Le 15/12/2017 22:21 par utux

Oh, un autre utilisateur de NetBSD ^^ Avec iMil ça en fait deux répertoriés xD

Le 18/12/2017 19:21 par Mathieu

Bonjour

Merci pour cet article ! Npf c'est utile par les temps qui courent, et ça change un peu d'iptables.

Et en réponse à utux : les utilisateurs et admins NetBSD sont discrets, mais sympa et efficaces ;-)

Cordialement Mathieu

Le 19/12/2017 21:35 par Nils

@ utux : nous sommes encore plus nombreux sur IRC, #netbsdfr sur Freenode.

@ Mathieu : merci du compliment :)

pbulk : aller plus loin sur les paramètres

2017-12-14T18:42:00+01:00

Aujourd'hui, je me suis dit que j'allais encore parler de mon Raspberry Pi 2. Oui, celui-là même qui en ce moment passe sont temps à compiler des paquets pkgsrc. J'avais commencé par parler de la mise en place de pbulk, puis il y a peu j'ai abordé les problèmes d'alimentation rencontrés suite à cette mise en place.

Cette fois-ci, ce n'est pas une question d'alimentation, mais de limites systèmes. J'indiquais dans mon billet les options suivantes en tête du fichier pbulk.conf :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Le premier problème que j'ai eu s'est matérialisé sous la forme d'un pur et simple “kill” lors de la compilation d'un paquet. Difficile ensuite de comprendre que celui-ci arrivait au bout d'une heure ! J'ai donc compilé le dit paquet manuellement et me suis rendu compte que cela mettait bien plus d'une heure. Cela peut sembler surprenant au premier abord, mais j'avais oublié que même en ayant 4 coeurs, un Raspberry Pi 2 est bien moins puissant qu'un PC classique x86_64. Il met donc, logiquement, bien plus de temps pour créer un même paquet. J'ai donc fini par commenter ces deux directives, pour voir si d'autres paquets, auparavant en échec pour des raisons obscures, peuvent compiler sans soucis.

A l'heure où j'écris ceci, le bulk build n'est pas terminé, mais j'ai déjà pu voir que le paquet qui m'a mis sur la voie est créé avec succès, ainsi que d'autres qui ne pouvaient pas être créés du fait de l'absence de ce premier.

Crédit photo : Joe deSousa - Gears.

Xen : installation d'un invité domU NetBSD

2017-05-09T09:00:00+02:00

Dans le billet précédent, j'ai abordé la création d'un hyperviseur Xen (dom0) NetBSD.Il est donc temps de s'occuper du système invité NetBSD, le domU.

Création du domU Xen

Pour créer notre domU, nous avons besoin de 3 éléments présents sur le dom0 :

un fichier de disque dur (on pourrait utiliser LVM ou une partition, mais cela est moins flexible) ;
dans le cas de NetBSD, un fichier de noyau ;
et un fichier de configuration.

D'abord, le fichier de disque dur. Pour le créer, il suffit d'utiliser la commande dd. La taille de ce fichier déterminera la taille du disque dur de la machine virtuelle. Créons un fichier de 4 Go (4096 blocs d'1 Mo) :

root@rogue:~# dd if=/dev/zero of=/srv/xen/images/disk/netbsd.img bs=1m count=4096

On peut remarquer que cet exemple remplit notre fichier de zéros, et ne crée pas de fichier sparse. Il semble que la gestion des fichiers sparse ne soit pas parfaite sous NetBSD, d'après le tutoriel officiel.

Ensuite, récupérons les fichiers noyau :

root@rogue:~# mkdir -p /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:~# cd /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOMU.gz

On récupère deux fichiers de noyau, car l'un d'entre eux ne sert que pour l'installation. Une fois celle-ci terminée, il faut penser à configurer notre domU avec le noyau "classique".

Nous pouvons enfin créer notre fichier de configuration, /usr/pkg/etc/xen/netbsd :

root@rogue:/usr/pkg/etc/xen# grep -v ^# netbsd | grep -v ^$
name = "netbsd"
uuid = "d0f3e8d3-2f54-11e7-b035-00301bbde894"
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:02' ]
disk = [ '/srv/xen/images/disk/netbsd.img,raw,xvda,rw' ]

Les directives du fichier de configuration sont assez explicites, néanmoins il convient de préciser certaines choses :

d'abord, le nom de la machine virtuelle ("name") doit être unique ;
et en passant, l'uuid aussi (généré via uuidgen), mais il n'est pas obligatoire, la directive peut être vide ;
la mémoire est spécifiée en méga-octets ;
on peut spécifier plusieurs interfaces réseau ou disques durs.

On peut ajouter bien d'autres options, mais il est préférable de commencer par un fichier simple, qui démarrera une machine en mode texte, avant d'aller plus loin.

Maintenant que notre fichier de configuration est prêt, démarrons notre domU :

```` root@rogue:/usr/pkg/etc/xen# xl create -c netbsd

L'option -c permet d'attacher la console locale de la machine virtuelle en mode texte, et donc de pouvoir interagir avec (pour, par exemple, effectuer une installation).

### Installation de NetBSD dans le domU

L'installation se passe de manière similaire à ce qui est [présenté dans le guide officiel](https://www.netbsd.org/docs/guide/en/chap-exinst.html ""NetBSD"), mais à une différence près : une fois l'installation terminée, il faut quitter l'installeur (au lieu de redémarrer), puis éteindre la machine virtuelle :

shutdown -p now

De retour dans le dom0, il faut alors changer le fichier de noyau pour un démarrage "classique" :

root@rogue:/usr/pkg/etc/xen# vi netbsd kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-XEN3_DOMU.gz"

On peut ensuite démarrer notre machine virtuelle, dans l'exemple suivant sans attacher la console locale de celle-ci :

root@rogue:/usr/pkg/etc/xen# xl create netbsd ```

On est vraiment obligé de spécifier sur le noyau ?

Dans le domU d'exemple du billet précédent, le système OpenWrt était démarré grâce à pygrub, un chargeur de démarrage pour Xen. Celui-ci n'est hélas pas capable de lire le système de fichiers FFS utilisé par NetBSD. Cela n'est pas non plus possible pour pv-grub, qui n'est de toute façon pas disponible dans les paquets Xen pkgsrc.

Quelles sont alors les possibilités ? La première consiste à créer une partition /boot en ext2/3/4 au début du disque virtuel, et d'y placer noyau et configuration Grub, comme l'indique ce tutoriel. Une autre consiste à compiler soi-même une version de Grub2, qui semble maintenant gérer Xen, tout du moins d'après ce billet du blog officiel Xen, daté de janvier 2015.

Autres actions possibles

Démarrer sa machine virtuelle, c'est bien, pouvoir effectuer d'autres actions et vérifications, c'est mieux ! Voici donc, en vrac, quelques commandes utiles pour gérer ses domU :

xl shutdown \<chemin vers le fichier de configuration> permet d'arrêter proprement celui-ci ;
besoin d'appuyer sur le bouton Off comme un gros barbare ? xl destroy \<nomdudomU> ;
lister les domU en fonctionnement : xl list ;
et pour avoir cette liste en temps réel, présentée à la manière d'un top, on peut utiliser xl top.

D'autres commandes et paramètres sont disponibles dans la page de manuel de la commande xl.

Crédit photo : ColonelMustard - the handler''

Xen : installation d'un hyperviseur dom0 NetBSD

2017-05-02T12:00:00+02:00

J'ai écrit dans le passé quelques billets concernant Xen, mais jamais sur l'installation à proprement parler d'un hyperviseur Xen à base de NetBSD. Il est temps de réparer cela ! Mais avant de commencer, quelques rappels :

en terminologie Xen, chaque système invité se nomme un "domaine" ;
une machine virtuelle est un domaines non-privilégié, en anglais "unprivileged domain", généralement raccourci en "domU" ;
l'OS qui fait fonctionner l'hyperviseur est un domaine privilégié, en anglais "privileged domain", ce qui donne en raccourci "dom0".

Il s'agit donc de détailler l'installation et la configuration de Xen en tant que dom0 sur un système NetBSD amd64. Pour valider son bon fonctionnement, une installation rapide d'un domU OpenWrt sera effectuée à la fin.

Mais avant de démarrer, voici quelques informations sur la configuration qui sera effectuée :

comme la machine physique ne dispose pas des instructions de virtualisation (Intel Atom 330), seul le mode "paravirtuel" sera abordé ;
la machine physique se verra attribuer 256 Mo de RAM sur ses 2 Go pour son fonctionnement ;
la configuration réseau sera en mode "bridge", le dom0 et les domU seront donc sur le même réseau.

Allons-y !

Installation et configuration de NetBSD

Commençons par l'installation du système d'exploitation : NetBSD 7.1 amd64. Il n'y a rien en particulier à signaler sur l'installation, cela dépend avant tout de son usage. Cette machine n'étant pas destinée à devenir un environnement de production, j'ai choisi un partitionnement minimal, à savoir juste un / qui prend tout le disque.

A noter aussi qu'à ce moment, il n'y a besoin de rien en particulier concernant le noyau. J'ai pris l'habitude de ne pas installer les sets de compilation ou source sur une machine sauf si j'en ai expressément besoin. Donc, je me suis limité aux sets suivants :

base ;
etc ;
man ;
misc ;
modules ;
tests ;
text ;
xbase.

Côté réseau, il sera sans doute plus simple de configurer une adresse IP statique. On va aussi dès maintenant configurer le bridge :

root@rogue:~# cat > /etc/ifconfig.bridge0 
create
!brconfig $int add re0 up

A noter que l'interface de la machine physique est re0, il convient de la modifier selon celle disponible. On va aussi autoriser la retransmission de paquets réseau :

root@rogue:~# cat >> /etc/sysctl.conf
net.inet.ip.forwarding=1

Ces modifications seront prises en compte au prochain démarrage du système, qu'il convient de faire dès maintenant.

Pour les paquets logiciels, j'ai choisi d'utiliser mon propre dépôt pkgsrc de paquets binaires. Là aussi, rien d'exceptionnel, j'ai juste installé mon petit confort personnel. Il est néanmoins possible d'utiliser le dépôt binaire pkgsrc officiel (configuré lors de l'installation) ou d'utiliser pkgsrc depuis les sources.

Installation et configuration de Xen 4.6

Maintenant que notre système est installé et prêt, passons à l'installation de Xen. Rien de compliqué non plus à ce niveau, il suffit d'utiliser pkgin :

root@rogue:~# pkgin in xenkernel46 xentools46

Des messages seront affichés durant l'installation des différents paquets, montrant un certain nombre de messages de conseils et de recommandations.

Pour que Xen fonctionne, il faut d'abord démarrer un noyau spécialisé qui chargera de lancer l'hyperviseur. Le noyau NetBSD dom0 est disponible à côté du noyau générique sur les dépôts :

root@rogue:~# wget http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOM0.gz
root@rogue:~# mv netbsd-XEN3_DOM0.gz /

Configurons maintenant le chargeur de démarrage. Il suffit d'insérer la ligne suivante au début du fichier /boot.cfg :

menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /usr/pkg/xen46-kernel/xen.gz dom0_mem=256M

Parmi les détails de cette ligne de configuration, on remarquera l'allocation de 256 Mo de mémoire vive pour le dom0.

Par contre, si jamais le partitionnement prévoit un /usr séparé, il vaudra mieux copier /usr/pkg/xen46-kernel/xen.gz dans / et de remplacer les chemins en accord avec la nouvelle localisation du fichier. Une fois que le chargeur de démarrage est modifié, un redémarrage est nécessaire, mais juste avant on peut créer les fichiers spéciaux dans /dev :

root@rogue~# cd /dev && sh MAKEDEV xen

Maintenant on peut redémarrer :)

Mais tout n'est pas encore prêt. Par exemple, le service xencommons doit être activé et démarré. On ajoute alors la ligne suivante au fichier /etc/rc.conf :

xencommons=YES

On peut ensuite lancer le service :

root@rogue~# service xencommons start

Il y a encore un fichier de configuration à modifier avant de commencer à faire joujou avec nos machines (para-)virtuelles : /usr/pkg/etc/xl.conf. Je n'ai fait que deux modifications à ce fichier :

root@rogue:~# grep -v ^# /usr/pkg/etc/xen/xl.conf | grep -v ^$
vif.default.script="vif-bridge"
vif.default.bridge="bridge0"

Il est temps d'effectuer rapidement un test de domU !

Test d'un domU OpenWrt

Un moyen de tester rapidement le fonctionnement de son dom0 Xen est d'utiliser un domU OpenWrt : il s'agit en effet d'un OS léger, non seulement d'un point de vue processeur et mémoire, mais aussi d'un point de vue espace disque. Au moment de la rédaction de cet article, la dernière version stable d'OpenWrt est la 15.05.1 et porte le nom de Chaos Calmer.

Deux éléments sont nécessaires : un fichier qui sera le disque dur de la machine virtuelle, et un fichier de configuration. Dans le premier cas c'est très simple, il suffit d'aller le récupérer sur le site d'OpenWrt, de le placer dans un répertoire, et de le décompresser :

root@rogue:~# mkdir -p /srv/xen/images/disk
root@rogue:~# cd /srv/xen/images/disk
root@rogue:/srv/xen/images/disk# wget https://downloads.openwrt.org/latest/x86/xen_domu/openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gzroot@rogue:/srv/xen/images/disk# zcat openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gz > openwrt.img

Continuons avec le fichier de configuration, basé sur un fichier d'exemple. Il doit se trouver dans /usr/pkg/etc/xen/, et se nomme tout simplement openwrt :

name = "openwrt"
uuid = "26824417-2dde-11e7-a2aa-00301bbde894"
bootloader = "/usr/pkg/bin/pygrub"
extra = "root=/dev/xvda2 rw"
memory = 128
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:01' ]
disk = [ '/srv/xen/images/disk/openwrt.img,raw,xvda,rw' ]

Maintenant que tout cela est en place, il ne reste plus qu'à lancer la machine virtuelle :

root@rogue:~# xl create -c /usr/pkg/etc/xen/openwrt

Une fois OpenWrt démarré, il suffit alors d'appuyer sur la touche entrée pour activer la console locale. Côté tests, il faut vérifier le nombre de processeurs (dans /proc/cpuinfo, il doit n'y en avoir qu'un), ainsi que la quantité de mémoire vive (dans /proc/meminfo, ou via free -m, on doit avoir 128 Mo). Si un serveur DHCP est présent, on peut facilement tester le réseau via udhcpc :

root@OpenWrt:/# udhcpc -i br-lan

On peut désormais vérifier que le réseau est bien connecté.

Crédit photo : Marcos Leal - Army

Commentaires

Le 03/05/2017 14:35 par utux

NetBSD ? Masochiste.

Le 03/05/2017 15:05 par Nils

Mais qu'est-ce que c'est bon ;-)

Sysupgrade : mise à jour facile d'un système NetBSD

2017-03-28T09:30:00+02:00

NetBSD 7.1 est disponible. Comme d'habitude, il est recommandé de mettre à jour son système, en particulier car cette version apporte de nombreux correctifs de sécurité.

Historiquement, mettre à jour son système NetBSD se fait via le logiciel d'installation, sysinst. Cependant, cette méthode a le principal désavantage de nécessiter de redémarrer sur l'installeur, et donc de rendre le système indisponible pendant toute la mise à jour.

Une deuxième possibilité consiste à décompresser soi-même les sets du système de base puis de lancer les commandes de post-installation, comme expliqué par exemple sur le wiki de GCU.

Cette deuxième possibilité, certes plus rapide, est automatisable, mais nécessite un peu d'intelligence, comme le fait de n'installer que les sets nécessaires, un noyau différent de GENERIC (surtout dans le cas où on compile soi-même un noyau personnalisé), voire même d'effacer son répertoire de téléchargement après coup. Et cela tombe bien, car c'est ce que fait sysupgrade ! A l'aide d'un simple fichier de configuration, celui-ci est capable de :

télécharger les sets d'une version précise de NetBSD ;
remplacer votre noyau par le nouveau, automatiquement, ou en spécifiant un nom de configuration ;
d'effectuer les tâches de post-installation ;
et même de faire le ménage à la fin !

Sysupgrade fait maintenant partie de la documentation officielle de mise à jour. Pour l'utiliser, idéalement, une commande suffit :

# sysupgrade auto http://cdn.NetBSD.org/pub/NetBSD/NetBSD-7.1/amd64

En ce qui me concerne, j'ai choisi de m'assurer que certaines options sont activées dans _/usr/pkg/etc/sysupgrade.conf_, en particulier car la commande _config_, qui permet de détecter le nom de la configuration du noyau, est disponible dans le set _comp_, que je n'installe pas systématiquement (ce dernier permet de disposer d'outils de développement et de compilation, que j'estime inutiles sur un serveur web par exemple).Mon fichier de configuration ressemble donc à ceci :

RELEASEDIR="http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/$(uname -m)"
KERNEL=GENERIC
ETCUPDATE=yes

Ma commande de mise à jour se résume donc à un simple sysupgrade auto. En revanche, la post-installation sera déclenchée et me demandera si je souhaite mettre à jour certains fichiers de configuration. Il convient donc d'être particulièrement attentif lors de cette étape.

Des remarques, des propositions d'améliorations ? Où même des exemples supplémentaires ? Les commentaires sont là pour ça !

pbulk : compilation massive de paquets pkgsrc

2017-02-27T09:30:00+01:00

Je continue dans ma série de billets sur pkgsrc, mais cette fois-ci on retourne sous NetBSD. L'objectif aujourd'hui est de construire de nombreux paquets (idéalement tous, ou alors une liste précise) binaires et de créer un dépôt pour ceux-ci. On appelle cela un bulk build lorsqu'on tente de construire tous les paquets disponibles, et un partial bulk build lorsqu'on décide de n'en construire qu'une partie, en inscrivant ceux-ci dans un fichier de liste.

Précisons que ce contenu est en partie basé sur le tutoriel du wiki officiel : Using pbulk to create a pkgsrc binary repository. Si vous préférez la langue de Shakespeare, cela peut s'avérer un bon point de départ.

Préparation

Effectuer ce genre d'opérations requiert idéalement un système dédié, matériel ou virtuel. Dans mon cas, j'ai opté un Raspberry Pi 2B.

Bon, on va pas se faire d'illusion, c'est juste pour du bulk build partiel, n'imaginons même pas tenter de construire tous les paquets disponibles sans une cinquantaine de ces trucs.

Côté ressources, il est donc préférable d'avoir plusieurs coeurs, 1 giga-octet de mémoire vive minimum, et quelques dizaines de giga-octets d'espace disque. Au niveau du partitionnement, c'est un peu comme on veut tant que l'endroit où on crée la sandbox (et les paquets) est assez grand. Dans mon cas, j'ai fait un choix très simpliste, vu que le Pi ne sert qu'à cela : un / sur une carte SD de 32 giga-octets. Le répertoire pour créer les sandbox est tout simplement /srv/sandbox.

Concernant l'installation de l'OS, là aussi on va se faciliter l'existence, il suffit d'installer tous les sets, sauf les codes sources du noyau et du système (encore moins de la partie graphique). Exemple sur le Pi, la liste des sets installés :

$ ls -hl /etc/mtree/
total 5.7M
-r--r--r--  1 root  wheel   57K Sep 25  2015 NetBSD.dist
-r--r--r--  1 root  wheel  749K Sep 25  2015 set.base
-r--r--r--  1 root  wheel  2.4M Sep 25  2015 set.comp
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.etc
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.games
-r--r--r--  1 root  wheel  815K Sep 25  2015 set.man
-r--r--r--  1 root  wheel   96K Sep 25  2015 set.misc
-r--r--r--  1 root  wheel   26K Sep 25  2015 set.modules
-r--r--r--  1 root  wheel   90K Sep 25  2015 set.text
-r--r--r--  1 root  wheel  193K Sep 25  2015 set.xbase
-r--r--r--  1 root  wheel  473K Sep 25  2015 set.xcomp
-r--r--r--  1 root  wheel   11K Sep 25  2015 set.xetc
-r--r--r--  1 root  wheel  761K Sep 25  2015 set.xfont
-r--r--r--  1 root  wheel   17K Sep 25  2015 set.xserver
-r--r--r--  1 root  wheel   18K Sep 25  2015 special

Par contre, dans certains cas, l'absence de /usr/src ou de /usr/xsrc peut arrêter net certaines manipulations. IL faut donc penser à les créer (en tant que root) : mkdir /usr/src && mkdir /usr/xsrc. Il n'est pas nécessaire d'installer pkgsrc, mais disposer au moins d'un dépôt de paquets binaires peut être une bonne idée (la dernière version stable suffira). Il s'agit plus d'une question de préférence ici.

Création et configuration de la sandbox

Nous allons donc créer une sandbox qui va contenir l'installation de l'outil pbulk. Cela a plusieurs avantages :

on peut créer plusieurs sandbox pour tester différents cas, comme une version différente de pkgsrc ou des options de compilation ;
si une sandbox ne fonctionne plus, il est possible d'en créer une autre, voire même de scripter son installation pour aller plus vite ;
on pourra installer son petit confort sur le système hébergeant la sandbox (qui a dit bash, vim et git ?), et aussi installer des outils de supervision ou de métrologie.

Ne soyons pas non plus trop optimistes sur la pérennité du système, dans le cas du Pi, j'en suis à la troisième réinstallation (une carte SD n'est pas un disque dur, une clé USB non plus).

Pour créer la sandbox, installons mksandbox. Cet outil est en fait un script shell qui va utiliser des points de montage de type null mountpoint pour faciliter la création de nos espaces de création de paquet et éviter de recopier tout le contenu du système hôte. Au moment de l'écriture de ce billet, la version en date est la 1.7, disponible dans pkgsrc-2016Q4. Au choix, on peut pkgin in mksandbox, pkg_add -v mksandbox, ou bien cd /usr/pkgsrc/pkgtools/mksandbox && make install clean clean-depends.

Une fois mksandbox installé, créons notre premier bac à sable (en tant que root) :

# mksandbox --without-pkgsrc /srv/sandbox/pkgsrc-2016q4
Make and populate /srv/sandbox/pkgsrc-2016q4/dev
Make and populate /srv/sandbox/pkgsrc-2016q4/etc
Make empty dirs upon which to mount the null mounts
Making /tmp in /srv/sandbox/pkgsrc-2016q4
Making /var/games in /srv/sandbox/pkgsrc-2016q4
Making /var/run in /srv/sandbox/pkgsrc-2016q4
Making /var/log in /srv/sandbox/pkgsrc-2016q4
Making /var/spool/lock in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmp in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmp in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlog in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlogx in /srv/sandbox/pkgsrc-2016q4
Mount /usr/src from /srv/sandbox/pkgsrc-2016q4
Mount /usr/xsrc from /srv/sandbox/pkgsrc-2016q4
Sandbox creation is now complete

La sandbox est d'ailleurs déjà montée à l'issue de sa création :

# mount | grep 2016q4
/bin on /srv/sandbox/pkgsrc-2016q4/bin type null (read-only, local)
/sbin on /srv/sandbox/pkgsrc-2016q4/sbin type null (read-only, local)
/lib on /srv/sandbox/pkgsrc-2016q4/lib type null (read-only, local)
/libexec on /srv/sandbox/pkgsrc-2016q4/libexec type null (read-only, local)
/usr/X11R7 on /srv/sandbox/pkgsrc-2016q4/usr/X11R7 type null (read-only, local)
/usr/bin on /srv/sandbox/pkgsrc-2016q4/usr/bin type null (read-only, local)
/usr/games on /srv/sandbox/pkgsrc-2016q4/usr/games type null (read-only, local)
/usr/include on /srv/sandbox/pkgsrc-2016q4/usr/include type null (read-only, local)
/usr/lib on /srv/sandbox/pkgsrc-2016q4/usr/lib type null (read-only, local)
/usr/libdata on /srv/sandbox/pkgsrc-2016q4/usr/libdata type null (read-only, local)
/usr/libexec on /srv/sandbox/pkgsrc-2016q4/usr/libexec type null (read-only, local)
/usr/share on /srv/sandbox/pkgsrc-2016q4/usr/share type null (read-only, local)
/usr/sbin on /srv/sandbox/pkgsrc-2016q4/usr/sbin type null (read-only, local)
/var/mail on /srv/sandbox/pkgsrc-2016q4/var/mail type null (read-only, local)
/usr/src on /srv/sandbox/pkgsrc-2016q4/usr/src type null (read-only, local)
/usr/xsrc on /srv/sandbox/pkgsrc-2016q4/usr/xsrc type null (read-only, local)

Profitons-en pour découvrir le script de montage, démontage, et d'entrée dans la sandbox, qui se nomme sandbox et se trouve à la racine de celle-ci. Dans mon cas c'est donc /srv/sandbox/pkgsrc-2016q4.

Pour démonter la sandbox, c'est donc :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Pour monter la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Et pour entrer dans la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox chroot

Démontons-donc la sandbox, et avant de la remonter, éditons le script de sandbox. Les lignes 16 à 33 montrent la liste des répertoires à monter, et nous allons en ajouter une, qui permettra à la sandbox d'envoyer des mails (c'est donc optionnel mais pratique parfois). Il s'agit du répertoire /var/spool. Dans mon cas, le résultat est donc :

fses="\\
/bin /bin ro \\
/sbin /sbin ro \\
/lib /lib ro \\
/libexec /libexec ro \\
/usr/X11R7 /usr/X11R7 ro \\
/usr/bin /usr/bin ro \\
/usr/games /usr/games ro \\
/usr/include /usr/include ro \\
/usr/lib /usr/lib ro \\
/usr/libdata /usr/libdata ro \\
/usr/libexec /usr/libexec ro \\
/usr/share /usr/share ro \\
/usr/sbin /usr/sbin ro \\
/var/mail /var/mail ro \\
/usr/src /usr/src ro \\
/usr/xsrc /usr/xsrc ro \\
/var/spool /var/spool rw \\
"

Notons qu'il s'agit du seul répertoire accessible en écriture. Nous pouvons alors monter la sandbox, et y entrer.

Notre sandbox est crée, mais il nous faut ajouter quelques éléments avant d'installer pbulk. Par exemple, il nous manque pkgsrc. Installons donc ce dernier :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr                                                                                              
netpi2# cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot co -rpkgsrc-2016Q4 pkgsrc

Dans le cas d'une installation de pkgsrc-current, il suffit de retirer la partie -rpkgsrc-2016Q4 de la commande précédente.Sauf que, dans mon cas, le Raspberry Pi (ou bien sa carte SD) ne tient pas le coup et abandonne avant la fin du checkout. Procédons à l'alternative :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr
netpi2# ftp http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz 
Trying 2a04:4e42:4::262:80 ...
ftp: Can't connect to `2a04:4e42:4::262:80': No route to host
Trying 151.101.61.6:80 ...
Requesting http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz
100% |*************************************************************************************************************************************************************************************************| 37422 KiB    2.65 MiB/s    00:00 ETA
38320872 bytes retrieved in 00:13 (2.65 MiB/s)
netpi2# unxz -v pkgsrc-2016Q4.tar.xz                                                                                                                                                                                                         
pkgsrc-2016Q4.tar.xz (1/1)
  100 %        36.5 MiB / 437.1 MiB = 0.084   8.8 MiB/s       0:49   
netpi2# tar -xvpf pkgsrc-2016Q4.tar
# non, je ne copierai pas la sortie d'un tar verbose de pkgsrc.
netpi2# cd pkgsrc && cvs update -dP

Note pour plus tard : bsdtar ne prend pas en compte nativement le format xz. En attendant, les archives au format bzip2 c'est pas mal.

Installation et configuration de pbulk

Avant d'installer pbulk, il convient de comprendre certains détails. Pbulk s'installe via pkgsrc, mais tous les paquets qui vont être créés par la suite le seront aussi, et probablement désinstallés. Cela risque donc d'influer sur les dépendances de pbulk. L'idée est donc d'installer pbulk non pas dans l'emplacement habituel des paquets /usr/pkg/ mais dans un autre endroit, qui se trouve être /usr/pbulk.

En préalable à l'installation de pbulk, initialisons un fichier d'options de compilation, nommé mk.conf.frag :

PKG_DEVELOPER=yes

MAKE_JOBS=3
SKIP_LICENSE_CHECK=yes
PKG_COMPILER=ccache gcc
PKG_RCD_SCRIPTS=yes
ALLOW_VULNERABLE_PACKAGES=YES
PKG_DEFAULT_OPTIONS+=
KRB5_ACCEPTED=heimdal mit-krb5
USE_CWRAPPERS=yes
PKG_OPTIONS.irssi+= ssl perl inet6

PKGCHK_CONF?=   /etc/pkgchk.conf
DEPENDS_TARGET= bulk-install
BATCH=          yes
BULK_PREREQ+=   pkgtools/lintpkgsrc
BULK_PREREQ+=   pkgtools/pkg_install
BULK_PREREQ+=   devel/ccache

# http://wiki.netbsd.org/tutorials/pkgsrc/cross_compile_distcc/
.for DISTCCDEPS in devel/ccache sysutils/checkperms pkgtools/digest devel/distcc devel/popt devel/libtool-base lang/f2c devel/gmake
.  if "${PKGPATH}" == "${DISTCCDEPS}"
IGNORE_DISTCC=  yes
IGNORE_CCACHE=  yes
.  endif
.endfor

WRKOBJDIR=              /tmp
PACKAGES=               /srv/packages
DISTDIR=                /srv/distfiles

L'idée est d'indiquer ici des options de personnalisation de compilation. Il est possible de comprendre à quoi correspondent ces options en allant jeter un œil dans le répertoire /usr/pkgsrc/mk/defaults/, mais je vais malgré tout m'attarder sur l'une d'entre elles : MAKE_JOBS. Cette directive permet d'utiliser plusieurs commandes make en parallèle, et il convient de l'ajuster selon le nombre de cœurs ou de threads de votre ordinateurs. Généralement une règle simple serait au minimum "nombre de processeurs +1". Mais, le Raspberry PI, malgré ses 4 cœurs, ne tient pas le coup, j'ai donc abaissé la valeurs à 3. A noter que le contenu de ce mk.conf.frag sera copié lors de l'installation de pbulk dans le fichier /etc/mk.conf. On pourra le modifier entre deux builds, pas besoin de relancer l'installation. Tiens, d'ailleurs, lançons-là :

sh /usr/pkgsrc/mk/pbulk/pbulk.sh -n -c mk.conf.frag

Une fois pbulk installé, configurons son fichier principal : /usr/pbulk/etc/pbulk.conf. Je ne vais pas détailler toutes les options, mais juste celles que je modifie. Commençons d'ailleurs par ajouter les deux lignes suivantes juste après la première :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Comme l'indiquent les commentaires en anglais (recopiés textuellement depuis la page wiki du début du billet), ils servent à limiter la consommation CPU de nos builds, au cas où. Je choisis ensuite l'URL du rapport de bulk build :

base_url=http://pkg.anotherhomepage.org/pub/pkgsrc/reports/NetBSD/earmv6hf/7.0_2016Q

Ce rapport va me permettre de voir quels paquets n'ont pu être construits, et surtout de comprendre pourquoi grâce aux fichiers de log.

Avant la construction des paquets, une phase permet de lister ceux-ci et de déterminer l'ordre dans lequel les construire. Cette étape se nomme le "scan". Pour accélérer cette étape, nous pouvons conserver le résultat du scan d'un build précédent. Pour cela :

reuse_scan_results=yes

Il est possible d'utiliser plusieurs machines avec pbulk. Ce n'est pas notre cas ici :

master_mode=no

On passe alors aux options de publication des paquets, via rsync :

pkg_rsync_args="-rltoDPq"
pkg_rsync_target="user@host:/chemin/vers/les/paquets/"
report_rsync_args="-rltoDPq"
report_rsync_target="user@host:/chemin/vers/les/rapports/"

Le build est long, c'est pratique d'avoir un mail quand c'est fini, et qui contient le rapport :

report_subject_prefix="pkgsrc-2016Q4"
report_recipients="adresse@domaine.valide"

C'est d'ailleurs l'occasion de parler du BulkTracker, qui permet de suivre différents bulk builds. Pour y participer, il suffit d'ajouter dans dans report_recipients l'adresse pkgsrc-bulk chez NetBSD point org.

On parlait de bulk buid partiel, on peut spécifier un fichier contenant une liste de paquets pour ne pas avoir à compiler tous les paquets :

limited_list=/etc/pkgchk.conf

Dans ce fichier, chaque paquet est sur sa propre ligne. Pour le moment, on peut démarrer avec juste pkgtools/pkgin dedans.

Je choisis ensuite de modifier certains répertoires, celui qui contient les logs de construction des paquets, et celui qui contient les paquets :

bulklog=/srv/bulklog
packages=/srv/packages

Ne pas oublier aussi, surtout pour NetBSD, de bien positionner la variable make :

make=/usr/bin/make

Dernier détail, la fin du fichier contient quelques redéfinitions de variables, donc attention de les mettre en commentaire !

Et tu bulk, et tu bulk, et tu bulk (mais sans t-shirt jaune ni planche de surf)

Avant de lancer la construction à proprement parler, petit avertissement : il est plus que recommandé d'utiliser screen ou tmux, car cela prend énormément de temps !

Lançons pbulk :

/usr/pbulk/bin/bulkbuild
Warning: All log files of the previous pbulk run will be
removed in 5 seconds. If you want to abort, press Ctrl-C.
Removing old scan results

Si jamais un paquet ne fonctionne pas, mais qu'après mise à jour, il peut compiler, il est possible de ne pas tout recompiler :

/usr/pbulk/bin/bulkbuild-rebuild category/pkgname

Il est aussi possible de reprendre un build arrêté inopinément :

/usr/pbulk/bin/bulkbuild-restart

J'espère que malgré la longueur, ce billet saura se montrer utile et intéressant. Comme toujours, les commentaires sont là pour accueillir remarques, questions et compléments !

Moi aussi j'ai des lutins qui courent très vite dans les fils !

2015-03-25T09:30:00+01:00

Résumé des épisodes précédents : NetBSD et PXE sont de grands copains. Démarrer ce type d'OS en PXE est faisable, pas trop difficile, documenté dans la langue de Shakespeare ou dans celle de Molière que ce soit pour un système fini (merci iMil) ou juste pour l'installation (autopromotion sans honte).

Mieux vaut tard que jamais, j'ai décidé de tenter ma chance et de configurer un système NetBSD sans disque, suite à la présence à \${HOME} d'une machine graphiquement réduite mais disposant d'une puissance de calcul non négligeable, jugez plutôt :

marvin# egrep '(name|MHz)' /proc/cpuinfo 
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2100.35
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2106.73
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2304.94
marvin# grep MemTotal /proc/meminfo
MemTotal:   3931368 kB

Merci à Madame de me laisser l'utiliser !

Je pourrais utiliser une clé USB, débrancher les disques durs et en ajouter un de mon stock. Mais ce ne serait pas drôle. J'ai utilisé les liens ci-dessus pour démarrer le brave Marvin via NFS, je ne vais donc pas paraphraser ces articles, mais ajouter ici quelques détails, remarques, trucs et peut-être astuces glanés ici et là et qui m'ont aidé.

D'abord, mieux vaut tester dans une machine virtuelle. Parce qu'aller chercher la bécane au fond sous le bureau, ça va une fois. Du coup, il faut s'assurer quand même qu'elle démarre sur le réseau, voire via Wake On LAN pour les plus fainéants. Sinon, une clé USB ou un CD Etherboot devrait faire l'affaire.

Ensuite, repérer la marque de la carte réseau et surtout potentiellement le pilote qui sera utilisé par NetBSD sera pratique : en effet, il faudra créer un fichier ifconfig.xy0, où xy0 sera remplacé par le nom du pilote de la carte réseau, dans mon cas c'est nfe0. Comment trouver le nom du pilote ? Soit on démarre un noyau NetBSD (l'installeur par exemple, qui permet d'obtenir un shell et d'exécuter dmesg | grep -i eth), soit on connaît le modèle de carte réseau et on cherche dans les sources. En ce qui me me concerne, je suis allé cherché la chaîne "NVIDIA" dans le fichier de configuration du noyau.

Toujours dans la catégorie réseau, si vous faites des tests en machine virtuelle, vous risquez probablement de le faire depuis un ordinateur portable connecté en Wi-Fi. Mieux vaut réfléchir un instant à la qualité de son réseau sans fil, et envisager de faire les tests en filaire. Mon expérience personnelle (VM simple cœur, 2Go de ram) : en Wi-Fi, le système démarre en plus de 5 bonnes minutes, en filaire (gigabit Ethernet) cela met moins d'une minute. 5 FICHUES MINUTES QUOI !!! En prime, dès que vous allez vouloir écrire ne serait-ce qu'un méga-octet sur le système, cela va se traîner. J'ai senti ma douleur quand je me suis rendu compte que j'avais oublié de décompresser un set.

J'ai eu une surprise sur le fichier /dev/null, il peut être nécessaire de le recréer :

marvin# cd /dev/
marvin# rm null
marvin# ./MAKEDEV -u all

L'installeur de NetBSD crée automatiquement certains fichiers ou paramètres. Sauf qu'on ne l'a pas utilisé... Parmi les trucs qu'il peut être utile de faire manuellement, il y a ces lignes dans /etc/fstab :

procfs                                          /proc            procfs  rw,auto,linux
kernfs                                          /kern            kernfs  rw
ptyfs                                            /dev/pts       ptyfs    rw

Il n'est pas obligatoire de monter /proc avec l'option linux, c'est juste un confort personnel. Ne pas oublier de créer les répertoires /proc/ et /kern/ avant.

Autre paramètre, celui de la date et de l'heure : par défaut, le système est en heure UTC, moi je veux l'heure de Paris. Pour cela, j'ai modifié le lien symbolique /etc/localtime :

marvin# readlink -f /etc/localtime
/usr/share/zoneinfo/Europe/Paris

Cela n'exclut pas le paramétrage NTP.

J'ai choisi de ne configurer qu'un seul partage NFS, car je n'envisage pas dans l'immédiat d'utiliser ce partage pour d'autres machines. Du coup, je n'ai initialement pas paramétré de swap, mais j'ai ajouté un fichier après coup, en utilisant la documentation officielle. Cela donne :

marvin# dd if=/dev/zero bs=1024k count=1024 of=/swapfile
marvin# chmod 600 /swapfile
marvin# swapctl -a -p 1 /swapfile
marvin# echo "/swapfile none    swap    sw,priority=1 0 0" >> /etc/fstab

Si comme moi vous avez déjà un serveur PXE en place, avec un fichier boot.cfg utilisé par pxeboot_ia32.bin, vous n'avez pas envie de mettre tous les noyaux, d'installation ou non, dans une longue liste. Il est possible de créer un deuxième fichier, qu'on donne à manger à pxeboot en lieu et place de boot.cfg. On le paramètre au niveau du serveur DHCP, par exemple pour ISC DHCP j'ai mis en place la configuration suivante :

host marvin {
        hardware ethernet 01:23:45:67:89:ab;
        fixed-address 192.168.1.13;
        option host-name "marvin";
        option root-path "/chemin/vers/diskless/nbmarvin";
        if filename = "boot.cfg" {
                filename "tftp:nbmarvin.boot.cfg";
        }   
}

On remarque donc que si pxeboot veut récupérer boot.cfg depuis la machine marvin, alors on lui servira nbmarvin.boot.cfg.

J'ai aussi remarqué que le clavier est en qwerty par défaut. Comme je n'ai pas relié de clavier ou d'écran à cette machine, et que j'ai configuré un accès SSH dès que possible, je n'ai pas changé ce paramètre. Toutefois, pour les pressés, vous pouvez utiliser la documentation officielle pour changer l'agencement du clavier.

Et sinon, pas de bol, la carte Wi-Fi PCI n'est pas reconnue :

vendor 0x1814 product 0x3060 (miscellaneous network) at pci1 dev 7 function 0 not configured

Bref, quelques notes en vrac qui, je l'espère, pourront s'avérer utile à l'occasion. Maintenant, il me reste à utiliser cette puissance de calcul à ma disposition (quelqu'un a dit bulk build pkgsrc ?).

vimrc global à son système

2015-02-06T09:30:00+01:00

Quand on utilise Vim, on a tendance à personnaliser sa configuration en ajoutant ses options préférées dans son fichier \~/.vimrc. Sur un système GNU/Linux (mon expérience porte principalement sur RHEL/CentOS/Fedora), il est possible d'étendre cette personnalisation à tous les utilisateurs d'un système en modifiant /etc/vimrc. En revanche, côté NetBSD, le chemin n'est pas le même. On pourrait naïvement penser qu'il suffit d'utiliser le préfixe /usr/pkg, hein ? Bein non, loupé : le fichier par défaut pour tous les utilisateurs est /usr/pkg/share/vim/vimrc. Heureusement, rien d'insurmontable, et quelques liens symboliques bien placés permettront d'harmoniser les configurations sur tous les systèmes.

je m'en frotte encore les yeux

2015-01-26T09:30:00+01:00

J'ai encore du mal à y croire : sur la page de la liste des développeurs NetBSD, on y trouve un "Nils". Et c'est moi.

Je. Suis. Développeur. NetBSD.

Je m'en frotte encore les yeux. Je me pince de temps en temps. Et il m'arrive d'aller vérifier sur la page, des fois que quelqu'un soit revenu sur la décision.

Bon allez, c'est pas tout, j'ai des paquets à commiter.

Commentaires

Le 30/01/2015 09:56 par orgrim

Félicitations Mr Nils@ :-)

Le 05/02/2015 09:33 par Nils

Merci :)

obtenir facilement les propriétés d'un fichier avec stat

2013-09-02T09:42:00+02:00

Généralement, quand on cherche à obtenir les propriétés d'un fichier, on utilise la commande ls, avec l'argument -l, ce qui donne un résultat proche de ceci :

nils@orgrimmar:~$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 août  4 11:21 /dev/null

C'est bien gentil, mais si on ne souhaite avoir comme information que le propriétaire d'un fichier, ça fait beaucoup de choses à filtrer. Filtrer la sortie de ls avec awk n'est pas le truc le plus méchant, mais je trouve que c'est comme utiliser un fusil à pompe pour se débarrasser d'une mouche. On est dans le monde UNIX, là où il y a des programmes qui ne font qu'une seule tâche, mais qui la font bien.

Et l'outil qui fait cela se nomme tout simplement stat, et est disponible sur de nombreux systèmes. Sous RHEL/CentOS, il est inclus dans le paquet coreutils, et il est installé avec le système de base dans NetBSD. Là où c'est par contre un peu moins drôle, c'est que l'implémentation Linux diffère de l'implémentation BSD.

Exemple, sous Linux :

nils@orgrimmar:~$ stat -c %U /dev/null 
root

Et ensuite sous NetBSD :

nils@dev:~$ stat -c %U /dev/null 
stat: unknown option -- c
usage: stat [-FlLnqrsx] [-f format] [-t timefmt] [file ...]

Allez, on recommence avec les bonnes options :

nils@dev:~$ stat -f %Su /dev/null 
root

Ici, j'ai cherché à afficher le nom de l'utilisateur propriétaire du fichier, mais d'autres propriétés sont disponibles, comme le nom du groupe, les UID et GID propriétaires, les droits, la taille, les dates de création et de modification, le nom du fichier... D'ailleurs, lancé sans autre argument que le nom du fichier, stat propose bon nombre d'informations.

freeshell : votre accès terminal UNIX sur internet

2013-08-26T09:42:00+02:00

Je me suis dit que ça serait sympa de vous faire découvrir l'association SDF (pour Super Dimension Fortress) et son projet freeshell : un accès en mode terminal sur une machine UNIX (NetBSD pour être exact). Cet accès, dans certaines conditions, est gratuit. C'est assez chouette, ça existe depuis très longtemps et permet d'apprendre les rudiments d'UNIX sans forcément installer en physique ou en virtuel ce type d'environnement. L'association fait cela à but éducatif et culturel, et est reconnue "non-profit" (oui, c'est une association américaine).

Pour accéder à freeshell, et créer un compte, il suffit de se munir d'un client SSH et de se connecter de la façon suivante :

ssh new@sdf.org

il existe d'autres moyens, qui reposent généralement sur SSH ou telnet, sur la page d'inscription au service.

J'ai indiqué plus haut que sous certaines conditions, ce service est gratuit : il y a en fait différent niveaux de services, selon ce que vous êtes prêts à payer. Une fois le compte et l'accès créé, vous disposez de certains outils, comme :

mutt, pop3, imap, icq, twitter, bsflite (aim), irc (sur le réseau SDF) ;
games, mud, lynx, gopher, TOPS-20 ;
hébergement HTTP statique de type http://yourlogin.sdf.org (d'autres domaines sont possibles) ;
traceroute, ping, whois, dig et d'autres.

mais tout ça est dans un shell limité. Si vous consentez à payer une petite somme (historiquement 1 Dollar US), un accès shell "classique" (comprendre : bash, ksh, tcsh, rc ou zsh) vous est alors ouvert, avec bien plus de possibilités, comme le webmail, FTP, SFTP (en entrée, pas en sortie), ou un accès à plus d'outils. Pourquoi le shell limité et pourquoi la somme ? Pour éviter le spam d'une part, et d'autre part car le traitement peut se faire par courrier papier, il suffit d'envoyer un billet de 1 Dollar (ou de 5 Euros) à l'adresse indiquée dans la page d'explication.

Encore plus d'outils et de possibilités sont offertes à qui est prêt à mettre un peu plus la main au portefeuille, et certains services sont facturés au mois, comme par exemple un accès VPN. Le tout est hébergé aux USA, et il existe aussi une version européenne, hébergée en Allemagne : SDFEU. Rien que pour l'accès shell, traceroute, dig, whois et autres lynx, c'est assez pratique je trouve, d'avoir un point "de sortie" ailleurs que dans son pays d'origine. Cela permet par exemple de tester des filtrages (géolocalisation ?). C'est aussi, à mon sens, un moyen de disposer d'un hébergement web (statique) peu coûteux et à taille plus humaine, et à finalité moins commerciale.

Nombre d'occurrences dans un fichier - remix

2012-10-01T13:37:00+02:00

Je détaillais dans un billet écrit il y a déjà un sacré bout de temps comment obtenir une sorte de top 10 des adresses IP effectuant le plus de requêtes dans un fichier de log Apache. J'ai décidé de revenir dessus, et de faire quelques déclinaisons de ce one-liner selon les recherches. Attention si vous voulez copier-coller ces exemples, ils ont été réalisés sous NetBSD, et la commande sort n'a pas les mêmes options. Grosso modo pour le moment, j'ai vu que là où on écrit sort -g sous GNU/Linux, il faut écrire sort -n sous NetBSD. J'ai aussi décidé de me limiter à un top 5 dans l'affichage, afin d'éviter un billet trop long.

Revenons donc d'abord sur le one-liner de base, les IP qui font le plus de requêtes, avec à gauche, l'adresse IP, et à droite le nombre de hits :

root@dev:/var/log/httpd# awk '{frequencies[$1]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
81.X.Y.Z    6414
208.F.B.I 1578
178.K.G.B  1301
67.D.S.T  1179
77.C.I.A     1157

Ensuite, effectuons pareil mais sur les URLs visitées, toujours avec le nombre de hits à droite :

root@dev:/var/log/httpd# awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
/post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5        7787
/post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5        4010
/post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL 1910
/post/2007/11/28/Installation-et-configuration-dun-serveur-dedie-OpenArena-071  1284
/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH  1266

Comme il ne s'agit que de modifier le numéro du champ, on peut aussi voir les codes de retour HTTP les plus obtenus :

root@dev:/var/log/httpd# awk '{frequencies[$9]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
200     57019
304     6156
404     1797
500     114
403     20

On peut ensuite aller chercher avec grep les pages causant des erreurs 500 ou 404.

Toujours avec la même facilité (un simple numéro de champ à modifier), on peut afficher les referers qui amènent le plus de hits :

root@dev:/var/log/httpd# awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
"-"     44306
"http://blog.anotherhomepage.org/post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5"       3443
"http://blog.anotherhomepage.org/post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL"        686
"http://blog.anotherhomepage.org/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH" 552
"http://www.google.fr/search?q=phpmyadmin+centos&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   401

On remarque que beaucoup n'ont pas de referer, mais il est probable que ce soient des hits sur le flux RSS. On remarque aussi que j'ai beaucoup de referers de mon propre site, il me suffit de les filtrer si je ne veux pas les afficher. Afin de rendre le traitement plus rapide, je décide de mettre la commande grep en premier dans mon traitement :

root@dev:/var/log/httpd# grep -v "blog.anotherhomepage.org" access.log | awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' | sort -nr -k 2,2 | head -5
"-"     44306
"http://www.google.fr/search?q=phpmyadmin+centos&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   401
"http://www.google.fr/search?q=centos+phpmyadmin&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   166
"http://forum.hardware.fr/hfr/OSAlternatifs/Installation/resolu-centos-phpmyadmin-sujet_70143_1.htm"    121
"http://www.google.fr/" 77

Reprenons notre affichage des URLs les plus visitées, mais cette fois prenons en compte les méthodes (GET, HEAD, POST) et la version du protocole HTTP :

root@dev:/var/log/httpd# awk -F """ '{frequencies[$2]++;} END {for (field in frequencies) printf "%s\\t%d" , field , frequencies[field];}' < ./access.log | sort -nr -k 4| head -5
GET /post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5 HTTP/1.1   4266
GET /post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5 HTTP/1.0   3521
GET /post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5 HTTP/1.1   2181
GET /post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5 HTTP/1.0   1829
GET /post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL HTTP/1.0    1193

On note ici l'utilisation de l'option "-F" de awk pour changer le motif du séparateur de champ, ce qui me permet d'avoir des champs avec espace.

Enfin, dernier exemple, trions maintenant les User-Agents :

root@dev:/var/log/httpd# awk -F """ '{frequencies[$6]++;} END {for (field in frequencies) printf "%d\\t%s" , frequencies[field], field;}' < ./access.log | sort -nr | head -5
10539   Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) VoilaBot BETA 1.2 (support.voilabot@orange-ftgroup.com)
6493    Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320; SPV M700; OpVer 19.123.2.733) OrangeBot-Mobile 2008.0 (mobilesearch.support@orange-ftgroup.com)
4188    Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)
3269    msnbot/2.0b (+http://search.msn.com/msnbot.htm)
3017    Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

J'ai décidé cette fois-ci d'afficher le nombre d'occurrences à gauche, car le nombre de champs (séparés par un espace) n'est plus fixe dans le cas des User-Agents. Mais au moment d'écrire cette phrase, j'ai de nouveau parcouru la page de manuel de sort et j'ai pu voir qu'il est possible de spécifier le séparateur de champ (option -t). J'ai utilisé le caractère \$ pour séparer le nombre d'occurrences du libellé du User-Agent, suivi de 'tr' pour le remplacer par une tabulation :

awk -F """ '{frequencies[$6]++;} END {for (field in frequencies) printf "%s$%d" , field , frequencies[field];}' < ./access.log | sort -nr -t$ -k 2,2| tr $ "\\t" | head -5
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) VoilaBot BETA 1.2 (support.voilabot@orange-ftgroup.com)  10539
Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320; SPV M700; OpVer 19.123.2.733) OrangeBot-Mobile 2008.0 (mobilesearch.support@orange-ftgroup.com)        6493
Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 4188
msnbot/2.0b (+http://search.msn.com/msnbot.htm) 3269
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)        3017

Le choix du caractère de séparateur de champ est discutable, mais il ne change pas qu'après réflexion, l'affichage de la commande précédente me semble plus lisible. Et je pense qu'afficher le nombre d'occurences en permier sera plus lisible dans d'autres cas, comme le referer ou l'URL.

Couleurs dans le terminal

2011-12-05T08:40:00+01:00

Pour beaucoup de gens, la vue d'un terminal, en général en texte blanc sur fond noir (mais aussi en noir sur fond blanc ou beige sur certaines distributions), peut s'avérer très peu attrayante. En ce qui me concerne je me suis accommodé et j'ai fini par apprécier le terminal, grâce à quelques modifications cosmétiques apportant de la couleur. Je trouve ainsi mon environnement beaucoup plus lisible.

Le prompt

Dans bash (et probablement dans d'autres shells), il est possible de modifier l'apparence du prompt via la variable d'environnement PS1. Regardons quelle est la valeur de PS1 sur un système CentOS (les simples quotes visent à montrer qu'il y a un espace à la fin) :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\\u@\\h \\W]\\$ '

Il est possible d'en modifier l'apparence avec de nombreux paramètres, tels que la couleur, certaines informations. Par exemple, j'ai choisi d'appliquer la personnalisation suivante sur tous mes environnements bash :

nils@arreat:~$ echo "PS1 vaut: '$PS1'"
PS1 vaut: '\\[\\]\\u\\[\\]@\\[\\]\\h\\[\\]:\\w\\[\\]\\$\\[\\] '

Ce qui est gênant, c'est que si ma variable d'environnement possède des couleurs, leurs codes ne sont pas affichés mais directement interprétés. En réalité, ma variable PS1 vaut :

# récupartion depuis mon bashrc :
PS1=$'\\[\\E[01;32m\\]\\u\\[\\E[0m\\]@\\[\\E[01;36m\\]\\h\\[\\E[0m\\]:\\w\\[\\E[01;32m\\]\\$\\[\\E[0m\\] '

Le nom d'utilisateur et le signe "\$" sont verts, tandis que le nom d'hôte est bleu. J'ai réalisé une variante pour l'utilisateur root où le vert est remplacé par du rouge.

Pour essayer, rien de plus simple : il suffit d'exporter la variable d'environnement PS1 avec une nouvelle valeur :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\\u@\\h \\W]\\$ '
[root@orgrimmar ~]# PS1=$'\\[\\E[01;32m\\]\\u\\[\\E[0m\\]@\\[\\E[01;36m\\]\\h\\[\\E[0m\\]:\\w\\[\\E[01;32m\\]\\$\\[\\E[0m\\] '
root@orgrimmar:~# echo "PS1 vaut: '$PS1'"
PS1 vaut: '\\[\\]\\u\\[\\]@\\[\\]\\h\\[\\]:\\w\\[\\]\\$\\[\\] '

Il est possible d'aller plus loin, comme de remplacer \\h par \\H pour obtenir le nom complet de la machine, d'insérer la date, d'afficher le prompt en gras... Vous trouverez chez Nixcraft les différents codes pour démarrer et stopper une couleur, ainsi que pour la mise en gras.

Si vos expérimentations amènent un résultat peu plaisant, deux possibilités : la première consiste à appliquer de nouveau l'ancienne valeur PS1, si vous avez copié son contenu ailleurs, ou d'aller le chercher par exemple dans /etc/bashrc ; la deuxième consiste tout simplement à fermer puis relancer votre terminal.

Une fois que votre nouveau prompt vous plaît, vous voulez rendre le changement définitif. Il est possible d'éditer son fichier .bashrc, .bash_profile ou .profile pour cela. Si vous souhaitez que ce changement soit effectif pour tous les utilisateurs, il est possible de modifier directement /etc/profile ou /etc/bashrc, mais je ne vous le recommande pas : il est possible de mal éditer le fichier et de supprimer accidentellement des commandes utiles, et donc de mettre en vrac son système.

Pour CentOS/RHEL/Fedora, j'ai pris l'habitude de créer un fichier nommé /etc/profile.d/prompt.sh : en effet, le fichier /etc/profile de ces distributions charge tous les .sh situés dans /etc/profile.d. Il devient donc aisé d'ajouter ou de retirer des personnalisations shell comme des alias, le prompt, et d'autres variables d'environnement qui affecteront tous les utilisateurs.

Pour NetBSD, j'ai choisi de créer un fichier /usr/pkg/etc/bashrc contenant ces personnalisations, et d'ajouter le contenu suivant dans /etc/profile (qui, par défaut, ne contient que des commentaires) :

if [ "${BASH_no}" != "no" ]; then
                 [ -r /usr/pkg/etc/bashrc ] && . /usr/pkg/etc/bashrc
fi

De la couleur dans ls

Selon votre système, cette option peut ne pas être disponible : cela fonctionne avec CentOS 4 et 5, mais pas avec NetBSD. Il s'agit tout simplement d'utiliser l'option --color, qui peut être complétée, par exemple --color=auto ou --color=tty. D'où viennent ces couleurs ? De la variable d'environnement LS_COLORS. On peut donc modifier cette variable pour afficher les couleurs différemment, et consulter la page de manuel de dircolors pour plus de détails.

Grep

La commande grep possède une option --color, parfois activée par défaut dans un alias sur certaines distributions. Elle colore en rouge la chaîne de caractères recherchée, que ce soit sous CentOS ou NetBSD.

Pages de manuel en couleur

most permet de visualiser un texte, comme more ou less. A la différence de ces deux derniers, most affiche les pages de manuel en couleur. Pour cela, vous pouvez utiliser la commande suivante :

PAGER=most man <votrecommande>

Pour que ce soit définitif, exportez la variable d'environnement PAGER=most. Attention toutefois, vérifiez que vous n'avez pas un PAGER=more qui traîne quelque part. Concernant la disponibilité du package, on peut le trouver dans pkgsrc ainsi que dans RPMForge.

Colorer ses fichiers de log

Un outil très pratique pour avoir des fichiers de log en couleurs est ccze. Il m'arrive de l'utiliser de la manière suivante :

tail -f /chemin/vers/mon/log/apache | ccze

Je peux aussi m'en servir sur un fichier qui n'est pas mis à jour en direct, en duo avec less :

ccze -A < monfichierdelog | less -R

Ce petit bijou connaît de nombreux formats de fichiers de log, et les rend du coup plus agréables à lire. C'est disponible dans pkgsrc et dans EPEL

Un top en couleur ?

Htop est une version “améliorée” de top qui, en plus d'afficher la couleur, affiche les taux d'occupation processeur et mémoire d'une manière un peu “graphique”. A noter cependant que cet outil est d'abord développé pour Linux, et qu'il faut, sous NetBSD, monter /proc avec l'option “linux” (celle-ci est cependant différente de la couche de compatibilité binaire linux). Htop est disponible dans pkgsrc et dans EPEL

Coloration syntaxique avec VIm

Vous trouvez vi trop morne et déprimant ? Installez VIm et activez la coloration syntaxique ! Souvent, seul vi est installé. Côté pkgsrc, le package se nomme vim et a pour dépendance vim-share. Côté Red Hat, on installera vim-enhanced (dispo dans les dépôts de base). Une fois ceci fait, ajoutez dans votre répertoire home un fichier .vimrc contenant au moins :

syn on
set nu

Ensuite, éditez un script shell, par exemple. Vous verrez la couleur et les numéros de ligne. Pour ceux qui comme moi on un fond noir ou sombre, on ajoutera la directive suivante à son .vimrc :

set bg=dark

La coloration syntaxique s'adaptera ainsi au fond de votre terminal.

Et voilà ! C'est Noël sur votre shell :-)

Commentaires

Le 13/12/2011 11:49 par Zanko

On peut avoir la couleur directement sous less avec quelques variables d’environnement, du style : export LESS_TERMCAP_mb=$'\E[01;31m' # begin blinking export LESS_TERMCAP_md=$'\E[01;38;5;33m' # begin bold export LESS_TERMCAP_me=$'\E[0m' # end mode export LESS_TERMCAP_se=$'\E[0m' # end standout-mode export LESS_TERMCAP_so=$'\E[01;31;5;31m' # begin standout-mode - info box export LESS_TERMCAP_ue=$'\E[0m' # end underline export LESS_TERMCAP_us=$'\E[38;5;31m' # begin underline

Lancement de GNU Screen en arrière-plan

2011-11-28T09:30:00+01:00

Les entrailles de GNU Screen (que j'abrègerai en screen par la suite) sont parfois difficiles à comprendre. L'histoire commence ainsi : je possède une machine NetBSD, un peu bruyante, que j'allume le matin au lever et que j'éteins le soir au coucher. J'utilise screen sur cette machine, et j'aimerais, par grosse fénéantise, que ce dernier se lance au démarrage de ma machine, en mode détaché. De la sorte, il ne me reste qu'à lancer un bon vieux “screen -r” lorsque que je m'y connecte et mon comportement ne change pas d'autres machines allumées 24h/24 : je me connecte, je “screen -r” et je suis prêt.

Jusque-là rien de bien particulier : un petit tour dans la page de manuel m'apprend que cela est déjà possible :

screen -d -m

Cette commande permet de faire en sorte qu'il démarre en mode détaché, et que c'est justement fait pour un éventuel script de démarrage. En bref, la paix dans le monde, mes amis :-)

Je me précipite donc sur \${EDITOR} et entame l'écriture épique d'un script shell qui va lancer screen en mode détaché sous l'identité de l'utilisateur que je suis, avec le fichier .screenrc qui convient. Le script fonctionne, le script fonctionne au démarrage de la machine (c'est mieux, hein ?), toujours la paix dans le monde, avec les oiseaux qui chantent, nous sommes dans un rêve :-)

Donc, plein d'illusions, je lance la commande screen -r . Et là, c'est le drame : le prompt de mon shell (bash) n'est pas coloré, et n'affiche pas le répertoire courant. Après avoir demandé conseil à mon moteur de recherche favori, je me rend compte que dans ce cas, screen a eu la bonne idée de remplacer la variable d'environnement PS1 (qui définit le prompt) par une valeur autre. D'où vient-elle ? Je ne le savais pas encore. J'ai essayé de redéfinir cette variable dans mon fichier de configuration .screenrc, sans succès. En désespoir de cause, je tente un “unset PS1”. Victoire ! J'ai mon prompt personnalisé ! je suis joie, bonheur, les oiseaux chantent, la paix dans le monde, tout ça tout ça...

Jusqu'à ce que j'édite un fichier texte. Et là, c'est le drame (à nouveau) : mon éditeur de texte, VIm, dispose d'une fonction de coloration syntaxique que j'active par défaut. C'est trèèèès pratique. J'active aussi la numérotation des lignes. Mais là, pas de couleur. Il s'agit pourtant d'un type de fichier connu. Je tente ma chance avec d'autres programmes disposant d'un affichage coloré, sans succès non plus. Après quelques bidouillages, je me rend compte qu'en changeant la variable d'environnement TERM de screen à xterm-color, j'obtiens à nouveau la couleur. En désespoir de cause j'ajoute “export TERM=xterm-color” au fichier /usr/pkg/etc/bashrc (ce qui m'évite de copier-coller un .bashrc dans le \$HOME de mon utilisateur et de root), je relance le script et là : couleur :-)

Avec le recul de l'écriture de ce billet, je me suis rendu compte que lorsque j'utilise screen -d -m, ce dernier charge mon fichier .profile (qui charge .shrc). Ces deux fichiers m'ont posé problème dans le passé : par exemple .profile contient deux exports qui entrent conflit avec mon bashrc, “export EDITOR=vi” et “export PAGER=more” (j'utilise vim et most à la place). J'ai aussi remarqué la ligne suivante dans le fichier .shrc :

export PS1="$(whoami)@$(hostname -s)$ "

Tiens, c'est marrant, c'est exactement le prompt que j'avais lors de mon premier problème... ;-)

Bref, ma solution n'est peut-être pas la plus élégante, mais au moins ça fonctionne. Mais comme on me l'a fait remarquer il y a presque deux mois, sur les systèmes Unix : There Is More Than One Way To Do It (Il y a plus d'une façon de le faire).

Commentaires

Le 28/11/2011 10:50 par Natacha

Il y a plus d'une façon de faire, mais parfois certaines sont plus justes que d'autres… En l'occurrence, tricher sur le TERM risque de venir tout un jeu d'ennuis : tu fais croire aux applications qu'il faut utiliser les séquences d'échappement d'xterm-color alors que tu es dans screen, et les deux ne sont pas interchangeables.

Par exemple d'après le termcap que j'ai sous les yeux, screen envoit \033[4~ pour signaler à l'application que la touche Fin a été utilisée, chose que l'application ne va pas comprendre parce que xterm-color evoits \033OF. Donc je soupçonne que ce changement de TERM casse la touche Fin. Et dans l'autre sens, la séquence à envoyer à screen pour effacer l'écran est \033[H\033[J mais l'application qui croit qu'elle a affaire à un xterm enverra \033[H\033[2J à la place.

Si ça ne te poses pas de problème, tant mieux, mais ça fait une piste pour toutes les petites choses qui vont casser comme ça ;-)

Le 28/11/2011 21:55 par Nils

Ça ne me pose pas de problème pour le moment, surtout que je n'utilise pas souvent la touche Fin. Mais cela me forcera à trouver un moyen plus élégant et à écrire un autre billet :)

Utilisation de nombreux domU en backend fichiers sur un dom0 NetBSD

2011-06-30T14:35:00+02:00

Oui, j'utilise des machines virtuelles Xen dans des fichiers. Pas de partition, pas de LVM, non. Un bon vieux fichier qu'on peut effacer sans regrets une fois son domU "jetable" inutile. Pour utiliser ces fichiers, et pour monter des fichiers en tant que disque de manière générale, NetBSD utilise le pilote vnd (4). Et par défaut, il y a 4 fichiers spéciaux vnd. Et lorsqu'on désire lancer 42 machines virtuelles en même temps, chacune ayant besoin d'un fichier vnd pour monter son disque dur, on obient une erreur du genre :

Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working.

Alors on s'affole, on copie-colle le message dans un moteur de recherche bien connu, et on tombe sur ce genre de chose :

How much /dev/vnd*d device do you have ? Maube you need to create more ?e.g.:cd /dev./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8

Donc on applique :

root@arreat:/usr/pkg/etc/xen# cd /dev
root@arreat:/dev# ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8 vnd9 vnd10 vnd11 vnd12 vnd14 vnd15
root@arreat:/dev# cd /usr/pkg/etc/xen
root@arreat:/usr/pkg/etc/xen# xm create vmjetable1 && xm create vmkikoo2 \\
&& xm create vmpipeau3 && xm create vmdelire4 && xm create encoreunevmjetable

Maintenant, c'est la RAM qui va commencer à manquer... mais c'est un autre problème ;-)

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

2011-06-20T09:30:00+02:00

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

Configuration d'une redondance DNS

2011-05-02T09:30:00+02:00

Je suis dans la situation suivante : j'ai une machine exécutant entre autres un serveur DHCP et un serveur DNS, et je souhaite réinstaller cette machine. Problème, si je la réinstalle, le DHCP et le DNS seront indisponibles. Il me faut donc redonder ces deux services pour ne pas perturber les autres machines. Après la redondance DHCP, ce billet aborde la redondance DNS. Ce billet, comme le précédent, n'aborde pas la configuration complète d'un serveur DNS mais détaille les options de configurations liées à la redondance

Une redondance basique dans un LAN est très facile à mettre en œuvre car il n'y a pas besoin de modifier quoi que ce soit chez un registrar. Il faudra cependant ajouter l'adresse IP du second serveur DNS dans la configuration de toutes les machines ayant une adresse IP statique, car celles-ci ne récupèrent pas la liste des serveurs DNS via DHCP. Une redondance DNS se compose généralement d'au moins deux serveurs : un serveur maître et un ou plusieurs serveurs esclaves. Toutes nos futures modifications dans le DNS s'effectueront sur le serveur maître et seront répliquées automatiquement vers le serveur esclave. Dans notre cas, le serveur maître utilise NetBSD 4.0 et le serveur esclave utilise NetBSD 5.1; dans les deux cas, ISC Bind est utilisé dans sa version embarquée avec l'OS, et configuré dans un chroot.

Sur notre serveur maître, configurons nos zones dans le fichier /var/chroot/named/etc/named.conf :

zone "anotherhomepage.loc" IN {
        type master;
        file "anotherhomepage.loc";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

zone "37.13.10.in-addr.arpa" IN {
        type master;
        file "anotherhomepage.loc.reverse";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

Remarquons que nous autorisons le transfert vers 10.13.37.11 qui est le serveur esclave. Continuons dans le fichier de zone anotherhomepage.loc dont voici quelques extraits :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601 ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)

; Name servers
anotherhomepage.loc.    IN      NS     ns0
anotherhomepage.loc.    IN      NS     ns1
; Mail servers
anotherhomepage.loc.    IN      MX      10      mail
; "A" entries
ns0                  IN      A       10.13.37.10
ns1                  IN      A       10.13.37.11
mail                 IN      A       10.13.37.12

Notre serveur esclave est donc renseigné pour le DNS, voyons voir dans le DNS inverse, fichier de zone anotherhomepage.loc.reverse :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601  ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)
        IN      NS      ns0.anotherhomepage.loc.
        IN      NS      ns1.anotherhomepage.loc.
        IN      MX      10      mail.anotherhomepage.loc.
10      IN      PTR     ns0.anotherhomepage.loc.
11      IN      PTR     ns1.anotherhomepage.loc.
12      IN      PTR     mail.anotherhomepage.loc.

Occupons-nous à présent de notre serveur esclave. De ce côté, un seul fichier à modifier, /var/chroot/named/etc/named.conf, car les autres seront transférés par les mises à jour de zone :

zone "anotherhomepage.loc" IN {
        type slave;
        masters { 10.13.37.5; };
        file "anotherhomepage.loc";
        allow-update { 10.13.37.5; };
        allow-query { any; };
        allow-notify { 10.13.37.5; };
};

zone "37.13.10.in-addr.arpa" IN {
        type slave;
        masters { 10.13.37.10; };
        file "anotherhomepage.loc.reverse";
        allow-update { 10.13.37.10; };
        allow-query { any; };
        allow-notify { 10.13.37.10; };
};

Il ne reste maintenant qu'à vérifier notre configuration. Par défaut, les logs vont dans /var/log/messages. Vous pouvez définir un autre emplacement pour les logs, comme par exemple :

logging {
        channel simple_log {
                file "/var/log/named/bind.log" ;
                severity info;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
        category default{
                simple_log;
        };
        category queries{
                simple_log;
        };
};

Cet exemple est à insérer dans votre named.conf.Incrémentons les numéros de série, effectuons une relance de bind sur le serveur esclave puis le serveur maître :

root@ns0:/var/chroot/named/var# /etc/rc.d/named reload
Reloading named config files.

Regardons le résultat sur le serveur esclave pour la relance du serveur maître :

root@ns1:/var/chroot/named/etc# tail -f /var/chroot/named/var/log/named/bind.log
26-Apr-2011 19:14:10.864 notify: info: client 10.13.37.5#64893: received notify for zone '37.13.10.in-addr.arpa'
26-Apr-2011 19:14:10.923 general: info: zone 37.13.10.in-addr.arpa/IN: Transfer started.
26-Apr-2011 19:14:10.924 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: connected using 10.13.37.60#65525
26-Apr-2011 19:14:11.335 general: info: zone 37.13.10.in-addr.arpa/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.336 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 258 records, 8672 bytes, 0.411 secs (21099 bytes/sec)
27-Apr-2011 19:14:11.337 notify: info: zone 37.13.10.in-addr.arpa/IN: sending notifies (serial 2011042601)
26-Apr-2011 19:14:11.383 notify: info: client 10.13.37.5#64893: received notify for zone 'anotherhomepage.loc'
26-Apr-2011 19:14:11.388 general: info: zone anotherhomepage.loc/IN: Transfer started.
26-Apr-2011 19:14:11.390 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: connected using 10.13.37.60#65524
26-Apr-2011 19:14:11.654 general: info: zone anotherhomepage.loc/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.654 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 268 records, 8464 bytes, 0.263 secs (32182 bytes/sec)
26-Apr-2011 19:14:11.657 notify: info: zone anotherhomepage.loc/IN: sending notifies (serial 2011042601)

Houra ! Les transferts ont eu lieu ! Maintenant, il reste à modifier dans notre serveur DHCP les adresses IP des serveurs DNS. Dans le cas d'ISC DHCP :

option domain-name-servers 10.13.37.10, 10.13.37.11;

Notez que ce billet permet une redondance assez basique, et loin d'être totalement sécurisée : quelqu'un d'assez malin peut, en utilisant une attaque de type “Man-in-the-middle” peut appliquer des modifications au serveur esclave. Pour les personnes qui aimeraient corriger ce défaut, il faut se tourner vers DNSSEC.

Configuration d'une redondance DHCP

2011-04-25T09:30:00+02:00

Ce billet est basé sur l'excellent billet de Paul Heinlein et publié avec son aimable autorisation. Le billet original se trouve ici.

Commençons par jeter un oeil à la configuration actuelle du serveur DHCP, elle ressemble un peu à ceci :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

On y trouve un pool, un groupe et une machine dans ce groupe avec une adresse IP fixée grâce à son adresse MAC : n'importe quelle machine se verra attribuer une adresse entre 10.13.37.200 et 10.13.37.249, mais la machine dont l'adresse MAC est 08:00:27:d3:8f:2d se verra attribuer l'IP 10.13.37.199.

Que se passe-t-il si je stoppe le serveur DHCP ? Les clients n'ont plus d'IP, donc plus d'accès au réseau, ce qui peut s'avérer gênant. Recopions la configuration sur l'autre serveur puis modifions celle-ci, qui va maintenant ressembler à ça :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        primary; # declare this to be the primary server
        address 10.13.37.5;
        port 647;
        peer address 10.13.37.60;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

Maintenant notre machine est serveur primaire DHCP et communique avec le serveur désigné après peer address. Allons d'ailleurs voir la nouvelle configuration du serveur secondaire :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        secondary; # declare this to be the secondary server
        address 10.13.37.60;
        port 647;
        peer address 10.13.37.5;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

A noter que si vous utilisez un pare-feu sur vos machines, il faudra autoriser les ports 647/tcp et 647/udp qui permettent la communication entre les deux serveurs.

Que se passe-t-il au démarrage et arrêt des serveurs ?

Exemple dans les logs du serveur primaire, après ajout de la configuration, le serveur dhcp primaire est nommé master-dhcp et le secondaire slave-dhcp :

Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 53 leases to leases file.
Apr 20 22:28:31 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to startup
Apr 20 22:28:45 master-dhcp dhcpd: failover peer dhcp-failover: I move from startup to communications-interrupted

Démarrons maintenant DHCPD sur le serveur secondaire, et voyons le résultat sur le serveur primaire :

Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:30:29 master-dhcp dhcpd: pool 80c3200 192.168.6/24 total 50  free 26  backup 24  lts -1

Et regardons les logs du serveur secondaire :

Apr 20 22:30:28 slave-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 50 leases to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to startup
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to communications-interrupted
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from startup to normal
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from communications-interrupted to normal
Apr 20 22:30:29 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Si je stoppe le serveur primaire, on le voit dans les logs du serveur secondaire :

Apr 20 22:32:08 slave-dhcp dhcpd: peer dhcp-failover: disconnected
Apr 20 22:32:08 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to communications-interrupted

Et le redémarrage est aussi visible :

Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:32:40 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Pour finir, cette configuration n'est possible que si les deux serveurs DHCP ont la même version d'ISC DHCP. Heureusement (?), de NetBSD 4.0 jusqu'à NetBSD 5.1 inclus, ISC DHCP est toujours en version 3.0.3 ;-)

Effectuer une netinstall de NetBSD 5

2011-04-18T09:30:00+02:00

J'avais déjà rédigé un petit tip pour NetBSDfr, mais cette fois-ci je suis allé un peu plus loin : J'ai documenté l'installation par le réseau, incluant un démarrage PXE de NetBSD 5, pour i386 et amd64. Et c'est sur le wiki NetBSDfr que ça se passe.

Faites chauffer les cartes réseau …

configuration basique pour bozohttpd

2011-04-04T09:30:00+02:00

NetBSD possède dans ses sets de base quelques logiciels intéressants pour un serveur : un serveur SSH, un serveur DNS, un serveur DHCP, même un serveur TFTP et celui qui m'intéresse plus particulièrement aujourd'hui, un serveur HTTP. Il ne s'agit pas, comme on pourrait s'y attendre, d'Apache HTTP Server, mais de bozohttpd, un serveur web peu connu mais particulièrement léger et à la configuration minimaliste, pour peu que le besoin le soit aussi. D'ailleurs c'est très simple, mon besoin est on ne peut plus simple : je désire créer un miroir local de distributions Linux et NetBSD et je ne souhaite pas y passer des heures à configurer un virtualhost. Autre avantage de bozohttpd dans ce cas précis, comme il est installé par défaut dans le système de base, pas besoin de l'installer. Ca fera toujours un paquet de moins à maintenir.

Une fois passée l'extase du "pas besoin de l'installer, c'est déjà fait", on se met à la recherche d'un fichier de configuration. Après la frustration d'être rentré bredouille, la page d'accueil du logiciel explique très simplement que "it has no configuration file by design". Il faut donc le configurer en le lançant avec différentes options. Un petit grep bien senti permet de voir comment ça va se passer :

root@arreat:~# grep -i http /etc/defaults/rc.conf 
httpd=NO                httpd_flags=""
                        httpd_wwwdir="/var/www"
                        httpd_wwwuser="_httpd"

Il suffit donc de positionner les options dans la directive "httpd_flags" de son rc.conf, et éventuellement de changer "httpd_wwwdir" selon l'emplacement de ses fichiers.D'abord, copions ces options dans notre rc.conf :

root@arreat:~# grep -i http /etc/defaults/rc.conf >> /etc/rc.conf

Ensuite, pour pouvoir lancer bozohttpd, on édite /etc/rc.conf et on passe httpd=NO à httpd=YES. Une fois l'édition terminée, on lance le serveur :

root@arreat:~# /etc/rc.d/httpd start

Par défaut, bozohttpd cherche un fichier index.html dans "httpd_wwwdir", et affiche son numéro de version. Paranoïa oblige, je souhaite enlever le numéro de version, et comme je veux juste mettre à disposition un miroir local de logiciels, je me fiche qu'il n'y ait pas d'index dans les répertoires. Et pour finir, je change le répertoire de base :

httpd=YES
httpd_flags="-X -S 'AHP Intranet'"
httpd_wwwdir="/srv/www"
httpd_wwwuser="_httpd"

L'option "-X" active le “directory indexing”, en clair, le listage des fichiers. L'option "-S" suivie d'une chaîne de caractère permet de substituer le nom réel du serveur à un nom personnalisé, ici "AHP Intranet". Une fois le service httpd relancé, j'obtiens ma liste de fichiers :-)

En bref, je n'ai pas eu à passer deux heures à configurer un virtual host, ni à retirer des modules, à tuner le nombre de processus. 10 minutes montre en main. Et pour plus d'options, la documentation peut être accédée via “man 8 httpd” ou sur le site de bozohttpd.

Logrotate dans pkgsrc : ça marche chez toi ?

2011-02-09T09:30:00+01:00

Il y a quelques mois maintenant, je me suis inscrit au projet pkgsrc-wip chez Sourceforge, dans le but de mettre à jour Logrotate. Le résultat est maintenant utilisable : il y a un makefile et des patches, tout ça compile sans accrocs sous NetBSD 5.0.2 et 5.1 (en amd64 du moins), bref de mon côté c'est au poil :)

Je n'ai pas forcément testé intensivement le paquet binaire, donc je lance ce léger appel à tests, si jamais ça intéresse quelqu'un. Comme Le CVS de pkgsrc-wip est actuellement indisponible, vous pouvez télécharger le Makefile et les patches dans une archive ici. Compilez, faites tourner les logs, merci d'avance !

Transfert de fichier simple et sécurisé : sftp en chroot

2009-10-04T09:33:00+02:00

Meurs, FTP, meurs !

C'est quoi ton problème ?

Comme beaucoup de gens, pour transférer des fichiers sur un serveur web, j'utilise souvent FTP. Ce protocole possède plusieurs inconvénients :

il faut ouvrir plusieurs ports dans le pare-feu, au moins deux (connexion de contrôle et de données)
le mot de passe transite en clair sur le réseau, et même si on utilise FTPS, qui chiffre la partie authentification, tous les clients et serveurs ne le supportent pas ou de manière boguée (voir chez FileZilla pour une explication)
les données transitent en clair (mince, le fichier config.php de mon appli avec les codes d'accès à la base de données...)
gestion du NAT catastrophique (du moins avec Vsftpd)

Du coup, je cherche depuis plusieurs mois à éradiquer FTP de mes machines. Ce qui m'intéresse, c'est de pouvoir enfermer les utilisateurs dans une cage, de sorte qu'ils n'aient accès qu'à leurs données et pas à celles des autres, encore moins les autres fichiers et répertoires du serveurs. On appelle ceci un chroot. Je faisais déjà ceci avec Vsftpd, j'espérais donc le faire avec la solution de remplacement. D'ailleurs, cette solution de remplacement était déjà toute trouvée : je désirais utiliser le serveur SFTP contenu dans le très bon logiciel OpenSSH. Maintenant, il me fallait réussir à créer des utilisateurs en leur empêchant d'avoir accès au shell, et en les confinant dans un chroot.

Et t'as quoi comme solution ?

Pour enlever l'accès au shell, très facile : tout système Unix qui se respecte possède soit un exécutable nommé false, soit un autre nommé nologin. D'ailleurs ce dernier est très simpliste, regardons sur, au hasard, un système NetBSD 5.0.1 :

nils@tomb:~ $cat /sbin/nologin 
#! /bin/sh
echo "This account is currently not available."
exit 1

Il suffit donc de remplacer le shell de l'utilisateur par le chemin vers nologin, et cette question est résolue.

Pour créer et maintenir un chroot, c'est une autre paire de manches. Dans Vsftpd c'était assez simple, et j'espérais trouver aussi simple. De nombreuses pages sur Scponly ou rssh expliquent comment faire un chroot pour un utilisateur n'ayant accès qu'à sftp ou scp, mais le jour où il faut mettre à jour l'OS, voire le migrer vers une version majeure plus récente (ou pourquoi pas en changer, comme passer d'un Linux à un BSD ou inversement, ou tout simplement changer de distribution Linux), le chroot doit être maintenu à jour. Et ça, je trouve que c'est totalement contre-productif, en tous cas du point de vue du sysadmin fainéant que nous avons tous en nous ;)

Et là, la lumière est arrivée, par ici. Depuis la version 4.8, OpenSSH permet de créer des chroot, et n'oblige pas à recréer tout un environnement quand il s'agit de sftp. Exactement ce dont j'ai besoin ! Maintenant, reste à savoir quels systèmes disposent d'au moins OpenSSH 4.8.

Une petite liste non-exhaustive des systèmes chanceux :

NetBSD 5.0.1
FreeBSD 7.2
Debian Lenny
Mac OS 10.5.8

Une autre liste, mais de systèmes moins chanceux :

CentOS 3,4,5.X
RHEL 3,4,5.X
Debian Etch

Si votre système unix libre (ou pas, d'ailleurs, puisque j'ai listé Mac OS X) comporte OpenSSH, vous pouvez vérifier sa version par :

nils@darkmoon:~ $ssh -V
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006

(exemple pris sur un mac) En utilisant sshd au lieu de ssh, ça sera sans doute plus représentatif, mais l'option -V n'existe pas sur le serveur. La réponse retournée donnera quand même la version. Exemple, toujours sur le même mac :

nils@darkmoon:~ $sshd -V
sshd: illegal option -- V
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-f config_file]
            [-g login_grace_time] [-h host_key_file] [-k key_gen_time]
            [-o option] [-p port] [-u len]

Si votre système ne possède pas un OpenSSH assez récent, plusieurs possibilités s'offrent à nous :

changer de système
mettre à jour vers la dernière version majeure si celle-ci possède une version assez récente
installer sa propre version d'OpenSSH ou récupérer le paquet qu'aurait fait quelqu'un de généreux

La dernière solution est assez documentée pour CentOS et RHEL, pour faire ses propres RPM, mais j'ai décidé de ne pas la suivre, car cela pose le problème des mises à jour : de la même manière que maintenir un chroot ne me satisfait pas, passer mon temps à guetter les nouvelles versions d'OpenSSH pour compiler un paquet ne me plait pas plus. La deuxième solution s'avère sans doute la moins gênante selon les applications en production. De mon côté, j'ai choisi la première : migration de serveur dédié oblige, j'en ai profité pour élargir mes horizons dans le monde des unix libres et depuis quelques mois, ce blog tourne sous NetBSD. C'est donc avec cet OS que je vais décrire la manipulation de création de chroot.

On passe à l'action ?

Je pars du principe dorénavant que nous avons un système avec un OpenSSH 4.8 ou supérieur, que le serveur sshd est activé, que nous avons deux utilisateurs : root, et notre utilisateur habituel avec lequel nous faisons tout ce qui n'a pas besoin d'être fait en root. Le but est d'avoir un ou plusieurs utilisateurs supplémentaires, enfermés dans un répertoire défini, sans shell, et pouvant accéder à ce réperoire en sftp. On pourra, en supplément, faire en sorte que l'utilisateur accède à son compte sftp avec une clé (et éventuellement une phrase de passe) plutôt qu'un mot de passe.

Cela va se faire en modifiant dans un premier temps le fichier de configuration /etc/ssh/sshd_config (en tant que root, et le chemin peut varier selon le système). Cherchons la ligne contenant sftp-server, pour NetBSD elle ressemble à ceci :

Subsystem      sftp    /usr/libexec/sftp-server

On constate que le serveur sftp est un programme externe. Nous allons le remplacer par le sous-système sftp de sshd :

Subsystem       sftp    internal-sftp

J'ai donc remplacé /usr/libexec/sftp-server par internal-sftp. Allons ensuite à la fin du fichier, et ajoutons les directives suivantes :

Match Group wwwusers
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no

Cela signifie que pour les utilisateurs du groupe wwwusers, je les emprisonne dans leur répertoire home, je les oblige à utiliser le sftp interne, et je les empêche d'utiliser les différentes techniques de forwarding habituellement à disposition avec sshd. j'aurais pu les chrooter ailleurs, d'autres sites indiquent par exemple /chroot/%u, où %u désigne le nom de l'utilisateur. Une fois ces modifications effectuées, il ne reste qu'à redémarrer le serveur ssh et à créer le groupe et les utilisateurs.

Petit aparté concernant NetBSD 5.01 : j'ai remarqué un bug sur cette version, qui doit aussi être présent dans la 5.0; il ne faut surtout rien ajouter au fichier de configuration /etc/ssh/sshd_config après cette directive, pas même un commentaire ! Si cela venait à arriver, la directive que nous venons d'ajouter serait tout simplement ignorée.

Créons le groupe :

root@vhost:~ #groupadd wwwusers

Créons ensuite un utilisateur nommé test :

root@vhost:~ #useradd -m -g wwwusers -s /sbin/nologin test

Attribuons un mot de passe à cet utilisateur :

root@vhost:~ #passwd test
Changing password for test.
New Password:
Retype New Password:

(le mot de passe est tapé en aveugle, bien entendu). Ensuite, assurons-nous que le répertoire home de l'utilisateur appartient non pas à l'utilisateur mais à root, avec des permissions en 755. Si ce n'est pas le cas, on y remédie de cette manière :

root@vhost:~ #chown root:wheel /home/test
root@vhost:~ #chmod 755 /home/test

On notera que pour les OS Linux, on indique root:root par rapport à NetBSD qui n'a pas de groupe root mais un groupe wheel. A ne pas oublier aussi, seul /home/test appartient à root, pas les fichiers et répertoires à l'intérieur (i.e. pas de chmod/chown -R)

Depuis une autre machine, vérifions que nous pouvons nous connecter en sftp :

sftp test@vhost
Connecting to vhost...
Password:
sftp> ls
sftp> pwd
Remote working directory: /

Ici, on remarque que je me suis déjà connecté à cette machine avant, puisqu'on ne me réclame pas d'accepter de clé. On remarque aussi qu'on est directement dans le répertoire / et qu'il n'y a rien, la commande pwd indique / et pas /home/test. Si on crée dans ce répertoire un deuxième /home/test, sftp nous y emmènera directement dedans. De plus, on note qu'on ne peut pas créer ou ajouter de répertoire/fichier (normal, le répertoire appartient à root). Créons donc, sur le serveur, le second “home” de l'utilisateur :

root@vhost:~ #cd /home/test
root@vhost:/home/test # mkdir -p home/test
root@vhost:/home/test # chown -R test:wwwusers home
root@vhost:/home/test # chmod 755 home

Reconnectons-nous à notre serveur sftp :

sftp test@vhost
Connecting to vhost...
Password:
sftp> ls
sftp> pwd
Remote working directory: /home/test/

Je peux maintenant créer des répertoires, envoyer des fichiers, en rapatrier d'autres. Mission accomplie !