I just had yet another support call with IBM, concerning the Tape Console (or VE console, courtesy of Falconstor). My basic problem was/is, that I, as a german person, do have a german Windows Server 2003 installation. Now, if you do have german decimal number format selected in the regional settings, the display is gonna be kinda impaired and you’re gonna see something like this:
And now compared to the english decimal number format:
This time, the IBM support was quite fast in answering to my ESC, more or less to my satisfaction. Basic statement from IBM is: The VTL console isn’t supported on any german Windows OS. It’s only supported on a english Windows OS.
Today, after a short break (you can call it break, I think), I sat down and looked at the IBM RSA II adapter’s remote management GUI and it’s trouble with JRE versions. Ever since the last Java updates, I was unable to access the RSA console because Java would throw an error like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Initializing RemoteDisk v2.2
MCSv.3.6initialized
Established connection torsa.home.barfoo.org:1045
Connected via socket:Socket[addr=rsa.home.barfoo.org/10.0.0.150,port=2000,localport=4292]
Closing socket
java.lang.NullPointerException
at mcsClient.Row.isValid(Unknown Source)
at java.awt.Component.invalidateIfValid(Unknown Source)
at java.awt.Component.setLocale(Unknown Source)
at javax.swing.JComponent.(Unknown Source)
at javax.swing.JPanel.(Unknown Source)
at javax.swing.JPanel.(Unknown Source)
at javax.swing.JPanel.(Unknown Source)
at mcsClient.Row.(Unknown Source)
at mcsClient.Options.(Unknown Source)
at mcsClient.McsToolBar.(Unknown Source)
at mcsClient.McsClient.begin(Unknown Source)
at mcsClient.McsClient.init(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ausnahme:java.lang.NullPointerException
In the end, I downloaded every version since JRE 1.5.0.11 (that is 20 different versions :!:), as wittnessed by Michael Ellerbeck that the last working version for him was JRE 1.5.0.11, and gave each one a try (since I want to report the issue to IBM, so that they gonna release a fix sometime soon).
So here’s the list of what Java JRE version works with an RSA II adapter running Firmware 1.10 (GGEP36B):
Java JRE 1.50 U11 ……… works
Java JRE 1.50 U12 ……… works¹
Java JRE 1.50 U13 ……… works
Java JRE 1.50 U14 ……… works
Java JRE 1.50 U15 ……… works
Java JRE 1.50 U16 ……… works
Java JRE 1.50 U17 ……… works
Java JRE 1.50 U18 ……… works
Java JRE 1.60 ……… works
Java JRE 1.60 U01 ……… works
Java JRE 1.60 U02 ……… works
Java JRE 1.60 U03 ……… works
Java JRE 1.60 U04 ……… works
Java JRE 1.60 U05 ……… works
Java JRE 1.60 U06 ……… works
Java JRE 1.60 U07 ……… works
Java JRE 1.60 U12 ……… not working (see above)
Java JRE 1.60 U13 ……… not working (see above)
Java JRE 1.60 U14 ……… not working (see above)
1: This version presents some small annoyances (garbled video output)
Update: IBM already knows about the problem, but says it’s presumably a Java problem since it stopped working mid-version in between U11 and U12.
Tobi recently finished writing yet another book, which he also talked about in a blog post. Shortly after, I asked him a rather curious question. What exactly is the plant or animal on the cover of the book ? He was kind enough to send a voucher copy of the book my way.
Praxisbuch Nagios
He actually mentions it in the credits at the beginning of the book. Turns out it is an animal, a sea pen or sea feather (I’m guessing at Pennatula aculeata).
Now as for the content of the book itself, I do have to admit that I haven’t read the whole book. I just picked a few topics (SNMP-Traps with Nagios, notifications) which I did find rather well written. My (soon ex-) trainee, Michel, however already bugged Tobias about some errors in the book itself, or rather some changes which happened after 3.0.3 (that’s the Nagios version the book is based on).
All in all, I guess I can congratulate Tobias on yet another good written book!
Finally, after about 6 months (I last talked about that on February 25th, when Virtual Center 2.5U4 was released) our troubles with our “custom” certificates seems to be resolved! As it turns out, it really was our fault and not VMware’s.
When generating the pfx from the signed certificate and the key-file, you need to supply a password, otherwise the vCenter service is unable to utilize the private key of the pfx, since it’s unable to access the PFX with the default password (testpassword is the default for Virtual Center as well as vSphere).
As noted in the Replacing VirtualCenter Server Certificates document for Virtual Infrastructure 3, as well as through our Customer support, you need to specify the password when exporting the signed crt/Private key into the pfx:
After successfully doing so, you just need to replace the original files (hopefully move them away beforehand) with the ones generated. And afterwards, you should be able to utilize your new certificates! When you now try to clone a template and customize it using an existing customization spec, you’re gonna see this:
vCenter: Cannot decrypt password
After clicking on “OK“, you’re gonna get the normal customization specification edit frame, where you should be able to skip ahead to “Workgroup or Domain“, where you’re gonna have to reenter the domain administrator password.
Today a error message reappeared I thought I wouldn’t see again. We use Wyse Thin Clients and 2X running on two terminal servers, to provide the thin clients with applications. Now, once a while one of the thin clients (not all at once, just a single one) refuse to connect to the terminal server jabbing about this:
1
;html-script:false]The remote computer disconnected the session because of an error inthe licensing protocol.
The error message you get from the 2X client ain’t the slightest bit more helpful.
1
2
;html-script:false]Die Remote-Sitzung wurde unterbrochen,da kein Terminalserver-Lizenz Server zur Bereitstellung einer Lizenz
verfügbar ist.
I remember the solution being not so trivial with the thin clients. As it turns out, Microsoft does have a solution for that kind of problem.
“Simply” open up the registry, and clean out HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSLicensing. That is the place where the remote desktop client saves the obtained terminal server licensing key.
After the last reinstallation of Windows (both at home and at work), I decided that from this day forth, I’d be working as unprivileged user (ie not as local administrator). Now, working as unprivileged user is some kind of relief (since not every program is able to wreak havoc within your computer), but also somewhat of a burden.
Up until now, I had serious troubles burning CDs and/or DVDs as unprivileged user. Basically InfraRecorder refused to work at all. Only way that I had left, was copying the ISO to my local disk and then use runas in conjunction with InfraRecorder, to execute as Administrator.
Yesterday, I sat down and searched the Net for any kind of information. After a short while, I stumbledupon this:
Execute secpol.msc as Administrator. You can configure this security setting by opening the appropriate policy and expanding the console tree as such: “Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options“. Toggle “Devices: Restrict CD-ROM access to locally logged-on user only” to enabled. After logging of and logging back on, you should be allowed to use the CD-drive as unprivileged user.
In the past I had toyed with the thought of setting up a VPN-Server at home, so that I could do stuff from elsewhere. Now, I finally got around doing so. First obstacle ? How exactly would I be doing that ?
Get the DD-WRT VPN flavor of course!
Configure the VPN server
Now, the second part seems to be a bit harder. There is a wiki article on how to configure OpenVPN in the DD-WRT wiki, but not for v24 SP1. Lucky me, someone already made himself the work of writing somewhat of a guide down. But, guess according to Murphy’s law, things ain’t ever gonna be easy. As I’m running Ubuntu Karmic on my workbook, the commands ain’t matching the current openvpn package being delivered with Karmic. So here is, intended only as a guide, the list of steps one has to do in order to get the certs …
1
2
3
4
5
6
7
8
9
10
sudo su-
cd/usr/share/doc/openvpn/examples/easy-rsa/2.0
# Change KEY_COUNTRY, KEY_PROVINCE, KEY_CITY,
# KEY_ORG and KEY_EMAIL with a editor of your choosing
$EDITOR vars
source./vars
./build-dh
./pkitool--initca
./pkitool--server barfoo.org
./pkitool workbook.home.barfoo.org
That’s it … all that’s remaining, is copy & pasting those certs into the Web GUI of your OpenVPN router and setting up your client according to the OpenVPN documentation.
And as the message says, PHP (or rather mod_fastcgi?) would simply stop to process requests. In the end, I tuned some of the lighttpd/mod_fastcgi parameters.
Up till now (I made the change on July 14th), these changes seem to have fixed the issue, guess I’m still hoping (with the saying “Hope dies last” in mind) it’s gonna fix my problems once and for all.
At first, it seemed that my lighttpd issues were resolved by updating PHP/remerging lighttpd. But apparently not. After putting in a crontab entry, that restarts lighttpd every 15 minutes (which completely sucks), the issue was minimized in it’s impact but not really solved.
Thanks to Michél (I guess, again) — who helped me looking at the strace logs, and of course Christian (aka hoffie — one of my old Gentoo buddies), the issue seems finally resolved. It turns out it was neither a PHP nor lighttpd issue. It was a simple matter of (stale) symlinks in /etc/ssl/certs if you can imagine that. Apparently a stale symlink forced PHP into a loop or something, from which it couldn’t recover on it’s own.
So the thank you is probably to the one, who introduced those lines to the ca-certificates ebuild (guess, that would be vapier, the old code monkey):
1
2
3
4
5
6
if[[$badcerts-eq1]];then
ewarn"You MUST remove the above broken symlinks"
ewarn"Otherwise any SSL validation that use the directory may fail!"
ewarn"To batch-remove them, run:"
ewarn"find -L ${ROOT}etc/ssl/certs/ -type l -exec rm {} +"
fi
After letting the find run through /etc/ssl/certs and restarting lighttpd in the process, everything is back to working order! Finally!
