To begin, here are my server’s software and versions:
Operating system
CentOS Linux 7.8.2003
Perl version
5.016003
Path to Perl
/usr/bin/perl
BIND version
9.11
Postfix version
2.10.1
Mail injection command
/usr/lib/sendmail -t
Apache version
2.4.6
PHP versions
7.4.8
Webalizer version
2.23-08
Logrotate version
3.8.6
MySQL version
5.7.31
SpamAssassin version
3.4.0
I can add system level users and FTP works fine (but email logins do not work).
If I add users to any virtual host via VirtualMin for email or FTP access, the system can receive email for that user and I can go look at their mail queue and read the incoming emails.
However, the username.domain login name format appears not to work for either email or FTP, in that login attempts for either using the username.domain login name format fail on bad passwords.
I am using Postfix and Proftpd. Before I had to manually change the inet_interfaces setting in /etc/postfix/main.cf to ‘all’ from its default setting of ‘localhost’, and verified that I had port 25 open for SMTP, I could neither send nor receive email from the system.
Now the mail server can receive email for virtual users, but under no circumstances can the server send anything that isn’t to itself, i.e, within the localhost zone.
And, the username.domain style users cannot log in (but the system level users where the name in the /etc/passwd and /etc/shadow files where the username is expressed as ‘username’ instead of ‘username.domain’ can access FTP just fine.
I have tried other FTP engines. The behavior is the same with respect to FTP logins. This leads me to believe that this is a Webmin/Virtualmin problem, not a system level problem.
I have to get my email running. Anybody have any idea what’s going on?? Other users appear to have this working out of the box. Alas, I am not among them.
To add users to a virtual server, I usually go to Virtualmin → Edit users and then click Add user to this server. Email and FTP works fine for users created in this manner.
What is the process that you are following to create users and why do you need to ‘add system level users’?
As a workaround, because the method you describe does not produce accounts that can log in to either FTP or IMAP.
The result is always a message about an incorrect password, no matter what.
Somehow some critical bit of connective tissue is missing between the virtual host users VirtualMin sets up and the actual services on the host machine.
Have you checked for OOM killer messages in the kernel log? This seems like the kind of mysterious failure that’d come from having random processes being killed by the kernel because of lack of memory, though this specific error is one I’ve literally never seen. I don’t even know what it means, and how it could possibly effect both Dovecot and FTP…unless it means PAM isn’t working (but PAM isn’t a server that needs to be running, so…still doesn’t make sense). The error seems to indicate some dovecot service isn’t running…which would not affect FTP.
Have you tried just rebooting? That should free up all the memory and restart all services.
We’ve got 2.3Gb RAM free on the server host, so running out of RAM isn’t likely to be an issue.
The FTP problem is solved, the server did not know its own host name. We made changes to /etc/hostname and /etc/system/network to fix that problem, and now virtual domain FTP users can log into their FTP accounts just fine with no issues.
So what we had was one problem masking another.
Now it’s just down to Dovecot not authenticating logins properly, and we’re trying to trace that one down. Something to do with the CRAM-MD5 not kicking in as it should.
You need PLAIN passwords to authenticate to PAM. There is no hash type that’s available to mail services that matches Linux system user hashes. Unless you’ve moved users into a dedicated mail user database (LDAP or an SQL database, usually, explicitly configured to store this kind of password).
We were also having a problem where /home/{virtual-domain-owner-account}/public_html/cgi-bin/autodetect.cgi couldn’t be executed because the file was not in the ‘apache’ group and so Apache couldn’t read it to execute it during IMAP login. That’s also fixed.
So now what we’re seeing in the dovecot status is things like this:
The /home/krypton/homes/gene directory exists, and the /home/krypton/homes/gene/mail directory exists.
However, the account’s incoming mail is currently stored in the file /var/spool/mail/gene.krypton.
I think dovecot is looking in the wrong place - yet /home/{virtualdomainowneraccount}/homes/{virtual domain email user} is where VirtualMin is setting up new virtual domain users mail folders.
It shouldn’t need to be. Apache is a member of the domain owner’s group in a default Virtualmin setup.
Wait, what??? That’s completely wrong, too.
Are you sure your installation completed successfully? It looks like your system is simply not finished. Steps are numbered as they run with a running counter (i.e. 11/23), and it looks like at least the last two or three steps simply didn’t run.
I do think I may have screwed up in one major way, in that I looked at the prerequisities for VirtualMin, saw a bunch of the modules, and installed them by hand myself before installing Webmin/Virtualmin, specifically including Postfix and Dovecot.
That may have been a significant mistake, and the documentation does not tell you to have Webmin install the modules itself, so in my defense there was no warning not to do this.
So now, my email client is telling me that the server doesn’t support IMAP4. This is the first time I’ve ever seen an error like that.
Freshly installed is really important…don’t add anything, don’t configure any services, don’t enable any third party repos. Just give it an FQDN and run the install script.
It’s hard enough to start from a known quantity and reliably end up with everything working across a half-dozen distros and versions managing dozens of packages and services. It’s impossible when there could be any variety of customizations done in advance.
Can I recommend you back up anything important and start over with a freshly installed OS and then install Virtualmin? And watch the installation carefully for errors or skipped steps (i.e. if it stops at 20/23, it’s not completed, and you should post about here and I’ll help figure out why). It may be possible to fix this installation, but I’m not going to be able to spend the time going through all of the dozens of things that might be wrong…and even if we do that, it’s likely there will continue to be surprises forever. This is a wildly complicated system and we have no idea how many things are wrong or undone.
I did that in the first place. The documentation was faulty in that it did not mention the fact that it is important for Webmin to install the packages it needs itself instead of doing it manually from the command line before you run Webmin setup. That’s what led to this situation.
And no, I can’t rip the production server apart and do this over from scratch. It’s online, serving a radio stream to the entire planet, plus half a dozen mission critical domains, some of which are our clients’ projects.
At this point I have everything working except Dovecot. FTP now works flawlessly. Mail is being stored in the correct place where VirtualMin expects to see it now, mail is being delivered and it can be read and responded to in UserMin. I’m close to figuring this Dovecot thing out on my own. Failure is not an option.
At the moment the only issues are Dovecot is still being a pain, but the autoconfig.cgi scripts aren’t running because nothing in the cgi-bin directories delivers anything but a 500 error - specifically “End of script output before headers” problem, which suggests that not enough time is being allocated for them to deliver output, regardless of what language the CGI is written in.
We’ve already checked the file permissions for the files in the CGI directories, they’re set to 755, so that’s not it. We’ve already checked to make sure they’re referencing the right runtime interpreters, and they are, and the scripts work from the command line, so that’s not it either. Not being able to access autoconfig.cgi is messing with Thunderbird’s ability to do its setups based on these XML scripts.
Well, the best I can do to help here is point you to the software that does the actual configuration (which is what seems to be incomplete on your system).
That’s the plugins directory, where the actual scripts that do the work are located. If you look through the services that are misbehaving (though I think there are a lot of things misbehaving that you’re unaware of based on the Apache permissions issue above), you can see what was supposed to have happened during install and sort of compare to your existing system.
You could run these things now, but since you’ve since done a bunch of your own config, likely in ways that aren’t quite the way we’d do it, it’s as likely to break things as it is to fix them. The virtualmin config-system command can call these plugins, e.g. to run the Dovecot plugin: virtualmin config-system --include Dovecot
But, since we’re in uncharted waters, there’s no guarantees it’ll do anything good.
I could, for example, archive the Dovecot configs, uninstall it, then run the specific install scripts that handle this for Virtualmin from the config modules. If it makes it worse, I have the archives.