Perhaps I am missing something here, but I thought the whole reason for using a central ldap authentication approach is that all groups and users are defined in the ldap server and every local machine uses that server for authentication and association of rights to local resources (files and such) for all accounts, except for local system accounts and root? The global groups being added to local groups is something that I am familiar with from Microsoft's view of how to assign rights to files, and local resources, but I have never seen it used that way in *nix. As an aside, isn't the purpose of newgrp so you can switch what group your associated with on a local system? Dave Hopkins <div>On 10/24/07, Craig White <<a href="mailto:craig@tobyhouse.com">craig@tobyhouse.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Wed, 2007-10-24 at 19:34 -0400, Rob Owens wrote: > On Wed, Oct 24, 2007 at 06:29:27PM -0400, Rob Owens wrote: > > On Wed, Oct 24, 2007 at 03:13:33PM -0500, Jim Kronebusch wrote: > > > > > From a console on the server as root: > > > > > > > > > > vigr (this is a vi-based group file editor - it locks the file to > > > > > prevent other writes) > > > > > > > > > > now append fusers to the fuse group entry. If it is after another entry > > > > > for the fuse group, use a comma between the entries. > > > > > > > > I tried adding an ldap group to a local group and it did not work properly (it > > > > was as if members of the ldap group were not members of the local group). > > > > Then I tried adding a local group to another local group and that also did not > > > > work (similar results as above). Is there something special I need to do in > > > > order to allow a group to be a member of another group and have the "child > > > > group" inherit the permissions of the "parent group"? > > > > > > > > -Rob > > > > > > I had tried the same thing before and could not get this too work. As you said it acted > > > as if the users were not part of the group. I was only able to get local groups working > > > if I mirrored them in the LDAP server as shown in Step 4 of > > > <a href="http://www.1-cs.com/ubuntu_ldap_howto.txt"> www.1-cs.com/ubuntu_ldap_howto.txt</a>. I then set up Webmin to add all new users to these > > > groups. This is working very well for me. > > > > Yes, I read that document (thanks, by the way). My only concern is that if I make the GID for the ldap group the same as the GID for the local group, that's only good for one operating system. The GID-to-groupname for Debian, Ubuntu, and CentOS are not always the same. > > > > Are there any workarounds for this problem? > > I just checked two of my Debian Etch machines for GID-to-groupname info. They are the same up until GID 100 or so, then they start to differ. It seems the GIDs are simply in the order that the groups were created. So very basic system groups probably always have the same GID. But groups for optional packages will tend to differ. For instance, GID 107 on one of my Etch machines is lpadmin, and on the other it's gdm. GID 105 on one Etch machine is mysql, and on the other it's avahi. > > So what if, for instance, I want an ldap user to be a member of the mysql group on two different machines, and that group is a different GID on each machine? Does this mean I should create a mysql ldap group and remove the local mysql groups? (And that would mean chgrp'ing all the files that had local mysql group associated with them). ---- makes perfectly good sense Craig _______________________________________________ K12OSN mailing list <a href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/k12osn"> https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <<a href="http://www.k12os.org">http://www.k12os.org</a>> </blockquote></div>