Vlogger with a named pipe

In an old post I dealt with the nice mod_chroot module to secure your multisite server. I also adopted recently vlogger in order to manage better apache logs for virtual hosts, when you have dozens or hundreds of them. Unfortunately the suggested way to use it (a simple piped command) does not work nicely with mod_chroot, because the piped command has to run in the chroot jail.

Of course, it is not a good idea installing the whole perl intepreter and all required modules in a minimized jail, so I adopted an oldish classic trick (the old things are always the best) to solve the issue: using a named pipe. You basically need to do something like the following:

mkfifo -m 600 /var/run/apache2/logger && chown www-logs /var/run/apache2/logger

cat /var/run/apache2/logger | /usr/sbin/vlogger -u www-logs -g nogroup -s access.log /var/log/vlogger >/dev/null 2>&1 &

/etc/init.d/apache2 start

Of course your log directives will be something like:

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vcombined
CustomLog "/var/run/apache2/logger" vcombined

You absolutely need to run the reader before the writer, else the init script would hang for ever. It is easy adding a simple init script to run vlogger before apache and it has also the big advantage of not requiring re-fork a perl intepreter at every damn log action. Piping rocks.

Beamers

I ask myself again and again: why it is always a challenge using a laptop with a beamer? It is not rocket science, but I always find problems due to lack of sync with certain beamers and certain laptops combinations. If you are lucky, you can see an image, but probably some parts of the screen (and of your slides) are invisible. It happens also under Windows, but it happens too many times under Linux.
Lately, I'm finding difficult to use my Thinkpad X31 under that respect, even if I always managed to use it without great issues until some months ago. Does it need a macumba before use?

Lessons of the life...

Waiting hours to complete GRASS importing for an Hyperion 242 bands data set, just to discover that all bands are zeroed as result. At least, I also find that the latest Envi 4.3 is not able to read those HDF files correctly. Free software is any way better...

To package or not to package...

... this is the problem

I just casually saw Norbert post about the ion3 querelle. This a very unfortunate example of collapsing interactions among upstreams and maintainers. My general advice (but for suggesting to use wmii or dwm instead of ion3 :-)) is avoiding packaging of development branches, but this is a decision which sometimes is difficult to take: some programs seems in development for years and stable releases could result largerly unusable or limited. Surely our - and generally speaking any distribution - release cycle and maintainance are not adequate for many on-the-edge software out there.

When upstreams releases [a]periodical milestones, those could be packaged, but upstream will not support them: we have already our problems in supporting regular releases for security independently by upstream for mainstream programs, without adding pieces of casual crap around.

Packaging a casual snapshots is out of question IMHO, but for using it in sid/experimental, so I can understand the upstream opinion, because many users report problem to upstream instead of maintainers. I see definitively no silver bullet anyway, but for maintainers' capability of understanding what should be packaged or not and opening an unbreakable communication channel with upstreams to be up-to-date in respect with upstream roadmap.

Playing with mod_chroot...

... or why PHP sucks so much?

It is quite common (at least for me) finding abused web applications on shared hosts around. The most typical case is finding some kind of IRC bot running as www-data and a few unauthorized files around used for phishing, cross-site scripting or what else. That motivated me to try playing with mod_chroot in order to minimize the possibility of webapps abuse from our friendly kiddies^Wcrackers. Mod_chroot is a nice tiny Apache module whose purpose is the confinment of webapps within a limited tree, where nothing but a few files and dirs are available to try exploits and abuse badly written code.

Unfortunately, I found that mod_chroot poses one major problem (among others, see its CAVEATS doc): the sucking mail() function is not working out of the box, because PHP folks - God knows why - decided to implement that stuff by calling a local /usr/sbin/sendmail program within a shell call. The most sane option is simply ignoring the issue and living happy with a disabled local mail() function. A nice solution in that case is using a PEAR Mail module, which is able to send mails via SMTP in much more elegant way. Unfortunately, there are quite a good number of morons out there, and that could be not a viable option if you are the system administrator of a bounce of shared hosts which are exposed to those morons, who absolutely need a working mail() function.

After a few googling around, I did find that many people had the same problem, but none found (or explained) a working and neat solution for a working mail() implementation, so I'm writing some notes about that. My implementation is based on a nice tiny program (mini_sendmail) which has the great advantage of not requiring a configuration file or a spool directory to work. It also works without suid bit on, which is a good thing as well. It is statically compiled by default, so it simplifies things a lot. In order to have mail() working you need also to install a (statically compiled) shell, e.g. bash-static as sh under the /bin directory of your chroot tree (a more tiny shell would be appropriate). I commented out the silly username autodetection code in the mini_sendmail.c source, because it creates some problem within an empty chroot tree (it failed with a "can't determine username" message with or without the /etc/passwd file available).

Now, the next step is using an entry like

sendmail_path = /usr/sbin/sendmail -t -fwww-data@your.domain -s127.0.0.1

in your php.ini file. You can also use another IP address if your SMTP server is not your localhost or you used some more exotic routing setup. Having a suitable /etc/hosts is also useful. A final trick is adding a var/lib/php4 or what ever directory is required to store PHP session files. No other files should be required in order to have all working. Of course, you have also to use inet sockets for any required connection (e.g. mysql) but this is typically the default in etch. I would also suggest to add only ad hoc statically-compiled binaries within the chroot tree when required, else you will need to store all required shared libs: in that case you will need to find binaries requirement by using ldd and chroot to find loading/running errors by means of an usual trial-and-error cycle.

Proftpd 1.3 out in experimental

After being busy with DebianGis related things and a few other packages recently, finally I found the time (and will :-)) to complete and uploaded an experimental deeply re-packaged version of proftpd.

Now proftpd is quite near to the release of 1.3 and current 1.3.0rc5 is considered the final release candidate before that (due in a couple of weeks). So it is also time to test the new package and give feedbacks to me and upstream team. I removed the ancient multi-binary approach to promote the new dynamic shared objects to prime time. As always, there are quite a few feature and configuration changes in the new version, so people are warned about that.

I happily reduced the number of patches applied to the sources and refined scripts all around, but more work is required to manage better upgrades and also adding more contributed modules, as well. And some silly things surely have been overlooked. So, stay tuned...

Italian, really!

Ok, ok, I like pizza, mandolino and do it better... I'm definitively condamned to live in the same country of Berlusconi, sigh!

Your Inner European is Italian!

Passionate and colorful. You show the world what culture really is.

Who's Your Inner European?