Re: OpenLDAP 2.5 - Fedora Release - Help Needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 18, 2021 at 5:14 PM Simo Sorce <simo@xxxxxxxxxx> 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@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
> 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@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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux