On Thursday, May 18, 2023 4:58:30 PM EDT Kaleb Keithley wrote:
On Thu, May 18, 2023 at 9:57 AM John Mulligan <phlogistonjohn@asynchrono.us> wrote:
Unfortunately, I don't think this RPM derived cephadm is appropriate for general uses. RPM mangles the shebang line to something RH-distro specific so
That's not entirely accurate.
Packaging guidelines these days say that the python shebang should be /usr/bin/python3. I believe that's true even for Debian and Ubuntu.
Agreed!
Some developers think it's smart to use #! /usr/bin/env python. In gluster we had a mix of that and some #! /usr/bin/python or #! /usr/bin/python2 shebangs. These were all changed to #! /usr/bin/python3. (Obviously on old distros like RHEL7 it needs to be /usr/bin/python2 and in gluster we added some sed magic to the glusterfs.spec to fix them at build time. Before its EOL, RHEL7 was one of the last major distros still using python2.)
On Fedora, RHEL, and SUSE, rpmbuild will whine about incorrect shebangs during the build. It may even change them, I don't remember at this point. IIRC, if it changes them, it changes them to /usr/bin/python3.
Interesting.... when I wrote that I had just looked at a non-zipapp version of cephadm that was extracted from the RPM and it had a weird "system python" shebang (`/usr/libexec/platform-python -s`) see: `https://download.ceph.com/rpm-17.2.6/el8/noarch/ and download the `cephadm` the system extracted there. I was worried, but had not confirmed that rpmbuild was still doing that. I should probably get access to a proper main/reef build and see what the result is before saying more on this. :-)
this `cephadm` wouldn't work properly on distros like debian, ubuntu, etc.
If all the shebangs are #! /usr/bin/python3 — either in the source to start with, or changed by the rpmbuild — they work on Debian and Ubuntu just fine. Or they should. If they don't, there's a different problem.
OK, that's good news. With the new zipapp compilation we have the ability to force the shebang to be something we explicitly set (like "/usr/bin/python3"). As of this moment it takes whatever shebang is default for python's zipapp module & function.
If cephadm is a separate package (for some definition of package) I have to wonder why you're *not* working on adding them to Fedora and CentOS Storage SIG, where Ceph and several related packages are already being packaged for wide consumption.
cephadm is part of the packages. For RPM it is one of the many sub-packages in ceph.spec.in. For another example, see the same dir linked above and the file `cephadm-17.2.6-0.el8.noarch.rpm`. That's probably the "best" way to get it on one's system. However, there's been a long standing workflow that one can aqucuire a "standalone" cephadm and bootstrap using that. See https://docs.ceph.com/en/pacific/cephadm/install/#install-cephadm and the curl based installation section. This is a workflow that is currently broken on "main" and "reef" and we're trying to replace/replicate. For exactly what systems and workflows we expect to use the curl based workflow, I'm not clear on but the idea may be to support other distros that have docker/podman support (because containers!). But I haven't been working on cephadm long enough to know - perhaps Adam will chime in here. :-)