Life

Recently, we got the recommendation from our system partner to use static allocated tape cartridges instead of dynamic allocated ones. Apparently using dynamic allocating cartridges comes with a performance penalty if more than a few nodes are backing up a large amount of data at once. And yet again, I noticed that the IBM Virtualization Engine Console (aka Falconstor Software) is really error prone. In order to change the allocation type, we had to shred the old cartridges first (500 x ~100M up till now), chance the allocation type at the virtual tape library level, and then recreate the 500 cartridges with a fixed size (500x 102400MB). Now, as I was kinda optimistic, I decided to create all 500 cartridges at once. ...

Well, it’s yet again Sunday afternoon. And I had (again I might add) the urge to play around with all the stuff I have at home. So at first, I “fixed” the ground wire off my NAS box. Ground wire for the CPU fan Afterwards, I went back upstairs. Hooked my Philips up to my notebook and figured I really need a wireless keyboard. Because typing with the Windows on-screen keyboard is a huge pain in the ass (as well as a pain for the mouse-hand)! ...

Just like I announced last week, my binary packages repository is now history. I’m gonna remove the redirections from lighttpd and DNS in a few.

Well, I recently (well, yesterday) built the opsview RPM’s for SLES10, and started fiddeling about with it today. Alex " recommended" I should rather look at Opsview instead of Centreon, but boy was there a surprise waiting for me … Opsview has the advantage that it at least lets you use the package manager. But, it also needs a lot of handy work (just like Centreon, which I really dislike since it’s real error prone). ...

I had the problem, that the automatic update function of YaST doesn’t work like I want it to. I just wanted it to install only those updates, that ain’t interactive, don’t need a service restart and don’t need a reboot. YaST does only feature an online update that skips “interactive” updates (I’ve never even encountered an interactive update up till now). So I went ahead and wrote a (hackish) script, that achieves what I need. ...

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 … ...

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. 1 find /tmp -name "ssh-*" -mtime +5 | xargs rm -rf

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: ...

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. ...

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 .. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 vetapeservice@VTL-B:~> cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (x86_64) VERSION = 10 PATCHLEVEL=1 vetapeservice@VTL-B:~> uname -a Linux VTL 2.6.16.46-229-smp #1 Sun Apr 13 05:21:49 UTC 2008 x86_64 GNU/Linux vetapeservice@VTL-B:~> free -m total used free shared buffers cached Mem: 4022 1378 2643 0 342 552 -/+ buffers/cache: 484 3537 Swap: 3815 0 3815 vetapeservice@VTL-B:~> cat /proc/cpuinfo processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 8218 stepping : 3 cpu MHz : 2600.186 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 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: the build for the VE uses busybox as init IBM stripped man/info they are running Xorg/Fluxbox on it Just don’t ask me why there’s a DE ( d esktop e nvironment) running, it ain’t even hooked up to a monitor. Only reason would be for the RSA’ remote monitor stuff … lala