• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

System wide Masternode Setup with Systemd auto (re)start RFC

Should the official guide be updated to this one

  • yes

    Votes: 19 90.5%
  • no

    Votes: 2 9.5%

  • Total voters
    21

xkcd

Well-known member
Masternode Owner/Operator
Hi Dash Commuity.

I have been working with @strophy on possibly upgrading the Dash Masternode setup guide to make the installation of Dash more inline with other packages, ie a proper installation of Dash in system wide directory /opt. The advantage of doing so, means the dashd daemon can then be controlled by systemd and made to start at boot and restart in event of a crash, it makes upgrading easy, it means the executables are managed by root alone, it makes downgrading easier, it means there wont be other rouge versions of `dashd` floating around that confuse users.

@strophy has asked me to post this and Request For Comments from community members, eg @UdjinM6 and others I don't know you all. Also, thanks to @t0dd for the dashd.service unit file, which I pinched and tweaked and stripped.

The flow is similar to what you might find in the LinuxFromScratch book, which basically explains the commands and their purpose and then provides a block the user need only copy and paste into the terminal. Where possible the blocks are fault tolerant and re-runnable. Also, for crucial blocks they will echo a confirmation message for peace of mind, and help with support.

The installation attempts abide my the principle of least privilege as that will increase the security of the server. It prevents ssh logins via root, you need only check your VPS logs to see how often that is brute forced on your machine, rather it creates two new users dashadmin and dash the admin user will have sudo privelges, but the dash user no special priveleges whatsoever and password that is pure random.

The part of the existing guide https://docs.dash.org/en/stable/masternodes/setup.html#set-up-your-operating-system that I want to change starts from the VPS setup. Ie right from the first login to the freely created VPS. I have tested the guide in Ubuntu 18.04 LTS and Raspbian (Rasp Pi2b). It is fully portable.

Below starts the new stuff. Oh note, the commentry is very terse at the moment, but the code is correct, requesting comments on the code/strategy.


# This is the updated guide for MN setup.

# Login to the VPS as root and change the password of this user to something complicated and long, write it down and keep it safe.

Code:
passwd root

# We will create two new users, one to administer the server and one to run the `dashd` service. We abide my the principle of least privilege `https://en.wikipedia.org/wiki/Principle_of_least_privilege` as that will increase the security of the server.

Code:
useradd -m -c dash dash -s /bin/bash
useradd -m -c "Dash Admin" dashadmin -s /bin/bash -G sudo,dash

# For the dash user, choose a very random long passwd. You don't have to remember this password or write it down, it will never be used.

Code:
< /dev/urandom tr -dc A-Za-z0-9 | head -c${1:-32};echo
passwd dash

# For the dashadmin user, choose a long password and write it down, this is the password you will use from now on to login into the VPS and administer the masternode.

Code:
passwd dashadmin

# Now it is time to logout and try logging in with your dashadmin user and password. To logout, press CTRL+D in the PuTTY (shell) window, or type exit, or type logout until the window is closed, avoid pressing the X icon to close this window.
# Login as dashadmin

# Make sure you are now logged in as dashadmin and not root, check with the output from the below command.

Code:
whoami

# For security reasons we want to disable remote logins to the root user from now on. This user exists on every UNIX/Linux machine and is being brute force attacked on your machine all the time! Run the below block. Copy & paste the block in one go into the terminal (PuTTY).

Code:
if (( $(id -u) != 0 )); then
sudo bash -c \
"grep -q \".*PermitRootLogin [ny][oe].*\" /etc/ssh/sshd_config &&\
sed -i 's/.*PermitRootLogin [ny][oe].*/PermitRootLogin no/g' /etc/ssh/sshd_config||\
echo \"PermitRootLogin no\">>/etc/ssh/sshd_config"
else echo "Only run this block as your dashadmin user, not root."; fi

# Now, we will update the system from the Ubuntu package repository:

Code:
sudo apt update
sudo apt upgrade

# Install additional packages required for the MN.

Code:
sudo apt install ufw python virtualenv git unzip pv speedtest-cli

# Configure a firewall.

Code:
sudo ufw allow ssh/tcp &&\
sudo ufw limit ssh/tcp &&\
sudo ufw allow 9999/tcp &&\
sudo ufw logging on &&\
sudo ufw enable

# Configure swap space so that the VPS has at least 1GB of swap, this helps with avoiding crashes when the RAM is running low.

Code:
if (( $(free -m|grep Swap|awk '{print $2}') < 2048 ))
then
  echo "Adding 2GB swap..."
  sudo bash -c "fallocate -l 2G /var/swapfile&&\
  chmod 600 /var/swapfile&&\
  mkswap /var/swapfile&&\
  swapon /var/swapfile&&\
  grep -q \"^/var/swapfile.none.swap.sw.0.0\" /etc/fstab ||\
  echo -e \"/var/swapfile\tnone\tswap\tsw\t0\t0\" >>/etc/fstab"
else
  echo "You already have enough swap space."
fi

# Memory management. We want the VM to use memory more effectively and prevent crashes due to low memory. Run the below to set this parameter.

Code:
sudo bash -c "echo \"vm.overcommit_memory=1\">>/etc/sysctl.conf"

# Time now to let the above changes take effect and make sure the VPS is able to reboot properly. Run the below command to reboot the VPS, your terminal session will automatically close.

Code:
sudo reboot

# Log back into the VPS using dashadmin.
# Make sure you are now logged in as dashadmin and not root, check with the output from the below command.
Code:
whoami

# We now download and install the dashcore software. Run the below commands.

Code:
cd /tmp/
wget https://github.com/dashpay/dash/releases/download/v0.17.0.3/dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz

# Generate the SHA256 hash (checksum) for the package to make sure it is not corrupted or been tampered with in some way, do not skip this step.

Code:
sha256sum dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz

Verify the hash matches the one from the github page https://github.com/dashpay/dash/releases click on the latest version and find the file called SHA256SUMS.asc and open it ina text editor. You can also verify the signatures with the core devs using Darren TAPPs guide
, but for now I am not adding those steps here.

# If all the above checks are OK, the proceed the install the package copy & paste the block below to install Dash.


Code:
sudo bash -c "cd /opt&& rm -f dash 2>/dev/null;tar xvf /tmp/dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz&& ln -s dashcore-0.17.0 dash"

# Note: When upgrading to a version that is 0.16.x where x is 1,2,3... use the above command and change the version number as appropriate, you will also have to download and check the file hash as posted above, then stop and start your dashd again (instructions for this are later in this document) and you are done. Watch the wallet though as you may have to restart the MN from the wallet too.

# The dash package comes with user manuals, we want these to be available to the dash user, run the below command.

Code:
sudo bash -c "echo -e \"MANPATH_MAP\t/opt/dash/bin\t\t/opt/dash/share/man\">>/etc/manpath.config"


# Next, we need to configure the PATH environment variable for the dash user so it can run dash commands, eg `dashd` and `dash-cli` etc
Code:
sudo bash -c "echo 'PATH=/opt/dash/bin:\$PATH'>>/home/dash/.profile"

# Configure a bare bones dash.conf file.

Code:
sudo -u dash bash -c "mkdir -p /home/dash/.dashcore&&cat >/home/dash/.dashcore/dash.conf<<\"EOF\"
#----
rpcuser=rpcuser$(< /dev/urandom tr -dc A-Za-z0-9 | head -c20;echo)
rpcpassword=rpcpassword$(< /dev/urandom tr -dc A-Za-z0-9 | head -c20;echo)
rpcallowip=127.0.0.1
#----
listen=1
server=1
daemon=1
#----
masternodeblsprivkey=XXXXXXXXXXXXXXXXXXXXXX
externalip=$(curl http://ipecho.net/plain)
#----
EOF"

# Edit the `dash.conf` file with nano and enter your masternodeblsprivkey, Ctrl + X to close the editor, then Y and Enter save the file.
Code:
sudo -i -u dash bash -c "nano ~/.dashcore/dash.conf"


# Next we wish to register the `dashd` deamon as a system process so that is starts automatically when the VPS boots and shutdown automatically when the VPS shutsdown, it will also restart the process if it should crash for some reason.

Code:
sudo mkdir -p /etc/systemd/system&&\
sudo bash -c "cat >/etc/systemd/system/dashd.service<<\"EOF\"
[Unit]
Description=Dash Core Daemon
After=syslog.target network-online.target

# Notes:
#
# Watch the daemon service actions in the syslog journal with:
# sudo journalctl -u dashd.service -f

[Service]
Type=forking
User=dash
Group=dash

# Make dashd less likely to be killed when RAM is low.
OOMScoreAdjust=-1000

ExecStart=/opt/dash/bin/dashd -pid=/home/dash/.dashcore/dashd.pid
# Time that systemd gives a process to start before shooting it in the head
TimeoutStartSec=10m

# If ExecStop is not set, systemd sends a SIGTERM, which is \"okay\", just not ideal
ExecStop=/opt/dash/bin/dash-cli stop

# Time that systemd gives a process to stop before shooting it in the head
TimeoutStopSec=120

Restart=on-failure
# If something triggers an auto-restart, let's wait a bit before taking further action
# Note: This value is in addition to the stop sleep time
RestartSec=120

# In this interval span of time, we allow systemd to start dashd "burst" number
# of times. With Dash we really only want one instance started, so... let's
# really limit this. But we want to give systemd some room to attempt to
# correct things. To be honest, I think the way things are configured between
# these settings and TimeoutStartSec, only one instance will be initiated.
StartLimitInterval=300
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

# Really useful:
# * https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
# * https://www.freedesktop.org/software/systemd/man/systemd.service.html
# * man systemd, man systemd.service, and man systemd.unit

EOF"
 
Last edited:
Continues from previous post.......



# Next we register with systemd which controls all the processes (daemons) running on the VPS and ask it to enable `dashd` at boot and to launch it for the first time.

Code:
sudo systemctl daemon-reload &&\
sudo systemctl enable dashd &&\
sudo systemctl start dashd &&\
echo "Dash is now installed as a system service and initializing..."

# To see the status of the `dashd` process issue the below command.

Code:
systemctl status dashd.service

# You should see it running. If not, go back through this guide and check everything has been done correctly. To view systemd logs for dash, issue:

Code:
sudo journalctl -u dashd.service -f

# Press 'CTRL+C' to quit.

# Also to view the dashd logs, issue the below command CTRL+C to quit, the logs should be streaming past very quickly.

Code:
sudo tail -300f ~/../dash/.dashcore/debug.log

# To see that dashd is running correctly, we need to configure and run `top`
# The below steps for configuring `top` are optional, but if you do it will make the UI much more user friendly. Copy & paste the block below into the terminal.

Code:
echo "H4sICKY9SFsCAy50b3ByYwCt01tv0zAUB/Dn+lP4ibUQRhMnoYNmG2vVXVjHZRuXcQle4qQecRPZ
iRo+EGziCWlD1VoKQ7TfCwdVcvbYiZfoHCU+/v90lDROlgRsxf2AhrBDIwKru7Sf5TDhsUeEIAIO
aNqTj74fD0QNbPsPqAa7sU9cHKXC40593lJO80Q4ugbbJMKf3JQy4qBl+bqVcXneqYM2CSoBJZEv
vIw7n8/OL76Pf0yupsPR5ezWUu32He3u8r26btiN1bVHG63O5tb2zuPd7t6Tp8+e7x8cvnj56vXR
m7fv3rsf8LHnkyDs0RNQkbODCIfyahsZlqFBEfNU5s0dvaFBhvMUi4+iyBlynPRcL8lKHSNMdqAi
Msa8iBf5mQjFvOwR7Bcl0mAxpSgNsBMflxlfLoej6vnFdDxZb57OlMK6KWMFNUyzxKgvrrCVwlaK
+0phgy5hZcVo3Jz8/HX1u7ux96eNzKFcSPWaZWXuuKnC0BdnWIphKYapGBY4FPzaMk7Pvn6TC5nO
av+y6wYyZfiHTWd1bf1/LAMtrkBKgZTCUAoEOjQnvjugPhFpMWhfHnWZ8HBEivZAflhqjwiPXZEl
CZe/qLwJ/AVPpBK+xwMAAA=="|\
base64 -d|zcat >~/.toprc


# You can view the .toprc with the below command

Code:
cat ~/.toprc

# Test `top` with the below command. This will show you what is running on the VPS, processes using the most CPU will appear at the top of the list. You should see `dashd` at the top of the list, it should be running as the 'dash' user. You can also monitor memory usage. Once done press 'q' to quit.

Code:
top

# From now on to start/stop `dashd` use the below commands and the final one is to monitor its present status. Do not run the below commands now, keep them for your reference.

Code:
sudo systemctl start dashd
sudo systemctl stop dashd
sudo systemctl status dashd

# The next few commands should be run as the dash user, login as the dash user now.:
Code:
sudo su - dash

# Verify you actually are the dash user by typing in `whoami` is should display dash.

Code:
whoami

# The below will install and configure sentinel.
Code:
cd &&\
git clone https://github.com/dashpay/sentinel &&\
cd sentinel &&\
virtualenv venv &&\
venv/bin/pip install -r requirements.txt &&\
venv/bin/py.test test &&\
venv/bin/python bin/sentinel.py


# You will see a message reading dashd not synced with network! Awaiting full sync before running Sentinel. Add sentinel to crontab to make sure it runs every 10 minutes to check on your masternode:


Code:
echo "*/10 * * * * { test -f ~/.dashcore/dashd.pid&&cd ~/sentinel && venv/bin/python bin/sentinel.py;} >> \
~/sentinel/sentinel-cron.log 2>&1" \
|crontab -&&echo "Successfully installed cron job."

# We now need to wait for 15 confirmations of the collateral transaction to complete, and wait for the blockchain to finish synchronizing on the masternode. You can use the following commands to monitor progress:

Code:
dash-cli mnsync status
dash-cli getblockcount
dash-cli masternode status


# To exit the VPS and close your session, either press CTRL+D repeatedly until all sessions are closed, or type `exit` repeatedly, you can also use `logout`.

Code:
exit


----------------------------------------------------

Thanks for reading, that is the end of the guide. By this time, dash binaries are installed in /opt a non-privileged user called dash exists with only dashcore created files in ~/.dashcore and a sentinel installation is in ~/sentinel and systemd is configured to startup/shutdown dashd on system reboots automatically and in the event of dashd crash.

Please leave your feedback.
-xkcd
 
Last edited:
Thanks for this significant contribution! Since I have a much more limited understanding of Linux system architecture, I have asked @xkcd to post this here for more community input before we consider changing the docs. On the positive side, standardizing installation in this way would make troubleshooting considerably easier and result in longer lasting masternodes with better uptime. The risk of attack is also significantly reduced, and resource usage has more checks and stops to keep dashd running, particularly on low end hardware. I particularly like and strongly support the fact that this runs as a daemon, under its own user, controlled by systemd.

However, it also adds considerable complexity and margin for user error. As someone lurking and providing occasional support in the Discord support channels all day, I'm worried that our many Windows users with literally zero understanding of Linux may get stuck and have no idea about what they have done wrong or how to fix it. This increases support burden for problems only peripherally related to the actual task of installing and starting a Dash masternode. It could also encourage users to run on lower spec hardware than strictly required because of the resilience of this setup in low memory environments. I wonder if this would better be delivered as an Ansible script, or integrated into dashman, to reduce the margin of error while following the procedure.

Interestingly, one of the (few) innovations by the SAFE fork of Dash is a (closed source) one-click masternode installer delivered as a .exe Windows binary. Would something like this be possible using Ansible? Could several of these steps be further optimised by packaging dashd for Debian/Ubuntu on Launchpad? What is our policy on code that isn't compiled using Gitian? @t0dd how does this work on Redhat?

Comments please @flare @moocowmoo @TaoOfSatoshi @thephez @UdjinM6
 
Philosophical comments and why I built the Fedora/RHEL/CentOS packages the way I did (from which @xkcd developed some of this configuration)...
  1. If you are running a masternode, robustness and repeatability matters -- you need to run it like a sysadmin even if you are not a sysadmin
  2. system-native packaging should be the norm. An update or upgrade should be essentially a 1-line command, or close to that (as should backups) ... rpms coming from a DNF/YUM repo for Fedora, for example. .deb/APT for debian derived linuxes
  3. systemd to manage the service in case of reboot, etc. Plus you can build in things like "email me if the masternode restarts" and such (see my docs in github.com/dashcore-rpm)
  4. dedicated system user who has permissions/ownership of the app and system-level config -- I use dashcore, @xkcd uses just dash it looks like
  5. follow the Filesystem Hierarchy Standard for location of all the bits - http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html ... for example...
    • /usr/bin (dash-qt, dash-cli, and dashd) or even /usr/sbin (arguably for dashd)
    • for system-level masternode/node ...only user dashcore has access
      • /var/lib for masternode/node data files (the blockchain, etc)
      • /etc/ for masternode/node config
      • /var/log for log files
    • for user run GUI wallet and such
      • typical ~/.dashcore location
  6. Recommend all packages be deployed to a reliable repository and GPG signed
  7. Recommend y-stream packages 12.Y have their own new repository to avoid inadvertent upgrades between protocols. Example, I have 12.1, 12.2, 12.3 repositories. Upgrades between z-stream releases is trivial and can be automated. Upgrades between y-stream releases requires a manual configuration change.
The only real controversial thing I have implemented is putting dashd in /usr/sbin. There are solid arguments either way for placing it in /usr/sbin or /usr/bin ... /usr/local/{sbin,bin} I think is not correct.

/opt/ is for oddball stuff IMHO. But... my opinion.

Note: I package sentinel as well. It should be just as stupid easy

The big advantages of doing this this way...
  • I can update and reboot my masternode OS with zero concern beyond normal "I'm updating the kernel" concerns. This is what it looks like on my system: sudo upgrade -y && sudo reboot
    and if I want to be extra careful: sudo upgrade -y && sudo systemctl stop dashd ; sudo reboot
    I even do that for z-stream releases: 12.3.1 to 12.3.2 for example
  • With explicit instruction, it shrinks the error margin for relatively unskilled people while boosting the reliability of the deployment.
  • Updates can be fully automated. Upgrades remain relatively simple (my systems were down for less than a minute during major y-stream releases: 12.0 to 12.1, 12.1 to 12.2, 12.2 to 12.3
  • If you have a super beefy machine, you could probably figure out how to run multiple dashd's far more cleanly though, to be frank, I haven't tried. I probably should.
  • These kinds of configurations are the same between linux distributions. The packaging may be different, but the workflow, file locations, and systemd are all universal. And yes, at this point systemd is far superior to initd. :)
The disadvantages...
  • having your datadir in /var/lib/dashcore (or whereever) and your config in /etc/dashcore/dash.conf may confuse some people.
  • using dedicated system user (no login dir even) can confuse people and makes running some commands more complicated: sudo -u dashcore dash-cli getnetworkinfo (for example)
  • setting up things like event emailing is not rocket science but it is not trivial either. But that is advanced stuff no matter how you do it, I suppose.
  • The concept of a system service is foreign to a lot of people.
  • Windows does it differently. launchd on Apple is conceptually similar. IMHO at some point masternode deployments across all platforms should be this type, or in containers perhaps, but that can also be done incorrectly as well.
Anyway. Those are my initial thoughts. I should have contributed my stuff upstream a long time ago probably. I will help out where I can if @xkcd does so. I will be contributing desktop refinement stuff soon, for sure.

Comments and criticisms welcome. -todd
 
So I had a brief chat with @nmarley who recommended breaking this work up into a PPA to install Dash properly (using systemd and correct folders, etc.) on Debian-like systems, while using Docker images to simplify the steps and configuration required to perform a masternode installation. I'm not familiar with Docker, but it sounds like a simple, reasonable and more popular alternative to Ansible or some arbitrary copy-paste script from a forum or the docs. What do you guys think?
 
Hi @strophy , I have been working on a script that does the installation and configuration as detailed above. I will look into using Docker, but for a dedicated system like a MN it may be of little benefit and instead incur an overhead, ie disk/ram/cpu. I have read of @t0dd s comments and generally disagree on location of conf files data files and even the package itself, given I do believe the dash package is an oddball and it is more convienent to the user to have the user data kept together, it also makes running test nodes easier, since those would run under a separate user, thus all the dynamic stuff is contained use the user's home folder.

upload_2018-7-18_20-8-58.png
 
To update to 13.3, just copy and paste the below blob as the dash admin user (any user that has admin rights).
Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.13.3.0/dashcore-0.13.3.0-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.13.3.0-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.13.3.0-x86_64-linux-gnu.tar.gz && \
sudo rm dash && \
sudo ln -s dashcore-0.13.3 dash && \
sudo systemctl restart dashd
 
Last edited:
To update to 14.0, just copy and paste the below blob as the dash admin user (any user that has admin rights).
Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.14.0.1/dashcore-0.14.0.1-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.14.0.1-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.14.0.1-x86_64-linux-gnu.tar.gz && \
sudo rm dash && \
sudo ln -s dashcore-0.14.0 dash && \
sudo systemctl restart dashd

Next, remove sentinel and re-install it. This must be run as the `dash` user.
Code:
sudo su - dash
and then...
Code:
cd &&\
rm -fr sentinel ;\
git clone https://github.com/dashpay/sentinel &&\
cd sentinel &&\
virtualenv venv &&\
venv/bin/pip install -r requirements.txt &&\
venv/bin/py.test test &&\
venv/bin/python bin/sentinel.py
 
Last edited:
To upgrade to v0.14.0.5 we just need to replace the binaries and restart the daemon, the below will do that when run as the dash-admin user. Check the sha256sum is same as the one on Github.
Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.14.0.5/dashcore-0.14.0.5-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.14.0.5-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.14.0.5-x86_64-linux-gnu.tar.gz && \
sudo systemctl restart dashd
 
Last edited:
To upgrade to v0.15.0.0 we just need to replace the binaries and restart the daemon, the below will do that when run as the dash-admin user. Check the sha256sum is same as the one on Github.
Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.15.0.0/dashcore-0.15.0.0-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.15.0.0-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.15.0.0-x86_64-linux-gnu.tar.gz && \
sudo rm dash && \
sudo ln -s dashcore-0.15.0 dash && \
sudo systemctl restart dashd
 
Last edited:
To upgrade to v0.16.1.1 we just need to replace the binaries and restart the daemon, the below will do that when run as the dash-admin user. This willl not reset your position in the payment queue!

First step is to remove some conflicting paramaters from the dash.conf file. Missing this step will prevent the node from starting after the upgrade in some instances.

Code:
sudo -i -u dash bash -c "sed -i '/logtimestamps=/d;/maxconnections=/d;/masternode=/d;/masternodeprivkey=/d' ~/.dashcore/dash.conf"

Now we download and install the binaries... Check the sha256sum is same as the one on Github.

Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.16.1.1/dashcore-0.16.1.1-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.16.1.1-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.16.1.1-x86_64-linux-gnu.tar.gz && \
sudo rm dash && \
sudo ln -s dashcore-0.16.1 dash && \
sudo systemctl restart dashd

Then, please run sudo su - dash to become the dash user and update sentinel.
Code:
cd &&\
rm -fr sentinel ;\
git clone https://github.com/dashpay/sentinel &&\
cd sentinel &&\
virtualenv venv &&\
venv/bin/pip install -r requirements.txt &&\
venv/bin/py.test test &&\
venv/bin/python bin/sentinel.py
 
Last edited:
Dear All,

I have created and released the DASH Masternode Zeus (DMZ) for testing. It is an alternative to the aging DASHMAN. It installs a new masternode on a Ubuntu VPS according to this guide using a simple to use TUI. It is available from https://github.com/kxcd/Masternode-Zeus You can clone it and run it like so,
Code:
git clone https://github.com/kxcd/Masternode-Zeus
chmod +x Masternode-Zeus/masternode_zeus.sh
Masternode-Zeus/masternode_zeus.sh

Here are a couple of pictures of it in action.

Main_Menu.PNG


Status.png
 
Last edited:
xkcd,

ZEUS is fantastic! Thank you for creating and sharing it.

I set up a MN manually using your methodology before you released ZEUS. I'd like to use ZEUS to manage it, but I'm concerned about the mno vs dashadmin usernames and directories. Please advise.
 
...but I'm concerned about the mno vs dashadmin usernames and directories. Please advise.
I am glad you like it! The mno and dashadmin users are setup the same way and interchangable. I just liked mno better as username in the end, so the Zeus sets up the user with that name, but if you were to run Zeus on VPS that you set up as above using my guide it will work just fine using the dashadmin account.
 
I am glad you like it! The mno and dashadmin users are setup the same way and interchangable. I just liked mno better as username in the end, so the Zeus sets up the user with that name, but if you were to run Zeus on VPS that you set up as above using my guide it will work just fine using the dashadmin account.
Worked like a charm! Thank you so much. Really excellent work.
 
Thank you for ZEUS.. it seems to work well. I couldnt get it installed on Ubuntu 16.04 x64 (missing package), but on 20.10 it went fine.
 
I am glad you like it! The mno and dashadmin users are setup the same way and interchangable. I just liked mno better as username in the end, so the Zeus sets up the user with that name, but if you were to run Zeus on VPS that you set up as above using my guide it will work just fine using the dashadmin account.

What if we already setup our masternode with a completely different username (not mno and not dashadmin) and want to use Zeus just for option 2-7 ?
I tried to use Zeus on an already running masternode and could not get it to work with my different username. It would be nice if we could provide Zeus with our specific username, located in our home directory and that we could then use option 2-7.

We could use Zeus as monitoring and update tool then for already installed masternodes, running on specific, non-default, usernames.

I assume that means either fetching the usernames from the home directoy and putting that in a variable to use or asking users for their username and putting that in a variable to use. Masternode operators could have multiple usernames in their home directory for multiple masternodes, so that would need some thinking through.

It would also be nice if Zeus got its own dedicated dash.org/forum thread for more visibility.
 
Last edited:
What if we already setup our masternode with a completely different username (not mno and not dashadmin) and want to use Zeus just for option 2-7 ?
Did you install the MN using the guide above? If not, just copy the BLS from your installation, wipe the VPS, install the latest ubuntu and enter the same BLS key when prompted, there is a reason we install things in a particular way. If Zeus is not finding your MN, chances are it is not installed right.
 
To upgrade to v0.17.0.3 we just need to replace the binaries and restart the daemon, the below will do that when run as the dash-admin user. This willl not reset your position in the payment queue!

Now we download and install the binaries... Check the sha256sum is same as the one on Github.

Code:
cd /tmp/&& \
wget https://github.com/dashpay/dash/releases/download/v0.17.0.3/dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz&& \
sha256sum dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz &&\
cd /opt && \
sudo tar xvf /tmp/dashcore-0.17.0.3-x86_64-linux-gnu.tar.gz && \
sudo rm dash && \
sudo ln -s dashcore-0.17.0 dash && \
sudo systemctl restart dashd

Then, please run sudo su - dash to become the dash user and update sentinel.
Code:
cd &&\
rm -fr sentinel ;\
git clone https://github.com/dashpay/sentinel &&\
cd sentinel &&\
virtualenv venv &&\
venv/bin/pip install -r requirements.txt &&\
venv/bin/py.test test &&\
venv/bin/python bin/sentinel.py
 
Last edited:
Back
Top