- Make BDEPEND independent from DEPEND (The `BDEPEND` is a
build-time requirement, so it should not be included in the whole
`DEPEND` list. If it does, an installation of `sys-auth/sssd`
causes other dependencies to be installed not only in the
`/build`, but also under the SDK. That's not what we want, so we
need to exclude `BDEPEND` from the list.)
- Move runstatedir option from configure to make (Now that the
upstream sssd 2.3.1 does not support `--runstatedir` option from
its configure script, we need to remove the option, to unblock the
configure issue like `unrecognized option --runstatedir`. Instead
we need to pass `runstatedir=` to emake commands.)
- Disable realm check for nsupdate (At the moment bind-tools does
not enable `gssapi`, so its `nsupdate` tool is also not able to
run `realm` command. As a result, configure script of `sssd` fails
when running `echo realm | nsupdate`, like `syntax error`.
To avoid such issues, we need to disable the nsupdate check for
now. After we could enable `gssapi` for the SDK correctly, we can
bring back the nsupdate check in the future.)
- Add patch for CVE-2021-3621
- Set the conf dir path explicitly (Without passing the
--with-systemdconfdir flag, the configure script will query
pkg-config for the directory itself. In the cross-compilation
setup that we have, this will result in a path sysroot prepended
to the path twice. systemd.eclass has a workaround for this issue,
but it does not provide an elegant getter of the system
configuration directory, thus we call `_systemd_get_dir`
ourselves.)
- Make it compatible with newer python versions.
- Fix samba version detection by exporting the CPP variable. For
some reason it was empty after the toolchain updates.
- take care of nscd.conf via tmpfiles, add files/nscd-conf.tmpfiles.
- don't run sanity checks in pkg_pretend to prevent gcc checks when
only the binary package is installed.
- comment out 'dostrip -x' to force the OS image binaries to be stripped
- remove everything glibc wants to put under /etc since we use
baselayout to provide that
## Description
When an EC2 instance boots up with a flatcar image (even the latest) the kubelet fails.
The userdata defines (and should do so) that the `/etc/eks/bootstrap.sh` should run, which it does.
This seems to add a ExecStartPre to the kubelet.service:
`ExecStartPre=/usr/share/oem/eks/download-kubelet.sh`
Both the `bootstrap.sh` and the `download-kubelet.sh` are consistent with:
https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/bootstrap.shhttps://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh
The `download-kubelet.sh` fails with `Unsupported Kubernetes version` because in the case statement on line 24->50 (https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh#L25) only has values for kubernetes version 1.15 -> 1.21
If I manually alter the file and add 1.22 (when I test this on 1.22.9 kubernetes version deployment) and re-run the `bootsrap.sh` it works fine as far as I can see, the node than joins the cluster and shows up as `Ready` and pods starting running on the node.
The last PR I can see on this particular thing was done about a year ago f0da7f8c9e
## Impact
No EKS support for kubernetes versions higher than 1.21
## Environment and steps to reproduce
1. **Set-up**: Create an EKS cluster with the latest flatcar AMI in the worker nodes
2. **Task**: SSH into the node (probably through a Bastion)
3. **Action(s)**: No actions needed
4. **Error**: kubelet.service fails because the download-kubelet.sh doesn't have download locations for kubernetes version above 1.21
## Expected behavior
Download locations for kubernetes versions 1.22 and 1.23 (EKS doesn't have support for 1.24 yet it seems) should be located inside the download-kubelet.sh
## Additional information
By running `aws s3 ls s3://amazon-eks/` you can list the available locations of the other versions, so for it should result in this:
``` sh
case $CLUSTER_VERSION in
1.23)
S3_PATH="1.23.9/2022-07-27/"
;;
1.22)
S3_PATH="1.22.12/2022-07-27/"
;;
1.21)
S3_PATH="1.21.2/2021-07-05"
;;
1.20)
S3_PATH="1.20.4/2021-04-12"
;;
1.19)
S3_PATH="1.19.6/2021-01-05"
;;
1.18)
S3_PATH="1.18.9/2020-11-02"
;;
1.17)
S3_PATH="1.17.12/2020-11-02"
;;
1.16)
S3_PATH="1.16.15/2020-11-02"
;;
1.15)
S3_PATH="1.15.12/2020-11-02"
;;
*)
echo "Unsupported Kubernetes version"
exit 1
;;
esac
```
We fetch the latest release of calico from calicoproject/calico
releases instead of from calico-version.yaml file in tigera/operator
repo. This is because we download the Tigera Operator manifest from
the calico repository, so we can expect that when the release happens,
both calico and the operator agree on versions used (so we expect that
calico 3.24.0 is using operator version 1.28.0, and the operator
1.28.0 is using calico 3.24.0).
