Nico Kadel-Garcia <nkadel@xxxxxxxxx> writes: > Robbie Harwood <rharwood@xxxxxxxxxx> wrote: >> Nico Kadel-Garcia <nkadel@xxxxxxxxx> writes: >>> Robert Marcano <robert@xxxxxxxxxxxxxxxxx> wrote: >>>> Nico Kadel-Garcia wrote: >>>>> Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: >>>>>> Dario Lesca wrote: >>>>>>> Robert Marcano ha scritto: >>>>>>>> >>>>>>>> I switched to run Samba DCs on a container with non Fedora / RHEL / >>>>>>>> CentOS provided RPMs. >>>>>>> >>>>>>> Thank Robert for reply. >>>>>>> >>>>>>> Then why don't release samba compiled with Heimdal kerberos? >>>>>>> >>>>>>> Just change a flag in build time, and all can use it into a production >>>>>>> environment. >>>>>> We do not support Heimdal builds in Fedora. It is not possible to reuse >>>>>> components of Samba built against Heimdal within other applications >>>>>> compiled against MIT Kerberos. This is, in particular, a show-stopper >>>>>> for FreeIPA and SSSD integration. >>>>> >>>>> My personal experience is that this is not true. sssd in a recent >>>>> Fedora (Fedora 29 last year) works just fine against an honest-to-god >>>>> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with >>>>> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works >>>>> against a real AD controller. sssd does not rely on a freeipa server. >>>>> It has genuinely unfortunate behavior of pre-downloading the *entire* >>>>> LDAP tree, and breaking if it can't complete this, but that's another >>>>> issue that won't be visible in most small test environments with local >>>>> domain controllers. >>>> >>>> The parent poster is refering to having two Kerberos implementations >>>> on the same process, not from two different machines. For example, an >>>> application linking against Samba libraries with Heimdal and at the >>>> same time linking with system MIT Kerberos for another features of >>>> that application unrelated with Samba. >>> >>> Sorry to sound critical, but this is irrelevant because, to use domain >>> controller enabled Samba, it compiles its own internal Kerberos. There >>> are other system libraries which Samba shares, such as libtalloc and >>> libldb, but for the comain controller. As best I can tell with sssd, >>> it's not been a problem. I did not run FreeIPA at all after some >>> failed attempts, and found with Samba compatible completely with AD >>> and the clients able to work, I had no use for it. So the libraries >>> did not overlap. > > >>> If FreeIPA were dropped from Fedora, would there remain any reason to >>> prefer MIT Kerberos over Heimdal Kerberos? It's not that I object to >>> the MIT Kerberos, I know several of the authors personally as old >>> friends. But that's not a reason to prefer the software. >> >> Hi, your Fedora krb5 maintainer here. I have met and work with several >> Heimdal developers, and have nothing against them or their project; >> they generally do good work. > > And you present some reasons to prefer MIT krb5 overall. Fair enough. > I do note that "dropping FreeIPA" didn't get mentioned. Is it the > primary component of Fedora that relies specifically on MIT krb5? No. You can't switch out implementations after compilation. krb5 client authentication is very widely used throughout the distro, and is part of the minimum possible install. ssh uses it; both firefox and chromium/chrome use it; the NFS stack uses it; postgres/mariadb/mysql use it; etc. Basically, if you have a program that performs user authentication, it has Kerberos support. (And if not, I'm probably interested in adding it :) ) On my fc30: root@seton:~# dnf repoquery --whatrequires krb5-libs | grep x86_64 | wc -l ... 250 Thanks, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
