This adds support for automatically registering node hostnames in DNS by
sending the current hostname to DHCP via option 12. If the current hostname is
updated, issue a new DISCOVER to propagate the update to DHCP (updating the
hostname on lease renewals is not universally supported by DHCP servers). This
addition maintains the previous functionality where the node can also request
its hostname from the DHCP server. The received hostname will be processed and
prioritized as usual by the `network.HostnameSpecController`.
This change set also contains fixes to make DHCP renewals compliant with RFC
2131, specifically avoiding sending the server identifier and requested IP
address when issuing renewals using a previous offer. This also uncovered
issues and missing features in the upstream `insomniacslk/dhcp` library, the
fixes and improvements for which are now finally merged.
Sending hostname updates have been tested against `dnsmasq` and the built-in
DHCP + DNS services in Windows Server. Hostname retrieval from DHCP and edge
cases with overridden hostnames from different configuration layers have been
extensively tested against `dnsmasq`.
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Implement the network config screen with input forms to configure the initial node networking by writing a config to the META partition.
Closessiderolabs/talos#6961.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
- github.com/aws/aws-sdk-go to v1.44.209
- github.com/stretchr/testify to v1.8.2
- github.com/jsimonetti/rtnetlink to v1.3.1
- google.golang.org/genproto to v0.0.0-20230223222841-637eb2293923
- github.com/emicklei/dot to v1.3.1
- github.com/gdamore/tcell/v2 to v2.6.0
- github.com/insomniacslk/dhcp to v0.0.0-20230220063916-5369909a5de7
- github.com/jsimonetti/rtnetlink to v1.3.1
- github.com/opencontainers/runtime-spec to v1.1.0-rc.1.0.20230215090456-58ec43f9fc39
- github.com/rivo/tview to v0.0.0-20230226195229-47e7db7885b4
Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Recent Docker versions seem to have changed the API in the way container
IP addresses are reported.
Also fix running Talos 1.3 image under talosctl 1.4.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This improves the performance of the I/O operations if the underlying
filesystem supports it.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This is handy when the node with qemu went down, so you had to manually delete the folder after it restarted.
Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
There's a cyclic dependency on siderolink library which imports talos
machinery back. We will fix that after we get talos pushed under a new
name.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This the first step towards replacing all import paths to be based on
`siderolabs/` instead of `talos-systems/`.
All updates contain no functional changes, just refactorings to adapt to
the new path structure.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
It wasn't possible to disable IPv4 and enable IPv6 for the talosctl create
command as it combined the IP address and port incorrectly.
Signed-off-by: Philipp Sauter <philipp.sauter@siderolabs.com>
Containers created with `talosctl cluster create` are ran with readonly
filesystem. This more accurately mimics standard Talos.
Signed-off-by: Andrew Rynhard <andrew@rynhard.io>
Fixes#6119
With new stable default hostname feature, any default hostname is
disabled until the machine config is available.
Talos enters maintenance mode when the default config source is empty,
so it doesn't have any machine config available at the moment
maintenance service is started.
Hostname might be set via different sources, e.g. kernel args or via
DHCP before the machine config is available, but if all these sources
are not available, hostname won't be set at all.
This stops waiting for the hostname, and skips setting any DNS names in
the maintenance mode certificate SANs if the hostname is not available.
Also adds a regression test via new `--disable-dhcp-hostname` flag to
`talosctl cluster create`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The default qemu binary was only set as qemu-system-<arch>.
Signed-off-by: Davincible <david.brouwer.99@gmail.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
It wasn't used when building an endpoint to the local API server, so
Talos couldn't talk to the local API server when port was changed from
the default one.
Fixes#5706
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Add an OVMF image source path for QEMU, needed on RHEL-based systems.
Signed-off-by: Han Cen <hi@chamburr.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Docker on WSL seems to have same issue as Docker/OS X and
Docker/Windows: container IPs are not routable from the host, so we need
to apply same "magic" by using exposed ports.
WSL `talosctl` binary is built for Linux, so we need to do additional
checks for the platform.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
talosctl could not find the ovmf flash image to provision a local qemu
on Fedora. We added the source path where the dnf package manager will
place the image.
Fixes#5517
Signed-off-by: Philipp Sauter <philipp.sauter@siderolabs.com>
As QEMU clusters are used for testing, use unsafe cache options to
reduce amount of fsyncs going to the host blockdevice.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Docker by default disable IPv6 completely in the containers which breaks
SideroLink on Docker-based clusters, as SideroLink is using IPv6
addresses for the Wiregurard tunnel.
This change might break `talosctl cluster create` on host systems which
have IPv6 disabled completely, so provide a flag to revert this
behavior.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR removes the bit where we disabled persistence for the docker
provider. Doing so allows us to do things like upgrade k8s against a
docker-based cluster for testing purposes. Tested locally and a cluster
created just fine and an `upgrade-k8s` completed successfully.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
The CNI is executed on the host. Even if we want to run an arm64 qemu,
we still need to execute the amd64 CNI on the host.
Signed-off-by: Florian Klink <flokli@flokli.de>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Filter the default list down to IPv4/IPv6 depending on the network
configuration. The problem is that the full list contains IPv6 resolvers
and these won't work on IPv4-only network (which is default for
`talosctl cluster create`).
This is not a problem for QEMU, as QEMU filters down the list for
built-in DHCP server already splitting it for DHCP4/DHCP6.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Talos shouldn't try to re-encode the machine config it was provided
with.
So add a `ReadonlyWrapper` around `*v1alpha1.Config` which makes sure
that raw config object is not available anymore (it's a private field),
but config accessors are available for read-only access.
Another thing that `ReadonlyWrapper` does is that it preserves the
original `[]byte` encoding of the config keeping it exactly same way as
it was loaded from file or read over the network.
Improved `talosctl edit mc` to preserve the config as it was submitted,
and preserve the edits on error from Talos (previously edits were lost).
`ReadonlyWrapper` is not used on config generation path though - config
there is represented by `*v1alpha.Config` and can be freely modified.
Why almost? Some parts of Talos (platform code) patch the machine
configuration with new data. We need to fix platforms to provide
networking configuration in a different way, but this will come with
other PRs later.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Related to #4448
The only remaining part is filtering out SideroLink addresses when Talos
looks for a node address.
See also https://github.com/talos-systems/siderolink/pull/2
The way to test it out:
```
$ talosctl cluster create ... --extra-boot-kernel-args
siderolink.api=172.20.0.1:4000
```
(where 172.20.0.1 is the bridge IP)
Run `siderolink-agent` (test implementation):
```
$ sudo _out/siderolink-agent-linux-amd64
```
Now on the host, there should be a `siderolink` Wireguard userspace
tunnel:
```
$ sudo wg
interface: siderolink
public key: 2aq/V91QyrHAoH24RK0bldukgo2rWk+wqE5Eg6TArCM=
private key: (hidden)
listening port: 51821
peer: Tyr6C/F3FFLWtnzqq7Dsm54B40bOPq6++PTiD/zqn2Y=
endpoint: 172.20.0.1:47857
allowed ips: fdae:41e4:649b:9303:b6db:d99c:215e:dfc4/128
latest handshake: 2 minutes, 2 seconds ago
transfer: 3.62 KiB received, 1012 B sent
...
```
Each Talos node will be registered as a peer, tunnel is established.
You can now ping Talos nodes from the host over the tunnel:
```
$ ping fdae:41e4:649b:9303:b6db:d99c:215e:dfc4
PING fdae:41e4:649b:9303:b6db:d99c:215e:dfc4(fdae:41e4:649b:9303:b6db:d99c:215e:dfc4) 56 data bytes
64 bytes from fdae:41e4:649b:9303:b6db:d99c:215e:dfc4: icmp_seq=1 ttl=64 time=0.352 ms
64 bytes from fdae:41e4:649b:9303:b6db:d99c:215e:dfc4: icmp_seq=2 ttl=64 time=0.437 ms
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This verifies that members match cluster state and that both cluster
registries work in sync producing same discovery data.
Fixes#4191
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Note: Talos can be still run under `Firecracker`, support for
Firecracker was only removed for `talosctl cluster create`.
Reason:
* code is untested/unmaintained, and probably doesn't work correctly
* firecracker Go SDK pulls lots of dependencies and it blocks CNI Go
module update
Bonus: `talosctl-linux-amd64` shrinks by 2 MiB.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This has two big visible changes:
* `installer` image now contains assets for both `amd64` and `arm64`, so
it can be used to generate any Talos image (including RPi on amd64 host)
* Talos is using cross-compilation instead of emulation to build
non-native architectures: on amd64, Go amd64 compiler produces binaries
for both arm64 and amd64
(before this change: Go arm64 compiler via QEMU produces arm64 binaries on amd64)
CI implications: we no longer require arm64 nodes.
Changes walkthrough:
* `installer` container now keeps assets under `/usr/install/<arch>`
* Dockerfile build starts forcing toolchain/base image to use the build
host native architecture, not target architecture
* lots of duplication for amd64/arm64 as we want to combine assets for
both arches in a single image (e.g. we have multi-arch amd64/arm64
installer image, each arch has native installer binary, but both arches
contain full set of amd64/arm64 assets)
* fixed a small bug preventing arm64 on amd64 talosctl cluster create
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
