Somewhat inspired by the services extentions, it would
be great to have the rules built based on files in a
directory. This would make distibuted configuration
(such as with cfengine) and enabling/disabling via
package distribution somewhat easier. As an example:
#Firehhol.conf
version 5
interface any world
conf_dir world # this could just default to the
interface name.
##In the conf_dir (/etc/firehol/world/)
#000-Policy.enable <rename to *.disable to remove a rule>
policy reject
#010-DNS-client.enable
client dns accept dst "1.1.1.1 2.2.2.2"
#010-DNS-server.disable
server dns accept
#020-SSH-client.enable
client ssh accept
...And on it could go
This would be packages could easily distribute a single
base config file for their services (e.g. lynx packages
might have a file which would allow client http
connections) and make it _easier_ to change many
systems that are similar (but not the same) by adding
and removing files within the conf_dir structure.
Order of processing is simply controlled by the file
names where 010 would be processed before 020 HOWEVER
if 2 rules have the same number, their order of
processing is not guaranteed (although the rest of the
filename would probably make this somewhat consistant).
It would not be hard to devise a system where package
supplied enable or disable files are easily
identifiable (not used in the above examples) however,
###-service-pkg<package name>.(dis|en)able. This of
course is probably outside the scope of firehol itself
and up to the package maintainers of individual systems
is put here for completness.
There is an alternative to this and that is to use
symbolic links. (ala apache2 on debian - or is that
symbolic link thing a feature of apache2..anyway).
However, I would probably leave it to the firehol
experts to decide, which is a better solution.
Cheers,
Stewart