Well, I believe I've solved about 95% of this problem. The main problem was that the LDAP binding wasn't working, even tho I used the same high-level account for both connections. Once I created a secondary account, and used it for the lookup binds, everything started working properly. mostly.
Now there appears to be an issue with the searches not always making it back in time, or something. I see the LDAP logs returning the search results, but the admin screens are showing no group entries. I tried running nscd, but even with that I'm still getting intermittent missing groups. The only thing I can question is if the ldap queries are done in a synchronous manner, or in a callback form. These random missed queries bother me, but all appears to be working -- I can just reload the screen a few times until the groups appear. I'm worried, still, that this might impact issues outside of the Web UI. On Nov 23, 2007 8:08 PM, Adam Levine <[EMAIL PROTECTED]> wrote: > environment: > OF: version: 2.2, x86, having run 'conary updateall' (which caused > other problems, not related) > Sun Directory Server 6.x, with samba schema installed, running on > another system > > > Issue Summary: > > I have defined groups via Accounts / Account Administration / Group > Administration, and they appear in my LDAP. They also appear in > listing from the system command, "getent group". > > However: > > The list of groups is empty on the following pages: > - https://nas:446/admin/account_groups.html (Accounts / List of > Groups) > - https://nas:446/admin/shares_edit.html (Shares / Edit shares > / Group access configuration) > > Problem determination: > > The list of groups being returned from php getgrent() does not > match what is returned by the system command, "getent group". I have > verified this by adding debug information at line 44 of > /opt/openfiler/var/www/htdocs/admin/account_groups.html: > print("<!-- group info: " . $group_info["gr_gid"] . " : " . > $group_info["gr_name"] . " -->"); > > List of places where getgrent() appears: > > ../account/index.html: while ($group_info = getgrent()) > ../admin/account_groups.html: while ($group_info = getgrent()) > ../admin/quota.html: while ($group_info = getgrent()) > ../admin/shares_edit.html: while ($group_info = getgrent()) > ../admin/account_groups.html.1: while ($group_info = getgrent()) > ../admin/bak.account_groups.html: while ($group_info = getgrent()) > ../admin/account_users.html: while ($group_info = getgrent()) > > Workaround: > > If I add the group to /etc/group, and match the gid with the LDAP > entries, these groups do appear in the lists, and are properly marked > as being LDAP groups. > > So.... > > 1) Is the Group Administration function supposed to create > corresponding group entries in /etc/group, or only in the LDAP system? > 2) Is there a replacement function for php getgrent() that should > be used instead? > 3) Is this underlying mis-match of group information going to > manifest in other places outside of the Web UI, such as under the > covers with SMB shares? > 4) Should I open a bug for this? > > > Thanks for any help! > _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users
