TYPO3 hogging

Well, we do appear to be having some strange load problems with our main TYPO3 box hosting several home pages of the local universities, as you can see below.

LOAD on t3node1 between 05:00-19:00 on 2008/04/07
LOAD on t3node1 between 05:00-19:00 on 2008/04/07

We repeatedly tried to figure out which of them was the one responsible, but neither I nor the other Unix sysadmin knew a better way to figure out the load each TYPO3 installation was causing (since there ain’t no phptop or something similar). But since today the new semester started, we figured it might be good to finally figure which one it was. And a few minutes (as in one or two) wouldn’t be much of a problem compared to the advantage we’re getting out of it.

As a comparison, here’s the “normal” load for the last week:

LOAD on t3node1 between 2008/03/31 and 2008/04/07
LOAD on t3node1 between 2008/03/31 and 2008/04/07

So as a last resort (because of said load problems), we simply deactivated one vHost after another, until the load started to relax. Unsurprisingly it was one of the installations that had problems before. Let’s see whether or not the people over at said university are insightful or not … 😆

Creating multi-distribution RPM/XML repositories

Well, as we do have quite a few custom built RPM’s, I was searching for a new solution to manage the repo(s). Currently I do have a single repository per distribution.

One thing one needs to know about createrepo (from createrepo), it doesn’t support this type of thing in the first place. So I had to come up with another way of doing it. First, I created a proper layout (much like the Debian Official Repository layout):

  • dists/
    • sle9/ (contains the repodata for SLES 9)
    • sle10/ (contains the repodata for SLES 10)
    • esx35/ (contains the repodata for VMware ESX 3.5)
  • i586/
  • noarch/
  • ppc64/
  • src/
  • x86_64/

As you can see, this is gonna get tricky in regards to managing the RPMS in a single place, while keeping the distributions apart.

So I went ahead, rewrote the script that perviously managed our two repositories for SLES 9/10. The limitation I pointed out above (keeping the RPMS in a single place), is easily overcome by using bind-mounts (sure it looks messy).

Now the only problem I’m still facing is that createrepo isn’t even looking at the excludes when it’s called by the script. But if I pass the raw command line the script is calling on a simple shell, it works like a charm .. So I don’t have the slightest clue right now, why in gods name it ain’t working … 🙁

open-vm-tools for Debian Etch

Well, after a loooong time of trying to get the modules and all the other stuff (read: init-script for the guest daemon and modules) working, I think I’m about there.

I finally fixed a long-standing issue, with the postinst/prerm scripts, and the tools should be about ready. Gonna try and send it Daniel Baumann’s way (that is the Debian Maintainer), for proper inclusion into Lenny.

I (successfully) tried splitting the Xorg parts from the “normal” open-vm-tools, as I usually don’t want Xorg installed on *any* of my virtual machines. Thus leaving me with open-vm-tools, open-vm-modules and open-vm-toolbox (and open-vm-source) as a list of packages one could install.

Integrating Windows XPe into Active Directory

As the guys over at FreeWyseMonkeys demonstrated with JoinDomain.zip, it ain’t hard to integrate a Windows XP Embedded system into Active Directory.

You basically need this:

  • A system powered by Windows XP Embedded
  • netdom.exe (from any Windows XP – SP2 in your MUI language)
  • some know-how, on how to use netdom to integrate it into your AD

Everything else is already present on the Windows XP Embedded systems I’ve seen. Then let’s get it on !

First, copy over the netdom.exe to your XPe, and then run the following command:

Here as a note:

  • ud and pd is a User/Password inside your Active Directory with the permissions to create new computer accounts
  • uo and po is a User/Password with administrative rights on the Windows XP Embedded device

After that, you just need to reboot, Et Voilà! the system is present in your Active Directory. Just be aware, if you’re using a localized Windows XP Embedded by Wyse, make sure to contact your fellow Wyse Support, as the is a bug with the MUI stuff needed for the domain logon.

Also, as yet-another side note: The default Administator password is mentioned in this Knowledge Base entry.

Backup solutions

Well some people apparently completely *don’t* understand the use of a backup client like dsmc, additionally they don’t seem to have the slightest clue on how to draw up a “clever” backup solution.

Lemme describe the situation for you. We do have two Solaris systems at work, housing our mailing system(s). Now apparently, people are unable to install the Tivoli Storage Manager Client on Solaris (or get it working properly – which people are blaming on the software not working).

Now, they draw up this insane plan … We do have about 900GiB of mail space, which is currently located on our SAN. So people decide, they don’t want the backup client on their system, as it’s slow (which I do agree to, dsmc is *slow* for large amounts of data – especially if it’s 900GiB in 15MiB parts).

So they think of something like this:

  • Attach a second disk to the mail system
  • The mail server then creates a tar file (at which iteration I can’t say, but from the size of the volume, I’d figure once a day) on the secondary disk
  • The mail server exports said disk via NFS
  • Another, semi-independent system then imports said disk via NFS, while also housing the Tivoli Storage Manager client, to backup that big tar-file …

So much for *well* planned backup solutions ……… 😆

OCFS2 follow-up

OK, it turned out that said colleague wasn’t responsible at all. Turns out, the *real* trigger was me creating a new volume on our SAN, on the same array that houses the OCFS2 volume.

Apparently, during creation of an additional SAN volume, all other SAN volumes in this array are either read-only or delayed during that time, as you can see from the following log:

OCFS2 fun yet again

I’m coming back today from a six day vacation in the warm south (that is Stuttgart), back at work and find three sheets of paper on my desk. Two tell me something I haven’t done yet, the other one tells me something I haven’t seen yet.

One of my colleagues had to restart one of our web nodes and now the thing can’t mount the logging volume (and thus, logrotate / awstats failed to do it’s job). OCFS2 ain’t spitting any error messages, when trying to mount the volume you see it joining the domain the volume belongs to on the other nodes, so from a first glance at things .. nothing is wrong ?

One thing I’ll have to add is, that you can’t reboot the box cleanly (as in you have to use the power button, so I figure something is either stuck or something is malfunctioning ..) *shrug*

Zend Optimizer again

Well, I happen to be back at my favorite application. Today I stumbled upon a “nice” thing. If you turn on the Zend Optimizer (doesn’t matter whether it is 2.6.2 or 3.3.0), one of the TYPO3 back ends ain’t showing *any* content in the preview pane. Once you turn the Zend Optimizer stuff off, it works without a problem.

O RLY ?
O RLY ?

And as Zend stated on their “Support Forum“, they don’t really support the Zend Optimizer stuff in the first place. Which is nice, what for do you need the Zend Guard shit in the first place ??

Well, so I do have two options now:

  1. Disable the one plug-in, which really needs the Zend Optimizer (as it also features the Zend De Guard engine – or whatever you want to call it)
  2. or risk some other things breaking due to the Zend Optimizer engine not working (correctly) with php-5.1.2 (which is rather old considering 5.3.0 is in development right now)

But I will see about that tomorrow …

YA RLY!
YA RLY!