Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | |||
users:runningnodes [2015/09/08 03:39] – cmotc | users:runningnodes [2018/02/22 02:32] (current) – Refresh this article, also refer to the tox-bootstrd's README instead of duplication just a small part of it in here (and almost no one uses SysVinit nowadays anyway) nurupo | ||
---|---|---|---|
Line 1: | Line 1: | ||
===== How to run a Bootstrap Node ===== | ===== How to run a Bootstrap Node ===== | ||
- | ==== Installation | + | ==== tox-bootstrapd - Tox Bootstrap Daemon (recommended) |
- | Assuming that Toxcore has already been built, cd to < | + | Tox Bootstrap Daemon, or tox-bootstrapd for short, is a highly configurable Linux/Unix daemon that acts as a bootstrap node. |
- | Change | + | tox-bootstrapd resides in the toxcore repository and is built along with the toxcore as long as you [[https://github.com/TokTok/c-toxcore/blob/master/INSTALL.md|make sure that you have building |
- | === Daemonized version === | + | Once you have built tox-boostrapd, |
- | Toxcore also has a daemonized version of the bootstrap node code wish can be used on SystemV init or systemd init systems. | + | You can also call |
- | You first need to configure tox to build the bootstrap node executable. Run the configure script with < | + | < |
- | === Configuring Daemon script === | + | to see all available command-line options. Most of the options are set in a config file though. |
- | //Note that the following instructions might be out of date and it's preferable to read the [[https:// | + | ==== DHT_bootstrap - Simple Bootstrap Program ==== |
- | Next we need to configure < | + | DHT_bootstrap is a very simple bootstrap program that runs in the foreground. In contrast |
- | Set the //NAME//, //USER//, //CFG//, // | + | DHT_bootstrap resides in the toxcore repository |
- | ^Option^Description^ | + | |
- | | NAME | Name of the executable (default | + | |
- | | USER | Name of the user the daemon will run as (e.g. //tox//) | | + | |
- | | CFG | Location | + | |
- | | PIDFILE | Where to create the pid file for the daemon | | + | |
- | | SCRIPTNAME | Path to the tox_bootstrap_daemon.sh (used to change name of the script) | | + | |
- | There are a few other options generated by a combination of these items, and you may wish to customize them for your needs. | + | Once built, you can call |
- | === Configuring the daemon itself === | + | < |
- | Now we need to configure | + | to see the available options. |
- | At minimum you need to set the // | + | DHT_bootstrap allows bootstrapping off just one other bootstrap node, address, port and key of which you can provide as the first 3 arguments to it. |
- | ^Option^Description^ | + | |
- | | keys_file_path | The path to your keys file that will store the keypair for your daemon | | + | |
- | | pid_file_path | The path to the pid file and should be set based on what you chose for PIDFILE earlier | | + | |
- | + | ||
- | To get the bootstrap nodes, | + | |
- | + | ||
- | === Generate | + | |
- | + | ||
- | Place the daemon script in < | + | |
- | + | ||
- | Finally, start the service! | + | |
- | + | ||
- | === Troubleshooting === | + | |
- | + | ||
- | The daemon outputs to syslog, so if you have the appropriate permissions: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | will give you a nice debug output (NB: if you change the name edit the grep appropriately) | + | |