Mailing List Archive

hmm...well, i just tried various setups where the group name had to add
folks based on their primary group (/etc/passwd) and/or the secondary
groups (/etc/group). this was with 8.1.10 as well as 8.1.11.

a couple things. first, did you build the new version using the same
flags as the old? (in case there's *something* that might have changed)
is there any other type of change the might have occurred?

if that doesn't shed any light, we'll have to get a lot of details on
how it's failing. there isn't really any debug statements in that chunk
of code, unfortunately. tracing the code (strace/truss/whatever) might
be necessary, to make sure it's calling getgrnam(), etc.

bottom line...this *should* be working. i suppose the other possibility
is that the config file is begin parsed differently. a 'conserver -S
-D' (and any other appropriate args) would be useful for that (to see
how the access lists were built).

Bryan

On Thu, May 26, 2005 at 01:56:06PM -0700, Phil Dibowitz wrote:
> Back on 8.1.6, you wrote me a patch to get conserver to look at _all_ groups
> of a user, not just primary groups.
>
> I'm now on 8.1.10 and that doesn't seem to work anymore....
>
> any idea why?
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Thu, May 26, 2005 at 02:54:44PM -0700, Bryan Stansell wrote:
> hmm...well, i just tried various setups where the group name had to add
> folks based on their primary group (/etc/passwd) and/or the secondary
> groups (/etc/group). this was with 8.1.10 as well as 8.1.11.

Unfortunately, the old version isn't working either, and I *know* it used to
work...

So I'm looking at system stuff now.

"id -a user" shows the right group.... not sure what's going on.

I'm continuing to look...

--
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427

On Thu, May 26, 2005 at 02:54:44PM -0700, Bryan Stansell wrote:
> hmm...well, i just tried various setups where the group name had to add
> folks based on their primary group (/etc/passwd) and/or the secondary
> groups (/etc/group). this was with 8.1.10 as well as 8.1.11.
>
> a couple things. first, did you build the new version using the same
> flags as the old? (in case there's *something* that might have changed)
> is there any other type of change the might have occurred?
>
> if that doesn't shed any light, we'll have to get a lot of details on
> how it's failing. there isn't really any debug statements in that chunk
> of code, unfortunately. tracing the code (strace/truss/whatever) might
> be necessary, to make sure it's calling getgrnam(), etc.

FYI, I truss'd it:

[root@scc2 conserver]# grep getgrnam /tmp/concserver.out
[root@scc2 conserver]#

Bryan - should I send you the truss output?

--
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427

Phil, you're on Solaris right? Here's a shot in the dark -- have you bounced the 'nscd' daemon? It's the first place that I start when any name-service looks to be playing up... Also, isn't 'getgrnam' a C library call? It won't show in a truss output...

Will.

William Charles ______________________________________________________________
Global UNIX Engineering, Asia/Pacific [/] Deutsche Bank Sydney +61 2 9258 1916




phil@usc.edu
Sent by: users-bounces@conserver.com
To
bryan@conserver.com
27/05/2005 08:21 AM cc
users@conserver.com
Subject
Re: Group problems ... again?










On Thu, May 26, 2005 at 02:54:44PM -0700, Bryan Stansell wrote:
> hmm...well, i just tried various setups where the group name had to add
> folks based on their primary group (/etc/passwd) and/or the secondary
> groups (/etc/group). this was with 8.1.10 as well as 8.1.11.
>
> a couple things. first, did you build the new version using the same
> flags as the old? (in case there's *something* that might have changed)
> is there any other type of change the might have occurred?
>
> if that doesn't shed any light, we'll have to get a lot of details on
> how it's failing. there isn't really any debug statements in that chunk
> of code, unfortunately. tracing the code (strace/truss/whatever) might
> be necessary, to make sure it's calling getgrnam(), etc.

FYI, I truss'd it:

[root@scc2 conserver]# grep getgrnam /tmp/concserver.out
[root@scc2 conserver]#

Bryan - should I send you the truss output?

--
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427

[attachment "att4tuvn.dat" deleted by William Charles/Sydney/DBAustralia/DeuBa] _______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users





--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Fri, May 27, 2005 at 08:35:39AM +1000, William Charles wrote:
>
> Phil, you're on Solaris right? Here's a shot in the dark -- have you bounced the 'nscd' daemon? It's the first place that I start when any name-service looks to be playing up... Also, isn't 'getgrnam' a C library call? It won't show in a truss output...

I am, and I stopped nscd as soon as I started having issues....

and yes, getgrnam is in fact a C call... doh!

--
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427

Gah!

I think I got it.

Someone added a local entry for that group in /etc/group overriding the NIS
group!!!

Once I saw that the old .6 worked, I figured it couldn't be a conserver issue.

--
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427