Rules no longer need to be rearranged when creating a network.
Per-network rules are always appended to the FORWARD chain so,
after adding them, there's no need to delete the per-driver
rules to re-insert them at the top of the chain.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Go automatically canonicalises HTTP headers, meaning the string `API-Version` passed as a header has always been returned as `Api-Version`. Similarly, `OSType` is returned as `Ostype`.
This commit updates the documentation to reflect this behaviour and modifies the codebase to ensure that input strings are aligned with their canonical output values.
Signed-off-by: maggie44 <64841595+maggie44@users.noreply.github.com>
Commit facb2323 aligned the way the default bridge's IPv6 subnet
and gateway addresses are selected with IPv4.
Part of that involved looking at addresses already on the bridge,
along with daemon config options. But, for IPv6, the kernel will
assign a link-local address to the bridge.
Make sure that address is ignored when selecting "bip6" when it's
not explicitly specified.
This is made slightly complicated because we allow fixed-cidr-v6
to be a link-local subnet (either the standard "fe80::/64", or
any other non-overlapping LL subnet in "fe80::/10").
Following this change, if fixed-cidr-v6 is (or is included by)
"fe80::/64", the bridge's kernel-assigned LL address may be used
as the network's gateway address - even though it may also get an
IPAM-assigned LL address.
Signed-off-by: Rob Murray <rob.murray@docker.com>
These tests create iptables rules for different addresses on
docker0 but, unlike tests that do that for user-defined bridges,
those rules aren't removed when the test deletes the network,
because the default bridge network can't be deleted.
So, use (abuse) the L3Segment code to run the tests in their
own network namespace.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Same as "nat" mode, there's masquerading and port mapping from the
host - but no port/protocol filtering for direct access to the
container's address from remote hosts.
This is the old default behaviour for IPv4 when the filter-FORWARD
chain's default policy was "ACCEPT" (the daemon would only set it
to "DROP" when it set sysctl "ip_forward" itself, but it didn't set
up DROP rules for unpublished ports).
Now, port filtering doesn't depend on the filter-FORWARD policy. So,
this mode is added as a way to restore the old/surprising/insecure
behaviour for anyone who's depending on it. Networks will need to
be re-created with this new gateway mode.
Signed-off-by: Rob Murray <rob.murray@docker.com>
This new field is used by libnetwork to determine which endpoint
provides the default gateway for a container.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Use the same logic to generate IPAMConf for IPv6 as for IPv4.
- When no fixed-cidr-v6 is specified, rather than error out, use
the default address pools (as for an IPv4 default bridge with no
fixed-cidr, and as for user-defined networks).
- Add daemon option --bip6, similar to --bip.
- Necessary because it's the only way to override an old address
on docker0 (daemon-managed default bridge), as illustrated by
test cases.
- For a user-managed default bridge (--bridge), use IPv6 addresses
on the user's bridge to determine the pool, sub-pool and gateway.
Following the same rules as IPv4.
- Don't set up IPv6 IPAMConf if IPv6 is not enabled.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a user-managed bridge is used for the default network (--bridge),
an address from the bridge determines the subnet for the network.
If a fixed-cidr is supplied, it should fall within that subnet. If it
doesn't, it's a misconfiguration - fixed-cidr is the range of
allocatable addresses, and they need to be in the network. (Either
the user's bridge is missing an address that matches their fixed-cidr
or the fixed-cidr is wrong.)
When this happens, because it's been allowed in the past (and, because
the address-pool implementation treats fixed-cidr/SubPool as an offset
into the network rather than an actual address range, so working IP
addresses would normally still be assigned to containers) ... don't
reject the config and cause daemon startup to fail. Just log a warning
and ignore fixed-cidr.
Signed-off-by: Rob Murray <rob.murray@docker.com>
For a docker-managed default bridge (docker0), when no --bip is
supplied, the gateway address and subnet size can be inferred
from existing bridge addresses.
But, if fixed-cidr's subnet size is increased so that it's biggger
than the subnet of the bridge's existing address - the bridge's
subnet needs to be incresed to match. (fixed-cidr determines the
range of addresses that can be automatically allocated, and these
should not fall outside the default bridge's subnet.)
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a docker-managed default bridge (docker0) already has an
address, and the fixed-cidr subnet fits within the subnet defined
by that address, the existing address should be used as the
gateway and to define the subnet.
But, when fixed-cidr is changed, no --bip is supplied, and no
existing bridge network includes fixed-cidr ... the existing
bridge address needs to be updated.
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a user-managed bridge is used instead of docker0 (--bridge), with
a fixed-cidr - the bridge should have an IP address/subnet that
encompasses fixed-cidr ... the bridge address's subnet then defines
the network's subnet, and fixed-cidr defines the allocatable range
within that.
But, selection of the correct subnet/address from the bridge depended
on the address being within fixed-cidr (within the allocatable range).
This change removes that assumption. So, a bridge address with a
subnet that includes fixed-cidr is selected.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Becuase I'm about to add tests that use netlink, and the netlink
package breaks compilation under Windows.
Signed-off-by: Rob Murray <rob.murray@docker.com>
If we have an error type that we're checking a substring against, we
should really be checking using ErrorContains to indicate the right
semantics to assert.
Mostly done using these transforms:
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.ErrorContains(e, s)) -> assert.ErrorContains(t, e, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.Contains(err.Error(), s)) -> assert.ErrorContains(t, err, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Check(t, is.Contains(err.Error(), s)) -> assert.Check(t, is.ErrorContains(err, s))'
As well as some small fixups to helpers that were doing
strings.Contains explicitly.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
If a values is non-nil when we don't expect it, it would be quite
helpful to get an error message explaining what happened.
find . -type f -name "*_test.go" | \
xargs gofmt -w -r "assert.Assert(t, a == nil) -> assert.Assert(t, is.Nil(a))"
find . -type f -name "*_test.go" | \
xargs gofmt -w -r "assert.Check(t, a == nil) -> assert.Check(t, is.Nil(a))"
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Migrated using
find . -type f -name "*_test.go" |
xargs gofmt -w \
-r "assert.Check(t, strings.Contains(a, b)) -> assert.Check(t, is.Contains(a, b))"
find . -type f -name "*_test.go" |
xargs gofmt -w \
-r "assert.Assert(t, strings.Contains(a, b)) -> assert.Assert(t, is.Contains(a, b))"
Using a boolean in assert.Assert or assert.Check results in error
messages that don't contain the actual problematic string, and when
running the integration suite on an actual machine (where the source
code parsing doesn't work) this makes it almost impossible to figure out
what the actual error is.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Set the daemon.json config as a string-literal in the tests, instead of
using a map[string]interface{} as intermediary format.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add an integration test to check that a container on a network
with gateway-mode=nat can access a container on a network with
gateway-mode=routed, but not vice-versa.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The default for a user-defined chain is RETURN anyway.
This opens up the possibilty of sorting rules into two groups
by using insert or append, without having to deal with appending
after the unconditional RETURN.
Signed-off-by: Rob Murray <rob.murray@docker.com>
We don't yet support this at the API level, so for now it returns
an error when trying to set multiple, but this makes sure that the
client types are already ready for this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`ImageManifestDescriptor` will contain an OCI descriptor of
platform-specific manifest of the image that was picked when creating
the container.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Some other tests on this file where skipped with this same line. Let's
skip this one, that seems to be flaky too.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
Delete the entries that were added, rather than looking at the service
map (DNS config) and trying to delete entries without accounting for
the container's --hostname.
Signed-off-by: Rob Murray <rob.murray@docker.com>
integration/service/update_test.go:290:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
integration/network/bridge/bridge_linux_test.go:177:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
integration/system/disk_usage_test.go:261:5: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
integration/volume/volume_test.go:202:3: The copy of the 'for' variable "ep" can be deleted (Go 1.22+) (copyloopvar)
ep := ep
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
integration/build/build_test.go:95:3: The copy of the 'for' variable "c" can be deleted (Go 1.22+) (copyloopvar)
c := c
^
integration/build/build_test.go:615:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
integration/build/build_test.go:743:3: The copy of the 'for' variable "builderVersion" can be deleted (Go 1.22+) (copyloopvar)
builderVersion := builderVersion
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
