OpenBSD creating additional ptys
I like a lot of windows. A lot of them. Today I bumped into a default limit on OpenBSD 4.8 and tmux(1) started returning “No such file or directory” when I attempted to create a new window. This turned out to be a simple thing to solve, though.
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.
Rackspace: meh. not that fanatical.
I had such high hopes for Rackspace. I’ve been hearing so many great things, I couldn’t help but get my hopes up. My experience with Rackspace was anything but good, however.
It’s not like my request was complicated. I wanted about 10 servers in managed colocation on a private switch behind a pfsense firewall. Managed colocation means that I’ll do all the work of configuring them. All Rackspace has to do is stick some servers in a rack and connect them with cables. This is part of their advertised service offering.
Talking to the Rackspace sales team was an ordeal. The problem wasn’t that I had to go through four tiers of sales people — though I did — or that they didn’t get back to me when they said they would — though they didn’t. The biggest problem I had is that every time I’d advance through another tier of sales people, they would contradict the previous tier. Every time I talked to someone new they would take something off the table until, in the end, we arrived at a solution that didn’t resemble what I wanted in the first place.
The last straw was when the latest salesperson told me that he just found out about a new rule that all managed colocation customers are required to rent a Cisco ASA firewall. My BSD firewalls aren’t good enough. This seems especially confusing since (presumably) I wouldn’t have to administer a Cisco firewall if I were to just rent 10 dedicated servers from them.
Regardless, for $600 per month per server I should be able to configure them in whatever way I want. That’s way too steep a price to put up with all this run around.
I shall make a point of never doing business with a company who doesn’t list their prices on their website.
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.
tech stuff. 
You must be logged in to post a comment.