Re: [OpenAFS] Re: coreutils-6.11 released
If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 further $ id -Gn users id: cannot find name for group ID 1091323188 1091323188 Because of this I get many scripts that scan /etc/group and /etc/passwd in a loop and when I ask why they don't use 'grous' or 'id' I get Ahh this has been broken for a long time or Somehow my computer is broken. Is there a way of maybe instead of giving an error message to give back a pag name. My intent was not to hide the number it was to hide the error because people think their systems are broken even if there are not. I can see the conflict here between users and sysadmins. Does someone know if there is a way to find out if the group is a pag group or not. Then I could write a version that still shows the group number but suppresses the error. Would that be OK? Cheers Didi --- www.cern.ch/ribalba / www.ribalba.de Email / Jabber: [EMAIL PROTECTED] Phone (Work) : +41 22 7679376 Skype : ribalba Address : CERN / IT-FIO-FS / GENEVE 23/ SCHWEIZ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
Didi [EMAIL PROTECTED] wrote: If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 further $ id -Gn users id: cannot find name for group ID 1091323188 1091323188 If someone can provide code to determine efficiently whether a nameless GID is a PAG then we can probably make everyone happy. If that happens, I'll need to know if there's a standard or accepted mapping from GID to PAG group name. Pointers to unencumbered code would be welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Apr 21, 2008, at 4:23 , Didi wrote: If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 I touched on a solution to that in the part of my message that you elided. I admit I was rather confused by what exactly was being cited as the problem, but this is on I do know about. (I'd actually love to see some kind of plugin setup so an AFS PAG shower could be added, but at the same time that seems just a little bit silly/ overblown for simple stuff like id and groups.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Sun, 20 Apr 2008 11:37:44 -0700 Russ Allbery [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: You can tell I don't use AFS and didn't do my homework. I wish you'd noticed and spoken up a month or so ago. Unfortunately, I only follow the announcement list. :/ Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? Usually to tell whether two shells are in different PAGs, which is useful when hunting down problems with AFS PAM modules and the like. Also to tell whether a process is in a PAG at all, although with current Linux kernels the keyring is the canonical place where that's stored. Sure. There are PAG prettifiers like libnss-afs that make it look a bit different, like 1103204785(AfsPag-c191b1) but still that's just a variation of the basic theme and having it show up in any form is indispensable. Regards, -doc ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Apr 20, 2008, at 14:37 , Russ Allbery wrote: Jim Meyering [EMAIL PROTECTED] writes: Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? Usually to tell whether two shells are in different PAGs, which is useful when hunting down problems with AFS PAM modules and the like. Also to tell whether a process is in a PAG at all, although with current Linux kernels the keyring is the canonical place where that's stored. Putting on my sysadmin hat, I am somewhat baffled by this discussion. Completely hiding unknown groups? I would print numerically and return a nonzero exit status (the latter possibly overrideable for OpenAFS use where they are expected); hiding them completely isn't just a way to annoy OpenAFS users, it also hides a clue to a system configuration problem (namely, missing groups in the group database). If someone actually needs the hiding behavior, make it an option (possibly invokable via an environment variable). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
