mirror of
https://github.com/zerotier/ZeroTierOne.git
synced 2024-12-18 20:47:53 +00:00
105 lines
7.1 KiB
Groff
105 lines
7.1 KiB
Groff
.TH "ZEROTIER\-ONE" "8" "December 2016" "" ""
|
|
.SH "NAME"
|
|
\fBzerotier-one\fR \- ZeroTier virtual network endpoint service
|
|
.SH SYNOPSIS
|
|
.P
|
|
\fBzerotier\-one\fP [\-switches] [working directory]
|
|
.SH DESCRIPTION
|
|
.P
|
|
\fBzerotier\-one\fR is the service/daemon responsible for connecting a Unix (Linux/BSD/OSX) system to one or more ZeroTier virtual networks and presenting those networks to the system as virtual network ports\. You can think of it as a peer to peer VPN client\.
|
|
.P
|
|
It's typically run by init systems like systemd (Linux) or launchd (Mac) rather than directly by the user, and it must be run as root unless you give it the \fB\-U\fP switch and don't plan on actually joining networks (e\.g\. to run a network controller microservice only)\.
|
|
.P
|
|
The \fBzerotier\-one\fR service keeps its state and other files in a working directory\. If this directory is not specified at launch it defaults to "/var/lib/zerotier\-one" on Linux, "/Library/Application Support/ZeroTier/One" on Mac, and "/var/db/zerotier\-one" on FreeBSD and other similar BSDs\. The working directory should persist\. It shouldn't be automatically cleaned by system cleanup daemons or stored in a volatile location\. Loss of its identity\.secret file results in loss of this system's unique 10\-digit ZeroTier address and key\.
|
|
.P
|
|
Multiple instances of \fBzerotier\-one\fR can be run on the same system as long as they are run with different primary ports (see switches) and a different working directory\. But since a single service can join any number of networks, typically there's no point in doing this\.
|
|
.P
|
|
The \fBzerotier\-one\fR service is controlled via a JSON API available at 127\.0\.0\.1:<primary port> with the default primary port being 9993\. Access to this API requires an authorization token normally found in the authtoken\.secret file in the service's working directory\. On some platforms access may be guarded by other measures such as socket peer UID/GID lookup if additional security options are enabled (this is not the default)\.
|
|
.P
|
|
The first time the service is started in a fresh working directory, it generates a ZeroTier identity\. On slow systems this process can take ten seconds or more due to an anti\-DDOS/anti\-counterfeit proof of work function used by ZeroTier in address generation\. This only happens once, and once generated the result is saved in identity\.secret in the working directory\. This file represents and defines/claims your ZeroTier address and associated ECC\-256 key pair\.
|
|
.SH SWITCHES
|
|
.RS 0
|
|
.IP \(bu 2
|
|
\fB\-h\fP:
|
|
Display help\.
|
|
.IP \(bu 2
|
|
\fB\-v\fP:
|
|
Display ZeroTier One version\.
|
|
.IP \(bu 2
|
|
\fB\-U\fP:
|
|
Skip privilege check and allow to be run by non\-privileged user\. This is typically used when \fBzerotier\-one\fR is built with the network controller option included\. In this case the ZeroTier service might only be acting as a network controller and might never actually join networks, in which case it does not require elevated system permissions\.
|
|
.IP \(bu 2
|
|
\fB\-p<port>\fP:
|
|
Specify a different primary port\. If this is not given the default is 9993\. If zero is given a random port is chosen each time\.
|
|
.IP \(bu 2
|
|
\fB\-d\fP:
|
|
Fork and run as a daemon\.
|
|
.IP \(bu 2
|
|
\fB\-i\fP:
|
|
Invoke the \fBzerotier\-idtool\fR personality, in which case the binary behaves like zerotier\-idtool(1)\. This happens automatically if the name of the binary (or a symlink to it) is zerotier\-idtool\.
|
|
.IP \(bu 2
|
|
\fB\-q\fP:
|
|
Invoke the \fBzerotier\-cli\fR personality, in which case the binary behaves like zerotier\-cli(1)\. This happens automatically if the name of the binary (or a symlink to it) is zerotier\-cli\.
|
|
|
|
.RE
|
|
.SH EXAMPLES
|
|
.P
|
|
Run as daemon with OS default working directory and default port:
|
|
.P
|
|
.RS 2
|
|
.nf
|
|
$ sudo zerotier\-one \-d
|
|
.fi
|
|
.RE
|
|
.P
|
|
Run as daemon with a different working directory and port:
|
|
.P
|
|
.RS 2
|
|
.nf
|
|
$ sudo zerotier\-one \-d \-p12345 /tmp/zerotier\-working\-directory\-test
|
|
.fi
|
|
.RE
|
|
.SH FILES
|
|
.P
|
|
These are found in the service's working directory\.
|
|
.RS 0
|
|
.IP \(bu 2
|
|
\fBidentity\.public\fP:
|
|
The public portion of your ZeroTier identity, which is your 10\-digit hex address and the associated public key\.
|
|
.IP \(bu 2
|
|
\fBidentity\.secret\fP:
|
|
Your full ZeroTier identity including its private key\. This file identifies the system on the network, which means you can move a ZeroTier address around by copying this file and you should back up this file if you want to save your system's static ZeroTier address\. This file must be protected, since theft of its secret key will allow anyone to impersonate your device on any network and decrypt traffic\. For network controllers this file is particularly sensitive since it constitutes the private key for a certificate authority for the controller's networks\.
|
|
.IP \(bu 2
|
|
\fBauthtoken\.secret\fP:
|
|
The secret token used to authenticate requests to the service's local JSON API\. If it does not exist it is generated from a secure random source on service start\. To use, send it in the "X\-ZT1\-Auth" header with HTTP requests to 127\.0\.0\.1:<primary port>\|\.
|
|
.IP \(bu 2
|
|
\fBdevicemap\fP:
|
|
Remembers mappings of zt# interface numbers to ZeroTier networks so they'll persist across restarts\. On some systems that support longer interface names that can encode the network ID (such as FreeBSD) this file may not be present\.
|
|
.IP \(bu 2
|
|
\fBzerotier\-one\.pid\fP:
|
|
ZeroTier's PID\. This file is deleted on normal shutdown\.
|
|
.IP \(bu 2
|
|
\fBzerotier\-one\.port\fP:
|
|
ZeroTier's primary port, which is also where its JSON API is found at 127\.0\.0\.1:<this port>\|\. This file is created on startup and is read by zerotier\-cli(1) to determine where it should find the control API\.
|
|
.IP \(bu 2
|
|
\fBcontroller\.db\fP:
|
|
If the ZeroTier One service is built with the network controller enabled, this file contains the controller's SQLite3 database\.
|
|
.IP \(bu 2
|
|
\fBcontroller\.db\.backup\fP:
|
|
If the ZeroTier One service is built with the network controller enabled, it periodically backs up its controller\.db database in this file (currently every 5 minutes if there have been changes)\. Since this file is not a currently in use SQLite3 database it's safer to back up without corruption\. On new backups the file is rotated out rather than being rewritten in place\.
|
|
.IP \(bu 2
|
|
\fBiddb\.d/\fP (directory):
|
|
Caches the public identity of every peer ZeroTier has spoken with in the last 60 days\. This directory and its contents can be deleted, but this may result in slower connection initations since it will require that we go out and re\-fetch full identities for peers we're speaking to\.
|
|
.IP \(bu 2
|
|
\fBnetworks\.d\fP (directory):
|
|
This caches network configurations and certificate information for networks you belong to\. ZeroTier scans this directory for <network ID>\|\.conf files on startup to recall its networks, so "touch"ing an empty <network ID>\|\.conf file in this directory is a way of pre\-configuring ZeroTier to join a specific network on startup without using the API\. If the config file is empty ZeroTIer will just fetch it from the network's controller\.
|
|
|
|
.RE
|
|
.SH COPYRIGHT
|
|
.P
|
|
(c)2011\-2016 ZeroTier, Inc\. \-\- https://www\.zerotier\.com/ \-\- https://github\.com/zerotier
|
|
.SH SEE ALSO
|
|
.P
|
|
zerotier\-cli(1), zerotier\-idtool(1)
|
|
|