User and group not deleted on virtual server deletion

When deleting a virtual server, its administrative user and group don't get deleted, although the confirmation message says they will. As an effect, when trying to recreate a virtual server with the same name, creation fails due to already existant user (and group).



Are users and groups on your system stored in regular files like /etc/passwd and /etc/group , or in a separate LDAP database?

In regular files, I manually deleted them with deluser and delgroup and can recreate the virtual server.

That is very unusual - does this happen every time you create and then delete a domain?

Yes, it happens every time, but I just realized there was an error in the delete report that I didn't notice before:

.. Administration user failed! : Failed to query Postfix config command to get the current value of parameter home_mailbox: at ../ line 1376.

Actually I uninstalled Postfix from my system, because I needed to replace it with ssmtp. After changing "Mail server to configure" in "System Settings => Virtualmin Configuration" to "sendmail" it looked like everything was working without Postfix, but didn't notice this was still caused by its absence.

I don't know if I have to change something else to be able to work without Postfix, or if Virtualmin is not really designed to work without it. In this case, I guess this is not really a bug (or at least the issue title should be different).

Virtualmin should work fine with either Sendmail or Postfix.

If you go to System Settings -> Re-Check Configuration, does it report any errors detecting the mail server?

No, there's no error during Re-Check Configuration (there's no message about mail server at all). I tried again to create and delete a virtual server, and the problem is still the same.

Could you add the line error_stack=1 to /etc/webmin/config , and then re-try deleting a domain, and post the full error message?

I added that option but I can see no extra information on the Postfix error message while creating a domain, only that line I pasted in the previous post.

I can see error_stack is working, because if I try to readd the domain, and get the error about the already existant user, that one has the stack trace.

Anyway I'll try to replicate the steps I did with this installation on a virtual machine, and see if I can reproduce the error.

It look like I can't reproduce the error on a different server... after uninstalling Postfix and changing the mail server in virtualmin configuration everything seems to work and no other call to Postfix is made...

I tried to check everything and the configuration looks exactly the same...

I also tried to change back and forth the mail server setting (an re-checking configuration) on the server which has the error, and it's still there.

I found something that might be linked to the error. In the production server, checking under Webmin -> Webmin Configuration -> Sending Email, Local Mail Server is still "Postfix" (even if Postfix is uninstalled and Virtualmin is configured to use Sendmail), while in the virtual test server the Local Mail Server had been actually changed to Sendmail.

That appears to be because in the production server I disabled the "Mail for domain" feature for Virtualmin before changing the mail server in the Virtualmin Configuration. It looks like changing the mail server for Virtualmin while the feature is disabled results in Webmin not changing accordingly.

Still, I managed to get in the same situation in the test server by: - uninstalling ssmtp and reinstalling Postfix - reenabling Mail for domain - setting Virtualmin to use Postfix - uninstalling Postfix and reinstalling ssmtp - disabling Mail for domain - setting Virtualmin to use Sendmail

Now I can get Webmin Configuration to still display "Postfix" as Local Mail Server also on the test server... but the virtual server deletion still works without any error!

I will try again to reproduce it on another fresh install tomorrow.

Ok, let me know.

If you can re-produce this, I'd be interested in logging into a system that is having the problem so I can debug the underlying issue.