Re: Multi-distro home directories

[Jeff Licquia <jeff@licquia.org>]

On Mon, 2003-06-09 at 13:03, mike808@users.sourceforge.net wrote:
> 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.

Well, this is at work, so all the machines in question are behind a
firewall.  We don't allow NFS through that.  We are looking into various
VPN technologies that might allow better integration with off-network
systems.

But I was more referring to the fact that the problem is similar to
yours, in that we have to share home directories across multiple
platforms.

> > 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. 

I'm not sure I understand your problem here.  If something is installed
on one distro but not another, then the menu entry obviously shouldn't
show up on the latter.  If you want consistency, you need to make sure
the same stuff is installed on the same systems; it's when you don't
that the above behavior manifests itself.  What would you prefer it do,
if not that?

> 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.

In other words, you have two incompatible goals here.  You want to demo
the default system, but you also want to change the system from the
default in order to meet another goal.

Suppose SuSE doesn't include Gnumeric, and you port the Red Hat version
for consistency's sake.  So when the Gnumeric icon shows up on the SuSE
desktop, is that the default?  Nope.  And people who install SuSE based
on your demo will wonder what happened to Gnumeric.

You'll have to trade off consistency for "authenticity".  Some changes
won't be user-visible; some might.  You'll have to judge when to
sacrifice authenticity for consistency or vice versa.

> 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.

This actually seems like a fairly straightforward tradeoff.  By
including e2fsprogs that supports all possible options, fixing label
support in SuSE, Mandrake, and Xandros, reconciling SuSE's handling of
reiserfs (or just avoiding reiserfs altogether), and writing a
cryptotab-to-fstab-and-back utility, you should be able to reconcile the
differences in ways that aren't user-visible.  It will be a lot of work,
and a pain to maintain as the distros change, but it's possible.

> 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.

Speaking from experience here, I can tell you that there's really no
shortcuts to achieving this.  Not only are the distros different, but
they keep changing in different ways.  You'll end up constantly chasing
them.

As for patches: most of the distro vendors, frankly, aren't going to
care.  Debian might, to some degree, but the other vendors certainly
won't.  The problem you describe is, at best, irrelevant to them, and in
some cases works against their interests.

Take Red Hat, for instance.  Why would they put time and effort into
making their distro more compatible with SuSE and Mandrake so that
people can build "comparison stations" that allow people to evaluate the
distros on the merits?  They're the market leader; it makes no sense for
them.

> > 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.

In that case, you'll probably need to set up something like my session
scheme, where the right session for the running distro is detected and
loaded when you log in.

> > > 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.

That's, again, where you need to decide whether authenticity or
consistency is more important.

> 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.

Here's the direction I would take, were this task handed to me:

Control the X session.  Provide .xsession, .xinitrc, and their
equivalents on every distro.  In the .xsession, detect the distribution,
and set the session based on the distro.  If the distro's session
doesn't exist yet, create a new session.  Support a very limited number
of distros you can verify to start.

You've got other problems to solve, as well.  How, for example, do you
handle user management?  What about errors, where the user logs in
without inserting the drive?

> 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.

The job you described before sounds too big.  You might want to limit
your scope to this Knoppix system, and require a reboot for your scheme
to work.  This way, at least you've got a consistent platform to base
your work on.
-- 
Jeff Licquia <jeff@licquia.org>

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