Archive for the ‘Unix-type stuff’ Category
Dell OMSA quick links
In my recent web scour, here are the most useful links for a minimal install of Open Manage Server Administrator to keep an eye on storage status.
- Dell YUM Repository – Use this handy yum repo to install and stay up-to-date on the latest OMSA. Pay particular attention to the section on how to install the individual OMSA components.
- OMSA 6.4 Documentation and in particular the CLI Guide
- Dell Linux Engineering for GPG Key 23B66A9D
Random Notes for OMSA & Dell Update Packages on CentOS 5:
- Use the more recent OpenIPMI package from Dell’s yum repo
- Dell Update Packages rely on libstdc++-33.i386 (which is documented) but also libxml2.i386 & procmail (which is not)
Dell embraces and extends command line utilities
From Dell’s OMSA Manual:
Use the omreport -? command to get a list of the available commands for omreport.
Really, Dell? You’ve decided to go another way on the whole CLI thing? That’s cool, I’m sure there wasn’t any good reason every other Unix utility uses -h for help. Oh wait…
# ./omreport -?
zsh: no matches found: -?
zsh: exit 1 ./omreport -?
Thanks Dell. What I needed was another special case in my life.
Software RAID on OpenBSD 4.8
jpiasetz has a very good recipe on installing with software raid on OpenBSD 4.6, and so far I’ve had good success doing something very similar with OpenBSD 4.8. The biggest thing I changed was using wd1a rather than sd0a for /altroot. Then it’s easy enough to use daily(8)’s integrated altroot sync to keep altroot up-to-date.
OpenBSD 4.8 duplicity port isn’t getting the job done
Trying to use duplicity from the current OpenBSD -stable (4.8) was a non-starter for me. The failure took the form of:
% duplicity -v1 /path/to/files file:///path/to/backups
Traceback (most recent call last):
File "/usr/local/bin/duplicity", line 1236, in
with_tempdir(main)
File "/usr/local/bin/duplicity", line 1229, in with_tempdir
fn()
File "/usr/local/bin/duplicity", line 1207, in main
full_backup(col_stats)
File "/usr/local/bin/duplicity", line 416, in full_backup
globals.backend)
File "/usr/local/bin/duplicity", line 294, in write_multivol
globals.gpg_profile, globals.volsize)
File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 278, in GPGWriteFile
bytes_to_go = data_size - get_current_size()
File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 270, in get_current_size
return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: '/tmp/duplicity-leH-Rr-tempdir/mktemp-nQQHGO-2'
Which turned out to be a terribly confusing and unrelated error message. The error reported in the above stack trace was actually an error in the cleanup process. The actual problem had been masked by duplicity’s gpg fork a long time prior.
So what was the problem?
- pkg_add satisfied duplicity’s gnupg dependency by installing gnupg-2.0.15
- duplicity’s child was attempting to execute gpg, but only gpg2 had been installed by gnupg-2.0.15
That’s right. This problem was solved with ln -s /usr/local/bin/gpg2 /usr/local/bin/gpg.
Well, at least I had the opportunity to get intimate with the python debugger…
Fix your drifting pointer in GNOME
Plagued with a drifting pointer? I sure am.
For me this happens when I accidentally zoom using an accessibility “feature” in GNOME. Actually, it’s in Compiz and ambushes me when I accidentally hit Super (windows key) instead of Alt when resizing a window using the Alt+middle click+drag combination.
Compiz seems to be a little particular about getting the screen fully zoomed out again, but here’s a method that’s (so far) always reset the zoom without leaving me with a randomly drifting cursor.
To zoom out again, hold the super key and scroll down using your scroll wheel. I’m sure there’s a better way, but I don’t know it. Disabling zoom hotkeys in gconf-editor didn’t seem to work for me. If you’ve figured this out, please leave a comment!
ecryptfs mount options
I was having trouble tracking down the ecryptfs mount options that can be used to stop the mount.ecryptfs helper utility from prompting quite so much. I tested this on Ubuntu 10.10. ecryptfs_verbosity claims to be the option that I really want to change, but I couldn’t get this one working.
You can add these options to your /etc/fstab. Their values are partially documented here: http://ecryptfs.sourceforge.net/README
Here’s what I added to my /etc/fstab to stop mount.ecryptfs from prompting for anything besides the password on Ubuntu 10.10:
/root/.crypto /root/crypto ecryptfs noauto,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=n 0 0
Grand Perspective for Disk Usage
I’ll create a theme for today by sharing another program that I love: Grand Perspective. This one is OS X freeware that uses a tree map for visualizing your disk usage. You really wouldn’t know it by the poor choice of screen shots on their site, but this program is incredibly useful for making obvious where all of my disk space went.
Bigger files get correspondingly bigger rectangles, so it becomes immediately obvious where that huge but forgotten download is hiding or which VM needs a good shrinking. If you give it a try, be sure to play around with zoom and focus.
Beware the spacewalk
I think spacewalk is great. It’s a great product provided for free and sponsored by Red Hat. In fact, I think it’s so great that it’s going to keep RHEL-based distros relevant for non-enterprise users for the next 2-3 years. Of course, then someone will add support for debian/unbuntu, but that’s beside the point.
I think spacewalk is great. I’ve been using it to good success for a little while now. It hasn’t reached 1.0 yet, but that hasn’t given me a single problem. Until now.
I expected the roadmap to 1.0 was more of a process of removing the Red Hat proprietary bits, removing Oracle dependence, finishing the migration to java, adding the open source flourishes, etc. The releases up to this point have been reliable and robust.
Then Spacewalk 0.7 released a version of rhnsd that was broken. Not just a little bit broken, either. A lot broken. Broken in a way that means it doesn’t work under any circumstances. Broken in a way that means the code was never tested prior to commit or release. Also it leaks file descriptors. Also it leaks memory.
rhnsd isn’t a minor part of the client. It’s the daemon that runs in the background and calls rhn_check on a configurable interval. If rhnsd isn’t working, that means clients don’t check in. If clients don’t check in then there’s really no point in having Spacewalk.
I expect there to be bugs in pre-1.0 software, of course, but I don’t think it’s too much to ask that code at least be trivially tested prior to release. I still like Spacewalk, but it’s clear that I should be a lot more active in my support of the project.
The thing I don’t understand, though, is that Spacewalk has been released for a month. How has no one else noticed a problem? The community seems pretty active. Am I using Spacewalk in a novel way? Does no one else upgrade their clients? It just doesn’t add up. Maybe I’m doing it wrong.
HD audio buzzzzzzz
So… I’m using a dangerously long audio cable to connect my computer. It’s always caused a buzzing sound when connected to the amp but not my computer. No surprise there.
After a recent hardware refresh, though, it started buzzing while the computer is powered up and connected. It will start buzzing about 10 seconds after a sound is played and continue buzzing until another sound is played. This behavior immediately made me think of a Karmic release note about putting sound cards to sleep.
After figuring out where the kernel documentation is for Ubuntu (it’s the linux-doc package), powersave.txt confirmed my suspicions. The easiest solution for me was to disable this sleep behavior. I’m using a desktop and while it might be nice to put my sound card to sleep, it’s really not necessary.
It turns out that this option is explicitly set to the default in Ubuntu 9.10 in /etc/modprobe.d/alsa-base.conf. To disable this behavior, all you have to do is set power_save=0 in the snd-hda-intel options line. You can change the setting in the running kernel via /sys/module/snd_hda_intel/parameters/power_save.
After a quick “echo 0 >> /sys/module/snd_hda_intel/parameters/power_save”, everything was back to normal, and I could get on with my day.
rsyslog and logwatch don’t play well together
Notice a hell of a lot fewer log messages being reported since you’ve upgraded to a modern syslog supporting RFC 3339-style high-precision timestamps? Yeah, me too.
It seems as though logwatch doesn’t support these timestamps, so it silently filters out all messages recorded by my rsyslog daemons. What’s worse is that I can’t easily figure out a way to disable that behavior. It’s implemented using an executable filter, and — while there’s plenty of documentation about how to override configuration in /etc/logwatch — there’s no documentation about how to *remove* a filter.
Oh well. I never much liked logwatch, anyway. I mostly don’t like any log monitoring scheme that requires me to read through hundreds of daily e-mails that almost always report everything is normal. That’s not sustainable…
tech stuff. 
You must be logged in to post a comment.