Suggest changing chkconfig line to start CSF earlier

[TommyTheKid]

Hi,

We are having a bad interaction between CSF and SSSD. SSSD starts at 12 and CSF starts at 15. When CSF starts, it starts blocking packets for a period of time (sometimes several seconds) while it sorts out its policies (csf.allow). We do not have an extensive set of policies, but maybe 20 or so lines of csf.allow. When CSF blocks these packets during startup, it confuses sssd, and makes it so that I can't login (except as root on the console, which is annoying).

Code: Select all

# grep chkconfig iptables csf sssd
iptables:# chkconfig: 2345 08 92
csf:# chkconfig: 2345 15 80
sssd:# chkconfig: - 12 88

If csf was changed to 08, to match when "iptables" would normally start, it resolves the issue because CSF is fully started and ready to process packets by the time that sssd starts. We have tested this, but are sure that every csf update will wipe out our test. I propose to change the "chkconfig" line in /etc/rc.d/init.d/csf to look like:

Code: Select all

# chkconfig: 2345 08 80

That would make it startup at the time when the "default" RHEL/CentOS firewall would have started, which seems appropriate.

Thanks in advance,
Tommy

[ForumAdmin]

csf has to start after iptables, which would mean starting at 09, however on cPanel servers ip addresses are not fully applied until 11 which means that the earliest it can start would be 12 which may conflict with your sssd service depending on which starts first. If you could test whether starting csf and 12 instead of 15 works on your service, we can move it down to 12.

[TommyTheKid]

Sorry for the delayed response...

The firewall should start *before* the network is up. That is why iptables starts at 08 and network at 10. I recommend 09 based on your response, however, 12 would be better than nothing (c[sf] would still start before s[ssd]). I guess it doesn't really matter because sssd recovers, and any time later when csf is restarted (csf -r), it also happens. I would say we can chalk this up to a limitation of iptables, not having the ability to "build" the ruleset in an inactive way, then swap rulesets in an atomic operation.