The usual IT babble
Posts tagged SLES9
TSM client: Backing up files with umlauts on SLES
Mar 2nd
In the past, I always had problems with SLES and our Tivoli Storage Manager client’s when backing up files with german umlauts. Well, today I looked a bit harder, and quite quickly found a solution.
sles9 root [0] > env | grep ^LC LC_CTYPE=de_DE.UTF-8
As you can see from the above, SLES9/10 ain’t setting LANG or LC_ALL (which I searched for first), but is setting LC_CTYPE.
So, simply changing the LC_CTYPE in the init-script and/or prepending the dsmc command line with a new LC_CTYPE fixes my umlauts problems!
sles9 root [0] > LC_CTYPE="en_US" dsmc incr
Well, I had a long’ish talk with one of my trustworthy IBM senior consultants the day after writing this …
He told me something along the lines of this:
If you would like to back up files with names containing characters with a code > 127 please ensure that you have chosen a SBCS character set for your locale. The default code page C or the code page POSIX supports characters up to 127 only. Files whose names contain special characters will be skipped if C or POSIX is used. It is strongly recommended to perform a system backup by using a SBCS character set to prevent any file or directory from being skipped. This behavior for different locales is intended.
And this:
The UTF-8 locale is default on some Linux platforms. However, TSM Client currently does not support running under UTF-8 locales (such as en_US.UTF-8 and ja_JP.UTF-8). Export your LANG and LC_ALL environment variables to the iso8859-1 or EUC versions of your locale and then start a new xterm (or mlterm) session prior to running TSM Client.
That basically means, at least for using the TSM Client Java Interface (dsmj) and the scheduler/client acceptor daemon you have to switch your locales to something _not_ UTF-8 capable.
He also mentioned, that IBM doesn’t have a real solution for this problem, as well that there is no real workaround. You need to invest some time into figuring out the “right” locale setting for your system(s), since after writing the above I came to the result that it ain’t enough ..
You need to do the following:
lang="de_DE@euro" export LC_CTYPE="$lang" export LANG="$lang" export LC_ALL="$lang"
After doing so, the scheduler and the command-line client works …
TYPO3 hogging
Apr 7th
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
Apr 2nd
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)
Mar 8th
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 '
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.
SLES-9.2 (continued)
Aug 9th
OK, so after yesterdays battle with SLES and rpm, I decided to simply upgrade rpm (again rpmbuild -bb rpm.spec as in from source).
I had to tune (hah, remove stuff that isn’t working on this ancient gcc-3.3.3 ie. -fstack-protector) a bit to get it working, wasted 20 minutes worth of CPU time and ~30 of my time. I finally gave up. I couldn’t persuade neither rpm, nor git to compile on the damn SLES/Dell.
While the above was running, I did some compile-testing on Tim’s behalf (he back ported the e1000-driver updates from 2.6.18 to our 2.6.17 branch), seems to work so far.
On a more personal note, I’d like to stab all people neglecting their promises!