wjd.nu

2006-11-21 - irssi / utf-8

irssi, the best irc client out there, has excellent character encoding/translation support. The following should speak for itself. Just make sure you're using 0.8.10 or later.

/set term_charset utf-8 (your own terminal charset)
/set recode_autodetect_utf8 ON (detect UTF-8 in a non-UTF8 channel)
/set recode_out_default_charset iso-8859-15 (default channel encoding)
/recode add #your_utf8_channel utf-8 (set UTF-8 as encoding on #your_utf8_channel)

2006-11-20 - mod_php4 / php5-cgi / apache2

Running mod_php4 and php5-cgi together on the same apache2 install on your debian/stable box is easy. Unfortunately many HOWTOs give anwers that are incomplete or do not work.

A solution that works for me is the following. I assume you already have mod_php4 installed and working for .php files.

(1) Get the debian backports archive url in your sources.list. Add the following line to /etc/apt/sources.list.

deb http://www.backports.org/debian sarge-backports main contrib non-free

(2) Fetch the php5-cgi package. (First apt-get update, then apt-get install php5-cgi.) Assert that you now have /usr/lib/cgi-bin/php5, the php5 cgi binary.

(3) Add the following two lines to your /etc/apache2/apache2.conf to start recognising .php5 files.

AddHandler php5-script .php5
Action php5-script /cgi-bin/php5

Remember that this will only work when you actually do have /cgi-bin/ ScriptAlias'ed to /usr/lib/cgi-bin/ for the particular VirtualHost you want to use php5 on.

(4) Make sure mod_actions is enabled (a2enmod actions), otherwise you'll get this message: Invalid command 'Action', perhaps mis-spelled or defined by a module not included in the server configuration.

(5) Restart apache2 (/etc/init.d/apache2 force-reload) and test your php5 scripts with phpinfo.php5:

<?php phpinfo(); ?>

Enjoy.

Now you'll want your *.php5 files to be automatically recognised by one of the best editors out there (vim). See this diff:

--- /usr/share/vim/vim63/filetype.vim.orig      2006-11-27 10:47:21.456177336 +0100
+++ /usr/share/vim/vim63/filetype.vim   2006-11-27 10:42:53.517910144 +0100
@@ -986,7 +986,7 @@
 au BufNewFile,BufRead *.pod                    setf pod

 " Php3
-au BufNewFile,BufRead *.php,*.php3             setf php
+au BufNewFile,BufRead *.php,*.php3,*.php4,*.php5 setf php

 " Phtml
 au BufNewFile,BufRead *.phtml                  setf phtml

2006-10-29 - smb/cifs links / firefox / linux

Getting these pesky smb:// links (SMB/CIFS filesystem) to work properly under Firefox under Ubuntu/Linux is as easy as cake.

"Surf" to about:config and add/edit the following values:

network.protocol-handler.app.smb = (string)"/usr/bin/nautilus"
network.protocol-handler.external.smb = (boolean)true

Now nautilus - your default file browser - will take care of links starting with smb://. This means that you'll be able to open files instead of downloading them.

Of course this is known to many, or this might already work in your setup. But for me it was hard enough to find to be mentioned here.

See also: Irigo Files: Tilslut netværksdrev fra Firefox og Mac for the solutions for Windows, Linux and OSX (it's in Danish, but you should be able to read it) or Opening SMB/CIFS shared files using the Opera browser for the solutions for Opera and Firefox for Windows.

2006-10-23 - on getting slander removed from google

So someone used your name to sign a bullshit article on the internet in a childish attempt at being funny. You call the maintainers of the site to get the article removed, they comply, but google still has the article cached. Now everyone will still think that you are gay (like that would really be something to be ashamed of *sigh*). So you call again to get the article removed from the google cache. The site maintainers get out of their way to make sure that your article is removed from the google cache whilst keeping their other articles in the cache.

It works see, no link to a cached version of the article anymore. You're home free... not, haha :-D

Lessons to learn. You're better off waiting for the googlebot to update the cache with the newer empty (cleaned) version.

2006-09-26 - useful linux tools

At times there are things you never need to do in Linux, but need right now.

Getting or setting the duplexicity (full-duplex or half-duplex) and speed of a network interface card. (mii-tool(8) from the Debian net-tools package.)

# mii-tool [dev]

Rebooting a Windows NT (or compatible machine) from a linux box. (net(8) from the Debian samba-common package.)

# net rpc shutdown -r -f -I <ip> -U <user> -n <netbiosname>

2006-09-04 - apache2 / ssl / multiple virtualhosts

A howto on getting multiple name-based virtual SSL hosts on the same server, IP and port.

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2 writes:

Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.

It comes as rather a shock to learn that it is impossible.

This is the case because the SSL session takes place before the HTTP session has begun and therefore no Host: header has been sent with which to decide which to virtual host the request should go. They go on to mention that possible workarounds include (1) using different ports for different vhosts or (2) using different IPs.

Method (2) is not always possible. Many people only have one IP address at their disposal. Method (1) is almost always possible, but that is simply not kewl.

What you end up with without either of the aforementioned methods is a webserver directory structure like:
https://ssl.your-domain.tld/somesite/
https://ssl.your-domain.tld/someothersite/
https://ssl.your-domain.tld/yetanothersite/

Well, if you're like me, and have your /var/www/ directory organised in exactly the same way, there is method (3) that will help you get proper https virtualhosts. I.e. your /var/www/ looks like this:
/var/www/somesite
/var/www/someothersite
/var/www/yetanothersite
With a tiny bit of mod_rewrite voodoo we can let you have those multiple vhosts on the same IP and port. As long as you can live with the fact that they will all use the same certificate.

The setup is as follows. You have your configuration with one virtualhost for your SSL traffic on port 443. This will be the default config in which you have to add all vhost directory configurations that you want secured. (Let's name it default-ssl.) Now, we'll (re)place the following stuff in your VirtualHost block for port 443:

RewriteEngine On
#RewriteLog /var/log/apache2/default-ssl-rewrite.log
#RewriteLogLevel 10

DocumentRoot /var/www/
<Directory "/var/www">
  AllowOverride None
  Order allow,deny
  deny from all
</Directory>

# You'll get warnings in the errorlog about your certificate
# not belonging to the vhost. Set it to error.
LogLevel error
# Add the host header to the combined log.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %{Host}i" combinedvhost
CustomLog /var/log/apache2/default-ssl-access.log combinedvhost

You used to have a Directory directive in /etc/apache2/sites-available/somesite? Place that block in your default-ssl. And add the appropriate rewrite rules which internally rewrite https://abc.yz/def to /var/www/abc/def.
Repeat as often as desired.

RewriteCond %{SERVER_NAME} =somesite.tld
RewriteCond %{REQUEST_URI} !^/somesite\.tld/
RewriteRule ^/(.*) /somesite%{REQUEST_URI}
<Directory "/var/www/somesite">
  AllowOverride None
  Order allow,deny
  allow from all
</Directory>

There are of course drawbacks, but maybe you can live with them... I can.

• You'll be using the same certificate for all virtual hosts.
• All the logs will wind up in the same file. (Logically in: /var/log/apache2/default-ssl-*.log.)

2006-09-04 - apache2 / mod_ssl / setup

Setting up https support on your apache2 which was configured for http support only, is quite trivial as long as you remember to add the correct stuff in the correct locations. This howto assumes that you're running debian/sarge, but it will mostly apply to any other distribution as well.

A quick summary:

Step 1: add port 443 to /etc/apache/ports.conf.

<IfModule mod_ssl.c>
  Listen 443
</IfModule>

Step 2: add mod_ssl symlinks in mods-enabled.

# cd /etc/apache2/mods-enabled
# ln -s ../mods-available/ssl.* .

Step 3: replace the NameVirtualHost * directive with two directives for port 80 and port 443. This directive is in /etc/apache2/sites-available/default by default, but I prefer to place it in /etc/apache2/apache2.conf because it applies to all sites, not only the default site.

NameVirtualHost *:80
<IfModule mod_ssl.c>
  NameVirtualHost *:443
</IfModule>

Step 4: convert <VirtualHost *> to <VirtualHost *:80> in all site declarations in /etc/apache2/sites-available/.

Step 5: replace the port 80 virtual host directive with <VirtualHost *:443> for the site for which you want SSL enabled and add the following stuff to redirect http access to https in the same site declaration file (this assumes you have rewrite.load in your mods-enabled directory).

<VirtualHost *:80>
  ServerName your-site-name
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
</VirtualHost>

Step 6: create a certificate for your site. Put these files in a proper location somewhere (e.g. in /etc/apache2/ssl/) and make them readable by root only.

# openssl genrsa -des3 -out server.key 1024
# openssl rsa -in server.key -out server.pem
# openssl req -new -key server.pem -out server.csr
# openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt

Step 7: add this to your SSL enabled site configuration. You can use the .key file instead of the .pem file, but then you'll have to enter the password every time you start apache2.

SSLCertificateFile ssl/server.crt
SSLCertificateKeyFile ssl/server.pem
SSLEngine On

Step 8: restart apache and you're ready to go. Note that you can only have one https site per IP address. I don't know why this is because I haven't bothered to find out yet.

Enjoy! :-)

2006-09-04 - debian/sarge / sa-exim / bayes

After upgrading debian/sarge, the bayesian filtering in sa-exim stopped working. I don't know what changed exactly, but somehow spamassassin didn't read the bayes database from the correct location anymore. Previously sa-exim would call spamc as the Debian-exim user and therefore it would look for the bayes database files in /var/spool/exim4/.spamassassin/ (the Debian-exim home directory). Adding byes_path /var/spool/exim4/.spamassassin/bayes to /etc/spamassassin/local.cf did the trick to get the site-wide spam filtering back up and running.

When I have the time, I may write a small setup howto for sa-exim on debian.

2006-07-16 - SimpleXMLRPCServer / python / trouble

Using xmlrpc to communicate between php and python seemed like a good idea. Fire up the SimpleXMLRPCServer and talk to it with python using curl and xmlrpc_encode_request. This worked perfectly fine, apart from the fact that documentation on using namespaces or using object methods isn't all that obvious. Functions could be called.

Calling functions with larger than small arguments (a relatively small dictionary) however were causing weird failures. A nice traceback was printed, and after adding a print statement, "no element found: line 1, column 0" could be found. As far as I could find, this happened after XML_CONTEXT_BYTES has been reached on the input side. Somehow the xml parsing (expat I suppose) failed after that many bytes (1024 in my case).

mod_python, pyro and Cheetah it will be then...

2006-07-15 - Internet Explorer / alpha channel png

Everyone knows that Internet Explorer doesn't handle the alpha transparency channel in portable network graphics (png) files. A tiny bit of javascript can fix this quickly for you, because Microsoft does have a proprietary filter style extension that does do correct png handling.

Step 1: create a transparent gif file (100x100 should be fine).

Step 2: put the following script somewhere and run it at onLoad time (e.g. by adding window.onload = function() { ... }). Make sure you check the browser make first: navigator.appName == 'Microsoft Internet Explorer'.

function iefix_replacePng() {
  for(var i = 0; i < document.getElementsByTagName('IMG').length; ++i) {
    var elem = document.getElementsByTagName('IMG')[i];
    if(/\.png$/.test(elem.src)) {
      /* Set the filter and escape single quotes. */
      elem.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"
          + elem.src.replace(/'/g, "\\'") + "', sizingMethod='scale')";
      /* Replace this with the path of your blank image. */
      elem.src = 'images/blank.gif';
    }
  }
}

2006-07-02 - exim4 / sa-exim / spamassassin

Tor Slettnes writes in 2004 that "SA-Exim does not pass the recipient username to SpamAssassin". Knowing that would have saved me some failed configuration attempts. Unfortunately now I'm stuck using a site-wide bayes database, instead of a per-user configuration. The other option would be to read and implement lot's of stuff which I'm not about to do any time soon.

It would've been nice to simply have an option to do SAspamcpath: /usr/bin/spamc -u ${destination_user} in /etc/exim4/sa-exim.conf.

2006-06-23 - uw-imapd / no SSL / login

After upgrading the uw-imapd debian/stable package (from a rather old version), the regular LOGIN command fails to work (which your SquirrelMail configuration might have been using before). Plaintext passwords have been disabled by default. Obviously SSL and secure login (etc.. etc..) is better, but a quick fix is to put the following text in /etc/c-client.cf:

I accept the risk
set disable-plaintext nil

2006-06-05 - mount / utf8 / vfat

Beware: when doing a mount of a vfat filesystem on your UTF8-ified linux distribution, make sure you append the utf8 option to mount. Otherwise your LFN (long file name) entries will get doubly encoded.