Sun now allows redistribution of Java by Linux and Open-Solaris distributions.
As a result of this move, there are now packages of Sun’s Java for Debian and Ubuntu.
The packaging code is largely based on the code we are using for Blackdown Java for some years. The code is available under the MIT license from the jdk-distros project on java.net. (More info on Tom Marble’s blog.)
I’m glad Sun finally opens Java up a bit after years of restrictive licensing.
I have upgraded this server to kernel 2.6.16.2. The next backup cycle resulted in a minor disaster: The backup process deadlocked at removing the first LVM2 snapshot and the snapshot source volumes were blocking write accesses. A cleanup shutdown was impossible and I had to hard-reset the machine.
After some searching I found out that you apparently need lvm2 2.02.01 or later and devmapper 1.02.02 or later to successfully remove snapshot volumes now. Unfortunately neither of these versions is available for sarge from Debian or backports.org yet, so I had to make my own backports.
As it turned out (see below), it is also necessary to use 2.6.16.12 or to apply the patch from this email to older 2.6.16 versions in order to reliably remove snapshots.
If you are brave enough, you can get the backported packages by adding
deb http://blog.blackdown.de/static/debian/lvm/ sarge main deb-src http://blog.blackdown.de/static/debian/lvm/ sarge main
to /etc/apt/sources.list
.
The repository contains debs for devmapper, dlm, lvm2, and lvm-common. The Release
files is signed with my GPG key. If you have a recent apt
version, you can authenticate the packages after importing the key with apt-key
:
wget http://blog.blackdown.de/static/gpg.asc -O - | \ sudo apt-key add -
April 15th, 2006: In about 40 backup cycles I’ve seen three lockups with 2.6.16.2 now. Until snapshots get fixed in 2.6.16, I’d recommend to stay with 2.6.15. I’m using 2.6.15.3 again now.
April 24th, 2006: Added note about “dm snapshot: fix kcopyd destructor” patch from Alasdair G Kergon. With this patch snapshots work fine for me again.
May 2nd, 2006: Alasdair G Kergon’s patch has been included in 2.6.16.12.
I got a new PowerMac G5 Quad a couple of weeks ago. Nice machine, except for the weak graphics and non-existent sound support on Linux.
The built-in sound card is completely unsupported at this time. As I did not feel like writing a driver for it, I plugged in an old USB sound device (Creative Sound Blaster Audigy 2 NX). At first this did not work, I just got oopses. But with a small fix (included in the kernel since 2.6.15.5) it started to work.
Next I tried to set up ALSA‘s dmix plug-in with S16 which resulted in horrible crackling: The byte swapping code was broken.
Also, ALSA’s softvol
plug-in (not strictly necessary but nice to have with GNOME’s volume control applet) didn’t work, it did not support any format available with snd-usb-audio on big-endian machines.
Here are the fixes for these two problems (against alsa-lib-1.0.11rc3):
If somebody is interested, here is the USB-Audio.conf I use with my Audigy 2 NX.
By the way: Is it normal that the dmix
plug-in consumes 100% CPU?
April 9th, 2006: The patches have been integrated into alsa-libs 1.0.11rc4, the 100% CPU issue is fixed in that version too.
There’s also a ALSA driver for the chip in the PowerMac Quad now, see this mail from Johannes Berg.
A few people have asked for an updated version of my Securing WordPress Admin Access With SSL guide. So here is an updated version for WordPress 2!
The situation has not changed much since WordPress 1.5: WordPress 2.0 still does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP and I still do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:
The Goal
All communication involving passwords or authentication cookies should be done over HTTPS connections. wp-login.php
and the wp-admin
directory should only be accessible over HTTPS.
Normal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.
The Plan
- Add an HTTPS virtual host that forwards requests to the HTTP virtual host
- Modify WordPress to send secure authentication cookies, so cookies never get sent over insecure connections accidentally
- Require a valid certificate on HTTPS clients. That means to log in to WordPress you need both a valid certificate and a valid password. If someone manages to get your password, he still can not login because he does not have a valid certificate.
The Implementation
Note: This documentation assumes a Debian sarge installation with Apache 2. Some things, in particular Apache module related ones, will be different on other systems.
The server used throughout the instructions is example.org/192.0.34.166. The server’s DocumentRoot
is /blog and WordPress resides in /blog/wp. The value of WordPress’ home
option is ‘http://example.org’ and the value of its site_url
option is ‘http://example.org/wp’.
- Prepare the SSL certificates:
- Generate your own certificate authority (CA) if you don’t have one already (I’m using the makefile from OpenSSL Certificate Authority Setup for managing mine) and import it into your browser.
- Generate a certificate for the SSL server and certify it with your private CA.
- Generate a certificate for your browser and certify it with your private CA. Most browsers expect a PKCS#12 file, so generate one with
$ openssl pkcs12 -export -clcerts \ -in blogclient.cert \ -inkey blogclient.key \ -out blogclient.p12
Then import
blogclient.p12
into your browser.
- Make WordPress SSL-ready:
Apply this patch to the WordPress code. It makes the following changes:- Use secure authentication cookies in
wp_setcookie()
- Make
check_admin_referer()
work with HTTPS URLs - Use HTTPS URLs for notification mails
- Use HTTPS URLS for redirects to
wp-login.php
- Only allow XML-RPC logins from the local host (ie. the HTTPS proxy)
- Add the Mark-as-Spam feature from trunk
The patch is against svn version 3825 of WordPress (ie. WordPress 2.0.3), when you apply it to a newer version, you will likely get some harmless ‘
Hunk succeeded
’ message. If you are getting ‘Hunk FAILED
’ message, just send me note and I’ll update the patch. - Use secure authentication cookies in
- Enable the necessary Apache modules:
- Install mod_proxy_html. It will be used to replace absolute ‘http://example.org’ HTTP URLs in the WordPress output with ‘https://example.org’ HTTPS URLs:
$ aptitude install libapache2-mod-proxy-html
The module gets enabled automatically after installation.
- Enable mod_proxy and mod_ssl
$ a2enmod proxy $ a2enmod ssl
Debian provides sane default configurations for both modules. You might want to take a look at the configuration files (
ssl.conf
andproxy.conf
) nevertheless.
I have changedSSLCipherSuite
toTLSv1:SSLv3:!SSLv2:!aNULL:!eNULL:!NULL:!EXP:!DES:!MEDIUM:!LOW:@STRENGTH
in
ssl.conf
in order to just allow TLS v1 and SSL v3 ciphers which provide strong encryption and authentication (see ciphers(1)). - If you are compressing WordPress output (that is if you enabled the ‘WordPress should compress articles (gzip) if browsers ask for them’ option) then also enable mod_headers:
$ a2enmod headers
- Install mod_proxy_html. It will be used to replace absolute ‘http://example.org’ HTTP URLs in the WordPress output with ‘https://example.org’ HTTPS URLs:
- Configure Apache to listen on the HTTPS port
$ cat > /etc/apache2/conf.d/ssl.conf << EOF <IfModule mod_ssl.c> Listen 443 </IfModule> EOF
- Modify the blog virtual host to limit access to
wp-login.php
andwp-admin
to the local host. Also completely deny access to files which should never be accessed directly. Here is an example:10-wp2-example.org
- Now setup the HTTPS virtual server:
20-wp2-example.org-ssl
If you are compressing WordPress output you have to enable theRequestHeader
line. - Enable the site and restart Apache
$ a2ensite 20-blog-ssl $ /etc/init.d/apache2 restart
- Remove the old WP cookies from your browser
- Test the new setup!
February 1st, 2006: wp2-ssl.patch updated for WordPress 2.0.1
March 11st, 2006: WordPress 2.0.2 has been released, fixing some security issues. The HTTPS patch still applies fine to that version.
March 19th, 2006: Updated wp2-ssl.patch. Changes: Fix bug in list-manipulation.php, use HTTPS for ‘Login’ and ‘Register’ links, backport ‘Mark-as-Spam’ feature from trunk
May 1st, 2006: WordPress 2.0.3 has been released. Here is the updated wp2-ssl.patch.
July 29th, 2006: WordPress 2.0.4 has been released, fixing some security issues. Here is an updated version of the wp2-ssl.patch.
January 12st, 2007: wp2-ssl.patch updated for 2.0.6 and 2.0.7-RC1
January 15st, 2007: WordPress 2.0.7 has been released. The patch still applies fine to that version.
The new evdev driver in XOrg 6.9 is broken on big-endian machines (e.g. powerpc). Here’s a patch that fixes the problem.