Trusted vendors in SUSE Linux Enteprise 10

The other day I had a closer look at the zypper logs (well, I was digging for a time-history of installed packages). First … damn does zypper produce a *lot* of logs on a “productive” (or rather on a maintained – as in up-to-date) system.

But glazing over the logs, I found out something new about zypper. It actually has an internal list, which only purpose is to identify a trusted vendor …

As you can see from the log, the list of trusted vendors is:

  • ati technologies inc.
  • jpackage project
  • novell
  • nvidia
  • opensuse
  • sgi
  • silicon graphics
  • suse

Cleaning up /tmp

Well, I just looked into /tmp on one of our boxes and noticed that SSHd left behind some (try 400) directories .. Now, I could use a simple rm -rf /tmp/ssh-*, but I didn’t want to kill my current agent forward file.

After looking at the man-page of find, I stumbled about -mtime. And that seems to work out quite well.

packages.barfoo.org is going away

For those of you, still using my binary packages. It’s just a waste of disk space for me (6.8G to be exact), so I decided to remove them. I’m gonna give people one week to grab yourself a copy. I’m gonna keep the bashrc and all the other stuff I wrote back when I was still interested in binary packages, but the binary packages are gonna vanish!

Again, grab yourself a copy if you need them, at some point next week (probably on Friday), I’m simply gonna rm -rf them.

Tivoli Storage Manager Client and Microsoft Cluster Services

Well, I just had another look at our client scheduler services on our Microsoft Cluster. A while back we noticed that those scheduler services were going nuts after some time. Well, as it turns out, I can tell why. Microsoft Cluster Services have a feature called registration replication, which replicates a given key, if changed when the resource is online, to all connected cluster nodes.

Now, we added the obvious registry key to the settings of our cluster resources for the scheduler services (SOFTWAREIBMADSMCurrentVersionBackupClientNodes<TSM NODE NAME>) and the scheduler service would use the same registry key to store it’s passwords. But it seems we were far off with that assumption.

The scheduler service uses another registry key, it’s quite similar to the one the GUI is using, but it’s different enough (SOFTWAREIBMADSMCurrentVersionNodes<TSM NODE NAME>).

Automating zypper updates

Well, I just looked into using zypper up to update some of our boxen (I do have a script, which holds the boxen it needs to process in a variable and simply goes through them one by one) — yes, I could activate auto-update, I just don’t want that at this point 😉

So at first I tried just using zypper to automatically update that given list, but even if you pass –no-confirm, zypper would still ask for your confirmation (which seems kinda stupid). After a short while thinking about it, a lesson from solar@gentoo.org came to mind. When working in a chroot, he simply used this:

And analog to that, I simply tried this:

And guess what: it worked 😉

VI Client: Changing the language from the system default

Well, as I am in fact running a german Windows XP, the VI Client started displaying all menus and operations in German when I updated to 2.5u2. Normally, I wouldn’t have much of a problem with that, but recently it started to annoy me, since the translation is a bit off from the real meaning of much of the operations.

So today, in the morning I started looking for ways to revert the VI Client back to displaying everything in English. And guess what. There’s no way to switch the language from the VI Client itself. There’s just a workaround.

Simply rename the folder in “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure Client2.5“, %ProgramFiles%VMwareInfrastructureVIUpdate” “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientPluginsConverter Enterprise 4.0.2” and “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientPluginsUpdate Manager 1.0 Update3” named “de” to something else. Tada, your VI Client is back in English.

Distribution running on IBM TS7530 Virtualization Engine

Well, I was just a bit curious earlier what distribution might be running on our IBM TS7530 Virtualization engines .. well, I just had a look-see ..

Main difference to a “normal” SUSE Linux Enterprise Server 10 installation (there’s about zip normal with that kind of installation, thus the quotes) thus far are:

  1. the build for the VE uses busybox as init
  2. IBM stripped man/info
  3. they are running Xorg/Fluxbox on it

Just don’t ask me why there’s a DE (desktop environment) running, it ain’t even hooked up to a monitor. Only reason would be for the RSA’ remote monitor stuff … *lala*

Read More

New Theme

Well, since it’s yet another new year (oh, Happy new year! by the way ..), I decided to drop the old crybook and switch over to iNove, which I think looks quite good with a few additions.

If anyone finds something that ain’t working or looks just wrong, tell me please.