This howto is different to some other guides as follows:
The building is done separately (on a different machine) so that the running machine does not require compilers and build dependencies
It encourages the user to not rely on custom scripts to compile, install, and upgrade
Instead it uses the familiar Debian/Ubuntu package manager for installation and upgrades
It should make troubleshooting problems easier since there are no changes to executable paths, library paths, or environment variables and there are no complex scripts that automate things
@COSDpool@rdlrt feel free to modify or use aspects if it is relevant to your documentation efforts.
This is promising & I’ve suggested adding an Appendix section to the outline of our remodelling Stake Pool Course… for material like this that’s useful for growth & further study but not necessarily part of the rigorous procedure for every SPO:
I get the distinct feeling that there seems to be 3 main issues with the approach I am taking:
I am using the package manager to install and update cardano-node as opposed to using a custom script or manual method
I am setting up everything to use standard filesystem locations for configs, database, binaries and libraries (but with no “pollution of filesystem” because the package manager effectively compartmentalises everything as it does for every other package)
I advise installing only necessities on the running machine (relay) and to have compilers and development toolchain on a different machine (or at least a different account)
The first 2 things make it easier for a novice user and particularly someone who is not very familiar with Linux. The third point does involve a few extra steps on a different machine (or account), but the benefit is simplification of installations/upgrades across multiple machines, as well as some security advantages.
But these are just my opinions. Since the guides are directed at novice users, such an approach makes sense to me.
I am happy to write similar guides about setting up and running a block-producer including all the stake pool operations such as creating the pool keys and certificate. I can also write guides about running each relay and block-producer in virtual machines (kvm on Linux) including the routing and firewalling.
Unfortunately, it is not practical for the package manager to have the user configure filesystem layout at the install stage. If the community has decided that they don’t want to use their package managers, prefer a /opt/cardano filesystem layout with custom user path, and want the development toolchain on their running machines, then I will butt out. Because, I don’t want to work at crossed-purposes with the rest of the community.
on the contrary I think there will come a point in any intelligent SPO’s life when they’re going to need to consider the subjects you are writing about: so I would rather take this opportunity to attract & promote this material as soon as we can come up with a productive way to classify it.
I really like your approach of using the standard ways to do things. And it should really have a place in the documentation somewhere (maybe also for other distributions?).
…, but that is not really intuitive. If they are not very familiar with Linux, they will also not know about the Filesystem Hierarchy Standard and only roughly know what their package manager does. Unfortunately.
You could tell them how to use systemctl cat and systemctl edit. That would also be a good replacement for the slightly cumbersome self-defined configuration file/EnvironmentFile construction you are currently using for modifying the port. That way, they could change the layout at will, which might especially be wanted for the huge database, which people might want to put in a better suited place.
I don’t think the community has decided on anything. The non-optional part of the introduction should probably have a few words about the fact that things can be in a lot of different places depending on which method(s) you followed.
I don’t think that not using the package manager of the distribution implies that they build everything anew on each machine. They could, e.g., just copy the binaries around, use the IOG-built binaries in the first place, …
I was hoping that someone would produce similar packages for other distributions.
Exactly and they usually don’t want to know either. They just want the executable to work from everywhere. And novices don’t want to do things like modify their users PATH and then wonder why the same command doesn’t work as root or some other user.
Yeah that is a bit of a cludge. I have another document part-written about setting up a block producer which would involve creating a new systemd service file. I wanted a way to allow the user to have a different port number configured and have the default systemd service use it. Can you suggest a better way to do that?
Yes and copy the secp256k1 library files and create the correct symlinks. (The Debian build system compiled this library in to the binaries on my system.)
I changed the systemd service file to the following:
[Unit]
Description=Cardano Node
Requires=network.target
[Service]
Type=simple
SyslogIdentifier=cardano-node
Restart=always
RestartSec=5
TimeoutStopSec=300
Nice=-7
RuntimeDirectory=cardano
User=cardano
Group=cardano
KillSignal=SIGINT
LimitNOFILE=32768
Environment='PORT=3001'
# Default PORT can be overridden in MY_CARDANO_NODE_CONFIG
Environment='MY_CARDANO_NODE_CONFIG=/etc/cardano/my-cardano-node-config.json'
ExecStart=sh -c "\
if [ -f ${MY_CARDANO_NODE_CONFIG} ]; then \
PORT=$$(jq --arg PORT ${PORT} '.port // ($PORT | tonumber)' ${MY_CARDANO_NODE_CONFIG}); \
else \
PORT=${PORT}; \
fi; \
cardano-node +RTS -N -RTS run \
--host-addr 0.0.0.0 \
--port $${PORT} \
--topology /etc/cardano/mainnet-topology.json \
--database-path /var/lib/cardano \
--socket-path /run/cardano/mainnet-node.socket \
--config /etc/cardano/mainnet-config.json \
"
[Install]
WantedBy=multi-user.target
It is still a bit cumbersome because systemd doesn’t let you run scripts easily.
This allows people to set their preferred custom port in “my-cardano-node-config.json” file without having to create a new systemd service file. But, it doesn’t matter if this file doesn’t exist because it will default to using port 3001 which seems to be a Cardano “standard”.
If they don’t like that method then it is pretty easy to edit the systemd service file to create a custom version which will override the system-wide version the deb package installs. Note that if you want to run cardano-node as a block producer you will need to create a custom systemd service file anyway because you need to specify your kes and vrf keys as well as your operational certificate.
For example, this is the systemd service file I use for my block producer:
Also the Terminada deb repository now has the 1.35.7 binary debs for both arm64 and amd64 systems. If you don’t want to compile your own debs and want to trust someone called “Terminada”, then you can simply use my compiled versions by adding the Terminada repository to your apt sources list: