Leadership schedule failing for cardano-cli 8.0.0

Staking & Delegation Operate a Stake Pool
21

Part of my problem is caused by trying to build each of the parts into Debian packages. It is much easier if I can use the standard libraries already provided in the Debian repositories.

I believe it is fine to compile against the Debian (and Ubuntu) libsodium so long as you add the following to your cabal.project.local file:

package cardano-crypto-praos
  flags: -external-libsodium-vrf

I don’t know how the cabal magic works, but I believe these lines somehow expose some extra functions so that your compiled cardano-node binary doesn’t need the custom IOG version of libsodium. In other words, it can run with only the standard libsodium. Probably the extra functions required are compiled in so they don’t need to be dynamically loaded???

If on the other hand, you build the custom IOG version of libsodium and compile cardano-node against that (IE: without those extra cabal.project.local magic lines), then that means you must also copy that custom version of libsodium to every machine you want to run your cardano-node binary.

I have now made some “libsodium23-iog” and “libsodium-dev-iog” packages using the IOG version of libsodium. I had to add a heap of extra symbols to the symbols file I stole form the standard Debian libsodium package so that the Debian package system can work out dependencies correctly. This is because IOG have added, or made available, many extra functions in libsodium which are not available in the Debian version of libsodium. If I now install my libsodium-dev-iog package and compile cardano-node against that then the Debian package manager will know that my custom libsodium23-iog package is a dependency for installing and running my new cardano-node debian package. Thus when I do “apt install cardano-node” the package manager will automatically also install my “libsodium23-iog” package as a dependency.

In other words, it is a bit of extra work to create custom versions of library deb packages if you don’t use the standard Debian/Ubuntu libraries.

This is also why I am trying to figure out why IOG is not using one of the later release versions of libsecp256k1. I really want to just use the standard Debian version of libsecp256k1 which is version 0.2.0 and is later than the git commit “ac83be33” specified by IOG. If anyone from IOG can tell me if version 0.2.0 is fine, I would be grateful. I actually compiled against that Debian version and it is running fine on all my relays and my block producer for a couple of weeks now.

It is worth a bit of pain to get things packaged correctly because then I can compile everything on a separate build machine and none of my running machines need to have any of the compiler or build chain software. Furthermore, the package manager then takes care of installs and upgrades which removes a lot of human error such as forgetting to remove old versions of binaries/libraries or setting up executable/library paths correctly. It is just much better to use your package manager to install, remove, and upgrade software.

1 Like
22

Good info. So I did build from source and I can see from the binary that it’s linked to the libsodium I built and installed with the specified commit in the release notes
$ ldd ./cardano-cli
libsodium.so.23 => /usr/local/lib/libsodium.so.23 (0x00007f2a80c26000)
$ ldd ./cardano-node
libsodium.so.23 => /usr/local/lib/libsodium.so.23 (0x00007f2a80c26000)

23

The package manager puts my binary in /usr/bin/ and all the libraries in standard locations. There is no need for custom library paths.

ldd /usr/bin/cardano-node
... snip ...
        libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f29c5f2b000)
        libsecp256k1.so.1 => /lib/x86_64-linux-gnu/libsecp256k1.so.1 (0x00007f29c5e01000)
... snip ...

Upgrading is then very easy. Just build the new version into a deb and put it in your repository. Then on every relay or block producer just “apt dist-upgrade”. The package manager takes care of removing old versions etc. and even restarts the systemd process. Just like every other software package on your system.

1 Like
24

Except they call out a specific commit for that library

25

Yes, I want to know why they call for that specific commit of libsecp256k1.

I have compiled cardano-node using release version 0.2.0 of libsecp256k1 (version in Debian Bookworm) and have been running this on all my relays and my block producer for multiple epochs continuously, without any problems. Release version 0.2.0 of libsecp256k1 is later than the specific commit IOG calls for and has some included bugfixes.

So why does IOG still call for that specific libsecp256k1 commit? Is it just because that was the current commit when first used and they haven’t changed it because there are no important bugfixes relating to any code IOG uses?

1 Like