Needs to be upgraded to latest releases!
Please see the changelogs @ samba
May i ask if I'm the only one wo wants the latest bugfix releases of samba in current ports?
Created attachment 222494 [details]
Testing base for update to Samba 4.13.4
Please find attached a partially tested 4.13.4 update.
Note that files/patch-source3_lib_messages.c is included upstream (verifed, as well as the GPG signature of the hased tar.gz used for creating this port pdate) and files/patch-bind was removed intentionally since maintaining the diff wasn't adopted upstream and currently it's just an additional maintenance burden.
patches were adopted/recreated where needed, plist was re-created in order to respecting -DNO_PYTHON (%%SABA4_PYTHON%%).
My only interest is to get a CIFS server as lean and slick as possible, without AD-DomainController overhead and bloated dependencies.
I tested compiling and packaging WITH_AD_DC and -DNO_PYTHON (which reqires disabling AD_DC).
I did _NOT_ test any combination possible, nor did I dig into the autoduplicate PLIST warnings.
Note that samba replaced crypto libraries upstream, so even if AD_DC is disabled, GnuTLS is a mandatroy dependency for other code paths nowadays.
stage-qa complained about missing ICU dependency, so I added this LIB_DEPENDS.
This portorigin is inofficial/samba413 instead of net/samba413 and has a package suffix of -OLN.
If you want to try as drop in net/samba413 replacement, it's enough to move directory content and
--- samba413/Makefile 2021-02-16 18:50:07.532967000 +0100
+++ samba413/Makefile 2021-02-01 20:13:53.626385000 +0100
@@ -8,11 +8,6 @@
MASTER_SITES= SAMBA/samba/stable SAMBA/samba/rc
-# Overwrite official port's attributes with this inofficial ones
-CATEGORIES= inofficial net
COMMENT= Free SMB/CIFS and AD/DC server and client for Unix
Created attachment 222497 [details]
Testing base for update to Samba 4.13.4
There was a last minute plist correction missing.
This shell-archive is gzipped.
(In reply to Dutchman01 from comment #1)
You are not the only one, if you can provide patches, it helps.
(In reply to Harald Schmalzbauer from comment #2)
> GnuTLS is a mandatroy dependency for other code paths nowadays.
Argh, that's unfortunate... Can we not patch it "back" to use OpenSSL?
> This portorigin is inofficial/samba413 instead of net/samba413 and
> has a package suffix of -OLN.
> If you want to try as drop in net/samba413 replacement, it's enough
> to move directory content and
Thanks for the work, Harald, but I, for one, don't know anything about "inofficial". Could you attach diffs against the existing net/samba413 as is customary for tickets seeking to upgrade an existing port? Thanks again!
Created attachment 222559 [details]
Testing diff for updating net/samba413 to 4.3.14
This diff applies to net/samba413, as opposed to tha shar, which is meant as parallel testing port in inofficeial/samba413.
(In reply to Mikhail Teterin from comment #5)
GnuTLS doesn't replace OpenSSL routines, but samba's own legacy crypro code, afair!
Most likely in source3, but haven't inspected at all. Just distilled from release notes!
The diff shows that I forgot to add the previous comment/diff-header to files/0001-Zfs-provision-1.patch.
Please take care before committing, no functional impact of course.
(In reply to Harald Schmalzbauer from comment #6)
Can you, please, provide functional diff against the 4.13.1 version of the port?
So far I see a huge patch with shifted line numbers - which nice to fix eventually, but that doesn't really affect correctness of the patches themselves.
You also, seems, randomly moved lines in the pkg-plist, so it's hard to say what was really added, what was removed, etc.
In this form it's not realistic to understand what was actually changed.
Can you provide a bit more detailed summary to what was changed?
Also, what is that NO_PYTHON flag you are talking about?
(In reply to Timur I. Bakeyev from comment #8)
Hi Timur, I intentionally created a shar because the diff might be misleading.
I started mechanically inspecting patches (read: no functional checks, just plausability/compiling) against vanilla 4.13.4. That's why there are many line shifts.
Like mentioned, only two patch differences affect functionality: The patch-source3_lib_messages.c was included upstream, so deleted. Likewise the patch-bind was deleted, since upstream added bind916 support - not as smart as your regex introducing patch-bind, but since upstream didn't adopt it, one had to spend time on a cosmetic maintenance level for each release - hence I droped it.
What I wasn't aware when I started to create a plist from scratch is the module-dependent auto registering logic - which needs inspection, since I get pkg duplicate warnings for files which never show up in the manual plist.
I also wasn't aware of your manual grouping in the PLIST.
Mine is diff based on 'make makeplist' (kept the intermediate diffs for future repeatings).
The additional diff was on user request for user-testings only. Since I have -DNO_PTYHON 4.13.4-packages running in production, others can have something to test with low efforts.
Maintaining the samba monster can in no way be mentioned in the context of low efforts...
I don't have test environment for serious AD_DC related functions (while skills would last in that case), but I also don't know about FAM details, e.g., not to mention vfs_fruit, vfs_freebsd, vfs_zfs. The vfs_fruit is simply not testable for me aswell, the latter are beyond skills. At leaset if it is about maintaining in a sensible ammount of time.
I was surprised that I don't have to delete des keys in the kerberos keytab after "net ads join" anymore - no idea when in the 4.x line they introduced that change. Even checking differences between 4.11, 4.12 and 4.13 is beyond my time budget, since I only need a very limited subset of samba functions - most likely like the majority of samba users.
But it took me one whole day to create a working port for the update 4.13.1 -> 4.13.4 - note: I didn't have to actually "port" anything, I just used already provided patches; the real work was already done by someone else!!! _Much_ too much effort for a simple "maintenace" release. I have no idea why we want to keep 4.12 and 4.11 alive too. Does anybody have a test- or production environment utilizing any of the changings between those major releases? I strongly doubt.
Samba in it's current upstream Linux-only maintained state is not maintainable on FreeBSD in any sensible way imho. That's why I created an inofficial/samba413, where I want to reach a state so that Windows-altering ACEs for ZFS backed shares gives expected results and compatibility, stability and performance is acceptable. To my surprise, no show stopper yet - which contradicts my samba experience of the last decade.
But this is a one-shot, so it doesn't really help you with the samba burden, sorry.
I'm not sure if samba maintenance (and it's tdb, talloc, tevent relatives) results in a lower time*skills factor than implementing CIFS in base - like Illumos does (and ZFS assumes to be).
Testing/adopting the ActiveDirectory stack and CUPS etc. and all sensible combinations of it, will consumes at least much more time considering the ammount needed during the next 5 years.
Either upstream starts taking FreeBSD into account for release QA, or samba will stay a nightmare on FreeBSD for maintainers and users likewise.
That said, 4.13.4 seems to be in a pretty usable state for simple CIFS service tasks.