version bump requested for samba-3.0.21
Hi, this is quite important. The new release contains some nice new features and a long-needed fix to enable Windows CE based devices to access the Samba Server. Previously this failed with various effects until you used use spngo = no in smb.conf (thus disabling access from windows xp)
I'll be travelling untile the end of January. Maybe I'll be able to commit this before, but I don't assure you this. For the brave souls who would try this enterprise, the only needed operation is the change of the patchset. So: -- remove the python patch (the first, maybe?): accepted upstream and now included -- update the makefile patches (for suid LDFLAGS and gentoo-alt and bsd support) Maybe something more, but nothing difficult.
Looks like a 3.0.21a is right around the bend due to an oplock bug introduced in the new oplock code introduced with 3.0.21. I may try to fudge an ebuild together after that's released if the official one will be awhile.
3.21a came out today!
Created attachment 75961 [details] proposed samba-3.0.21a.ebuild proposed samba-3.0.21a.ebuild needs updated patchset
Created attachment 75962 [details] samba-3-gentoo-0.3.11.tar.bz2 updated patchset for the proposed samba-3.0.21a.ebuild
Created attachment 75997 [details] samba-3.0.21a.ebuild proposed samba-3.0.21a.ebuild cosmetic - updated the header information to match the version no functional difference from the previous post Happy Gnu Year!
Just a note that add that this non-official ebuild/patchset is running quite well in a production environment where Samba handles all file and print sharing, plus is the PDC for 150 systems. Of course, YMMV.
After upgrading with this ebuild from samba 3.0.14a, I'm now getting problems with winbind. The following message is repeated in my winbindd log, and can be triggered even by running wbinfo -p [2006/01/09 11:58:27, 0] nsswitch/winbindd.c:process_loop(748) process_loop: Invalid request size from pid 7233: 1836 bytes sent, should be 1824 This usually means that you are running old wbinfo, pam_winbind or libnss_winbind clients This message suggests a build/installation problem. I tried rebuilding this ebuild a second time, in case the first build picked up old libs from the previously installed 3.0.14a, but that didn't help.
I'll take a look and see if there's something I missed. I didn't really look at anything beyond those issues Christian mentioned. I do have an installation that needs winbind and was planning to get the running within the next couple of days.
Re: comment 9 Luke, Sorry, I don't see what could be causing the issue for you. Are you sure you're building it with the "winbind" USE flag set? Visually checking the install image it looks like the ebuild is working correctly. Interested to know if any other users that need winbind are having issues. Chris
Okay, my problem was simply that some old winbindd processes were still running (despite "/etc/init.d/winbind restart"). After manually killing these processes my problem has now gone away. I guess the problem here was that winbind from samba-2.0.14a did not obey SIGTERM... no fault of this samba-2.0.21a ebuild.
Created attachment 76952 [details, diff] vampire.patch A patch posted on Samba's bugzilla to fix 'net rpc vampire' (desirable when moving from NT4 to Samba) which segfaults in 3.0.21a.
Created attachment 76953 [details] samba-3.0.21a.ebuild (will apply vampire.patch) If a working 'net rpc vampire' is needed, place the vampire patch in the files directory and use this ebuild.
I test this ebuild in a 80 windows clients and run OK Before 3.0.21a in some windows XP, after startup net links are brokens
Created attachment 78680 [details] samba-3.0.21b.ebuild Haven't verified it line by line but the patchset included in this bug report (0.3.11) applies fine to samba-3.0.21b so I'm attaching an updated ebuild to install the newly released 3.0.21b (vampire.patch not needed nor used for the 3.0.21b version).
3.0.21a (without vampire.patch) and 3.0.21b in portage. *They both use vscan engine version 0.3.6b* (so the portage patchset is a bit changed). Thanks to Chris Smith for the excellent work.
