Only block the specific port Weave Net is listening on.
Add a comment so users know what the rule is for.
Remove the rule added in v2.6.3 because it was too coarse.
We expect the loopback address 127.0.0.1 to be accessible only from
the local host.
We need to allow RELATED,ESTABLISHED traffic which may be the return
path of a Kubernetes HostPort.
We need two rules:
* `-A INPUT -i weave -j WEAVE-NPC-EGRESS`: applies to packets destined
to a local node.
* `-A FORWARD -i weave -j WEAVE-NPC-EGRESS`: the rest. It can match
an ingress packet.
- Track only local changes.
- Add comment to the iptables rule which prevents SNAT'ing.
- Rename the ipset to weaver-no-masq-local to prevent NPC from destroying it.
- Fix comment about create/flush WEAVE-EXPOSE.
- Add comment about reexpose being no-op if bridge hasn't been exposed.
- Add comment that the feature is not only for Kubernetes.
- Reuse the ipset instance.
"weave attach $CIDR $CONTAINER_ID" is no longer possible w/o
running weaver. This feature was undocumented and complicated
the weave script, as "weave attach" required to call "create_bridge".
Removing the feature allows us to eliminate the bridge creation
from the script.
Running "weave attach" w/o weaver results in the following err:
bridge "weave" not present; did you launch weave?
Also, this commit simplifies the "attach-container" cmd from
weaveutil by removing "mtu" as a param. The cmd is used
only by "weave attach", and a mtu is value for an attached
container interface is exactly the same as one of the weave bridge.
Both cmds depend on running weaver which creates the bridge
during its initialization. So, calling "create_bridge"
during execution of the cmds is redundant.
Now we don't bundle the docker command inside weaveexec, we need to do
an explicit 'docker pull' to ensure the images are there.
Also set the weavedb tag to :latest to remove a warning from docker
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(https://github.com/moby/moby/pull/28257) which makes containers
inaccessible from a remote host when the bridge is exposed.
The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.
The chain is a target of the rule "-t filter -A FORWARD -o weave".
The change makes "weave expose" to call the "/expose" HTTP
endpoint implemented in router which exposes the bridge.
Such architectural change required as we need to know whether NPC is
enabled when exposing the bridge and weaver knows this fact the best.
Unfortunately, this change makes impossible to "weave expose"
when weaver is not running.
`weaveexec` no longer mounting '/' so we can't access the weavedb file
to get persistent peer ID. If `weaver` was running, we couldn't have
read the file anyway because BoltDB does not support concurrent access
from two processes.
Consequence is that if someone really does need the bridge creation on
'weave expose' the peer ID may change if created pre-1.9.0. We'll just
live with that (per @bboreham).
Fixes#2957
- replace `docker stop` with `weaveuitl stop-container`
- replace `docker kill` with `weaveutil kill-container`
- replace `docker rm` with `weaveutil remove-container`
- replace `docker run` with minimal `weaveutil container-run`
- replace `docker inspect -f {{.ID}}` with `weaveutil container-id`
- replace data-only container `docker create` with `weaveutil create-volume-container`
- remove `docker inspect` dependencies from `weave` script
`rewrite_etc_hosts` and `with_container_fqdn`
- rework `weave` script `check_running` and `check_not_running` to use `weaveutil`
- rework `weave version` to use `weaver` /report API or `weaver --version` if not running
- rework `weave setup`'s `docker pull` to run locally rather than in `weaveexec` container
There are 3 ways to get help:
• weave --help
• weave help
• weave <command> --help
At the moment, only the first one prints the usage instantaneously, the
others go much further in the script and take quite some time, which is
not idea of impatient users.
Note that "help" only works because it's not a recognized command and
ends up in the default case of "case $COMMAND" (and indeed, "Unknown
weave command 'help'" is displayed). This is because handle_help_arg()
always returns true and so the second part of:
handle_help_arg "$1" || handle_help_arg "--$1"
is never evaluated.
This commit changes things a bit so all 3 ways to get help are
recognized early, print the usage and exit.
`proxy_parse_args` is currently called:
- once, all the time
- again, if Docker is configured with TLS.
If a second call to `proxy_parse_args` happens, given the way we append to `PROXY_ARGS` and merge proxy and remaining args, genuine arguments like peers can be mixed with flags/options/etc. hence forming an invalid peers list and crashing Weave Net.
Raj Chaudhuri