Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
On Mon, May 16, 2005 at 06:29:50PM +0200, Christian Perrier wrote: > I must confess that I have absolutely no idea of what the bug > submitter is requesting in http://bugs.debian.org/134473 > > Has anyone a rough idea? A new option to the low level tools allowing to specify on which files to work on. Rational: on nis server, you don't want to allow the user of your company to log onto your nis server, you want them to be added in the DB managed by the nis server. You don't want to modify /etc/passwd but /var/yp/ypfiles/etc/passwd. At least, that's what I understand from this mail, I've no personal opinion, beside the relative simplicity of the corresponding patch. I'm CCing debian NIS packager (hello Miquel) to see what he think about it. [For the context, shadow packaging just changed into a team effort, and we're doing massive bug triage] Bye, Mt. signature.asc Description: Digital signature
Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
On Mon, 16 May 2005 23:35:40, Martin Quinson wrote: > On Mon, May 16, 2005 at 06:29:50PM +0200, Christian Perrier wrote: > > I must confess that I have absolutely no idea of what the bug > > submitter is requesting in http://bugs.debian.org/134473 > > > > Has anyone a rough idea? > > A new option to the low level tools allowing to specify on which files to > work on. > > Rational: on nis server, you don't want to allow the user of your company to > log onto your nis server, you want them to be added in the DB managed by the > nis server. You don't want to modify /etc/passwd but > /var/yp/ypfiles/etc/passwd. > > At least, that's what I understand from this mail, I've no personal opinion, > beside the relative simplicity of the corresponding patch. > > I'm CCing debian NIS packager (hello Miquel) to see what he think about it. > [For the context, shadow packaging just changed into a team effort, and > we're doing massive bug triage] Well actually nowadays Mark Brown does most (the last few releases, all) of the work on NIS. But it's probably not a bad idea to make the tools more flexible. It sure beats vi :) Mike.
Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
(enlarging the discussion again..:-)). See http://bugs.debian.org/134473 > > I'm CCing debian NIS packager (hello Miquel) to see what he think about it. > > [For the context, shadow packaging just changed into a team effort, and > > we're doing massive bug triage] > > Well actually nowadays Mark Brown does most (the last few releases, > all) of the work on NIS. > > But it's probably not a bad idea to make the tools more flexible. > It sure beats vi :) Well, I will need to be convinced..:-) Up to now, we are still looking at useradd/userdel as "low-level" tools and thus the "high-level" functionality is better be integrated into adduser/deluser. We also have, for instance, a request to make useradd add users in LDAP backends and we could even end up in requests to be able to add users in "winbind" backends one can have with the samba package (users authenticated against a NT domain). I'm very reluctant to push such feature requests to upstream shadow and ask it with all possible name services systems. I think that adding a kind of plugin mechanism to Debian specific adduser utilities would be more logical, if that's feasible. Marc and adduser maintainers, opinions, thoughts ?
Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
On Tue, May 17, 2005 at 07:28:25AM +0200, Christian Perrier wrote: > (enlarging the discussion again..:-)). See http://bugs.debian.org/134473 > > > > I'm CCing debian NIS packager (hello Miquel) to see what he think about > > > it. > > > [For the context, shadow packaging just changed into a team effort, and > > > we're doing massive bug triage] > > > > Well actually nowadays Mark Brown does most (the last few releases, > > all) of the work on NIS. > > > > But it's probably not a bad idea to make the tools more flexible. > > It sure beats vi :) > > > Well, I will need to be convinced..:-) > > Up to now, we are still looking at useradd/userdel as "low-level" > tools and thus the "high-level" functionality is better be integrated > into adduser/deluser. > > We also have, for instance, a request to make useradd add users in > LDAP backends and we could even end up in requests to be able to add > users in "winbind" backends one can have with the samba package (users > authenticated against a NT domain). > > I'm very reluctant to push such feature requests to upstream shadow > and ask it with all possible name services systems. Well, we're not exactly speaking of adding a whole new mecanism, I think, but of allowing the tools to do exactly the same work on other files. For sake of helping nis users. It's a valuable goal which is easy to achieve. I vote +1 for it. If Mark and Miquel confirm that this would indeed help nis user (and thus confirm that this is probably the submitter request), I'll prepare a patch. Once the technical issue will be solved, the complexity of the solution may help in the political discussion about whether we want it ;) Tomasz, what's you opinion on this one? Bye, Mt. signature.asc Description: Digital signature
Bug#134473: [Adduser-devel] Re: Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
On Tue, May 17, 2005 at 07:28:25AM +0200, Christian Perrier wrote: > I think that adding a kind of plugin mechanism to Debian specific > adduser utilities would be more logical, if that's feasible. As far as I remember, this is on the features list for the next generation adduser. Unfortunately, there is not work being done on next generation adduser at the moment, and features like this will surely not be in current adduser under its current maintainership. No time. 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#134473: [Adduser-devel] Re: Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
Quoting Marc Haber ([EMAIL PROTECTED]): > On Tue, May 17, 2005 at 07:28:25AM +0200, Christian Perrier wrote: > > I think that adding a kind of plugin mechanism to Debian specific > > adduser utilities would be more logical, if that's feasible. > > As far as I remember, this is on the features list for the next > generation adduser. Unfortunately, there is not work being done on > next generation adduser at the moment, and features like this will > surely not be in current adduser under its current maintainership. No > time. OK, thanks for the very quick (as usual) reply, Marc. I'm not fond of reassigning "my/our" bugs to others but in that case, this bug would become a request to add a plugin for NIS to adduser...as soon as the plugin or similar mechanism is implemented in adduser..:-) Would you bother me to reassign this to adduser or do you have already requests for NIS account management for it ? About adduser maintainership, what is your current setup? Do you have a team setup or is the package basically maintained by just you? The shadow revival we recently made has given me some ideas about team package maintenance I'd like to share (in fact, this is a bit too late but I intended to talk about this at debconfstill maybe for an informal BOF if I have enough courage...)
Bug#134473: [Adduser-devel] Re: Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
Hi, On Tue, May 17, 2005 at 08:36:46AM +0200, Christian Perrier wrote: > I'm not fond of reassigning "my/our" bugs to others but in that case, this > bug would become a request to add a plugin for NIS to adduser...as > soon as the plugin or similar mechanism is implemented in adduser..:-) I think that the new adduser will probably be an entirely new package. > Would you bother me to reassign this to adduser or do you have > already requests for NIS account management for it ? Feel free to reassign, but that bug will quickly catch a "severity wishlist, tags wontfix help". > About adduser maintainership, what is your current setup? Do you have > a team setup or is the package basically maintained by just you? Adduser used to be maintained by Roland Bauerschmidt, and he accepted me as a co-maintainer in 2004. He is quite busy with openldap, I am quite busy with exim4, and thus only urgent bugs or easily fixable items get addressed. I understand that Roland has some ideas about the next generation adduser, but I surely don't plan on putting any time into that. From the degree of Roland's participation in adduser in the last months, I guess that he is swamped with work as well. So it looks like next generation adduser will be a completely different package written by somebody else, and that a plugin architecture in the current adduser won't happen any time soon. Actually, I got involved with adduser maintainership when I needed some minor changes to make package account creation easier. These issues are addressed, which kind of concludes my interest in adduser. I'll try to keep the package free of RC bugs, and fix trivial requests, but investing any time into big architectural changes are a non-option for me. 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]
