Switch k9s source from GitHub to use openSUSE#294
Conversation
Co-authored-by: Paulo Gomes <paulo.gomes.uk@gmail.com>
Co-authored-by: Paulo Gomes <paulo.gomes.uk@gmail.com>
|
Thank you very much @pjbgf! I've accepted both changes. |
| RUN zypper --non-interactive ar https://download.opensuse.org/repositories/devel:kubic/15.6/devel:kubic.repo \ | ||
| && zypper --non-interactive ar https://download.opensuse.org/repositories/devel:/kubic/openSUSE_Factory_ARM/ devel_kubic_arm \ | ||
| && zypper --non-interactive ar https://download.opensuse.org/repositories/devel:/kubic/openSUSE_Factory_zSystems/ devel_kubic_zed \ |
There was a problem hiding this comment.
Please don't do this. You are adding a repository for SLE/Leap 15.6 and Factory to the same image. This is going to cause so many subtle dependency issues, it'll bite you down the road. Also, you are adding unmaintained community repositories! Do you really want your image to be based on something that might just as well be broken?
There was a problem hiding this comment.
@dcermak - I'm not very familiar with how SLE/Leap repos interact. Ultimately the goal was to fix CVEs and better at dog-fooding in one go. I wasn't able to find how to access these packages another way.
Ultimately it sounds like "official SLES" support for k9s (and with x64, arm64, maybe s390x) isn't something we provide? Since I agree this would be a big concern:
you are adding unmaintained community repositories!
Seems likely I'll close this PR since this is a major blocker for the concept. Which is rather unfortunate since compared to the upstream k9s this had far less CVEs when I scanned the image.
There was a problem hiding this comment.
@dcermak - I'm not very familiar with how SLE/Leap repos interact. Ultimately the goal was to fix CVEs and better at dog-fooding in one go. I wasn't able to find how to access these packages another way.
Leap and SLES are essentially the same, so that's not a big problem. The bigger issue is throwing in repositories for Factory i.e. Tumbleweed. That's a completely different distribution at this point and mixing it with Leap or SLES will end badly.
Ultimately it sounds like "official SLES" support for
k9s(and with x64, arm64, maybe s390x) isn't something we provide?
No, we don't.
Seems likely I'll close this PR since this is a major blocker for the concept. Which is rather unfortunate since compared to the upstream
k9sthis had far less CVEs when I scanned the image.
That would be unfortunate. I would suggest that you or someone else who you deem trustworthy takes over maintenance of k9s and then you can include it in such a container image.
Co-authored-by: Dan Čermák <dcermak@suse.com>
Co-authored-by: Guilherme Macedo <guilherme@gmacedo.com>
Co-authored-by: Guilherme Macedo <guilherme@gmacedo.com>
| RUN zypper --non-interactive refresh && \ | ||
| zypper --installroot /chroot -n rm busybox-vi busybox-links && \ | ||
| zypper --installroot /chroot -n in bash-completion jq vim curl && \ | ||
| zypper --installroot /chroot clean -a && \ | ||
| rm -rf /chroot/var/cache/zypp/* /chroot/var/log/zypp/* /chroot/etc/zypp/ | ||
| zypper --installroot /chroot -n in bash-completion jq vim curl k9s |
There was a problem hiding this comment.
I don't really understand this part, why are you installing k9s into /chroot/ that you copied from the busybox image? What's the advantage of this added complexity, when in the end you copy everything into a scratch image anyway?
There was a problem hiding this comment.
@dcermak The final image is largely a copy of the bci-busybox plus the zypper installed components (and other downloaded/built artefacts).
The copy into scratch avoids redundant layers if this were to be copied into another bci-busybox final image.
Given that bci-busybox does not include zypper, is there a better approach to be able to zipper in on it?
There was a problem hiding this comment.
Just install everything into the image based on bci-base and copy everything out of it into the scratch image. The intermediate step of running the zypper in in a chroot based on busybox is only asking for trouble, as your shell is now POSIX /bin/sh and not bash, which too many rpm scriptlets do not support.
There was a problem hiding this comment.
@dcermak good point, this is actually a practice we observed in other teams using OBS/IBS. Issues with the rpm scriptlets would make the zypper operation fail or would it be a silent, resulting in potential unexpected behaviours executing the installed app?
There was a problem hiding this comment.
The failure could be either silent or you could end up with a broken package, it's impossible to tell in advance. You'd probably see a failure in the rpm installation log, but you'd have to inspect them manually.
5 participants
Per title, this is 1/3 steps to address: #286