Got 7.3 installed Wednesday, things went so so.
Been working on getting roundcubemail setup and firewalld is kicking my butt.
I can't figure out all these zones. I opened imap, imaps, pop3, pop3s, smtp, smtps in zones internal, trusted and public.
I still get connection refused.
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access? Two days and can't access mail.
Is this a Redhat brain child? According to firewalld.org, only Redhat, CentOS and Fedora are using it.
Not too happy
On 01/27/2017 06:01 PM, TE Dukes wrote:
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access?
All traffic from localhost is allowed. No zone is involved.
The zone for "outside" access depends on which interface receives the packet, and what zone you've put that interface in. I believe that defaults to "public."
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Friday, January 27, 2017 9:23 PM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 01/27/2017 06:01 PM, TE Dukes wrote:
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access?
All traffic from localhost is allowed. No zone is involved.
The zone for "outside" access depends on which interface receives the packet, and what zone you've put that interface in. I believe that
defaults to
"public."
I'm telneting in from ssh on a machine on the local network, still getting connection refused.
The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same services/ports opened in each zone).
I may as well disable firewalld and let my router handle the firewall.
I don't plan to use my server as a workstation.
On 28 Jan 2017 3:02 am, "TE Dukes" tdukes@palmettoshopper.com wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Friday, January 27, 2017 9:23 PM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 01/27/2017 06:01 PM, TE Dukes wrote:
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access?
All traffic from localhost is allowed. No zone is involved.
The zone for "outside" access depends on which interface receives the packet, and what zone you've put that interface in. I believe that
defaults to
"public."
I'm telneting in from ssh on a machine on the local network, still getting connection refused.
The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same services/ports opened in each zone).
I may as well disable firewalld and let my router handle the firewall.
I don't plan to use my server as a workstation.
Have a read through this and then decide on if you want to use it or not.
You can also switch to iptables-service and mask firewalld if you want the same behaviour as in C6.
7.3 also has nftables as a tech preview, but I've not finished my article on that yet.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of James Hogarth Sent: Saturday, January 28, 2017 4:18 AM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 28 Jan 2017 3:02 am, "TE Dukes" tdukes@palmettoshopper.com wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Friday, January 27, 2017 9:23 PM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 01/27/2017 06:01 PM, TE Dukes wrote:
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access?
All traffic from localhost is allowed. No zone is involved.
The zone for "outside" access depends on which interface receives the packet, and what zone you've put that interface in. I believe that
defaults to
"public."
I'm telneting in from ssh on a machine on the local network, still
getting
connection refused.
The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same
services/ports
opened in each zone).
I may as well disable firewalld and let my router handle the firewall.
I don't plan to use my server as a workstation.
Have a read through this and then decide on if you want to use it or not.
You can also switch to iptables-service and mask firewalld if you want the same behaviour as in C6.
7.3 also has nftables as a tech preview, but I've not finished my article
on that
yet.
I saw something about that somewhere.
Did you forget a link?
Thanks
On 28 January 2017 at 12:01, TE Dukes tdukes@palmettoshopper.com wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of James Hogarth Sent: Saturday, January 28, 2017 4:18 AM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 28 Jan 2017 3:02 am, "TE Dukes" tdukes@palmettoshopper.com wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Friday, January 27, 2017 9:23 PM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 01/27/2017 06:01 PM, TE Dukes wrote:
I telnet localhost 143, I get connection refused.
What zone is used for the local network and what zone is used for outside access?
All traffic from localhost is allowed. No zone is involved.
The zone for "outside" access depends on which interface receives the packet, and what zone you've put that interface in. I believe that
defaults to
"public."
I'm telneting in from ssh on a machine on the local network, still
getting
connection refused.
The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same
services/ports
opened in each zone).
I may as well disable firewalld and let my router handle the firewall.
I don't plan to use my server as a workstation.
Have a read through this and then decide on if you want to use it or not.
You can also switch to iptables-service and mask firewalld if you want the same behaviour as in C6.
7.3 also has nftables as a tech preview, but I've not finished my article
on that
yet.
I saw something about that somewhere.
Did you forget a link?
Thanks
Oops you're right I did ...
The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same services/ports opened in each zone).
The "zones" are just labels and are used to create kernel iptables. Each zone has a default set of open and closed ports ranging from "trusted" which accepts all packets to "public" which has everything closed. You can modify the allowed ports and services on each zone at will.
Some of the zones have "special" features - "block" rejects all packets, "drop" drops all packets, "external" has masquerading turned on and so on.
If you have a single network, then that interface will, by default, be put in the "public" zone, so most ports will be closed. That's fine, just leave it in that zone, it's just a label/container.
You can list the services open in the default zone by doing
firewall-cmd --list-services
or for ports not services
firewall-cmd --list-ports
or for a different zone
firewall-cmd --zone=public --list-services
You can also find out which zones your interface(s) is in with
firewall-cmd --get-active-zones
One of the gotchas with firewalld is that the changes are made in either the current running iptables *or* the stored rules, not both. So if you make a change to the running rule set, those changes won't be kept the next time you restart firewalld. You can either use the ' --permanent' flag to set the stored rules (but it won't affect the active rules) or the '--runtime-to-permanent' flag to copy the current active rules to the stored ones.
The bottom line is that firewalld is just another application that manipulates the kernel packet routing tables. Use something else if you prefer it - some of the system tools assume firewalld, but if you are aware of what's happening it shouldn't be an issue.
I may as well disable firewalld and let my router handle the firewall.
If you are happy that there is nothing behind your firewall that could cause a problem then that's an acceptable route.
P.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Pete Biggs Sent: Saturday, January 28, 2017 6:02 AM To: centos@centos.org Subject: Re: [CentOS] firewalld
The zone apparently means something because an interface can only be on
one.
Moving it to a different zone results in the same error (same services/ports opened in each zone).
The "zones" are just labels and are used to create kernel iptables. Each zone has a default set of open and closed ports ranging from "trusted" which accepts all packets to "public" which has everything closed. You can modify the allowed ports and services on each zone at will.
Some of the zones have "special" features - "block" rejects all packets, "drop" drops all packets, "external" has masquerading turned on and so on.
If you have a single network, then that interface will, by default, be put in the "public" zone, so most ports will be closed. That's fine, just leave it in that zone, it's just a label/container.
You can list the services open in the default zone by doing
firewall-cmd --list-services
or for ports not services
firewall-cmd --list-ports
or for a different zone
firewall-cmd --zone=public --list-services
You can also find out which zones your interface(s) is in with
firewall-cmd --get-active-zones
One of the gotchas with firewalld is that the changes are made in either the current running iptables *or* the stored rules, not both. So if you make a change to the running rule set, those changes won't be kept the next time you restart firewalld. You can either use the ' --permanent' flag to set the stored rules (but it won't affect the active rules) or the '--runtime-to-permanent' flag to copy the current active rules to the stored ones.
The bottom line is that firewalld is just another application that manipulates the kernel packet routing tables. Use something else if you prefer it - some of the system tools assume firewalld, but if you are aware of what's happening it shouldn't be an issue.
I may as well disable firewalld and let my router handle the firewall.
If you are happy that there is nothing behind your firewall that could cause a problem then that's an acceptable route.
P.
Thanks,
That's a better explanation of things than I have read so far.
Yes, initially I wasn't adding the --permanent to the rules but I wasn't doing really any reboots.
I did a few --reloads so that may have gotten me.
I have zoneminder, dns, and urbackup working. I can ssh and scp in from work but mail is being a pain.
Thanks
firewalld isn't the only thing that will prevent services from accessing the internet. I found that I needed to do a relabel before postfix could access DNS and I have seen other issues as well. Have you tried disabling the firewall to see if you can get connections to work? Then try to disable SElinux and see if that works.
# netstat --inet -l -n
Is the service listening on port 143?
# systemctl stop firewalld
Does it now work?
# setenforce 0
Does it now work?
Once you establish what's biting you then you can fix it. To force a relabel do
# touch /.autorelabel
# reboot
Mike
On 01/28/2017 07:11 AM, TE Dukes wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Pete Biggs Sent: Saturday, January 28, 2017 6:02 AM To: centos@centos.org Subject: Re: [CentOS] firewalld
The zone apparently means something because an interface can only be on
one.
Moving it to a different zone results in the same error (same services/ports opened in each zone).
The "zones" are just labels and are used to create kernel iptables. Each zone has a default set of open and closed ports ranging from "trusted" which accepts all packets to "public" which has everything closed. You can modify the allowed ports and services on each zone at will.
Some of the zones have "special" features - "block" rejects all packets, "drop" drops all packets, "external" has masquerading turned on and so on.
If you have a single network, then that interface will, by default, be put in the "public" zone, so most ports will be closed. That's fine, just leave it in that zone, it's just a label/container.
You can list the services open in the default zone by doing
firewall-cmd --list-services
or for ports not services
firewall-cmd --list-ports
or for a different zone
firewall-cmd --zone=public --list-services
You can also find out which zones your interface(s) is in with
firewall-cmd --get-active-zones
One of the gotchas with firewalld is that the changes are made in either the current running iptables *or* the stored rules, not both. So if you make a change to the running rule set, those changes won't be kept the next time you restart firewalld. You can either use the ' --permanent' flag to set the stored rules (but it won't affect the active rules) or the '--runtime-to-permanent' flag to copy the current active rules to the stored ones.
The bottom line is that firewalld is just another application that manipulates the kernel packet routing tables. Use something else if you prefer it - some of the system tools assume firewalld, but if you are aware of what's happening it shouldn't be an issue.
I may as well disable firewalld and let my router handle the firewall.
If you are happy that there is nothing behind your firewall that could cause a problem then that's an acceptable route.
P.
Thanks,
That's a better explanation of things than I have read so far.
Yes, initially I wasn't adding the --permanent to the rules but I wasn't doing really any reboots.
I did a few --reloads so that may have gotten me.
I have zoneminder, dns, and urbackup working. I can ssh and scp in from work but mail is being a pain.
Thanks
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Mike McCarthy, W1NR Sent: Saturday, January 28, 2017 8:45 AM To: CentOS mailing list Subject: Re: [CentOS] firewalld
firewalld isn't the only thing that will prevent services from accessing the internet. I found that I needed to do a relabel before postfix could access DNS and I have seen other issues as well. Have you tried disabling the firewall to see if you can get connections to work? Then try to disable SElinux and see if that works.
# netstat --inet -l -n
Is the service listening on port 143?
# systemctl stop firewalld
Does it now work?
# setenforce 0
Does it now work?
Once you establish what's biting you then you can fix it. To force a relabel do
# touch /.autorelabel
# reboot
Mike
I have dovecot answering now. I can read mail using Mutt.
I think I have problems with mysql/mariadb using roundcube. It may be I need to open ports for mariadb as well.
Thanks
On 28 January 2017 at 13:44, Mike McCarthy, W1NR sysop@w1nr.net wrote:
firewalld isn't the only thing that will prevent services from accessing the internet. I found that I needed to do a relabel before postfix could access DNS and I have seen other issues as well. Have you tried disabling the firewall to see if you can get connections to work? Then try to disable SElinux and see if that works.
# netstat --inet -l -n
Is the service listening on port 143?
Just a side note here, since EL7 removed net-tools from the default install (after all it has been deprecated for about a decade now) you probably should get used to providing advice using the iproute2 suite instead.
In this case `ss -tlnp` to list all tcp ports in a listening state, showing the pid using the port and not resolving the ports to friendly names.
For an example of why this is important think about using pacemaker or keepalived to manage IPs migrating between systems. They won't be visible using ifconfig but only via ip as they aren't exposed in the kernel structures that ifconfig uses - https://www.hogarthuk.com/?q=node/6
Another example is when you have multiple interfaces and you have source policy routing (or similar advanced routing behaviour) that makes use of rules and multiple routing tables. The older route command is only capable of displaying the default main table, not the rest of the tables in use, but `ip route show table all` will give you all the routing tables in use on your system (even in a default install it's a lot more than the route command shows) and ip rule gives you the rules in use, if any.
On a similar note bridge-utils is also deprecated, though brctl is ingrained into many minds!
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of James Hogarth Sent: Saturday, January 28, 2017 10:43 AM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 28 January 2017 at 13:44, Mike McCarthy, W1NR sysop@w1nr.net wrote:
firewalld isn't the only thing that will prevent services from accessing the internet. I found that I needed to do a relabel before postfix could access DNS and I have seen other issues as well. Have you tried disabling the firewall to see if you can get connections to work? Then try to disable SElinux and see if that works.
# netstat --inet -l -n
Is the service listening on port 143?
Just a side note here, since EL7 removed net-tools from the default install (after all it has been deprecated for about a decade now) you probably should get used to providing advice using the iproute2 suite instead.
In this case `ss -tlnp` to list all tcp ports in a listening state, showing the pid using the port and not resolving the ports to friendly names.
For an example of why this is important think about using pacemaker or keepalived to manage IPs migrating between systems. They won't be visible using ifconfig but only via ip as they aren't exposed in the kernel structures that ifconfig uses - https://www.hogarthuk.com/?q=node/6
Another example is when you have multiple interfaces and you have source policy routing (or similar advanced routing behaviour) that makes use of rules and multiple routing tables. The older route command is only capable of displaying the default main table, not the rest of the tables in use, but `ip route show table all` will give you all the routing tables in use on your system (even in a default install it's a lot more than the route command shows) and ip rule gives you the rules in use, if any.
On a similar note bridge-utils is also deprecated, though brctl is ingrained into many minds!
https://fedoramagazine.org/build-network-bridge-fedora/
Thanks for the info. I'll take a look at it.
Again, thanks!
Still un-resolved. Could be wrong but I think its firewalld preventing me from accessing mail with roundcube.
I'm getting Connection to storage server failed.
From roundcubemail log:
[29-Jan-2017 16:45:05 -0500]: <4r5ccifn> IMAP Error: Login failed for tdukes from 192.168.1.102. AUTHENTICATE PLAIN: * BYE Internal error occurred. Refer to server log for more information. in /usr/share/roundcubemail/program/lib/Roundcube/rcube_imap.php on line 197 (POST /?_task=login?_task=login&_action=login)
There is absolutely nothing in the httpd logs.
I telnet to localhost 143 or 993 and I can connect, telneting to 25 or 465, connection refused.
Clearly, below, those services and ports are open as well as mysql.
Ouput from: firewall-cmd --list-all-zones
work target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh urbackup-server ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
drop target: DROP icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
internal (active) target: default icmp-block-inversion: no interfaces: enp1s0 lo sources: services: dhcp dhcpv6 dhcpv6-client dns ftp http https imap imaps mdns mysql openvpn pop3 pop3s rsyncd samba samba-client smtp smtps ssh transmission-client urbackup-server ports: 465/tcp 20000/tcp 25/tcp 10000/tcp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
external target: default icmp-block-inversion: no interfaces: sources: services: ssh urbackup-server ports: protocols: masquerade: yes forward-ports: sourceports: icmp-blocks: rich rules:
trusted (active) target: ACCEPT icmp-block-inversion: no interfaces: virbr0 sources: services: dhcp dhcpv6 dhcpv6-client dns ftp http https imap imaps mysql ntp openvpn pop3 pop3s rsyncd samba samba-client smtp smtps ssh transmission-client urbackup-server ports: 465/tcp 20000/tcp 25/tcp 10000/tcp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
home target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client mdns samba-client ssh ports: 10000/tcp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
dmz target: default icmp-block-inversion: no interfaces: sources: services: ssh ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: services: dhcp dhcpv6-client dns ftp http https imap imaps mysql pop3 pop3s rsyncd samba samba-client smtp smtps ssh transmission-client urbackup-server ports: 465/tcp 20000/tcp 25/tcp 10000/tcp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
block target: %%REJECT%% icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
eno1 is on the public zone, lo is on the internal zone
I can read mail with mutt and usermin.
What am I missing?
TIA
On 01/29/2017 01:54 PM, TE Dukes wrote:
I telnet to localhost 143 or 993 and I can connect, telneting to 25 or 465, connection refused.
As I mentioned before: firewalld allows all traffic to localhost. If you're getting connection refused, then those services aren't running.
As for dealing with login denied errors, you should be looking at the IMAP server's logs, not the HTTP server's.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Gordon Messmer Sent: Sunday, January 29, 2017 6:56 PM To: CentOS mailing list Subject: Re: [CentOS] firewalld
On 01/29/2017 01:54 PM, TE Dukes wrote:
I telnet to localhost 143 or 993 and I can connect, telneting to 25 or 465, connection refused.
As I mentioned before: firewalld allows all traffic to localhost. If
you're
getting connection refused, then those services aren't running.
As for dealing with login denied errors, you should be looking at the IMAP server's logs, not the HTTP server's.
Here's the excerpts from maillog:
Jan 29 13:52:28 ts130 MailScanner[3941]: MailScanner Email Processor version 5.0.3 starting... Jan 29 13:52:28 ts130 logger[3944]: MailScanner started Jan 29 13:52:28 ts130 MailScanner[3941]: Reading configuration file /etc/MailScanner/MailScanner.conf Jan 29 13:52:28 ts130 MailScanner[3941]: Reading configuration file /etc/MailScanner/conf.d/README Jan 29 13:52:28 ts130 MailScanner[3941]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:28 ts130 MailScanner[3941]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:28 ts130 MailScanner[3941]: Using SpamAssassin results cache Jan 29 13:52:28 ts130 MailScanner[3941]: Connected to SpamAssassin cache database Jan 29 13:52:28 ts130 MailScanner[3941]: Enabling SpamAssassin auto-whitelist functionality... Jan 29 13:52:33 ts130 MailScanner[4235]: MailScanner Email Processor version 5.0.3 starting... Jan 29 13:52:33 ts130 MailScanner[4235]: Reading configuration file /etc/MailScanner/MailScanner.conf Jan 29 13:52:33 ts130 MailScanner[4235]: Reading configuration file /etc/MailScanner/conf.d/README Jan 29 13:52:33 ts130 MailScanner[4235]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:33 ts130 MailScanner[4235]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:33 ts130 MailScanner[4235]: Using SpamAssassin results cache Jan 29 13:52:33 ts130 MailScanner[4235]: Connected to SpamAssassin cache database Jan 29 13:52:33 ts130 MailScanner[4235]: Enabling SpamAssassin auto-whitelist functionality... Jan 29 13:52:38 ts130 MailScanner[4363]: MailScanner Email Processor version 5.0.3 starting... Jan 29 13:52:38 ts130 MailScanner[4363]: Reading configuration file /etc/MailScanner/MailScanner.conf Jan 29 13:52:38 ts130 MailScanner[4363]: Reading configuration file /etc/MailScanner/conf.d/README Jan 29 13:52:38 ts130 MailScanner[4363]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:38 ts130 MailScanner[4363]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:38 ts130 MailScanner[4363]: Using SpamAssassin results cache Jan 29 13:52:38 ts130 MailScanner[4363]: Connected to SpamAssassin cache database Jan 29 13:52:38 ts130 MailScanner[4363]: Enabling SpamAssassin auto-whitelist functionality... Jan 29 13:52:43 ts130 MailScanner[4459]: MailScanner Email Processor version 5.0.3 starting... Jan 29 13:52:43 ts130 MailScanner[4459]: Reading configuration file /etc/MailScanner/MailScanner.conf Jan 29 13:52:43 ts130 MailScanner[4459]: Reading configuration file /etc/MailScanner/conf.d/README Jan 29 13:52:43 ts130 MailScanner[4459]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:43 ts130 MailScanner[4459]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:43 ts130 MailScanner[4459]: Using SpamAssassin results cache Jan 29 13:52:43 ts130 MailScanner[4459]: Connected to SpamAssassin cache database Jan 29 13:52:43 ts130 MailScanner[4459]: Enabling SpamAssassin auto-whitelist functionality... Jan 29 13:52:48 ts130 MailScanner[4528]: MailScanner Email Processor version 5.0.3 starting... Jan 29 13:52:48 ts130 MailScanner[4528]: Reading configuration file /etc/MailScanner/MailScanner.conf Jan 29 13:52:48 ts130 MailScanner[4528]: Reading configuration file /etc/MailScanner/conf.d/README Jan 29 13:52:48 ts130 MailScanner[4528]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:48 ts130 MailScanner[4528]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:48 ts130 MailScanner[4528]: Using SpamAssassin results cache Jan 29 13:52:48 ts130 MailScanner[4528]: Connected to SpamAssassin cache database Jan 29 13:52:48 ts130 MailScanner[4528]: Enabling SpamAssassin auto-whitelist functionality... Jan 29 13:53:03 ts130 MailScanner[4235]: Auto: Found virus scanners: clamavmodule Jan 29 13:53:03 ts130 MailScanner[3941]: Auto: Found virus scanners: clamavmodule Jan 29 13:53:05 ts130 MailScanner[4363]: Auto: Found virus scanners: clamavmodule Jan 29 13:53:05 ts130 MailScanner[4459]: Auto: Found virus scanners: clamavmodule Jan 29 13:53:11 ts130 MailScanner[4528]: Auto: Found virus scanners: clamavmodule Jan 29 13:53:17 ts130 MailScanner[4459]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4459]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4459]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[4235]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4235]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4235]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[4363]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4363]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4363]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[3941]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[3941]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[3941]: Using locktype = flock Jan 29 13:53:21 ts130 MailScanner[4528]: Connected to Processing Attempts Database Jan 29 13:53:21 ts130 MailScanner[4528]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:21 ts130 MailScanner[4528]: Using locktype = flock
Last login attempt from roundcube
Jan 29 16:38:08 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2076, secured, session=<dVTVg0JHkAAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:44:47 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2282, secured, session=<OEeVm0JHkgAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:44:47 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:44:47 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:44:56 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2290, secured, session=<FyIlnEJHlAAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:44:56 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:44:56 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:45:05 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2301, secured, session=<yISwnEJHlgAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:45:05 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:45:05 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information.
???
I have no clue
Last login attempt from roundcube
Jan 29 16:38:08 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2076, secured, session=<dVTVg0JHkAAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information.
It's a dovecot configuration error. The login has clearly worked, so stop fussing with the firewall.
You need to look in /etc/dovecot/conf.d/10-mail.conf and set 'mail_location' to where the user's email is stored. If you are using Maildir then it will probably be
mail_location = maildir:~/Maildir
if mbox, then probably
mail_location = mbox:~/mail:INBOX=/var/mail/%u
but adjust the paths to where things are actually stored.
You will, obviously, have to set your MTA to deliver the mail to the correct location and in the correct format as well.
P.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Pete Biggs Sent: Sunday, January 29, 2017 8:27 PM To: centos@centos.org Subject: Re: [CentOS] firewalld
Last login attempt from roundcube
Jan 29 16:38:08 ts130 dovecot: imap-login: Login: user=<tdukes>, method=PLAIN, rip=::1, lip=::1, mpid=2076, secured, session=<dVTVg0JHkAAAAAAAAAAAAAAAAAAAAAAB> Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: user tdukes: Initialization failed: Namespace '': Mail storage autodetection failed with home=/home/tdukes Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information.
It's a dovecot configuration error. The login has clearly worked, so stop fussing with the firewall.
You need to look in /etc/dovecot/conf.d/10-mail.conf and set 'mail_location' to where the user's email is stored. If you are using Maildir then it will probably be
mail_location = maildir:~/Maildir
if mbox, then probably
mail_location = mbox:~/mail:INBOX=/var/mail/%u
but adjust the paths to where things are actually stored.
You will, obviously, have to set your MTA to deliver the mail to the correct location and in the correct format as well.
Thank you!!!!!!
Its working now! Never had to do that before, everything always worked out of the box.
# Location for users' mailboxes. The default is empty, which means that Dovecot # tries to find the mailboxes automatically. This won't work if the user # doesn't yet have any mail, so you should explicitly tell Dovecot the full # location. # # If you're using mbox, giving a path to the INBOX file (eg. /var/mail/%u) # isn't enough. You'll also need to tell Dovecot where the other mailboxes are # kept. This is called the "root mail directory", and it must be the first # path given in the mail_location setting. # # There are a few special variables you can use, eg.: # # %u - username # %n - user part in user@domain, same as %u if there's no domain # %d - domain part in user@domain, empty if there's no domain # %h - home directory # # See doc/wiki/Variables.txt for full list. Some examples: # # mail_location = maildir:~/Maildir # mail_location = mbox:~/mail:INBOX=/var/mail/%u # mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n # # <doc/wiki/MailLocation.txt> # mail_location = maildir:~/Maildir <<<<<------ this!!
Really appreciate the help!!
On Sun, Jan 29, 2017 at 04:54:02PM -0500, TE Dukes wrote:
Still un-resolved. Could be wrong but I think its firewalld preventing me from accessing mail with roundcube.
as someone else already suggested, did you turn selinux off temporarily "setenforce 0" to see if it still fails?
I've had several problems lately where that simple step revealed selinux as the cause, not firewall.
Fred
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Fred Smith Sent: Sunday, January 29, 2017 7:07 PM To: centos@centos.org Subject: Re: [CentOS] firewalld
On Sun, Jan 29, 2017 at 04:54:02PM -0500, TE Dukes wrote:
Still un-resolved. Could be wrong but I think its firewalld preventing me from accessing mail with roundcube.
as someone else already suggested, did you turn selinux off temporarily "setenforce 0" to see if it still fails?
I've had several problems lately where that simple step revealed selinux
as
the cause, not firewall.
Fred
Yes, selinux has been disabled.
Sorry I didn't mention that.
On 1/27/2017 6:01 PM, TE Dukes wrote:
I can't figure out all these zones. I opened imap, imaps, pop3, pop3s, smtp, smtps in zones internal, trusted and public.
I still get connection refused.
I telnet localhost 143, I get connection refused.
the firewall is more likely to give you connection timed out as it genereally drops rather than rejects the connectiosn.
connection refused often means nothing is actually listening on that port, 143/tcp being IMAP. you sure the imap service is running?
-
Fred Smith -
Gordon Messmer -
James Hogarth -
John R Pierce -
Mike McCarthy, W1NR -
Pete Biggs -
TE Dukes