Setting up Gallery2+PostgresQL+PHP5 on Debian Etch

The Gallery2 package for Debian Etch seems to be very well done, except one thing - it's geared towards MySQL usage (the Gallery makers recommend MySQL because they say that they use some special MySQL constructs which have to be emulated on other databases).
My view on this is:

• I prefer PostgresQL - it's a more mature database.


• I prefer Apache2


• I prefer PHP5 - I hate this language and think it has tendency to push poor programmers to shoot themselves (and their users) in their feet but if I have to install it on my machine then I'd rather use the latest and greatest.


• I prefer mod-php5 as opposed to the other ways to integrate Apache2 with PHP.

In addition, the Debian packages state their dependencies in a way that seems to encourage Aptitude to choose Apache (1), MySQL and PHP4.

So first thing first: After picking gallery2 for installation in Aptitude, go through all the packages it depends on and remove the ones you don't want and which have other alternatives. Get rid of the PHP4 and MySQL dependencies - Aptitude makes it pretty easy by simply making sure that you choose other packages to satisfy the dependencies and remove the rest. Just follow the suggestions made by Aptitude when you ask to remove a package with dependencies on it, and make sure that Aptitude doesn't signal "Broken Packages" before going ahead to execute the changes.

Setup a separate user for gallery:
$ sudo adduser --system --group gallery

Does the trick - add a system user (with a shell of /bin/false), create a home directory for it and a group especially for it.

The following should be pretty self-explanatory but the summary is: Create a new role ("user"), create a database, set a password, allow role to be logged in:
$ sudo -u postgres psql
postgres=# create role gallery;
postgres=# create database gallery owner gallery;
postgres=# alter role gallery encrypted password 'password';
postgres=# alter role gallery login;
postgres=# \q
Allow logging in to role "gallery" from another user without having to run psql as the UNIX user "gallery" by adding the following lines to the end of /etc/postgresql/8.1/main/pg_hba.conf:

local gallery gallery md5

And I also had to enable access to Gallery2's index.php by adding "Indexes" to the Options line in /etc/apache2/conf.d/gallery2 (link to /etc/gallery2/apache.conf

After that I could access my web server's "/photos/" and start the automatic configuration.

How to block Skype traffic with one iptables rule

There is an interesting lecture (PDF) by Philippe Biondi and Fabrice Desclaux about how and what they learned about the Skype client code and protocol. On page 75 they give the following secret incantation for blocking Skype traffic:
iptables -I FORWARD −p udp −m length −−length 39 −m u32 −−u32 ’27&0x8f=7’ −−u32 ’31=0x527c4833’ −j DROP

xdns - archeological diggings

Finally I re-found my own DNS Library source still almost at the same place where I left it almost 15 years ago.

Granted - the "xdns" program around it is pretty useless today, and the dns packet creation and parsing library is a classic candidate for C++ -style Object-based interface, but the basics are still there and might be useful for others who still have to deal with raw DNS packets...

SSH breaks when the loopback device isn't configured

Helping others troubleshooting is great fun and very rewarding - you get to learn some new things yourself.

In this case, this chap had a trouble getting X11 forwarded over an SSH tunnel. Everything looked fine, the same setup on another machine worked just as it should, all the flags (X11Forwarding) were set correctly but still the $DISPLAY envariable wasn't set on the remote side.

The bottom line - the loopback device ("lo") wasn't configured. This can be checked with a simple "ifconfig".

The break-through in the investigation came when he executed sshd in debug mode and received the following errors:

debug2: bind port 6999: Cannot assign requested address
...
Failed to allocate internet-domain X11 display socket.

Some googling revealed the following post, which actually gave the answer (so at least some of the credit should go to Jim Prewett, who bothered to document his findings four years ago): http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104336969724537

WARNING: You have to run sshd in debug mode on an alternate port because sshd debug mode will only serve one connection then exit, so you have to keep your existing non-debug sshd running or else you'll lock yourself out.