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.