Been working out how I'd like to configure our replacement server's disks.

Given the pain of the last server I'd like to use LVM, and not use the fakeraid controllers built into the servers.

Test server had flat BIOS battery, which means it forgot it was configured to use RAID. The BIOS of the DELL SC1425 writes metadata to disks when configured as RAID, which it doesn't then read when it boots in other modes to check if it should be in RAID mode - hmm - maybe I'm missing something here but it looks like a BIOS battery going flat puts your data at unnecessary risk to me.

Whilst the "dmraid" tools can be used to manipulate some of this metadata, typically the system won't let you erase it once booted. Can anyone explain why to me? Eventually I enabled RAID in the BIOS and deleted the RAID array it then found. Then I reinstalled.

The box also had a prior LVM config. The Debian installer is good at finding and reading any old LVM config on a box, and then not wiping/reseting this information. This got me an "Incorrect metadata area header checksum", which I eventually reverted to the slow but effective "dd if=/dev/zero of=/dev/sdX" to make sure any state information on the disks was truly dead.

Trying to set up LVM on software RAID requires a separate /boot for the installers health at least (I'm not fighting it any harder). Once you configure RAID the installer says it needs (and does need) a reboot so that the installer can take this on board and then configure LVM. There are some related bug reports already, but this seems to be as designed.

Aside from the above it "just worked" ;) This isn't the first time that the Debian installer has tripped me by preserving existing state on disk drives, I'm thinking I should write zero's over all disks before use, tedious as it is.

..... and the first search result I had with Twitter results in was someone suggesting we redirect IE6 users to a certain well known Christmas Island domain name.

Whilst I understand the sentiment, I didn't think it was the most useful second result on the Internet to display for that search term.

Must try harder Google - (Matt Cutts, Marissa Mayer, do you guys have an alert for your own names I wonder?) and I couldn't find a button to immediately switch this spew off.

Today was too full of Paypal pain.

Amongst other things to activate my PayPal security key, I first had to delete all my Paypal cookies, as otherwise I was only offered the option to activate SMS based security.

But in my guise of being positive here is what I think Paypal needs to do.

1) Stop shuffling customers between websites, pick a domain and stick to it. Don't send me to Paypal.co.uk simply to forward me to paypal.com/uk, and then to paypal-marketing.somewhere else. I care about my online security I have to whitelist these manually for active content, even if I didn't I have to keep an eye on the toolbar to make sure I'm not being phished.

2) Stop advertising "http:"; URLs, use HTTPS only. Why encourage people to visit using an insecure system, when a secure one is only one letter more to type.

3) Stop promoting proprietary email verification and use well established standards for same, not new ones invented by people who couldn't encrypt their spaghetti letter soup. Everyone who understands security is using OpenPGP for email, do catch up it will be simpler in the end.

4) Make it harder to access accounts when a security key is not present.

I have a lot more suggestions but that'll get them started.

I confess, I long for the days when Paypal's search gave results for pages that exist, and contained the word you actually searched for......

Error:

[Mon Jan 18 11:24:53 2010] [notice] mod_fcgid: process /.../MyApp/script/MyApp_fastcgi.pl(10514) exit(communication error), terminated by calling exit(), return code: 255

Was caused by changed file permissions on the script MyApp_fastcgi.pl

The simple ones are the hardest to find sometimes.

We have a web application written in Catalyst running using mod_fcgid on Lenny which we wish to improve performance on, the folks are #catalyst recommended NYTProf as a profiling tool.

Attempts to persuade the application itself to run under libapache2-mod-perl2 failed miserably (well actually succeeded first time, then failed repeatedly). The behaviour of mod-perl seems to be inconsistent from run to run, with Apache starting or not starting apparently randomly (race condition?).

So set about trying to gather data when it runs under mod_fcgid.

Modified the start of the "scripts/myapp_fastcgi.pl" script to read "#!/usr/bin/perl -w -d:NYTProf", and modified the permissions of "scripts" so that www-data could write the profile data there.

Added "MaxProcessCount 1" to the virtualhost so that only one fcgid process is used. Modified "/etc/apache2/apache.conf" so MaxKeepAliveRequests is 0, as when the process restarts the nytprof.out is overwritten.

Added a method to the Catalyst app that causes the FCGI process to exit cleanly, so that the NYTProf file is not truncated. I'd hoped "kill" of the fcgi process would work here but no joy so far.

The fastcgi process is still restarting occasionally. Any ideas why anyone?

I can add the process ID to the output file if this gets too painful, but it is not so often I can't collect useful data about performance (the fcgid will restart every hour due to configurable timeout, but I don't get anywhere near an hour when collecting profile data before the process restarts).

So far everything points to performance of the YAML libraries as our first bottleneck in this application, although we may simply be reading and saving YAML files more often than we have to.

Tried to use a package (phpesp) that uses PHP gettext support.

There is a comment in the PHP gettext pages that Debian needs package locales-all for this to work.

Now I think:

It just works (i.e. I didn't strictly need to fiddle)

You want "locales-all" because software using gettext almost certainly can/will support locales you don't have installed if you don't.

phpESP tests gettext support with a locale I didn't have installed.

php-gettext is a separate package implementation a PHP based gettext like approach which you shouldn't need because PHP gettext works if you use Debian.

It feels like there is a bug report due when I have to read comments on the PHP website to make stuff work in Debian. Maybe it is a RTP for phpESP that is missing? Guess I'll let you know if we decided to use it in anger.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421268

Well trodden paths.....

As someone pointed out at the Devon and Cornwall GNU/Linux user group mentioned Google Docs has a form editor that does much the same thing much more easily, but them my freedom to fiddle would disappear. Still credit to Google for a nice implementation.

The disk drive overheated, the screen was full of I/O errors and a panic message, but the kernel carried on routing packets for another 2 hours before it succumbed. By which time I was in the computer room, and had built a replacement server just in case the disk drive was dead.

I need a job where I get paid extra for a call out at 03:30 over the holiday period, preferably in extra sleep.

3 years ago I wrote a short rant highlighting that many big email providers fail to make even preliminary efforts to improve the deliver-ability of their email.

3 years on I note the situation is now worse. The RFC-Ignorant list I referred to then, now has additional records for hotmail. There are now other widely implemented statistical systems using this list. Thus making it more important to sort these details out.

The topic came onto my radar again when someone testing their own email address hit an issue, one of the contributing factors was a 7 year old listing of their provider (Verizon) on RFC-Ignorant.

If you have a lot of trouble with email being falsely marked as spam, perhaps you are using the wrong provider.

They may be "too big to block", but they aren't "too big" to leave.

Friends don't let other friends use {hotmail|Yahoo!|orange.fr|....}

The trouble with Googling for error is Google sometimes says:

Did you mean: fastcgi server has closed connection

Now to figure out how close the connections are, and move them further apart ;)

Bug filed.