4 avr. 2017

curl : utiliser une version plus récente sur macOS

Le système macOS dispose en standard de curl. Mais ce binaire n'est pas forcément dans une version assez récente, ou alors certaines options ne sont pas compilées.

Installation de curl par pkgin

Nous allons, grâce à pkgsrc, installer une autre version, sans toucher à celle installée par défaut. Pour cela, le prérequis est de suivre mon tutoriel pour installer pkgsrc. Une fois que c'est fait, une commande suffit :

sudo pkgin in curl

Comme vu dans les billets précédents, installer un logiciel grâce à pkgin est très simple. En plus, si la variable d'environnement $PATH définit l'emplacement des programmes issus de pkgsrc avant ceux du système, la prochaine invocation de curl dans le terminal sera celle que nous venons d'installer.

Mais il se peut qu'on ait besoin de plus : par exemple, ajouter ou retirer des options de compilation. Passons donc à une autre méthode d'installation, via les sources.

Installation de curl par compilation des sources

Tout d'abord, comparons les versions et les options de compilation :

nils@dalaran-wifi:~$ /usr/bin/curl -V
curl 7.51.0 (x86_64-apple-darwin16.0) libcurl/7.51.0 SecureTransport zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets
nils@dalaran-wifi:~$ /opt/pkg/bin/curl -V
curl 7.53.1 (x86_64-apple-darwin13) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.8 libssh2/1.8.0 nghttp2/1.20.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

Une option dont on a besoin n'est pas présente ? Ce n'est pas grave, car on peut l'ajouter. L'étape suivante consiste à lister les options disponibles :

    nils@dalaran-wifi:/opt/pkgsrc/www/curl$ bmake show-options
    Any of the following general options may be selected:
    gssapi     Enable gssapi (Kerberos V) support.
    http2     Add support for HTTP/2.
    inet6     Enable support for IPv6.
    ldap     Enable LDAP support.
    libidn     Add support for libidn text conversion.
    libssh2     Use libssh2 for SSHv2 protocol support.
    rtmp     Enable rtmp:// support using rtmpdump.

    These options are enabled by default:
    inet6 libidn

    These options are currently enabled:
    inet6 ldap libidn libssh2

    You can select which build options to use by setting PKG_DEFAULT_OPTIONS
    or PKG_OPTIONS.curl.

On peut alors éditer _/opt/pkg/etc/mk.conf.local_ (en tant que root, ou via _sudo_) et ajouter des options, comme par exemple http2 :

PKG_OPTIONS.curl+= http2

Et ensuite, on recompile :

nils@dalaran-wifi:/opt/pkgsrc/www/curl$ bmake package-install

L'étape d'après est de vérifier la présence de l'option http2 :

    nils@dalaran-wifi:/opt/pkgsrc/www/curl$ /opt/pkg/bin/curl -V
    curl 7.53.1 (x86_64-apple-darwin16) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.8 libssh2/1.8.0 nghttp2/1.20.0
    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

En conclusion, il est très simple, grâce à pkgsrc, de disposer d'une autre version de logiciel que celle installée par défaut, et de la compiler avec les options dont on a besoin.

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

28 mar. 2017

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

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 !

13 mar. 2017

dmidecode : pour en savoir un peu plus sur son matériel

De nombreux outils libres de détection et d'information sur le matériel de son ordinateur existent. En vrac, lspci, lshw, et dmidecode. J'ai un peu mis le nez dans ce dernier récemment, et j'ai remarqué quelques options intéressantes, que je partage ici.

Habituellement, dmidecode est lancé, sans argument, en tant que root. En effet, celui-ci a besoin d'accéder au matériel via le SMBIOS. Je ne copierai pas ici un exemple de sortie, car c'est assez long. On peut commencer par limiter un peu cette longueur, en utilisant l'option -q, pour quiet. La différence est assez notable, voici une comparaison (sous NetBSD, bien entendu) :

root@shell2:~# dmidecode | wc -l
     544
root@shell2:~# dmidecode -q| wc -l
     443

Près de 100 lignes de différence, concernant principalement des entrées inactives et des méta-données. Cela devrait déjà aider en lisibilité.

Ensuite, il se peut qu'on cherche une information précise sur son système. Par exemple, le nombre de modules de mémoire vive, ainsi que le nombre total de modules présents :

root@shell2:~# dmidecode -q -t memory | grep Size
        Size: 4096 MB
        Size: No Module Installed
        Size: No Module Installed
        Size: No Module Installed

J'ai donc un module de 4 Go de mémoire vive, et la machine peut en accueillir trois autres. L'option -t peut prendre d'autres valeurs, il suffit de ne pas en indiquer pour avoir la liste.

Une autre option utile est -s, par exemple si on recherche des informations sur son processeur :

root@shell2:~# dmidecode -s processor-family
Atom
root@shell2:~# dmidecode -s processor-manufacturer
Intel(R) Corporation
root@shell2:~# dmidecode -s processor-version
Intel(R) Atom(TM) CPU  C2350  @ 1.74GHz
root@shell2:~# dmidecode -s processor-frequency
1743 MHz

Cette option peut aussi prendre d'autres valeurs, et comme pour la précédente, il suffit de ne pas en indiquer pour avoir la liste.

Là où j'ai beaucoup ri, c'est quand je suis allé chercher des informations sur le système et le baseboard :

root@shell2:~# dmidecode -s system-manufacturer
Online Labs
root@shell2:~# dmidecode -s system-product-name
SR
root@shell2:~# dmidecode -s system-version
(^_^)
root@shell2:~# dmidecode -s system-serial-number
42
root@shell2:~# dmidecode -s baseboard-manufacturer
Online Labs
root@shell2:~# dmidecode -s baseboard-product-name
SR
root@shell2:~# dmidecode -s baseboard-version
42
root@shell2:~# dmidecode -s baseboard-serial-number
42
root@shell2:~# dmidecode -s baseboard-asset-tag
42

On remarque donc que le constructeur de la machine peut y mettre un peu ce qu'il veut. On reconnaît ici clairement un serveur Dédibox.

Pour plus de détails, la page de manuel reste incontournable.

Des remarques, des propositions d'améliorations ? Où même des exemples amusants sur certains systèmes particuliers ? Les commentaires sont là pour ça !

27 fév. 2017

pbulk : compilation massive de paquets pkgsrc

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.

braverthanithought.jpg

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 !

16 janv. 2017

dehydrated, un client alternatif pour Let's Encrypt

Après quelques galères avec Certbot, j'ai découvert dehydrated, un client pour Let's Encrypt écrit en Bash.

Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX MPROTECT. C'est tout du moins ce qu'indique ce rapport de bug.

N'ayant ni le temps ni les compétences pour voir ce qui bloque exactement du côté de Certbot, j'ai fait ce que pas mal d'autres ont fait : j'ai recherché une alternative. La première alternative qui a attiré mon attention est acme-client, en version portable, d'ailleurs disponible au moment où j'écris ces lignes dans pkgsrc-wip. Mais en fait celui-ci ne semble pas fonctionner sous NetBSD, me hurlant des histoires de droits et de suid bizarres.

J'ai ensuite jeté mon dévolu sur dehydrated, un client écrit en Bash. Celui-ci a l'avantage non-négligeable de fonctionner, contrairement au précédent. Je me suis donc lancé dans son empaquetage (wip/dehydrated au moment où j'écris ces lignes, mais j'espère l'importer dans pkgrsc-current dès que possible). Dehydrated est assez pratique à utiliser, il nécessite des dépendances assez classiques pour un script shell (sed, awk, curl), en plus d'OpenSSL. Bien qu'il dispose de fichiers de configuration, de nombreuses options peuvent être spécifiées sur la ligne de commandes. Dehydrated prévoit aussi des scripts "hook" pour pouvoir déclencher d'autres actions avant et après le renouvellement d'un certificat par exemple.

Le paquet est globalement fonctionnel sous NetBSD, le seul prérequis avant de se lancer dans l'édition des fichiers de configuration est d'avoir une configuration OpenSSL existante (ce qui se fait rapidement, en copiant simplement le fichier d'exemple fourni dans /usr/share/examples/openssl/), et de savoir dans quel répertoire le challenge ACME sera déposé. J'espère d'ici là avoir amélioré la prise en compte d'OpenSSL d'ailleurs (utilisation de celui de pkgsrc par exemple). Idéalement, ce serait assez cool que dehydrated puisse utiliser LibreSSL.

Il existe d'autres clients alternatifs que je n'ai pas essayés, comme getssl, mais lequel est votre préféré et pourquoi ? Le formulaire de commentaire n'attend que votre réponse !

Propulsé par Dotclear