Usermin does not respond

I am setting up Virtualmin for a new server, and after creating a site, I cannot seem to be able to get a user to successfully login to Usermin. The login page is available, but after entering a username and password, no response is ever received from Usermin. The new session appears as a currently logged in session in Usermin Configuration, although no pages are ever sent to the user's browser.

How can we diagnose this problem and resolve it?

(BTW, I imagine this support request should have been filed under a the "Usermin Core" project, but your support system will not allow that as no "components" have been defined for it!)

Closed (fixed)


Joe's picture
Submitted by Joe on Mon, 06/08/2009 - 18:13 Pro Licensee

Is there anything in the Usermin logs? They're usually in /var/usermin.

Also, what browser are you using?

I've tested it with both Firefox and IE; neither work. However, I don't think that's the issue. I did discover that /etc/aliases.db did not exist; a "newaliases" command seems to have remedied that.

I don't know if you recall, but this is a FreeBSD box, and it had required some manual configuration to get Dovecot working properly. Although Vitrualmin says Dovecot and Postfix are configured and working, I'm not 100% convinced. Perhaps Postfix needs some additional setup.

Looking in /var/usermin, there are definite errors recorded miniserv.error...

[08/Jun/2009:17:30:19 -0400] started
[08/Jun/2009:17:30:19 -0400] Perl module Authen::PAM needed for PAM is not installed : Can't locate Authen/ in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9 .) at (eval 10) line 1.
BEGIN failed--compilation aborted at (eval 10) line 1.
[08/Jun/2009:17:30:19 -0400] Continuing without the Authen::PAM perl module

It would appear that the p5-Authen-PAM port needs to be installed. I installed it, which seems to have eliminated that error.

Unfortunately, Usermin logins still do not work.

Where else do we look?

This may be related...

/var/log/maillog shows a problem with the dovecot ssl certificate...

Jun  8 20:29:26 <mail.crit> new dovecot: Fatal: imap-login: Can't load private key file /etc/ssl/certs/dovecot.pem: error:0906D06C:PEM routines:PEM_read_bio:no start line
Jun  8 20:29:26 <mail.crit> new dovecot: Fatal: pop3-login: Can't load private key file /etc/ssl/certs/dovecot.pem: error:0906D06C:PEM routines:PEM_read_bio:no start line

Not sure if that would prevent a Usermin login, but I imagine it needs to be fixed anyway....didn't see any easy spot in Virtualmin to manage that...I guess I'll have to look into this one now...

(Suggestions always welcome :-)


I recreated the dovecot ssl cert and key files using dovecot's script (and updating their dovecot-openssl.cnf file as necessary). That did not work. However, changing the key to non encrypted might have resolved some problems. Obviously, I'd rather use an encrypted key file for the SSL certificate, but if this will get it to work for now, I can research this later. (Eventually, I'd like to use my Geotrust signed certificate for SSL, but that's tied to my old server until I complete the migration).

It looks like users can now login to Usermin.

However, mail is still being rejected.

This is obviously very frustrating.

What error message are you getting when mail is being rejected? I presume you mean mail sent using Usermin?

Also, what gets logged to /var/log/mail* when mail is rejected?

The mail rejection problem was at the SMTP level, when sending email from an outside system to the new system. However, that turned out to be an unrelated DNS issue, which I resolved.

Unfortunately, mail is still not being received from an outside system. When an email is sent, it does appear to be received, as the following lines in /var/log/maillog seem to show (if I'm understanding them correctly)...

Jun  9 07:55:35 <> new postfix/smtp[29381]: D587ADB94B8: to=<>, orig_to=<>,[]:25, delay=86, delays=0.04/0.01/86/0.07, dsn=2.0.0, status=sent (250 ok 1244548418 qp 5120)
Jun  9 07:55:35 <> new postfix/qmgr[9252]: D587ADB94B8: removed

Unfortunately, the mail does not appear to be going into the Mailbox. In fact, I have no idea what was done with that email.

Checking the Virtualmin "Search Mail Log" option, results in "No messages matched your search", even when a search is done for any domain.

Something appears to be definitely wrong with Postfix SMTP configuration. Since I did have to manually setup the Dovecot config file for this system ( didn't work completely), is it possible that similar steps need to be done for Postfix? What settings are needed?

Is your system? According to the mail logs you posted, it looks like the message was received by that system ..

I recently notice that as well. For some unknown reason, it appears to be relaying the mail to our old server. is our old server, which obviously must remain running until the new system is fully functional and tested.

For this test domain (, I can see no reason why it would have relayed the mail. The DNS for is as follows:

$ttl 38400
@       IN      SOA (
                        38400 )
@       IN      NS
@       IN      NS       IN      A   IN      A   IN      A     IN      A     IN      A       IN      A IN      A  IN      A       IN      MX      5       IN      TXT     "v=spf1 a mx ip4: ~all"

I do not see any references at all to (the old server), so I do not understand why postfix on this system is attempting to relay the mail.

I also see a couple of other unusual items... (1) The TTL value for the zone is quite high (38400) even though I had thought I set it to 600. I cannot seem to find any location in Virtualmin to set 600 as the default TTL value. How can I set this? (2) Do you know why Virtualmin created an "" DNS record? What is the purpose of that?

So is the IP of the old system, or the new?

Also, what is the output of the command following command run on the new system :

host is the new system (as is .248 and .249) is the old system (.240-.246 will be moved to new system when migration is completed)

host has address mail is handled by 5

Looks correct to me. This is baffling.

I wonder if Postfix is caching the old address? Does restarting Postfix help?

Restarting Postfix did not solve the problem. I do agree that it looks like something is being cached.

It appears that the spot in Virtualmin where the default TTL value can be set is the "Negative cache time" field in the DNS BIND Zone Defaults. It seems that this value is the same as the Min TTL value in the SOA record, and is used for the '$TTL' (default TTL value) entry as well. Is this correct?

I created yet another test domain ( This one was previously cleared from my old server so there were no entries which should have been cached at all. It is a domain which was not in use. I added it in Virtualmin and checked all DNS records on the new server. It looks perfect. There is no reference in the DNS information for this domain to the old server at all.

However, postfix still tries to relay mail to! In fact, the new site email was rejected as well.

Clearly, something is wrong with the postfix configuration.

Is there any reference to in any of the Postfix config files under /etc/postfix ? Perhaps it is set up as the default relaying destination for all domains?

I might have an idea as to where the problem is...

I sent a test message to "" I would appear that delivery was attempted to "" (good) I appears to have reached "" (good) Address re-written as "" (at first glance seemed okay...) But this is then relayed to "" because it handles all mail for ""

Is this something that can be easily managed?

The big problem is that I must keep,,, etc. on my old server until I am fully ready to migrate all the domains to the new one. In theory, I should be able to call the new server "" for now, and move all those other names and IPs to it later.

Is my approach to this wrong? Do you have a better migration strategy I should be using? It was my plan to migrate some smaller sites to the new system and fully test them (live) before switching my paying clients who tend to get upset when mail doesn't work.

Running "host" on the new server reveals... has address mail is handled by 10

I thought changing the DNS zone for on the new server would allow me to get the new server to resolve and to the new IP address. It does not.

As far as "", grep reveals no references to it in any files /etc/local/etc/postfix

Perhaps it would be easier if I were to use as the domain for the new server, switching it to when done with the old server. Is that something that could be accomplished easily in Virtualmin?

This may be due to a mismatch between what Postfix thinks your system's hostname is, and what it really is. What does the hostname command output on your system? It should be something new, like ..

Also, in /etc/postfix/ , the mydestination line should contain that hostname as one of the values.

hostname reports ""

mydestination however reports: "$myhostname, localhost.$mydomain, localhost,"

I tried changing that "" in it to "", but it still relays mail!

So far, postfix seems just as frustrating as qmail, which I was looking forward to moving away from.

Did you restart Postfix after making this change?

Also, are there any other references to in

Yes, I restarted postfix. No, no other references to in

Also check the myorigin line .. it should be set to :

myorigin =

Also, what is being logged to the mail log now when you try to send mail?

my origin was "$mydomain"

I'll can change it to ""


I added "" to the mydestination and now it appears to accept mail locally for

Mail seems to be delivered now.

Now, for me to do some testing...

Ok .. let us know how it goes. Sadly, Postfix has some very confusing rules about what it considers to be the local domain.

So far it looks good. Thanks for all your help.

BTW, I have a few miscellaneous questions regarding Virtualmin/Webmin/Usermin, SpamAssassin integration, Squirrelmail integration, etc. I assume I should post these in a separate ticket? Since they're not critical issues (i.e. not problems, just questions), is there a better place to post them than then though this support system?

If they are bugs, a separate ticket would be good. Otherwise, the discussion forums are better ..

Automatically closed -- issue fixed for 2 weeks with no activity.