FC2 and FC1 and common home

Jeremy Katz katzj at redhat.com
Wed Apr 7 02:47:08 UTC 2004


On Tue, 2004-04-06 at 19:58, Colin Walters wrote:
> On Tue, 2004-04-06 at 19:42, Jeremy Katz wrote:
> > Unfortunately, they can't.  Anything before one of the FC1 update
> > kernels actually panics on boot if you have xattrs set on the
> > filesystem. 
> 
> Ah.  Is that the fast-symlink bug?

Yep.

> > One problem is that we do partitioning before we ask about SELinux which
> > leads to a bit of a chicken and the egg question of how to handle this
> > (it's pointless to ask someone who's installing without SELinux if we
> > should label their preexisting /home).
> 
> Ah, true.  Perhaps another dialog at the end - only displayed if SELinux
> is enabled and a previously-formatted partition was mounted.

But this isn't really all that ideal from an interface point of view. 
Why should this be handled separately from the rest of the questions
about my partitions?  I'm also trying to move to less dialogs, not
more.  Some thought is definitely required.  Another option would be a
special-case of preexisting /home getting mounted with the context mount
options, but I don't really like that other (it feels like a hack).

> > Because users.te isn't centrally managed.  I shouldn't have to touch
> > every one of the systems I maintain just to add a user.  If I have to do
> > that, we might as well go back to the stone ages where I had to manually
> > distribute a new passwd file to every machine I maintain to add a
> > user.  
> 
> It's not *that* manual; you could just have a little script which builds
> a policy with the modified users.te on one of them, scp's it over to all
> of them, and then runs load_policy.

No, that's completely and utterly manual.  How do I scp to them?   I've
written the expect script to do this sort of thing before and it's not
really what you want to use in an environment of any size.  If I have to
at all touch a machine to make a trivial and common change like this,
then I'm not really centrally administered.

Jeremy





More information about the fedora-devel-list mailing list