I've been setting up a cookbook OSD creation process and as I walked through the various stages, I noted that the /etc/redhat-release file said "CentOS Stream 8". I panicked, because IBM has pulled the Ceph archives for CentOS 8 and nuked the machine, then rebuilt it with more attention to detail. I consistently was seeing the correct redhat-release until I installed cephadm and ran cephadm shell. Cephadm is running a chroot jail, it seems, and it's plugging in the wrong value for that file. Presumably from its internal image instead of copying the actual file. The false release string does not leak outside of cephadm, though. So far this appears to be only important as a possible confusion point, but it is of concern since the repositories in /etc/yum.repos.d download from repositories whose URLs are derived from the OS release that YUM (dnf) thinks it's running under and I'd hate to find out the hard way that something got confused. Probably rpm and yum/dnf shouldn't be available from within cephadm, but since cephadm pulls stuff internally that may not be possible. This was seen on AlmaLinux 9.4, cephadm version 16.2.15.
On 7/18/24 21:50, Tim Holloway wrote:
I've been setting up a cookbook OSD creation process and as I walked through the various stages, I noted that the /etc/redhat-release file said "CentOS Stream 8".
This is the case because the orachestrator cephadm uses container images based on CentOS 8. When you execute "cephadm shell" it starts a container with that image for you. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Ah. Makes sense. Might be nice if the container build appended something like "cephadm container" to the redhat-release string, though. A more concerning item is that the container is based on CentOS 8 Stream. I'd feel more comfortable if the base OS was more release- oriented. Especially since Centos8 Stream EOL'ed back around May. More importantly, the Ceph archives for CentOS 8 went down the Memory Hole. That's really worrisome. Makes it questionable that it would be easy to build from source on a blank system now. Yanking repos is not the Linux Way. I could probably spin up a copy of CentOS 2, because repos are still online even if no sensible person would want it for a production server. But not so the CentOS 8 enterprise extensions. They;re gone. On Fri, 2024-07-19 at 09:00 +0200, Robert Sander wrote:
On 7/18/24 21:50, Tim Holloway wrote:
I've been setting up a cookbook OSD creation process and as I walked through the various stages, I noted that the /etc/redhat-release file said "CentOS Stream 8".
This is the case because the orachestrator cephadm uses container images based on CentOS 8.
When you execute "cephadm shell" it starts a container with that image for you.
Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin
https://www.heinlein-support.de
Tel: 030 / 405051-43 Fax: 030 / 405051-19
Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
On 19-07-2024 14:04, Tim Holloway wrote:
Ah. Makes sense. Might be nice if the container build appended something like "cephadm container" to the redhat-release string, though.
A more concerning item is that the container is based on CentOS 8 Stream. I'd feel more comfortable if the base OS was more release- oriented. Especially since Centos8 Stream EOL'ed back around May.
Yeah. The ceph devs are aware of that. The new release for Reef 18.2.4 and Squid are based on CentOS stream 9. CentOS 8 stream has been (or is being) phased out.
More importantly, the Ceph archives for CentOS 8 went down the Memory Hole. That's really worrisome. Makes it questionable that it would be easy to build from source on a blank system now.
Yanking repos is not the Linux Way. I could probably spin up a copy of CentOS 2, because repos are still online even if no sensible person would want it for a production server. But not so the CentOS 8 enterprise extensions. They;re gone.
There have been some discussons on ceph-dev ML if CentOS stream a good build target for Ceph containers. Some people like to see debian instead. Not sure if this will be point of discussion in the future (again). But we all agree it should be based on a OS that is still supported (and upgraded before it gets EOL). Gr. Stefan
Well, for what it's worth, I'm fairly agnostic about the distro used, more interested in its stability. Alpine is Debian-based, I think and very popular as a minimalistic based for containers. I prefer the Red Hat world myself, but can live with either. Nominally Ceph is a Red Hat product, and that's about the only other factor I can think of. On Fri, 2024-07-19 at 14:50 +0200, Stefan Kooman wrote:
On 19-07-2024 14:04, Tim Holloway wrote:
Ah. Makes sense. Might be nice if the container build appended something like "cephadm container" to the redhat-release string, though.
A more concerning item is that the container is based on CentOS 8 Stream. I'd feel more comfortable if the base OS was more release- oriented. Especially since Centos8 Stream EOL'ed back around May.
Yeah. The ceph devs are aware of that. The new release for Reef 18.2.4 and Squid are based on CentOS stream 9. CentOS 8 stream has been (or is being) phased out.
More importantly, the Ceph archives for CentOS 8 went down the Memory Hole. That's really worrisome. Makes it questionable that it would be easy to build from source on a blank system now.
Yanking repos is not the Linux Way. I could probably spin up a copy of CentOS 2, because repos are still online even if no sensible person would want it for a production server. But not so the CentOS 8 enterprise extensions. They;re gone.
There have been some discussons on ceph-dev ML if CentOS stream a good build target for Ceph containers. Some people like to see debian instead. Not sure if this will be point of discussion in the future (again). But we all agree it should be based on a OS that is still supported (and upgraded before it gets EOL).
Gr. Stefan
participants (3)
-
Robert Sander
-
Stefan Kooman
-
Tim Holloway