Comments inline...
On 26/01/15 15:11, Jason Price wrote:
Thank you. That looks interesting, but two questions:
1) When you state: "Firewall <<| tag == 'mariadb' |>>" does that
leverage the puppetforge firewall module from puppetlabs? (
https://docs.puppetlabs.com/puppet/latest/reference/subsystem_catalog_compilation.html
) or something else?
Yes, this uses a firewall resource from the puppetlabs/firewall module.
2) How does this handle a client instance going away?
Every server that has its firewall managed by this module will normally
be set up with the 'purge' option. This means that any firewall rule not
in the catalogue will be removed from the firewall config.
https://forge.puppetlabs.com/puppetlabs/firewall#beginning-with-firewall
How soon the firewall rule will actually disappear depends on the
deactivation timeout for exported resources in PuppetDB, and whether you
properly decommission nodes when you shut them down. I think by default
if a node is destroyed, its exported resources are deactivated after 30
days, after which time your server will remove the firewall rule next
time it checks in. You can speed up the process by issuing 'puppet node
deactivate xyz.example.com' on your puppetmaster.
If your database client checks in and doesn't declare the exported
resource (i.e. if you edit the manifest), it will disappear from the
database server on the next run anyway.
Our experience is that the system works absolutely fine in our site of
about 80 nodes, provided we remember to issue 'puppet node deactivate'
when we kill off an old server.
Cheers,
Jonathan
-Jason
On Mon, Jan 26, 2015 at 4:28 AM, Jonathan Gazeley
<[email protected]
<mailto:[email protected]>> wrote:
I have done exactly this with a MariaDB cluster. Each client that
needs to access the database includes a class called
mariadb::client which includes this snippet:
# Auto-add a firewall rule in the MySQL and MariaDB server just
for us
@@firewall { "100-mariadb-${::fqdn}":
proto => 'tcp',
dport => '3306',
tag => 'mariadb',
source => $::ipaddress,
action => 'accept',
}
And then the MariaDB server realises all of those resources in its
server class:
# MariaDB firewall rules for clients
Firewall <<| tag == 'mariadb' |>>
It works nicely, but the only flaw is that when you build a new
system, it is not immediately able to use the database, and you
have to wait until after the database server has also checked in
with Puppet.
Cheers,
Jonathan
On 23/01/15 22:15, Jason Price wrote:
Problem statement:
I have a Database server, and I have an arbitrary number of
clients. I wish to collect the client IP addresses, and build
out a set of firewall rules on the DB server to allow the client
IPs to connect.
Bonus points if something can be purged out if it hasn't called
home to puppet in 48 hours (or something similar)
(technically, I need to do it both directions, since the DB is
Cassandra, and the number of nodes can grow there too, and the
clients need to be able to have firewall rules for each of those,
but one problem at a time)
Does puppet offer a canonical solution for this problem?
In searching around, using Exported Resources with puppetdb seems
like a good start, but there are numerous challenges with this
approach: mostly in leveraging those IP addresses in an ERB (to
drive the firewall rules).
Other searching lead to the ConCat module, but that seems to only
work within the context of a single client and doesn't seem to be
queryable by other clients.
Thanks for any insights;
Jason
--
You received this message because you are subscribed to the
Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAChvjRC-t90oYDZJyFztkRX2J9E3riC-Ns2%3DQjJuNucfV%2BDEtg%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-users/CAChvjRC-t90oYDZJyFztkRX2J9E3riC-Ns2%3DQjJuNucfV%2BDEtg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54C608BA.9070300%40bristol.ac.uk
<https://groups.google.com/d/msgid/puppet-users/54C608BA.9070300%40bristol.ac.uk?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAChvjRDZc0FOZccAqacD%3D9-kPNwJsAj2A_aCjBiZZZXc3a8c8Q%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-users/CAChvjRDZc0FOZccAqacD%3D9-kPNwJsAj2A_aCjBiZZZXc3a8c8Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54C66F07.1030902%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.
