Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

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

Discussion in 'Masternode Guides' started by xkcd, Jul 12, 2018.

?

Should the official guide be updated to this one

  1. yes

    5 vote(s)
    83.3%
  2. no

    1 vote(s)
    16.7%
  1. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    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` -ne 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}') -lt 1024 ]
    then
      echo "Adding 1GB swap..."
      sudo bash -c "fallocate -l 1G /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.14.0.4/dashcore-0.14.0.4-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.14.0.4-x86_64-linux-gnu.tar.gz
    # Verify the hash matches the one posted online as shown below.

    # 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.14.0.4-x86_64-linux-gnu.tar.gz&& ln -s dashcore-0.14.0 dash"
    # Note: When upgrading to a version that is 0.14.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 -c${1:-8};echo)
    rpcpassword=rpcpassword$(< /dev/urandom tr -dc A-Za-z0-9 | head -c${1:-8};echo)
    rpcallowip=127.0.0.1
    #----
    listen=1
    server=1
    daemon=1
    #----
    masternode=1
    masternodeblsprivkey=XXXXXXXXXXXXXXXXXXXXXX
    externalip=$(wget -qO- http://ipecho.net/plain)
    #----
    EOF"
    # Edit the `dash.conf` file with nano. 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"
     
    #1 xkcd, Jul 12, 2018
    Last edited: Nov 23, 2019
  2. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    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 'q' 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
     
    #2 xkcd, Jul 12, 2018
    Last edited: Feb 2, 2019
    • Winner Winner x 2
  3. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    614
    Likes Received:
    362
    Trophy Points:
    133
    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
     
    • Like Like x 1
  4. t0dd

    t0dd Active Member

    Joined:
    Mar 21, 2016
    Messages:
    145
    Likes Received:
    132
    Trophy Points:
    93
    Dash Address:
    XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
    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
     
    • Like Like x 1
    • Informative Informative x 1
  5. strophy

    strophy Administrator
    Dash Core Team Dash Support Group Moderator

    Joined:
    Feb 13, 2016
    Messages:
    614
    Likes Received:
    362
    Trophy Points:
    133
    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?
     
  6. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    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
     
  7. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    Updated guide for 13.0 release.
     
  8. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    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
    
     
    #8 xkcd, Mar 16, 2019
    Last edited: Apr 18, 2019
  9. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    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
    
     
    #9 xkcd, May 22, 2019
    Last edited: Jun 6, 2019
    • Like Like x 2
    • Winner Winner x 1
  10. xkcd

    xkcd Member
    Masternode Owner/Operator

    Joined:
    Feb 19, 2017
    Messages:
    76
    Likes Received:
    51
    Trophy Points:
    58
    Dash Address:
    XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
    To upgrade to v0.14.0.4 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.4/dashcore-0.14.0.4-x86_64-linux-gnu.tar.gz&& \
    sha256sum dashcore-0.14.0.4-x86_64-linux-gnu.tar.gz &&\
    cd /opt && \
    sudo tar xvf /tmp/dashcore-0.14.0.4-x86_64-linux-gnu.tar.gz && \
    sudo systemctl restart dashd
    
     
    #10 xkcd, Aug 16, 2019
    Last edited: Nov 23, 2019

Share This Page