I posted a thread about this but think it may be a bug. I first tried it with a fresh CentOS install, but after not being able to send mail, did a fresh install of Ubuntu(/virtualmin) on the server which was sending mail fine.
I've now put CentOS 7 back on, and postfix isn't working on this install either (unable to send mail with ssl):
The server response was: Error: authentication failed: generic failure
Take a look at the config - it seems Virtualmin is creating a problem, look specifically at the lines that start:
smtp inet n - n - - smtpd...
and
smtps inet n - n - - smtpd -o syslog_name=postfix/smtps...
It appears to me that Virtualmin is appending things (as well as repeating some) to the end of these lines that actually need to go onto separate lines? I've tried putting everything on separate lines but to no avail, but maybe something else that is related to this is causing the issue?)
#
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes
#smtp inet n - n - 1 postscreen
#smtpd pass - - n - - smtpd
#dnsblog unix - - n - 0 dnsblog
#tlsproxy unix - - n - 0 tlsproxy
submission inet n - n - - smtpd
# -o syslog_name=postfix/submission
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_reject_unlisted_recipient=no
# -o smtpd_client_restrictions=$mua_client_restrictions
# -o smtpd_helo_restrictions=$mua_helo_restrictions
# -o smtpd_sender_restrictions=$mua_sender_restrictions
# -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
#628 inet n - n - - qmqpd
pickup unix n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
#qmgr unix n - n 300 1 oqmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent. See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
I've put the master.cf file from my older centos 6 server on this install, but still the same issue.
Comments
Submitted by JamieCameron on Fri, 07/17/2015 - 20:36 Comment #1
Are you seeing this when the system receives email, or when email is sent via it by clients?
Also, what exactly gets logged to
/var/log/maillog?Submitted by Brook on Sat, 07/18/2015 - 04:31 Comment #2
Seeing it when email is attempted to be sent by clients.
This went into maillog after trying to send an email:
Submitted by andreychek on Sat, 07/18/2015 - 10:21 Comment #3
It looks like saslauthd is causing some trouble at the moment... can you verify that saslauthd is started?
Submitted by Brook on Sun, 07/19/2015 - 07:26 Comment #4
Hi Eric, I reinstalled the OS and this time it appears to be working - I wonder if the problem with httpd in the other issue had anything to do with it, or the order in which I have set things up. It's very odd as it happened on two installs, and perhaps something you will want to look into to be on the safe side.
I will actually be reinstalling everything on another new CentOS 7 install in the next week or so, so if it happens again I'll let you know.
Submitted by andreychek on Sun, 07/19/2015 - 09:43 Comment #5
I'm glad to hear it's working now!
I'm not sure what would have caused the issues you saw, it seems unlikely that an Apache problem would cause this particular issue.
Out of curiosity, are there any third party repositories that were enabled previously?
Submitted by Brook on Sun, 07/19/2015 - 11:55 Comment #6
No, the only command I ran was yum upgrade (so was running CentOS 7.1) before installing Virtualmin.
However, I am finding the system a bit unstable, and I'm not sure whether that's CentOS 7 or Virtualmin on CentOS 7. For example earlier today the site I currently have on this server stopped resolving, logged in to the server to find httpd was reporting that the document root did not exist - but it did. Restarted the server and it was fine. You're also aware of the other problems I've faced by the numerous issues and threads I have posted.
How are you finding CentOS 7 with Virtualmin? Would you say it is stable enough for production servers? I am currently thinking about going back to CentOS 6 because it has just been so stable - I just need to check whether Docker support it as I think I am going to be adding quite a few more Docker containers in future.
Submitted by andreychek on Sun, 07/19/2015 - 12:16 Comment #7
Well, there's quite a few people using CentOS 7. And we haven't been receiving many reports of problems.
That's making us wonder if there's something unusual or different about your environment.
Are you using a VPS, or a dedicated server there?
Also, what is the output of this command:
ls /etc/yum.repos.dIt's also possible that something recently changed in CentOS that our installer isn't handling correctly, so we do want to make sure there isn't a problem that needs to be fixed.
Submitted by Brook on Sun, 07/19/2015 - 12:35 Comment #8
Hi Eric, here is the output:
CentOS-Base.repo CentOS-CR.repo CentOS-Debuginfo.repo CentOS-fasttrack.repo CentOS-Sources.repo CentOS-Vault.repo epel.repo epel-testing.repo virtualmin.repoIt is the 'minimal' CentOS image that gets installed and it is a dedicated server. If you need any further info just let me know.
Also once I'm done with the server I can probably freshly install CentOS 7 back on it and let you have a play with it for a day if you wanted to take a look? I have the server for another week and am hoping to move all my sites on it, reinstall OS on the old server then move them all back.
Submitted by andreychek on Sun, 07/19/2015 - 13:50 Comment #9
Are you performing the CentOS install yourself, or are you using an image of some kind?
I see that the EPEL repo is enabled -- it's possible that was the cause of the ClamAV issue you were seeing previously. Joe suspects you're ClamAV packages weren't the ones provided by Virtualmin.
Also, the CR, Vault, and Fasttrack repos -- are those something you're enabling? Those don't appear to be on by default in the CentOS installs I've performed.
Submitted by Brook on Sun, 07/19/2015 - 15:07 Comment #10
Hi Eric
It is the image that the datacenter provides (see attached images) I just click on the Linux tab and select the distro I want. Th only thing I do before installing Virtualmin is `yum upgrade`.
In the second image, they say:
[quote]
What changes are made to the distributions?
The standard offered images generally contain no additional or modified drivers or other software (eg. for RAID controllers). The images are updated regularly.
Software
Each image contains software for all available installation options (software RAID and LVM) and file systems (ext2/3/4, reiserfs, xfs).
Boot loader
GRUB2 is the preferred boot loader and is used when it is supported by the operating system tools (like YAST), otherwise GRUB (GRUB legacy) is used. The usage of LILO is no longer supported.
The boot loader configuration is adjusted so that any graphics mode is disabled (nomodeset).
Network
The network configuration is pre-configured so that there are no restrictions. No firewall is enabled by default, but we recommend our users enable one as part of their system setup.
Drives/RAID
If software RAID is used the RAID verification is set to a random time.
Time (NTP/Chrony/systemd-timesyncd)
The configuration is adjusted so that the Hetzner NTP servers are used. The preference is to use systemd-timesyncd if available, as it provides a strict client mode.
Package repositories
Provided that Hetzner has a mirror of the distribution, this gets used by default and is pre-configured, along with another mirror.
[/quote]
Submitted by andreychek on Sun, 07/19/2015 - 15:42 Comment #11
Thanks, you've provided lots of great info!
It sounds like the next step us for me to fire up a new Virtual Machine with CentOS 7, and to see if we see similar results as to what you're seeing.
We can then work from there to determine how best to resolve all that. Thanks for your input!
Submitted by Brook on Sun, 07/19/2015 - 16:37 Comment #12
I also found this Eric:
[quote] Extra Packages for Enterprise Linux (EPEL) - (See http://fedoraproject.org/wiki/EPEL) provides rebuilds of Fedora packages for EL5, EL6 and EL7. Packages should not replace base, although there have been issues around point releases in the past. You can install EPEL by running yum install epel-release. The epel-release package is included in the CentOS Extras repository that is enabled by default. Support available on Freenode in #epel, on mailing lists, and its issue tracker. [/quote]
From http://wiki.centos.org/AdditionalResources/Repositories
Submitted by runnerz on Thu, 02/04/2016 - 07:54 Comment #13
The problem means that i have customers who cannot use gmail as mail tool for domains setup on this server. But using roundcube (local install on server) and usermin works fine. Any clue to where i should start looking. This was a clean install CentOS 7.2 and then restored config and sites from backup.
Submitted by andreychek on Thu, 02/04/2016 - 09:31 Comment #14
It sounds like you're seeing a different issue than the one described above runnerz... any chance you could start a new support request, and in it, could you describe the problem you're having and any errors that you are receiving?
Submitted by runnerz on Thu, 02/04/2016 - 14:16 Comment #15
Did check again, it is the same problem i have nobody is able to send email. I get this in the /var/log/maillog.
Feb 4 21:14:07 bender01 postfix/smtpd[2216]: connect from unknown[213.14.124.28] Feb 4 21:14:07 bender01 postfix/smtpd[2216]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Feb 4 21:14:07 bender01 postfix/smtpd[2216]: warning: unknown[213.14.124.28]: SASL LOGIN authentication failed: generic failure Feb 4 21:14:07 bender01 postfix/smtpd[2216]: disconnect from unknown[213.14.124.28] Feb 4 21:14:24 bender01 postfix/smtpd[2216]: connect from unknown[::1] Feb 4 21:14:24 bender01 postfix/smtpd[2216]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Feb 4 21:14:24 bender01 postfix/smtpd[2216]: warning: unknown[::1]: SASL LOGIN authentication failed: generic failure Feb 4 21:14:24 bender01 postfix/smtpd[2216]: disconnect from unknown[::1]