Monthly Archives: May 2007

How NOT to Make Iced Coffee

Messy Iced Coffee.jpg

1. Grind coffee beans 2. Dump grounds into a Nalgeen 3. Fill with water 4. Shake to mix grounds into water 5. Let stand to brew …. 6. Mess around with coffee filters to try and get the stupid grounds back out…
Warning: Performing the aforementioned steps may incur incredulous laughter from any baristas you may know… 😉

End of the Semester!

Geek Mug.jpg

Well, with the conclusion of the ECE 453 open house a little bit ago, my classwork for the semester is officially over! Everything ended up on a really great note, culminating in the above mug, our award for the “best in class” design project. More later, when I get ahold of Ben’s video of our project in action 🙂 Now to enjoy some iced coffee…

Even Nerdy Boys Will Be Boys

Grass Stains.jpg

In a way I think I’m actually glad to learn I haven’t outgrown grass stains. Keeps me from over-nerddom 🙂 Plus it was totally worth it, ey Jared?
Anyhow, for those concerned about what happened to me lately, fear not. It’s simply project time of the semester, and thus I live in Engineering Hall 🙂 I’ll ae resuming my regularly-scheduled life on Thursday, at which point all will be in and graded!
See you then.

Totally Seamless SSHFS under Linux using Fuse and Autofs

This is awesome.

I worked on this for something like 2 hours this afternoon, and finally tracked down all the nuances to get it working. I’m really pleased with the results, and hope that they can be of some to use to you as well, because I could not find a decent tutorial on this subject despite extensive Googling.

The Problem: Connect to a remote filesystem over SSH

Odds are if you’ve stumbled on this tutorial, you already know the problem: You want to access a remote file system over SSH. You want to use FUSE SSHFS, and you don’t want to ever have to think about it, so you’re looking for Autofs integration. To keep this to the point, I’m going to skip over the installation of these packages and just explain the configuration, especially since installation is very distribution specific. I’ll simply say on my system (Ubuntu Feisty) it consisted of:

sudo apt-get install sshfs autofs

The Solution

Getting SSHFS to work with Autofs really isn’t hard, you just need the magic configuration. Here’s how I got things working for me:

  1. Set up certificate authentication for your local root to the remote account on the remote machine, by use of sudo ssh-keygen locally, and the (remote account’s) ~/.ssh/authorized_keys file.
  2. Test the certificate authentication by verifying that the following command does not prompt for your remote password:
    sudo ssh remoteuser@remotehost uptime
  3. Test that sshfs can establish the requisite connection:
    sudo mkdir /mnt/sshfs_temp
    sudo sshfs remoteuser@remotehost: /mnt/sshfs_temp
    sudo fusermount -u /mnt/sshfs_temp
    sudo rmdir /mnt/sshfs_temp

    Note that the : is required after the host to specify the remote directory. (: alone means the remote user’s home. :/remote/path indicates a remote path.)

  4. Add the following line to your /etc/auto.master file:
    /mnt/ssh /etc/auto.sshfs        uid=1000,gid=1000,--timeout=30,--ghost

    Where /mnt/ssh is the path you want all ssh automounts to appear in,
    1000 is the UID of the user you want the sshfs mount to belong to (i.e., be writable by),
    1000 is the GID of the user you want the sshfs mount to belong to, and
    30 is the timeout in seconds to keep the FUSE connection alive.

  5. Copy the following into a new file /etc/auto.sshfs:
    #
    # This is an automounter map and it has the following format
    # key [ -mount-options-separated-by-comma ] location
    # Details may be found in the autofs(5) manpage
    remote1     -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs#remoteuser@remotehost1:
    remote2  -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs#remoteuser2@remotehost2:/remote/path
    

    This creates two sshfs mappings (obviously, adding or removing lines creates more or fewer mappings).
    The first will be at /mnt/ssh/remote1, and map to the home directory of remoteuser on the host remotehost1.
    The second will be at /mnt/ssh/remote2, and map to the directory /remote/path on the host remotehost2, with the permissions of the user remoteuser2.
    Note the characters to escape # and : These escape characters are what took me two hours to track down: FUSE requires a parameter of the form: sshfs#user@host:directory, but autofs treats everything following a # as a comment, and the : character has a special meaning. These characters must be escaped by a

  6. Restart autofs to reload the configuration files:
    sudo /etc/init.d/autofs restart
  7. Test it out! As root or the user indicated by uid above, run:
    ls /mnt/ssh/remote1

    You should be greeted by the contents of the remote file system. Congratulations!

The Problems

  • This exact setup only works for one user due to specifying a uid. This is fine for a home desktop system, but will likely need further work to allow multiple users access to the remote filesystem. Perhaps careful usage of gid could alleviate this problem, though logging into the remote machine as a specific user still represents a security risk.
  • I have not examined the architecture enough since I am only seeking to enable my home desktop system, so I cannot vouch for the security of this setup whatsoever. For example, the use of the allow_other option for FUSE may have security consequences since the mountpoint is created as root (to my understanding, at least).

Your Friendly Neighborhood Fountain Repairman

Fountain Repairman.jpg

After the annual cleaning-out of the tree blossoms that clogged the fountain, Chris (pictured) and I turned our attention to a couple misaligned valves and cracked air hoses. And correcting the mistake of one really misguided computer engineer -that would be yours truly- who thought a spigot was leaking like crazy, when in fact, water was simply coming out because he opened it.