Re: Multi-distro home directories

[mike808@users.sourceforge.net]

Thanks Jeff, Alan.

Q: Anyone shared home directories across distros on a multi-boot system?

Jeff replied: 
> We've played a little at work with shared NFS home directories on
> multiple machines with different distros (and different versions of the
> same distro), which is close to the same thing.

How do you deal with RPC/firewall issues? NFS (actually RPC) requires a huge 
hole in your firewall to work (i.e. open everything >1024).
Not to mention two machines. Yuk. I've thought about using samba and 
smbmount instead - that I could live with the firewall rules required.

> GNOME seems to not have a problem with missing icons; they just don't
> show up in the menu.  Toolbar launchers typically just don't work, and
> sometimes have the GNOME "missing" icon in place of the app icon, but it
> doesn't seem to cause a problem, and the launcher comes back when the
> app is installed.

Well, in my book, that's a problem when stuff "just doesn't show up" in menus.
Users like consistency. And when stuff isn't there, I don't know its not
there because GNOME didn't like it or because the distro just doesn't 
provide it. My purpose is to be able to demonstrate different "default" 
distributions on a single system (boot drive), and still have the system
as a whole, be reasonably useful - for example to fix something in some 
distro or port something from one packaging to another. LSB and common
packaging (SDEBs and SRPMs) help quite a bit for that.

By porting I usually mean synchronizing a particular version and options
for a package across several distributions. They are almost always different,
and each distro throws in their own "tweaks" for a given package.

My poster child for this is the e2fsprogs package. MDK uses 1.32 w/ HTREE,
SuSE 8.1 uses 1.27, SuSE 8.2 uses 1.28 w/o HTREE, RH9 uses 1.28. And each
has tweaks specific to what they each thought was a problem for their distro.
SuSE, for example, has different reiserFS-handling code than was adopted
for 1.32. And, being able to mount and use each other's ext3 filesystems 
is a big deal in this setup. RH likes to label their filesystems and 
uses it extensively in their fstab. SuSE, MDK, and Xandros ignore using labels 
in /etc/fstab, and barf when encountering them in the way the RH uses them.
SuSE separates out cryptofs into /etc/cryptotab; RH and MDK use /etc/fstab.
So, synchronizing the fstab across the distros is not trivial.

So, getting all of these to play nice with a common version (and patches)
is quite desirable. Then, having a package around to install on each, 
send patches back to the various distro vendors, etc. is also handy. 
Especially if rebuilding a distro image or building a new one.

> Themes might be a problem; for example, if you're set up on RH's
> Bluecurve theme, you might have a problem on a system without
> Bluecurve.  But I typically just pick themes that are available on all
> the systems I use.

Part of the exercise is to be able to show the "native" distro, so making
them all look the same doesn't really do that, nor does it help when I want
to post how-to instructions, since the menus I'm seeing are totally different 
than what the questioner will.

> What I'd worry about is that you'd have stuff strewn all over your 
> multiple user directories.

Uh-huh. Yup. Ditto.
 
> It might be a good idea, too, to try and keep the distros running
> something close to the same software as much as possible.  So, for
> example, don't upgrade to any KDE 3.1 distros until all of them support
> it.  That might be hard if Debian is in the mix (Keith Packard
> supposedly describes the Debian versions as "stale", "testy", and
> "usable" :-), although there are backports of KDE and GNOME to woody
> which might help.

It is. Xandros and Lycoris are some of my selections. I've slots for a pure 
Debian and a Libranet, too. See my comments on using a common e2fsprogs.
It's not as trivial as one might think.

> > Also, anyone know of any project or folks working on cross-distro cryptoFS
> > stuff? At last check, SuSE uses blowfish, MDK uses AES128, RH has XOR, and
> > none of them can mount each other's CFS. Go figure.
> 
> That's weird.  Are they just missing the right crypto modules, or are
> they really different systems?  I can't imagine any distro not including
> all of the popular algorithms, even if their setup tool prefers one of
> them.

Well, they don't. They typically include only one module (i.e. that they 
will support for $$$) - it's the one I listed for each. So I usually wind up 
compiling the module for the other distros. And then they each have a different 
process for mounting cryptoFSes. SuSE likes to mount them at boot time. I'm 
thinking to use them as a private FS for a specific user (like a home 
directory), for example, on a keychain USB drive. SuSE thinks it's more a big 
fat data partition that anyone can access once it's mounted, and they really 
only support cryptofs mounting during boot time. To me, once it's mounted, it 
might as well be a regular FS and accessible to all, not just the process tree 
of the process mounting the cryptofs.

There's a user-space cryptoFS effort that looks interesting, and it 
operates at a process level, but requires hacks to login and such.

So, I think you can see where this is going: a USB-based keychain drive
with a user home directory on a cryptofs usable on different "host" distros.

There's a security-oriented personal edition of Knoppix that's getting close.
i.e. a Knoppix "boot anywhere" CD with an encrypted USB keychain to securely
use any system that boots Knoppix (which is a lot) and doesn't touch
the underlying host system. *That* would yield a secure, portable "desktop" 
system - making the CPU, network, etc. a commodity. A distributed roaming 
profile, not constrained to a central profile repository, if you will.

Mike808/

---------------------------------------------
http://www.valuenet.net



-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.