Date: Monday, August 27, 2018 09:57:01 -0400 From: TE Dukes tdukes@palmettoshopper.com
From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of centos--- via CentOS Sent: Monday, August 27, 2018 9:31 AM
On 08/27/2018 09:05 AM, TE Dukes wrote:
Thanks again! I still think it's a mail issue. I can't get mail using usermin either.
Think I'm going to remove the TLS stuff from postfix main.cf that I added yesterday and retry.
If I missed this further up thread my apologies - is SELinux enabled and are there any relevant exceptions being logged?
Pretty sure SELinux is turned off unless it got turned on without my knowledge through an updtate/upgrade.
I removed the TLS lines from main.cf I added last night and remotely did a reboot from here at work.
Mail is again working!! I am skeptical to mark this thread solved as I thought it was solved back in July.
I think, removing my ISP's DNS servers from resolve.conf was the fix, could be removing IPV6 from etc/hosts. Might put it back in just to see.
As I indicated earlier, removing those lines from your postfix config will have no impact on your ability to reach your roundcube instance.
Unlike the windowz world, you mostly don't need to "reboot" a machine after making changes to a service (e.g., your postfix config change). An unnecessary reboot can bring in many issues so makes debugging a problem difficult. Instead, restart the service in question (often a reload is all that's needed, but a service restart generally doesn't hurt in a single/lower user environment).
Unless you are VPN-ing (or equiv) my sense is that you are currently getting to your mail (roundcube) from outside your network. Earlier, when it wasn't working, my sense was that you were inside. If that's true you can't really tell if your issue has been resolved as you are coming at things from different network directions.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Richard Sent: Monday, August 27, 2018 10:16 AM To: CentOS mailing list Subject: Re: [CentOS] Mail has quit working
Date: Monday, August 27, 2018 09:57:01 -0400 From: TE Dukes tdukes@palmettoshopper.com
From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of centos--- via CentOS Sent: Monday, August 27, 2018 9:31 AM
On 08/27/2018 09:05 AM, TE Dukes wrote:
Thanks again! I still think it's a mail issue. I can't get mail using usermin either.
Think I'm going to remove the TLS stuff from postfix main.cf that I added yesterday and retry.
If I missed this further up thread my apologies - is SELinux enabled and are there any relevant exceptions being logged?
Pretty sure SELinux is turned off unless it got turned on without my knowledge through an updtate/upgrade.
I removed the TLS lines from main.cf I added last night and remotely did a reboot from here at work.
Mail is again working!! I am skeptical to mark this thread solved as I thought it was solved back in July.
I think, removing my ISP's DNS servers from resolve.conf was the fix, could be removing IPV6 from etc/hosts. Might put it back in just to see.
As I indicated earlier, removing those lines from your postfix config will have no impact on your ability to reach your roundcube instance.
Unlike the windowz world, you mostly don't need to "reboot" a machine after making changes to a service (e.g., your postfix config change). An unnecessary reboot can bring in many issues so makes debugging a problem difficult. Instead, restart the service in question (often a reload is all that's needed, but a service restart generally doesn't hurt in a single/lower user environment).
Unless you are VPN-ing (or equiv) my sense is that you are currently getting to your mail (roundcube) from outside your network. Earlier, when it wasn't working, my sense was that you were inside. If that's true you can't really tell if your issue has been resolved as you are coming at things from different network directions.
The mail in question is system mail sent via cron. I access it from both inside the network and outside. Due to being on a dynamic ip, I can't send mail to the outside but I can receive it.
Again, really appreciate the help!!
Added back the IPV6 to /etc/hosts a couple days ago for grins and giggles. No longer getting IPV6 errors in logwatch for bind. Everything working.
I think removing my ISP's nameservers from /etc/resolv.conf was the fix. They have been in there forever so still have my fingers crossed.
Again, many thanks!!
On 08/29/2018 06:54 PM, TE Dukes wrote:
Added back the IPV6 to /etc/hosts a couple days ago for grins and giggles. No longer getting IPV6 errors in logwatch for bind. Everything working.
I think removing my ISP's nameservers from /etc/resolv.conf was the fix.
I just caught up on the thread. It looks like the core issue was never actually resolved: "getent hosts localhost" still doesn't return the expected result, right?
$ getent hosts localhost ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 $ grep ^hosts /etc/nsswitch.conf hosts: files dns myhostname
If you're not getting the expected result from "getent", and if your nsswitch.conf lists "files", then glibc is somehow broken. "rpm -V glibc" might tell you how, or it might not. Could be that glibc can't load /lib64/libnss_files.so.2.
In any case, DNS is now providing you with a result for "localhost", and that'll work around most of the problems, but you really should take steps to fix glibc. With something that low-level broken, I'd urge you to build a new system from scratch, and automate the build with some configuration management tool this time, so that the next time you need to rebuild, you can do it quickly.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Thursday, August 30, 2018 6:23 PM To: centos@centos.org Subject: Re: [CentOS] Mail has quit working
On 08/29/2018 06:54 PM, TE Dukes wrote:
Added back the IPV6 to /etc/hosts a couple days ago for grins and giggles. No longer getting IPV6 errors in logwatch for bind. Everything working.
I think removing my ISP's nameservers from /etc/resolv.conf was the fix.
I just caught up on the thread. It looks like the core issue was never actually resolved: "getent hosts localhost" still doesn't return the expected result, right?
$ getent hosts localhost ::1 localhost localhost.localdomain localhost6localhost6.localdomain6
Its returning exactly as above
$ grep ^hosts /etc/nsswitch.conf hosts: files dns myhostname
Its returning: files dns
If you're not getting the expected result from "getent", and if your nsswitch.conf lists "files", then glibc is somehow broken. "rpm -V glibc" might tell you how, or it might not. Could be that glibc can't load /lib64/libnss_files.so.2.
rpm -V returns nothing.
In any case, DNS is now providing you with a result for "localhost", and that'll work around most of the problems, but you really should take steps to fix glibc. With something that low-level broken, I'd urge you to build a new system from scratch, and automate the build with some configuration management tool this time, so that the next time you need to rebuild, you can do it quickly. _______________________________________________
Thanks for the follow up!!
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of TE Dukes Sent: Thursday, August 30, 2018 6:36 PM To: 'CentOS mailing list' Subject: Re: [CentOS] Mail has quit working
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Thursday, August 30, 2018 6:23 PM To: centos@centos.org Subject: Re: [CentOS] Mail has quit working
On 08/29/2018 06:54 PM, TE Dukes wrote:
Added back the IPV6 to /etc/hosts a couple days ago for grins and
giggles.
No longer getting IPV6 errors in logwatch for bind. Everything
working.
I think removing my ISP's nameservers from /etc/resolv.conf was the
fix.
I just caught up on the thread. It looks like the core issue was never actually resolved: "getent hosts localhost" still doesn't return the expected result, right?
$ getent hosts localhost ::1 localhost localhost.localdomain localhost6localhost6.localdomain6
Its returning exactly as above
$ grep ^hosts /etc/nsswitch.conf hosts: files dns myhostnameIts returning: files dns
If you're not getting the expected result from "getent", and if your nsswitch.conf lists "files", then glibc is somehow broken. "rpm -V glibc" might tell you how, or it might not. Could be that glibc can't load /lib64/libnss_files.so.2.
rpm -V returns nothing.
My bad, rpm -V glibc returns nothing.
-
Gordon Messmer -
Richard -
TE Dukes