on 20.1.8_1
TL;DR:
lines 386 and 387 in system_usermanager.php should be flipped
(create unix system user before changing its group settings)
--------------------
long story:
In System / Access / Users (system_usermanager.php), adding a new user
with activated entries in "Group Memberships" fails to add the
corresponding new unix system user to the respective unix system group
in /etc/group.
To remedy this, you would need to remove group membership in the GUI,
"Save", add group membership again, "Save".
Calls to "local_user_set_groups()" and "local_user_set()" in
system_usermanager.php apparently have the wrong order, trying to modify
group settings for the unix system user before it even exists:
/usr/local/www/system_usermanager.php:
36 function get_user_privdesc(& $user)
...
386 local_user_set_groups($userent, $pconfig['groups']);
387 local_user_set($userent);
388 write_config();
If the user has not existed before, this results in an error message in
/var/log/system.log:
Jul 22 17:22:42 opnsense1 opnsense: /system_usermanager.php: The command '/usr/sbin/pw 'groupmod' 'admins' -g '1999' -M '0,2000,2006,2007,2010,2011,2012,2014,2015,2016'' returned exit code '67', the output was 'pw: user `2016' does not exist'
In a HA config, this bug is _not_ propagated to slave firewalls, they
will do the right thing:
master, wrong group settings:
root@opnsense1:~ # grep testuser9 /etc/passwd /etc/group
/etc/passwd:testuser9:*:2016:65534:testuser9:/home/testuser9:/bin/sh
slave, correct group settings:
root@opnsense2:~ # grep testuser9 /etc/passwd /etc/group
/etc/passwd:testuser9:*:2016:0:testuser9:/home/testuser9:/bin/sh
/etc/group:admins:*:1999:root,mfedv,testuser9
Flipping lines 386 and 387 in system_usermanager.php is sufficient to
get the unix system user added to the right group in /etc/group the
first time.
Note however that in the special case of the "admins" group, the "gid"
field in /etc/passwd still has different values on master node
(nobody=65534) and slave node (wheel=0).
Hitting "Save" again on master node (even with no modifications at all)
then brings the "gid" to 0 on the master node, too.
Not sure though if gid="wheel" is needed/warranted, I have been using
(GUI) group "admins" ssh accounts on cluster nodes with different gid
settings for some time and have not noticed any difference in behaviour.
Regards
Matthias Ferdinand