Re: [Puppet Users] puppetlabs-firewall scope
Hi Louis,
Did you ever find a workaround for this problem? I'm experiencing the same
thing, where the existing rules are not all purged at once so it causes the
other resources to time out. This can last for up to 10 minutes so it can
cause some problems.
Jeff
On Sunday, December 9, 2012 7:22:58 AM UTC+11, Lofic wrote:
Thanks a lot. Indeed, in that way it leaves my untargeted nodes alone.
And I feel it's cleaner than putting things in the site.pp.
However I still have one little problem : at first application on some fw
rules on a node with puppet, the purge of preexisting rules is slow,
blocking the network temporarily.
Hopefully it comes back after a while.
I don't have this annoyance if I 'iptables -F' first.
See an example below.
I can work with that but if you have a workaround you're welcome.
Louis Coilliot
Info: Applying configuration version '1354997226'
/Firewall[ fe701ab7ca74bd49f13b9f0ab39f3254]/ensure: removed
/Firewall[ a627067f779aaa7406fa9062efa4550e]/ensure: removed
/Firewall[ 49bcd611c61bdd18b235cea46ef04fae]/ensure: removed
Error: /File[nagios.vim]: Could not evaluate: Connection timed out -
connect(2) Could not retrieve file metadata for
puppet:///modules/nagios/nagios.vim: Connection timed out - connect(2)
Error: /File[nagiosvim-install.sh]: Could not evaluate: Connection timed
out - connect(2) Could not retrieve file metadata for
puppet:///modules/nagios/nagiosvim-install.sh: Connection timed out -
connect(2)
Error: /File[/etc/vimrc]: Could not evaluate: Connection timed out -
connect(2) Could not retrieve file metadata for
puppet:///modules/vim/vimrc: Connection timed out - connect(2)
/Firewall[ b205c9394b2980936dac53f8b62e38e7]/ensure: removed
/Firewall[000 accept all icmp]/ensure: created
Info: /Firewall[000 accept all icmp]: Scheduling refresh of
Exec[persist-firewall]
/Firewall[ d53829245128968bfa101d5214694702]/ensure: removed
/Firewall[001 accept all to lo interface]/ensure: created
Info: /Firewall[001 accept all to lo interface]: Scheduling refresh of
Exec[persist-firewall]
/Firewall[002 accept related established rules]/ensure: created
Info: /Firewall[002 accept related established rules]: Scheduling refresh
of Exec[persist-firewall]
/Firewall[003 accept SSH]/ensure: created
Info: /Firewall[003 accept SSH]: Scheduling refresh of
Exec[persist-firewall]
/Firewall[999 drop all on INPUT eventually]/ensure: created
Info: /Firewall[999 drop all on INPUT eventually]: Scheduling refresh of
Exec[persist-firewall]
/Firewall[999 drop all on FORWARD eventually]/ensure: created
Info: /Firewall[999 drop all on FORWARD eventually]: Scheduling refresh of
Exec[persist-firewall]
/Stage[main]/Firewall/Exec[persist-firewall]: Triggered 'refresh' from 6
events
Finished catalog run in 196.45 seconds
Le 07/12/2012 20:34, Shawn Foley a écrit :
I created a firewall module. In firewall/manifests/init.pp i have the
following.
class firewall {
## Always persist firewall rules
exec { 'persist-firewall':
command = '/sbin/iptables-save /etc/sysconfig/iptables',
refreshonly = true,
}
## These defaults ensure that the persistence command is executed after
## every change to the firewall, and that pre post classes are run in
the
## right order to avoid potentially locking you out of your box during
the
## first puppet run.
Firewall {
notify = Exec['persist-firewall'],
before = Class['firewall::post'],
require = Class['firewall::pre'],
}
Firewallchain {
notify = Exec['persist-firewall'],
}
## Purge unmanaged firewall resources
##
## This will clear any existing rules, and make sure that only rules
## defined in puppet exist on the machine
resources { 'firewall': purge = true }
## include the pre and post modules
include firewall::pre
include firewall::post
}
Then you just include firewall
Shawn Foley
425.281.0182
On Tue, Dec 4, 2012 at 12:36 PM, Louis Coilliot
louis.c...@think.frjavascript:
wrote:
Hello,
I can't figure out how I can use the module puppetlabs-firewall only
for some targeted nodes.
If I put :
resources { firewall: purge = true }
in top scope (i.e. site.pp),
then all the firewall rules on all my nodes are purged. Even for nodes
for which I don't apply any module containing specific firewall { ...
} resources.
If I put it in a module (i.e. myfw ), then for all nodes where I
apply a module containing firewall resources, I got a mix of the
previous rules (defined locally with the OS) and the new ones provided
with puppet.
Did I miss something or is it the expected behaviour ?
If this is expected, is there a workaround to apply the purge of the
rules only for some nodes where I want to apply specific firewall
rules through modules and puppet-firewall ?
Thanks in advance.
Louis Coilliot
--
You received this message because you are
Re: [Puppet Users] f5 module usage/debugging tips?
Hi Chris,
I think I've narrowed the issue down.
I'm able to use the 10.2.0.2 f5 gem in a simple script with F5 v11.3.0 to
create an f5_node so it looks like the F5 is keeping some
backwards-compatibility.
The problem is only occurring when the F5 gem is used within puppet. The f5
gem is using the ruby 1.8.7's built-in SOAP library that clashes with a
monkey-patch in Puppet to override the instance_variables method of the
basic Ruby Object class.
The patch was introduced in this
commit:
https://github.com/puppetlabs/puppet/commit/1f4e44c26a0d703d1192d26ef8ab555e4508e338
*lib/puppet/util/monkey_patches.rb*:
class Object
alias :puppet_original_instance_variables :instance_variables
def instance_variables
puppet_original_instance_variables.map(:to_sym)
end
end
This in turn clashes with the SOAP class in Ruby 1.8.7:
lib/soap/mapping/mapping.rb:
def self.get_attribute(obj, attr_name)
if obj.is_a?(::Hash)
obj[attr_name] || obj[attr_name.intern]
else
name = XSD::CodeGen::GenSupport.safevarname(attr_name)
if obj.instance_variables.include?('@' + name)
obj.instance_variable_get('@' + name)
elsif ((obj.is_a?(::Struct) or obj.is_a?(Marshallable)) and
obj.respond_to?(name))
obj.__send__(name)
end
end
end
Since Puppet has overridden the instance_variable method to return an Array
of Symbols, this breaks the obj.instance_variables.include?('@' + name)
line because it is trying to compare a Symbol with a String which will
always be false. This in turn causes the F5 gem to send SOAP requests to
the F5 with nil values so the nodes are never created on the F5.
This is a pretty strange issue as I thought that there would have been
other users of the puppetlabs-f5 module with Ruby 1.8.7 and so would have
hit the same issue, or am I missing something?
Anyway, it looks like to fix the problem we'll either need to patch the F5
gem to override the above method within Ruby or somehow revert the
monkeypatch in Puppet for the F5 puppet module, unless you can think of a
cleaner and better solution?
Jeff
On Wednesday, June 12, 2013 3:34:02 PM UTC+10, Christopher Wood wrote:
Unfortunately due to various non-puppet bigip upgrade issues I haven't
been able to back to this yet. If I get anything useful working I will
post.
On Tue, Jun 11, 2013 at 03:32:56AM -0700, jgm...@gmail.com
javascript:wrote:
Hi Chris,
How did you go with trying to use the Puppet F5 module with v11.3.0?
I
think I am having the same issue as you were.
The puppet output would say that the resource was created but the
iControl
debug logs shows that it is being sent an empty SOAP create message.
I've tried running a simple ruby script using the 10.2.0.2 f5 gem and
was
able to create the node successfully so it looks the Puppet is doing
something funny.
Any help would be greatly appreciated.
Thanks,
Jeff
On Tuesday, February 12, 2013 8:31:04 AM UTC+11, Christopher Wood
wrote:
On Mon, Feb 11, 2013 at 12:40:12PM -0800, Nan Liu wrote:
On Mon, Feb 11, 2013 at 8:27 AM, Christopher Wood
[1][1]christop...@pobox.com wrote:
(Following up to my own post for posterity's sake, see
[2][2]xkcd.com/979.)
Short form: for me this isn't yet as easy as a file resource
but
the
puppetized management payoff will be worth the work. My
issues
are most
likely a reflection of my own puppet/ruby/iControl/SOAP
skill.
I am going to explore a personalized set of F5
types/providers
that I
can use without first loading up the wsdl file for every
involved
iControl interface, version, and hotfix.
Points from my various BigIP/puppet experimentations:
a) The f5-icontrol-10.2.0.2.gem doesn't necessarily work
with LTM
11.1.0. (Or I haven't figured it out, also quite likely.)
This
could be
because the gem ships different wsdl files but I couldn't
get it
to work
with later iControl wsdl files anyway.
b) In LTM 11, F5 deprecated some interfaces so puppet f5
module
providers like f5_node are suddenly using deprecated
interfaces.
c) Some parts of the iControl api are being updated/fixed
over
time, for
instance the hotfix id 388590 reading Certificates can now
successfully
be updated using the iControl Management::KeyCertificate
interface,
see:
[3][3]
http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14175.html
d) Judging by my soap-newbie eye the soap4r package appears
Re: [Puppet Users] f5 module usage/debugging tips?
Hi Chris, How did you go with trying to use the Puppet F5 module with v11.3.0? I think I am having the same issue as you were. The puppet output would say that the resource was created but the iControl debug logs shows that it is being sent an empty SOAP create message. I've tried running a simple ruby script using the 10.2.0.2 f5 gem and was able to create the node successfully so it looks the Puppet is doing something funny. Any help would be greatly appreciated. Thanks, Jeff On Tuesday, February 12, 2013 8:31:04 AM UTC+11, Christopher Wood wrote: On Mon, Feb 11, 2013 at 12:40:12PM -0800, Nan Liu wrote: On Mon, Feb 11, 2013 at 8:27 AM, Christopher Wood [1]christop...@pobox.com javascript: wrote: (Following up to my own post for posterity's sake, see [2] xkcd.com/979.) Short form: for me this isn't yet as easy as a file resource but the puppetized management payoff will be worth the work. My issues are most likely a reflection of my own puppet/ruby/iControl/SOAP skill. I am going to explore a personalized set of F5 types/providers that I can use without first loading up the wsdl file for every involved iControl interface, version, and hotfix. Points from my various BigIP/puppet experimentations: a) The f5-icontrol-10.2.0.2.gem doesn't necessarily work with LTM 11.1.0. (Or I haven't figured it out, also quite likely.) This could be because the gem ships different wsdl files but I couldn't get it to work with later iControl wsdl files anyway. b) In LTM 11, F5 deprecated some interfaces so puppet f5 module providers like f5_node are suddenly using deprecated interfaces. c) Some parts of the iControl api are being updated/fixed over time, for instance the hotfix id 388590 reading Certificates can now successfully be updated using the iControl Management::KeyCertificate interface, see: [3] http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14175.html d) Judging by my soap-newbie eye the soap4r package appears abandonware, savon isn't up to complicated data structures and I have yet to dive into handsoap (the starter page says to start with a wsdl, see my wsdl-tracking issues). Picking the right soap package to use is likely going to be job 1. (If the list has any feedback to the above, I'm very much all ears.) Have you tried the v11 gem?�[4]https://devcentral.f5.com/internal-forums/aff/2306. The module certainly needs to updates against v11 API, but seems like it would be a better starting point. Nan� I might give that a go. That LTM 11 gem is for 11.1.0 and I'm already on 11.3.0 in the lab due to a key/cert management issue, but the gem should be fine if I rebuild it with the wsdl files from my lab device. -- 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 puppet-users...@googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript:. Visit this group at [5] http://groups.google.com/group/puppet-users?hl=en. For more options, visit [6]https://groups.google.com/groups/opt_out. References Visible links 1. mailto:christop...@pobox.com javascript: 2. http://xkcd.com/979 3. http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14175.html 4. https://devcentral.f5.com/internal-forums/aff/2306 5. http://groups.google.com/group/puppet-users?hl=en 6. https://groups.google.com/groups/opt_out -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
