ssm-client upgrades are not working

[gordan-bobic]

Upgrading from pmm-client 1.17.5 to ssm-client 8.8.1.17.5.3 loses client's configuration.

Immediately after the upgrade:

# ssm-admin list
SSM client is not configured, missing config file. Please make sure you have run 'ssm-admin config'.

Configuration should be preserved and migrated.

Additionally, /etc/systemd/system/pmm-linux-metrics-42000.service remains in place after the upgrade, which I don't think it should.

[oblitorum]

Current ssm-client package provides binary pmm-admin along side with ssm-admin, because we want it also works if someone accidently type pmm-admin ... instead of ssm-admin ....

But there is a scriptlet in pmm-client 1.17.5 package:

%preun
# uninstall
if [ "$1" = "0" ]; then
    pmm-admin uninstall
fi

So when doing upgrade from pmm-client to ssm-client, this script will be executed after the binary pmm-admin gets replaced, which makes it same as doing ssm-admin uninstall, and that causes the problem. Surely there is another way to get around this, but not providing the binary pmm-admin is the most straightforward way, could we remove pmm-admin from the ssm-client package?

[gordan-bobic]

Wow, great spot. I'm not sure how we can work around this, if this is in the original pmm-client package - that scriptlet is part of the pmm-client package and will execute - I don't think we can control it from our upgrade package that deprecates it. In other words - I don't think removing pmm-admin alias will fix this because this will execute before ssm-client package is actually installed. Unless I'm mistaken? If pmm-admin doesn't exist, then the %preun scriptlet will fail and the installation/upgrade will fail.

Plan B would be to have an external script / pastable to preserve the config files and then rebuild the config from that.

[oblitorum]

this will execute before ssm-client package is actually installed

No, according to this doc, the %preun of old package runs after the %post of new package, and I can confirm it's in that order.

[gordan-bobic]

Interesting. That is most fortunate, if not what I expected. Do we need to do something like symlink pmm-admin to /bin/true for the %preun to not fail?

[oblitorum]

You mean symlink pmm-admin from the new package? If new package contains pmm-admin, the old pmm-admin gets replaced, thus the new pmm-admin gets executed in %preun. If new package doesn't contain pmm-admin, the old pmm-admin is still present and gets executed in %preun. Either way %preun won't fail.

[gordan-bobic]

Ooo, just had a thought! In ssm-admin - can you add a check for whether it was invoked via pmm-admin name? And in that case, make uninstall do nothing, so that the upgrade process works?

[oblitorum]

Sure, will do that

[gordan-bobic]

You think my idea will work? :grin:

[oblitorum]

Yes, I think so, using condition like argv[0] == "pmm-admin", let's try it out 🙂