* Use INVOCATION_ID to detect execution under systemd, since as of a9b5a1933f NOTIFY_SOCKET is now cleared by the server code.
* Set the unit type to notify by default for both server and agent, which is what Rancher-managed installs have done for a while.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
* Update docs to include s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x drone pipeline
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Install trivy linux arch only for amd64
This is done so that trivy is not installed for s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x arch if condition for Dockerfile.test
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x arch in install script
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x GOARCH in build script
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add SUFFIX s390x in scripts
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Skip image scan for s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update klipper-lb to version v0.3.5
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update traefik version to v2.6.2
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update registry to v2.8.1 in tests which supports s390x
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Skip compact tests for s390x arch
This is done because compact test require a previous k3s version which supports s390x and it is not available
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
- also updated k3s-uninstall.sh on zypper and TU systems
- fix#4409 for Fedora CoreOS
new installer tests via github actions:
- fedora-coreos
- opensuse-microos
Signed-off-by: Jacob Blain Christen <jacob@rancher.com>
Support invoking install.sh on SLE Micro with or without SELinux
enabled. Same deal for SLES.
Additionally, easy-to-invoke assertions, via Vagrant, that the local
install.sh works correctly:
- tests/install/centos-7 (stand-in for rhel 7)
- tests/install/centos-8 (stand-in for rhel 8)
- tests/install/opensuse-leap (stand-in for sles)
- tests/install/opensuse-microos (stand-in for sle-micro)
- tests/install/ubuntu-focal
Addresses #3188
Addresses #3917
Signed-off-by: Jacob Blain Christen <jacob@rancher.com>
If install.sh relies on awk, install.sh malfunctions when run on a
device with a limited environment where awk is not available. This patch
replaces the use of awk with built-in shell script functionality.
Fixes: #3737
Signed-off-by: Joakim Roubert <joakim.roubert@axis.com>
* install.sh: test if BIN_DIR is readonly, else use /opt
On flatcar /usr is a readonly partition, while /opt is allowed for
writing.
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
* install.sh: only warn on Flatcar about selinux
This check is a bit more explicit, but only warn about finding the rpm
installed policy when on Flatcar Container Linux
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
* Update install.sh
Co-authored-by: Brad Davidson <brad@oatmail.org>
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
Co-authored-by: Brad Davidson <brad@oatmail.org>
It's a bad practice to install packages via rpm directly. It's better to install all packages with Yum/Dnf. It's also possible to install packages directly via an URL, which is the purpose of this PR.
Wants= is required to actually set the dependency on network-online.service
After= is required or k3s.service will be started at the same time as network-online.service
In network environments with slow DHCP, both are required to ensure valid network configuration for k3s
Signed-off-by: Adam Farden <adam@farden.cz>
Adds the line `After=network-online.target` to the k3s systemd service
file. This applies the fix mentioned in
[this GH comment](https://github.com/rancher/k3s/issues/1626#issuecomment-642253812)
which I can confirm makes k3s networking survive reboot in Raspbian
Buster.
[It appears, in some docs I found](https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files)
that this is a recommended and usual way of specifying that we need the
target to be _completed_ before starting k3s. Using just the `Wants=`
directive doesn't work for this task, you have to add both directives
at once to do this. Quote:
> `Wants=`: This directive is similar to `Requires=`, but less strict.
> `Systemd` will attempt to start any units listed here when this unit
> is activated. If these units are not found or fail to start, the
> current unit will continue to function. This is the recommended way to
> configure most dependency relationships. **Again, this implies a
> parallel activation unless modified by other directives**
> [...]
> `After=`: The units listed in this directive will be started before
> starting the current unit. This does not imply a dependency
> relationship and **one must be established through the above
> directives if this is required.**
- _(Emphasis mine)_
Signed-off-by: Matthew Clive <arcticlight@arcticlight.me>
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
This allows us to fail quickly if we're handed a schemeless or plain
HTTP URI, rather than having the agent barf when the systemd unit
starts. For an operator, this makes for a cleaner error up front and
clear messaging for how to fix the situation.
Signed-off-by: Josh McSavaney <mcsaucy@csh.rit.edu>
When for some reason, k3s crashes, and can't startup again, e.g. when
the data backend is not available (dqlite crashed, database server is
offline, ...), on openrc systems, supervise-daemon will try to restart
it, as per supervise-daemon(8):
respawn-max:
Sets the maximum number of times a daemon will be respawned during
a respawn period. If a daemon dies more than this number of times
during a respawn period, will give up trying to respawn it and exit.
The default is 10, and 0 means unlimited.
Setting respawn-max to 0, makes sure a k3s process on openrc systems will
keep trying to come online, even if the database backend is offline for a
longer period of time.
This aligns the openrc service configuration with the systemd
configuration, which has
Restart=always
RestartSec=5s