I just upgraded our system here to 3.0.0 from RC4 last night. As usual I
built an RPM from the source RPM after adding --with-acl-support to the
specfile. I found that unlike previous RCs, RPM would not upgrade to
3.0.0 using -Fvh. In the end I removed RC4 and then installed 3.0.0 in
the normal way (backing up and restoring /etc/samba and
/var/cache/samba).
However, the real issue is that we're still having problems with
winbind. It appears that sometimes for whatever reason winbind can't
contact the domain controller, and then without trying to contact one of
the other DCs stops being able to look up domain groups/users. Here is
an excerpt from log.winbindd:
------- snip --------
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_connect(218)
Connected to LDAP server 192.168.55.6
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_server_info(1886)
got ldap server name fozzy@CJNTECH, using bind path: dc=CJNTECH
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 48018 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2 3
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 3 6 1 4 1 311 2 2 10
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(191)
got principal=fozzy$@CJNTECH
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_do_paged_search(451)
ldap_search_ext_s((objectCategory=group)) -> Can't contact LDAP server
[2003/10/02 04:49:00, 3] libads/ldap_utils.c:ads_do_search_retry(60)
Reopening ads connection to realm 'CJNTECH' after error Can't
contact
LDAP server
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_connect(218)
Connected to LDAP server 192.168.55.6
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_server_info(1886)
got ldap server name fozzy@CJNTECH, using bind path: dc=CJNTECH
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 48018 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2 3
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 3 6 1 4 1 311 2 2 10
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(191)
got principal=fozzy$@CJNTECH
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_do_paged_search(451)
ldap_search_ext_s((objectCategory=group)) -> Can't contact LDAP server
[2003/10/02 04:49:00, 3] libads/ldap_utils.c:ads_do_search_retry(60)
Reopening ads connection to realm 'CJNTECH' after error Can't
contact
LDAP server
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_connect(218)
Connected to LDAP server 192.168.55.6
[2003/10/02 04:49:00, 3] libads/ldap.c:ads_server_info(1886)
got ldap server name fozzy@CJNTECH, using bind path: dc=CJNTECH
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 48018 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 2 840 113554 1 2 2 3
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(184)
got OID=1 3 6 1 4 1 311 2 2 10
[2003/10/02 04:49:00, 3] libads/sasl.c:ads_sasl_spnego_bind(191)
got principal=fozzy$@CJNTECH
[2003/10/02 04:49:00, 1] nsswitch/winbindd_ads.c:enum_dom_groups(218)
enum_dom_groups ads_search: Success
[2003/10/02 04:49:00, 3]
nsswitch/winbindd_group.c:get_sam_group_entries(526)
get_sam_group_entries: could not enumerate domain groups! Error:
NT_STATUS_UNSUCCESSFUL
------- snip --------
In the smb.conf, "password server" is set to *, so I would have
expected winbind upon failing the connection to one DC to switch to
one of the other DCs in our domain (of which there are 3). On the
other hand, maybe it is getting half-way through the connection and
then being cut off, in which case it just tries the same one again.
The odd thing is this mostly seems to be happening at strange hours
when nobody would be using the Samba server, though there probably
would have been some users logged in via Citrix to the DC which is
being contacted above.
BTW, I haven't yet seen any more outright crashes of winbind as
described in my "winbind RC4 crash" post, but I am still monitoring.
Winbind has basically been flaky ever since we started using the 3.0
betas, and we really need to sort out why. We are also having
problems with roaming profiles randomly failing to copy and folder
redirection failing since we went to RC2, although I haven't been able
to find any supporting log entries - Windows is claiming "the security
ID cannot be assigned as the owner of this object" or "access
denied".
Cheers,
Paul