On friday the 17th, I decided to upgrade to OpenBSD 5.7. If some of you could not reach my website this day, it was because of it !

This article (the French version of course) is a reminder to the next time, in hope I could find better ways around problems.

Foreplay

I first create a new root password. Because I use sudo a lot rather than using the root account. During upgrade, sudo won’t be available. So instead, create a fake password for root. After upgrade, return to the previous situation: a huge long unusable password !

I obviously had a look at the upgrade page for 5.7. Looks fine.

Let’s download the bsd.rd and check sha fingerprint.

Let’s go ! Take a deep breath, and reboot the machine at 210 days uptime.

First one !

Boot on bsd.rd. The script asks me what I want to do. Upgrade.

And… Here it is ! The machine want to get to the internet, but there is no internet !

The server is usually in fixed ip and resolve itself domain names. But it is now in low grade run. It does not have ip, and won’t get one automatically, as it is also the usual DHCP and radvd !

Everything has to be done by hand. So, reboot, ask for shell, and…

ifconfig re0 192.168.40.23
route add default 192.168.40.1

For DNS resolution :

echo nameserver 8.8.8.8 > /etc/resolv.conf

Second problem: when you are OK, you can ping Google and the rest of the world, so you hit the upgrade command, the process begin again, disks are mounted and the machine gets again its usual running conf’, which is:

nameserver ::1

So, what I did was simply to set the ip of ftp.OpenBSD.dk server instead of its full hostname. Downloading and installation continued like a charm.

httpd

When I began to use httpd, new problem. The soft crash with a simple Core dump.

The website turned on Nginx for a couple of hours, time to set the problem down.

I fetch the sources with cvs, compile. But then again, crash. I don’t know what’s my fail.

So I fetch the very last sources with github, compile and install. It runs.

Just need to set it up. To do that, I have gone through all Nginx conf’ and reproduce the relevant stuff, particularly redirections. And I lost some feature: default redirection to the upper level in case the current URL fails (conf’ Nginx):

location ~* ^/([0-9]+)/([0-9]+)/([0-9]+)/(.+)/$ {
    try_files $uri $uri/ /$1/$2/$3/;
    }

I think I can live with that.

Here is the state of httpd.conf file. Just to make you feel comfortable, it took me a couple of hours, not just five minutes.

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" }
}

«Location match» set the redirections. The addresses look a bit less ugly, easier to write and remind. Except that Piwigo makes its addresses in a weird way that does not make much sense. So no one will type them by hand. But ok, it was just for the beauty of it.

But when visiting the address, we see the actual one in the URL bar of the browser. Not a joke !

I set the TLS conf’ commonly:

listen on egress tls port 443

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

I reuse the Nginx conf’ as of now. Will change pretty soon.

Spamd

Some other new thing, the spamd daemon now listen to TLS. But not to ipv6.

I won’t tell everything I think about the way the Universe should run. But I like the commit message, it explains it well:

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

So it begins by requesting a tls connection if the server has a TLSA record. If the connection fails, stop there. Now that we have a tls listening spamd, the greylisting process can go to its end:

  1. spamd receives a connection request, STARTTLS or not.
  2. it asks the requester to come back later.
  3. when coming back, the requester is flagged as a serious client rather than a spammer.
  4. its mail is eventually accepted.
  5. The flagging remains as long as the clients send regular and proper mails (weeks, months… no greylistings this times).

What I understand of OpenBSD’s code is that it is organized in a highly abstract way. I read a few documents about it. Impossible to find them again. It is said to always use the highest or the most generic function, precisely to make this easier (ipv6 connectivity, upgrade of system’s functions…) Add ipv6 should have been as easy as STARTTLS.

I suppose this last comment just show how much I know about that ! Anyway, thanks to the dev’ for adding STARTTLS to spamd.

I can now publish a TLSA record. Postfix begin to recognize it, meaning we can secure mail better.

By the way… You have to use the same TLS certificate that the one used in the true smptd server. Because it is this one you will use as TLSA.

DKIMproxy

I have a DKIM proxy to sign mail (I used this How-to for setup procedure). This allows my mail to pass Google & co. It is utterly bad designed. So I don’t filter my incoming mail with DKIM. But I want it validated by Google. So it has to be DKIM signed.

During this big all-in-one upgrade, the DKIM signer crash.

I go through the whole debugging process, where I learn a few more useful commands, like cpanm which allows to uninstall Perl modules.

I install, uninstall modules. It does a few good. But I still have this error (dkimproxy launched manually):

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.

So, let’s have a look to this Client.pm, there, at the end of line. A new method of module INET6 is indeed called. What if I just erase the 6 to use INET module ?

Bingo !

Amazing what a single character can change !

Same time, dkimproxy does not work on ipv6. So why using INET6 ?

That’s all folks.

But there will be good news soon. Stay tuned !