open-vm-tools for Debian Etch
Posted on March 27th, 2008 by Christian in Life
Well, after a loooong time of trying to get the modules and all the other stuff (read: init-script for the guest daemon and modules) working, I think I’m about there.
I finally fixed a long-standing issue, with the postinst/prerm scripts, and the tools should be about ready. Gonna try and send it Daniel Baumann’s way (that is the Debian Maintainer), for proper inclusion into Lenny.
I (successfully) tried splitting the Xorg parts from the “normal” open-vm-tools, as I usually don’t want Xorg installed on *any* of my virtual machines. Thus leaving me with open-vm-tools, open-vm-modules and open-vm-toolbox (and open-vm-source) as a list of packages one could install.
metadata.xml (the third)
Posted on March 14th, 2008 by Christian in Gentoo
So Petteri came up with a nifty python script (nopaste|local), which in return spit out this. Which generated a rather complete list (nopaste|local), that looks like this:
700: perl
569: maintainer-needed
128: media-video
126: xemacs
47: sound
32: ha-cluster
32: crypto
19: desktop-misc
16: netmon
15: forensics
13: web-apps
10: pam-bugs
8: vserver-devs
8: mips
8: embedded
8: app-backup
8: apache-bugs
8: alsa-bugs
7: net-im
7: kde
6: tcltk
6: media-tv
6: dev-embedded
5: voip
5: theology
5: samba
5: net-p2p
5: freedesktop-bugs
4: sparc
4: java
4: graphics
2: net-mail
2: ldap-bugs
2: kernel
2: fonts
2: cpp
1: x11
1: wxwidgets
1: www-servers
1: tex
1: shell-tools
1: sgml
1: sci
1: qmail-bugs
1: python
1: proaudio
1: media-optical
1: kerberos
1: hp-cluster
1: amd64
metadata.xml (the second)
Posted on March 14th, 2008 by Christian in Gentoo
As I was kinda bored after work today, I had a closer look at what I saw during my fuckup in the morning. Well, Steve said, that when he looked at metadata.xml it’d be “really common” .. still that isn’t making it right ..
There is a reason we do have a herds.xml (exactly for the reason to associate people with packages, and that’s what the <herd> tag is for in metadata.xml) file. So after a preliminary look through the repository, here are the winners:
700 : perl
126 : xemacs
63 : haskell
47 : sound
32 : ha-cluster
31 : crypto
19 : desktop-misc
16 : netmon
15 : forensics
13 : web-apps
8 : mips
8 : app-backup
7 : kde
6 : tcltk
6 : net-im
6 : media-tv
6 : dev-embedded
5 : voip
5 : theology
5 : samba
5 : net-p2p
4 : sparc
4 : java
4 : graphics
2 : net-mail
2 : kernel
2 : fonts
2 : embedded
2 : cpp
1 : x11
1 : wxwidgets
1 : www-servers
1 : tex
1 : shell-tools
1 : sh
1 : sgml
1 : sci
1 : python
1 : proaudio
1 : php
1 : media-optical
1 : kerberos
1 : hp-cluster
1 : gentopia
1 : amd64
Don’t know how accurate that list is, but you can check it for yourself. The commands I’ve used are these:
for i in $( < ../herds.list ); do grep --exclude=eclass --exclude=CVS \ --exclude=profiles --exclude=skel.* -R \ "<email>$i@gentoo.org</email>" /cvs/gentoo-x86/* ; done > redundant-metadata-xml.list
for i in $( < herds.list ); do echo -e " $( grep "<email>$i@gentoo.org</email>" \ ~/public_html/redundant-metadata-xml.list | \ wc -l )\t: $i"; done | \ grep -v "^ 0" | \ sort -nr > public_html/redundant-metadata-xml.overview
While herds.list holds a list (separated by \n) with all the herds there are. The raw files are here and here and here. Knock yourself out!
metadata.xml
Posted on March 14th, 2008 by Christian in Gentoo
So I ended up cleaning out some retired (~20) people from metadata.xml, where I found this interesting piece of metadata.xml:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> <pkgmetadata> <herd>kernel-misc</herd> <maintainer> <email>crypto@gentoo.org</email> <name>Crypto herd</name> </maintainer> <maintainer> <email>masterdriverz@gentoo.org</email> <name>Charlie Shephered</name> </maintainer> </pkgmetadata>
And here the hint for all you people again: A DAMN HERD AIN’T NO MAINTAINER. SO IF YOUR HERD IS MAINTAINING A PACKAGE, PUT IT INTO <herd> and not into the <maintainer>. kthnxbye.
To be or not to be …
Posted on March 9th, 2008 by Christian in Gentoo, Life
… that’s the question. I’ve been thinking lots and lots about my involvement with our “beloved” distribution.
I talked to some of the users (that is Gordon), some fellow developers (hello Christina, Łukasz, solar, Jorge, Anders) about whether or not I’m actually still wanted and/or needed. Turns out, the collective opinion is, that I am fun to have around (*shrug* don’t ask me why, I don’t find myself particularly funny/amusing) and that’d I’d be the person to have around.
That being said, I still do have some things on my agenda (they haven’t changed .. like getting healthier - as in heading to the gym; getting a better paid job; getting my own life; getting some friends), which are going to jockey with those Gentoo interests.
Integrating Windows XPe into Active Directory
Posted on March 7th, 2008 by Christian in Life
As the guys over at FreeWyseMonkeys demonstrated with JoinDomain.zip, it ain’t hard to integrate a Windows XP Embedded system into Active Directory.
You basically need this:
- A system powered by Windows XP Embedded
- netdom.exe (from any Windows XP - SP2 in your MUI language)
- some know-how, on how to use netdom to integrate it into your AD
Everything else is already present on the Windows XP Embedded systems I’ve seen. Then let’s get it on !
First, copy over the netdom.exe to your XPe, and then run the following command:
netdom.exe join /d:barfoo.org \ /OU:"OU=Thinclients,OU=Computer,DC=barfoo,DC=org" \ %COMPUTERNAME% \ /ud:Administrator /pd:P@ssw0rd \ /uo:Administrator /po:P@ssw0rd \ /verbose
Here as a note:
- ud and pd is a User/Password inside your Active Directory with the permissions to create new computer accounts
- uo and po is a User/Password with administrative rights on the Windows XP Embedded device
After that, you just need to reboot, Et Voilà! the system is present in your Active Directory. Just be aware, if you’re using a localized Windows XP Embedded by Wyse, make sure to contact your fellow Wyse Support, as the is a bug with the MUI stuff needed for the domain logon.
Also, as yet-another side note: The default Administator password is mentioned in this Knowledge Base entry.
Backup solutions
Posted on March 7th, 2008 by Christian in Life
Well some people apparently completely *don’t* understand the use of a backup client like dsmc, additionally they don’t seem to have the slightest clue on how to draw up a “clever” backup solution.
Lemme describe the situation for you. We do have two Solaris systems at work, housing our mailing system(s). Now apparently, people are unable to install the Tivoli Storage Manager Client on Solaris (or get it working properly - which people are blaming on the software not working).
Now, they draw up this insane plan … We do have about 900GiB of mail space, which is currently located on our SAN. So people decide, they don’t want the backup client on their system, as it’s slow (which I do agree to, dsmc is *slow* for large amounts of data - especially if it’s 900GiB in 15MiB parts).
So they think of something like this:
- Attach a second disk to the mail system
- The mail server then creates a tar file (at which iteration I can’t say, but from the size of the volume, I’d figure once a day) on the secondary disk
- The mail server exports said disk via NFS
- Another, semi-independent system then imports said disk via NFS, while also housing the Tivoli Storage Manager client, to backup that big tar-file …
So much for *well* planned backup solutions ……… 
OCFS2 follow-up
Posted on March 7th, 2008 by Christian in Life
OK, it turned out that said collegue wasn’t responsible at all. Turns out, the *real* trigger was me creating a new volume on our SAN, on the same array that houses the OCFS2 volume.
Apparently, during creation of an additional SAN volume, all other SAN volumes in this array are either read-only or delayed during that time, as you can see from the following log:
kernel: (13,3):o2hb_write_timeout:242 ERROR: Heartbeat write timeout to device sdd1 after 12000 milliseconds kernel: Heartbeat thread (13) printing last 24 blocking operations (cur = 4): kernel: Heartbeat thread stuck at waiting for read completion, stuffing current time into that blocker (index 4) kernel: Index 5: took 0 ms to do submit_bio for read kernel: Index 6: took 0 ms to do waiting for read completion kernel: Index 7: took 0 ms to do bio alloc write kernel: Index 8: took 0 ms to do bio add page write kernel: Index 9: took 0 ms to do submit_bio for write kernel: Index 10: took 0 ms to do checking slots kernel: Index 11: took 0 ms to do waiting for write completion kernel: Index 12: took 2002 ms to do msleep kernel: Index 13: took 0 ms to do allocating bios for read kernel: Index 14: took 0 ms to do bio alloc read kernel: Index 15: took 0 ms to do bio add page read kernel: Index 16: took 0 ms to do submit_bio for read kernel: Index 17: took 0 ms to do waiting for read completion kernel: Index 18: took 0 ms to do bio alloc write kernel: Index 19: took 0 ms to do bio add page write kernel: Index 20: took 0 ms to do submit_bio for write kernel: Index 21: took 0 ms to do checking slots kernel: Index 22: took 0 ms to do waiting for write completion kernel: Index 23: took 2004 ms to do msleep kernel: Index 0: took 0 ms to do allocating bios for read kernel: Index 1: took 0 ms to do bio alloc read kernel: Index 2: took 0 ms to do bio add page read kernel: Index 3: took 0 ms to do submit_bio for read kernel: Index 4: took 9995 ms to do waiting for read completion kernel: (13,3):o2hb_stop_all_regions:1682 ERROR: stopping heartbeat on all active regions. kernel: Kernel panic - not syncing: *** ocfs2 is very sorry to be fencing this system by panicing ***
OCFS2 fun
Posted on March 6th, 2008 by Christian in Life
Turns out, that said colleague has been playing with NFS on one off the web nodes, thus apparently rendering the remaining nodes offline (or semi-offline).
Now after all web nodes hung themselves, we had to hard reset them, now everything is tingly again .. *yay* for a great first day …
OCFS2 fun yet again
Posted on March 6th, 2008 by Christian in Life
I’m coming back today from a six day vacation in the warm south (that is Stuttgart), back at work and find three sheets of paper on my desk. Two tell me something I haven’t done yet, the other one tells me something I haven’t seen yet.
One of my colleagues had to restart one of our web nodes and now the thing can’t mount the logging volume (and thus, logrotate / awstats failed to do it’s job). OCFS2 ain’t spitting any error messages, when trying to mount the volume you see it joining the domain the volume belongs to on the other nodes, so from a first glance at things .. nothing is wrong ?
One thing I’ll have to add is, that you can’t reboot the box cleanly (as in you have to use the power button, so I figure something is either stuck or something is malfunctioning ..) *shrug*