Log

In kind of a follow up to my previous post on using find and sed to search and replace multiple files, I found out something else.

I needed to find and replace something in every file, except for any files which had ".svn" in them. After struggling for a few fruitless minutes with -regex, I stumbled upon this example in the manual page:

find /sbin /usr/sbin -executable \! -readable -print

   Search for files which are executable but not readable.

The \! allows us to invert the tests after it. Perfect! All we need to do is use -regex to do our excluding:

find . -type f \! -regex ".*\.svn.*"

And we can now search and replace in all files except those that have ".svn" in them:

find . -type f \! -regex ".*\.svn.*" -print0 | xargs -0 sed -i "s/foo/bar/"

Neat. Note that, again, -regex is a GNU find only construct.

I always kept a small Python script around for searching and replacing in Linux. Turns out that GNU sed has an inline edit mode which I didn't know about:

       -i[SUFFIX], --in-place[=SUFFIX]

              edit files in place (makes backup if extension supplied)

This makes searching and replacing in files as simple as:

find . -name "*.txt" -print0 | xargs -0 sed -i "s/foo/bar/"

This replaces all occurences of "foo" with "bar" in all the .txt files in or below the current directory.

Unfortunately, -i appears to be a GNU extension, so it won't work on *BSD or Solaris, probably.

I have a laptop that travels with me to work as well as being used at home. I have a number of network CIFS mounts that I like to have available when I am at home, so I have them set to "auto" in /etc/fstab. [...] The problem is that when I shift locations, I need proper handling of those network mounts.

Handling network mounts on a very mobile laptop.

Since Debian 4.0 or some such, when your MAC address changes, your interfaces changes too. So if you spoof the MAC address of your nic, or you clone a Debian 5.0 VirtualBox guest and assign it a new different random MAC address, or if your nic broke down and you replaced it, the new nic will be assigned to eth1 instead of eth0 (if you previously only had one network card in your machines, that is). Chances are your statically defined network settings (in /etc/network/interfaces) will not work anymore, because they refer to eth0, and not to eth1.

The reason behind this appears to be Udev. It keeps a list of MAC addresses and which interfaces they were assigned to, and when it sees a new MAC, it assumes that is a new network card, and so assigns it a new ethX interface. This is both a good thing, as it will keep your system from rearranging all the nic's if you add one or one dies, and a bad thing, as your network will not come up anymore if you've replaced the previous nic

To fix this, log in at the console as root, find a file named something like persistent-net.rules in the /etc/udev/rules.d/. The file may be prepended with some and remove all the lines in that file below the You can modify it... line.

When done, reboot. (I haven't yet found out how to regenerate the file. Running the executable the file mentions doesn't work for me).

ArchFS is a FUSE (user-space, so it does not require a special kernel module, other than the FUSE kernel module) file system on top of rdiff-backup (an incremental backup tool). It allows you to mount a rdiff-backup repository and then provides an easy way to maneuver through the various revisions in that repository.

Here's an interesting article on trying to understand TCP performance. It discusses how the TCP flow-control window (receive buffer), window scaling, selective ACKs and some other TCP features/options affect your link's speed. Of course it's only a tiny fraction of the total picture that is link performance, but it's an interesting read.

There's also a webpage which inspects the TCP options your browser sends and calculates it's maximum theoretical speed.

I used to be real pleased with Ubuntu, because it got a couple of things right that Debian didn't. But I've upgraded my Ubuntu install three times now, and every time I upgraded everything broke.

The last time I upgraded, everything even remotely having anything to do with sound broke. This was because the geniuses at Ubuntu decided to include the shitty PulseAudio sound architecture in Ubuntu way before it was ready to be included. (Yeah, I know, not really PulseAudio's fault, but I'm just trying to get the PulseAudio crowd pissed at the Ubuntu crowd in the hopes that they'll gun them down).

Last time I upgraded, from Hardy to Intrepid, all my sound stuff broke again, flash didn't work anymore, my wireless broke (I've kind of fixed it now, but now NetworkManager keeps dropping the wireless connection when I push too much data through it, and can't get up again without a reboot – piece of shit), my hotkeys and all my keybindings broke, my sessions weren't saved anymore, my sound applet refuses to address the right mixer channel, my ~/.xinitrc is being ignored, I can't rm -rf / anymore (my favorite past-time thing in Linux :-( ).

Each time I upgraded Ubuntu, I found myself doing a clean install a couple of days later because too many things had broken. And even after that, many of the broken things were still busted.

I've had it with Ubuntu. It's a piece of shit. I'm going back to Debian Stable.

FastCGI is a hybrid solution to serving web applications written in a wide variety of programming languages. It sits somewhere between CGI, which spawns a new instance of the web application for each request, and the various web server modules (such as mod_php, mod_python and mod_wsgi) which take care of pre-spawning a pool of interpreters and web applications from within the web server, which will then handle requests.

FastCGI, too, can take care of spawning a pool of web application instances to handle requests. It can also facilitate communications between a web server and an external, already running web application. Unlike CGI, FastCGI does not spawn a new process for each request, and unlike the various web server modules it is not completely embedded within the web server. Instead it uses TCP/IP or Unix sockets to communicate to the web application. This makes it possible to create advanced setups such as spreading out requests over multiple servers, limiting web applications' rights and system resources using the standard Unix tool-set, etc.

FastCGI is available for a large range of web servers, is fast and is powerful and versatile in its capabilities. It is however not well documented, nor easy to set up. This document covers the basic idea behind FastCGI, setting up FastCGI for Apache (v2) and hooking it up to a simple Python web application. Such a light-weight setup, which requires nothing more than a FastCGI Python library, can provide an alternative Python web development environment for people who feel that the Python web development frameworks (Django, Pylons, TurboGears and even Web.py) are too bloated.

Jump to this document.

For a long time Apache only supported a single authentication provider per location. For instance, you'd have:

<Location />
    Require valid-user

    AuthType Basic
    AuthName "FooCoorporation"
    AuthBasicProvider ldap

    AuthzLDAPAuthoritative Off
    AuthLDAPURL ldap://192.168.1.1:389/ou=foo,o=electricmonk,c=nl
    AuthLDAPBindDN cn=ldapreader,o=electricmonk,c=nl
    AuthLDAPBindPassword PASSWORD
</Location>

In older Apaches, it wasn't possible to add another Authentication provider. So, in the situation above, you can run into problems when your LDAP server dies on you, and you won't be able to login to the / location anymore until the LDAP was fixed. Another problem with single authentication mechanisms is that there's no way to add authenticated users if they're not in the LDAP.

Since Apache 2.2 multiple authentication providers are now supported. This is nice, since now you can have an LDAP authentication provider with an htpasswd fallback authentication mechanism.

You can enable it by specifying multiple AuthBasicProvider providers:

    AuthBasicProvider ldap file

So the full Location section becomes, for example:

<Location />
    Require valid-user

    AuthType Basic
    AuthName "FooCoorporation"
    AuthBasicProvider ldap file

    AuthzLDAPAuthoritative Off
    AuthLDAPURL ldap://192.168.1.1:389/ou=foo,o=electricmonk,c=nl
    AuthLDAPBindDN cn=ldapreader,o=electricmonk,c=nl
    AuthLDAPBindPassword PASSWORD

    AuthUserFile /var/www/.htpasswd
</Location>

There's a web-crawler out there called VoilaBot, which is hammering my site with needless crawls and which appears to ignore robots.txt files completely. Apparently it's a crawler for a french portal/search engine. If you need to block this bot from your site, there are two things you can do:

Firewall

If you've got a firewall on your box, you can deny access to the two IP ranges 81.52.143.0 / 24 and 193.252.149.0 / 24. That'll get them off your back permanently. For Linux machines with iptables firewall, the following will do the trick:

iptables -A INPUT --source 193.252.149.0/24 -j DROP
iptables -A INPUT --source 81.52.143.0/24 -j DROP

htaccess

If you don't want to firewall the bot, you can deny them access to your website by putting a .htaccess file in your web root directory with the following contents:

order allow,deny
deny from 81.52.143.
deny from 193.252.149.

Don't trust VoilaBot to honour your robots.txt file; it won't.