Ubuntu CLI Install: System Automations

[Llibyddap]

Running a guardian node on ubuntu 20.04 headless server. After going through the process of getting it to sync and working through the finickiness of the databases (see 42and 40) I'd like to understand (i) if there are any best practices for running as systemd and (ii) how does the summary fingerprint persists?

Systemd The basic idea would be to create a system service. But I think it probably needs to run a bash or expect script to pass the node passphrase... Here's the idea:

#  /etc/systemd/system/guardian.service
[Unit]
Description=Guardian Node service
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/etc/systemd/system/guardian.sh

[Install]
WantedBy=multi-user.target

(Yes, I know... it's running as root...) This would be the script that is run in expect and would look to initialize the node on restart.

# /etc/systemd/system/guardian.sh
#!/usr/bin/expect

spawn /root/theta_mainnet/bin/theta start --config=/root/theta_mainnet/guardian_mainnet/node
expect "Please enter the password to launch the Theta node:"
send "super_secrete_password\r"
interact
EOF

And to be complete - run it with:

chmod +x guardian.sh
systemctl start guardian.service
systemctl enable guardian.service

Although this is how I've done similar automation on my servers with persistent services - I have some concerns about how the start/restart of the system will work relative to the DB.

summary fingerprint/key During various iterations of my install I noticed that the summary key changed with each 'build'. If the db is deleted due to a corruption, does that create a new summary fingerprint such that the corrupted node has to be unstaked and then the new node restaked after the WithdrawnReturn Height is reached?

Thought I would start here before I begin hacking away.

[Llibyddap]

Here's what I resolved...

Automated Launch The scripting above turned out to be too erratic and wouldn't work consistently. So rather than using systemd, I reverted to crontab execution. I added a single line to the crontab for -u root. The line ensures that guardian.sh is called on boot or reboot of the server.

# crontab -e -u root

@reboot /etc/systemd/system/guardian.sh

The actual scripting called by crontab simply dumps the password into the theta executable. Obviously not the best form, but it's reliable and now tested.

# /etc/systemd/system/guardian.sh

#!/bin/bash

printf 'super_secrete_password' | /root/theta_mainnet/bin/theta start --config=/root/theta_mainnet/guardian_mainnet/node

while true; do sleep 600; done

Don't forget to use your own super_secrete_password. If there is a better solution on the exit that would be great. I found that without leaving the script open it would eventually cause the exit of theta.

summary fingerprint/key After a dozen reboots I found that:

1. the db didn't become corrupted, and
2. the summary fingerprint didn't change

So, I still have this open question.