On 3/6/19 7:11 AM, Niko Mayr wrote:
>> I was able to see, however, that you have re-introduced the WIDE_TC_MARKS
>> option to the default shorewall.conf. Don't do that - that option has
>> been superseded for some time.
>
> Thanks for clarification. I got the error message "ERROR: shorewall.conf
> does not set option WIDE_TC_MARKS at
> /root/shorewall/tools/build/annotate.pl line 37."
> when trying to build, so I gave it a shot. Wanted to remove it
> afterwards, as it's not directly related.
>
>> I believe that:
>> 1) The order in which Docker and Shorewall are started should not matter.
>> 2) Either product should be able to be started, stopped, restarted or
>> reloaded without effecting the other product.
>
> Yes that would be ideal. Seems like something each product would need to
> take care of.
> As Docker decided to add ACCEPT rules which are hit if the jumps in the
> FORWARD chain aren't removed, Shorewall
> needs to have the last word. Thus in our current approach Shorewall
> needs to be reloaded after a start/restart of
> Docker, as the jumps in the FORWARD chain would be re-added.
>
>> When Shorewall executes a 'start', 'stop', or 'reload' ('restart' is a
>> 'stop' followed by a 'start'), it saves all Docker-related chains and
>> rules, then integrates them into the new configuration.
>
> Actually it looks like Shorewall-5.2.3 drops rules (that were added
> after start) on restart, while conserving them on reload.
>
>> The problem with that approach is that when Docker adds something new,
>> that
>> new content doesn't get saved/restored by Shorewall. That fundamental
>> weakness in the current design caused me to consider dropping Docker
>> support entirely in Shorewall 5.2.
>
> Maybe that's the problem in the issue above. Or do you mean the short
> window between export/re-import of existing rules on start (or is that
> performed atomically like mentioned). It might be possible to not
> re-import the state before Shorewall was started, but clean the current
> state when Shorewall is stopped.
>
> Generally it's probably not ideal to blow up Shorewall with special
> integrations for other iptables using products.
> Maybe the general conserving integration with hooks (like already given
> with extension scripts) is an adequate choice.
> We went for further integration as it's partially there and implementing
> the missing parts in extension scripts
> also felt unsatisfactory and it looked like just a few changes.
>
>> If I ran Docker ...
>
> We thought about scenarios like that, but didn't want to add the
> virtualization layer at first. Maybe we could also reconsider that.
> If an integration could fulfill your two precepts I'd prefer that.
>
> Thanks,
> Niko
>
I finally got a chance to look at your patch. The biggest thing that
jumps out is that you have overloaded Swarm mode onto the script-global
variable g_dockeringress. This will break configurations which have
DOCKER-INGRESS in the filter table but not in the nat table. I think
that a new global variable ('g_dockerswarm', perhaps) needs to be
introduced to to track the new functionality.
-Tom
--
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
