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
As I posted earlier, I tried working around some limitations in Microsoft’s Active Directory by teaching the script some intelligence. But, since we recently started using Thin Clients, all the stuff I did with the fancy vbs was just a waste-of-time. Turns out, Windows XP Embedded doesn’t work quite the same as a " normal" Windows XP (that’s where I tested the script on), and it simply dies when running the WMI Query. Bollocks. ...
Well, we had our TS7530 delivered in late September, the day after the IBM service guys came by to prep the VTL for our needs (IBM sells the thing as black box). Now, since that day; they fought with the Call Home functionality. The trouble was simply, that the Call Home Service running on the Virtualization Engines just didn’t start. After about 6 weeks of trial and error (and the IBM service guys popping in every second week), they finally found the cause of the Call Home Service not being able to start. Domain Name Resolution. Neither the IP addresses of the VE’s nor the VE console were registered in our DNS/or local host files. ...
As some people know, I previously " created" (mostly modified the check_swap plug-in to print RAM usage) check_ram in C. Now one of my problems for the past few months was putting the C plug-in as well as " supported" environment under the same hat. Today I had another look at the amount of available plug-ins in NagiosExchange. There are quite a few plug-ins available, but as I do have some experience with Python, I used the one written in Python. It was rather easy hacking in support for performance data into it, as the below shows. Someone else already posted a non-unified diff for performance data support, but that ain’t quite right according to the Nagios plug-in development guidelines.
Well, when they delivered the VTL about four weeks ago, nobody figured this thing would be such a mess. Apparently IBM hasn’t set up that much VTL’s with engine failover. Point being, the VE’s have eight HBA ports (four inside, four outside the black box). Now, as they configured the VTL, the ports were all in initiator mode. And we needed the fourth port in target mode as well, as it’s better to have 4 independent paths to the VTL. The only problem was, the VE console didn’t think so. ...
At first, as we prepped the zoning for the VTL, we did it WWN-based. Now the trouble with the HBA’s of the VTL is simply that it has different WWPN’s on the same WWN. And WWN-based zoning simply doesn’t allow access to that. So off we went and switched to Switchport-based zoning, and see. It just works 🤷