Richard G
Verified User
Yes I know, that is correct. I just mentioned mail because if root is doing something outgoing it's mostly sending out mail. But it allows an packet, that is correct.These rules accept all outgoing udp/tcp packets
They put it in as extra precaution, I once asked for the reason why and this is the answer I got from smtalk.
So more for beginners. Normally in a correct configured server, these lines should not be needed.Inability to connect to remote FTP servers with the passive ports, inability to SSH to remote servers using custom ports, inability to connect to DA instances using a custom (non-2222) port and similar things![]()
I didn't say it was, but you can not say it's not related to resolv.conf because it can be and it can be easily reproduced too.This is not the case on our servers, we don't have these 127.0.0.1 entries and use different resolvers.
Not always but in certain situations it can cause the license issue.
Debian/Ubuntu users will have no problem with it. For example with Debian, the "recursion no" setting, will just skip the search to the next resolver (as should be), only searches from localhost get disabled, even if localhost is added seperately to the localnets statement in the allow-recursion setting. But then it just takes the next resolver in line.
But in Almalinux 8, if you have 127.0.0.1 as first resolver in the /etc/resolv.conf file, it doesn't matter what else you got in there, as soon as you have the "recursion no" setting in there it only tries that one and skips te rest, hence the resolving is totally not done. And without resolving the license check can not take place.
You can easily reproduce this. We had this issue ourselves and this was the cause in our case.
Without 127.0.0.1 it does not seem to be an issue, so this is a bug in Almalinux 8 at least.
I wasn't stating this ans -the- answer to licensing check issues. It's just one of the things which can cause it.
The license check failures can ofcourse be caused by several things. I never had them with CSF at any time so I don't really believe that is related but as you say that can be easily tested, you don't even need to reboot the server for that.
Just doublecheck with the
iptables -L
command if it's really disabled.