Bug #6468: When we install rudder-agent after having removing it, the uuid is not restored on RPM-based systems - Rudder - Issue Tracker

Subject changed from When we install rudder-agent after having purged it, the uuid is not restored to When we install rudder-agent after having removing it, the uuid is not restored

Nicolas CHARLES wrote:

After purging rudder-agent, and reinstalling it, the uuid is not restored, which completely defeat the idea of backuping it.

At least on 3.0, but probably in 2.10

There is a vocabulary confusion here: if we are purging a package (apt-get purge), then this is the expected behaviour.

If we did not, but we just removed the package, then this file should indeed be restored. According to #7901 this works.

It needs testing again to confirm.

Actions

Copy link

#14

Updated by Jonathan CLARKE over 8 years ago

Related to Bug #7901: Backup and restore policy_server.dat like we do with uuid.hive file added

Actions

Copy link

#15

Updated by Jonathan CLARKE over 8 years ago

Assignee changed from Matthieu CERDA to François ARMAND

Actions

Copy link

#16

Updated by François ARMAND over 8 years ago

Translation missing: en.field_tag_list set to Next minor release
Assignee changed from François ARMAND to Benoît PECCATTE
Target version changed from 3.0.16 to 2.11.21
How to reproduce updated (diff)

Validated: with a simple remove / install, the uuid is not restored on centos6/7.

The behaviour is consistent on debian: apt-get remove / install => uuid.hive restored ; apt-get purge / install => new uuid.hive.

Actions

Copy link

#17

Updated by François ARMAND over 8 years ago

Priority changed from N/A to 2

This is not a big problem, but it is a non-consistence between package, so a maintenance nightmare in the future (so the next minor).

Actions

Copy link

#18

Updated by Jonathan CLARKE over 8 years ago

Subject changed from When we install rudder-agent after having removing it, the uuid is not restored to When we install rudder-agent after having removing it, the uuid is not restored on RPM-based systems

This is indeed implemented very differently in RPM and debian packages in all released versions:

In RPM packages, the postinst will always generate a new UUID, see https://github.com/Normation/rudder-packages/blob/branches/rudder/3.1/rudder-agent/SPECS/rudder-agent.spec#L538
In deb package, the postinst never generates a new UUID, it just runs check-rudder-agent to do that job, and that script will restore a backup if there is one available and only generate a new UUID if not. See https://github.com/Normation/rudder-packages/blob/branches/rudder/3.1/rudder-agent/debian/postinst#L173

However, in master (future 3.3/4.0), this behaviour has been harmonised and all platforms use the approach currently in RPM packages. This actually duplicates the code from check-rudder-agent.

I believe the correct solution here is therefore to follow the deb package approach, and always call check-rudder-agent at the end of postinst to restore existing UUID or create a new one if necessary.

Actions

Copy link

#19