Bug 252164 - net/samba413: update 4.13.1 -> 4.13.4, samba412 and 411 need updates, too
Summary: net/samba413: update 4.13.1 -> 4.13.4, samba412 and 411 need updates, too
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Graham Perrin
URL: https://www.freshports.org/net/samba413/
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-26 16:13 UTC by DutchBSD
Modified: 2022-11-07 22:29 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (timur)


Attachments
Testing base for update to Samba 4.13.4 (536.83 KB, text/plain)
2021-02-16 18:05 UTC, Harald Schmalzbauer
no flags Details
Testing base for update to Samba 4.13.4 (125.14 KB, application/gzip)
2021-02-16 18:28 UTC, Harald Schmalzbauer
no flags Details
Testing diff for updating net/samba413 to 4.3.14 (127.41 KB, patch)
2021-02-18 19:41 UTC, Harald Schmalzbauer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description DutchBSD 2020-12-26 16:13:11 UTC
Ports:
net/samba413
net/samba412 
net/samba411 

Needs to be upgraded to latest releases!
Please see the changelogs @ samba

Dutchman01
Comment 1 DutchBSD 2021-02-07 14:35:48 UTC
May i ask if I'm the only one wo wants the latest bugfix releases of samba in current ports?
Comment 2 Harald Schmalzbauer 2021-02-16 18:05:52 UTC
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
 DISTNAME=                      ${SAMBA4_DISTNAME}
 
-# Overwrite official port's attributes with this inofficial ones
-PKGNAMESUFFIX=                 -OLN
-CATEGORIES=                    inofficial net
-VALID_CATEGORIES+=             inofficial
-
 MAINTAINER=                    timur@FreeBSD.org
 COMMENT=                       Free SMB/CIFS and AD/DC server and client for Unix
Comment 3 Harald Schmalzbauer 2021-02-16 18:28:26 UTC
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.
Comment 4 Kurt Jaeger freebsd_committer freebsd_triage 2021-02-17 06:23:54 UTC
(In reply to Dutchman01 from comment #1)
You are not the only one, if you can provide patches, it helps.
Comment 5 Mikhail Teterin freebsd_committer freebsd_triage 2021-02-18 19:22:22 UTC
(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!
Comment 6 Harald Schmalzbauer 2021-02-18 19:41:56 UTC
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.
Comment 7 Harald Schmalzbauer 2021-02-18 19:50:50 UTC
(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.

-harry
Comment 8 Timur I. Bakeyev freebsd_committer freebsd_triage 2021-02-21 03:33:34 UTC
(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?
Comment 9 Harald Schmalzbauer 2021-02-21 10:08:34 UTC
(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.

-harry
Comment 10 commit-hook freebsd_committer freebsd_triage 2021-03-05 03:17:00 UTC
A commit references this bug:

Author: timur
Date: Fri Mar  5 03:16:54 UTC 2021
New revision: 567357
URL: https://svnweb.freebsd.org/changeset/ports/567357

Log:
  Bump net/samba413 to 4.13.4 version.
  Split pkg-plist into managable chunks.
  Made PYTHON3 bindings a selectable option.

  PR:		252164

Changes:
  head/net/samba413/Makefile
  head/net/samba413/distinfo
  head/net/samba413/files/patch-bind
  head/net/samba413/files/patch-buildtools_scripts_abi__gen.sh
  head/net/samba413/files/patch-buildtools_wafsamba_samba__install.py
  head/net/samba413/files/patch-source3_lib_messages.c
  head/net/samba413/files/patch-source3_modules_vfs__fruit.c
  head/net/samba413/files/patch-vfs_freebsd
  head/net/samba413/pkg-plist
  head/net/samba413/pkg-plist.ad_dc
  head/net/samba413/pkg-plist.cluster
  head/net/samba413/pkg-plist.python
Comment 11 Harald Schmalzbauer 2021-03-05 08:32:02 UTC
Great, thanks for taking care.
But the option for python bindings can be somewhat misleading, since talloc, tdb et. al. depend on python independent of the setting from the samba port.
  One probably expects disabling python bindings for samba would reduce dependency installation for samba package, which isn't true with just setting the samba option!
  Only if NO_PYTHON is defined at compile time of all the major dependencies, these will drop python bindings/dependency and the samba package will be significantly smaller.
So not showing this by OPTIONS safes much headache I guess.
Comment 12 Harald Schmalzbauer 2021-03-05 20:18:43 UTC
Would have suggested the following diff:
--- Makefile    2021-03-05 20:53:17.350996000 +0100
+++ Makefile    2021-03-05 18:29:32.858086000 +0100
@@ -104,12 +99,9 @@
 OPTIONS_RADIO=                 DNS
 OPTIONS_RADIO_DNS=             NSUPDATE BIND911 BIND916
 # Make those default options
-OPTIONS_DEFAULT=               ADS DOCS FAM LDAP \
-                               PROFILE QUOTAS SYSLOG UTMP \
+OPTIONS_DEFAULT=               AD_DC ADS DOCS FAM LDAP \
+                               PROFILE PYTHON3 QUOTAS SYSLOG UTMP \
                                FRUIT GSSAPI_BUILTIN AVAHI
-.ifndef(NO_PYTHON)
-OPTIONS_DEFAULT+=              AD_DC PYTHON3
-.endif

together with
.if defined(NO_PYTHON) && ${PORT_OPTIONS:MPYTHON3}
                               @${ECHO_CMD}; \
                               ${ECHO_MSG} "===>  PYTHON3 option is set but NO_PYTHON is defined at the same time"; \
                                ${ECHO_CMD}; \

.endif                                ${FALSE}


But this won't work, since

AD_DC_IMPLIES=                 PYTHON3

was a big surprise for me.
I'm really disappointed how OPT_IMPLIES was implemented.
It simply ignores users' options selections and adjusts settings silently behind the scene.

OPT_PREVENTS does the right thing, it _notifies_ the user of a technical conflict.
This is the only way to implement such "helpers" - silently overwriting (disrespecting) user directives by super-smart-assistants is known elsewhere, but not the kind of help FreeBSD was known for.
That said, of course my rant is lacking a proper diff, sorry, time doesn't permit to dig into the ports/Mk - which still misses some fixes bugzilla would provide from my reports.
And as far as I saw, there's no OPT_NOTSET_PREVENTS.
Too many pseudo-smart helpers only help accumulating sematically wrong makefiles...
Comment 13 Graham Perrin freebsd_committer freebsd_triage 2021-11-21 14:50:37 UTC
<https://www.freshports.org/net/samba413/#history> 4.13.14 ▶ <https://cgit.freebsd.org/ports/commit/?id=7fb6816ae482d59213038839076095670273b4a9>

> net/samba413: Upgrade to the latest version to address 
> security vulnerabilities: …
Comment 14 Michael Osipov 2022-11-07 20:22:05 UTC
Can someone close this as overcome by events?
Comment 15 Graham Perrin freebsd_committer freebsd_triage 2022-11-07 22:29:19 UTC
(In reply to Harald Schmalzbauer from comment #11 and comment #12)

For any outstanding actionable issue, please aim for a separate bug report. 


(In reply to Michael Osipov from comment #14)

Closing, as suggested. Severity reduced to the norm for updates. 

FreshPorts includes links to cgit, Codeberg, GitHub, and GitLab views of commits. 

----

I imagine efforts, now, focusing on net/samba416.

<https://www.freshports.org/net/samba416/>