On 3/4/2020 5:53 PM, Tom Eastep wrote:
> On 3/4/20 8:26 AM, Tom Eastep wrote:>
> > The generated script probes the current netfilter configuration
> > looking for Docker-generated chains. It does that by using the
> > iptables -L command. In the trace, we see:
>
> > + chain_exists DOCKER-ISOLATION-STAGE-1 + qt1 /sbin/iptables --wait
> > -t filter -L DOCKER-ISOLATION-STAGE-1 -n + local status + [ 1 ] +
> > /sbin/iptables --wait -t filter -L DOCKER-ISOLATION-STAGE-1 -n +
> > status=1 + [ 1 -ne 4 ] + return 1
>
> > The relevant shell code is:
>
> > qt1() { local status
>
> > while [ 1 ]; do "$@" </dev/null >/dev/null 2>&1 status=$? [ $status
> > -ne 4 ] && return $status done } ... chain_exists() # $1 = chain
> > name, $2 = table name (optional) { qt1 $g_tool -t ${2:-filter} -L
> > $1 -n } ... g_tool=/sbin/iptables --wait ... chain_exists
> > DOCKER-ISOLATION-STAGE-1 && dockerisostage=Yes ...
>
> > So the command /sbin/iptables --wait -t filter -L
> > DOCKER-ISOLATION-STAGE-1 -n is failing with exit status 1!
>
> > If there was a problem with the syntax of the command (which there
> > isn't), the exit status would have been 2.
>
> > This is curious, since in the output you posted we see that the
> > chain definitely does exist just prior to the attemted restart.
>
> > Chain DOCKER-ISOLATION-STAGE-1 (1 references) 0 0
> > DOCKER-ISOLATION-STAGE-2 all -- docker0 !docker0 anywhere
> > anywhere 0 0 DOCKER-ISOLATION-STAGE-2 all --
> > br-ac3db22b180b !br-ac3db22b180b anywhere anywhere 22
> > 5235 DOCKER-ISOLATION-STAGE-2 all -- br-61206706fa14
> > !br-61206706fa14 anywhere anywhere
>
> > The command succeeds for other chains:
>
> > + chain_exists DOCKER-USER + qt1 /sbin/iptables --wait -t filter -L
> > DOCKER-USER -n + local status + [ 1 ] + /sbin/iptables --wait -t
> > filter -L DOCKER-USER -n + status=0 + [ 0 -ne 4 ] + return 0 +
> > g_dockeruser=Yes
>
> > In fact, chain_exists() has been around for years and is used in
> > many places in Shorewall (both in the CLI and in the generated
> > firewall script).
>
> > After sending my post yesterday, I did find a bug in the code that
> > would also cause the DOCKER-ISOLATION-STAGE-* chains to be
> > dropped. I've attached a patch to fix that.
>
> > My only suggestion is to temporarily modify qt1 (it is in
> > /usr/share/shorewall/lib.common) to remove the redirection of
> > standard error (remove the '2>&1'). That will result in spurious
> > iptables error messages, but at least the trace will then show why
> > the 'iptables -L' command intermittently fails on your system.
>
> > One final thing -- the failing logic is executed for start, stop,
> > restart and reload so presumably any of these commands can loose
> > Docker chains.
>
>
> Today, we have set up a couple of Docker test beds (One on Debian and
> one on Foobar (a rhel7 derivative)).
>
> Found another bug in my recent changes -- patch attached.
>
> I also understand the issue with 'systemctl restart shorewall' on
> Debian[-derived] systems. The Debian standard for 'start' and 'stop'
> says that the 'stop' command must undo the effect of 'start'. As you
> know, the 'shorewall stop' command doesn't really do that; it rather
> places the firewall in a 'safe' state. To work around this issue,
> 'systemctl stop shorewall' actually does a 'shorewall clear'.
>
> Back in the days of SysV init, the /etc/default/shorewall file set a
> flag that told /etc/init.d/shorewall to do a 'clear' rather than a
> 'stop'. The file was shipped with flag set, but users could reset it
> if desired (at the risk of having update/upgrade issues). When we went
> to systemd, that was no longer feasible, so the shorewall.service file
> released with Debian has the following:
>
> ExecStop=/sbin/shorewall $OPTIONS clear
>
> Note that systemd does not support 'ExecRestart=...' in the .service
> file, but rather executes the 'ExecStop' command followed by the
> 'ExecStart' command. This obviously looses Docker rules.
>
> I won't be releasing any change regarding this issue until at least
> 5.2.4. In the mean time, you can avoid using 'systemctl restart
> shorewall' and use 'shorewall restart' instead. Or you can modify the
> above line in the .service file to read:
>
> ExecStop=/sbin/shorewall $OPTIONS stop
>
> followed by 'systemctl daemon-reload'.
>
> Note that this issue is independent of the 'iptables -L' issue in my
> prior post. Nevertheless, the attached patch *is* required to make the
> code work correctly otherwise.
>
> -TomSorry to butt in, but it's worth noting that Systemd has a feature called "drop-in overrides" that can alleviate this inconsistency for people for whom it's an issue. Instead of modifying the shorewall.service file in `/lib/systemd/system/`, type (as root): `systemctl edit shorewall.service`. This will open the default terminal editor to a blank file in which you can paste the following: [service] # reset ExecStop ExecStop= # set ExecStop to "stop" instead of "clear" ExecStop=/sbin/shorewall $OPTIONS stop Then type `systemctl daemon-reload` to activate the changes. This change will survive future updates of the shorewall package from apt repositories. The override file itself will be saved to `/etc/systemd/system/shorewall.service.d/`. -- - J Cliff Armstrong - AKA JadedDragoon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
