Stephen John Smoogen wrote:
On Sun, Aug 3, 2008 at 3:50 AM, Jeroen van Meeuwen
<kanarip(a)kanarip.com> wrote:
> Stephen John Smoogen wrote:
>> One of the items that I have to deal with at UNM is a long list of
>> different firewalls and servers. I have Solaris(9,10), AIX(various),
>> MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
>> to worry about with lots of different firewall needs for each one. As
>> I am trying to standardize the firewalls... I run into that same
>> headache everyone runs into at some point or another... How does one
>> organize the various different firewalls in both the VCS and the
>> upcoming configuration management system... while perfect is the enemy
>> of the good.. what is a good way of doing it as I see way to many ways
>> of laying it out in file structure.
>>
>> firewalls/project/OS/system
>> project/firewall/OS/system
>> OS/firewall/project/system
>> OS/system/project/firewall
>>
>> etc etc etc. with some other // items added. Any ideas?
>>
> Sounds like a very sweet apple to sink my teeth in. Are you asking how
> to standardize this best both CSI-style and puppet-style?
>
Yes. Since CSI (wow I have 3 acronyms to deal with CIS, CSI, and SCI..
I wonder if I can get a ISC, and ICS somewhere) needs to have a
regularized layout of how to deal with puppet, VCS and other things
that meet togther.
Awesome, here we go:
Judging from the list you give here in OSs and versions of those OSs, I
doubt they all use "iptables"-compatible firewalls, and that every
iptables or iptables-"alternative" command for each version of a given
OS is compatible with all the versions of that OS.
I suggest the following naming schema / tree layout:
firewall (name of the module)
`- files/ (to put the files in, doh)
`- $os (from the $operatingsystem fact[1])
`- $osver (from the $operatingsystemversion or
$lsbdistrelease fact[1])
Where the default firewall goes into firewall/files/, an old obsolete
firewall for RHEL2 (whereas RHEL3-5 supposedly are common) goes into
firewall/files/RedHat/2/, and the later major OS versions go into
firewall/files/RedHat.
This might however need a fact to be created so that you know the
firewall type as well (ipchains/iptables/foo/bar), so that you can:
class firewall {
case $firewall_type { # Comes from the new fact
iptables: { include firewall::iptables }
ipchains: { include firewall::ipchains }
foo: { include firewall::foo }
bar: { include firewall::bar }
}
}
Let me know what you think (as I'm starting to write the facts and
module itself and stuff).
Kind regards,
Jeroen van Meeuwen
-kanarip
[1] The assignment of facts to variables is useful in this particular
instance as there is now a common variable to use throughtout the rest
of the manifests, although facter in Fedora now knows about
$operatingsystemrelease for many OSs.