Bug #8450
closed
High Availability Sync / xmlrpc.php removes "remote system username" on backup cluster member
Added by Alex S over 6 years ago.
Updated over 6 years ago.
Description
Two-member cluster:
- Primary: upgraded from 2.4.2-p1 to 2.4.3 using the GUI
- Backup: issue occurs both after an upgrade from 2.4.2-p1 to 2.4.3 using the GUI, as well as after a 2.4.3 clean install + configuration restore.
The php-fpm process running on the backup firewall removes the local user account ("xmlrpcsync") defined for configuration sync.
php-fpm 243 /xmlrpc.php: Removing user: xmlrpcsync
In addition, the "admins" group on the backup firewall is removed as well.
The behaviour is consistent on two pfSense two-node clusters running 2.4.3.
Files
Does the xmlrpcsync user exist on the primary?
I use a custom user (xmlrpc) for this and it survived the upgrade, as well as countless 2.4.3-DEV/BETA/RC upgrades so there might be something peculiar about your config.
I would suggest hashing this out on the forum and if a specific set of steps to duplicate can be found, post them. There has to be more to it than simply upgrading.
No, the xmlrpcsync user does not exist on the primary. However, since the "user manager users and groups" checkbox is not checked on the "configuration synchronisation settings" page, this should not be relevant to this particular scenario, right? FYI, I have created a test user and a test group on the primary, and - as expected - these are not created on the secondary.
Furthermore, the fact that the "admins" group was also removed, and that this behaviour can be duplicated on a fresh install with its configuration restored on two different clusters, has made me believe that this looks like a bug.
I will do some additional checks and report back.
OK now we're getting somewhere. I can confirm that there is something to look at here regarding syncing users from the primary to the secondary when the sync users box is unchecked on the primary. I saw the same as you. The admins group and xmlrpcsync user were deleted on the secondary.
It is unrelated to the upgrade though as simply disabling the sync user manager checkbox and forcing a config sync seems to trigger this when both nodes are already 2.4.3.
- Priority changed from Normal to High
- Target version set to 2.4.4
- Assignee set to Jim Pingle
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Target version changed from 2.4.4 to 2.4.3-p1
Tested on 2.4.4.a.20180507.0753, confirmed resolved.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF