Vendredi 17, j’ai décidé de faire la mise à jour de OpenBSD 5.6 à 5.7. Si certains n’ont pu se connecter à mon site web ce soir là, c’était pour ça !

J’écris cet article comme aide-mémoire, et choses à prévoir pour la prochaine fois. Peut-être que je trouverais des solutions pour rendre le processus plus efficace.

Préliminaire

En guise de préliminaire, je redéfini un mot de passe root. En effet, plutôt que de me connecter avec le compte root, je fais une utilisation importante de sudo pour les tâches administratives. Hors durant l’upgrade, sudo ne va pas répondre !

Donc on refait un mot de passe. Après l’upgrade, on retourne à la situation normale, c’est à dire un mot de passe root au hasard tellement long qu’il est impossible à utiliser.

J’ai bien sûr jeté un coup d’œil sur la page dédiée à l’upgrade du site d’OpenBSD. Pas l’air bien méchant.

J’ai téléchargé le noyau de secours bsd.rd et vérifié son empreinte sha.

Bon on se lance… La mort dans l’âme, je reboote la machine à 210 jours d’uptime.

Premier écueil

On boote sur bsd.rd et le script me demande se que je veux faire. Upgrade.

Et là, c’est le drame ! La machine cherche à se connecter à internet pour récupérer les programmes, mais il n’y a pas d’internet !

En effet, le serveur est d’ordinaire en ip fixe et résout lui-même les noms de domaines. Hors il est là en mode fonctionnement basique. Il n’a donc pas encore d’adresse ip, il ne faut d’ailleurs pas en attendre du DHCP ou de radvd puisque c’est lui le DHCP et le radvd d’ailleurs !

Donc, on reboote, on demande le shell pour mettre tout à la main, ip et route !

ifconfig re0 192.168.40.23
route add default 192.168.40.1

Pour ce qui est de la résolution de noms :

echo nameserver 8.8.8.8 > /etc/resolv.conf

Puis on lance la commande upgrade. Et là, deuxième problème ! Lorsqu’on commence l’upgrade, les disques sont montés, donc la machine récupère ses paramètres nominaux, qui sont précisément:

nameserver ::1

Donc en fait, ce que j’ai fait, c’est que j’ai indiqué l’ip du serveur ftp.OpenBSD.dk en lieu et place de son nom d’hôte réseau. Le téléchargement et l’installation s’est alors poursuivi sans soucis.

httpd

Lorsque je veux commencer à utiliser httpd, nouveau soucis ! Le binaire se plante méchamment avec un beau Core dump.

Durant quelques heures, le site a donc tourné sous Nginx en attendant de pouvoir régler le problème.

Je récupère les sources via cvs, ça compile, aucun soucis. Sauf que lorsque je lance le binaire, ça continue de planter. Impossible de savoir où est mon erreur.

Finalement, je récupère les sources de httpd via github, je compile, j’installe, je lance. Aucun soucis.

Reste plus qu’à configurer. Pour ça, on regarde toute la conf de Nginx, et on reproduit tout, en particulier les redirections. Au passage, je perds une fonctionnalité: la redirection par défaut au niveau supérieur en cas d’échec de l’URL présente (conf’ Nginx):

# faillite du nom de l'article
location ~* ^/([0-9]+)/([0-9]+)/([0-9]+)/(.+)/$ {
    try_files $uri $uri/ /$1/$2/$3/;
    }

Ça va, je pense qu’on peut survivre sans ça.

Voici l’état du fichier httpd.conf. Je vous rassure, ça m’a pris quand même un peu plus de trois heures à faire.

server "www.22decembre.eu" {
	alias "22decembre.eu"

	listen on egress        port 80
	include "/etc/httpd.tls"

	root "/pelican"

	location "/bibliotheque/" { block return 301 "http://biblib.22decembre.eu" }
	location "/biblib/"     { block return 301 "http://www.22decembre.eu/2013/12/17/softwares-projects-en/" }

	location "/drafts/*"    { directory auto index }
	location "/downloads/*" { directory auto index }

	location "*/feed/" { directory index atom.xml }

	location match "/2012/02/27/*"  { block return 301 "http://www.22decembre.eu/2015/03/31/5-sign-mail-fr/" }
}

server "piwik.22decembre.eu" {
	listen on egress        port 80
	include "/etc/httpd.tls"

	root "/piwik"
	directory index index.php
	
	location "/links" { directory index index.php }
	location "*.php" { fastcgi socket "/tmp/php.sock" }
}

server "photos.22decembre.eu" {
	listen on egress    port 80
	include "/etc/httpd.tls"

	root "/photos"
	
	location "*.php" { fastcgi socket "/tmp/php.sock" }

	location match "^/index/category/([%g]+)$" { block return 301 "/index.php?/category/%1" }
	location match "^/picture/([%d]+)/category/([%g]+)$" { block return 301 "/picture.php?/%1/category/%2" }
}

server "blackblock.22decembre.eu" {
	include "/etc/httpd.tls"

	root "/blackblock"
	directory index index.html

	location "*.php" { fastcgi socket "/tmp/php.sock" }
}

server "blackblock.22decembre.eu" {
	listen on egress        port 80
	block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

server "dansk.22decembre.eu" {
	listen on egress        port 80
	include "/etc/httpd.tls"

	root "/dansk"
}

server "biblib.22decembre.eu" {
	listen on egress        port 80
	include "/etc/httpd.tls"

	root "/biblib/app/"
	location "*" { fastcgi socket "/biblib/tmp/biblib.sock" }
}

Les «location match» indiquent les directives de réécriture des adresses, qui font donc moins môches, plus faciles à écrire et à retenir dans le cas de Piwigo. Sauf que la façon dont Piwigo fabrique ses adresses n’a pas beaucoup de sens à priori, donc c’est pas des adresses qu’on écrit à la main, mais c’est pas grave, c’est pour la beauté de la chose.

Par contre, quand on visite l’adresse en question, on voit bien la vraie adresse dans la barre d’adresse. C’est pas des blagues.

J’ai mis en commun la conf’ TLS, voici le httpd.tls :

listen on egress tls port 443

tls     key             "/etc/nginx/certs/blackblock.key"
tls     certificate     "/etc/nginx/certs/ssl-unified.crt"

Je réutilise la conf’ de Nginx pour l’instant.

Spamd

Autre nouveauté, le démon anti-spam, spamd, écoute maintenant en tls. Mais pas en ipv6.

Je passe sur mes commentaires et la façon dont je pense que tel ou telle chose devrait fonctionner. J’aime bien le message de commit du dev’, il explique tout:

add STARTTLS support, using the shiny libtls.
Rationale: when you publish DANE records for certificate pinning, you MUST
offer TLS on the indicated service. Not offering TLS is verboten since
that would re-open the door for a MitM. This is obviously fundamentally
incompatible with having spamd in front of your mailservers - spamd kinda
is a MitM here, but intentional and utterly valid.
DANE is desirable because it allows one to not have to trust the broken
SSL CA model, and, depending on the mode chosen, even show the SSL cert
mafia the middle finger by not needing them at all.
ok reyk jsing bob

Autrement dit, on commence par demander une connection tls si le serveur MX a un enregistrement TLSA. Si la connection tls échoue, on va pas plus loin. Maintenant donc, on a un démon spamd qui écoute en tls. Ce qui signifie que le processus de greylisting pourra se faire jusqu’au bout:

  1. spamd reçoit une première demande de connection, en STARTTLS ou pas.
  2. il indique au demandeur de revenir plus tard.
  3. au bout de X temps, le demandeur est marqué comme un client sérieux et pas un spammeur.
  4. son courrier est alors accepté
  5. tant que le client envoie du courrier de manière régulière, ça passe, sans greylisting.

De ce que je comprends, le code d’OpenBSD est organisé avec une forte abstraction (j’ai lu deux ou trois articles/documents là dessus. Impossible de retrouver l’adresse).
Les instructions sont de toujours utiliser la fonction la plus générique possible, ou de plus haut niveau, précisément pour faciliter ce genre de choses (connectivité ipv6, mise à jour de fonctions systèmes…). Ajouter le support ipv6 aurait donc dû être enfantin, en même temps que STARTTLS.

Mais bon, c’était mon commentaire. Je suppose qu’il révèle seulement mon peu de compétences dans le sujet en question. Je remercie les dev’ d’OpenBSD pour avoir ajouté la connection STARTTLS sur spamd.

Ça me permet de publier un enregistrement TLSA pour mon serveur de courrier, ce qui est tout bon car Postfix reconnaît DANE, on peut donc mieux sécuriser son courrier.

À propos… Il faut bien prendre le même certificat TLS que celui du vrai serveur de courrier (smtpd). Bah oui, c’est ce certificat que vous publiez comme TLSA. Donc c’est celui que vous devez utilisez avec spamd aussi !

DKIMproxy fait des siennes

J’ai un proxy DKIM pour signer le courrier (j’ai utilisé ce How-to pour la procédure d’installation et de configuration). Ceci permet concrètement que mon mail soit validé par Google & co.

C’est assez mal fichu, en effet, comme le signale si bien l’ami Bortz, les règles de validation ou non du courrier sont pour le moins … absconces. Donc, moi je ne filtre pas en fonction de DKIM. Par contre je veux que mon courrier arrive chez Google & co, donc il faut que je le signe pour cela !

Con mais on y peut rien !

Lors de cette grosse mise à niveau, le signeur plante. Comme ça, l’air de rien.

Je passe tout en revue, X modules Perl, l’occasion de découvrir quelques autres commandes, comme cpanm qui permet de désinstaller des modules Perl.

J’installe, je réinstalle des modules. Apparemment ça s’avère un poil positif. N’empêche, j’ai toujours cette erreur (dkimproxy lancé à la mano) :

root@blackblock:~:#  /usr/local/bin/dkimproxy.out --conf_file=/etc/dkimproxy_out.conf --user=_dkimproxy --group=_dkimproxy 
2015/07/19-19:23:03 main (type Net::Server::PreFork -> MultiType -> Net::Server::PreFork) starting! pid(10213)
Resolved [localhost]:10022 to [127.0.0.1]:10022, IPv4
Binding to TCP port 10022 on host 127.0.0.1 with IPv4
Setting gid to "721 721"
Setting uid to "721"
dkimproxy.out[11864]: connect from 127.0.0.1
Can't locate object method "new" via package "IO::Socket::INET6" at /usr/local/libdata/perl5/site_perl/MSDW/SMTP/Client.pm line 109.

Bon, bah je vais voir en direct dans le fichier Client.pm là, à l’extrémité de la ligne. Il est bien fait appel à une méthode new du module INET6. Tiens, si j’enlevais juste le 6, pour utiliser INET ?

Bingo !

C’est dingue ce qu’un tout petit caractère de rien du tout peut changer !

Bon en même temps, dkimproxy ne fonctionne pas en ipv6. Donc pourquoi utiliser le module INET6 ? Mais bon, c’est résolu !

C’est tout pour l’instant.

Mais il y aura du neuf très prochainement !