Planet Debian Administration

29th July 2015

Steve: Nowadays I live in Finland


My (Finnish) wife and I have now relocated from Edinburgh, Scotland, to Helsinki, Finland.

I've been here for 13 days at the moment, and am still settling in. But so far things are going well. So, yeah, that happened.

29th July 2015 06:39:14 : 2 comments.

13th July 2015

Alexmore: CRM more7

CRM7 to autorski produkt firmy more7 Polska służący do zarządzania relacjami z klientem. System zyskał już uznanie na rynku IT, a wiele firm z powodzeniem wdrożyło CRM7, korzystając z jego wsparcia przy planowaniu i zarządzaniu. CRM7 to nowoczesne wsparcie dla wielu branż: logistycznej, spedycyjnej, ochroniarskiej, usługowej, przemysłowej, handlowej, marketingowej oraz finansowej. Zaletą korzystania z CRM7 jest przede wszystkim łatwa obsługa oraz kompleksowe wsparcie specjalistów, którzy nie tylko pomogą Państwu zaimplementować system, ale również odpowiedzą na wszelkie pytania na etapie korzystania z systemu.
13th July 2015 09:17:34 : Comments disabled

4th June 2015

dkg: Challenge: one reproducible package a week

Tags: ,
I encourage anyone interested in debian development to get involved with the Reproducible Builds project. My own project is to try to diagnose (and hopefully provide patches for) two unreproducible packages a week. Maybe you can do one package a week?

Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post.

It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future).

My usual workflow is this:

The information at the R-B wiki page is quite detailed if you want more info.

Finally, many many thanks to all of the people involved in the project, and particularly to h01ger and Lunar^, who have both contributed a ton of work, and have also made it easy to plug in and help as a less-involved contributor. The nice automatically-updated statistics provided by the team's continuous integration work makes it a fun game to help out.

4th June 2015 02:31:12 : No comments. Link

17th May 2015

mcortese: GNOME Wayland

I've just realized that the last version of GNOME (the one shipped with Jessie) allows to start the session under Wayland instead of the classic X. I think it's a only a preview to start collecting some feedback and bug reports from the field, and that it shouldn't be considered a mature, workable option.

On my admittedly underpowered system (an Atom-based netbook) the usability approaches zero, with xwayland taking up 99% of the CPU and several seconds of lag between action (mouse clicks, key presses) and feedback. In addition, synaptics options like tap-to-click are not recognized -- or not obeyed, I'm not sure.

I'd be curious about other users' experience, if any have been brave enough to try it out!

17th May 2015 10:23:00 : 1 comment.

8th May 2015

dkg: Cheers to audacity!

When paultag recently announced a project to try to move debian infrastructure to python3, my first thought was how large that undertaking would likely be. It seems like a classic engineering task, full of work and nit-picky details to get right, useful/necessary in the long-term, painful in the short-term, and if you manage to pull it off successfully, the best you can usually hope for is that no one will notice that it was done at all.

I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem.

I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in.

So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!)

The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.

8th May 2015 18:43:51 : No comments. Link

1st May 2015

dkg: Preferred Packaging Practices

Tags: , ,
I just took a few minutes to write up my preferred Debian packaging practices.

The basic gist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea).

I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things:

My preferred packaging practices document is a work in progress. I'd love to improve it. If you have suggestions, please let me know.

Also, if you've written up your own preferred packaging practices, send me a link! I'm hoping to share and learn tips and tricks around this kind of workflow at debconf 15 this year.

1st May 2015 19:41:06 : No comments. Link

16th April 2015

fugit: Building a certain Version of Debian

The Problem: Vendor software we were looking to evaluate did not compile correctly using the lastest version of wheezy(7.8 at the time of writing).

The Solution: We had a to build a new server using This allowed us to build the server at a point in time after 7.1 was released but prior to the 7.2 release. Below are the settings we use.

    cat /etc/apt/sources.list
    deb wheezy main
    deb  wheezy/updates main

For more details head on over to the site.

16th April 2015 16:56:15 : 2 comments.

16th March 2015

dkg: Bootable grub USB stick (EFI and BIOS for Intel)

Tags: , , ,

I'm using grub version 2.02~beta2-2.

I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process.

I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.

I'm documenting what I did here, in case it's useful to other people.

Set up the USB stick's partition table:

parted /dev/sdX -- mktable gpt
parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB
parted /dev/sdX -- mkpart efi fat32 4MiB -1
parted /dev/sdX -- set 1 bios_grub on
parted /dev/sdX -- set 2 esp on
After this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print
Model:  USB FLASH DRIVE (scsi)
Disk /dev/sdX: 1032MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name      Flags
 1      1049kB  4194kB  3146kB  fat32        biosgrub  bios_grub
 2      4194kB  1031MB  1027MB               efi       boot, esp

0 root@foo:~# 
make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2
mount /dev/sdX2 /mnt
ensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \

grub-install --removable --boot-directory=/mnt \
     --target=i386-pc /dev/sdX
At this point, you should add anything else you want to /mnt here! For example: And don't forget to cleanup:
umount /mnt
16th March 2015 23:12:35 : 8 comments.

2nd February 2015

ajt: DKIM

Tags: , , , ,

Recently a friend asked me about SPF and DKIM. I was vaguely aware of them and their generally perceived uselessness. I've never bothered with them but thought I'd look into them for him. SPF was trivial to set up using my Bytemark DNS, and easy to testing using of many on-line email tools.

The challenge is DKIM, I found several sites that explained what to do - they were all variation around a theme and seemed easy enough. Generate a key pair (check), put the public half into your DNS (check), tweak Exim4 (ARGH!!!).

As far as I tell I followed what the web site said and reloaded the Exim config and it looks like it's all loaded into place, the key is readable by Exim, the path is correct but no matter what I do Exim wont add the DKIM signature to my outgoing emails...!

2nd February 2015 20:55:28 : No comments. Link

12th December 2014

dkg: a10n for l10n

The abbreviated title above means "Appreciation for Localization" :)

I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand.

The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software.

I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Prévot.

This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people.

If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software.

Thank you to all the localizers!

(this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)

12th December 2014 23:00:04 : 1 comment.

23rd November 2014

rkreider: It's been 7 Years

It's been seven years since I last posted an entry here. WOW! I re-read some of my blog entries and laughed at myself. I've learned so much since then. Maybe I'll try to be a bit more active in the coming future.
23rd November 2014 03:54:14 : 1 comment.

6th November 2014

dkg: GnuPG 2.1.0 in debian experimental

Tags: , ,
Today, i uploaded GnuPG 2.1.0 into debian's experimental suite. It's built for amd64 and i386 and powerpc already. You can monitor its progress on the buildds to see when it's available for your architecture.


GnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. GnuPG users who don't have this capability available won't be able to communicate with End-To-End users.

There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all.

One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring.

I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use.

Timing for debian

The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment.

If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you.

Long term migration concerns

GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently.

In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now.

In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow:

And GnuPG 2.1.0 drops support for the older, known-weak OpenPGPv3 key formats. This is an important step for simplification, but there are a few people who probably still need to use v3 keys for obscure/janky reasons, or have data encrypted to a v3 key that they need to be able to decrypt. Those people will want to have GnuPG 1.4 around.

Call for testing

Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install `gnupg2` and its friends from experimental. If you want to be sensibly conservative, i recommend backing up `~/.gnupg` before trying to use it:

cp -aT .gnupg .gnupg.bak
sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemon
If you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed.
6th November 2014 23:27:16 : 10 comments.

31st August 2014

Steve: Site code is public once again.

Tags: , ,

Originally the code behind this site as 100% open, but during the course of some of the earlier migrations it was closed by accident - jumping from CVS to hg, and now to git things moved around a lot.

Nothing was ever intended to be secret, private, or closed, it was just an aspect I've failed to pay attention to.

Anyway the code behind this site is called YAWNS and once again it is open to the public:

31st August 2014 14:55:26 : 2 comments.

8th August 2014

Steve: Code overhaul .. volunteers welcome


The code behind this site is badly in need of another overhaul.

At the moment it runs on a set of ropy CGI scripts that are neither efficient nor pleasant.

My current plan is to record the basics from scratch, then port over functionality as time goes on. As part of that I think I'll be coming up with some toy-servers:

With that structure in mind the core of the site can just mediate between requests and the actual backend - without worrying about actual implementation-details.

In terms of features the only thing I think I'm going to remove is the comment-feed RSSs.

There is a feed for the comments on every article - and that feed gets spidered like mad, for articles that are many years old.

I'm open to the idea of collaboration if there are users who wish to help - and the code will be on github in due course.

8th August 2014 10:14:56 : 7 comments.

16th July 2014

Steve: Rejoining the Debian project

I resigned from the debian project a few years ago, but I'm currently going through the process to un-retire.

Fun times.

(I have more free time now that I'm happily married and my wife works as a Doctor in A&E - having a few late-night shifts in local hospitals.)

16th July 2014 10:37:18 : 1 comment.

27th June 2014

Steve: Git-based DNS hosting

Tags: , ,

So I accidentally released a service which will give you resilient, low-latency, DNS-hosting (which uses Amazons route53 on the backend).

If you'd like to use Git to store your DNS-data, and add/update DNS-entries via a simple "git push" then you should check it out:

27th June 2014 16:44:06 : No comments. Link

10th June 2014

lee: Using Amazon SES with Exim (Submission)

Tags: , , ,

A previous entry from 2011 on the subject on using SES and Exim still comes up in web searches. As with the 2011 config, this assumes a standard Debian/Ubuntu exim4 deployment using a split-file config.

SES now allows authenticated relay via port 25, but also submission (port 587). Logically it makes more sense to think of SES as a Submission host since it uses ESMTPSA and makes modifications to the mail in transit, so I explicitly create a submission transport at /etc/exim4/conf.d/transport/40_local_submission

  debug_print = "T: remote_submission for $local_part@$domain"
  driver = smtp
  port = 587
  hosts_require_auth = *
  hosts_require_tls = *
Then I add in a router which activates based on the sender at /etc/exim4/conf.d/router/180_local_aws-ses
  debug_print = "R: send_via_ses for mail from $sender_address"
  driver = manualroute
  host_find_failed = freeze
  domains = ! +local_domains
  senders = AWS_SES_SENDER
  transport = remote_submission
  route_list = * AWS_SES_SERVER
The site specific configuration /etc/exim4/conf.d/main/00_local_aws-ses
## sender email addresses to be routed via SES, one-per-line
AWS_SES_SENDER = lsearch*@;/etc/exim4/ses_senders

## nearest SES ingress point
And assuming the standard auth handling is in place, add a line to /etc/exim4/passwd.client
Note, these are SMTP specific credentials and not the AWS credentials previously used. Run update-exim4.conf and then restart exim.
10th June 2014 21:35:33 : No comments. Link

3rd June 2014

Steve: Hire Steve ...

If you're looking for a system administrator, who is very very familiar with Debian GNU/Linux, please do consider getting in touch.

I'm an ex-member of the Debian project, and was a member of the Debian Security Team, which involved handling security updates for the distribution. (This came about as a result of my interest in auditing software, a process which lead to the discovery, and fixing, of numerous flaws in popular open-source applications and servers.)

I'm based in Edinburgh, but I have had many years working remotely, and would be happy to repeat that.

As you can see from my prior submissions I'm very familiar with system administration, including (but not limited to):

3rd June 2014 12:46:28 : No comments. Link

15th May 2014

Steve: Promoting my own creations ..

Tags: , ,

In the past I've written and posted articles upon this site about my own software.

Over time I've become a little less keen on doing so, on the basis that people might think it is too Steve-centric. That said I'd always created this site to document things of interest to myself, and the fact that others enjoy them is a good bonus.

In summary I wrote a mail client, it is console-based like mutt, but it has a real scripting language you can use to do fun things (Lua).

You can find details here, should you have any interest:

Relatedly I've been pondering a "Hire Steve" banner on the top of the site. I've resisted the temptation for the moment, but give it a couple more weeks of unemployment and I may well change my mind..

15th May 2014 13:31:32 : 2 comments.

12th May 2014

simonw: Web Application Vulnerability scanners

Been trying out various web application vulnerabilities scanners, both Open Source and Proprietary.

These are tools that will analyse your website, or in some case an instrumented copy of your site, and identify some types of common security flaws, or in other cases simple omissions to use best practice.

My main goal is to find tools which are easy to integrate into a Continuous Integration process, so ideally looking for scanners with minimal user interaction, with a command line driven batch mode, to beef up the current CI process.

I've not reached any conclusions yet, but it is an interesting landscape. Almost everyone agrees more tools are better, because they are all slightly different, there are inevitably bugs that one finds, that another misses. CPU time is a LOT cheaper than developer, or Pen Tester time, so a lot of automation makes sense, however the significant false positive rate means that more tools do make some more work. This scales better than I expected, because the same issues trip up different tools in the same way.

For example the WordPress action "wp-post-comments.php" returns a "500 Server Error" HTTP response code under some circumstances, and lots of tools leap on this proudly noting they have "crashed" your server, when the response header shows otherwise.

But alas WordPress defaults to 500 status codes when people omit required fields on forms, and other common cases. This WordPress annoyance has been lurking for at least 4 years, and the Lead Developers seem in no hurry to stop it emitting error codes suggesting it has crashed just because someone forgot to enter their email address.

Almost all the tools pick up on this, and arguably rightly so, but it isn't a useful find.

Intercepting Proxies

Intercepting Proxies sit between the browser, and website to test, and thus can easily identify (and modify if needed) any traffic from browser to server. For AJAX, web sockets, and a number of other web technologies this is an essential place to be for spotting certain common vulnerabilities (like failure to validate AJAX server side).

One of our tools of choice is BurpSuite, which is a fantastic little application. You do need to buy the Pro version to do proper automated scanning. Whilst we'll use it for manual, and pre-release testing, its focus is on manual testing, and whilst some folk have tried to drive it from the command line, I suspect down this route lies pain and eternal maintenance.

The OWASP Zed Attack proxy tool is targeted at almost exactly the same space as BurpSuite (Clone?). In true Open Source style it is harder to use, a little rougher around the edges, but allegedly does more, and seems to have a little more momentum and adaptability. Oh and a very responsive lead funded by Mozilla. So far it takes longer to run, and has more false positives, but in my initial tests identify a whole host of minor but legitimate issues, although I rushed it, it still took nearly 4 hours for a small website (CPU time may be cheap but we do want answers before the release date). I suspect many folk who've never used BurpSuite Pro will think ZAP fantastic, and it does look like a little attention to settings will pay dividends in both time to run, and false positive rate.

I suspect either tools can be used in Continuous Integration as a proxy, but I see more effort to support this from the OWASP ZAP lead.

Vulnerability Scanners

In a previous roles where I was working on PHP and Perl websites, predominantly doing simple forms, the tool of choice was Wapiti. My reading around suggests it is still an excellent choice, scoring well in comparisons and being quick and easy to use. The default version of Wapiti in Debian is 1 until Jessie, so you probably want either a dedicated network security distro like Kali in a machine somewhere, or just Debian testing.

I note also that OSSIM vulnerability scanner (OpenVAS) will run wapiti if it is installed, but again because it is based on Squeeze it is wapiti version 1 you get if you use "apt-get". Still if you need a network security scanner installing OSSIM is a lot easier than installing OpenVAS in Debian, sticking in wapiti is a no-brainer as a one line enhancement. OSSIM can run Nikto with a really minor tweak I've discussed on their forum as well.

Nikto still finds a place in my arsenal. Somehow I can't love w3af. Few of the other tools make me love them (except NMAP of course).

Next on my list are some of the more established proprietary tools, but there are a huge number of Open Source tools I simply won't have time to evaluate, so any tips on where to check first appreciated. I don't see an alternative to the Intercepting proxy, or something logically equivalent, there is also a requirement to handle newer features of browsers like Web Sockets and local storage (which I see as a greatly enriched version of cookie poisoning).

As always these tools won't keep you safe, but they may let you know when you are heading in the wrong direction, which is why using them as early in the development process as possible makes sense.
12th May 2014 21:32:39 : No comments. Link

7th May 2014

ajt: Strange Dovecot behaviour solved

I recently had an incident where Dovecot didn't start properly and then the following day it did. Yesterday I had the same scenario and it was really annoying. The core process starts but none of the actual worker children do.

The problem turns out to be a NFS mount to a box that went away, which meant when Dovecot started went looking for email mbox files on the home directory of the users (not NFS mounted) it got stuck. I eventually spotted this by starting Dovecot under strace and it was instantly obvious what the problem was, and a quick force umount of the now-absent filesystem allowed Dovecot to carry on.

7th May 2014 22:08:43 : 1 comment.

14th April 2014

dkg: OTR key replacement (heartbleed)

I'm replacing my OTR key for XMPP because of heartbleed (see below).

If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified.

Hash: SHA512

OTR Key Replacement for XMPP
Date: 2014-04-14

My main XMPP account is

I prefer OTR [0] conversations when using XMPP for private

I was using irssi to connect to XMPP servers, and irssi relies on
OpenSSL for the TLS connections.  I was using it with versions of
OpenSSL that were vulnerable to the "Heartbleed" attack [1].  It's
possible that my OTR long-term secret key was leaked via this attack.

As a result, I'm changing my OTR key for this account.

The new, correct OTR fingerprint for the XMPP account at is:

  F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D

Thanks for taking the time to verify your peers' fingerprints.  Secure
communication is important not only to protect yourself, but also to
protect your friends, their friends and so on.

Happy Hacking,

  --dkg  (Daniel Kahn Gillmor)


[0] OTR:
[1] Heartbleed:
Version: GnuPG v1

14th April 2014 18:43:20 : No comments. Link

24th February 2014

dkg: Inline-PGP considered harmful

Tags: , , ,
We changed the default PGP signatures generated by enigmail in debian from Inline PGP to PGP/MIME last year, and the experiment has gone well enough that we're now using it in jessie and wheezy (where it arrived as part of a security update to make the extension work with the security-updated icedove package).

After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly.

The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently.

The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step).

Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.

24th February 2014 02:09:40 : 5 comments.

19th February 2014

Steve: Easily sharing markdown text

I've just about completed a new toy project:

This is basically a markdown-using pastebin site.

You can paste in your random markdown text, and once you've done so you receive a link you can share with your boss, your friends, or whoever.

The source code is available on Github, and there is a (trusted) docker image too, which makes installation trivial.

Feedback welcome, either here, via mail, or via the github tracker.

I'm pretty pleased with the project, and it is already proving useful.

19th February 2014 09:41:32 : No comments. Link

31st January 2014

Steve: Server Optimization ..

Tags: , , , ,

Contributions and feedback welcome, on my new site:

Much like this one in nature, but much more succinct and focussed.

31st January 2014 19:46:03 : No comments. Link

19th January 2014

Steve: Starting a new job ..

Tags: ,

On Monday (tomorrow) I'll be starting a new job, once again working from home - something I was keen to avoid.

Still it won't be so bad, the only potential concern is that I'll be starting on my home desktop, and at some point during the day I'm expecting a delivery of a new Macbook which I need to switch over to using.

I've never used a Mac, not since system 7, so that'll be "fun".

19th January 2014 11:52:30 : 2 comments.

26th December 2013

fugit: Problem with Bonding and Vlan on Wheezy

Tags: , , ,
The Problem: Using the same configuration that worked under squeeze for Bonding and Vlan with Openvz, on wheezy it is failing. The symptoms are that only the vlan with the default gateway set are working. I can move the default gateway to any vlan and it will work. The vlans work on when communicating to machines on the same vlan. Using tcpdump/wireshark I confirmed that traffic is coming in but never making it out the default GW unless it is the vlan with the default gateway. On the squeeze servers you can see the traffic going out the default GW.

The Solution:
Turns out you need to set net.ipv4.conf.default.rp_filter = 2 (or 0 for no spoof protection). Strict filter results in vlans not on the default gw to be broken. More details and links will be posted later. Unfortunetly I didn't find the links with the solutions till I had found the issue was net.ipv4.conf.default.rp_filter. I originally missed this in testing because you need to restart(networking) after making the changes. I am not sure how I missed this when rebuilding a new clean server with wheezy. When built from scratch with defaults rp_filter = 0. Like most problems it seems pretty obvious once you have the solution. The text in the sysctl.conf file says "Uncomment the next two lines to enable Spoof protection (reverse-path filter)." This pretty clearly was the issue. Sadly I tested twice to make sure change I had made were not causing the problem but the first time failed because I had not restarted the network or the server after reverting the changes to rp_filter. The second time I have no idea how I missed it on a clean build of a new server. After building the server and only changing the network config it presented the same symptoms, obviously I made a change or missed something. Hopefully this post will save someone else some time.

Cisco Setup:
Cisco Hardware
We are using a cisco Nexus 7000 switchs with gigabit ethernet module that supports 802.3ad. For more information regarding the different bonding options you can check out this link

Setup the port channel
interface port-channel170                                                                                                                                                                                        
  description servername01                                                                                                                                                                                                                  
  switchport mode trunk                                                                                                                                                                                                                     
  switchport trunk allowed vlan 45,48-49                                                                                                                                                                                                    
  vpc 170                                                                                                                                                                                                                                   
Configure the physical interfaces on the cisco switch:
interface Ethernet1/11                                                                                                                                                                                                                      
  description servername#1                                                                                                                                                                                                                  
  switchport mode trunk                                                                                                                                                                                                                     
  switchport trunk allowed vlan 45,48-49                                                                                                                                                                                                    
  spanning-tree port type edge                                                                                                                                                                                                              
  channel-group 170 mode active                                                                                                                                                                                                             
  no shutdown                                                                                                                                                                                                                               
interface Ethernet3/11
  description servername#2
  switchport mode trunk
  switchport trunk allowed vlan 45,48-49
  spanning-tree port type edge
  channel-group 170 mode active
  no shutdown
Make sure the the "switchport trunk allowed vlan" has the vlans you are going to be doing on the linux server. Until these matched nothing worked for me.

Server HardWare: The current server we are using is a DL360pG8 which has a broadcom tg3 4 port card. This card has had several reported issues to rule this out I later installed a base wheezy package on an older server that was known to work with our confugration under squeeze and our current Nexus 7000 switch. This produced the same issues reported here. I had also tried using the backport kernel to further rule out drivers, this was before building a new server.
lspci | grep -i broad
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
Linux Network Config:
Install the required pacakges and load bonding module
apt-get install vlan ifenslave
Interfaces Config: /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0

auto bond0
iface bond0 inet manual
        #bond-mode 802.3ad
        bond-mode 4
        bond-miimon 100
        bond_downdelay 200
        bond_updelay 200
        bond_xmit_hash_policy layer2+3
        bond_lacp_rate slow
        slaves eth0 eth1 eth2 eth3

auto vlan45
iface vlan45 inet static
        vlan_raw_device bond0  

auto vlan48
iface vlan48 inet static
        vlan_raw_device bond0  

auto vlan49
iface vlan49 inet static
        vlan_raw_device bond0  
I had also ready posts regarding people having problems using the "pretty" or easy to read version above so I also tried the below configuration with the same results.
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0

auto bond0
iface bond0 inet manual
        #bond-mode 802.3ad
        bond-mode 4
        bond-miimon 100
        bond_xmit_hash_policy layer2+3
        bond_lacp_rate slow
        slaves eth0 eth1 eth2 eth3

auto bond0.45
iface bond0.45 inet static

auto bond0.48
iface bond0.48 inet static

auto bond0.49
iface bond0.49 inet static
Trouble Shooting:
On Linux
ServerName# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100  
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 4
        Actor Key: 17
        Partner Key: 32938
        Partner Mac Address: 00:23:04:ee:be:0a

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: d8:9d:67:2c:aa:24
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: d8:9d:67:2c:aa:25
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: d8:9d:67:2c:aa:26
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: eth3
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: d8:9d:67:2c:aa:27
Aggregator ID: 1
Slave queue ID: 0
filename:       /lib/modules/3.2.0-4-amd64/kernel/drivers/net/bonding/bonding.ko
alias:          rtnl-link-bond  
author:         Thomas Davis, and many others
description:    Ethernet Channel Bonding Driver, v3.7.1
version:        3.7.1
license:        GPL
srcversion:     0384DF6574E0ED31BA573D8
intree:         Y
vermagic:       3.2.0-4-amd64 SMP mod_unload modversions
parm:           max_bonds:Max number of bonded devices (int)
parm:           tx_queues:Max number of transmit queues (default = 16) (int)
parm:           num_grat_arp:Number of peer notifications to send on failover event (alias of num_unsol_na) (int)
parm:           num_unsol_na:Number of peer notifications to send on failover event (alias of num_grat_arp) (int)
parm:           miimon:Link check interval in milliseconds (int)
parm:           updelay:Delay before considering link up, in milliseconds (int)
parm:           downdelay:Delay before considering link down, in milliseconds (int)
parm:           use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default) (int)
parm:           mode:Mode of operation; 0 for balance-rr, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb (charp)
parm:           primary:Primary network device to use (charp)
parm:           primary_reselect:Reselect primary slave once it comes up; 0 for always (default), 1 for only if speed of primary is better, 2 for only on active slave failure (charp)
parm:           lacp_rate:LACPDU tx rate to request from 802.3ad partner; 0 for slow, 1 for fast (charp)
parm:  aggregation selection logic; 0 for stable (default), 1 for bandwidth, 2 for count (charp)
parm:           min_links:Minimum number of available links before turning on carrier (int)
parm:           xmit_hash_policy:balance-xor and 802.3ad hashing method; 0 for layer 2 (default), 1 for layer 3+4, 2 for layer 2+3 (charp)
parm:           arp_interval:arp interval in milliseconds (int)
parm:           arp_ip_target:arp targets in n.n.n.n form (array of charp)
parm:           arp_validate:validate src/dst of ARP probes; 0 for none (default), 1 for active, 2 for backup, 3 for all (charp)
parm:           fail_over_mac:For active-backup, do not set all slaves to the same MAC; 0 for none (default), 1 for active, 2 for follow (charp)
parm:           all_slaves_active:Keep all frames received on an interfaceby setting active flag for all slaves; 0 for never (default), 1 for always. (int)
parm:           resend_igmp:Number of IGMP membership reports to send on link failure (int)
I also used tcpdump to determine where the connections were getting lost. I looked at them using wireshark. tcpdump -i any -U not port 22 -w /tmp/tcpdump_any_20131220.dump This showed that traffic was coming in no problem and everything was working except when connecting to vlan's that did not have a default gw and you were not on that vlan. This makes it look like a routing issue within the OS. If anyone would find the dump lines interesting let me know and I can dig them up and post them.
Routing table.
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 vlan48   U     0      0        0 vlan45   U     0      0        0 vlan48   U     0      0        0 vlan49
ip route list
default via dev vlan48 dev vlan45  proto kernel  scope link  src dev vlan48  proto kernel  scope link  src dev vlan49  proto kernel  scope link  src
On Cisco
show interface port-channel 170
port-channel170 is up
 vPC Status: Up, vPC number: 170
  Hardware: Port-Channel, address: 44d3.cae5.50a2 (bia 44d3.cae5.50a2)
  Description: servername
  MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA
  Port mode is trunk
  full-duplex, 1000 Mb/s
  Input flow-control is off, output flow-control is off
  Switchport monitor is off
  EtherType is 0x8100
  Members in this channel: Eth1/11, Eth3/11
  Last clearing of "show interface" counters never
  52 interface resets
  30 seconds input rate 80 bits/sec, 0 packets/sec
  30 seconds output rate 1832 bits/sec, 2 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 112 bps, 0 pps; output rate 1.94 Kbps, 2 pps
    380152 unicast packets  113302 multicast packets  3248 broadcast packets
    496720 input packets  88421937 bytes
    0 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 Rx pause
Loaded Modules
lsmod | egrep '8021q|loop|bond'
8021q                  19291  0
garp                   13193  1 8021q
bonding                79169  0
loop                   22641  0
discard packets when the route for outbound traffic differs from the route of incoming traffic
openvz on debian
ubnutu bug report where I found my answer
bondong on debian
bonding on wheezy
bonding on wheezy
broadcom related post tg3
openvz on wheezy
When you are making changes via sysctl and you use '-p' to load them don't forget to restart networking or the server. When you are in the thick of it remember to make your changes one step at a time so you can find the problem. Don't assume your first hunch is the answer.
26th December 2013 18:15:06 : 1 comment.

21st December 2013

dkg: Kevin M. Igoe should step down from CFRG Co-chair

I've said recently that pervasive surveillance is wrong. I don't think anyone from the NSA should have a leadership position in the development or deployment of Internet communications, because their interests are at odds with the interest of the rest of the Internet. But someone at the NSA is in exactly such a position. They ought to step down.

Here's the background:

The Internet Research Task Force (IRTF) is a body tasked with research into underlying concepts, themes, and technologies related to the Internet as a whole. They act as a research organization that cooperates and complements the engineering and standards-setting activities of the Internet Engineering Task Force (IETF).

The IRTF is divided into issue-specific research groups, each of which has a Chair or Co-Chairs who have "wide discretion in the conduct of Research Group business", and are tasked with organizing the research and discussion, ensuring that the group makes progress on the relevant issues, and communicating the general sense of the results back to the rest of the IRTF and the IETF.

One of the IRTF's research groups specializes in cryptography: the Crypto Forum Research Group (CFRG). There are two current chairs of the CFRG: David McGrew <> and Kevin M. Igoe <>. As you can see from his e-mail address, Kevin M. Igoe is affiliated with the National Security Agency (NSA). The NSA itself actively tries to weaken cryptography on the Internet so that they can improve their surveillance, and one of the ways they try to do so is to "influence policies, standards, and specifications".

On the CFRG list yesterday, Trevor Perrin requested the removal of Kevin M. Igoe from his position as Co-chair of the CFRG. Trevor's specific arguments rest heavily on the technical merits of a proposed cryptographic mechanism called Dragonfly key exchange, but I think the focus on Dragonfly itself is the least of the concerns for the IRTF.

I've seconded Trevor's proposal, and asked Kevin directly to step down and to provide us with information about any attempts by the NSA to interfere with or subvert recommendations coming from these standards bodies.

Below is my letter in full:

From: Daniel Kahn Gillmor <>
To:, Kevin M. Igoe <>
Date: Sat, 21 Dec 2013 16:29:13 -0500
Subject: Re: [Cfrg] Requesting removal of CFRG co-chair

On 12/20/2013 11:01 AM, Trevor Perrin wrote:
> I'd like to request the removal of Kevin Igoe from CFRG co-chair.

Regardless of the conclusions that anyone comes to about Dragonfly
itself, I agree with Trevor that Kevin M. Igoe, as an employee of the
NSA, should not remain in the role of CFRG co-chair.

While the NSA clearly has a wealth of cryptographic knowledge and
experience that would be useful for the CFRG, the NSA is apparently
engaged in a series of attempts to weaken cryptographic standards and
tools in ways that would facilitate pervasive surveillance of
communication on the Internet.

The IETF's public position in favor of privacy and security rightly
identifies pervasive surveillance on the Internet as a serious problem:

The documents Trevor points to (and others from similar stories)
indicate that the NSA is an organization at odds with the goals of the IETF.

While I want the IETF to continue welcoming technical insight and
discussion from everyone, I do not think it is appropriate for anyone
from the NSA to be in a position of coordination or leadership.


Kevin, the responsible action for anyone in your position is to
acknowledge the conflict of interest, and step down promptly from the
position of Co-Chair of the CFRG.

If you happen to also subscribe to the broad consensus described in the
IETF's recent announcement -- that is, if you care about privacy and
security on the Internet -- then you should also reveal any NSA activity
you know about that attempts to subvert or weaken the cryptographic
underpinnings of IETF protocols.


I'm aware that an abdication by Kevin (or his removal by the IETF chair) would probably not end the NSA's attempts to subvert standards bodies or weaken encryption. They could continue to do so by subterfuge, for example, or by private influence on other public members. We may not be able to stop them from doing this in secret, and the knowledge that they may do so seems likely to cast a pall of suspicion over any IETF and IRTF proceedings in the future. This social damage is serious and troubling, and it marks yet another cost to the NSA's reckless institutional disregard for civil liberties and free communication.

But even if we cannot rule out private NSA influence over standards bodies and discussion, we can certainly explicitly reject any public influence over these critical communications standards by members of an institution so at odds with the core principles of a free society.

Kevin M. Igoe, please step down from the CFRG Co-chair position.

And to anyone (including Kevin) who knows about specific attempts by the NSA to undermine the communications standards we all rely on: please blow the whistle on this kind of activity. Alert a friend, a colleague, or a journalist. Pervasive surveillance is an attack on all of us, and those who resist it are heroes.

21st December 2013 22:55:01 : 2 comments.

18th December 2013

dkg: automatically have uscan check signatures

Tags: , , , , ,
If you maintain software in debian, one of your regular maintenance tasks is checking for new upstream versions, reviewing them, and preparing them for debian if appropriate. One of those steps is often to verify the cryptographic signature on the upstream source archive.

At the moment, most maintainers do the cryptographic check manually, or maybe even don't bother to do it at all. For the common case of detached OpenPGP signatures, though, uscan can now do it for you automatically (as of devscripts version 2.13.3). You just need to tell uscan what keys you expect upstream to be signing with, and how to find the detached signature.

So, for example, Damien Miller recently announced his new key that he will be using to sign OpenSSH releases (his new key has OpenPGP fingerprint 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 -- you can verify it has been cross-signed by his older key, and his older key has been revoked with the indication that it was superceded by this one). Having done a reasonable verification of Damien's key, if i was the openssh package maintainer, i'd do the following:

cd ~/src/openssh/
mkdir -p debian/upstream
gpg --export-options export-minimal --armor --export '59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30' >> debian/upstream/signing-key.asc
And then upon noticing that the signature files are named with a simple .asc suffix on the upstream distribution site, we can use the following pgpsigurlmangle option in debian/watch:
I've filed this specific example as debian bug #732441. If you notice a package with upstream signatures that aren't currently being checked by uscan (or if you are upstream, you sign your packages, and you want your debian maintainer to verify them), you can file similar bugs. Or, if you maintain a package for debian, you can just fix up your package so that this check is there on the next upload.

If you maintain a package whose upstream doesn't sign their releases, ask them why not -- wouldn't upstream prefer that their downstream users can verify that each release wasn't tampered with?

Of course, none of these checks take the the place of the real work of a debian package maintainer: reviewing the code and the changelogs, thinking about what changes have happened, and how they fit into the broader distribution. But it helps to automate one of the basic safeguards we should all be using. Let's eliminate the possibility that the file was tampered with at the upstream distribution mirror or while in transit over the network. That way, the maintainer's time and energy can be spent where they're more needed.

UPDATED 2015-05-03: use the currently-preferred location for the signing key.

18th December 2013 03:15:46 : 4 comments.

15th December 2013

lee: Whitelisting hosts in Exim4 causing TLS errors


By the end of 2013 the minimum key-size for signed TLS certificates will be 2048 bits. Older 1024 bit certificates will be revoked and web browsers will throw errors on anyone attempting to connect using 1024 bit keys.

Unfortunately, in the context of server-to-server opportunistic encryption, such as used by ESMTPS, this is a dangerous choice. 1024 bit encryption is still far harder to decode than plaintext (which is currently the usual fall-back delivery).

Sadly that's what's happened in some Debian derived releases of Exim4 (using GnuTLS). An affected mail server will likely see something like the following in the logs:

TLS error on connection to [] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

(Even worse, the choice to increase the minimum prime size also breaks connections to many servers that implement EDH - i.e. Ephemeral Diffie-Hellman with smaller encryption keys such as allowed by export.)

The quickest way to check if a remote mail server has a small key is to run a command such as:

$ echo QUIT | openssl s_client -connect -starttls smtp 2>/dev/null| grep "public key is"

If the server public key is less than 2048 bit in size, you may want to contact the postmaster or other administrative contact to let them know they need to generate a new server key.[1] If the key is 2048 bit and above, you may need to use another tool to see what's happening.

As of Exim 4.80 there is a new transport option, tls_dh_min_bits, which lets the minimum key size to be set.

So if this affects you, you could modify the minimum key size for the default transport (add " TLS_DH_MIN_BITS = 512 "). However, for these sort of workarounds it's my preference to add in special-case configuration.

(Filenames assume the split-config of debian deployments.)

Create /etc/exim4/conf.d/transport/40_temp_tls_smallprime (a modified copy of 30_exim4-config_remote_smtp)

  debug_print = "T: remote_smtp_tls_smallprime for $local_part@$domain"
  driver = smtp
  multi_domain = false
  tls_dh_min_bits = 512
dkim_domain = DKIM_DOMAIN
dkim_selector = DKIM_SELECTOR
dkim_private_key = DKIM_PRIVATE_KEY
dkim_canon = DKIM_CANON
dkim_strict = DKIM_STRICT
dkim_sign_headers = DKIM_SIGN_HEADERS

Then create /etc/exim4/conf.d/router/177_temp_tls_smallprime (i.e. so it appears before the normal external router) with two entries, one for mail servers that have <2048 keys, and ones that negotiate EDH.

  debug_print = "R: dnslookup_tls_smallprime for $local_part@$domain"
  driver = dnslookup
  domains = ! +local_domains : ! +relay_to_domains
  condition = ${if forany{${lookup dnsdb{>: mxh=$domain}}}{match_domain{$item}{+smallkey}}}
  transport = remote_smtp_tls_smallprime
  same_domain_copy_routing = yes

  debug_print = "R: dnslookup_tls_edh for $local_part@$domain"
  driver = dnslookup
  domains = ! +local_domains : ! +relay_to_domains
  condition = ${if forany{${lookup dnsdb{>: mxh=$domain}}}{match_domain{$item}{+tlsexport}}}
  transport = remote_smtp_tls_smallprime
  same_domain_copy_routing = yes

Then you add in the lists of mail servers to your main config. For example adding the following to /etc/exim4/conf.d/main/10_temp_smallprime

## Servers that present small keys
domainlist smallkey = :
## Hosts that use large keys to sign small "export" size keys for encryption
domainlist tlsexport = *

[1] It may be more complex than that, of course.[3] While most MTAs operating in client mode would be expected to deal with a 2048 bit key, there are known older email clients that would not be able to cope with keys larger than 1024 bits. Servers may need to maintain backward compatibility for these older clients.

[2] Using GnuTLS to inspect the key negotiation is slightly more involved since you need to do the SMTP negotiation

$ gnutls-cli --crlf --insecure --starttls --port 25 220 ESMTP
EHLO Hello 250-AUTH LOGIN 250-AUTH=LOGIN 250-STARTTLS 250 HELP STARTTLS 220 TLS go ahead (Hit Ctrl-D) *** Starting TLS handshake - Ephemeral Diffie-Hellman parameters - Using prime: 768 bits - Secret key: 766 bits - Peer's public key: 767 bits [...] QUIT

[3] You'll note that the example above, adapted from a real "secure email provider", tops out at 768 bits. Which is still the US export limit for asymmetric algorithms used by exported software not in the public domain. They use a 2048 bit key merely to sign the small key used to encrypt the session.

15th December 2013 17:27:21 : No comments. Link