In message <afrsquqsti4pr...@freefall.freebsd.org>, Lexi Winter writes: > > > --dqKOQqea6XkA3NXh > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Cy Schubert: > > I'll take a look at this and maybe reach out to you offline to plan > > the necessary ports changes. I have some gssapi.mk patches to > > implement an optional port split as requested by some in a PR who want > > more of a Red Hat style of package split. > > i think you're referring to my PR. after some more testing, i realised > this can't work, because even if you split the port into krb5-libs and > krb5-server, krb5-libs still has to be compiled with LDAP support > because the support libraries include LDAP code. using an LDAP-enabled > kdc with a non-LDAP-enabled libs causes the kdc to crash at startup.
That is correct and it is what I was expressing in the PR. You have a circular reference regardless. Your LDAP server requires Kerberos for authentication while Kerberos stores its KDB in LDAP. You will need to build one without Kerberos support, build the other, then build the first with. The reason the circular dependency isn't readily apparent to most people is that LDAP uses cyrus-sasl-gssapi for authentication which depends on Kerberos. Kerberos in base will not fix this because it uses a BDB KDB database (there is no LDAP in base) and the LDAP configuration uses an LDAP KDB. > > so my original intention of making krb5-libs not depend on OpenLDAP > isn't possible with that solution. i didn't get around to updating the > PR yet, sorry. It's a circular impossibility. But if people wanted it I'd have implemented it and let them figure out whether the chicken or the egg came first. Again, because the circular dependency isn't in people's face, they don't see it. People think splitting the ports will fix the problem. It won't. Splitting the ports will reduce the number of prerequisites installed but I don't think that's worth all the effort. Even though I have a git branch that already implements the change it's not worth the maintenance headache as pkg-plist generation will consume more developer (my) time every upgrade. > > i'm hoping with MIT krb5 in base, we might be able to find a better > solution to this, but i haven't had a chance to actually try it. > it may be we have to go with a glib-style "bootstrap port" solution. It may help bootstrap but you can't rely on it to supply your KDC needs as it doesn't and will never use LDAP, unless we import OpenLDAP into base, and that's another matter of discussion. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=0 <tangent> Regarding OpenLDAP in base, should we remove NIS we should consider importing OpenLDAP to replace it. I used to use NIS (still configured) but have migrated my NIS to LDAP. With PAM and nsswitch it's easy to have it reference LDAP before NIS during conversion. Then comment out NIS from nsswitch.conf. This requires a bit of planning to allow both to coexist so that users can convert during a conversion period. </tangent>
