Tobias Schlitt - a passion for php

I recently migrated my server to a new maschine and a new provider. After supporting Kore today with installing spamdyke on his maschine, too, I seized the chance to update my Spam Filtering with Spamdyke in front of Qmail howto on the wiki. The howto describes how to install the most recent version of spamdyke on a Gentoo system, explains the most important configuration options and gives some practical hints for such setups. You can ask Kore, it only takes about 10 minutes to do so ;) and saves you a huge lot of spam. Comments and addtions are very welcome.

Since my new baby is not fully working under Gentoo, yet, I'm updating my kernel each time a new version of gentoo-sources occurs in portage. If you are configuring your kernel by hand, you know what that means every time (at least for me it did):

- Move around /usr/src/linux symlink
- Copy .config
- $ make oldconfig
- $ make (before that make clean, if you re-compile a kernel)
- $ make modules_install
- $ module-rebuild rebuild, to rebuild external modules on Gentoo
- Copy files to /boot
- Add the new kernel to the grub menu
- Activate it as the default one

Time to integrate these steps into a little script.

This one takes over all the mess from above. It hides a lot of nasty output from me, but allows me to watch it through a temporary log file if I tend to. It creates the rudimentary entries in my grub.conf above all others so that the new kernel is active by default.

The script (rename it to .sh only, make it executable and run it as root) should be adjustable to your needs within minutes. Maybe someone finds it useful. Please leave me a comment if you do and also if you don't!

After 2 years of really satisfied use of the IBM/Lenovo T43p I decided that time has come to upgrade. When the T61p was released by Lenovo some weeks ago I felt that this would be the right for me and so far I did not regret it until now. While I read/heart a lot about Lenovo quality constantly dropping I cannot confirm this.

My version T61p comes with a 15.4" LCD with a maximum resolution of 1920x1200 (after 1600x1200 I did not want anything smaller anymore). While it is about 4 cm wider than my previous T43p its size is still ok for me, since I don't use a desktop PC beside it. The integrated Core 2 Duo (T7700 @ 2.40GHz) compiled my whole Gentoo system (about 800 packages, including nice stuff like OpenOffice.org, Firefox, Thunderbird and Xorg) in about 16 hours (impressive!), supported by 4 GB of RAM.

Although brand new hardware is usually a synonyme for "does not work under Linux" I was impressed, how flawlessly most things worked out of the box. As you can imagine, not everything went out of the box, what is because I'm writing this little blog. Maybe I can assist some people shipping around some pitfalls.

The integrated audio chip 82801H did not work with the latest alsa-driver package, when I first installed the box. I tried compiling the drivers from kernel with no success and only unmasking the CVS version helped. However, the latest media-sound/alsa-driver-1.0.15_rc2 works fine with the snd_hda_intel driver. Tormented by ATI driver politics for Linux, I'm quite happy with the NVIDIA Quadro FX 570M, which is supported by the recent binary drivers. A bit weird but quite ok for me is, that the NVIDIA X Server Settings tool tells me I have 512 MB graphics memory, while the NVIDIA website states that this chip is only available with max. 256 MB. ;)

The brand-new 4965 wireless chip by Intel ran out of the box with the driver (net-wireless/iwlwifi-1.0.0_p1 currently) and firmware (net-wireless/iwl4965-ucode) packages in portage. While connection and association works quite fine in most cases I noticed some weird speed problems and only got about 200-300 kb/s download rates in my local network. As it looks, this was a problem of having CONFIG_MAC80211=y instead of CONFIG_MAC80211=m. Since I re-compiled gentoo-sources-2.6.22-r7 with the new wifi stack build as a module it works perfectly fine and I get 2-3 mb/s. Hope that was the solution for this problem now.

The ACPI support is not perfect so far. While CPU frequency scaling works fine, I'm not able to adjust the LCD brightness through /sys or to switch of bluetooth via hotkey. Suspend to RAM using the Gnome NetworkManager works out of the box. I also tried roughly to get the fingerprint reader to work. Compiling thinkfinger and enrolling my fingerprint worked fine, but pam_thinkfinger does not accept fingerprints currently. Since enrolling worked, this seems to be a setup specific problem. The internal clock of the T61p needs the setting CLOCK_OPTS="--directisa" in /etc/conf.d/clock to work correctly.

I uploaded my Kernel config, dmesg output, the infos of lspci and my xorg.conf as examples for configurations. If anyone has solutions for any problems or tips about how to get stuff working, please post a comment here!

When I returned from vacation, which already wasn't as relaxing as expected due to priate issues, I directly returned to a huge mess, which you might already have been noticing by the downtime of phpunit.de website.

The first experience I had after booting my notebook was, that there did not seem to be any new emails in my private inbox. While this would usually be quite convenient after vacation, it made me kind of affraid, where the expected huge email load would have gone? SSHing into my private little server showed some interessting facts: First of, the load-indicator was at about 2500 (as Sebastian showed in his article already), a cool value in a way, if it is not your own server. The second fact was, that the /var partition had run full 4 days previously.

The latter issue was easily fixable: MySQL wrote binary logs of any change happening to a database. Don't ask me why, I did not (at least I'm not aware I did) switch this feature on, so it's possible a standard setting on Gentoo. Deleting these logs freed 6 GB of space on /var and made Lighttpd start up again to serve at least some of the websites. Sadly it did not serve phpunit.de, but more on that later.

Digging into my Qmail installation I noted, that about 5000 mails got stuck in the local queue, not being delivered (qmHandle helped a lot here). A closer look told me, that these were at least some of the messages I had expected in my inbox, which calmed me down a bit. Restarting Qmail and forcing it to flush its queues let my Thunderbird start downloading mails, so I left it for a while that way. When returning ah hour later, my inbox showed over 24000 emails. Wow! I had expected a huge lot, but that was a bit too much.

Guess what, each email was there at least duplicated, while most mails existed 7-10 times. I guess this was the effect of me trying out Qmailadmins auto-reply feature right before vacation. This test did not work as expected, so I switched the flag of again, being sure it would not do any damage. Still, even with having delivered a 24000 mails mess to me, Qmail had 5000 mails stuck... Those turned out to me mostly spam and bounces, so I decided to delete them from the queue directly and about 200 mails were left over from the 4 days with a full partition. Sounds Windozish, but a final reboot helped to flush those, too. I guess there was some Qmail process stuck, which kept the MTA to deliver further on, like a lock.

Sorting out all the bulsh** from my inbox took about the rest of Saturday, so I did not find time to take care of the webserver. On Sunday I spontaniously decided to join the geeks at FrOSCon, which was the right decision. Right now I notice, that I did not take the chance of shaking the hand of Henry Bergius, who was attending to give a talk at the PHP room we organized, because I was too busy discussion stuff with other people. Sorry for that, Henry, I hope we will meet again soonish!

Anyway, during some session Sebastian and me took the chance to check through Lighttpd, which still did not serve Sebastians site on PHPUnit. I have to admit, this was my fault actually: Short before vacation I updated the world of the server, because of some security issues I heard of. Since times were heavily busy, I forgot to take further care of the update, like restarting processes and running post-update tasks indicated by emerge. That way, Trac for phpunit.de was updated, but the necessary Python updates were incorrect, since I did not run python-updater on the new Python versions installed. Doing so finally fixed phpunit.de.

So, what did I learn from this mess? I guess 3 things: 1. If you change a running system, do it right and keep thinking of the update. 2. Monitor your server more closely, so that you see issues like full partitions before they get serious. 3. Vacation auto-reply is in general a bad idea! ;)

Anyway, the server is running smooth again and Sebastian was smiling all over the face, that phpunit.de is up and running again, while he looked over my shoulder and corrected this article.

So, after that messy weekend and the borked vacation before, it's time for me to get into eZ Components development again. I did not do much in the past 2 months in that field, but the following weeks are still university free, so you can expect some progress. Today I already caught up with about 400 mails in my eZ mail account so development can start right away tomorrow.

Sorry to everyone who missed phpunit.de last week! Since there is the still the slight possibility, that some mails were bounced our eaten, please email me again, if I did not reply to you, yet! Thanks for your appreciation!

When Sebastian left the Gentoo project, I decided to give it a try to become a Gentoo developer, which is a quite long process. Now I took the first step and provided new ebuilds for the recent eZ Components release 2006.2. Since I'm not an official developer, yet, these ebuilds are only available through the Gentoo PHP overlay, for now. I think Luca will put them into portage, or at least into php-testing, as soon as he is back from Christmas vacation.

So far, you can try them out through the php-experimental overlay. The easiest way is to use layman ($ emerge layman):

$ layman -a php-experimental
$ eix-sync || emerge --sync
$ emerge -av ezc-eZcomponents

Some feedback would be nice.

Since a few days Jakob Westhoff - a good friend, university and usergroup collegue of mine - has a blog. I convinced him to set one up, because he produces a lot of geeky things, which by now stayed on his harddisc.

Yesterday Jakob has published a first piece of his work: An enhanced way of configuring wireless devices on Gentoo Linux. Usually you define all your settings in the /etc/conf.d/wireless file. But if you have to manage a lot of access points with a lot of advanced settings (like post assignement scripts), this file gets large and unmaintainable. Jakob enhanced the wireless configuration to use a directory /etc/conf.d/wireless.d/, where you can store a single configuration file for each AP.

I did not try it out myself (mainly because of the lag of time), but what I saw on his maschine looks great! I hope the Gentoo people will possibly intergrate it into the system.

Great work, Jakob!

No, not myself, but my server. Until now I ow a 1und1 Root Server L, which I bought more than 2 years ago. Now that 1und1 offers a new generation of servers, I decided to switch to a 64-bit machine. My old server had a Celeron processor, 256 MB RAM and 20 GB HD, which could not really handle my spam protection anymore. The new one is an Athlon 64 3000+, has 1 GB RAM and 2 80 GB SATA discs, which I run as a soft raid.

While migrating all of my stuff (28 domains, which I host for myself and friends) to the new server, I decided to switch the platform, I'm running, completely. While I still claimed a few weeks ago, that Debian is my favorite system for servers, I now have Gentoo running. I know, this is a system most people would never use for something else but desktops, but for one major reason it's better for me than Debian in this place: I'm more familiar with it! While I used Debian constantly more than 2 years on all of my machines, I got much too used to the Gentoo style of doing things in the past month and always tried stuff like "$ eix spamassassin" or "$ emerge -pv apache". Gentoo is simply cleaner and I have a much better overview on what my system has installed and what should be running.

When switching the system itself, I decided to go for other server software, too. While Postfix is a cool MTA, it's still hard to configure (naturally easier than Sendmail, but still hard) and it took me 2 weeks to figure out how stuff has to work. Since there is a very nice Gentoo-Howto for Qmail and it looked like this one is capable of everything I basically need for my personal playground, I went this way. Believe me or not, setting up my whole mail stuff (including virtual domains and accounts, spam and virii protection, mailing lists,...) took me 2 man days. Qmail, qmail-scanner, vpopmail, ezmlm, qmailadmin and maildrop give you a fantastically clean interface, to realize even complex architectures easily.

Beside my migration from Postfix to Qmail, I started (influenced by Kore) to use Lighttpd as my web server. Lighttpd is developed by Jan Kneschke and is a lighweight, easy to configure and secure web server. Most convenient, it uses the FCGI interface to address PHP, which is almost as fast as using Apache with mod_php, but gives you a huge bunch of flexibility. For instance I run 2 versions of PHP (4.4 and 5.1) in parallel inside 1 server, being able to define on a host or filename basis, which version to choose.

The migration is now almost complete and I'm very satisfied with the results. So long, thanks Qmail and Lighttpd! See some more info on my setup in the extended body of this entry.

Today I again was annoyed by Gentoos handling of PHP through its packaging system Portage. I love portage above everything else, believe me, but the PHP package sucks. Although it compiles really well and is very easy to configure (hey, thanks Sebastian and all the other maintainers!), Gentoo seems to have an issue with enabling certain compiling options by default. If you don't set any of the USE flags (configuration options for compiling packages through Portage) for PHP, it will simply compile with --disable-all and is completly unusable.

I discovered this when first time compiling PHP through Portage (about 2 weeks ago), because I wanted to test installing eZ components through it (and those logically depend on PHP). I had to add the USE flags "session", "pcre" and "spl" there, to get a half-way usable PHP. With my upgrade yesterday, Portage installed PHP 5.1.2, where also Reflection is an optional feature (I have no clue why and it sucks, IMO). Therefore I again had to add "reflection" to my flags for PHP compilation.

I know, this is not the fault of Sebastian and the other maintainers of PHP in Gentoo, but a general problem with Gentoo's policies here, although I have no clue, where the issue could be when adding at least the most basic flags by default (if someone really wants a smaller distribution, he can always remove the flags). Most distributions (e.g. RedHat, Suse and Debian) provide a much to oversized PHP or provide all extensions as precompiled loadable modules. This mostly sucks, too, why I tend to compile PHP always from scratch. But in heavy contrast you receive a completly unusable PHP from Gentoo, by default, which sucks even more.

You Gentoo guys: I really love your distribution and I pay high tribute to you for all the greatnesses. But please, make PHP usable by default. Thanks!

2 weeks after our release candidate, I am very proud that we released eZ components 1.0 today.

As usual, you can download the archives (tar.bz2, zip) from our website or use the PEAR Installer:

$ pear upgrade ezc/eZComponents
or
$ pear install components.ez.no/eZComponents

(note that you don't need ...-beta anymore! ;)

Beside some bug fixes, we concentrated on documentation in the past two weeks: Each component has now an introductory tutorial in it's online documentation and the API docs have been revised.

Sebastian has already brought the 1.0 release into Gentoos portage tree, so they are available through its fabulous emerge command (currently soft-masked, but that should be gone, soon).

Now we'll start working on 1.1! :)

If you have any suggestions on enhancements for 1.1 or have any other feedback, please let us know in our forum!