I restored a virtualmin backup and numerous sites after a fresh install on Centos 5.7 but I cannot connect via SMTP to send mail. I don’t know if there was a way to back up all webmin settings but I did not do that.
Initially when trying to send email Thunderbird would just hang. After creating /etc/postfix/sender_access and postmapping it it would then connect but immediately say the password was wrong and ask for a new one - checking mail was fine though and all passwords are fine. I tinkered with some items in main.cf with no success but restored to original.
Also note this is a dedicated server with no blocked ports from the ISP and no problem exists with firewall disabled
My first errors in the log were:
fatal: open database /etc/postfix/sender_access.db: No such file or directory
warning: process /usr/libexec/postfix/smtpd pid 461 exit status 1
warning: /usr/libexec/postfix/smtpd: bad command startup – throttling
after creating /etc/postfix/sender_access I now get:
But any pertinent info that may have existed in those posts is not longer accessible on this site!!! So can someone chime in and rewrite this solution? I have no idea what it is and have been up for over 30 hours straight and need this thing to work asap.
I had to go to Google to search for posts by me since the search here doesn’t work…
Here is the answer:
It doesn’t look like you have the -r flag enabled… you can add that by editing “/etc/sysconfig/saslauthd”, and changing the FLAGS= line at the end to read: (no quotes btw)
OPTIONS=-r
After setting that, you can restart saslauthd with:
One other thing in there that we may be able to tweak for the better… it looks like Postfix is trying to connect to a service on port 8891, but it doesn’t look like that service is running.
Do you know what that might have been?
If not, you could simply comment out this line in your Postfix config:
non_smtpd_milters = inet:localhost:8891
Or, if you do know what that is, you could install and configure that service.
I think the issue you’re seeing here in this thread is related to your post in the above thread – and rather than spreading out the replies between both threads, I’m going to respond here
I think at least some of what we’re seeing here is a Virtualmin bug.
Certain things that you set in the Server Templates – those should make tweaks to your config files when those are set.
For example, when you specify user@domain for the username format, it knows to add the -r parameter to saslauthd in the config files.
And I think what we’re seeing is a bug, where those config file tweaks aren’t being reset when importing settings from a backup.
According to your other post, it sounds like you were attempting to use DKIM – and it looks like from your logs here that DKIM isn’t running. That sounds like a similar kind of bug.
What we can do is work with Jamie to get this fixed, and make sure it doesn’t happen to you or anyone else again.
In terms of settings you think Virtualmin should be corrected to handle – have you seen issues with more than the just the username format and DKIM settings?
If so, is there any chance you could offer a summary of what settings you had that weren’t properly enabled after importing the Virtualmin config backup?
DKIM was not running or installed upon recovery
Greylisting was not running or installed - I said I lost the data but I am not 100% on that. I’ll try to check.
The settings for the e-mail format at usernames was not configured properly.
I will try to remember if there was anything else. I do not it wasn’t a simple restore and done kind of deal. there was some work to do. I wasn’t upset because frankly it seems such a task would be very difficult…
Thanks again. I will chime in again to let you know if there was anything else.
Hmm not related but I noticed under “scheduled backups” when I scheduled some backups of a group of sites I had inadvertently check some items under “Virtualmin settings to also backup”… I backup virtualmin settings only in a separate backup so I don’t want this. No matter how many times I unclick those check boxes and save they remain when I reload scheduled backups.
So yes this means I restored some virtualmin setting from not only the single virtualmin backup but also apparently each time I restored a site. Keep in mind every backup I restored had been backed up on the same night…