Oh, so apparently there is a patch… somewhere? But is there actually any reason to keep the /etc/default/firehol file and the START_FIREHOL logic? I don’t understand the point of having it. What would be wrong with “systemctl [enable/disable] firehol”? That would be more proper, no?
AFAIK files like /etc/default/firehol are a relic of the old init system. Maybe I am mistaken but I assumed there would be a more modern approach that packages these days are supposed be using for adjusting whether or not to start services. Won’t your proposed fix of having the firehol script itself check /etc/default/firehol cause other problems? I am thinking of cases where someone is intentionally not letting it be run as a system service, but wants to execute it manually from the command-line (“firehol start”). E.g. someone wants to test their config file for unintentional lockout before enabling the service permanently. Also, when running via the command-line it is possible to specify alternate .conf file. So with your proposed modification there would also need to be a way to specify an alternate "default" file. Further, if you are going to have the START_FIREHOL check happening in the firehol script itself, then why the need for the /etc/default/firehol file at all? Doesn’t it just become a confusing additonal file? Why not just put START_FIREHOL in the firehol.conf (or the firehol-defaults.conf)? What’s the benefit of keeping a separate config file just for this one variable? My proposed fix is much simpler IMO: 1. Modify the systemd unit to be disabled by default. 2. Remove /etc/init.d/firehol 3. Remove /etc/default/firehol The only dilemma is that I do not know if there is some Debian policy around how (1) is supposed to be handled. I will try to look into it.
