A frontend for configuring FUSE filesystems
The title for this post is a little misleading because what I’m proposing is both a frontend and a backend for configuring FUSE-based filesystems.
This started off with me spending 2 days hacking together a small PyGTK tool to mount SSHFS filesystems. It quickly became apparent that my limited PyGTK skills had left me with some pretty ugly code. So, with a little more experience under my belt I decided to start again.
However, this time I’m not just going to tackle the mounting and unmounting of SSHFS filesystems – instead I plan to build a tool for mounting and unmounting any FUSE-based filesystem (whether it’s local or remote) and have it automatically mount selected filesystems on start-up.
I now have a basic specification which calls for the following major components:
- A new file, ~/.fusetab, that will contain definitions for all your FUSE-based filesystems.
- It will need to contain: FUSE driver (e.g. sshfs), filesystem path (local or remote), mount point and a flag to determine whether it should be automatically mounted on startup.
- A PyGTK frontend to manage the filesystems defined in ~/.fusetab.
- A fast, simple Python script to parse ~/.fusetab on startup and automatically mount the specified filesystems.
- A shared library, likely a simple Python class, that encapsulates a filesystem with methods to mount, unmount and get the mount status.
There will need to be hooks defined in the shared library that allows drivers to define additional creation and pre/post mount/unmount behaviour (i.e. when mounting over SSH for the first time it should attempt to append your local ~/.ssh/id_rsa.pub to your remote ~/.ssh/authorized_keys in order to remove the need for a password on-mount).
FUSE drivers will also have to instruct the shared library exactly how to mount filesystems. This I haven’t fully researched but I’m hoping that the Python FUSE bindings themselves will have something to do this elegantly, otherwise I’ll have to have the driver define the CLI program to execute for mounting filesystems.
If anyone reading this has any thoughts on this, especially regarding its design, please comment, I’d love to hear from you.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 UK: England & Wales License.
June 19th, 2007 at 11:06 pm
Sounds pretty dam good. It’ll be good to have a good UI to get no-hassle filesystem access to remote hosts on a per-user basis. NFS is good(-ish) but is not much use if you don’t have root (not to mention its routing complexities, and oh yeah, total lack of security). Few things to add though:
You say it should connect on start-up, but sometimes wouldn’t it be better to connect as the user logs in? If a system had loads of users (on NIS or similar) it would be crazy to mount them all even when they may not be used. Also, on a laptop network connections may not be available until the user has logged in and connected to wireless. Maybe there could be an option for this?
Also, the use of authorized_keys is good, but that would allow any form of ssh use on the remote host with no authentication (which may or may not be acceptable). Would the gnome-keyring be useful here to store passwords?
Lastly, I think there’s a typo where you mean fusetab instead of fstab :p
Good work with that, look forward to seeing something.
Alex
July 9th, 2007 at 8:09 am
Hi, I was thinking about working on a similar tool -> what is your status on this and is there chance of cooperation? For instance, I could help you with the GTK front-end, or anything else. Please reply by mail
Dimitri