[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC2 and FC1 and common home



On Wed, 2004-04-07 at 10:21 -0400, Colin Walters wrote:
> On Tue, 2004-04-06 at 22:47, Jeremy Katz wrote:
> 
> > But this isn't really all that ideal from an interface point of view.
> 
> I agree.  It is kind of a one-time special case though.

Which makes it all the more icky :)

> > 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).
> 
> That's an option, but it is a little tricky.  We'd have to be sure to
> give every domain that the user runs access to that type; e.g. right now
> ssh will refuse to look at a key unless it's user_home_ssh_t.

We're going to have to do something about this anyway.  NFS /home is not
uncommon and there's no way to do full security contexts with NFS --
it's just not in the protocol at all.  And that doesn't even start to
get into more bizarre things like AFS ;)

> > No, that's completely and utterly manual.  How do I scp to them? 
> 
> for machine in foo bar baz blah; do
>   scp policy.15 $machine:
> done
> 
> ?

And then I either have to type my password n times or use an ssh key or
something else like that (or an expect script).  But what happens if baz
is down when I push my update?  I then have to remember to go back and
update it later when it comes back up.  And that's with four machines.
As you get to more and more machines, it gets increasingly less
managable to do things like that.

> >   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.
> 
> You could also have a polling model or something where the machines
> check for updates from the central server.  I don't see what's wrong
> with push though...

At which point we're basically creating a duplicate of nis/ldap but with
other bits thrown on top :/

Jeremy



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]