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

2006-02-12 Thread 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

2005-12-21 Thread 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

2005-12-21 Thread 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

2005-12-20 Thread 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

2005-12-12 Thread 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

2005-12-11 Thread 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]