Weblog entry #7 for e5z8652
See all weblog entries made by e5z8652.
#7
Samba 3.2.x frustrations
Posted by e5z8652 on Tue 26 Aug 2008 at 19:03
I am having a difficult time fielding Samba 3.2.x in a Windows 2003 domain. This has me worried, as I would like to move my production Etch boxes to Lenny when it goes stable. (I work in a Microsoft shop, so everything that does not come from Redmond has to be flawless, work on five year old equipment, and invisible to certain individuals.)
<cut>
Essentially, Winbind crashes every five minutes or so with 3.2.0 and 3.2.1. This is an annoyance as it fills up my admin mailbox with the samba panic action results but otherwise everything works just fine. See bug 493752.
With the update to 3.2.1, the /etc/init.d script no longer handles winbind gracefully. It looks to me like it does not cleanly shut down winbind, and so a restart leaves winbind in the process table but not responding. Swat sees winbind as not running (I'm guessing that Swat does a wbinfo -p or something to determine winbind's state). Restarting winbind from Swat does work, as does killall -9 winbindd ; /etc/init.d/winbind start. However once winbind is started, the initial user authentication takes anywhere from 4.5 to 5.5 minutes to complete. After that initial authentication everything is just fine, right up until the init.d script is run. Now here's the wierd thing -- I am still getting the panic action notices, so the panic action script that restarts winbind works. Additionally, I do not notice a slowdown after the panic action script restarts winbind.
The winbind authentication delay affects logins or other non-samba user auth on my workstation (also a Lenny testbed for me). I think that is because /etc/nsswitch has "files winbind" for both passwd and group. On another box I built yesterday specifically to test this I did not edit /etc/nsswitch and the delay does not affect logins.
See bug 496569. (I really need to add the note about the panic action script to that bug.)
Anyway. My smb.conf is posted in both bugs. Maybe there's another pair of eyes with more samba experience that can see where I'm causing a deadlock? Our domain setup is not that exotic. We have one domain in one tree, with a trust relationship with two other single domain trees solely for the purpose of free/busy synchronization.
Etch 3.0.24 works flawlessly, and Lenny 3.0.30 worked flawlessly as well.
<cut>
Essentially, Winbind crashes every five minutes or so with 3.2.0 and 3.2.1. This is an annoyance as it fills up my admin mailbox with the samba panic action results but otherwise everything works just fine. See bug 493752.
With the update to 3.2.1, the /etc/init.d script no longer handles winbind gracefully. It looks to me like it does not cleanly shut down winbind, and so a restart leaves winbind in the process table but not responding. Swat sees winbind as not running (I'm guessing that Swat does a wbinfo -p or something to determine winbind's state). Restarting winbind from Swat does work, as does killall -9 winbindd ; /etc/init.d/winbind start. However once winbind is started, the initial user authentication takes anywhere from 4.5 to 5.5 minutes to complete. After that initial authentication everything is just fine, right up until the init.d script is run. Now here's the wierd thing -- I am still getting the panic action notices, so the panic action script that restarts winbind works. Additionally, I do not notice a slowdown after the panic action script restarts winbind.
The winbind authentication delay affects logins or other non-samba user auth on my workstation (also a Lenny testbed for me). I think that is because /etc/nsswitch has "files winbind" for both passwd and group. On another box I built yesterday specifically to test this I did not edit /etc/nsswitch and the delay does not affect logins.
See bug 496569. (I really need to add the note about the panic action script to that bug.)
Anyway. My smb.conf is posted in both bugs. Maybe there's another pair of eyes with more samba experience that can see where I'm causing a deadlock? Our domain setup is not that exotic. We have one domain in one tree, with a trust relationship with two other single domain trees solely for the purpose of free/busy synchronization.
Etch 3.0.24 works flawlessly, and Lenny 3.0.30 worked flawlessly as well.
Comments on this Entry
We got ahold of one of the other domain admins and compared notes about our configs.
You can recreate the problem by creating two domains:
Domain A, Forest B
Domain C, Forest D
For domain A, create an inbound non-transitive trust such that users in Domain A are trusted in Domain C, but users from Domain C are not trusted in Domain A.
For Domain C, create a similar trust so that users in Domain C are trusted in Domain A, but users from Domain A are not trusted in Domain C.
Now nobody trusts anyone but both domains think the other guy trusts them.
(Yes, this was an actual situation, no I have no idea why it was set up that way. It predates current admins.)
Winbind 3.0.30 handles this just fine.
Winbind 3.2.x breaks.
If for some reason you need this sort of trust setup, you can tell winbind 3.2.x to use rpc only.
If you nuke the broken trust relationship, winbind works as advertised.
James
You can recreate the problem by creating two domains:
Domain A, Forest B
Domain C, Forest D
For domain A, create an inbound non-transitive trust such that users in Domain A are trusted in Domain C, but users from Domain C are not trusted in Domain A.
For Domain C, create a similar trust so that users in Domain C are trusted in Domain A, but users from Domain A are not trusted in Domain C.
Now nobody trusts anyone but both domains think the other guy trusts them.
(Yes, this was an actual situation, no I have no idea why it was set up that way. It predates current admins.)
Winbind 3.0.30 handles this just fine.
Winbind 3.2.x breaks.
If for some reason you need this sort of trust setup, you can tell winbind 3.2.x to use rpc only.
If you nuke the broken trust relationship, winbind works as advertised.
James
[ Parent | Reply to this comment ]