The only pitfall on the installation was grub mishandling the Sas6 arrays. Two Raid-1 arrays were configured on the internal SAS6 controller. The two arrays are seen as virtual disk on the Linux side, but their names/order are reversed:

/dev/sda => contains the physical disks 2-3 (second array)

/dev/sdb => contains the physical disks 0-1 (first array)

Both me and Debian Installer got confused with the disk distribution. Grub insisted on being installed on /dev/sda and that device won’t boot the machine. After a few tries (and hours) I got grub on the boot array (the first one); the install was completed by entering the target chroot and manually issuing:

grub-install –no-floppy “(hd1)” 

Lesson learned, your Sas6 won’t look for a boot sector on the second array.

Now, with the machine provisioned and running, I’m itching with curiosity about the lcd display and the ipmi implementation on the machine. Seems that you can output to the lcd from linux in a primitive and crude way.

When i firs heard of chef i got a litle worried about the possible damages to puppet as a community and as a project. It seemed weird to me to hear from chef on the #puppet irc channel and also weird were some of the opinions on the blogs of Chef’s evangelist (in particular one impliying bad behavior from Lak when he asked for money/contract to fix a particular issue).

In my opinion puppet is a well-behaved FLOSS project that is fostering community, writing code, and earning money. I’m glad to see those same worries of community hijacking being discussed in puppet-users. And even happier seeing the changes in licensing and focus that are underway at reductivelabs.

So, cheers for reductivelabs for keeping the good work and trying new roads to grow and prosperity. Let’s not repeat the Tla Tale.

You can read the (now old) news about Chef at The Madstop.

I’m trying to collect some good practices and advise for those trying to add i18n support to their themes:

• Read the WordPress documentation on i18n. Print their best practices, put them in a visible place and recite them before any i18n effort.
• Use plenty of format strings. Ok, you already read the best practices, so you known I’m repeating them here. For better format strings use descriptions and comments (the _c() function)
• Use boilerplate copy everywhere. Don’t be too original with the text you include in your theme; “Submit It” better than “Say It Pal!” for a submit button. If your theme includes strings used by most other themes, chances are those strings are already i18n and l10n in . You can always have private copies of your theme with unique headers, titles, and button; the version you share should be as plain and simple as possible.
• Keep out strings that need no translation: and don’t skip small strings subject to translation; alt and title html parameters, submit buttons value, next|prev_post_link and other wp template tags, all accept i18n. See the next two samples; why “Comments” is left out of the _e() function?; is there a translation for ‘|’ in any language?
  

  <?php _e($numComments, ‘XXXXXXX’); ?> Comment(s)

  __(‘ | ‘)

The last and best tip is to use a theme with good i18n support and clean code as base template; sandbox is a great, clean, and fully i18n WP theme.

Working with many development and production some people forgets to check their default charsets; in the end encoding mismatchs crawl. I’ve seen a few programmers falling in this trap.

Last time our php was Latin-1 encoded and the production Apache server used Utf-8 by default. In a shared hosting environments the default encoding can be set from the .htaccess file:

AddCharset ISO-8859-1 .php
AddDefaultCharset ISO-8859-1

Same thing from php:

PHP. Use the header() function before generating any content, e.g.:
header(‘Content-type: text/html; charset=utf-8′);

Links and discussion:

• Basics on http charset parameter at w3c.
• Apache .htacces usage.
• Handy list of IANA accepted encoding names recognized by apache.

As Wouter, I find the biggest drawback to multi-filesystem layouts is lack of flexibility when resources are scarce; scarcity means laptops in the Wouter’s post. I’m thinking of long-lived servers in need of upgrades, in particular those with a life of unplanned and ad-hoc growth.

When scarcity strikes: drama.  The cleanup dance isn’t a solution, everything clogging /var and other undersized partitions is of value; forget about deleting it. On the first storage famines I go resizing the affected filesystems with unused/un-partioned space(yay, I planned for un-planned growth). After the resizing is done you realize that some other partition also need extra storage.

Here comes the cleanup-moving dance. First put data out of /var and system partitions, then update configuration for the affected services or start symlinking to the new directories.

My two worst cases were bacula related. In both bacula’s database needed more space than its current partition could afford:

• Shortly after updating retain period for data backups to two years (ISO requirement). Database moved to a new server where …
• When we moved from cvs to git; again bacula’ db jumped in size. It had to be moved and symlinked to /var.