Bug#329701: Re: Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Marc Haber]

user [EMAIL PROTECTED]
usertags #329701 close-20060531
thanks

On Wed, Dec 21, 2005 at 10:43:04AM +0100, Marc Haber wrote:
> adduser maintainership would like to see this discussed on
> debian-devel. Please state your case there, and I'll decide what to do
> afterwards.

Since the original submitter doesn't seem to have cared to start that
discussion (at least I have not seen it on -devel), I am tagging this
bug to be closed on 2006-05-31. This is more than three months in the
future, so there is plenty of time to discuss this with the other
Debian developers. I might be influenced to do the change if the
discussion doesn't point out bad negative effects of the change.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Wed, Dec 21, 2005 at 10:43:04AM +0100, Marc Haber wrote:
> On Wed, Dec 21, 2005 at 12:46:55AM +, Mark Brown wrote:

> adduser maintainership would like to see this discussed on
> debian-devel. Please state your case there, and I'll decide what to do
> afterwards.

I personally don't care too much, I'm just not going to have NIS assign
different semantics to GIDs to those used by the rest of Debian.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Marc Haber]

On Wed, Dec 21, 2005 at 12:46:55AM +, Mark Brown wrote:
> On Mon, Dec 12, 2005 at 08:40:31AM +0100, Marc Haber wrote:
> > On Mon, Dec 12, 2005 at 08:08:50AM +0100, Teddy Hogeborn wrote:
> > > One additional possibility is for adduser to support an interface to
> > > add users/groups in this new range, which would involve a new
> > > configuration option and at least one new command line option.  But
> > > this is not necessarily requested or required.
> 
> > I'm actually not convinced that this would do any good. adduser
> > traditionally does not care about NIS/LDAP setup, and I think that
> > accounts and groups that will appear on multiple systems should not be
> > created by adduser.
> 
> Traditionally the default setup for NIS (in general, not just in Debian)
> has been to export any administratively created users and groups from
> the NIS master server to clients on the network.  Users can configure it
> otherwise if they like (well, at least on Linux) but that's the default.

adduser maintainership would like to see this discussed on
debian-devel. Please state your case there, and I'll decide what to do
afterwards.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Mon, Dec 12, 2005 at 08:40:31AM +0100, Marc Haber wrote:
> On Mon, Dec 12, 2005 at 08:08:50AM +0100, Teddy Hogeborn wrote:

> > One additional possibility is for adduser to support an interface to
> > add users/groups in this new range, which would involve a new
> > configuration option and at least one new command line option.  But
> > this is not necessarily requested or required.

> I'm actually not convinced that this would do any good. adduser
> traditionally does not care about NIS/LDAP setup, and I think that
> accounts and groups that will appear on multiple systems should not be
> created by adduser.

Traditionally the default setup for NIS (in general, not just in Debian)
has been to export any administratively created users and groups from
the NIS master server to clients on the network.  Users can configure it
otherwise if they like (well, at least on Linux) but that's the default.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Marc Haber <[EMAIL PROTECTED]> writes:

> > > Which change is suggested to adduser?
> > 
> > The change of LAST_SYSTEM_UID in /etc/adduser.conf from 999 to 499.
> 
> /etc/adduser.conf is a conffile. The range 100-999 is laid down in
> policy 9.2.2, so changing the default in adduser is out of the
> question.

I'm trying to affect a policy change here.  But -policy consistently
refers to package maintainers to change their packages before a policy
change can be considered.  Therefore I'm trying to get packages to
change.  It can't be *impossible* to change, one or the other has to
be changed first.  I tried (several times) to bring up the issue in
debian-policy but no one replied.  That is why I'm now bringing up the
issue with you, the package maintainers of the affected packages.  So
far I have gotten the nis package maintainer to agree to the change if
done in concert with the other affected packages.

> > If this is done, Group IDs of 500 to 999 can be used for
> > NIS-exported groups, but this is not anything which adduser has to
> > be concerned about.
> 
> Right, adduser can be locally configure to handle this.

I know.  I'm talking about what the default should be.

> > One additional possibility is for adduser to support an interface
> > to add users/groups in this new range, which would involve a new
> > configuration option and at least one new command line option.
> > But this is not necessarily requested or required.
> 
> I'm actually not convinced that this would do any good. adduser
> traditionally does not care about NIS/LDAP setup, and I think that
> accounts and groups that will appear on multiple systems should not be
> created by adduser.

Fair enough for me; it was the nis package maintainer who suggested
that the proposal might be more convincing if adduser had an interface
to add users in this range.  I'm not attached to the idea.

Just to make something clear, though: users that are added by adduser
are already exported by NIS, since NIS by default exports all users
from ID 1000 and up (all except 65534).

/Teddy

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Marc Haber]

On Mon, Dec 12, 2005 at 08:08:50AM +0100, Teddy Hogeborn wrote:
> Marc Haber <[EMAIL PROTECTED]> writes:
> > Not having a clue about NIS and never having had any sizeable amount
> > of local users, I'd like to have an "executive summary" for this bug
> > report.
> > 
> > Which change is suggested to adduser?
> 
> The change of LAST_SYSTEM_UID in /etc/adduser.conf from 999 to 499.

/etc/adduser.conf is a conffile. The range 100-999 is laid down in
policy 9.2.2, so changing the default in adduser is out of the question.

> If this is done, Group IDs of 500 to 999 can be used for NIS-exported
> groups, but this is not anything which adduser has to be concerned
> about.

Right, adduser can be locally configure to handle this.

> One additional possibility is for adduser to support an interface to
> add users/groups in this new range, which would involve a new
> configuration option and at least one new command line option.  But
> this is not necessarily requested or required.

I'm actually not convinced that this would do any good. adduser
traditionally does not care about NIS/LDAP setup, and I think that
accounts and groups that will appear on multiple systems should not be
created by adduser.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Marc Haber <[EMAIL PROTECTED]> writes:

> Not having a clue about NIS and never having had any sizeable amount
> of local users, I'd like to have an "executive summary" for this bug
> report.
> 
> Which change is suggested to adduser?

The change of LAST_SYSTEM_UID in /etc/adduser.conf from 999 to 499.

If this is done, Group IDs of 500 to 999 can be used for NIS-exported
groups, but this is not anything which adduser has to be concerned
about.

One additional possibility is for adduser to support an interface to
add users/groups in this new range, which would involve a new
configuration option and at least one new command line option.  But
this is not necessarily requested or required.

If both adduser and the nis package can make this change, the Debian
Policy can then be approached to be changed to list the new ID range.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Marc Haber]

On Mon, Dec 12, 2005 at 12:28:09AM +0100, Teddy Hogeborn wrote:
> Maintainers of adduser, please review the log of bug #329701 and
> comment.  Thank you.

Not having a clue about NIS and never having had any sizeable amount
of local users, I'd like to have an "executive summary" for this bug
report.

Which change is suggested to adduser?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Mon, Dec 12, 2005 at 12:28:58AM +0100, Marco d'Itri wrote:
> > > > What I want is for any change in the default handling of UID and GID
> > > > ranges in NIS to be made in other parts of Debian too.

> As long as you  do not expect that NIS-served system users and groups
> will work too... This is a recipe for a disaster on udev systems,
> because they will not be available before networking is up.

As far as I can tell the range Teddy wants to create is more equivalent
to the existing 1000-2 range for user accounts than the 100-999
range it's being carved out of - more of a "locally allocated non-user
groups" range.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: Local (non-NIS) users and groups

[Marco d'Itri]

> > > What I want is for any change in the default handling of UID and GID
> > > ranges in NIS to be made in other parts of Debian too.
As long as you  do not expect that NIS-served system users and groups
will work too... This is a recipe for a disaster on udev systems,
because they will not be available before networking is up.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

reassign 329701 adduser
thanks

Maintainers of adduser, please review the log of bug #329701 and
comment.  Thank you.

Mark Brown <[EMAIL PROTECTED]> writes:

> It might be helpful to have everything ready to be changed in one
> fell swoop in order to avoid skew between policy and reality and to
> ensure that everyone is up to speed prior to the change.

All right, sounds good.  After I've gotten the OK from all involved
maintainers, I'll start with that.

> > Support?  You mean something like "adduser --system-shared"?
> 
> It might help convince people to accept such a change if there were
> a user interface for using it.

Right.  If the adduser maintainers are agreeable to the idea I'll look
into it.

> > Fair enough, but what parts other than "adduser" are there?
> 
> Off the top of my head there are some other implementations of
> adduser around.

Hmm, in what packages?  The only one I can find is "adduser-ng" which
does not seem to know *anything* about any ranges, it simply calls
"useradd" and "groupadd".  Since it it already range-ignorant, it does
not need to be changed.

(Maintainers of adduser, do you know of any more?)

> > Would you be OK with making this change if the "adduser" package
> > was changed too?  (Of course, after both packages are changed, the
> > Debian
> 
> I would probably go along with the adduser maintainers on this one.

Thank you.  Allright then.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Sun, Dec 11, 2005 at 04:54:17PM +0100, Teddy Hogeborn wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:

> > You might find that coming up with a concrete proposal for policy
> > might help there.

> I have the feeling that all that would happen is that maybe someone
> would ask the maintainers for the affected packages what *they* think,
> and hold off on any policy change until the packages are changed.  But
> it would be easy to write a specific change proposal, so I'll do that
> once someone actually needs one.

It might be helpful to have everything ready to be changed in one fell
swoop in order to avoid skew between policy and reality and to ensure
that everyone is up to speed prior to the change.

> > That would probably help too.  A patch implementing support for the
> > new GID range you want to add might also be helpful.

> Support?  You mean something like "adduser --system-shared"?  That's a
> bit more than I am asking for; I just wanted to have the range
> *available* as a general policy, not necessarily have a nice UI to it.

It might help convince people to accept such a change if there were a
user interface for using it.

> > What I want is for any change in the default handling of UID and GID
> > ranges in NIS to be made in other parts of Debian too.

> Fair enough, but what parts other than "adduser" are there?  (And
> don't say "debian-policy", please.)

Off the top of my head there are some other implementations of adduser
around.

> > It is very easy for people who want this behaviour to change their
> > local configuration suitably.  Doing it in NIS alone will at best
> > provide a small part of what you are asking for

> (Actually, it would solve all my problems.  This change is the only
> one I need to apply to use this GID range the way I want.)

Well, yes.  It would take slightly more to make it a useful feature in
Debian, though.

> Would you be OK with making this change if the "adduser" package was
> changed too?  (Of course, after both packages are changed, the Debian

I would probably go along with the adduser maintainers on this one.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Mark Brown <[EMAIL PROTECTED]> writes:

> > And it's not like this would be changed on a running system,
> > right?
> 
> That is not the case.  /var/yp/Makefile is a conffile and so will be
> updated if it hasn't been modified.

Oh, I see.  Sorry.  (Hmm, the installation scripts would have to check
for preexisting GIDs in the range 500-999 then, and warn
appropriately.)

> > (From what I can see, absolutely no one on -policy cares about
> > this, since I have asked about this on two occasions now and both
> > times gotten no reply whatsoever.)
> 
> You might find that coming up with a concrete proposal for policy
> might help there.

I have the feeling that all that would happen is that maybe someone
would ask the maintainers for the affected packages what *they* think,
and hold off on any policy change until the packages are changed.  But
it would be easy to write a specific change proposal, so I'll do that
once someone actually needs one.

> > If you want to avoid even that remote possibility, this change
> > should be coordinated with a change in the "adduser" package to
> > lower LAST_SYSTEM_UID in /etc/adduser.conf.
> 
> That would probably help too.  A patch implementing support for the
> new GID range you want to add might also be helpful.

Support?  You mean something like "adduser --system-shared"?  That's a
bit more than I am asking for; I just wanted to have the range
*available* as a general policy, not necessarily have a nice UI to it.
But thank you for the suggestion.

> > Is this what you want?  Would you be willing to make the change if
> > the maintainers for "adduser" were, too?
> 
> What I want is for any change in the default handling of UID and GID
> ranges in NIS to be made in other parts of Debian too.

Fair enough, but what parts other than "adduser" are there?  (And
don't say "debian-policy", please.)

> You are asking me to have the NIS package take part of an existing
> GID range and give it a new meaning without updating anything else
> in Debian to understand this.  I don't think that's a good idea.

All right, but I think you are overestimating the impact this would
have.  No other package (except for "adduser") even cares about the ID
ranges in question, from what I can see.  But I'll jump through
whatever hoops are necessary to have this proposal actually
considered.

> It is very easy for people who want this behaviour to change their
> local configuration suitably.  Doing it in NIS alone will at best
> provide a small part of what you are asking for

(Actually, it would solve all my problems.  This change is the only
one I need to apply to use this GID range the way I want.)

I mean, I have already solved my problems by making the change locally
(on a number of systems).  But I don't like making such changes to a
system policy, and Debian doesn't provide for a way to do what I want,
so I'm therefore trying to make Debian adopt my policy.  If I succeed,
it's one thing less odd about my systems compared to a standard
install.  I'll even be just as happy if Debian decides to adopt some
other way to do the same thing, just as long as I can do what I want
on my systems with minimal change to system policy.

> and may actually cause breakage.

Extremly unlikely, in my opinion.  But I'll approach things the Right
Way, as long as someone can say what way that is.  But not as long as
everybody keeps pointing at someone else.

To summarize:

Would you be OK with making this change if the "adduser" package was
changed too?  (Of course, after both packages are changed, the Debian
Policy would be approachable for change, after which everything would
be nice again.)  Or are there more parts of Debian that, in your
opinion, need to be changed in concert?  I would need to know this if
I am to approach maintainers with this proposal.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Fri, Dec 09, 2005 at 12:57:28PM +0100, Teddy Hogeborn wrote:

> And it's not like this would be changed on a running system, right?
> It would just be the default value in /var/yp/Makefile for new package
> installations for new NIS master servers.

That is not the case.  /var/yp/Makefile is a conffile and so will be
updated if it hasn't been modified.

> And I'm not actually seeing a conflict with policy in this case, since
> policy does not mention NIS exporting at all.

Policy and all the other packages in Debian that care about these things 
say that GIDs in the range 100-999 are reserved for dynamically
allocated system users and groups.  Since exporting random automatically
created users and groups tends to cause hassle NIS does not export those
ID ranges by default.

> If you want to touch ground you (as the actual maintainer you might
> get more responses than I got) could ask debian-policy if anyone would
> OBJECT to the change.  (From what I can see, absolutely no one on
> -policy cares about this, since I have asked about this on two
> occasions now and both times gotten no reply whatsoever.)

You might find that coming up with a concrete proposal for policy might
help there.

> The only thing I can foresee delaying this change is if you really
> want to be CERTAIN that no one does "adduser --system --group" 400
> times and suddenly gets into the exported GID range (not that I see
> anyone actually doing that, but...).  If you want to avoid even that
> remote possibility, this change should be coordinated with a change in
> the "adduser" package to lower LAST_SYSTEM_UID in /etc/adduser.conf.

That would probably help too.  A patch implementing support for the new
GID range you want to add might also be helpful.

> Is this what you want?  Would you be willing to make the change if the
> maintainers for "adduser" were, too?

What I want is for any change in the default handling of UID and GID
ranges in NIS to be made in other parts of Debian too.  I am not going
to unilaterally make this change in the NIS package.  You are asking me
to have the NIS package take part of an existing GID range and give it a
new meaning without updating anything else in Debian to understand this.
I don't think that's a good idea.

It is very easy for people who want this behaviour to change their local
configuration suitably.  Doing it in NIS alone will at best provide a
small part of what you are asking for and may actually cause breakage.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Mark Brown <[EMAIL PROTECTED]> writes:

I submit that this is not a problem in practice since I'd bet no one
using NIS has created more than 400 local groups that must not be
exported.

And it's not like this would be changed on a running system, right?
It would just be the default value in /var/yp/Makefile for new package
installations for new NIS master servers.

> > Noone needs to wait for debian-policy before changing their
> > packages.  The way to change the Debian policy is to change the
> > workings of the relevant packages (in this case just "nis") and
> > then report this fact to debian-policy as an agreed-upon policy by
> > the maintainers in question.
> 
> Unfortunately, this affects any package which creates a group since
> that's the range those groups come from.  If things were changed such
> that the 100-999 range were split into a 100-499 local range and a
> 500-999 exported range

You mean changed in the Debian Policy, I take it.

> that would be addressed and I'd have no problem with making the
> change you request.

That's not how changes happen in Debian Policy, as I understand it.
Instead, package maintainers change their packages' behavior and then
present their working changes to debian-policy as a fait accompli.
Policy reflect package behavior, not the reverse.  So the policy
change you are asking for can only come after you change the package.

And I'm not actually seeing a conflict with policy in this case, since
policy does not mention NIS exporting at all.

If you want to touch ground you (as the actual maintainer you might
get more responses than I got) could ask debian-policy if anyone would
OBJECT to the change.  (From what I can see, absolutely no one on
-policy cares about this, since I have asked about this on two
occasions now and both times gotten no reply whatsoever.)

The only thing I can foresee delaying this change is if you really
want to be CERTAIN that no one does "adduser --system --group" 400
times and suddenly gets into the exported GID range (not that I see
anyone actually doing that, but...).  If you want to avoid even that
remote possibility, this change should be coordinated with a change in
the "adduser" package to lower LAST_SYSTEM_UID in /etc/adduser.conf.
Is this what you want?  Would you be willing to make the change if the
maintainers for "adduser" were, too?

(Note that "adduser --system" by itself does not add more group IDs;
it places system users in the "nogroup" group by default.  The
additional "--group" option is needed to consume group IDs, and this
would have to be done more than 400 times to actually overflow.)

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

On Fri, Dec 09, 2005 at 05:32:14AM +0100, Teddy Hogeborn wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:

> > This looks like a question for policy rather than the NIS package
> > since coordination with things like adduser seems at least desirable
> > so I'm reassigning the bug there.

> Actually, no.  For this proposal, no cooperation with adduser is
> needed; adduser will work the same as always using the same number
> ranges.

Right.  That is precisely the reason want need to cooperate with adduser.

> > My instinct is that this is probably something that is best handled
> > by the local administrator since having it work effectively requires
> > more coordination between machines than is likely to be achived
> > automatically but I've not considerd the issues too deeply.

> Yes, of course, but a lot of configuration is needed to get NIS up and
> running anyway.  What I am asking for is for the *default* in the NIS
> package to not be changed when this change makes it more difficult to
> allow NIS-exported groups.

Obviously, you can create NIS exported groups, it's just that you can't
do it in exactly the way you want to.

> I don't think it's that strange since I am
> just asking for Debian not to change the default upstream value.  The
> current nis package's change of the MINGID value to 1000 serves no
> purpose that I can see.

The purpose it serves it to address bugs like 58881, avoiding collisions
between groups created locally by adduser on a system and groups
exported via NIS.

> Noone needs to wait for debian-policy before changing their packages.
> The way to change the Debian policy is to change the workings of the
> relevant packages (in this case just "nis") and then report this fact
> to debian-policy as an agreed-upon policy by the maintainers in
> question.

Unfortunately, this affects any package which creates a group since
that's the range those groups come from.  If things were changed such
that the 100-999 range were split into a 100-499 local range and a
500-999 exported range that would be addressed and I'd have no problem
with making the change you request.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

package debian-policy
reassign 329701 nis
thanks

(No reply from anybody on -policy for a few months now, so I follow up
myself.)

Mark Brown <[EMAIL PROTECTED]> writes:

> This looks like a question for policy rather than the NIS package
> since coordination with things like adduser seems at least desirable
> so I'm reassigning the bug there.

Actually, no.  For this proposal, no cooperation with adduser is
needed; adduser will work the same as always using the same number
ranges.

> My instinct is that this is probably something that is best handled
> by the local administrator since having it work effectively requires
> more coordination between machines than is likely to be achived
> automatically but I've not considerd the issues too deeply.

Yes, of course, but a lot of configuration is needed to get NIS up and
running anyway.  What I am asking for is for the *default* in the NIS
package to not be changed when this change makes it more difficult to
allow NIS-exported groups.  I don't think it's that strange since I am
just asking for Debian not to change the default upstream value.  The
current nis package's change of the MINGID value to 1000 serves no
purpose that I can see.

Noone needs to wait for debian-policy before changing their packages.
The way to change the Debian policy is to change the workings of the
relevant packages (in this case just "nis") and then report this fact
to debian-policy as an agreed-upon policy by the maintainers in
question.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Mark Brown]

package nis
reassign 329701 debian-policy
thanks

On Thu, Sep 22, 2005 at 11:25:38PM +0200, Teddy Hogeborn wrote:

> (I tried to raise this question for general discussion some time ago
> but no one replied.  See
> .
> Therefore I now submit a more specific proposal as a wishlist bug in
> the hope of some feedback.)

> In regards to NIS (and LDAP), there is no standard place for
> domain-exported groups which are not user-private groups.  I propose
> that the "system" GID space be split in half and all GIDs at 500 and
> above be considered domain-exported and those below to be
> machine-local.

> The only change necessary in the nis package is to *not* change MINGID
> in "nis-3.13/ypserv-2.14/scripts/ypMakefile.in".  The original value
> is already 500; just leave it.

> (I guess this ought to be written into the policy manual at some
> point, but you have to start somewhere, and it's easier to change a
> package than the Debian Policy.)

This looks like a question for policy rather than the NIS package since
coordination with things like adduser seems at least desirable so I'm
reassigning the bug there.  

My instinct is that this is probably something that is best handled by
the local administrator since having it work effectively requires more
coordination between machines than is likely to be achived automatically
but I've not considerd the issues too deeply.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Package: nis
Version: 3.13-2
Severity: wishlist

(I tried to raise this question for general discussion some time ago
but no one replied.  See
.
Therefore I now submit a more specific proposal as a wishlist bug in
the hope of some feedback.)

In regards to NIS (and LDAP), there is no standard place for
domain-exported groups which are not user-private groups.  I propose
that the "system" GID space be split in half and all GIDs at 500 and
above be considered domain-exported and those below to be
machine-local.

The only change necessary in the nis package is to *not* change MINGID
in "nis-3.13/ypserv-2.14/scripts/ypMakefile.in".  The original value
is already 500; just leave it.

(I guess this ought to be written into the policy manual at some
point, but you have to start somewhere, and it's easier to change a
package than the Debian Policy.)

/Teddy