On Mon, Nov 4, 2019 at 8:46 PM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > The problem with the Samba team's advice is that it essentially > > prevents the MIT Kerberos AD-DC implementation from getting any > > better. Without people using it, we can't know what needs to be fixed. > > The Red Hat FreeIPA team has been working on making this functionality > > work well with MIT Kerberos for nearly a decade. The main reason it's > > not in RHEL/CentOS 8 is because the functionality is too new for them > > to turn it on. > > I've been using Samba effectively for multi-platform integration and > account manage since 1996. This is not quite before Red Hat existed, > but it's close. d. I have never found FreeIPA to be useful in a > personal or professional environment. It relies on Samba for > integration with AD. Without robust integration with AD, I have no use > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > Perhaps it's time to drop FreeIPA? > Hello! FreeIPA user here. FreeIPA is one of the most popular reasons people run Fedora Server. The openSUSE Project's internal identity management system is FreeIPA on Fedora Server (there have been issues with porting it to openSUSE...). There are many other FreeIPA users, as well as downstream Red Hat IdM users. > > Also, declaring that it is experimental is meaningless. What defines > > it as experimental? Is there any particular known massive breakage? > > We're not going to ship Heimdal Kerberos because the two Kerberos > > implementations are incompatible and supporting both would be a > > massive nightmare. > > That aounsa like a question for the Samba lists. I'm active over > there. Want me to double check the status? > No need. Alexander Bokovoy has already answered that question upthread. > > At this point, the only way Samba Team will stop calling it > > experimental is when lots of folks are using it. That's why Fedora > > ships with it enabled. We have the opportunity to help make that > > better upstream. > > I think they're confused by the fact that Fedora and Red Hat, for > *years*, shipped with a "samba-dc" suite of packages that didn't > actually contain any software. The samba-dc packages basically said > "go away you silly English knighits or I shall taunt you a second > time". Samba-dc packages shouldnever have been published this way: it > would have been saner and safer to set a "Conflicts: samba-dc*" with > the primary samba package if these features were not enabled, rather > than publishing empty and useless packages. This is, in fact, what I > do with my published backports of Samba to RHEL with the dc enabled > with Heimdal.. I've been having some adventures with building those > lately due to modularity and the activation of zstd for RPM and the > instability of Fedora 31 in virtualized environments, but I received > workarounds from mock developers for that a few days ago. > I'm fully aware of how the Samba packaging is structured. I know exactly when the samba-dc packages stopped being empty, and I've been playing with samba AD-DC since it was activated in Fedora properly. That does not change the fact that the functionality is new and still needs time to bake. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
