I'm still waiting some clarificatons by HDF team about their HDF5 roadmap with SONAMEs and libraries name. It seems they partially learned to manage libtool properly to follow C API changes, but still some oddities are present, such as using the same names for MPI and serial flavors. I will probably have to again diverge from upstream names, which is generally something I don't like, as in the case of GDAL. A summary document about HDF5 plans is due in a brief also.
When finished with HDF updates, I will concentrate on a couple of new beasts which still are lacking in DebianGis and are of so much interest, that are Ossim and the CNES Orfeo Toolbox. In the meantime I would hope that debian-science team will define a squeeze-related policy for MPI.
As always, I'm still worried of the low level of activities in the DebianGis team, which is a constant since years. Unfortunately, this is a situation I see quite common also in many other teams, but I still don't see a right way to improve the status of the team to avoid an almost one-man show. Also I would like to see again Qgis in main, but I'm still waiting for feed-backs by past/current contributors to my last qgis-dev list and off-lists polls.
Monday, April 06, 2009
Tuesday, October 14, 2008
OSM and N810
I finally managed to use my Nokia N810 to do some GPS logging for OSM. The Nokia internal GPS is quite slow, so I used an external antenna and the well known Maemo Mapper tracking capability to log my first 60 kms in my area. I'm not too much happy with the result, because it seems the Nokia tablet is quite slow in tracking points: other trackers are someway configurable on those regards, but Mapper seems not taking in account any user preference about data sampling. Too bad, even if it is able to use OSM maps as default background, which is a great plus for a mapper. Definitively it needs a look to sources to understand what happens under the cover.
Thursday, January 17, 2008
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.
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.
Wednesday, December 12, 2007
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?
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?
Tuesday, March 20, 2007
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...
Wednesday, March 14, 2007
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.
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.
Tuesday, March 13, 2007
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.
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.
Subscribe to:
Posts (Atom)
