I don't think dovecot is related per se, actually. The reason is this: I have in the past (and indeed when migrating to CentOS 7) set up one at a time. But user/group is one thing. The problem with that is if it is indeed /etc/postfix/main.cf then it should be readable. As for adding postfix user, I seem to think the postfix rpm post install scriptlet (I maintain my own repository, small as it may be, I have experience with the spec files) adds the user (typically that is the case). You can find out if there are any files without owners in the database. Given that it is a new environment I suspect this is not the case. What is entirely possible however, is that your postfix refers to a user/group that does not exist. You can find files/directories with a uid or gid that does not exist :
Code: Select all
# /usr/bin/find / \( -path '/proc*' -o -path '/dev*' -o -path '/sys*' -o -path '/backup*' \) -prune -o \( -nouser -o -nogroup \) -printf "%u %g (%M) %p\n"
Which will look like:
(you might also have other paths you want to prune from the list but those are the ones that come to mind. If you use bind-chroot then /var/named/chroot will appear as circular filesystem but find handles that gracefully).
if for example /var/www had no user but a proper group. And that above is something similar to my system (technically a directory under it, a specific vhost). This goes back to the user/group ids starting differently (I had apache as the group but the user was id 501 but now that user in question is id 1001. I forgot about this certain vhost because it is a test vhost, only resolvable via internal view in bind).
As for SELinux there is something you can do to determine if it is relevant. That is this:
you have it in a VM, right ? Just disable selinux (/etc/sysconfig/selinux) and reboot. Try to start postfix. If it starts then you can assume something is up with SELinux. If not, it isn't SELinux. Even if it was not a VM you'd probably be fine (and/or you could set it to permissive, but since you have it in a VM disabled is fine).
Code: Select all
# /usr/sbin/sed -i.orig 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
Would change the line to disable selinux and save the original file in /etc/sysconfig/selinux.orig
There is one other thing that comes to mind although I don't think this is related as although Wietse Venema has suggested that there are (and this part is true) another copy of main.cf - specifically /usr/libexec/postfix/main.cf (check the entire directory) that could be used. But I've personally never had a problem here.
Although it was on the previous page I seem to remember that the /etc/postfix directory has proper permissions to actually open files in it. I cannot imagine /etc has an issue, either (and you run it as root so even when it drops privileges it would - or so I would think - read the configuration file first).
What does:
Code: Select all
# systemctl status postfix
# journalctl -xn
show ?
Also, I find that looking at /var/log/maillog and the surrounding lines is much more helpful (at times). This is a general rule, even. Why I think of this is it goes back to my programming experience (tracking down errors is beyond science; it is an art form). You can have one missing (or wrong) character on a line above and yet the compiler sees it (example: you don't end the line properly, above, so it is parsing it as one line but it sees it as the second line, in the file) and complains about the error on the line that appears fine. That example is not the only example. The point is that you can often get more insight into an issue with all the information available.
So I would do the following :
- check maillog and look around the failure (above and below it).
- if that doesn't give any information, try the two commands above to see if it gives any information.
- if that doesn't help, disable selinux and reboot (since in VM) to find out if it is or isn't selinux.
- if that does work, then you know where to go from. if it doesn't work you also know where not to go.
- if that still does not help, I would strongly consider what I suggested before: try to migrate your old install (that does work) in to the new one. configuration files for postfix from CentOS 6.x to CentOS 7.x shouldn't be an issue so it is not so much as the configuration as another problem.
I'm marking notify when a reply is posted so I can follow any further responses and maybe help (or try).