Created attachment 248412 [details] patch the security/krb5 LDAP option probably shouldn't be enabled by default because this can create dependency loops if OpenLDAP or Cyrus is built with MIT Kerberos. however, it's still useful to provide a version of Kerberos with LDAP support for people who need this. this patch adds new slave ports, krb5-ldap, krb5-ldap-121, and krb5-ldap-120 which build with LDAP enabled.
for context (and to justify this change): i'm trying to set up a backup KDC on a small arm64 system (RPi) which is too slow to build packages itself, i don't have any other arm64 systems i can build on, and since poudriere cross-building is mostly broken these days due to Rust, that means i'm relying on pkg.freebsd.org's binary packages. so, having a binary package for krb5-ldap would allow me to make progress on this.
How about we use flavors instead of subpackages? This would be a less intrusive change to the ports tree, keeping the change within teach Makefile. I don't think bapt@ intended a proliferation of slave ports when creating the subpackages feature. I see subpackages as a vehicle to split krb5 into server and client. That is the plan when the subpackages feature matures a little.
i didn't use subpackages for this (even though i think this would be a good example of a subpackage, since kldap is a loadable .so) because of the issues that resulted in subpackage adoption being paused, so this is just a normal slave port that builds a full package. i can redo this to use flavours instead though - i assume the flavours should be called "default" and "ldap"?
Created attachment 248414 [details] use flavors Use flavors instead of a proliferation of slave ports. Subpackages would also work in this instance.
Created attachment 248415 [details] flavors i came up with a patch that does flavours in a slightly different way, which i suppose is obsolete now, but i'll attach it for posterity :-)
Created attachment 248416 [details] use flavors Thinking I'm still at $JOB. Oops.
Created attachment 248417 [details] Flavors respecting existing package name This patch implements ldap and default flavors, whereas the default flavor maintains the same package name as existing today. It essentially adds a krb5-ldap flavor.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9926898a0c052d79aaa08708e3249fc39e633174 commit 9926898a0c052d79aaa08708e3249fc39e633174 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-13 00:33:16 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-02-13 18:47:53 +0000 security/krb5*: Flavorize with default and ldap flavors This provides a binary package to users who require MIT KRB5 with LDAP support. This patch does not change the current, now default, package name. PR: 277015 security/krb5-119/Makefile | 11 ++++++++++- security/krb5-120/Makefile | 11 ++++++++++- security/krb5-121/Makefile | 11 ++++++++++- security/krb5-devel/Makefile | 8 +++++++- security/krb5/Makefile | 2 ++ 5 files changed, 39 insertions(+), 4 deletions(-)
Fixed.
FYI, I'm not sure this is related, but today I'm getting a cyclic dependency which I can't track down yet. I'm trying to build this on FreeBSD 14.0. These packages depend on each other: * krb5-1.21.2_3 * openldap26-client-2.6.7 * cyrus-sasl-gssapi-2.1.28 The above come from: * security/krb5 (depends on openldap26-client) * net/openldap26-client (depends on security/cyrus-sasl2) * security/cyrus-sasl2
(In reply to Dan Langille from comment #10) You cannot add LDAP support to krb5 while openldap26-client depends on gssapi. You must remove either krb5 LDAP dependency or remove openldap26-client dependency on gssapi. However you can build and install the krb5 LDAP flavour. I don't know if installing it will force the removal of depending packages. Your only solution is to build krb5 without LDAP support. Then after installing openldap with the krb5 dependency, rebuild and deinstall/install the krb5 port with LDAP support by hand. This is a kludge. As a ports developer, you already know that there is no solution to circular dependencies.
Just before your reply, I found that net_openldap26-client_UNSET+=GSSAPI allowed security/cyrus-sasl2-gssapi to build. My original comment should have referred to security/cyrus-sasl2-gssapi, not security/cyrus-sasl2. Thank you for your reply.
This patch seems to solve the dependency loop with Poudriere when trying to build krb5 with the LDAP backend alongside with cyrus-sasl-gssapi using MIT kerberos. In my poudriere pkglist: security/krb5@default security/krb5@ldap net/openldap26-client net/openldap26-server and make.conf: OPTIONS_SET=GSSAPI GSSAPI_MIT OPTIONS_UNSET=GSSAPI_HEIMDAL GSSAPI_BASE GSSAPI_NONE HEIMDAL Poudriere builds all the packages without issue! Sadly, I cannot *install* krb5-ldap as it apparently does not satisfy cyrus-sasl-gssapi's dependency on krb5: # pkg install krb5-ldap Updating internal repository catalogue... internal repository is up to date. All repositories are up to date. Checking integrity... done (1 conflicting) - krb5-ldap-1.21.3 conflicts with krb5-1.21.3 on /usr/local/bin/compile_et Cannot solve problem using SAT solver, trying another plan Checking integrity... done (0 conflicting) The following 3 package(s) will be affected (of 0 checked): New packages to be INSTALLED: cyrus-sasl-gssapi: 2.1.28 krb5: 1.21.3 openldap26-client: 2.6.8 Number of packages to be installed: 3 I'm not a ports expert, but could gssapi.mk be modified to allow krb5-ldap to satisfy the krb5 dependency? Some background...I am working on building a FreeIPA-like solution using FreeBSD and OpenLDAP, where multiple OpenLDAP servers perform multi-master replication. I am using LDAP as the KDC's database backend, and clients authenticate using GSSAPI. I am currently working around this dependency loop by using GSSAPI_BASE, but the version of Heimdal in the base system is ancient and I'd rather not use it (it lacks support for KRB5_CLIENT_KTNAME and seems to refuse to use KRB5_KTNAME if the process drops privileges at any point).
(In reply to Cullum Smith from comment #13) This will require a change to Mk/Uses/gssapi.mk around line 77 to depend on the desired flavor. (Same problem if we had slave ports.) I don't maintain that file, cc'd hrs@. I think the correct solution would be to add an MIT_FLAVOR variable one could put into their make.conf. The MIT port could also respect MIT_FLAVOR to set the FLAVOR variable during build. Let's wait for hrs@ to weigh in.
Just in case anyone else encounters my issue from a search engine, I managed to solve this problem using Poudriere Sets: https://wiki.freebsd.org/VladimirKrstulja/Guides/Poudriere#Sets I have a special "set" used solely by my LDAP/KDC servers, where I set the following in /usr/local/etc/poudriere.d/kdc-make.conf: OPTIONS_SET=GSSAPI GSSAPI_MIT security_krb5_SET=LDAP security_cyrus-sasl2-gssapi_SET=GSSAPI_BASE security_cyrus-sasl2-gssapi_UNSET=GSSAPI_MIT This lets me build MIT KRB's against OpenLDAP. Then, when OpenLDAP pulls in cyrus-sasl, it links against the base Heimdal, resolving the dependency loop. In my "default" set (used by all hosts *except* my LDAP/KDC servers), I instead use the following options in /usr/local/etc/poudriere.d/make.conf: OPTIONS_SET=GSSAPI GSSAPI_MIT security_cyrus-sasl2-saslauthd_SET=GSSAPI_MIT This allows everything in my environment to use MIT's Kerberos, with the exception of cyrus-sasl2-gssapi on the LDAP server itself, which uses the base heimdal libraries. The only thing the LDAP server uses the base Heimdal for is to accept GSSAPI authenticated SASL connections from clients (which are all using MIT kerberos). No issues so far.