2009-03-31

Link collection 2009/03

Posted in Computers, PlanetDebian, Random links at 14:22 CEST (+0200) by sven

Well, I normally despise of thinks like this link collection, but I thought I might add it anyway, since these are useful links for me and if I don’t post them here, I’m likely to forget where to find them in the near future:

  1. Sean Finney has a nice post about storing the list of parameters a (shell) script got in a way that it can be restored later. Quite handy if your script walks through the arguments parsing them (and consuming them while doing so) but you want to be able to display them in a helpful way if the parsing fails at some point.
  2. A while ago, Ingo Jürgensmann had a post that helps retrieving files from lost+found after a filesystem check, provided that you run his helper script on a regular basis. The same approach can also be used if you have a backup of all files, but lost the sorting work you did after the backup was done. This is possible because running the script can be done more often then you would normally do backups.
  3. He also has a small post about mtr oddities when IPv6 comes into play
  4. Adeodato Simó wrote about databases and when timestamps that store the timezone information really are more useful then timestamps that don’t.
  5. Adeodato also has a short post on using ssh as a socks proxy, which can be quite handy if you are behind a firewall.

Update: Fixed link to Ingo’s file retrieval from lost+found article. Thanks to Patrick Schoenfeld who pointed me at the wrong link.
Also thanks to the anonymous poster who found an alternative way to store and (in a way) restore commandline parameters. The solution doesn’t work in an as general way as that by Sean Finney et al., but it is much shorter and therefore interesting for where it can be used (when you control how commandline parameters are processed). See comments on this post for details.

2009-03-26

Apache SSL oddity

Posted in Computers, PlanetDebian at 16:07 CET (+0100) by sven

If you ever have the problem described below, you have to realize that Apache HTTPD is selecting the SSL certificate (and/or key) not based on you VirtualHost definition, but based on the ServerName in the current context. This means that you have two virtual hosts with the same ServerName, but on two different IPs, and are wondering why the wrong key (and/or certificate) is used, it might be because of this. Assume we have the following (simplified) configuration:


<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>

(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA)

Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL).

This might as well be a bug or a design decision (AKA feature), I don’t know. However the “workaround” that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won’t do for the reverse/application proxy part).

Update: Fixed formatting on configuration sample to make it clear this is not about namebased virtual hosts.

2009-03-01

Rescueing files from lost+found

Posted in Computers, PlanetDebian at 18:49 CET (+0100) by sven

Oh well, I tried to search for it but failed miserably, so I’m blogging about it hoping the original author might read my post on planet.debian.org (where I read the original post):

A friend of mine might need exactly the sort of scripts someone posted here:

  1. Creating a list of file checksum+pathname/filename
  2. Reading files from lost+found and moving them to their original filename by identifying from the list in (1)

However, I can’t recall who posted about this, and don’t want to do the same work again. Please, Dear Lazyweb, help me ;-)