Bug#981088: pacemaker: crm shell can't be executed due to a library error
I'm dropping the bug submitter from CC because I believe the discussion is no
longer relevant for him.
Am Freitag, den 26.03.2021, 21:08 +0100 schrieb wf...@niif.hu:
> Markus Koschany writes:
[...]
> > Yes, exactly. There should be a versioned dependency on
> > pacemaker-cli-utils.
>
> What kind of versioned dependency? What's your source? I don't
> maintain crmsh, so I'm not familiar with its requirements.
One could add a versioned dependency like that
pacemaker-cli-utils (>= 1.1.24-0+deb9u1) and then tighten this version to
whatever version is the latest for each distribution. Since you are not the
maintainer of crmsh, this is a bit inconvenient to maintain and there is a
better solution.
> I wonder if pacemaker Recommending the same version of
> pacemaker-cli-utils would have helped here... probably not.
> Switching to Depends isn't unreasonable, but not compelling either.
You could change the Recommends to pacemaker-cli-utils (= ${source:Version})
which would have prevented the problem. This is probably the simplest solution.
>
> > Pacemaker works fine, there was just a corner case when some packages
> > were put on hold hence my suggestion to tighten the dependency.
>
> You needn't put anything on hold to reproduce this problem. Just
> install pacemaker-cli-utils from stretch, then upgrade libpe-status10
> from stretch-security, and crm_mon can't start anymore. Surely it isn't
> a common scenario, and any affected users are probably past this by now,
> but this is the gist of the problem. We may leave it at there, though.
This scenario is unrealistic because you would install pacemaker-cli-utils also
from stretch-security because of the pinning priority. Under normal conditions
an upgrade of pacemaker would pull in all needed dependencies in Stretch. As I
said the problem here was that dependencies were intentionally put on hold by
the bug submitter.
> > We usually don't change package names in oldstable releases. In this
> > case there were no other reverse-dependencies which had to be
> > rebuilt. If there were any we would just rebuilt affected packages.
>
> I see. This still risks breaking software built by the user, because it
> violates Policy 8.1: "The run-time shared library must be placed in a
> package whose name changes whenever the SONAME of the shared library
> changes."
Stretch is a LTS release now and we have to weigh our options. Normally we
don't upgrade packages to the latest upstream release but try to find targeted
fixes. This didn't work in case of pacemaker. Next we try to assess how
disrupting a new upstream release would be and if the security fixes outweigh
possible regressions. In this case it was more important to fix the security
vulnerabilities in pacemaker. Changing the package name was not really
necessary because there are no reverse-dependencies. All those libraries are
part of the same source package.
> Anyway, we have to find out if there's anything to do here.
I don't think there is anything to do in Stretch for now.
Regards,
Markus
signature.asc
Description: This is a digitally signed message part
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Markus Koschany writes: > Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu: > >> Thorsten Rehm writes: >> >>> In my opinion the crmsh package should be more strict with the >>> pacemaker-cli-utils package >> >> Sorry for not looking into this sooner. What do you mean by being >> "more strict"? Does crmsh require a specific version of >> pacemaker-cli-utils to function correctly? > > Yes, exactly. There should be a versioned dependency on > pacemaker-cli-utils. What kind of versioned dependency? What's your source? I don't maintain crmsh, so I'm not familiar with its requirements. >> While that's possible, I don't think it has anything to do with your >> problem, which is that crm_mon requires the libpe_status.so.10 shared >> library, but that is not provided by the 1.1.24-0+deb9u1 version of >> libpe-status10. Because it switched to providing libpe_status.so.16 >> instead. The library changed SONAME, but the package name did not >> change, which is forbidden. The same applies to libpengine10. >> >> Markus, I know introducing new packages through the security channel >> is highly unusual, but is it entirely impossible? Or can you >> recommend some other solution? > > In my opinion this issue has been resolved in Stretch. It's up to you > if you want to tighten the dependency on pacemaker-cli-utils in > unstable releases but we don't need to change that in Stretch right > now. I wonder if pacemaker Recommending the same version of pacemaker-cli-utils would have helped here... probably not. Switching to Depends isn't unreasonable, but not compelling either. > Pacemaker works fine, there was just a corner case when some packages > were put on hold hence my suggestion to tighten the dependency. You needn't put anything on hold to reproduce this problem. Just install pacemaker-cli-utils from stretch, then upgrade libpe-status10 from stretch-security, and crm_mon can't start anymore. Surely it isn't a common scenario, and any affected users are probably past this by now, but this is the gist of the problem. We may leave it at there, though. > We usually don't change package names in oldstable releases. In this > case there were no other reverse-dependencies which had to be > rebuilt. If there were any we would just rebuilt affected packages. I see. This still risks breaking software built by the user, because it violates Policy 8.1: "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes." Anyway, we have to find out if there's anything to do here. -- Thanks, Feri
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hello Feri, Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu: > Control: reassign -1 libpe-status10 1.1.24-0+deb9u1 > Control: severity -1 serious > > Thorsten Rehm writes: > > > In my opinion the crmsh package should be more strict with the > > pacemaker-cli-utils package > > Sorry for not looking into this sooner. What do you mean by being "more > strict"? Does crmsh require a specific version of pacemaker-cli-utils > to function correctly? Yes, exactly. There should be a versioned dependency on pacemaker-cli-utils. > > While that's possible, I don't think it has anything to do with your > problem, which is that crm_mon requires the libpe_status.so.10 shared > library, but that is not provided by the 1.1.24-0+deb9u1 version of > libpe-status10. Because it switched to providing libpe_status.so.16 > instead. The library changed SONAME, but the package name did not > change, which is forbidden. The same applies to libpengine10. > > Markus, I know introducing new packages through the security channel is > highly unusual, but is it entirely impossible? Or can you recommend > some other solution? In my opinion this issue has been resolved in Stretch. It's up to you if you want to tighten the dependency on pacemaker-cli-utils in unstable releases but we don't need to change that in Stretch right now. Pacemaker works fine, there was just a corner case when some packages were put on hold hence my suggestion to tighten the dependency. We usually don't change package names in oldstable releases. In this case there were no other reverse-dependencies which had to be rebuilt. If there were any we would just rebuilt affected packages. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Control: reassign -1 libpe-status10 1.1.24-0+deb9u1 Control: severity -1 serious Thorsten Rehm writes: > In my opinion the crmsh package should be more strict with the > pacemaker-cli-utils package Sorry for not looking into this sooner. What do you mean by being "more strict"? Does crmsh require a specific version of pacemaker-cli-utils to function correctly? While that's possible, I don't think it has anything to do with your problem, which is that crm_mon requires the libpe_status.so.10 shared library, but that is not provided by the 1.1.24-0+deb9u1 version of libpe-status10. Because it switched to providing libpe_status.so.16 instead. The library changed SONAME, but the package name did not change, which is forbidden. The same applies to libpengine10. Markus, I know introducing new packages through the security channel is highly unusual, but is it entirely impossible? Or can you recommend some other solution? -- Thanks, Feri
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hi Markus, thanks for the hint about holding and pinning packages. We're aware of that and did exactly the pinning variant for the pacemaker packages, after the broken release ;-) In my opinion the crmsh package should be more strict with the pacemaker-cli-utils package, if this is a possible option. There is always an alternative for crmsh, the pcs package. Maybe that's the reason why the pacemaker package is not so strict with the cli package. But that is beyond my knowledge. Thank you for the support and the update of the package to the current version. Best regards, Thorsten On Thu, 28 Jan 2021 at 18:50, Markus Koschany wrote: > > Hello Thorsten, > > Am Donnerstag, den 28.01.2021, 14:52 +0100 schrieb Thorsten Rehm: > > Hi Markus, > > > > thank you for your reply. > > I've installed a fresh Debian Stretch and I think I know why I had > > such a problem. I believe it's a dependency problem, but I let you > > decide, if this is the case. > > We're always installing the packages "pacemaker" and "crmsh" on our > > systems. As you know, the latter one has a dependency to the > > "pacemaker-cli-utils" package: > > [...] > > Indeed the problem could have been avoided if either the pacemaker-cli-utils > dependency of crmsh or the Recommends: pacemaker-cli-utils in pacemaker was > more strict. However the general issue here is that you instruct apt to > install > specific packages instead of upgrading the existing ones. If your policy > forbids upgrades then I suggest to mark packages you don't want to upgrade as > "on hold" or use apt pinning to change the priority of your packages. Then you > could still use the upgrade command for the remaining packages. I recommend to > install security updates though unless you are absolutely sure your > systems/configurations are not affected. I leave it to the maintainer of > pacemaker if he wants to tighten the Recommends of pacemaker-cli-utils in the > future. > > Regards, > > Markus
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hello Thorsten, Am Donnerstag, den 28.01.2021, 14:52 +0100 schrieb Thorsten Rehm: > Hi Markus, > > thank you for your reply. > I've installed a fresh Debian Stretch and I think I know why I had > such a problem. I believe it's a dependency problem, but I let you > decide, if this is the case. > We're always installing the packages "pacemaker" and "crmsh" on our > systems. As you know, the latter one has a dependency to the > "pacemaker-cli-utils" package: [...] Indeed the problem could have been avoided if either the pacemaker-cli-utils dependency of crmsh or the Recommends: pacemaker-cli-utils in pacemaker was more strict. However the general issue here is that you instruct apt to install specific packages instead of upgrading the existing ones. If your policy forbids upgrades then I suggest to mark packages you don't want to upgrade as "on hold" or use apt pinning to change the priority of your packages. Then you could still use the upgrade command for the remaining packages. I recommend to install security updates though unless you are absolutely sure your systems/configurations are not affected. I leave it to the maintainer of pacemaker if he wants to tighten the Recommends of pacemaker-cli-utils in the future. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hi Markus, thank you for your reply. I've installed a fresh Debian Stretch and I think I know why I had such a problem. I believe it's a dependency problem, but I let you decide, if this is the case. We're always installing the packages "pacemaker" and "crmsh" on our systems. As you know, the latter one has a dependency to the "pacemaker-cli-utils" package: $ apt-cache depends pacemaker | grep pacemaker-cli-utils Breaks: pacemaker-cli-utils Recommends: pacemaker-cli-utils Replaces: pacemaker-cli-utils $ apt-cache depends crmsh | grep pacemaker-cli-utils Depends: pacemaker-cli-utils This is the reason why we have the "pacemaker-cli-utils" package on our systems. We didn't install it manually, it was installed due to the dependency. So far so good. After you provided the new package of pacemaker, I did the following: $ apt install pacemaker crmsh This will update the two packages to the new version, but it will not update the package "pacemaker-cli-utils", but as you pointed out correctly, the new version of this package is needed as well. It could be, that I'm not fully understand the dependencies of packages, but in my humble opinion: If the "crmsh" package needs the "pacemaker-cli-utils" package and installs it in the first place due to the dependency, it should also update the dependency package if it needs the newer version. Why not use "apt upgrade" and update all packages? We have some company policies with an approval process to update our systems including a maintenance window. I didn't want to just update all non related packages to "hotfix" the pacemaker problem. Why not "apt install pacemaker crmsh pacemaker-cli-utils"? This didn't come to my mind in the first place, because we do not install the pacemaker-cli-utils package as mentioned before. But this fixes the issue of course. In detail, a system with the pacemaker 1.1.16-1+deb9u2 Package installed: $ apt-cache policy pacemaker crmsh pacemaker-cli-utils | grep -B1 -E "Installed|Candidate" pacemaker: Installed: 1.1.16-1+deb9u2 Candidate: 1.1.24-0+deb9u1 -- crmsh: Installed: 2.3.2-4 Candidate: 2.3.2-4+deb9u1 -- pacemaker-cli-utils: Installed: 1.1.16-1+deb9u2 Candidate: 1.1.24-0+deb9u1 $ apt install pacemaker crmsh Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libcib4 libcrmcluster4 libcrmcommon3 libcrmservice3 liblrmd1 libpe-rules2 libpe-status10 libpengine10 libstonithd2 libtransitioner2 Recommended packages: fence-agents The following packages will be upgraded: crmsh libcib4 libcrmcluster4 libcrmcommon3 libcrmservice3 liblrmd1 libpe-rules2 libpe-status10 libpengine10 libstonithd2 libtransitioner2 pacemaker 12 upgraded, 0 newly installed, 0 to remove and 11 not upgraded. Need to get 0 B/2,299 kB of archives. After this operation, 241 kB of additional disk space will be used. Do you want to continue? [Y/n] [...] $ apt-cache policy pacemaker crmsh pacemaker-cli-utils | grep -B1 -E "Installed|Candidate" pacemaker: Installed: 1.1.24-0+deb9u1 Candidate: 1.1.24-0+deb9u1 -- crmsh: Installed: 2.3.2-4+deb9u1 Candidate: 2.3.2-4+deb9u1 -- pacemaker-cli-utils: Installed: 1.1.16-1+deb9u2 Candidate: 1.1.24-0+deb9u1 $ crm_mon --version crm_mon: error while loading shared libraries: libpe_status.so.10: cannot open shared object file: No such file or directory $ apt install pacemaker-cli-utils Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: pacemaker-cli-utils 1 upgraded, 0 newly installed, 0 to remove and 10 not upgraded. Need to get 0 B/250 kB of archives. [...] $ crm_mon --version Pacemaker 1.1.24 Written by Andrew Beekhof Best regards, Thosten On Thu, 28 Jan 2021 at 00:26, Markus Koschany wrote: > > Hello, > > On Tue, 26 Jan 2021 08:24:19 +0100 Thorsten Rehm > wrote: > > Package: pacemaker > > Version: 1.1.24-0+deb9u1 > > Severity: normal > > > > Dear Maintainer, > > > > thank you for the effort and the update. > > Unfortunately there are still some problems with the updated version. > > > > I've just updated the pacemaker package from 1.1.16-1+deb9u2 to > > 1.1.24-0+deb9u1. Afterwards parts of the Cluster Resource Manager > > (crm) can't be executed due to a library error. TL;DR: > > libpe_status.so.10 != libpe_status.so.16 and libpengine.so.10 != > > libpengine.so.16 > > This can't be possible. You need to upgrade not only pacemaker but also all of > its dependencies. They are all part of the same source package. I have > tightened those dependencies explicitly. On my system crm_mon --version works > as expected. The command is part of the package pacemaker-cli-utils. > > Regards, > > Markus > > > > >
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hello, On Tue, 26 Jan 2021 08:24:19 +0100 Thorsten Rehm wrote: > Package: pacemaker > Version: 1.1.24-0+deb9u1 > Severity: normal > > Dear Maintainer, > > thank you for the effort and the update. > Unfortunately there are still some problems with the updated version. > > I've just updated the pacemaker package from 1.1.16-1+deb9u2 to > 1.1.24-0+deb9u1. Afterwards parts of the Cluster Resource Manager > (crm) can't be executed due to a library error. TL;DR: > libpe_status.so.10 != libpe_status.so.16 and libpengine.so.10 != > libpengine.so.16 This can't be possible. You need to upgrade not only pacemaker but also all of its dependencies. They are all part of the same source package. I have tightened those dependencies explicitly. On my system crm_mon --version works as expected. The command is part of the package pacemaker-cli-utils. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Package: pacemaker Version: 1.1.24-0+deb9u1 Severity: normal Dear Maintainer, thank you for the effort and the update. Unfortunately there are still some problems with the updated version. I've just updated the pacemaker package from 1.1.16-1+deb9u2 to 1.1.24-0+deb9u1. Afterwards parts of the Cluster Resource Manager (crm) can't be executed due to a library error. TL;DR: libpe_status.so.10 != libpe_status.so.16 and libpengine.so.10 != libpengine.so.16 In Detail: $ /usr/sbin/crm_mon --version Pacemaker 1.1.16 Written by Andrew Beekhof $ apt policy pacemaker pacemaker: Installed: 1.1.16-1+deb9u2 Candidate: 1.1.24-0+deb9u1 [...] $ apt install pacemaker [...] The following packages will be upgraded: libcib4 libcrmcluster4 libcrmcommon3 libcrmservice3 liblrmd1 libpe-rules2 libpe-status10 libpengine10 libstonithd2 libtransitioner2 pacemaker [...] $ apt policy pacemaker pacemaker: Installed: 1.1.24-0+deb9u1 Candidate: 1.1.24-0+deb9u1 [...] $ crm_mon --version crm_mon: error while loading shared libraries: libpe_status.so.10: cannot open shared object file: No such file or directory $ crm status /usr/sbin/crm_mon: error while loading shared libraries: libpe_status.so.10: cannot open shared object file: No such file or directory /usr/sbin/crm_mon: error while loading shared libraries: libpe_status.so.10: cannot open shared object file: No such file or directory ERROR: status: crm_mon (rc=127): $ ldd /usr/sbin/crm_mon | grep "not found" libpe_status.so.10 => not found libpengine.so.10 => not found $ dpkg -L libpe-status10 | grep so /usr/lib/x86_64-linux-gnu/libpe_status.so.16.1.0 /usr/lib/x86_64-linux-gnu/libpe_status.so.16 $ dpkg -L libpengine10 | grep so /usr/lib/x86_64-linux-gnu/libpengine.so.16.1.0 /usr/lib/x86_64-linux-gnu/libpengine.so.16 Can you please investigate again? I've already made a reply to bug #974563, but I've realized only after it's resolved. Thank you. Best regards, Thorsten Rehm -- System Information: Debian Release: 9.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-14-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pacemaker depends on: ii corosync 2.4.2-3+deb9u1 ii dbus 1.10.32-0+deb9u1 ii init-system-helpers1.48 ii libc6 2.24-11+deb9u4 ii libcfg62.4.2-3+deb9u1 ii libcib41.1.16-1+deb9u2 ii libcmap4 2.4.2-3+deb9u1 ii libcorosync-common42.4.2-3+deb9u1 ii libcpg42.4.2-3+deb9u1 ii libcrmcluster4 1.1.16-1+deb9u2 ii libcrmcommon3 1.1.16-1+deb9u2 ii libcrmservice3 1.1.16-1+deb9u2 ii libglib2.0-0 2.50.3-2+deb9u2 ii libgnutls303.5.8-5+deb9u5 ii liblrmd1 1.1.16-1+deb9u2 ii libpam0g 1.1.8-3.6 ii libpe-rules2 1.1.16-1+deb9u2 ii libpe-status10 1.1.16-1+deb9u2 ii libpengine10 1.1.16-1+deb9u2 ii libqb0 1.0.1-1 ii libquorum5 2.4.2-3+deb9u1 ii libstonithd2 1.1.16-1+deb9u2 ii libtransitioner2 1.1.16-1+deb9u2 ii lsb-base 9.20161125 ii pacemaker-common 1.1.16-1+deb9u2 ii pacemaker-resource-agents 1.1.16-1+deb9u2 ii perl 5.24.1-3+deb9u7 Versions of packages pacemaker recommends: pn fence-agents ii pacemaker-cli-utils 1.1.16-1+deb9u2 Versions of packages pacemaker suggests: ii cluster-glue 1.0.12-5 ii crmsh 2.3.2-4 -- no debconf information
