When restoring backups to a latest/fresh Virtualmin system configured to use LDAP, Unix user/group creation is skipped altogether. Debugging the restore/creation process, I found that a wrong comparison operator (== instead of eq for string) is used in feature-unix.pl:25.
virtual-server/feature-unix.pl 22:30
# Check if the UID or GID has been allocated to someone else, and if so
# re-allocate them. Also allocate if they haven't been done yet.
local @allusers = &list_all_users();
local ($uclash) = grep { $_->{'user'} == $_[0]->{'user'} } @allusers;
if ($uclash && &remote_unix() && $_[0]->{'wasmissing'}) {
# Domain is being re-created as part of a restore and users are stored
# remotely, and the user already exists. Assume shared LDAP storage.
goto QUOTAS;
}
This causes $uclash to populate with a wrong match, and results in assuming that "the user already exists" when remote_unix() is also true.
This bug is not visible when LDAP is not used. In that case, remote_unix() evaluates to false and the code continues to work with proper creation of Unix user/group.
Suggested fix is to use "eq" instead of "==" for username comparison:
local ($uclash) = grep { $->{'user'} eq $[0]->{'user'} } @allusers;
Status:
Closed (fixed)
Comments
Submitted by JamieCameron on Wed, 11/28/2018 - 22:21 Comment #1
Thanks! I will include this in the next Virtualmin release.
Submitted by IssueBot on Thu, 02/28/2019 - 09:07 Comment #2
Automatically closed - issue fixed for 2 weeks with no activity.