Today I had the pleasure to move the debconf mailinglists to lists.debian.org. That means that the following mailinglists:

• debconf-announce
• debconf-discuss
• debconf-team
• debconf-video

are now hosted on lists.debian.org. Please update any documentation or bookmarks you have. Next step would be to join debconf again ;).

laser-cutter sprint So I'm overcoming my jetlag after DebConf17 by helping to make the Alioth sprint happen, and while it's good to witness work on the upcoming git.debian.org replacement, I'm rather minding my own business instead of getting involved And so I got interested in this laser cutter, which since two months has been set up in the CCCHH hackerspace and which is nicely documentend (and set up), so I managed to learn how to do my first baby steps with the laser cutter in one evening: Basically there is a hosted web application named 'LaserWeb4' for which a pre-configuration exists, so that one only needs to load an image, scale and position it and tune the laser settings a bit. The laser itself is inside a cage, which has a physical safety switch which will turn off the laser if the cage is opened. Obviously the setup is a lot more complex and there are many parameters to tune, and I basically just learned one thing, which is "printing images on wood", but "printing images on a laptop cover" should be pretty similar and something to learn in the future And now I'm even teaching weasel how to use this thing (and he already made interesting new mistakes) and it looks like Ganneff & formorer are next. Fun fun fun! Oh, and the Alioth sprint also seems to be quite productive, but I'll leave reporting about this to others.

With the release of stretch we are pleased to open the doors for stretch-backports and jessie-backports-sloppy. \o/ As usual with a new release we will change a few things for the backports service.

What to upload where As a reminder, uploads to a release-backports pocket are to be taken from release + 1, uploads to a release-backports-sloppy pocket are to be taken from release + 2. Which means:

Source Distribution	Backports Distribution	Sloppy Distribution
buster	stretch-backports	jessie-backports-sloppy
stretch	jessie-backports	-

Deprecation of LTS support for backports We started supporting backports as long as there is LTS support as an experiment. Unfortunately it didn t worked, most maintainers didn t wanted to support oldoldstable-backports (squeeze) for the lifetime of LTS. So things started to rot in squeeze and most packages didn t received updates. After long discussions we decided to deprecate LTS support for backports. From now on squeeze-backports(-sloppy) is closed and will not receive any updates. Expect it to get removed from the mirrors and moved to archive in the near future.

BSA handling We - the backports team - didn t scale well in processing BSA requests. To get things better in the future we decided to change the process a little bit. If you upload a package which fixes security problems please fill out the BSA template and create a ticket in the rt tracker (see https://backports.debian.org/Contribute/#index3h2 for details).

Stretching the rules From time to time its necessary to not follow the backports rules, like a package needs to be in testing or a version needs to be in Debian. If you think you have one of those cases, please talk to us on the list before upload the package.

Thanks Thanks have to go out to all people making backports possible, and that includes up front the backporters themself who do upload the packages, track and update them on a regular basis, but also the buildd team making the autobuilding possible and the ftp masters for creating the suites in the first place. We wish you a happy stretch :) Alex, on behalf of the Backports Team

It may look that the decision for pagure as alioth replacement is already finalized, but that s not really true. I got a lot of feedback and tips in the last weeks, those made postpone my decision. Several alternative systems were recommended to me, here are a few examples:

• gitlab
• kallithea
• gogs
• gitblit

and probably several others. I won t be able to evaluate all of those systems in advance of our sprint. That s where you come in: if you are familiar with one of those systems, or want to get familiar with them, join us on our mailing list and create a wiki page below https://wiki.debian.org/Alioth/GitNext with a review of your system. What do we need to know?

• Feature set compared to current alioth
• Feature set compared to a popular system like github
• Some implementation designs
• Some information about scaling (expect something like 15.000 > 25.000 repos)
• Support for other version control systems
• Advantages: why should we choose that system
• Disadvantages: why shouldn t we choose that system
• License
• Other interesting features
• Details about extensibility
• A really nice thing would be a working vagrant box / vagrantfile + ansible/puppet to test things

If you want to start on such a review, please announce it on the mailinglist. If you have questions, ask me on IRC, Twitter or mail. Thanks for your help!

To get some idea about the expectations and current usage of alioth I created a survey. Please take part in it if you are an alioth user. If you need some background about the coming alioth replacement I recommend to read the great lwn article written by anarcat.

As some of you already know we do need a replacement for alioth.debian.org. It is based on wheezy and a heavily modified version of Fusionforge. Unfortunately I am the last admin left for alioth and I am not really familiar with fusionforge. After some chatting with a bunch of people we decided that we should replace alioth with a stripped down version of new services. We want to start with the basic things, git and and identity provider. For git there are two candidates: gitlab and pagure. Gitlab is really nice, but has a big problem: it is Opencore, which that it is not entirely opensource. I don t think we should use software licensed under such a model for one of our core services. That brings us to the last candidate: pagure. Pagure is a nice project based on gitolite, it is developed by the fedora project which use it for all their repos. Pagure isn t packaged for Debian yet, but that is work in progress (#829046). If you can lend a helping hand to the packager, please do so. To get things started we will have a Alioth Sprint from 18th to 20th August 2017 in Hamburg, Germany. If you want to join us, add yourself to the wikipage. For further discussions I created a mailinglist on alioth. Please subscribe if you are interested in that topic.

After a long time I decided to move my blog again to something with git and markdown in the background. I decided to give hugo a chance on my uberspace account. Uberspace is a nice, geek driven hoster in germany from geeks for geeks. The blog itself is hosted on github, it pushes commits to a simple golang based webhook service based on adnanh/webhook.

Today I spend some time to go through the lists.debian.org bugreports. In consequence I created three new lists:

• debian-hpc
• debian-rtc
• debian-metadata

Key signing parties are a pain and hopefully, one day, we will have better ways to authentication keys than reading hexadecimal strings out loud. The Zimmermann Sassaman key-signing protocol makes them much more bearable already by having only one single hexadecimal string read out loud. That string is the cryptographic hash of a document given to every participant listing all participants and their fingerprints. If everyone has the same hash, then we assume that everyone has the same document. Then, participants in turn will confirm that they fully recognize the fingerprint listed in the document. Alexander Wirt wrote a small key server dedicated to receive keys from the participants. There is also a script that will generate the document from the submitted keys and a ready-to-use keyring. The latter can be run automatically using inoticoming when a new key arrives. Finally, it would be nice if participants could confirm that their key has been properly added to the document, e.g. by making the list available on a web server. Setting all this up seemed like a good opportunity to play with Tor hidden services and systemd-nspawn. Here's the setup log with some comments. This was done on a small armhf device with Debian Jessie. Create a new hidden service Edit /etc/tor/torrc on the host to setup the hidden service:

HiddenServiceDir /var/lib/tor/ksp/
HiddenServicePort 80 10.0.0.2:80
HiddenServicePort 11371 10.0.0.2:11371

Run:

host# systemctl reload tor.service

Then, to learn the name of the newly created hidden service name:

host# cat /var/lib/tor/ksp/hostname
ksp123456789abcd.onion

Install the container debootstrap as always:

host# debootstrap --variant=minbase jessie /var/lib/container/ksp

Preliminary container configuration We do the following step simply using chroot as we are going to use the host network configuration for this stage. The container itself will not have access to the Internet.

host# chroot ksp

Let's set the hostname:

ksp-chroot# echo 'ksp' > /etc/hostname

Set up APT:

ksp-chroot# echo 'deb http://httpredir.debian.org/debian jessie main' > /etc/apt/sources.list
ksp-chroot# apt update

We need dbus to get systemd to work well:

ksp-chroot# apt-get install dbus

Make sure that we can resolve our own hostname:

ksp-chroot# apt-get install libnss-myhostname
ksp-chroot# sed -e '/^hosts:/s/files/myhostname \0/' -i /etc/nsswitch.conf

These are dependencies of the keyserver:

ksp-chroot# apt-get install --no-install-recommends libhttp-daemon-perl \
                liblog-loglite-perl libproc-reliable-perl

These ones are needed for the script generating the list:

ksp-chroot# apt-get install bzip2 inoticoming

And we will use the smallest HTTP server available:

ksp-chroot# apt-get install netcat-traditional micro-httpd

Finally, let's unconfigure all DNS resolvers:

ksp-chroot# echo > /etc/resolv.conf

And we are done with the chroot:

ksp-chroot# exit

Let's retrieve the ksp-tools repository now:

host# cd /var/lib/container/srv
host# git clone https://github.com/formorer/ksp-tools

Container setup We will now start the container with a shell to configure it:

host# systemd-nspawn -D ksp --network-veth

Let's ask systemd to configure the network for us:

ksp# systemctl enable systemd-networkd

Let's not forget to set a root password:

ksp# passwd

We add a dedicated user to run the keyserver and the list generation script:

ksp# adduser --system --group --disabled-password --disabled-login --home /var/lib/ksp ksp

Let's configure the keyserver:

ksp# cp /srv/ksp-tools/keyserver.conf /var/lib/ksp/keyserver.conf

Let's edit /var/lib/ksp/keyserver.conf:

homedir = /var/lib/ksp

Now create the GnuPG homedir for the keyserve:

ksp# mkdir /var/lib/ksp/keys
ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/gpg

Copy the template list generator:

ksp# cp -r /srv/ksp-tools/example /var/lib/ksp/keys/ksp123456789abcd_onion

Create the key repository:

ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/ksp123456789abcd_onion/keys

Create a directory accessible to the web server where the participant list will be generated:

ksp# mkdir -p /var/www
ksp# install -d -o ksp -g ksp -m 0755 /var/www/keys

Let's configure the list generation script by editing /var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars:

KS=ksp123456789abcd.onion
export GNUPGHOME=/tmp/ksp-gpg
KSPFILE="/var/www/keys/ksp-event.txt"

Don't forget to adjust the header in /var/lib/ksp/keys/ksp123456789abcd_onion/conf/list-header. Now we create a unit file for the keyserver in /etc/systemd/system/keyserver.service:

[Unit]
Description=Key signing party keyserver
[Service]
Type=simple
Environment="KSP_HOMEDIR=/var/lib/ksp"
ExecStart=/srv/ksp-tools/bin/kspkeyserver.pl --nodaemonize
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/ksp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target

Another unit for the list generator as /etc/systemd/system/ksp-list-generator.service:

[Unit]
Description=Key signing party list generator
[Service]
Type=simple
EnvironmentFile=/var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars
ExecStart=/usr/bin/inoticoming --foreground /var/lib/ksp/keys/ksp123456789abcd_onion/keys --chdir /var/lib/ksp/keys/ksp123456789abcd_onion bin/generate-list \;
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=/var/www/keys
CapabilityBoundingSet=
[Install]
WantedBy=multi-user.target

For the web server, we first configure a socket listening on port 80 in /etc/systemd/system/micro-httpd.socket:

[Unit]
Description=micro-httpd socket
[Socket]
ListenStream=80
Accept=yes
[Install]
WantedBy=sockets.target

And then the web server in /etc/systemd/system/micro-httpd@.service:

[Unit]
Description=micro-httpd server
[Service]
ExecStart=-/usr/sbin/micro-httpd /var/www/ksp
StandardInput=socket
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
CapabilityBoundingSet=

Let's now ask systemd to start all of these at boot time:

ksp# systemctl daemon-reload
ksp# systemctl enable keyserver.service
ksp# systemctl enable ksp-list-generator.service
ksp# systemctl enable micro-httpd.socket

One way to kill the container is to type Control+] three times. Boot the container Let's get this party started!

host# systemd-nspawn -b -D /var/lib/container/ksp --network-veth

Hopefully, things should work now. Participants to the KSP should then be able to send their key with:

$ torsocks gpg --keyserver ksp123456789abcd.onion --send-key $KEYID

(Sadly, this is broken with GnuPG 2.1 at the moment.) The participant list should be available at http://ksp123456789abcd.onion/ksp-event.txt. Final steps We need to tell systemd to start the container started at boot time:

host# systemctl enable systemd-nspawn@ksp.service

But the default command-line will not use a dedicated network, so we need to override that part of the configuration. First create a directory:

host# mkdir /etc/systemd/system/systemd-nspawn@ksp.service.d

And edit /etc/systemd/system/systemd-nspawn@ksp.service.d/use-network-veth.conf:

[Service]
# The empty line because we want to override all previous ExecStart
# and not add an extra command
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --directory=/var/lib/container/%i --network-veth

Let's reload systemd and verify that our snippet is there:

host# systemctl daemon-reload
host# systemctl cat systemd-nspawn@ksp.service

All good? Let's start it:

host# systemctl start systemd-nspawn@ksp.service

One should also add a firewall to disallow any outgoing connections from the ve-ksp interface as an extra protection.

Sometimes waiting for a delayed flight helps to implement things. I added some basic support for the new Debian SSO Client Certificate feature to paste.debian.net. If you are using such a certificate most anti-spam restrictions, code limitations and so on won t count for you anymore.

I just noticed that SSLLabs now supports IPv6. I could not find an announcement for it but I'd guess it's already there for some time. There is also a new sslscan release in experimental with IPv6 support. Thanks to Marvin and formorer who finally made that happen. Update: Since this won't hit official backports.d.o soon I've done a pbuilder build for jessie.

On 22nd of October 2004 an event called OS04 took place in Seifenfabrik Graz/Austria and it marked the first official release of the Grml project. Grml was initially started by myself in 2003 I registered the domain on September 16, 2003 (so technically it would be 11 years already :)). It started with a boot-disk, first created by hand and then based on yard. On 4th of October 2004 we had a first presentation of grml 0.09 Codename Bughunter at Kunstlabor in Graz. I managed to talk a good friend and fellow student Martin Hecher into joining me. Soon after Michael Gebetsroither and Andreas Gredler joined and throughout the upcoming years further team members (Nico Golde, Daniel K. Gebhart, Mario Lang, Gerfried Fuchs, Matthias Kopfermann, Wolfgang Scheicher, Julius Plenz, Tobias Klauser, Marcel Wichern, Alexander Wirt, Timo Boettcher, Ulrich Dangel, Frank Terbeck, Alexander Steinb ck, Christian Hofstaedtler) and contributors (Hermann Thomas, Andreas Krennmair, Sven Guckes, Jogi Hofm ller, Moritz Augsburger, ) joined our efforts. Back in those days most efforts went into hardware detection, loading and setting up the according drivers and configurations, packaging software and fighting bugs with lots of reboots (working on our custom /linuxrc for the initrd wasn t always fun). Throughout the years virtualization became more broadly available, which is especially great for most of the testing you need to do when working on your own (meta) distribution. Once upon a time udev became available and solved most of the hardware detection issues for us. Nowadays X.org doesn t even need a xorg.conf file anymore (at least by default). We have to acknowledge that Linux grew up over the years quite a bit (and I m wondering how we ll look back at the systemd discussions in a few years). By having Debian Developers within the team we managed to push quite some work of us back to Debian (the distribution Grml was and still is based on), years before the Debian Derivatives initiative appeared. We never stopped contributing to Debian though and we also still benefit from the Debian Derivatives initiative, like sharing issues and ideas on DebConf meetings. On 28th of May 2009 I myself became an official Debian Developer. Over the years we moved from private self-hosted infrastructure to company-sponsored systems, migrated from Subversion (brr) to Mercurial (2006) to Git (2008). Our Zsh-related work became widely known as grml-zshrc. jenkins.grml.org managed to become a continuous integration/deployment/delivery home e.g. for the dpkg, fai, initramfs-tools, screen and zsh Debian packages. The underlying software for creating Debian packages in a CI/CD way became its own project known as jenkins-debian-glue in August 2011. In 2006 I started grml-debootstrap, which grew into a reliable method for installing plain Debian (nowadays even supporting installation as VM, and one of my customers does tens of deployments per day with grml-debootstrap in a fully automated fashion). So one of the biggest achievements of Grml is from my point of view that it managed to grow several active and successful sub-projects under its umbrella. Nowadays the Grml team consists of 3 Debian Developers Alexander Wirt (formorer), Evgeni Golov (Zhenech) and myself. We couldn t talk Frank Terbeck (ft) into becoming a DM/DD (yet?), but he s an active part of our Grml team nonetheless and does a terrific job with maintaining grml-zshrc as well as helping out in Debian s Zsh packaging (and being a Zsh upstream committer at the same time makes all of that even better :)). My personal conclusion for 10 years of Grml? Back in the days when I was a student Grml was my main personal pet and hobby. Grml grew into an open source project which wasn t known just in Graz/Austria, but especially throughout the German system administration scene. Since 2008 I m working self-employed and mainly working on open source stuff, so I m kind of living a dream, which I didn t even have when I started with Grml in 2003. Nowadays with running my own business and having my own family it s getting harder for me to consider it still a hobby though, instead it s more integrated and part of my business which I personally consider both good and bad at the same time (for various reasons). Thanks so much to anyone of you, who was (and possibly still is) part of the Grml journey! Let s hope for another 10 successful years! Thanks to Max Amanshauser and Christian Hofstaedtler for reading drafts of this.

Recently I was doing some work on the alioth infrastructure like fixing things or cleaning up things. One of the more visible things I done was the switch from gitweb to cgit. cgit is a lot of faster and looks better than gitweb. The list of repositories is generated every hour. The move also has the nice effect that user repositories are available via the cgit index again. I don t plan to disable the old gitweb, but I created a bunch of redirect rules that - hopefully - redirect most use cases of gitweb to the equivalent cgit url. If I broke something, please tell me, if I missed a common use case, please tell me. You can usually reach me on #alioth@oftc or via mail (formorer@d.o) People also asked me to upload my cgit package to Debian, the package is now waiting in NEW. Thanks to Nicolas Dandrimont (olasd) we also have a patch included that generates proper HTTP returncodes if repos doesn t exist.

DMARC (https://wordtothewise.com/2014/04/brief-dmarc-primer/) is a great thing. To protect our subscribers we (Debian listmasters) will probably have to reject mails from every domain that enforces rejects via DMARC (p=reject) in the future. If you want to follow the discussion subscribe to Bug #752084. That means that users of such providers will not be able anymore to post to our lists without using a third party service. I can only encourage users of such providers ( aol , yahoo I mean you!) to tell their providers how shitty DMARC is. By the way, rumors say that this will include all gmail users in the future. If you want to laugh, there are some solutions for handling DMARC:

• http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail . I laughed a lot, especially of http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Relay_one_copy_through_author_domain_server

As requested in #747376 I created the following new debian lists:

• debian-lts
• debian-lts-changes
• debian-lts-announce

This year I am able to join the Debian Booth on FOSDEM again. I am also looking forward to meet some projects like foreman and many others. I also hope that I find the time to do some listmaster work, like accepting new lists or getting my new solr based search engine for lists.debian.org online. If you want to meet me, try the debian booth or drop me a short mail or twitter message (@formorer).

I was a member of the credativ family for almost 10 years. It was a great and and demanding time where I did things I never imagined I would have to do them :). I started as an apprentice and finished as a technical lead. In the last summer one of my best friends - if not my best - and I developed the idea of me joining his company hs42 as their new Head of IT. The whole concept is interesting, most time I ll do home-office and for ~ 1 week in a month I ll join the company in Oldenburg. After a lot of thinking I accepted that offer. That means that I left credativ in December. Being an open source consultant is interesting on the one hand, but somewhat annoying on the other hand. You will always do new things, but often you are not in the position of designing, deciding or even running them. I was always something that is nowadays known as a devop - a long time before this was getting hip . Now I have the opportunity to design, develop and run my own systems. That also means a little bit windows, but opsi exists :). Running systems on your own is different from the usual consultant work. Being a consultant often means that you design and implement something and after it works you have to give your baby into the hands of someone else. Running them on your own also means you can do constant improvement to something, not only when its broken. The job should give me more time for open source and my family, which is a good thing. It is still a little bit odd to work from home, but being together with your family most of the time is a great thing - and I don t want to miss it. The new job also allows me to work as consultant on my own, so if you need a Debian, E-Mail, Linux or whatever guy that helps you in doing things - get in touch with me. The time at credativ was a great one and I look back with a smile to all the good things. If you need Open Source Support they are the people you should ask. I will stay connected with credativ in many ways.

I am really annoyed of those people constantly posting Ingress updates on google+, maybe its time to test it on my own... So if someone has an invitation he can be sure I will be thankful ;)

On sunday ends the Call for Participation of the SIGINT 2012 in cologne, Germany. So if you have something important to say: hurry up before its too late!

For those interested in Sympa, version 6.1.4 has been uploaded to squeeze-backports. This version fixes around two dozen bugs since the version present in squeeze (6.0.1). I strongly recommend to use this version with squeeze as it fixes some very annoying bugs. How to install it: For squeeze users Be sure to have squeeze-backports repository enabled in your sources.list as explained on Debian Backports website then:

apt-get -t squeeze-backports install sympa

For lenny users For lenny users with a running sympa installation who plan to upgrade to squeeze and use sympa from squeeze-backports, it is recommended to upgrade directly from the version 5.3.4 (lenny's version) to 6.1.4. To do so, you just need to add some apt pinning in /etc/apt/preferences (see below) and then dist-ugprade normally.

Package: sympa
Pin: version 6.1.4*
Pin-Priority: 500

Sympa 6.1.6 is already out and should be uploaded in unstable soon, it should also be backported to squeeze-backports if all goes fine. Special thanks to Gerfried (rhonda) and Alexander (formorer) for their work on Debian Backports.