halo.spec: add an rpm specfile, binaries in /usr/sbin

[ofaaland]

Add an rpm specfile for use when packaging HALO with "rpmbuild".

Undefine _debugsource_packages because find-debuginfo.sh fails to find the sources and the rpm build fails. As a consequence, no halo-debugsource subpackage is created. However, a halo-debuginfo subpackage is still created with stripped debug symbols.

Put the binaries in /usr/sbin to conform to typical Redhat conventions.

Run tests, but do not fail the build if the tests fail, since the project is still immature.

Use @@Version@@ to facilitate replacement at build time with the version from Cargo.toml, perhaps via
cargo metadata --no-deps --format-version 1 | jq -r '.packages[0].version'

Use lowercase "halo" instead of "HALO" in the name to match the binaries produced and the github URL.

[ofaaland]

Feel free to push back on the choices made. Some of them are somewhat arbitrary.

Experimenting with "cargo rpm", I found that "cargo rpm init" puts the specfile it generates into .rpm/halo.spec. I don't like that it's a "hidden" directory, which is why I didn't follow its example, but perhaps it would be better to follow the "cargo rpm init" example where there isn't real harm. Let me know what you think.

[bertschinger]

I don't have much experience with making RPMs at this point, but the spec file looks pretty reasonable at first glance.

I'll have to look into how tools like cargo rpm work for packaging projects like this and hopefully I'll be able to respond with more detail after trying it out.

[bertschinger]

@ofaaland , I'm curious if you have an opinion here.

I am wondering whether it makes sense to create one RPM that includes both the manager AND remote binaries, or whether I should create two RPMs, one for the manager installation and one for the remote installation.

In the former case, the lustre nodes will all end up with the manager binary, CLI interface, etc. being installed. This is not exactly problematic as long as nobody tries to run the manager on one of the Lustre nodes, but it might be cleaner to have the lustre nodes only have the programs they are actually supposed to run.

Any thoughts?

[ofaaland]

To my mind this is a small enough project that it's not worth separating the manager and the remote.

The maintenance overhead for both developer and sysadmin is somewhat higher if they're two packages (deciding what files go in which package, needing two builds instead of one, the sysadmin keeping them in sync, etc.). The sysadmin needs some mechanism for validating that they're running the right services on different types of nodes, anyway. These all run on nodes that aren't user-facing, and so there's less pressure to minimize the attack footprint by reducing installed software. And the binaries, docs, etc. aren't so large it's a space consideration, in my mind.

I can see the argument for separating them, though. I know some sites do that kind of thing (e.g. build packages for the lustre client different than the lustre server).

[jarrett-lanl]

One RPM is fine for us a well. Ease of maintenance sounds worth the tradeoffs