On Fri, Jun 18, 2021 at 5:14 PM Simo Sorce <s...@redhat.com> wrote: > On Fri, 2021-06-18 at 16:27 +0200, Simon Pichugin wrote: > > Hi folks, > > my name is Simon Pichugin and I am a maintainer for OpenLDAP. > > > > Recently, OpenLDAP has released 2.5 version. > > It has quite a big amount of changes - > > https://www.openldap.org/software/release/announce.html > > And it includes a pretty important "Upgrading from 2.4.x" section - > > https://www.openldap.org/doc/admin25/guide.html#Upgrading%20from%202.4.x > > Also, OpenLDAP on Fedora currently has links to a versioned library: > > > > ❯ ldconfig -p | grep libldap > > libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2 > > libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2 > > > > Hi Simon,
is upstream releasing libraries with the versioned name in? > Or was this a Fedora packaging decision? > > Are they actually breaking ABI between 2.4 and 2.5 ? > Hi Simo, thank you for the reply! It really had helped me to think through and shape the plan. Yes, upstream releases libraries with the versioned name in them. > > This makes it harder to upgrade as a lot of packages depend on the > > versioned one (and the new package has only libldap-2.5.so.2 library. (I > > even filed an issue to sudo but I think it's not related to them much - > > https://github.com/sudo-project/sudo/issues/105 ) > > > > I suggest carefully reading the sections that talk about SONAME in > here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > I came here for advice as the upgrade can be a sensitive subject for many > > users. > > > > What I think can be done: > > > > - Rework openldap-compat package for openldap 2.5, so it will include > > libldap-2.4 libs (both with and without '_r'). I am not exactly sure > what's > > the proper way to do this (make a tarball with the compiled > libldap-2.4 > > libs and place it to the repo - would be okay?) > > No, you would probably want to have a separate package with its own > sources. > > > - Openldap 2.5 package will include only libldap-2.5.so.2 library and > > while testing we will tag it with some build tag so we can make sure > that > > everything builds with it successfully. > > Are there any API changes in 2.5 ? > I am wondering, is this just a gratuitous rename from upstream? Or will > there be issues building code because API changed? What about the ABI? > > If the ABI hasn't changes we could even think about just providing > symlinks ... > The ABI report goes as follows: https://spichugi.fedorapeople.org/compat_report.html So ABI doesn't differ much between the versions. ldap_gssapi_bind and ldap_gssapi_bind_s are not used anywhere in IDM stack (FreeIPA, Samba, SSSD, 389-ds, or python-ldap), and the depreciation was actually discussed many years ago: https://bugs.openldap.org/show_bug.cgi?id=6567 So probably, it's not used by anybody and libldap 2.4 -> 2.5 should transition well without issues. Still, I think we should go through the safe way and do the process through the Fedora Change proposal. I think we can do it similarly to https://fedoraproject.org/wiki/Changes/Autoconf_271 (but without a compact package as the issues other projects may have probably will be pretty minor and easily fixable and tested with the package with side-tag) What do you think? > > I am not sure how we can help openldap-servers package users. Should we > > create a change proposal that will include all of the information about > the > > upgrade (from the OpenLDAP Upstream guide)? And hope that they will read > it > > before the package upgrade? Is there any other way to notify them during > > 'dnf update'? > > One way to deal with this, if you create a compat package, is to > provide the 2.4 slapcat tool that is needed to perform the database > conversion. Then create an UPGRADE file with pointers in it to the > relevant documentation and *copy* it to the config directory (or > somwhere appropriate) in the pre-upgrade script if the package we are > upgrading to is from < 2.5 version. > Then add a check in the systemd unit file that will *prevent* the > server from being started if that file is present. > > Inside the file the last instruction will be to delete the file. > > This means the upgrade will not be seamless as the ldap server will not > restart until manually fixed, but at least it will be manageable by > admins. > > > Please, share any of your thoughts on this issue. I'll come to a decision > > sometime soon as we need to get OpenLDAP 2.5 at least in some state to > the > > Fedora Rawhide so it can be properly tested. > > > > Thank you for all of your great work on our awesome Fedora! > > > > Sincerely, > > Simon > > > > P.S. the PR for 2.5 change was filed by a community member and we already > > have some discussion there - > > https://src.fedoraproject.org/rpms/openldap/pull-request/6 > > Thanks for bringing this up, I do not envy the position you are in, > hairy upgrades are hairy. > > Have you checked if debian or any other distro already have something. > We may want to look at other people's clever ideas, and if good it may > make sense to align so we have similar way to handle upgrades and users > using multiple distributions will find it easier. > Currently, there are no other major distros that released OpenLDAP 2.5 fully and stable. Debian and Ubuntu have it in experimental. Also, Ubuntu has an article for the migration and it involves preinstallation config backup and manual steps afterwards: https://discourse.ubuntu.com/t/service-migrating-from-openldap-2-4-x-to-2-5-x/23807 And Gentoo has a similar way: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-nds/openldap/openldap-2.5.4.ebuild#n258 I think your idea with a check in systemd unit file is very good and it goes aligned with other implementations. Also, slapcat is provided with openldap-servers package so the user will be able to run it on their DB and migrate it to MDB. (of course, I'll test it to make sure that everything is fully working) I'll wait a bit before posting the Change Proposal, in case somebody would like to give more feedback on the idea. Thank you! Simon HTH, > Simo. > > > _______________________________________________ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
