[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi-distro home directories
Thanks Jeff, Alan.
Q: Anyone shared home directories across distros on a multi-boot system?
> 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
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.
To unsubscribe, send email to firstname.lastname@example.org with
"unsubscribe luci-discuss" in the body.