Some where in the Samba 4.0.x line after 4.0.3 samba 4 on OpenBSD became unusable as all of the samba daemons and command line tools took extremely long times to start up. This change was seen. --- samba-4.0.3/wscript Tue Dec 4 21:07:44 2012 +++ samba-4.0.26/wscript Mon Dec 8 18:46:38 2014 - if sys.platform != "openbsd4": + if not sys.platform.startswith("openbsd"): conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', testflags=True) We would like it if you could remove the following line on all samba 4.1.x and 4.2.x versions. if not sys.platform.startswith("openbsd"): so the linker can use the --as-needed Output of LD_DEBUG=1 time samba-tool: ==> before <== doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0] doing dtors doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740: [/usr/local/lib/libpython2.7.so.0.0] doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0] doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0] doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1] doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0] 251.92 real 251.96 user 0.19 sys doing dtors doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0] ==> after <== doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0] doing dtors doing dtors obj 0xa6021425800 @0xa603fca0740: [/usr/local/lib/libpython2.7.so.0.0] doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0] doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0] doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1] doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0] 1.49 real 1.24 user 0.22 sys doing dtors doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0] Thanks
The OpenBSD strict linking exception was introduced by Matthieu in 61d9aa5a3e899d4dfea7bff054837b0b3907fa75 So Matthieu, can you have a look at this bug report here, which wants the strict linking rules back? :-)
I can confirm that Samba4 is unusable without as-needed. as-needed was unsafe until recently (we upgraded the binutils version we used), but it is now usable. We removed the test about OpenBSD in our ports tree: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/samba/patches/patch-wscript?rev=1.1&content-type=text/plain Gotta perform test about no-undefined though.
(In reply to Jérémie Courrèges-Anglas from comment #2) > I can confirm that Samba4 is unusable without as-needed OpenBSD also still has the NGROUPS_MAX limit of 16, right? IMHO this makes Samba quite unusable on that platform anyway. But a start time of 251.92s is ridiculous in any case but this one looks like a performance bug that the OpenBSD developers should try to fix. A performance penalty of that dimension just becasue there are superfluous libs linked in is crazy - especially given that OpenBSD didn't care about making the as-needed linker option usable till some days ago. In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate
(In reply to Björn Jacke from comment #3) > OpenBSD also still has the NGROUPS_MAX limit of 16, right? IMHO this makes Samba quite unusable on that platform anyway. Samba is quite usable on OpenBSD right now, even if it can't support setups you may be used to. AFAIK, nobody hit/reported the NGROUPS_MAX limit with Samba so far. Also, if NGROUPS_MAX proves to be too low, we can bump it. > But a start time of 251.92s is ridiculous in any case but this one looks like a performance bug that the OpenBSD developers should try to fix. A performance penalty of that dimension just becasue there are superfluous libs linked in is crazy - especially given that OpenBSD didn't care about making the as-needed linker option usable till some days ago. It agree that it is ridiculous but very few other OpenBSD ports have such an enormous number of libraries and inter-libs references involved. :) > In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate Sorry but this won't happen. Testing for binutils corner cases doesn't sound like a pleasant task. Please trust that as-needed works on OpenBSD. If it doesn't we'll fix it.
(In reply to Jérémie Courrèges-Anglas from comment #4) Maybe the reason why nobody noticed NGROUPS_MAX is that OpenBSD can't run winbind in AD due to the lack of nsswitch. I considered to write a NIS server into winbind to make it work on OpenBSD, join the local "NIS domain". Question: Would NIS be considered a supported OpenBSD feature, so is it worth putting effort into it?
(In reply to Jérémie Courrèges-Anglas from comment #4) >Samba is quite usable on OpenBSD right now, even if it can't support setups you >may be used to. AFAIK, nobody hit/reported the NGROUPS_MAX limit with Samba so >far. Also, if NGROUPS_MAX proves to be too low, we can bump it. that would be awesome. Let me know when I need to update https://www.j3e.de/ngroups.html then :-). The new NGROUPS_MAX limit that FreeBSD 8.0 introduced would be a good start. >Sorry but this won't happen. Testing for binutils corner cases doesn't sound >like a pleasant task. Please trust that as-needed works on OpenBSD. If it >doesn't we'll fix it. okay, maybe we might just do that...
(In reply to Björn Jacke from comment #6) > The new NGROUPS_MAX limit that FreeBSD 8.0 introduced would be a good start. Thanks for the link. I think the issue was already discussed internally to the project. Pushing those boundaries are an interesting goal but IMO we have bigger problems to tackle first. Regarding the special treatment of linker flags on OpenBSD: --as-needed can safely go away. I would like to make tests for the other flags concerned by OpenBSD-specific tests. I only tested 4.1.20 on amd64 so far.
(In reply to Volker Lendecke from comment #5) > Maybe the reason why nobody noticed NGROUPS_MAX is that OpenBSD can't > run winbind in AD due to the lack of nsswitch. We don't support nsswitch, indeed. We package winbind for external software that might want to use it (eg dovecot, squid). I don't think this is specific to AD mode. > I considered to write a NIS server into winbind to make it work on > OpenBSD, join the local "NIS domain". Question: Would NIS be considered > a supported OpenBSD feature, so is it worth putting effort into it? I have no idea, really. You might be aware that we "support" LDAP auth using ypldap which is similar to your proposal, but I don't know people that are using it right now. I don't know about the future of such NIS bridges in OpenBSD. The idea is probably the only thing that could work right now, though. Thanks for bringing this up.
(In reply to Jérémie Courrèges-Anglas from comment #7) That should read - The check for openbsd to not include as-needed should go away. We require the linker flag to help resolve the slow startup times.
(In reply to Björn Jacke from comment #3) > In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate Currently the working Samba on OpenBSD (even the forthcoming 5.8 release) is Samba 3.6.15 + back ported security fixes where is was not an issue. I therefore don't see the need for the sanity check, just the removal of the test for OpenBSD. Moving forward, OpenBSD supports as-needed and even if individuals try compile samba 4 on older releases, then Samba 4 is unlikely to work due to lots of other factors that have been resolved in the OpenBSD ports tree version of Samba 4.
this is fixed in master with b0f41c07ffe8600433c20a038b1612c04ed29e89 Ralf: can you review+ for the cherry-pick to the release branches?
Great, thanks.
(In reply to Björn Jacke from comment #11) Pushed to autobuild-v4-[3|2]-test. Next time, please attach the patches for each branch to the bug report and explicitly add review flags for each version. Thanks!
(In reply to Karolin Seeger from comment #13) Is this an issue in 4.1 as well? I was asked privately to backport...
Well, yes I guess.
(In reply to Ralph Böhme from comment #15) > Well, yes I guess. That is true. The OpenBSD port is at 4.1.20 right now, thus it is affected (I have a local patch in our CVS repo). However I see no reason for anyone to run upstream samba-4.1.X on OpenBSD, so I did not ask for a backport to 4.1 which is maintenance mode. It would allow me to remove one local patch among 26 other patches, so it is not very high priority for me. :)
(In reply to Jérémie Courrèges-Anglas from comment #16) Thanks for your feedback, it's much appreciated! Closing out bug report. 4.1 is in the security fixes only mode now. Thanks!