Tag: Debian

Posting from Hurd!

Nothing’s really occured to me to post in a while, so here’s something kind of random.  I’m actually posting this from GNU/HURD (specifically, the Debian distribution).  I played around with it, installed some software, and eventually got Xorg and Mate running, and then Midori:

Midori on a GNU/Hurd desktop.
Even Midori was kind of sluggish, but it was usable until it crashed.

So how is it?  Slow, for one thing.  Not terribly while just using the terminal, but the install process took hours.  The installer is the basic Debian installer, but things like copying files to the hard drive took longer than it seems like they would under GNU/Linux.  The same is true of just installing packages.  The desktop is of course noticeably sluggish as well, although using something like Openbox might improve things here.  This machine is an old Dell Optiplex, with a 1.6 GHz P4 and 2 GB of RAM (only 768 MB were picked up according to htop).  The graphics are Intel, which I think requires a kernel module on Linux, which of course isn’t supported here.  This probably explains the X slowness, but otherwise while this machine is old it’s felt faster on other OSes.

As far as applications, there are quite a few Debian packages ported over, and while not everything works very smoothly (I tried getting Apache and PHP going, only to have mod-php give an error about allocating shared memory) a lot of familiar programs are available and do run.  I dare say that there’s enough here to run an almost-functional desktop, although there is no sound or USB support (although keyboards/mice may work due to BIOS emulation).

So what’s the point of it then?  The concept of HURD, as in how it runs on top of a microkernel, is interesting.  Basically, this means that most of the services provided are run as a set of servers in userspace on top of a very minimal kernel (Mach in this case).  This is in contrast to Linux, in which these are all part of the kernel.  So, a fault in one of these servers doesn’t necessarily bring down the entire operating system.  In fact, these programs don’t even have to run as root.  This modularity may not be that much of a big deal on a normal desktop or server, considering how mature monolithic kernels like Linux are these days, but one could imagine an embedded or remote system where this could be desirable.  (Think some diagnostic that restarts one of the servers should it crash, so your entire space probe doesn’t have to reboot.)  Some other interesting features in GNU/HURD are the ability for a process to have more than one UID associated with it, as well as translators, which can expose things as part of the filesystem.  (For example, they can be used to mount an FTP share on a directory, similar to Fuse.)

I’m probably not going to be installing a GNU/HURD desktop on my main computer anytime soon.  In fact, I would guess that most people won’t be.  (There are probably exceptions, like people who work on GNU/HURD.)  For day-to-day use, it’s similar enough to a normal Debian (in this case, there are other HURD distributions) system that it’s not really worth the effort compared to the ease of the mainstream alternatives.  However, I’ll be keeping an eye on this project now and then.  Of course, there aren’t many people working on it compared to say Linux, so development isn’t exactly snappy.  But, depending on how it matures it could hold promise in some applications.  (Again I’m thinking of embedded systems.)

It’s also nice to have alternatives.  This is part of the reason I use GNU/Linux, and experiment with other OSes.  Even if HURD really isn’t ready now, it can actually be somewhat useable.  So, I consider it worth checking out, if only as an educational experience.  (And hopefully not as a cuationary tale.)

Cyrus-SASL and IMAP and SMTP-Auth

I lost a little sleep over this, so now that it’s resolved, I’ll throw it here.  I have a Debian mail server, on which I have Email for some local user accounts (system ones, in /etc/passwd), and some virtual users in LDAP.  In order to do this I use the Courier authdaemon, which checks both those sources and lets me authenticate my IMAP and POP3 servers to them.  This works fine.  Thing is, I want to do SMTP auth as well, with Postfix.  (Note: Configuring all these things has been documented many times, look it up.)

SMTP-Auth is generally done via Cyrus-SASL (via saslauthd), which itself can look to a lot of places to determine if the user can log in.  Since I want to allow logins for SMTP to be the same for IMAP/POP, I have saslauthd try to log into my IMAP server (the rimap option, on Debian in /etc/default/saslauthd).  This worked great, until I upgraded to Debian 6.0 (“Squeeze”).

After I ran the upgrade, I was surprised to find that Thunderbird was reporting that Postfix was refusing my SMTP password.  I checked /var/log/auth.log, and found stuff like this:

Aug 21 14:11:48 clamato saslauthd[7289]: auth_rimap: unexpected response to auth request: * OK [ALERT] Filesystem notification initialization error — contact your mail administrator (check for configuration errors with the FAM/Gamin library)

ug 21 14:11:48 clamato saslauthd[7289]: do_auth         : auth failure: [user=myuser] [service=smtp] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server]

Now, both of the above entries are relevant, but I spent most of my time focused on the second one.  (D’oh!)  I searched around for it quite a bit, and found a couple bug reports about it from various points in the past few years.  I even tried one or two patches, but these did not work.  I tried downgrading and backporting, but these did not help.

Turns out the actually cause of this all (ie, SMTP-Auth not happening) has to do with the first line in that file, the one about FAM/GAMIN and filesystem notification.  Courier’s IMAP program likes to have this.  Apparently, it will even go so far as to tell you this when you log into the IMAP server, as I found out while finally deciding to do this via telnet.  I logged in fine, but in the login banner was the same alert message in the log…

Basically, what’s happening then is that saslauthd is logging into the IMAP server, getting the successful login response along with the alert message, and is concluding that the login was not in fact successful.  I was able to fix this just by installing the gamin package; see this page for slightly more information.

In my opinion, there is in fact a bug here, aside from my own inability to notice the other log message.   Courier logged me in successfully, even with the alert.  Saslauthd should’ve picked up on that.  Here’s the code to check this:

if (!strncmp(rbuf, TAG ” OK”, sizeof(TAG ” OK”)-1)) {
if (flags & VERBOSE) {
syslog(LOG_DEBUG, “auth_rimap: [%s] %s”, login, rbuf);
}
return strdup(“OK remote authentication successful”);
}

This is part of the auth_rimap.c file, and causes the auth_rimap function to return if the banner was correct.  However, if the banner is not exactly what it was expecting, it skips this and gives the unexpected response message.  I may put together a patch to change this, but right now I think I will go for a swim.

(On another note, I need to get a good code display plugin for this blog, so I’m not using block quotes for that.)

Windows Shares in /etc/fstab

A project I am doing at work involves having a Debian Linux machine mount a Windows share, and then letting a script go in and pull some data out of files for processing.  A lot of this is easily handled by Perl, but the first task is to mount the share.  And this had me stumped for a second.

The syntax for mounting a share in /etc/fstab looks kind of like this (on one line):

//servername/sharename    /mount/point   username=user,password=pass,default   0 0

Now, I had something like that set up, but when I would try to mount it by typing mount /mount/point, I would get an error like this:

[mntent]: line 21 in /etc/fstab is bad
mount: can’t find /mount/point/ in /etc/fstab or /etc/mtab

Now, I couldn’t figure out what was causing this at first.  I mean, it worked fine when I just used the mount command.  But, it turned out that the problem was a space in the Windows share name (something like /servername/share name).  I had thought that using a simple \ to escape the space would work, but on a hunch I searched to see if there was a proper way to escape, specifically for /etc/fstab.  This post explained it, and now I have the following in /etc/fstab:

//servername/share\040name    /mount/point   username=user,password=pass,default 0 0

Basically I just replaced the space with \040, which is unicode for a space.  Now I can mount it with no problems.