TYPO3 hogging
Posted on Monday, 7th April, 2008 in Life
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
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
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
Posted on Wednesday, 2nd April, 2008 in Life
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 … 
SLES-9 (once again)
Posted on Thursday, 8th March, 2007 in Life
OK, so today was the highlight of the week … We updated apache2 on Tuesday (yeah, that’s still 2.0.49, so if you have some exploits - try them 
) and now out of the sudden we have major performance issues. We looked nearly the whole forenoon for a reason, *why* the frackin’ apache was using 236% of the CPU’s.
In the afternoon, when my co-worker decided to go home (that was ~1500), I decided to revert back to the old patch level. But that isn’t as easy as you think (at least on SLES). The only thing I wanted to do, was something like this:
$ emerge '<apache2-2.0.49-r63' '<apache2-mod_php4-2.0.49-r63' '<apache2-mpm_prefork-2.0.49-r63'
Looks like SuSE (or Novell who bought SuSE sometime 3 or 4 years ago) doesn’t consider reverting to an older patch level. Which means I would have to remove apache2, apache2-prefork, apache2-mod_php4; fetch the basic RPMS from our FTP server (which sadly forbids directory listing, so I can’t exactly look for the original RPMS) and I tried to blindly to fetch them.
Foooked. Didn’t work .. now I cron’ed the POS to restart every half an hour, so at least we have *some* solution. Will see about reverting the the last patch tomorrow again, hopefully I’ll find the original RPMS.