If you own Dune tokens (DUN), you want them to work for the Dune network and ecosystem. It is a fun challenge and you will be rewarded for doing it. The more individual bakers we have in the Dune ecosystem the more decentralized and resilient Dune will become.
Granted, it takes a little bit of work — but good guides exist and I think you will find it worth while. This article focuses on getting you maximal uptime and ease of use once you have installed your node(s) and gotten your ledger to work.
Using systemd to control and monitor your node, baker, endorser and accuser
If you are not familiar with “services” or systemd there is a good intro here: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units
Briefly, what we want is a stable system with maximal uptime in return for minimal intervention. As such we need a Dune node that starts itself once the system boots and a baker/endorser/accuser that is always on and ready to bake/endorse/accuse. systemd can easily help us achieve this.
Below you’ll find the config files for such a system together with some explanation of how it works.
Basically, for a full bakery we want to configure and (auto-)run four services
- Dune Node
- Dune Baker
- Dune Endorser
- Dune Accuser
For a node only, the bottom of this page has instructions on how to use systemd to run a non-baking node. It is super easy. If you only need that then you can read the dune-node.service part and then skip to the bottom of the document.
The individual files for a full bakery are outlined below. You can copy and paste them into the paths/files mentioned in each section.
dune-node.service
First we want to set up the service to run our Dune node. The below example includes running over VPN — you dont have to, just remove the [email protected]<vpnprovider>.service under the [Unit] both for Wants and After.
At the ExecStart line you can place whatever command you normally use to start your node – just dont use nohub etc. You can (& should) change your userand group to whatever you use on your system. I control my nodes in a simple config.json – but the below should work with default settings all over.
# The Dune Node service (part of systemd) # file: /etc/systemd/system/dune-node.service [Unit] Description = Dune Node Service Documentation = http://Dune.gitlab.io/ Wants = network-online.target After = network-online.target [Service] User = baker Group = baker WorkingDirectory = /home/baker/ ExecStart = /home/baker/dune-network/dune-node run Restart = on-failure [Install] WantedBy = multi-user.target RequiredBy = dune-baker.service dune-endorser.service dune-accuser.service
To install your Dune node as a service that loads at boot time you use systemctl:
sudo systemctl enable dune-node.service
Notice that we use After to tell systemd that this service should be loaded after networking is established. We allow the Dune-node service to load without network by using Wants as we might establish network later. You can make sure the Dune node would only load once network is established by chainging ‘Wants’ to ‘Requires’ but I would recommend against doing so, as it limits your flexibility. Same with the VPN service
To start your Dune node service you would use:
sudo systemctl start dune-node.service Obviously, you rarely use this command unless you 1) havent rebooted your system after installing the service or 2) you have actively shut down the service
To start your Dune node service I strongly recommend you use the reload-or-restart instead, as this would ensure (via systemd) that the service is started if not running already and reloaded if already running:
sudo systemctl reload-or-restart dune-node.service
To see the status of your Dune node service you would use:
sudo systemctl status dune-node.service
To stop your Dune node service you would use:
sudo systemctl stop dune-node.service
If for some reason you don’t want the node to start at boot anymore, simply do:
sudo systemctl disable dune-node.service
dune-baker.service
Now that the node is up and running we want to run the baker, endorser and accuser the same way.
# The Dune Baker service (part of systemd) # file: /etc/systemd/system/dune-baker.service [Unit] Description = Dune Baker Service Wants = network-online.target BindsTo = dune-node.service After = dune-node.service [Service] User = baker Group = baker WorkingDirectory = /home/baker/ ExecStartPre = /bin/sleep 1 ExecStart = /home/baker/dune-network/dune-baker-all run with local node /home/baker/.dune-node ledger_bakerone_ed_0_0 Restart = on-failure [Install] WantedBy = multi-user.target
We know that these services require a Dune node and therefore we require the node to be running first — the hardest form of requirement is binding — this means that this service will only start if the service it BindsTo is successfully started and running. Also, if the service (Dune Node) this service (Dune Baker) binds to crashes this service will be stopped.
You should replace the ExecStart command with whatever command you want to run your baker with. Also, replace the ledger_bakerone_ed_0_0 with whatever alias your baking key has. Notice the ExecStartPre: It is a little hackish, but I found that introducing a one second delay between starting the node and the baker, endorser and accuser would make the service run smoothly. Else systemd will start them too closely together. There are ways to adjust this using sytemd, but to keep things simple, we simply sleep for a second prior to executing the command to fire up the baker.
We also know that it would probably be good to reload the baker, endorser and accuser should the node ever reload and therefore we use BindsTo to bind these services to the node. This effectively means, that all four services will restart if you restart the node and that you can restart each of the baker, endorser and accuser services seperately, should you need to.
Same commands as for node to enable, reload/start, stop and get status on the baker:
sudo systemctl enable dune-baker.servicesudo systemctl reload-or-restart dune-baker.servicesudo systemctl stop dune-baker.servicesudo systemctl status dune-baker.service
Note: You must have the Dune baking app open on your Ledger Nano S when you (re)start your baker and endorser.
dune-endorser.service
Now we simply do the same with the endorser and accuser daemons.
# The Dune Endorser service (part of systemd) # file: /etc/systemd/system/dune-endorser.service [Unit] Description = Dune Endorser Service Wants = network-online.target BindsTo = dune-node.service After = dune-node.service [Service] User = baker Group = baker WorkingDirectory = /home/baker/ ExecStartPre = /bin/sleep 1 ExecStart = /home/baker/dune-network/dune-endorser-all run ledger_bakerone_ed_0_0 Restart = on-failure [Install] WantedBy = multi-user.target
Same commands as for node to enable, reload/start, stop and get status on the baker:
sudo systemctl enable dune-endorser.servicesudo systemctl reload-or-restart dune-endorser.servicesudo systemctl stop dune-endorser.servicesudo systemctl status dune-endorser.service
Note: You must have the Dune baking app open on your Ledger Nano S when you (re)start your baker and endorser.
dune-accuser.service
# The Dune Accuser service (part of systemd) # file: /etc/systemd/system/dune-accuser.service [Unit] Description = Dune Accuser Service Wants = network-online.target BindsTo = dune-node.service After = dune-node.service [Service] User = baker Group = baker WorkingDirectory = /home/baker/ ExecStartPre = /bin/sleep 1 ExecStart = /home/baker/dune-network/dune-accuser-all Restart = on-failure [Install] WantedBy = multi-user.target
Same commands as for node to enable, reload/start, stop and get status on the accuser:
sudo systemctl enable dune-accuser.servicesudo systemctl reload-or-restart dune-accuser.servicesudo systemctl stop dune-accuser.servicesudo systemctl status dune-accuser.service
Combining all the services to get a nice status page for your Dune operations
sudo systemctl status dune-node.service dune-baker.service dune-endorser.service dune-accuser.service
Or alternatively, shorter but less ordered: sudo systemctl status 'dune-*.service'
You can restart all four services by restarting the node (because we bound the baker/endorser/accuser to the node):
sudo systemctl reload-or-restart dune-node.service
Similarly all services will stop upon:
sudo systemctl stop dune-node.service
And you can stop the baker/endorser/accuser individually if you want.
sudo systemctl stop dune-baker.servicesudo systemctl stop dune-endorser.servicesudo systemctl stop dune-accuser.service
Using front-end nodes and a private baker
The above configurations work for both front end nodes and for baking/endorsing/accusing nodes. If you want to use this (I recommend you do) for your front-end nodes too, simply remove the line RequiredBy = dune-baker.service Dune-endorser.service Dune-accuser.service from your dune-node.service and do not install the baker/accuser/endorser services.
Restarting your Dune operations automatically
Above, we use Restart:on-failure. You could use Restart:always – I just haven’t found it neccessary and there is a slight risk that – if combinded with loose restart settings – could exhaust your system. But feel free to try it out if it’ll make you sleep better at night. Now that you have all your Dune operations ‘servicified’ you can indeed start sleeping at night again, without loosing out on your baking and endorsing slots.
Using journalctl to monitor the node, baker, endorser and accuser
Sometimes it is neccessary to go through log files to identify root causes for different events and sometimes it is just fun to follow the your Dune services (=daemons) live. systemd has a very powerful tool to do this – it is called journalctl and a few examples on how to use it are given below.
To simply follow your node’s output real-time:
journalctl --follow --unit=dune-node.service
You dont really need to add the .service — but I’ll keep doing it here for clarity
Similarly with the baker, endorser and accuser:
journalctl --follow --unit=dune-baker.servicejournalctl --follow --unit=dune-endorser.servicejournalctl --follow --unit=dune-accuser.service
You can also get the output formatted to suit your needs. Try for example:
journalctl --follow --unit=dune-endorser.service --output=json-pretty
Dune runs its time by the universal timezone ‘UTC’ to get journalctl to output your log in utc simply add — utc:
journalctl --follow --unit=dune-endorser.service --utc
By now you’ve probably understood that the possibilities are almost endless and the flexibility is second to none. Try for example to get your log for the endorser after a given timestamp or between two timestamps by doing these:
journalctl --unit=dune-endorser.service --since=yesterdayjournalctl --unit=dune-endorser.service --since=todayjournalctl --unit=dune-endorser.service --since='2020-10-01 00:00:00' --until='2022-10-31 12:00:00'
Or find your bakes since last boot:
journalctl --unit=dune-baker.service --boot=-0 | grep candidate
If you have installed/compiled journalctl with pattern matching functionality you can do:
journalctl --unit=dune-baker.service --boot=-0 --grep=candidate
And on and on….
See more using man journalctl
Forget about cron jobs etc — systemd has you covered for some happy hands-off baking…
Enjoy!
Leave a Reply