tech stuff.

Posts Tagged ‘Linux

scp and POSIX ACLs

leave a comment »

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.

Written by Lee Verberne

2011/07/07 at 13:21

Posted in Linux

Tagged with , ,

Beware the spacewalk

with one comment

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.

Written by Lee Verberne

2010/01/26 at 23:01

Posted in Linux

Tagged with , , ,

HD audio buzzzzzzz

leave a comment »

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.

Written by Lee Verberne

2009/12/26 at 20:12

Posted in Linux

Tagged with ,

Simple encrypted disk images in Linux

leave a comment »

The Linux kernel supports encrypted loop images via the cryptoloop driver, so you can use losetup(8) to create simple encrypted loop devices for those situation when cryptsetup/LUKS/device-mapper is unavailable or too complicated.

You’ll need the following modules loaded (or compiled in):

  • loop
  • cryptoloop
  • twofish (or whatever algorithm you prefer)

First you’ll need to allocate the file:

# dd if=/dev/zero of=<file> bs=1k count=<fs-size-in-kilobytes>

After that, you can ask losetup to loop it to the first free loop device and report back which it chose:

# losetup -e twofish -f -s <file>

The first time out you’ll want to format the device (e.g. mke2fs -j /dev/loop0), after that it’s just a matter of mounting (mount /dev/loop0 /mnt).  After you’re done you can use losetup to close the file and remove the device:

# losetup -d /dev/loop0

An important note about this method is that there is no sort of password validation.  Whatever password you enter will be used by the encryption algorithm.  That means if you enter the incorrect password then you’ll just read (or worse: write) a bunch of garbled data from the device.

Written by Lee Verberne

2009/01/08 at 16:08

Posted in Linux

Tagged with