Thorsten Glaser: Apache 2, https clients linked against GnuTLS, connection errors
I ve been debugging a weird problem at work after upgrading a
complex system from lenny to wheezy, some https clients
failed to connect: GNU wget and Debian s version of lynx(1) which
is linked against libgnutls26 fail. NSS applications continue to
work, as does cURL; wget and lynx on MirBSD (linked with OpenSSL
of course) work. Even Debian s gnutls-cli tools from both gnutls26
and gnutls28 work. Huh. The error_log shows renegotiation problems,
yet setting the new Apache 2 configuration option to use insecure
renegotiation doesn t help either. (The option is a total #FAIL:
its only other value is use secure TLSv1.x renegotiation , but I
don t want/need SSL renegortiation at all, anyway.) Natureshadow
told me this was a hot issue on Debianforum at the moment, yet,
nobody had a clue or enough information to file a formal bugreport
against (initially) apache2, as that s what changed. I tracked it
down on a new VM with no configuration otherwise, and here are my
findings so others don t run into it.
Tracking down the problem, this can be reduced to the following configuration (minimised, to show the problem) in /etc/apache2/sites-enabled/1one:
<VirtualHost *:443> ServerName wiki-70.lan.tarent.de RedirectMatch permanent . https://evolvis-70.lan.tarent.de/ SSLEngine on SSLCertificateFile /etc/ssl/W_lan_tarent_de.cer SSLCertificateKeyFile /etc/ssl/private/W_lan_tarent_de.key SSLCertificateChainFile /etc/ssl/godaddy.ca </VirtualHost>
Do not mind the actual content, this is a very stripped-down demo on a not-actually-set-up-yet box.
Same is valid for the companion configuration file /etc/apache2/sites-enabled/2two:
NameVirtualHost *:443 <VirtualHost *:443> ServerName evolvis-70.lan.tarent.de SSLEngine on # workaround for BEAST (CVE-2011-3389), short-term SSLCipherSuite RC4-SHA SSLCertificateFile /etc/ssl/W_lan_tarent_de.cer SSLCertificateKeyFile /etc/ssl/private/W_lan_tarent_de.key SSLCertificateChainFile /etc/ssl/godaddy.ca SSLProtocol TLSv1 </VirtualHost>
Turns out the BEAST workaround was at fault here: the differing SSLCipherSuites between the vhosts (on the same Legacy IP / TCP Port tuple, as we use Wildcard SSL Certificates) made Apache 2 want to renegotiate, so either commenting it on 2two or, better, adding it to 1one helped. Interestingly enough, the SSLProtocol directive did not matter (in my tests). So, keep SSL settings synchronised between vhosts. In fact, those were already from include files, but 2two was from the Evolvis 5 generation, whereas we added to 1one an Include of the httpd.ssl1.inc file generated by the previous releases of EvolvisForge and had not switched those legacy vhosts to the new configuration, as everything worked on lenny. This wlog entry brought to you by the system administrators of tarent solutions GmbH and the Evolvis Project, based on FusionForge.
It feels like I'm sitting in a roller-coaster wagon. There's probably
too much change going on for me to assimilate naturally. In
particular:
I just wrapped up (well, mostly) one of the toughest Uni semestres. I had
to deal with lots of very time consuming assignments, and then the usual
round of final exams. Even if this semester I got the best marks in my
journey (or shall we say Via Crucis) through University, I still
managed to fail one exam, for the Advanced Networks subject, which is
quite annoying, given I got high marks (even the highest in one case) in
other subjects I really don't master at all. In any case, this is the end
of the pain. The only thing that's left is just one exam and a project
based on GNU/Linux technologies which will basically mean formatting for
prettyness the sysadmin docs we've been collecting at the office during
the last few years. This effort will be nothing to what I've been doing
during the past 18 months, so I'm really relieved to have it past me
already.
Getting rid of studies comes just two weeks before a big change in my
professional career. Friday was my last day at the
When I was first approached about this, I thought Collabora was a small
company. But as I looked more into it, I discovered that's not longer the
case, there's many more people than I imagined working there (here!), and
was delighted to see I knew many of them, and many other are well known
members of the major Free Sofware communities. I'll be joining the
sysadmin team to work closely with
I ve recently gone through some of the unpacked source sitting in the lintian lab, and I ve got a few cool stats.
First of all, the types of VCS tags I ve found:
Not much progress ATM (most translations are complete and D-I has been
frozen to prepare its release anyway).
Nothing special here. You would have seen a similar window before if you have installed apport. What changes with this release is, that now, when you check the Send an error report to help fix this problem, it will really file a bug report on the BTS.Here's what the emailed bug report will look like: 
A couple of days ago, I had
Getting Hotplugging working with a DisplayLink USB to DVI adapter
I merged Dave Airlie s randr provider patches to the server and pushed
them out in preparation for freezing the X server for the version 1.13
release. Before freezing, I figured I should at least test hotplugging
my DisplayLink adapter. Well, that took all day
Sources
For the impatient, here s where all of the bits are. These work on my
machine.
Upstream bits:
A year ago, I bought a 
My problem is that there's obviously no way to know the battery status from
Linux, the provided application only working on Windows.
And one dark night, while fragging on QuakeLive, my keyboard stopped
working: it had no battery left. This activity being quite energy consuming,
it emptied the whole battery.
Someone should write code to get the battery status and light meter from
Linux: challenge accepted!
How the keyboard works
I've been working the past two days on debian-cd, which was the main
thing (besides git-annex assistant) I planned to work on at DebCamp.
Yesterday, Steve McIntyre and I cleaned up some cruft in debian-cd's
package lists. This freed somewhere in the area of 30 mb. I also took a
grep through d-i and made sure the CDs include packages that d-i can
optionally install in some situations.
Today, I investigated how Recommends are ordered on the CD, and concluded
it's as close to optimal as can be easily achieved. So was not able to save
space there, but I did find a way to reorganize the desktop task that avoids
needing to include a lot of printing stuff and some other stuff on the
first CD. While that helped some, it still didn't get either Gnome or Kde
to entirely fit, so getting there will probably involve rebuilding 100 or
so packages with xz, if someone decides to do that.
So it's stil TBD whether Gnome or Kde will fit on a single CD in Debian
wheezy. At this point I think most of us are getting tired of fighting this
increasingly losing battle every release, and so other options like only
having a desktop DVD are looking more appealing, as they solve the problem
long-term. This would also free up the first CD for other interesting
use cases, perhaps xfce, or perhaps a CD targeted at server users, and/or
containing high-popularity non-desktop packages.
