Hi Felix, Hunter

Thanks for the responses.

There's no doubt that it's a tricky feature to write, but having the 
feature would be a big win for the community and my customers.  So I'd 
really like to do this, and I'm sure if we put our heads together we can 
come up with the best design possible.

I am playing in my mind with a few ways of doing this.

1.

Suppose we have two rules as follows:

ACCEPT     tcp  --  1.1.1.1/24           0.0.0.0/0           multiport 
dports 80,443 /* 100 allow http and https access */ 

ACCEPT     tcp  --  2.2.2.2/24           0.0.0.0/0           multiport 
dports 80,443 /* 100 allow http and https access */ 

The provider could be modified so as to represent these as:

firewall { '100 allow http and https access':                              
                                                                            
                        

  ensure             => 'present',

  action             => 'accept',

  chain              => 'INPUT',

  checksum_fill      => 'false',

  clamp_mss_to_pmtu  => 'false',

  clusterip_new      => 'false',

  dport              => ['80', '443'],

  isfragment         => 'false',

  kernel_timezone    => 'false',

  log_uid            => 'false',

  physdev_is_bridged => 'false',

  proto              => 'tcp',

  random             => 'false',

  rdest              => 'false',

  reap               => 'false',

  rsource            => 'false',

  rttl               => 'false',

  socket             => 'false',

  source             => ['1.1.1.1/24', '2.2.2.2/24'],

  table              => 'filter',

  time_contiguous    => 'false',

}


How?  I don't know yet.  At first glance it's hard to see why this would be 
a hugely difficult coding problem, but I suspect that many unpleasant 
edge-cases that I haven't thought of yet lie in wait for me, and that's why 
I lean to option 2.

2.

Add to the firewall module (or perhaps a new Forge module) a defined type 
that wraps around the existing firewall types/providers.  In Puppet 4, that 
should be easy to do in the DSL using an iterator; but because I'd like to 
support Puppet 3 as well, it's a bit trickier.  Still, quite doable.  The 
hardest part seems to be thinking up a name for the new type.  Any 
suggestions?

Best regards,
Alex


On Friday, February 12, 2016 at 11:35:33 AM UTC+11, Hunter Haugen wrote:
>
> The difficulty with allowing multiple sources is that it falls in line 
> only with a scripted workflow, not an idempotent workflow. This is from the 
> iptables manpage: "Multiple addresses can be specified, but this will 
> expand to multiple rules (when adding with -A), or will cause multiple 
> rules to be deleted (with -D)."
>
> Converting the firewall type to manage multiple rules with a single 
> resource is surely the way to madness ;).
>
>
>
>
> -Hunter
>
> On Thu, Feb 11, 2016 at 2:33 PM, Felix Frank <felix...@alumni.tu-berlin.de 
> <javascript:>> wrote:
>
>> On 02/09/2016 06:41 AM, Alex Harvey wrote:
>>
>>> Can I get some feedback at this early stage that my PR would be 
>>> accepted, assuming I can come up with a clean, working solution?
>>>
>>
>> Hi,
>>
>> I don't think that anyone will be able to answer this without at least 
>> looking at what you're building, or intend to.
>>
>> From experience, cool features like this have good chances, *unless* they 
>> come with some pitfalls or a catch that the maintainer (Puppet Labs?) is 
>> not willing to accept.
>>
>> As for the feature you're looking at: My gut tells me that you might not 
>> be able to come up with a clean model to support all that. Multiple 
>> destination ports should not be problematic, thanks to netfilter's 
>> multiport module.
>>
>> But multiple addresses get expanded into distinct rules, IIRC. This 
>> likely cannot be reconciled with Puppet's resource model, or not without 
>> introducing some bizarre semantic tricks.
>>
>> So my advice is to open a PR as soon as possible, even if the feature 
>> does not work yet, just to showcase your approach and gather the feedback 
>> you came seeking here.
>>
>> HTH,
>> Felix
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/56BD0C52.80307%40Alumni.TU-Berlin.de
>> .
>>
>> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/70047aa9-3d3d-4388-88a8-0a856e94dd76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to