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

Re: Bits from the release team: the plans for etch



On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote:

> An other issue that always annoyed me is that assuming a NIS server
> and a NIS client which both install say exim.  I want to give some
> users membership in the group Debian-exim.  I can't easily.
> 
> The UID picked by Debian-exim is not going to be the same for the NIS
> server and all the NIS clients, so I cannot get it propagated by NIS.
> And I don't want to have to maintain the group membership on all the
> clients.

That is a local administration decision. You should have a clear policy
wether you'll be allowing system groups in NIS _before_ creating the NIS
domain. If you do, you should have a plan _before_ creating the NIS
domain about how you will deal with the inevitable conflicts.

When I last administered a complex distributed environment (we used
first NIS+ then LDAP, but that's not important), we had a policy that
local software should never use user/group IDs coming from NIS+/LDAP,
and software installed on shared filesystems should never use user/group
IDs _not_ coming from NIS+/LDAP. Mixing local and remote IDs in group
membership was forbidden as well. That worked quite well.

> Yet some packages do not deal very well with that solution:  some are
> confused by some user or group that they cannot modify with usermod or
> groupmod.  Others are confused when removing the user or group
> (userdel and groupdel failing to remove a NIS entry).

Well, administering a distributed environment is more complicated than
administering a single machine and you should be prepared for this kind
of problems.

As for Debian, it would be useful to submit bugs for such packages when
you encounter them. Package maintainers often do not use NIS/LDAP etc. so
they have no experience in this area. Being nice to distributed NSS is
seldom hard if you understand the common problems.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------



Reply to: