Archive for the ‘Linux’ Category
Did your commands with custom -CApath stop working after upgrading to Oneiric? Mine did. It turns out Oneiric introduced a change (via OpenSSL 1.0.0, maybe?) that changed the subject hash algorithm used to index certificates in a -CApath directory. Look for a handy code snippet after the jump.
Read the rest of this entry »
scp doesn’t play well with POSIX filesystem ACLs, and as far as I can tell there’s nothing to be done about it.
The problem is that the server side explicitly calls
open(2) with the mode of the file on the client side in all cases. Since the file’s group permissions are linked to the mask ACL, this means that — for a mode 644 file — the file gets set
mask::r-- instead of inheriting the default mask from the directory.
In my opinion, the correct way to do it would be to create the file without an explicit mode unless the -p command line option was used. In fact, I would have thought that was the point of the -p flag.
This issue isn’t exclusive to ACLs, really. It seems like it would cause problems with standard unix permissions as well. Anyway, the only way around it seems to be changing the mode on the client side prior to the scp. bummer.
Note: I determined this by examining the version of OpenSSH distributed with Ubuntu Lucid, which is 5.3p1. Please let me know if you’ve had a different experience.
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)
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.
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!
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
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.