dns/samba-nsupdate: Deprecate

[0mp]

Summary

Based on the following comment by michaelo@:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247802#c8

[0mp]

The port looks pretty outdated. Is it time to deprecate it?

[timur]

The question is what problem are you trying to tackle. Chasing the software versions was never the good practice, IMHO, but see yourself.

The root of the problem here is the fact that maintainer of the dns/bind-tools doesn't want to enable krb5 support by default, so we don't have OOTB solution for the signed DNS updates in the AD configuration. This port was trying to close that gap, providing Samba AD, installable from the packages, without the need for building it separately.

This doesn't look like and adequate replacement:

====> GSSAPI Security API support: you have to select exactly one of them
     GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
     GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
     GSSAPI_MIT=off: Using security/krb5
     GSSAPI_NONE=on: Disable

Again, it could be that with the current state of Samba it's (almost) impossible to retain AD functionality and we should concentrate only on the basic fileserver with ability to join AD domain.

Then we can drop a lot of patches, dependencies and this port all together.

[0mp]

In D54182#1239024, @timur wrote:

The question is what problem are you trying to tackle. Chasing the software versions was never the good practice, IMHO, but see yourself.

The root of the problem here is the fact that maintainer of the dns/bind-tools doesn't want to enable krb5 support by default, so we don't have OOTB solution for the signed DNS updates in the AD configuration. This port was trying to close that gap, providing Samba AD, installable from the packages, without the need for building it separately.

This doesn't look like and adequate replacement:

====> GSSAPI Security API support: you have to select exactly one of them
     GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
     GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
     GSSAPI_MIT=off: Using security/krb5
     GSSAPI_NONE=on: Disable

Again, it could be that with the current state of Samba it's (almost) impossible to retain AD functionality and we should concentrate only on the basic fileserver with ability to join AD domain.

Then we can drop a lot of patches, dependencies and this port all together.

Thanks for the input! Could you post that comment to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291687. Otherwise it will get lost most likely as this revision is already closed.

[michaelo]

In D54182#1239024, @timur wrote:

The question is what problem are you trying to tackle. Chasing the software versions was never the good practice, IMHO, but see yourself.

The root of the problem here is the fact that maintainer of the dns/bind-tools doesn't want to enable krb5 support by default, so we don't have OOTB solution for the signed DNS updates in the AD configuration. This port was trying to close that gap, providing Samba AD, installable from the packages, without the need for building it separately.

This doesn't look like and adequate replacement:

====> GSSAPI Security API support: you have to select exactly one of them
     GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
     GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
     GSSAPI_MIT=off: Using security/krb5
     GSSAPI_NONE=on: Disable

Again, it could be that with the current state of Samba it's (almost) impossible to retain AD functionality and we should concentrate only on the basic fileserver with ability to join AD domain.

Then we can drop a lot of patches, dependencies and this port all together.

Which patches do you mean explicitly?

Is there an interesting to create dns/bind-nsupdate with Kerberos enabled by default or have bind-tools and nsupdate OPTIONS only? I have a custom port on top which updates with AD DNS at night. The only problem I see is how to depend on such a port if the admin wants to install bind-tools in parallel? There is no way to pick one of these two... I have been building bind-tools with MIT Kerberos from ports and it almost never failed for me. Can't we pursue the portmainer to enable GSS-API from base? I don't see any downside doing it.

I had hopes that one could add it to https://github.com/NLnetLabs/ldns, but they ditched it for a Rust-based library which likely never make into base :-(

[kiwi]

I think this is same issues we have with samba and sssd2.
In fact building tools with krb5 enabled per default should not be a good idea, because there is several way to acheive that and for some users they may not need this.
Maybe dns/bind-tools could have flavor support and then we can use already built bind-tools with krb5 ?

This will permit to have user have the tool prepackaged, have poudriere complaining there is something wrong, and have a direct dependency with the flavor ?

What do you think?

[michaelo]

In D54182#1239946, @kiwi wrote:

I think this is same issues we have with samba and sssd2.
In fact building tools with krb5 enabled per default should not be a good idea, because there is several way to acheive that and for some users they may not need this.

Why not? Even if it is base? It is already there, it won't hurt if you don't use it. All Linux distro build against a Kerberos flavor by default. This is not rocket science, IMHO.