Xavier Robin – Tag – My website

Switching to Catalyst

2012-01-07T16:42:10+01:00

It should be rather transparent, but I just switched my website from ePerl to Catalyst, as announced before. The application should be a bit more reliable (less error 500 pages, that is after the initial debugging period).

2011-02-14T09:04:02+01:00

Installing a recent mod_fastcgi in Ubuntu 10.04.1

2011-01-09T15:07:45+01:00

Yesterday I found I had a conflict between mod_deflate and mod_fastcgi. The bug is known to Ubuntu, but the proposed fix has never been committed. So I tried to install it manually. Here are the steps:

Go to http://www.fastcgi.com/dist/ and get the latest snapshot (for me it was the 05-Oct-2009 snapshot)
```
wget http://www.fastcgi.com/dist/mod_fastcgi-SNAP-0910052141.tar.gz
```

Extract and change directory:

tar -xf mod_fastcgi-SNAP-0910052141.tar.gz 
cd mod_fastcgi-SNAP-0910052141/

For Apache2, the installation instructions are in INSTALL.AP2. You just need to cp Makefile.AP2 Makefile and then make and make install. But make doesn't run and complains about a missing file instead
```
Makefile:12: /usr/local/apache2/build/special.mk: No such file or directory
make: *** No rule to make target `/usr/local/apache2/build/special.mk'.  Stop.
```
Hopefully the fix is trivial: in fact apache2 is in /usr/share/ instead of /usr/local/, so the following command will fix it:
```
sed 's/\/usr\/local\/apache2/\/usr\/share\/apache2/' Makefile
```
Now we can make and sudo make install. Don't forget to sudo apt-get remove libapache2-mod-fastcgi before. In my case I used checkinstall instead of make install to avoid messing the system.
Re-enable mod_fastcgi with a2enmod fastcgi.

That's it! Enjoy your browser not throbbing more than needed!

Switch to Catalyst

2011-01-08T19:30:02+01:00

There hasn't been much visible activity here recently. But it doesn't mean nothing is moving: I'm currently trying to switch from ePerl to a Catalyst application.

Using DBIx::Class to handle database queries is very slow in CGI mode, as everything must be reloaded each time a page is displayed (and DBIx::Class is huge at that). Basically, each page require at least 1 second to build, half of it is loading the perl libraries. The server load is very low, so it's not a problem here; but it is one for you who need to wait each time you want to see a page! After considering switching to mod_perl, I decided to prefer FastCGI that will be more memory friendly (there is only 256 MB here, so I'd better not load the application in every apache process serving static content!) I could probably have done it with ePerl, but I already built a Catalyst app in the past, and that was fun and efficient.

The application is nearly ready. I still need to fix a known bug with mod_deflate that keeps Firefox throbbing after the page is loaded (it took me days to figure out what was happening!) The admin part is not done yet, but it can wait a bit. Normally you won't see any difference in the beginning… except that pages will load faster! Stay tuned…

2010-06-27T16:35:29+02:00

Tags cloud

2010-06-13T19:34:58+02:00

There are several CPAN modules to generate tag clouds. To cite only 3 of them:

I just added tags cloud on this site (look the new home page!) with Data::CloudWeights. HTML::TagCloud generate ugly HTML and CSS that cannot be modified. HTML::TagClouder is marked as *WARNING* Alpha software! I mean it! Not for me, thanks!

Data::CloudWeights is far the most flexible. It generates an arrayref of hashes from which you can pick size, occurences, colors and so on. I use the following subroutine to generate the cloud with a very simple and standard code:

use Data::CloudWeights;
sub tag_cloud {
	my @tags = @_;
	my $cloud = Data::CloudWeights->new;
	for my $tag (@tags) {
		# The followin line is a bit more complicated than shown here
		# $tag is a DBIx::Class entry with more columns than displayed here
		$cloud->add($tag->tag, scalar  $tag->links, "/tag/" . $tag->tag);
	}
	my $cloud_html = "";
	foreach my $tag (@{$cloud->formation}) {
		$cloud_html .= '<a href="' . $tag->{'value'} .
			'" style="font-size: ' . $tag->{'size'} . 'em">';
		$cloud_html .= $tag->{'tag'};
		$cloud_html .= '</a>';
	}
	return $cloud_html;
}

ePerl

2010-06-13T18:32:35+02:00

There are two versions of ePerl:

The former is a C wrapper around a perl module. The latter is written entirely in perl.

I was using Ralf S. Engelschall's version until now, because it is in Debian repositories. However, I wanted to return an HTTP 500 code upon error, so that Google would't index errors (as it currently does). It is hard-coded in the C code. Rather than recompiling, I tried the newer version from MarginalHacks. The error code is hard-coded as well, but it is in Perl, so easier to rewrite and to link with my standard error code.

I had to modify my shebangs (#!/usr/bin/eperl.pl --mode=CGI is fine), and also to correct an error in eperl.pl by adding

@files = $ENV{"SCRIPT_FILENAME"};

inside the

if ($opt{'mode'} ne "f") {

block (that is, between lines 220 and 224), because we don't want to use the HTTP path passed as argument in CGI mode, but rather the script file name.

Unfortunately, I quickly noted that this new ePerl looses STDIN data. That means, no POST data available in the script: and I use that for comments and contact. There is a -t argument, but it had no effect for me. I'll stick to the old ePerl for the moment, and try to make sure my code runs fine, but I'll need to have a closer look into what happens exactly with input sooner or later.

Frayeur avec iptables

2010-06-08T17:51:42+02:00

La frayeur du jour : serveur bloqué par iptables ! J'avais pourtant fait attention de bien ouvrir les ports nécessaires :

iptables -P INPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 123 -j ACCEPT # ntp
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -P INPUT DROP

Heureusement, la console Gandi permet d'accéder à son serveur même bloqué pour en rétablir l'accès. Ouf ! Après quelques recherches, et la lecture d'un billet de SelbyTech sur iptables, je suspecte que l'interface loopback doit être nécessaire pour SSH, Apache et cie. Voici donc finalement les règles que j'ai utilisé :

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 123 -j ACCEPT # ntp
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

J'en profite pour ajouter une règle de SpamCleaner, et de l'adapter à une série de requêtes tentant (sans succès) d'accéder à un site distant détectée dans les logs d'Apache :

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET http://' -j DROP

Tout à l'air de bien fonctionner. Au final, le serveur n'aura été inaccessible que quelques minutes.

Commentaires ouverts

2010-06-05T21:01:07+02:00

Voilà, les commentaires sont ouverts ! Le site commence à prendre de la forme. Il reste encore à récupérer mes anciens billets postés ailleurs, et pas mal de détails à ajouter, mais globalement toutes les fonctionnalités importantes sont là.

Si vous rencontrez un problème, n'hésitez pas à le rapporter. Si le problème est avec les commentaires, au moins un des moyens indiqués sur la page contact devrait fonctionner.

Nouveau blog

2010-05-16T15:29:37.137915000+02:00

Encore un nouveau blog. Après avoir essayé Drupal (trop compliqué), Dotclear, Serendipity, Bloxsom, j'ai décidé de me coder un petit blog personnalisé en ePerl, avec une base de données PostgreSQL. Il y a encore pas mal de boulot avant d'avoir quelque chose de vraiment utilisable, mais je suis définitivement sur le bon chemin.