From 0a09a6e6f247729457d15480f8d2b9bb0b89ae5e Mon Sep 17 00:00:00 2001 From: elijah Date: Mon, 29 Aug 2016 22:55:41 -0700 Subject: Updated (very out of date) docs and README.md --- docs/en/guide/commands.html | 784 ++++++++++++++++++++++++ docs/en/guide/commands/index.html | 784 ++++++++++++++++++++++++ docs/en/guide/config.html | 584 ++++++++++++++++++ docs/en/guide/config/index.html | 584 ++++++++++++++++++ docs/en/guide/domains.html | 298 +++++++++ docs/en/guide/domains/index.html | 298 +++++++++ docs/en/guide/environments.html | 228 +++++++ docs/en/guide/environments/index.html | 228 +++++++ docs/en/guide/getting-started.html | 317 ++++++++++ docs/en/guide/getting-started/index.html | 317 ++++++++++ docs/en/guide/keys-and-certificates.html | 480 +++++++++++++++ docs/en/guide/keys-and-certificates/index.html | 480 +++++++++++++++ docs/en/guide/miscellaneous.html | 145 +++++ docs/en/guide/miscellaneous/index.html | 145 +++++ docs/en/guide/nodes.html | 231 +++++++ docs/en/guide/nodes/index.html | 231 +++++++ docs/en/guide/provider-configuration.html | 223 +++++++ docs/en/guide/provider-configuration/index.html | 223 +++++++ docs/en/guide/virtual-machines.html | 299 +++++++++ docs/en/guide/virtual-machines/index.html | 299 +++++++++ 20 files changed, 7178 insertions(+) create mode 100644 docs/en/guide/commands.html create mode 100644 docs/en/guide/commands/index.html create mode 100644 docs/en/guide/config.html create mode 100644 docs/en/guide/config/index.html create mode 100644 docs/en/guide/domains.html create mode 100644 docs/en/guide/domains/index.html create mode 100644 docs/en/guide/environments.html create mode 100644 docs/en/guide/environments/index.html create mode 100644 docs/en/guide/getting-started.html create mode 100644 docs/en/guide/getting-started/index.html create mode 100644 docs/en/guide/keys-and-certificates.html create mode 100644 docs/en/guide/keys-and-certificates/index.html create mode 100644 docs/en/guide/miscellaneous.html create mode 100644 docs/en/guide/miscellaneous/index.html create mode 100644 docs/en/guide/nodes.html create mode 100644 docs/en/guide/nodes/index.html create mode 100644 docs/en/guide/provider-configuration.html create mode 100644 docs/en/guide/provider-configuration/index.html create mode 100644 docs/en/guide/virtual-machines.html create mode 100644 docs/en/guide/virtual-machines/index.html (limited to 'docs/en/guide') diff --git a/docs/en/guide/commands.html b/docs/en/guide/commands.html new file mode 100644 index 00000000..bccbaf50 --- /dev/null +++ b/docs/en/guide/commands.html @@ -0,0 +1,784 @@ + + + + +Command Line Reference - LEAP Platform Documentation + + + + + + + + +

Command Line Reference

+ +

A copy of leap --help

+ Global Options +
+ leap add-user USERNAME +
+ leap cert +
1. + leap cert ca +
2. + leap cert csr +
3. + leap cert dh +
4. + leap cert update FILTER +
+
+ leap clean +
+ leap compile +
1. + leap compile all [ENVIRONMENT] +
2. + leap compile firewall +
3. + leap compile hosts +
4. + leap compile provider.json +
5. + leap compile zone +
+
+ leap db +
1. + leap db destroy [FILTER] +
+
+ leap debug FILTER +
+ leap deploy FILTER +
+ leap env +
1. + leap env ls [ENVIRONMENT] +
2. + leap env pin ENVIRONMENT +
3. + leap env unpin +
+
+ leap facts +
1. + leap facts update FILTER +
+
+ leap help command +
+ leap history FILTER +
+ leap inspect FILE +
+ leap list [FILTER] +
+ leap local +
1. + leap local destroy [FILTER] +
2. + leap local reset [FILTER] +
3. + leap local save [FILTER] +
4. + leap local start [FILTER] +
5. + leap local status [FILTER] +
6. + leap local stop [FILTER] +
+
+ leap mosh NAME +
+ leap new DIRECTORY +
+ leap node +
1. + leap node add NAME [SEED] +
2. + leap node init FILTER +
3. + leap node mv OLD_NAME NEW_NAME +
4. + leap node rm NAME +
+
+ leap scp FILE1 FILE2 +
+ leap ssh NAME +
+ leap test +
1. + leap test init +
2. + leap test run [FILTER] +
+
+ leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT +

+ +

The command “leap” can be used to manage a bevy of servers running the LEAP platform from the comfort of your own home.

+ +

Global Options

+ +

--log FILE +Override default log file. +Default Value: None
-v|--verbose LEVEL +Verbosity level 0..5 +Default Value: 1
--[no-]color +Disable colors in output.
-d|--debug +Print full stack trace for exceptions and load debugger gem if installed.
--force +Like –yes, but also skip prompts that are potentially dangerous to skip.
--help +Show this message
--version +Display version number and exit.
--yes +Skip prompts and assume “yes”.

+ + +

leap add-user USERNAME

+ +

Adds a new trusted sysadmin by adding public keys to the “users” directory.

+ +

Options

+ +

--pgp-pub-key arg +OpenPGP public key file for this new user +Default Value: None
--ssh-pub-key arg +SSH public key file for this new user +Default Value: None
--self +Add yourself as a trusted sysadmin by choosing among the public keys available for the current user.

+ + +

leap cert

+ +

Manage X.509 certificates

+ +

leap cert ca

+ +

Creates two Certificate Authorities (one for validating servers and one for validating clients).

+ +

See see what values are used in the generation of the certificates (like name and key size), run leap inspect provider and look for the “ca” property. To see the details of the created certs, run leap inspect <file>.

+ +

leap cert csr

+ +

Creates a CSR for use in buying a commercial X.509 certificate.

+ +

Unless specified, the CSR is created for the provider’s primary domain. The properties used for this CSR come from provider.ca.server_certificates, but may be overridden here.

+ +

Options

+ +

--bits BITS +Override default certificate bit length +Default Value: None
--country|-C COUNTRY +Set C in distinguished name. +Default Value: None
--digest DIGEST +Override default signature digest +Default Value: None
--domain DOMAIN +Specify what domain to create the CSR for. +Unless specified, the CSR is created for the provider’s primary domain. The properties used for this CSR come from provider.ca.server_certificates, but may be overridden here. +Default Value: None
--email EMAIL +Set emailAddress in distinguished name. +Default Value: None
--locality|-L LOCALITY +Set L in distinguished name. +Default Value: None
--organization|-O ORGANIZATION +Override default O in distinguished name. +Default Value: None
--state|--ST STATE +Set ST in distinguished name. +Default Value: None
--unit|--OU UNIT +Set OU in distinguished name. +Default Value: None

+ + +

leap cert dh

+ +

Creates a Diffie-Hellman parameter file, needed for forward secret OpenVPN ciphers.

+ +

leap cert update FILTER

+ +

Creates or renews a X.509 certificate/key pair for a single node or all nodes, but only if needed.

+ +

This command will a generate new certificate for a node if some value in the node has changed that is included in the certificate (like hostname or IP address), or if the old certificate will be expiring soon. Sometimes, you might want to force the generation of a new certificate, such as in the cases where you have changed a CA parameter for server certificates, like bit size or digest hash. In this case, use –force. If is empty, this command will apply to all nodes.

+ +

Options

+ +

--force +Always generate new certificates

+ + +

leap clean

+ +

Removes all files generated with the “compile” command.

+ +

leap compile

+ +

Compile generated files.

+ +

leap compile all [ENVIRONMENT]

+ +

Compiles node configuration files into hiera files used for deployment.

+ +

leap compile firewall

+ +

Prints a list of firewall rules. These rules are already implemented on each node, but you might want the list of all rules in case you also have a restrictive network firewall.

+ +

leap compile hosts

+ +

Print entries suitable for an /etc/hosts file, useful for testing your provider.

+ +

leap compile provider.json

+ +

Compile provider.json bootstrap files for your provider.

+ +

leap compile zone

+ +

Prints a DNS zone file for your provider.

+ +

Default Command: all

+ +

leap db

+ +

Database commands.

+ +

leap db destroy [FILTER]

+ +

Destroy one or more databases. If present, limit to FILTER nodes. For example leap db destroy --db sessions,tokens testing.

+ +

Options

+ +

--db DATABASES +Comma separated list of databases to destroy (no space). Use “–db all” to destroy all databases. +Default Value: None
--user USERS +Comma separated list of usernames. The storage databases for these user(s) will be destroyed. +Default Value: None

+ + +

leap debug FILTER

+ +

Output debug information.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

leap deploy FILTER

+ +

Apply recipes to a node or set of nodes.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--tags TAG[,TAG] +Specify tags to pass through to puppet (overriding the default). +Default Value: None
--dev +Development mode: don’t run ‘git submodule update’ before deploy.
--downgrade +Allows deploy to run with an older platform version.
--fast +Makes the deploy command faster by skipping some slow steps. A “fast” deploy can be used safely if you recently completed a normal deploy.
--force +Deploy even if there is a lockfile.
--sync +Sync files, but don’t actually apply recipes.

+ + +

leap env

+ +

Manipulate and query environment information.

+ +

The ‘environment’ node property can be used to isolate sets of nodes into entirely separate environments. A node in one environment will never interact with a node from another environment. Environment pinning works by modifying your ~/.leaprc file and is dependent on the absolute file path of your provider directory (pins don’t apply if you move the directory)

+ +

leap env ls [ENVIRONMENT]

+ +

List the available environments. The pinned environment, if any, will be marked with ‘*’. Will also set the pin if run with an environment argument.

+ +

leap env pin ENVIRONMENT

+ +

Pin the environment to ENVIRONMENT. All subsequent commands will only apply to nodes in this environment.

+ +

leap env unpin

+ +

Unpin the environment. All subsequent commands will apply to all nodes.

+ +

Default Command: ls

+ +

leap facts

+ +

Gather information on nodes.

+ +

leap facts update FILTER

+ +

Query servers to update facts.json.

+ +

Queries every node included in FILTER and saves the important information to facts.json

+ +

leap help command

+ +

Shows a list of commands or help for one command

+ +

Gets help for the application or its commands. Can also list the commands in a way helpful to creating a bash-style completion function

+ +

Options

+ +

-c +List commands one per line, to assist with shell completion

+ + +

leap history FILTER

+ +

Display recent deployment history for a set of nodes.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--last +Show last deploy only

+ + +

leap inspect FILE

+ +

Prints details about a file. Alternately, the argument FILE can be the name of a node, service or tag.

+ +

Options

+ +

--base +Inspect the FILE from the provider_base (i.e. without local inheritance).

+ + +

leap list [FILTER]

+ +

List nodes and their classifications

+ +

Prints out a listing of nodes, services, or tags. If present, the FILTER can be a list of names of nodes, services, or tags. If the name is prefixed with +, this acts like an AND condition. For example:

+ +

leap list node1 node2 matches all nodes named “node1” OR “node2”

+ +

leap list openvpn +local matches all nodes with service “openvpn” AND tag “local”

+ +

Options

+ +

--print arg +What attributes to print (optional) +Default Value: None
--disabled +Include disabled nodes in the list.

+ + +

leap local

+ +

Manage local virtual machines.

+ +

This command provides a convient way to manage Vagrant-based virtual machines. If FILTER argument is missing, the command runs on all local virtual machines. The Vagrantfile is automatically generated in ‘test/Vagrantfile’. If you want to run vagrant commands manually, cd to ‘test’.

+ +

leap local destroy [FILTER]

+ +

Destroys the virtual machine(s), reclaiming the disk space

+ +

leap local reset [FILTER]

+ +

Resets virtual machine(s) to the last saved snapshot

+ +

leap local save [FILTER]

+ +

Saves the current state of the virtual machine as a new snapshot

+ +

leap local start [FILTER]

+ +

Starts up the virtual machine(s)

+ +

Options

+ +

--basebox BASEBOX +The basebox to use. This value is passed to vagrant as the config.vm.box option. The value here should be the name of an installed box or a shorthand name of a box in HashiCorp’s Atlas. +Default Value: LEAP/jessie

+ + +

leap local status [FILTER]

+ +

Print the status of local virtual machine(s)

+ +

leap local stop [FILTER]

+ +

Shuts down the virtual machine(s)

+ +

leap mosh NAME

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. --ssh '-F ~/sshconfig'). +Default Value: None

+ + +

leap new DIRECTORY

+ +

Creates a new provider instance in the specified directory, creating it if necessary.

+ +

Options

+ +

--contacts arg +Default email address contacts. +Default Value: None
--domain arg +The primary domain of the provider. +Default Value: None
--name arg +The name of the provider. +Default Value: None
--platform arg +File path of the leap_platform directory. +Default Value: None

+ + +

leap node

+ +

Node management

+ +

leap node add NAME [SEED]

+ +

Create a new configuration file for a node named NAME.

+ +

If specified, the optional argument SEED can be used to seed values in the node configuration file.

+ +

The format is property_name:value.

+ +

For example: leap node add web1 ip_address:1.2.3.4 services:webapp.

+ +

To set nested properties, property name can contain ‘.’, like so: leap node add web1 ssh.port:44

+ +

Separeate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

+ +

Options

+ +

--local +Make a local testing node (by automatically assigning the next available local IP address). Local nodes are run as virtual machines on your computer.

+ + +

leap node init FILTER

+ +

Bootstraps a node or nodes, setting up SSH keys and installing prerequisite packages

+ +

This command prepares a server to be used with the LEAP Platform by saving the server’s SSH host key, copying the authorized_keys file, installing packages that are required for deploying, and registering important facts. Node init must be run before deploying to a server, and the server must be running and available via the network. This command only needs to be run once, but there is no harm in running it multiple times.

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--echo +If set, passwords are visible as you type them (default is hidden)

+ + +

leap node mv OLD_NAME NEW_NAME

+ +

Renames a node file, and all its related files.

+ +

leap node rm NAME

+ +

Removes all the files related to the node named NAME.

+ +

leap scp FILE1 FILE2

+ +

Secure copy from FILE1 to FILE2. Files are specified as NODE_NAME:FILE_PATH. For local paths, omit “NODE_NAME:”.

+ +

Options

+ +

-r +Copy recursively

+ + +

leap ssh NAME

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. --ssh '-F ~/sshconfig'). +Default Value: None

+ + +

leap test

+ +

Run tests.

+ +

leap test init

+ +

Creates files needed to run tests.

+ +

leap test run [FILTER]

+ +

Run the test suit on FILTER nodes.

+ +

Options

+ +

--[no-]continue +Continue over errors and failures (default is –no-continue).

+ + +

Default Command: run

+ +

leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT

+ +

Creates an SSH port forward (tunnel) to the node NAME. REMOTE_PORT is the port on the remote node that the tunnel will connect to. LOCAL_PORT is the optional port on your local machine. For example: leap tunnel couch1:5984.

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. –ssh ‘-F ~/sshconfig’). +Default Value: None

+ + +

+ + diff --git a/docs/en/guide/commands/index.html b/docs/en/guide/commands/index.html new file mode 100644 index 00000000..ec1785f8 --- /dev/null +++ b/docs/en/guide/commands/index.html @@ -0,0 +1,784 @@ + + + + +Command Line Reference - LEAP Platform Documentation + + + + + + + + +

Command Line Reference

+ +

A copy of leap --help

+ Global Options +
+ leap add-user USERNAME +
+ leap cert +
1. + leap cert ca +
2. + leap cert csr +
3. + leap cert dh +
4. + leap cert update FILTER +
+
+ leap clean +
+ leap compile +
1. + leap compile all [ENVIRONMENT] +
2. + leap compile firewall +
3. + leap compile hosts +
4. + leap compile provider.json +
5. + leap compile zone +
+
+ leap db +
1. + leap db destroy [FILTER] +
+
+ leap debug FILTER +
+ leap deploy FILTER +
+ leap env +
1. + leap env ls [ENVIRONMENT] +
2. + leap env pin ENVIRONMENT +
3. + leap env unpin +
+
+ leap facts +
1. + leap facts update FILTER +
+
+ leap help command +
+ leap history FILTER +
+ leap inspect FILE +
+ leap list [FILTER] +
+ leap local +
1. + leap local destroy [FILTER] +
2. + leap local reset [FILTER] +
3. + leap local save [FILTER] +
4. + leap local start [FILTER] +
5. + leap local status [FILTER] +
6. + leap local stop [FILTER] +
+
+ leap mosh NAME +
+ leap new DIRECTORY +
+ leap node +
1. + leap node add NAME [SEED] +
2. + leap node init FILTER +
3. + leap node mv OLD_NAME NEW_NAME +
4. + leap node rm NAME +
+
+ leap scp FILE1 FILE2 +
+ leap ssh NAME +
+ leap test +
1. + leap test init +
2. + leap test run [FILTER] +
+
+ leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT +

+ +

The command “leap” can be used to manage a bevy of servers running the LEAP platform from the comfort of your own home.

+ +

Global Options

+ +

--log FILE +Override default log file. +Default Value: None
-v|--verbose LEVEL +Verbosity level 0..5 +Default Value: 1
--[no-]color +Disable colors in output.
-d|--debug +Print full stack trace for exceptions and load debugger gem if installed.
--force +Like –yes, but also skip prompts that are potentially dangerous to skip.
--help +Show this message
--version +Display version number and exit.
--yes +Skip prompts and assume “yes”.

+ + +

leap add-user USERNAME

+ +

Adds a new trusted sysadmin by adding public keys to the “users” directory.

+ +

Options

+ +

--pgp-pub-key arg +OpenPGP public key file for this new user +Default Value: None
--ssh-pub-key arg +SSH public key file for this new user +Default Value: None
--self +Add yourself as a trusted sysadmin by choosing among the public keys available for the current user.

+ + +

leap cert

+ +

Manage X.509 certificates

+ +

leap cert ca

+ +

Creates two Certificate Authorities (one for validating servers and one for validating clients).

+ +

leap cert csr

+ +

Creates a CSR for use in buying a commercial X.509 certificate.

+ +

Unless specified, the CSR is created for the provider’s primary domain. The properties used for this CSR come from provider.ca.server_certificates, but may be overridden here.

+ +

Options

+ +

--bits BITS +Override default certificate bit length +Default Value: None
--country|-C COUNTRY +Set C in distinguished name. +Default Value: None
--digest DIGEST +Override default signature digest +Default Value: None
--domain DOMAIN +Specify what domain to create the CSR for. +Unless specified, the CSR is created for the provider’s primary domain. The properties used for this CSR come from provider.ca.server_certificates, but may be overridden here. +Default Value: None
--email EMAIL +Set emailAddress in distinguished name. +Default Value: None
--locality|-L LOCALITY +Set L in distinguished name. +Default Value: None
--organization|-O ORGANIZATION +Override default O in distinguished name. +Default Value: None
--state|--ST STATE +Set ST in distinguished name. +Default Value: None
--unit|--OU UNIT +Set OU in distinguished name. +Default Value: None

+ + +

leap cert dh

+ +

Creates a Diffie-Hellman parameter file, needed for forward secret OpenVPN ciphers.

+ +

leap cert update FILTER

+ +

Creates or renews a X.509 certificate/key pair for a single node or all nodes, but only if needed.

+ +

Options

+ +

--force +Always generate new certificates

+ + +

leap clean

+ +

Removes all files generated with the “compile” command.

+ +

leap compile

+ +

Compile generated files.

+ +

leap compile all [ENVIRONMENT]

+ +

Compiles node configuration files into hiera files used for deployment.

+ +

leap compile firewall

+ +

Prints a list of firewall rules. These rules are already implemented on each node, but you might want the list of all rules in case you also have a restrictive network firewall.

+ +

leap compile hosts

+ +

Print entries suitable for an /etc/hosts file, useful for testing your provider.

+ +

leap compile provider.json

+ +

Compile provider.json bootstrap files for your provider.

+ +

leap compile zone

+ +

Prints a DNS zone file for your provider.

+ +

Default Command: all

+ +

leap db

+ +

Database commands.

+ +

leap db destroy [FILTER]

+ +

Destroy one or more databases. If present, limit to FILTER nodes. For example leap db destroy --db sessions,tokens testing.

+ +

Options

+ +

--db DATABASES +Comma separated list of databases to destroy (no space). Use “–db all” to destroy all databases. +Default Value: None
--user USERS +Comma separated list of usernames. The storage databases for these user(s) will be destroyed. +Default Value: None

+ + +

leap debug FILTER

+ +

Output debug information.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

leap deploy FILTER

+ +

Apply recipes to a node or set of nodes.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--tags TAG[,TAG] +Specify tags to pass through to puppet (overriding the default). +Default Value: None
--dev +Development mode: don’t run ‘git submodule update’ before deploy.
--downgrade +Allows deploy to run with an older platform version.
--fast +Makes the deploy command faster by skipping some slow steps. A “fast” deploy can be used safely if you recently completed a normal deploy.
--force +Deploy even if there is a lockfile.
--sync +Sync files, but don’t actually apply recipes.

+ + +

leap env

+ +

Manipulate and query environment information.

+ +

leap env ls [ENVIRONMENT]

+ +

List the available environments. The pinned environment, if any, will be marked with ‘*’. Will also set the pin if run with an environment argument.

+ +

leap env pin ENVIRONMENT

+ +

Pin the environment to ENVIRONMENT. All subsequent commands will only apply to nodes in this environment.

+ +

leap env unpin

+ +

Unpin the environment. All subsequent commands will apply to all nodes.

+ +

Default Command: ls

+ +

leap facts

+ +

Gather information on nodes.

+ +

leap facts update FILTER

+ +

Query servers to update facts.json.

+ +

Queries every node included in FILTER and saves the important information to facts.json

+ +

leap help command

+ +

Shows a list of commands or help for one command

+ +

Gets help for the application or its commands. Can also list the commands in a way helpful to creating a bash-style completion function

+ +

Options

+ +

-c +List commands one per line, to assist with shell completion

+ + +

leap history FILTER

+ +

Display recent deployment history for a set of nodes.

+ +

The FILTER can be the name of a node, service, or tag.

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--last +Show last deploy only

+ + +

leap inspect FILE

+ +

Prints details about a file. Alternately, the argument FILE can be the name of a node, service or tag.

+ +

Options

+ +

--base +Inspect the FILE from the provider_base (i.e. without local inheritance).

+ + +

leap list [FILTER]

+ +

List nodes and their classifications

+ +

leap list node1 node2 matches all nodes named “node1” OR “node2”

+ +

leap list openvpn +local matches all nodes with service “openvpn” AND tag “local”

+ +

Options

+ +

--print arg +What attributes to print (optional) +Default Value: None
--disabled +Include disabled nodes in the list.

+ + +

leap local

+ +

Manage local virtual machines.

+ +

leap local destroy [FILTER]

+ +

Destroys the virtual machine(s), reclaiming the disk space

+ +

leap local reset [FILTER]

+ +

Resets virtual machine(s) to the last saved snapshot

+ +

leap local save [FILTER]

+ +

Saves the current state of the virtual machine as a new snapshot

+ +

leap local start [FILTER]

+ +

Starts up the virtual machine(s)

+ +

Options

+ +

--basebox BASEBOX +The basebox to use. This value is passed to vagrant as the config.vm.box option. The value here should be the name of an installed box or a shorthand name of a box in HashiCorp’s Atlas. +Default Value: LEAP/jessie

+ + +

leap local status [FILTER]

+ +

Print the status of local virtual machine(s)

+ +

leap local stop [FILTER]

+ +

Shuts down the virtual machine(s)

+ +

leap mosh NAME

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. --ssh '-F ~/sshconfig'). +Default Value: None

+ + +

leap new DIRECTORY

+ +

Creates a new provider instance in the specified directory, creating it if necessary.

+ +

Options

+ +

--contacts arg +Default email address contacts. +Default Value: None
--domain arg +The primary domain of the provider. +Default Value: None
--name arg +The name of the provider. +Default Value: None
--platform arg +File path of the leap_platform directory. +Default Value: None

+ + +

leap node

+ +

Node management

+ +

leap node add NAME [SEED]

+ +

Create a new configuration file for a node named NAME.

+ +

If specified, the optional argument SEED can be used to seed values in the node configuration file.

+ +

The format is property_name:value.

+ +

For example: leap node add web1 ip_address:1.2.3.4 services:webapp.

+ +

To set nested properties, property name can contain ‘.’, like so: leap node add web1 ssh.port:44

+ +

Separeate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

+ +

Options

+ +

--local +Make a local testing node (by automatically assigning the next available local IP address). Local nodes are run as virtual machines on your computer.

+ + +

leap node init FILTER

+ +

Bootstraps a node or nodes, setting up SSH keys and installing prerequisite packages

+ +

Options

+ +

--ip IPADDRESS +Override the default SSH IP address. +Default Value: None
--port PORT +Override the default SSH port. +Default Value: None
--echo +If set, passwords are visible as you type them (default is hidden)

+ + +

leap node mv OLD_NAME NEW_NAME

+ +

Renames a node file, and all its related files.

+ +

leap node rm NAME

+ +

Removes all the files related to the node named NAME.

+ +

leap scp FILE1 FILE2

+ +

Secure copy from FILE1 to FILE2. Files are specified as NODE_NAME:FILE_PATH. For local paths, omit “NODE_NAME:”.

+ +

Options

+ +

-r +Copy recursively

+ + +

leap ssh NAME

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. --ssh '-F ~/sshconfig'). +Default Value: None

+ + +

leap test

+ +

Run tests.

+ +

leap test init

+ +

Creates files needed to run tests.

+ +

leap test run [FILTER]

+ +

Run the test suit on FILTER nodes.

+ +

Options

+ +

--[no-]continue +Continue over errors and failures (default is –no-continue).

+ + +

Default Command: run

+ +

leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. Same as --ssh "-p SSH_PORT". +Default Value: None
--ssh arg +Pass through raw options to ssh (e.g. –ssh ‘-F ~/sshconfig’). +Default Value: None

+ + +

+ + diff --git a/docs/en/guide/config.html b/docs/en/guide/config.html new file mode 100644 index 00000000..558f6940 --- /dev/null +++ b/docs/en/guide/config.html @@ -0,0 +1,584 @@ + + + + +Configuration Files - LEAP Platform Documentation + + + + + + + + +

Configuration Files

+ +

Understanding and editing the configuration files.

+ Files +
+ Leapfile +
+ JSON format +
+ Node inheritance +
1. + Inheritance rules +
+
+ Common configuration options +
+ Macros +
+ Hash tables +

+ +

Files

+ +

Here are a list of some of the common files that make up a provider. Except for Leapfile and provider.json, the files are optional. Unless otherwise specified, all file names are relative to the ‘provider directory’ root (where the Leapfile is).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`Leapfile`	If present, this file tells `leap` that the directory is a provider directory. This file is usually empty, but can contain global options.
`~/.leaprc`	Evaluated the same as Leapfile, but not committed to source control.
`provider.json`	Global options related to this provider. See Provider Configuration.
`provider.ENVIRONMENT.json`	Global options for the provider that are applied to only a single environment.
`nodes/NAME.json`	The configuration file for node called NAME.
`common.json`	All nodes inherit from this file. In other words, any options that appear in `common.json` will be added as default values to each node configuration, value that can be locally overridden.
`services/SERVICE.json`	The properties in this configuration file are applied to any node that includes SERVICE in its `services` property.
`services/SERVICE.ENVIRONMENT.json`	The properties in this configuration file are applied to any node that includes SERVICE in its services and has environment equal to ENVIRONMENT.
`tags/TAG.json`	The properties in this configuration file are applied to any node that has includes TAG in its `tags` property.
`tags/TAG.ENVIRONMENT.json`	The properties in this configuration file are applied to any node that has includes TAG in its `tags` property and has `environment` property equal to ENVIRONMENT.
`secrets.json`	An automatically generated file that contains any randomly generated strings needed in order to deploy. These strings are often secret and should be protected, although any need for a random string or number that is remembered will produce another entry in this file. This file is automatically generated and refreshed each time you run `leap compile` or `leap deploy`. If an entry is no longer needed, it will get removed. If you want to change a secret, you can remove this file and have it regenerated, or remove the particular line item and just those items will be created anew.
`facts.json`	If some of your servers are running on AWS or OpenStack, you will need to discover certain properties about how networking is configured on these machines in order for a full deploy to work. In these cases, make sure to run `leap facts update` to periodically regenerate the facts.json file.
`files/*`	Various static files used by the platform (e.g. keys, certificates, webapp customization, etc). In general, only generated files and files used to customize the provider (such as images) live in the `files` directory.
`users/USER/`	A directory that stores the public keys of the sysadmin with name USER. This person will have root access to all the servers.

+ + +

Leapfile

+ +

A Leapfile defines options for the leap command and lives at the root of your provider directory. Leapfile is evaluated as ruby, so you can include whatever weird logic you want in this file. In particular, there are several variables you can set that modify the behavior of leap. For example:

+ +

@platform_directory_path = '../leap_platform'
+@log = '/var/log/leap.log'
+

+ +

Additionally, you can create a ~/.leaprc file that is loaded after Leapfile and is evaluated the same way.

+ +

Platform options:

+ +

@platform_directory_path (required). This must be set to the path where leap_platform lives. The path may be relative.

+ + +

Vagrant options:

+ +

@vagrant_provider. Changes the default vagrant provider (“virtualbox”). For example, @vagrant_provider = "libvirt".
@vagrant_network. Allows you to override the default network used for local nodes. It should include a netmask like @vagrant_network = '10.0.0.0/24'.
@custom_vagrant_vm_line. Insert arbitrary text into the auto-generated Vagrantfile. For example, @custom_vagrant_vm_line = "config.vm.boot_mode = :gui".
@vagrant_basebox allows specifying a different basebox as the default one. For example, @vagrant_basebox = "LEAP/jessie".

+ + +

Logging options:

+ +

@log. If set, all command invocation and results are logged to the specified file. This is the same as the switch --log FILE, except that the command line switch will override the value in the Leapfile.

+ + +

JSON format

+ +

All configuration files, other than Leapfile, are in the JSON format. For example:

+ +

{
+  "key1": "value1",
+  "key2": "value2"
+}
+

+ +

Keys should match /[a-z0-9_]/ and must be in double quotes.

+ +

Unlike traditional JSON, comments are allowed. If the first non-whitespace characters are // then the line is treated as a comment.

+ +

// this is a comment
+{
+  // this is a comment
+  "key": "value"  // this is an error
+}
+

+ +

Options in the configuration files might be nested hashes, arrays, numbers, strings, or boolean. Numbers and boolean values should not be quoted. For example:

+ +

{
+  "openvpn": {
+    "ip_address": "1.1.1.1",
+    "protocols": ["tcp", "udp"],
+    "ports": [80, 53],
+    "options": {
+      "public_ip": false,
+      "adblock": true
+    }
+  }
+}
+

+ +

If the value string is prefixed with an ‘=’ character, the result is evaluated as ruby. For example:

+ +

{
+  "domain": {
+    "public": "domain.org"
+  }
+  "api_domain": "= 'api.' + domain.public"
+}
+

+ +

In this case, the property “api_domain” will be set to “api.domain.org”. So long as you do not create unresolvable circular dependencies, you can reference other properties in evaluated ruby that are themselves evaluated ruby.

+ +

See “Macros” below for information on the special macros available to the evaluated ruby.

+ +

TIP: In rare cases, you might want to force the evaluation of a value to happen in a later pass after most of the other properties have been evaluated. To do this, prefix the value string with “=>” instead of “=”.

+ +

Node inheritance

+ +

Every node inherits from common.json and also any of the services or tags attached to the node. Additionally, the leap_platform contains a directory provider_base that defines the default values for tags, services and common.json.

+ +

Suppose you have a node configuration for bitmask/nodes/willamette.json like so:

+ +

{
+   "services": "webapp",
+   "tags": ["production", "northwest-us"],
+   "ip_address": "1.1.1.1"
+}
+

+ +

This node will have hostname “willamette” and it will inherit from the following files (in this order):

+ +

common.json + +
- load defaults: provider_base/common.json
- load provider: bitmask/common.json
+
service “webapp” + +
- load defaults: provider_base/services/webapp.json
- load provider: bitmask/services/webapp.json
+
tag “production” + +
- load defaults: provider_base/tags/production.json
- load provider: bitmask/tags/production.json
+
tag “northwest-us” + +
- load: bitmask/tags/northwest-us.json
+
finally, load node “willamette” + +
- load: bitmask/nodes/willamette.json
+

+ + +

The provider_base directory is under the leap_platform specified in the file Leapfile.

+ +

To see all the variables a node has inherited, you could run leap inspect willamette.

+ +

Inheritance rules

+ +

Suppose you have a node configuration mynode.json:

+ +

{
+  "tags": "production",
+  "simple_value": 100,
+  "replaced_array": ["dolphin", "kangaroo"],
+  "+add_array": ["red", "black"],
+  "-subtract_array": ["bitter"],
+  "converted_to_array": "not_array_element",
+  "!override": ["insist on this value"],
+  "hash": {
+    "key1": 1,
+    "key2": 2
+  }
+}
+

+ +

And a file tags/production.json:

+ +

{
+  "simple_value": 99999,
+  "replaced_array": ["zebra"],
+  "add_array": ["green],
+  "subtract_array": ["bitter", "sweet", "salty"],
+  "converted_to_array": ["array_element"],
+  "override": "this value will be overridden",
+  "hash": {
+    "key1": "one"
+  }
+}
+

+ +

In this scenario, mynode.json will inherit from production.json. The output of this inheritance will be:

+ +

{
+  "tags": "production",
+  "simple_value": 100,
+  "replaced_array": ["dolphin", "kangaroo"],
+  "add_array": ["red", "black", "green"],
+  "subtract_array": ["sweet", "salty"],
+  "converted_to_array": ["not_array_element", "array_element"],
+  "override": ["insist on this value"],
+  "hash": {
+    "key1": 1,
+    "key2": 2
+  }
+

+ +

The rules for inheritance (where ‘old’ refers to the parent, and ‘new’ refers to the child):

+ +

Simple values (strings, numbers, boolean): + +
- Replace the old value with the new value.
+
Array values: + +
- Two arrays: replace the old array with the new array.
- One array and one simple value: add the simple value to the array.
- If property name is prefixed with “+”: merge the old and new arrays.
- If property name is prefixed with “-”: subtract new array from old array.
+
Hash values: + +
- Hashes are always merged (the result includes the keys of both hashes). If there is a key in common, the new one overrides the old one.
+
Mismatch: + +
- Although you can mix arrays and simple values, you cannot mix arrays with hashes or hashes with simple values. If you attempt to do so, it will fail to compile and give you an error message.
+
Override: + +
- If property name is prefixed with “!”: then ensure that new value is always used, regardless of old value. In this case, the override takes precedence over type checking, so you will never get a type mismatch.
+

+ + +

NOTE: special property name prefixes, like “+”, “-”, or “!”, are not included in the property name. These prefixes determine the merge strategy, but are stripped out when compiling the resulting JSON file.

+ +

Common configuration options

+ +

You can use the command leap inspect to see what options are available for a provider, node, service, or tag configuration. For example:

+ +

leap inspect common – show the options inherited by all nodes.
leap inspect --base common – show the common.json from provider_base without the local common.json inheritance applied.
leap inspect webapp – show all the options available for the service webapp.

+ + +

Here are some of the more important options you should be aware of:

+ +

ip_address – Required for all nodes, no default.
ssh.port – The SSH port you want the node’s OpenSSH server to bind to. This is also the default when trying to connect to a node, but if the node currently has OpenSSH running on a different port then run deploy with --port to override the ssh.port configuration value.
mosh.enabled – If set to true, then mosh will be installed on the server. The default is false.

+ + +

Macros

+ +

When using evaluated ruby in a JSON configuration file, there are several special macros that are available. These are evaluated in the context of a node (available as the variable self).

+ +

The following methods are available to the evaluated ruby:

+ +

variable.variable

+ +

Any variable defined or inherited by a particular node configuration is available by just referencing it using either hash notation or object field notation (e.g. ['domain']['public'] or domain.public). Circular references are not allowed, but otherwise it is OK to nest evaluated values in other evaluated values. If a value has not been defined, the hash notation will return nil but the field notation will raise an exception. Properties of services, tags, and the global provider can all be referenced the same way. For example, global.services['openvpn'].x509.dh.

+ +

nodes

+ +

A hash of all nodes. This list can be filtered.

+ +

nodes_like_me

+ +

A hash of nodes that have the same deployment tags as the current node (e.g. ‘production’ or ‘local’).

+ +

global.services

+ +

A hash of all services, e.g. global.services['openvpn'] would return the “openvpn” service.

+ +

global.tags

+ +

A hash of all tags, e.g. global.tags['production'] would return the “production” tag.

+ +

global.provider

+ +

Can be used to access variables defined in provider.json, e.g. global.provider.contacts.default.

+ +

file(filename)

+ +

Inserts the full contents of the file. If the file is an erb template, it is rendered. The filename can either be one of the pre-defined file symbols, or it can be a path relative to the “files” directory in your provider instance. E.g, file :ca_cert or files 'ca/ca.crt'.

+ +

file_path(filename)

+ +

Ensures that the file will get rsynced to the node as an individual file. The value returned by file_path is the full path where this file will ultimately live when deploy to the node. e.g. file_path :ca_cert or file_path 'branding/images/logo.png'.

+ +

secret(:symbol)

+ +

Returns the value of a secret in secrets.json (or creates it if necessary). E.g. secret :couch_admin_password

+ +

hosts_file

+ +

Returns a data structure that puppet will use to generate /etc/hosts. Care is taken to use the local IP of other hosts when needed.

+ +

known_hosts_file

+ +

Returns the lines needed in a SSH known_hosts file.

+ +

stunnel_client(node_list, port, options={})

+ +

Returns a stunnel configuration data structure for the client side. Argument node_list is an ObjectList of nodes running stunnel servers. Argument port is the real port of the ultimate service running on the servers that the client wants to connect to.

+ +

stunnel_server(port)

+ +

Generates a stunnel server entry. The port is the real port targeted service.

+ +

Hash tables

+ +

The macros nodes, nodes_like_me, global.services, and global.tags all return a hash table of configuration objects (either nodes, services, or tags). There are several ways to filter and process these hash tables:

+ +

Access an element by name:

+ +

nodes['vpn1']                # returns node named 'vpn1'
+global.services['openvpn']   # returns service named 'openvpn'
+

+ +

Create a new hash table by applying filters:

+ +

nodes[:public_dns => true] # all nodes where public_dns == true
+nodes[:services => 'openvpn', 'location.country_code' => 'US'] # openvpn service OR in the US.
+nodes[[:services, 'openvpn'], [:services, 'tor']]  # services equal to openvpn OR tor
+nodes[:services => 'openvpn'][:tags => 'production']  # openvpn AND production
+nodes[:name => "!bob"] # all nodes that are NOT named "bob"
+

+ +

Create an array of values by selecting a single field:

+ +

nodes.field('location.name')
+==> ['seattle', 'istanbul']
+

+ +

Create an array of hashes by selecting multiple fields:

+ +

nodes.fields('domain.full', 'ip_address')
+==> [
+  {'domain_full' => 'red.bitmask.net', 'ip_address' => '1.1.1.1'},
+  {'domain_full' => 'blue.bitmask.net', 'ip_address' => '1.1.1.2'},
+]
+

+ +

Create a new hash table of hashes, with only certain fields:

+ +

nodes.pick_fields('domain.full', 'ip_address')
+==> {
+  "red" => {'domain_full' => 'red.bitmask.net', 'ip_address' => '1.1.1.1'},
+  "blue => {'domain_full' => 'blue.bitmask.net', 'ip_address' => '1.1.1.2'},
+}
+

+ +

With pick_fields, if there is only one field, it will generate a simple hash table:

+ +

nodes.pick_fields('ip_address')
+==> {
+  "red" => '1.1.1.1',
+  "blue => '1.1.1.2',
+}
+

+ +

+ + diff --git a/docs/en/guide/config/index.html b/docs/en/guide/config/index.html new file mode 100644 index 00000000..23e162d0 --- /dev/null +++ b/docs/en/guide/config/index.html @@ -0,0 +1,584 @@ + + + + +Configuration Files - LEAP Platform Documentation + + + + + + + + +

Configuration Files

+ +

Understanding and editing the configuration files.

+ Files +
+ Leapfile +
+ JSON format +
+ Node inheritance +
1. + Inheritance rules +
+
+ Common configuration options +
+ Macros +
+ Hash tables +

+ +

Files

+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`Leapfile`	If present, this file tells `leap` that the directory is a provider directory. This file is usually empty, but can contain global options.
`~/.leaprc`	Evaluated the same as Leapfile, but not committed to source control.
`provider.json`	Global options related to this provider. See Provider Configuration.
`provider.ENVIRONMENT.json`	Global options for the provider that are applied to only a single environment.
`nodes/NAME.json`	The configuration file for node called NAME.
`common.json`	All nodes inherit from this file. In other words, any options that appear in `common.json` will be added as default values to each node configuration, value that can be locally overridden.
`services/SERVICE.json`	The properties in this configuration file are applied to any node that includes SERVICE in its `services` property.
`services/SERVICE.ENVIRONMENT.json`	The properties in this configuration file are applied to any node that includes SERVICE in its services and has environment equal to ENVIRONMENT.
`tags/TAG.json`	The properties in this configuration file are applied to any node that has includes TAG in its `tags` property.
`tags/TAG.ENVIRONMENT.json`	The properties in this configuration file are applied to any node that has includes TAG in its `tags` property and has `environment` property equal to ENVIRONMENT.
`secrets.json`	An automatically generated file that contains any randomly generated strings needed in order to deploy. These strings are often secret and should be protected, although any need for a random string or number that is remembered will produce another entry in this file. This file is automatically generated and refreshed each time you run `leap compile` or `leap deploy`. If an entry is no longer needed, it will get removed. If you want to change a secret, you can remove this file and have it regenerated, or remove the particular line item and just those items will be created anew.
`facts.json`	If some of your servers are running on AWS or OpenStack, you will need to discover certain properties about how networking is configured on these machines in order for a full deploy to work. In these cases, make sure to run `leap facts update` to periodically regenerate the facts.json file.
`files/*`	Various static files used by the platform (e.g. keys, certificates, webapp customization, etc). In general, only generated files and files used to customize the provider (such as images) live in the `files` directory.
`users/USER/`	A directory that stores the public keys of the sysadmin with name USER. This person will have root access to all the servers.

+ + +

Leapfile

+ +

@platform_directory_path = '../leap_platform'
+@log = '/var/log/leap.log'
+

+ +

Additionally, you can create a ~/.leaprc file that is loaded after Leapfile and is evaluated the same way.

+ +

Platform options:

+ +

@platform_directory_path (required). This must be set to the path where leap_platform lives. The path may be relative.

+ + +

Vagrant options:

+ +

@vagrant_provider. Changes the default vagrant provider (“virtualbox”). For example, @vagrant_provider = "libvirt".
@vagrant_network. Allows you to override the default network used for local nodes. It should include a netmask like @vagrant_network = '10.0.0.0/24'.
@custom_vagrant_vm_line. Insert arbitrary text into the auto-generated Vagrantfile. For example, @custom_vagrant_vm_line = "config.vm.boot_mode = :gui".
@vagrant_basebox allows specifying a different basebox as the default one. For example, @vagrant_basebox = "LEAP/jessie".

+ + +

Logging options:

+ +

@log. If set, all command invocation and results are logged to the specified file. This is the same as the switch --log FILE, except that the command line switch will override the value in the Leapfile.

+ + +

JSON format

+ +

All configuration files, other than Leapfile, are in the JSON format. For example:

+ +

{
+  "key1": "value1",
+  "key2": "value2"
+}
+

+ +

Keys should match /[a-z0-9_]/ and must be in double quotes.

+ +

Unlike traditional JSON, comments are allowed. If the first non-whitespace characters are // then the line is treated as a comment.

+ +

// this is a comment
+{
+  // this is a comment
+  "key": "value"  // this is an error
+}
+

+ +

Options in the configuration files might be nested hashes, arrays, numbers, strings, or boolean. Numbers and boolean values should not be quoted. For example:

+ +

{
+  "openvpn": {
+    "ip_address": "1.1.1.1",
+    "protocols": ["tcp", "udp"],
+    "ports": [80, 53],
+    "options": {
+      "public_ip": false,
+      "adblock": true
+    }
+  }
+}
+

+ +

If the value string is prefixed with an ‘=’ character, the result is evaluated as ruby. For example:

+ +

{
+  "domain": {
+    "public": "domain.org"
+  }
+  "api_domain": "= 'api.' + domain.public"
+}
+

+ +

See “Macros” below for information on the special macros available to the evaluated ruby.

+ +

Node inheritance

+ +

Suppose you have a node configuration for bitmask/nodes/willamette.json like so:

+ +

{
+   "services": "webapp",
+   "tags": ["production", "northwest-us"],
+   "ip_address": "1.1.1.1"
+}
+

+ +

This node will have hostname “willamette” and it will inherit from the following files (in this order):

+ +

common.json + +
- load defaults: provider_base/common.json
- load provider: bitmask/common.json
+
service “webapp” + +
- load defaults: provider_base/services/webapp.json
- load provider: bitmask/services/webapp.json
+
tag “production” + +
- load defaults: provider_base/tags/production.json
- load provider: bitmask/tags/production.json
+
tag “northwest-us” + +
- load: bitmask/tags/northwest-us.json
+
finally, load node “willamette” + +
- load: bitmask/nodes/willamette.json
+

+ + +

The provider_base directory is under the leap_platform specified in the file Leapfile.

+ +

To see all the variables a node has inherited, you could run leap inspect willamette.

+ +

Inheritance rules

+ +

Suppose you have a node configuration mynode.json:

+ +

{
+  "tags": "production",
+  "simple_value": 100,
+  "replaced_array": ["dolphin", "kangaroo"],
+  "+add_array": ["red", "black"],
+  "-subtract_array": ["bitter"],
+  "converted_to_array": "not_array_element",
+  "!override": ["insist on this value"],
+  "hash": {
+    "key1": 1,
+    "key2": 2
+  }
+}
+

+ +

And a file tags/production.json:

+ +

{
+  "simple_value": 99999,
+  "replaced_array": ["zebra"],
+  "add_array": ["green],
+  "subtract_array": ["bitter", "sweet", "salty"],
+  "converted_to_array": ["array_element"],
+  "override": "this value will be overridden",
+  "hash": {
+    "key1": "one"
+  }
+}
+

+ +

In this scenario, mynode.json will inherit from production.json. The output of this inheritance will be:

+ +

{
+  "tags": "production",
+  "simple_value": 100,
+  "replaced_array": ["dolphin", "kangaroo"],
+  "add_array": ["red", "black", "green"],
+  "subtract_array": ["sweet", "salty"],
+  "converted_to_array": ["not_array_element", "array_element"],
+  "override": ["insist on this value"],
+  "hash": {
+    "key1": 1,
+    "key2": 2
+  }
+

+ +

The rules for inheritance (where ‘old’ refers to the parent, and ‘new’ refers to the child):

+ +

Simple values (strings, numbers, boolean): + +
- Replace the old value with the new value.
+
Array values: + +
- Two arrays: replace the old array with the new array.
- One array and one simple value: add the simple value to the array.
- If property name is prefixed with “+”: merge the old and new arrays.
- If property name is prefixed with “-”: subtract new array from old array.
+
Hash values: + +
- Hashes are always merged (the result includes the keys of both hashes). If there is a key in common, the new one overrides the old one.
+
Mismatch: + +
- Although you can mix arrays and simple values, you cannot mix arrays with hashes or hashes with simple values. If you attempt to do so, it will fail to compile and give you an error message.
+
Override: + +
- If property name is prefixed with “!”: then ensure that new value is always used, regardless of old value. In this case, the override takes precedence over type checking, so you will never get a type mismatch.
+

+ + +

+ +

Common configuration options

+ +

You can use the command leap inspect to see what options are available for a provider, node, service, or tag configuration. For example:

+ +

leap inspect common – show the options inherited by all nodes.
leap inspect --base common – show the common.json from provider_base without the local common.json inheritance applied.
leap inspect webapp – show all the options available for the service webapp.

+ + +

Here are some of the more important options you should be aware of:

+ +

ip_address – Required for all nodes, no default.
ssh.port – The SSH port you want the node’s OpenSSH server to bind to. This is also the default when trying to connect to a node, but if the node currently has OpenSSH running on a different port then run deploy with --port to override the ssh.port configuration value.
mosh.enabled – If set to true, then mosh will be installed on the server. The default is false.

+ + +

Macros

+ +

When using evaluated ruby in a JSON configuration file, there are several special macros that are available. These are evaluated in the context of a node (available as the variable self).

+ +

The following methods are available to the evaluated ruby:

+ +

variable.variable

+ +

Any variable defined or inherited by a particular node configuration is available by just referencing it using either hash notation or object field notation (e.g. ['domain']['public'] or domain.public). Circular references are not allowed, but otherwise it is OK to nest evaluated values in other evaluated values. If a value has not been defined, the hash notation will return nil but the field notation will raise an exception. Properties of services, tags, and the global provider can all be referenced the same way. For example, global.services['openvpn'].x509.dh.

+ +

nodes

+ +

A hash of all nodes. This list can be filtered.

+ +

nodes_like_me

+ +

A hash of nodes that have the same deployment tags as the current node (e.g. ‘production’ or ‘local’).

+ +

global.services

+ +

A hash of all services, e.g. global.services['openvpn'] would return the “openvpn” service.

+ +

global.tags

+ +

A hash of all tags, e.g. global.tags['production'] would return the “production” tag.

+ +

global.provider

+ +

Can be used to access variables defined in provider.json, e.g. global.provider.contacts.default.

+ +

file(filename)

+ +

Inserts the full contents of the file. If the file is an erb template, it is rendered. The filename can either be one of the pre-defined file symbols, or it can be a path relative to the “files” directory in your provider instance. E.g, file :ca_cert or files 'ca/ca.crt'.

+ +

file_path(filename)

+ +

Ensures that the file will get rsynced to the node as an individual file. The value returned by file_path is the full path where this file will ultimately live when deploy to the node. e.g. file_path :ca_cert or file_path 'branding/images/logo.png'.

+ +

secret(:symbol)

+ +

Returns the value of a secret in secrets.json (or creates it if necessary). E.g. secret :couch_admin_password

+ +

hosts_file

+ +

Returns a data structure that puppet will use to generate /etc/hosts. Care is taken to use the local IP of other hosts when needed.

+ +

known_hosts_file

+ +

Returns the lines needed in a SSH known_hosts file.

+ +

stunnel_client(node_list, port, options={})

+ +

Returns a stunnel configuration data structure for the client side. Argument node_list is an ObjectList of nodes running stunnel servers. Argument port is the real port of the ultimate service running on the servers that the client wants to connect to.

+ +

stunnel_server(port)

+ +

Generates a stunnel server entry. The port is the real port targeted service.

+ +

Hash tables

+ +

Access an element by name:

+ +

nodes['vpn1']                # returns node named 'vpn1'
+global.services['openvpn']   # returns service named 'openvpn'
+

+ +

Create a new hash table by applying filters:

+ +

nodes[:public_dns => true] # all nodes where public_dns == true
+nodes[:services => 'openvpn', 'location.country_code' => 'US'] # openvpn service OR in the US.
+nodes[[:services, 'openvpn'], [:services, 'tor']]  # services equal to openvpn OR tor
+nodes[:services => 'openvpn'][:tags => 'production']  # openvpn AND production
+nodes[:name => "!bob"] # all nodes that are NOT named "bob"
+

+ +

Create an array of values by selecting a single field:

+ +

nodes.field('location.name')
+==> ['seattle', 'istanbul']
+

+ +

Create an array of hashes by selecting multiple fields:

+ +

nodes.fields('domain.full', 'ip_address')
+==> [
+  {'domain_full' => 'red.bitmask.net', 'ip_address' => '1.1.1.1'},
+  {'domain_full' => 'blue.bitmask.net', 'ip_address' => '1.1.1.2'},
+]
+

+ +

Create a new hash table of hashes, with only certain fields:

+ +

nodes.pick_fields('domain.full', 'ip_address')
+==> {
+  "red" => {'domain_full' => 'red.bitmask.net', 'ip_address' => '1.1.1.1'},
+  "blue => {'domain_full' => 'blue.bitmask.net', 'ip_address' => '1.1.1.2'},
+}
+

+ +

With pick_fields, if there is only one field, it will generate a simple hash table:

+ +

nodes.pick_fields('ip_address')
+==> {
+  "red" => '1.1.1.1',
+  "blue => '1.1.1.2',
+}
+

+ +

+ + diff --git a/docs/en/guide/domains.html b/docs/en/guide/domains.html new file mode 100644 index 00000000..eb3331ff --- /dev/null +++ b/docs/en/guide/domains.html @@ -0,0 +1,298 @@ + + + + +Domains - LEAP Platform Documentation + + + + + + + + +

Domains

+ +

How to handle domain names and integrating LEAP with existing services.

+ Overview +
1. + Definitions +
+
+ Generating a zone file +
+ A single domain +
+ A separate domain for the webapp +
1. + Step 1. Configuring webapp.domain +
2. + Step 2. Putting the compiled provider.json in place +
+
+ Integrating with existing email system +
1. + Step 1. Modify LEAP webapp +
2. + Step 2. Configure MX servers +
+

+ +

Overview

+ +

Deploying LEAP can start to get very tricky when you need to integrate LEAP services with an existing domain that you already use or which already has users. Most of this complexity is unavoidable, although there are a few things we plan to do in the future to make this a little less painful.

+ +

Because integration with legacy systems is an advanced topic, we recommend that you begin with a new domain. Once everything works and you are comfortable with your LEAP-powered infrastructure, you can then contemplate integrating with your existing domain.

+ +

Definitions

+ +

provider domain

+ +

This is the main domain used to identify the provider. The provider domain is what the user enters in the Bitmask client. e.g. example.org. The full host name of every node in your provider infrastructure will use the provider domain (e.g. dbnode.example.org).

+ +

In order for the Bitmask client to get configured for use with a provider, it must be able to find the provider.json bootstrap file at the root of the provider domain. This is not needed if the Bitmask client is “pre-seeded” with the provider’s information (these providers show up in a the initial list of available providers).

+ +

webapp domain

+ +

This is the domain that runs the leap_web application that allows users to register accounts, create help tickets, etc. e.g. example.org or user.example.org. The webapp domain defaults to the provider domain unless it is explicitly configured separately.

+ +

API domain

+ +

This is the domain that the provider API runs on. Typically, this is set automatically and you never need to configure it. The user should never be aware of this domain. e.g. api.example.org. The Bitmask client discovers this API domain by reading it from the provider.json file it grabs from the provider domain.

+ +

mail domain

+ +

This is the domain used for mail accounts, e.g. username@example.org. Currently, this is always the provider domain, but it may be independently configurable in the future.

+ +

Generating a zone file

+ +

Currently, the platform does not include a dedicated dns service type, so you need to have your own setup for DNS. You can generate the appropriate configuration options with this command:

+ +

leap compile zone
+

+ +

A single domain

+ +

The easy approach is to use a single domain for provider domain, webapp domain, and email domain. This will install the webapp on the provider domain, which means that this domain must be a new one that you are not currently using for anything.

+ +

To configure a single domain, just set the domain in provider.json:

+ +

{
+  "domain": "example.org"
+}
+

+ +

If you have multiple environments, you can specify a different provider domain for each environment. For example:

+ +

provider.staging.json

+ +

{
+  "domain": "staging.example.org"
+}
+

+ +

A separate domain for the webapp

+ +

It is possible make the webapp domain different than the provider domain. This is needed if you already have a website running at your provider domain.

+ +

In order to put webapp on a different domain, you must take two steps:

+ +

You must configure webapp.domain for nodes with the webapp service.
You must make the compiled provider.json available at the root of the provider domain.

+ + +

NOTE: This compiled provider.json is different than the provider.json that you edit and lives in the root of the provider directory.

+ +

Step 1. Configuring `webapp.domain`

+ +

In services/webapp.json:

+ +

{
+  "webapp": {
+    "domain": "user.example.org"
+  }
+}
+

+ +

Step 2. Putting the compiled `provider.json` in place

+ +

Generate the compiled provider.json:

+ +

leap compile provider.json
+= created files/web/bootstrap/
+= created files/web/bootstrap/README
+= created files/web/bootstrap/production/
+= created files/web/bootstrap/production/provider.json
+= created files/web/bootstrap/production/htaccess
+= created files/web/bootstrap/staging/
+= created files/web/bootstrap/staging/provider.json
+= created files/web/bootstrap/staging/htaccess
+

+ +

This command compiles a separate provider.json for each environment, or “default” if you don’t have an environment. In the example above, there is an environment called “production” and one called “staging”, but your setup will probably differ.

+ +

The resulting provider.json file must then be put at the root URL of your provider domain for the appropriate environment.

+ +

There is one additional complication: currently, the Bitmask client tests for compatibility using some HTTP headers on the /provider.json response. This is will hopefully change in the future, but for now you need to ensure the right headers are set in the response. The included file htaccess has example directives for Apache, if that is what you use.

+ +

This step can be skipped if you happen to use the static service to deploy an amber powered static website to provider domain. In this case, the correct provider.json will be automatically put into place.

+ +

Integrating with existing email system

+ +

If your mail domain already has users from a legacy email system, then things get a bit complicated. In order to be able to support both LEAP-powered email and legacy email on the same domain, you need to follow these steps:

+ +

Modify the LEAP webapp so that it does not create users with the same name as users in the legacy system.
Configure your legacy MX servers to forward mail that they cannot handle to the LEAP MX servers, or vice versa.

+ + +

Step 1. Modify LEAP webapp

+ +

In order to modify the webapp to respect the usernames already reserved by your legacy system, you need to modify the LEAP webapp code. The easiest way to do this is to create a custom gem that modifies the behavior of the webapp.

+ +

For this example, we will call our custom gem reserve_usernames.

+ +

This gem can live in one of two places:

+ +

(1) You can fork the project leap_web and put the gem in leap_web/vendor/gems/reserve_usernames. Then, modify Gemfile and add the line gem 'common_languages', :path => 'vendor/gems/reserve_usernames'

+ +

(2) Alternately, you can put the gem in the local provider directory files/webapp/gems/reserve_username. This will get synced to the webapp servers when you deploy and put in /srv/leap/webapp/config/customization where it will get automatically loaded by the webapp.

+ +

What should the gem reserve_usernames look like? There is an example available here: https://leap.se/git/reserved_usernames.git

+ +

This example gem uses ActiveResource to communicate with a remote REST API for creating and checking username reservations. This ensures that both the legacy system and the LEAP system use the same namespace. Alternately, you could write a gem that checks the legacy database directly.

+ +

Step 2. Configure MX servers

+ +

To be written.

+ +

+ + diff --git a/docs/en/guide/domains/index.html b/docs/en/guide/domains/index.html new file mode 100644 index 00000000..9ebf3b2c --- /dev/null +++ b/docs/en/guide/domains/index.html @@ -0,0 +1,298 @@ + + + + +Domains - LEAP Platform Documentation + + + + + + + + +

Domains

+ +

How to handle domain names and integrating LEAP with existing services.

+ Overview +
1. + Definitions +
+
+ Generating a zone file +
+ A single domain +
+ A separate domain for the webapp +
1. + Step 1. Configuring webapp.domain +
2. + Step 2. Putting the compiled provider.json in place +
+
+ Integrating with existing email system +
1. + Step 1. Modify LEAP webapp +
2. + Step 2. Configure MX servers +
+

+ +

Overview

+ +

Definitions

+ +

provider domain

+ +

webapp domain

+ +

API domain

+ +

mail domain

+ +

This is the domain used for mail accounts, e.g. username@example.org. Currently, this is always the provider domain, but it may be independently configurable in the future.

+ +

Generating a zone file

+ +

Currently, the platform does not include a dedicated dns service type, so you need to have your own setup for DNS. You can generate the appropriate configuration options with this command:

+ +

leap compile zone
+

+ +

A single domain

+ +

To configure a single domain, just set the domain in provider.json:

+ +

{
+  "domain": "example.org"
+}
+

+ +

If you have multiple environments, you can specify a different provider domain for each environment. For example:

+ +

provider.staging.json

+ +

{
+  "domain": "staging.example.org"
+}
+

+ +

A separate domain for the webapp

+ +

It is possible make the webapp domain different than the provider domain. This is needed if you already have a website running at your provider domain.

+ +

In order to put webapp on a different domain, you must take two steps:

+ +

You must configure webapp.domain for nodes with the webapp service.
You must make the compiled provider.json available at the root of the provider domain.

+ + +

NOTE: This compiled provider.json is different than the provider.json that you edit and lives in the root of the provider directory.

+ +

Step 1. Configuring `webapp.domain`

+ +

In services/webapp.json:

+ +

{
+  "webapp": {
+    "domain": "user.example.org"
+  }
+}
+

+ +

Step 2. Putting the compiled `provider.json` in place

+ +

Generate the compiled provider.json:

+ +

leap compile provider.json
+= created files/web/bootstrap/
+= created files/web/bootstrap/README
+= created files/web/bootstrap/production/
+= created files/web/bootstrap/production/provider.json
+= created files/web/bootstrap/production/htaccess
+= created files/web/bootstrap/staging/
+= created files/web/bootstrap/staging/provider.json
+= created files/web/bootstrap/staging/htaccess
+

+ +

The resulting provider.json file must then be put at the root URL of your provider domain for the appropriate environment.

+ +

Integrating with existing email system

+ +

Modify the LEAP webapp so that it does not create users with the same name as users in the legacy system.
Configure your legacy MX servers to forward mail that they cannot handle to the LEAP MX servers, or vice versa.

+ + +

Step 1. Modify LEAP webapp

+ +

For this example, we will call our custom gem reserve_usernames.

+ +

This gem can live in one of two places:

+ +

What should the gem reserve_usernames look like? There is an example available here: https://leap.se/git/reserved_usernames.git

+ +

Step 2. Configure MX servers

+ +

To be written.

+ +

+ + diff --git a/docs/en/guide/environments.html b/docs/en/guide/environments.html new file mode 100644 index 00000000..db82302d --- /dev/null +++ b/docs/en/guide/environments.html @@ -0,0 +1,228 @@ + + + + +Environments - LEAP Platform Documentation + + + + + + + + +

Working with environments

+ +

How to partition the nodes into separate environments.

+ Assign an environment +
+ Environment commands +
+ Environment specific JSON files +
+ Bind an environment to a Platform version +

+ +

With environments, you can divide your nodes into different and entirely separate sets. For example, you might have sets of nodes for ‘testing’, ‘staging’ and ‘production’.

+ +

Typically, the nodes in one environment are totally isolated from the nodes in a different environment. Each environment will have its own separate database, for example.

+ +

There are a few exceptions to this rule: backup nodes, for example, will by default attempt to back up data from all the environments (excluding local).

+ +

Assign an environment

+ +

To assign an environment to a node, you just set the environment node property. This is typically done with tags, although it is not necessary. For example:

+ +

tags/production.json

+ +

{
+  "environment": "production"
+}
+

+ +

nodes/mynode.json

+ +

{
+  "tags": ["production"]
+}
+

+ +

There are several built-in tags that will apply a value for the environment:

+ +

production: An environment for nodes that are in use by end users.
development: An environment to be used for nodes that are being used for experiments or staging.
local: This environment gets automatically applied to all nodes that run only on local VMs. Nodes with a local environment are treated special and excluded from certain calculations.

+ + +

You don’t need to use these and you can add your own.

+ +

Environment commands

+ +

leap env – List the available environments and disply which one is active.
leap env pin ENV – Pin the current environment to ENV.
leap env unpin – Remove the environment pin.

+ + +

The environment pin is only active for your local machine: it is not recorded in the provider directory and not shared with other users.

+ +

Environment specific JSON files

+ +

You can add JSON configuration files that are only applied when a specific environment is active. For example, if you create a file provider.production.json, these values will only get applied to the provider.json file for the production environment.

+ +

This will also work for services and tags. For example:

+ +

provider.local.json
+services/webapp.development.json
+tags/seattle.production.json
+

+ +

In this example, local, development, and production are the names of environments.

+ +

Bind an environment to a Platform version

+ +

If you want to ensure that a particular environment is bound to a particular version of the LEAP Platform, you can add a platform section to the provider.ENV.json file (where ENV is the name of the environment in question).

+ +

The available options are platform.version, platform.branch, or platform.commit. For example:

+ +

{
+  "platform": {
+    "version": "1.6.1",
+    "branch": "develop",
+    "commit": "5df867fbd3a78ca4160eb54d708d55a7d047bdb2"
+  }
+}
+

+ +

You can use any combination of version, branch, and commit to specify the binding. The values for branch and commit only work if the leap_platform directory is a git repository.

+ +

The value for commit is passed directly through to git log to query for a list of acceptable commits. See man gitrevisions to see how to specify ranges. For example:

+ +

HEAD^..HEAD - current commit must be head of the branch.
3172444652af71bd771609d6b80258e70cc82ce9..HEAD - current commit must be after 3172444652af71bd771609d6b80258e70cc82ce9.
refs/tags/0.6.0rc1..refs/tags/0.6.0rc2 - current commit must be after tag 0.6.0rc1 and before or including tag 0.6.0rc2.

+ + +

+ + diff --git a/docs/en/guide/environments/index.html b/docs/en/guide/environments/index.html new file mode 100644 index 00000000..faeb6c6c --- /dev/null +++ b/docs/en/guide/environments/index.html @@ -0,0 +1,228 @@ + + + + +Environments - LEAP Platform Documentation + + + + + + + + +

Working with environments

+ +

How to partition the nodes into separate environments.

+ Assign an environment +
+ Environment commands +
+ Environment specific JSON files +
+ Bind an environment to a Platform version +

+ +

With environments, you can divide your nodes into different and entirely separate sets. For example, you might have sets of nodes for ‘testing’, ‘staging’ and ‘production’.

+ +

Typically, the nodes in one environment are totally isolated from the nodes in a different environment. Each environment will have its own separate database, for example.

+ +

There are a few exceptions to this rule: backup nodes, for example, will by default attempt to back up data from all the environments (excluding local).

+ +

Assign an environment

+ +

To assign an environment to a node, you just set the environment node property. This is typically done with tags, although it is not necessary. For example:

+ +

tags/production.json

+ +

{
+  "environment": "production"
+}
+

+ +

nodes/mynode.json

+ +

{
+  "tags": ["production"]
+}
+

+ +

There are several built-in tags that will apply a value for the environment:

+ +

production: An environment for nodes that are in use by end users.
development: An environment to be used for nodes that are being used for experiments or staging.
local: This environment gets automatically applied to all nodes that run only on local VMs. Nodes with a local environment are treated special and excluded from certain calculations.

+ + +

You don’t need to use these and you can add your own.

+ +

Environment commands

+ +

leap env – List the available environments and disply which one is active.
leap env pin ENV – Pin the current environment to ENV.
leap env unpin – Remove the environment pin.

+ + +

The environment pin is only active for your local machine: it is not recorded in the provider directory and not shared with other users.

+ +

Environment specific JSON files

+ +

This will also work for services and tags. For example:

+ +

provider.local.json
+services/webapp.development.json
+tags/seattle.production.json
+

+ +

In this example, local, development, and production are the names of environments.

+ +

Bind an environment to a Platform version

+ +

The available options are platform.version, platform.branch, or platform.commit. For example:

+ +

{
+  "platform": {
+    "version": "1.6.1",
+    "branch": "develop",
+    "commit": "5df867fbd3a78ca4160eb54d708d55a7d047bdb2"
+  }
+}
+

+ +

You can use any combination of version, branch, and commit to specify the binding. The values for branch and commit only work if the leap_platform directory is a git repository.

+ +

The value for commit is passed directly through to git log to query for a list of acceptable commits. See man gitrevisions to see how to specify ranges. For example:

+ +

HEAD^..HEAD - current commit must be head of the branch.
3172444652af71bd771609d6b80258e70cc82ce9..HEAD - current commit must be after 3172444652af71bd771609d6b80258e70cc82ce9.
refs/tags/0.6.0rc1..refs/tags/0.6.0rc2 - current commit must be after tag 0.6.0rc1 and before or including tag 0.6.0rc2.

+ + +

+ + diff --git a/docs/en/guide/getting-started.html b/docs/en/guide/getting-started.html new file mode 100644 index 00000000..b1274e14 --- /dev/null +++ b/docs/en/guide/getting-started.html @@ -0,0 +1,317 @@ + + + + +Getting Started - LEAP Platform Documentation + + + + + + + + +

Getting Started

+ +

An overview of the LEAP Platform

+ Sensitive files +
+ Useful commands +
+ Node filters +
+ Tracking the provider directory in git +
+ Editing JSON configuration files +
+ How does it work under the hood? +

+ +

Sensitive files

+ +

Some files in your provider directory are very sensitive. Leaking these files will compromise your provider.

+ +

Super sensitive and irreplaceable:

+ +

files/ca/*.key – the private keys for the client and server CAs.
files/cert/*.key – the private key(s) for the commercial certificate for your domain(s).

+ + +

Sensitive, but can be erased and regenerated automatically:

+ +

secrets.json – various random secrets, such as passwords for databases.
files/nodes/*/*.key – the private key for each node.
hiera/*.yaml – hiera file contains a copy of the private key of the node.

+ + +

Also, each sysadmin has one or more public ssh keys in users/*/*_ssh.pub. Typically, you will want to keep these public keys secure as well.

+ +

See Keys and Certificates for more information.

+ +

Useful commands

+ +

Here are a few useful leap commands:

+ +

leap help [COMMAND] – get help on COMMAND.
leap history [FILTER] – show the recent deployment history for the selected nodes.
leap ssh web1 – SSH into node web1 (requires leap node init web1 first).
leap list [FILTER] – list the selected nodes. + +
- leap list production – list only those nodes with the tag ‘production’
- leap list --print ip_address – list a particular attribute of all nodes.
+

+ + +

See the full Command Line Reference for more information.

+ +

Node filters

+ +

Many of the leap commands take a “node filter”. You can use a node filter to target a command at one or more nodes.

+ +

A node filter consists of one or more keywords, with an optional “+” before each keyword.

+ +

keywords can be a node name, a service type, or a tag.
the “+” before the keyword constructs an AND condition
otherwise, multiple keywords together construct an OR condition

+ + +

Examples:

+ +

leap list openvpn – list all nodes with service openvpn.
leap list openvpn +production – only nodes of service type openvpn AND tag production.
leap deploy webapp openvpn – deploy to all webapp OR openvpn nodes.
leap node init ostrich – just init the node named ostrich.

+ + +

See the full Command Line Reference for more information.

+ +

Tracking the provider directory in git

+ +

You should commit your provider changes to your favorite VCS whenever things change. This way you can share your configurations with other admins, all they have to do is to pull the changes to stay up to date. Every time you make a change to your provider, such as adding nodes, services, generating certificates, etc. you should add those to your VCS, commit them and push them to where your repository is hosted.

+ +

Note that your provider directory contains secrets, such as private key material and passwords. You do not want to have those passwords readable by the world, so make sure that wherever you are hosting your repository, it is not public for the world to read.

+ +

If you have a post-commit hook that emails the changes to contributors, you may want to exclude diffs for files that might have sensitive secrets. For example, create a .gitattributes file with:

+ +

# No diff, no email for key files
+*.key -diff
+*.pem -diff
+
+# Discard diff for secrets.json
+secrets.json -diff
+
+# No diff for hiera files, they contain passwords
+hiera/* -diff
+

+ +

Editing JSON configuration files

+ +

All the settings that compose your provider are stored in JSON files.

+ +

At a minimum, you will need at least two configuration files:

+ +

provider.json – general settings for you provider.
nodes/NAME.json – configuration file for node called “NAME”.

+ + +

There are a few required properties in provider.json:

+ +

{
+  "domain": "example.org",
+  "name": "Example",
+  "contacts": {
+    "default": "email1@example.org"
+  }
+}
+

+ +

See Provider Configuration for more details.

+ +

For node configuration files, there are two required properties:

+ +

{
+  "ip_address": "1.1.1.1",
+  "services": ["openvpn"]
+}
+

+ +

See Services for details on what servers are available, and see Configuration Files details on how configuration files work.

+ +

How does it work under the hood?

+ +

You don’t need to know any of the details of what happens “under the hood” in order to use the LEAP platform. However, if you are curious as to what is going on, here is a quick primer.

+ +

First, some background terminology:

+ +

puppet: Puppet is a system for automating deployment and management of servers (called nodes).
hiera files: In puppet, you can use something called a ‘hiera file’ to seed a node with a few configuration values. In LEAP, we go all out and put every configuration value needed for a node in the hiera file, and automatically compile a custom hiera file for each node.

+ + +

When you run leap deploy, a bunch of things happen, in this order:

+ +

Compile hiera files: The hiera configuration file for each node is compiled in YAML format and saved in the directory hiera. The source material for this hiera file consists of all the JSON configuration files imported or inherited by the node’s JSON config file.
Copy required files to node: All the files needed for puppet to run are rsync'ed to each node. This includes the entire leap_platform directory, as well as the node’s hiera file and other files needed by puppet to set up the node (keys, binary files, etc).
Puppet is run: Once the node is ready, leap connects to the node via ssh and runs puppet apply. Puppet is applied locally on the node, without a daemon or puppetmaster.

+ + +

You can run leap -v2 deploy to see exactly what commands are being executed.

+ +

This mode of operation is fundamentally different from how puppet is normally used:

+ +

There is no puppetmaster that all the servers take orders from, and there is no puppetd running in the background.
Servers cannot dynamically query the puppetmaster for information about the other servers.
There is a static representation for the state of every server that can be committed to git.

+ + +

There are advantages and disadvantages to the model that LEAP uses. We have found it very useful for our goal of having a common LEAP platform that many different providers can all use while still allowing providers to configure their unique infrastructure.

+ +

We also find it very beneficial to be able to track the state of your infrastructure in git.

+ +

Traditional system configuration automation systems, like Puppet or Chef, deploy changes to servers using a pull method. Each server pulls a manifest from a central master server and uses this to alter the state of the server.

+ +

Instead, the leap tool uses a masterless push method: The sysadmin runs leap deploy from the provider instance directory on their desktop machine to push the changes out to every server (or a subset of servers). LEAP still uses Puppet, but there is no central master server that each node must pull from.

+ +

One other significant difference between LEAP and typical system automation is how interactions among servers are handled. Rather than store a central database of information about each server that can be queried when a recipe is applied, the leap command compiles static representation of all the information a particular server will need in order to apply the recipes. In compiling this static representation, leap can use arbitrary programming logic to query and manipulate information about other servers.

+ +

These two approaches, masterless push and pre-compiled static configuration, allow the sysadmin to manage a set of LEAP servers using traditional software development techniques of branching and merging, to more easily create local testing environments using virtual servers, and to deploy without the added complexity and failure potential of a master server.

+ +

+ + diff --git a/docs/en/guide/getting-started/index.html b/docs/en/guide/getting-started/index.html new file mode 100644 index 00000000..c9457ddd --- /dev/null +++ b/docs/en/guide/getting-started/index.html @@ -0,0 +1,317 @@ + + + + +Getting Started - LEAP Platform Documentation + + + + + + + + +

Getting Started

+ +

An overview of the LEAP Platform

+ Sensitive files +
+ Useful commands +
+ Node filters +
+ Tracking the provider directory in git +
+ Editing JSON configuration files +
+ How does it work under the hood? +

+ +

Sensitive files

+ +

Some files in your provider directory are very sensitive. Leaking these files will compromise your provider.

+ +

Super sensitive and irreplaceable:

+ +

files/ca/*.key – the private keys for the client and server CAs.
files/cert/*.key – the private key(s) for the commercial certificate for your domain(s).

+ + +

Sensitive, but can be erased and regenerated automatically:

+ +

secrets.json – various random secrets, such as passwords for databases.
files/nodes/*/*.key – the private key for each node.
hiera/*.yaml – hiera file contains a copy of the private key of the node.

+ + +

Also, each sysadmin has one or more public ssh keys in users/*/*_ssh.pub. Typically, you will want to keep these public keys secure as well.

+ +

See Keys and Certificates for more information.

+ +

Useful commands

+ +

Here are a few useful leap commands:

+ +

leap help [COMMAND] – get help on COMMAND.
leap history [FILTER] – show the recent deployment history for the selected nodes.
leap ssh web1 – SSH into node web1 (requires leap node init web1 first).
leap list [FILTER] – list the selected nodes. + +
- leap list production – list only those nodes with the tag ‘production’
- leap list --print ip_address – list a particular attribute of all nodes.
+

+ + +

See the full Command Line Reference for more information.

+ +

Node filters

+ +

Many of the leap commands take a “node filter”. You can use a node filter to target a command at one or more nodes.

+ +

A node filter consists of one or more keywords, with an optional “+” before each keyword.

+ +

keywords can be a node name, a service type, or a tag.
the “+” before the keyword constructs an AND condition
otherwise, multiple keywords together construct an OR condition

+ + +

Examples:

+ +

leap list openvpn – list all nodes with service openvpn.
leap list openvpn +production – only nodes of service type openvpn AND tag production.
leap deploy webapp openvpn – deploy to all webapp OR openvpn nodes.
leap node init ostrich – just init the node named ostrich.

+ + +

See the full Command Line Reference for more information.

+ +

Tracking the provider directory in git

+ +

If you have a post-commit hook that emails the changes to contributors, you may want to exclude diffs for files that might have sensitive secrets. For example, create a .gitattributes file with:

+ +

# No diff, no email for key files
+*.key -diff
+*.pem -diff
+
+# Discard diff for secrets.json
+secrets.json -diff
+
+# No diff for hiera files, they contain passwords
+hiera/* -diff
+

+ +

Editing JSON configuration files

+ +

All the settings that compose your provider are stored in JSON files.

+ +

At a minimum, you will need at least two configuration files:

+ +

provider.json – general settings for you provider.
nodes/NAME.json – configuration file for node called “NAME”.

+ + +

There are a few required properties in provider.json:

+ +

{
+  "domain": "example.org",
+  "name": "Example",
+  "contacts": {
+    "default": "email1@example.org"
+  }
+}
+

+ +

See Provider Configuration for more details.

+ +

For node configuration files, there are two required properties:

+ +

{
+  "ip_address": "1.1.1.1",
+  "services": ["openvpn"]
+}
+

+ +

See Services for details on what servers are available, and see Configuration Files details on how configuration files work.

+ +

How does it work under the hood?

+ +

You don’t need to know any of the details of what happens “under the hood” in order to use the LEAP platform. However, if you are curious as to what is going on, here is a quick primer.

+ +

First, some background terminology:

+ +

puppet: Puppet is a system for automating deployment and management of servers (called nodes).
hiera files: In puppet, you can use something called a ‘hiera file’ to seed a node with a few configuration values. In LEAP, we go all out and put every configuration value needed for a node in the hiera file, and automatically compile a custom hiera file for each node.

+ + +

When you run leap deploy, a bunch of things happen, in this order:

+ +

Compile hiera files: The hiera configuration file for each node is compiled in YAML format and saved in the directory hiera. The source material for this hiera file consists of all the JSON configuration files imported or inherited by the node’s JSON config file.
Copy required files to node: All the files needed for puppet to run are rsync'ed to each node. This includes the entire leap_platform directory, as well as the node’s hiera file and other files needed by puppet to set up the node (keys, binary files, etc).
Puppet is run: Once the node is ready, leap connects to the node via ssh and runs puppet apply. Puppet is applied locally on the node, without a daemon or puppetmaster.

+ + +

You can run leap -v2 deploy to see exactly what commands are being executed.

+ +

This mode of operation is fundamentally different from how puppet is normally used:

+ +

There is no puppetmaster that all the servers take orders from, and there is no puppetd running in the background.
Servers cannot dynamically query the puppetmaster for information about the other servers.
There is a static representation for the state of every server that can be committed to git.

+ + +

+ +

We also find it very beneficial to be able to track the state of your infrastructure in git.

+ +

+ + diff --git a/docs/en/guide/keys-and-certificates.html b/docs/en/guide/keys-and-certificates.html new file mode 100644 index 00000000..ee7d2699 --- /dev/null +++ b/docs/en/guide/keys-and-certificates.html @@ -0,0 +1,480 @@ + + + + +Keys and Certificates - LEAP Platform Documentation + + + + + + + + +

Keys and Certificates

+ +

Working with SSH keys, secrets, and X.509 certificates.

+ Working with SSH +
1. + SSH related files +
2. + SSH and local nodes +
3. + To upgrade a SSH host key +
4. + When SSH host key changes +
5. + Changing the SSH port +
6. + Sysadmins with multiple SSH keys +
7. + Removing sysadmin access +
+
+ X.509 Certificates +
1. + Configuration options +
2. + Certificate Authorities +
3. + Server certificates +
4. + Client certificates +
5. + Commercial certificates +
6. + Examine Certs +
+
+ Let’s Encrypt certificate +
1. + Install the official acme client +
2. + Fetch cert +
3. + Deploy the certs +
+

+ +

Working with SSH

+ +

Whenever the leap command needs to push changes to a node or gather information from a node, it tunnels this command over SSH. Another way to put this: the security of your servers rests entirely on SSH. Because of this, it is important that you understand how leap uses SSH.

+ +

SSH related files

+ +

Assuming your provider directory is called ‘provider’:

+ +

provider/nodes/crow/crow_ssh.pub – The public SSH host key for node ‘crow’.
provider/users/alice/alice_ssh.pub – The public SSH user key for user ‘alice’. Anyone with the private key that corresponds to this public key will have root access to all nodes.
provider/files/ssh/known_hosts – An autogenerated known_hosts, built from combining provider/nodes/*/*_ssh.pub. You must not edit this file directly. If you need to change it, remove or change one of the files that is used to generate known_hosts and then run leap compile.
provider/files/ssh/authorized_keys – An autogenerated list of all the user SSH keys with root access to the notes. It is created from provider/users/*/*_ssh.pub. You must not edit this file directly. If you need to change it, remove or change one of the files that is used to generate authorized_keys and then run leap compile.

+ + +

All of these files should be committed to source control.

+ +

If you rename, remove, or add a node with leap node [mv|add|rm] the SSH key files and the known_hosts file will get properly updated.

+ +

SSH and local nodes

+ +

Local nodes are run as Vagrant virtual machines. The leap command handles SSH slightly differently for these nodes.

+ +

Basically, all the SSH security is turned off for local nodes. Since local nodes only exist for a short time on your computer and can’t be reached from the internet, this is not a problem.

+ +

Specifically, for local nodes:

+ +

known_hosts is never updated with local node keys, since the SSH public key of a local node is different for each user.
leap entirely skips the checking of host keys when connecting with a local node.
leap adds the public Vagrant SSH key to the list of SSH keys for a user. The public Vagrant SSH key is a shared and insecure key that has root access to most Vagrant virtual machines.

+ + +

To upgrade a SSH host key

+ +

Most servers will have more than one SSH host key. Sometimes, the server will have a better SSH host key than the one you have on file. In order to upgrade to the better SSH host key, simply re-run the init command:

+ +

workstation$ leap node init NODE_NAME
+

+ +

This will prompt you if you want to upgrade the SSH host key, but only if leap thinks that an upgrade is advisable.

+ +

When SSH host key changes

+ +

If the host key for a node has changed, you will get an error “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”.

+ +

To fix this, you need to remove the file files/nodes/stompy/stompy_ssh.pub and run leap node init stompy, where the node’s name is ‘stompy’. Only do this if you are ABSOLUTELY CERTAIN that the node’s SSH host key has changed.

+ +

Changing the SSH port

+ +

Suppose you have a node blinky that has SSH listening on port 22 and you want to make it port 2200.

+ +

First, modify the configuration for blinky to specify the variable ssh.port as 2200. Usually, this is done in common.json or in a tag file.

+ +

For example, you could put this in tags/production.json:

+ +

{
+  "ssh": {
+    "port": 2200
+  }
+}
+

+ +

Run leap compile and open hiera/blinky.yaml to confirm that ssh.port is set to 2200. The port number must be specified as a number, not a string (no quotes).

+ +

Then, you need to deploy this change so that SSH will bind to 2200. You cannot simply run leap deploy blinky because this command will default to using the variable ssh.port which is now 2200 but SSH on the node is still bound to 22.

+ +

So, you manually override the port in the deploy command, using the old port:

+ +

leap deploy --port 22 blinky
+

+ +

Afterwards, SSH on blinky should be listening on port 2200 and you can just run leap deploy blinky from then on.

+ +

Sysadmins with multiple SSH keys

+ +

The command leap add-user --self allows only one SSH key. If you want to specify more than one key for a user, you can do it manually:

+ +

users/userx/userx_ssh.pub
+users/userx/otherkey_ssh.pub
+

+ +

All keys matching ‘userx/*_ssh.pub’ will be usable.

+ +

Removing sysadmin access

+ +

Suppose you want to remove userx from having any further SSH access to the servers. Do this:

+ +

rm -r users/userx
+leap deploy
+

+ +

X.509 Certificates

+ +

Configuration options

+ +

The ca option in provider.json provides settings used when generating CAs and certificates. The defaults are as follows:

+ +

{
+  "ca": {
+    "name": "= global.provider.ca.organization + ' Root CA'",
+    "organization": "= global.provider.name[global.provider.default_language]",
+    "organizational_unit": "= 'https://' + global.provider.domain",
+    "bit_size": 4096,
+    "digest": "SHA256",
+    "life_span": "10y",
+    "server_certificates": {
+      "bit_size": 2048,
+      "digest": "SHA256",
+      "life_span": "1y"
+    },
+    "client_certificates": {
+      "bit_size": 2048,
+      "digest": "SHA256",
+      "life_span": "2m",
+      "limited_prefix": "LIMITED",
+      "unlimited_prefix": "UNLIMITED"
+    }
+  }
+}
+

+ +

You should not need to override these defaults in your own provider.json, but you can if you want to. To see what values are used for your provider, run leap inspect provider.json.

+ +

NOTE: A certificate bit_size greater than 2048 will probably not be recognized by most commercial CAs.

+ +

Certificate Authorities

+ +

There are three x.509 certificate authorities (CA) associated with your provider:

+ +

Commercial CA: It is strongly recommended that you purchase a commercial cert for your primary domain. The goal of platform is to not depend on the commercial CA system, but it does increase security and usability if you purchase a certificate. The cert for the commercial CA must live at files/cert/commercial_ca.crt.
Server CA: This is a self-signed CA responsible for signing all the server certificates. The private key lives at files/ca/ca.key and the public cert lives at files/ca/ca.crt. The key is very sensitive information and must be kept private. The public cert is distributed publicly.
Client CA: This is a self-signed CA responsible for signing all the client certificates. The private key lives at files/ca/client_ca.key and the public cert lives at files/ca/client_ca.crt. Neither file is distribute publicly. It is not a big deal if the private key for the client CA is compromised, you can just generate a new one and re-deploy.

+ + +

To generate both the Server CA and the Client CA, run the command:

+ +

leap cert ca
+

+ +

Server certificates

+ +

Most every server in your service provider will have a x.509 certificate, generated by the leap command using the Server CA. Whenever you modify any settings of a node that might affect it’s certificate (like changing the IP address, hostname, or settings in provider.json), you can magically regenerate all the certs that need to be regenerated with this command:

+ +

leap cert update
+

+ +

Run leap help cert update for notes on usage options.

+ +

Because the server certificates are generated locally on your personal machine, the private key for the Server CA need never be put on any server. It is up to you to keep this file secure.

+ +

Client certificates

+ +

Every leap client gets its own time-limited client certificate. This cert is use to connect to the OpenVPN gateway (and probably other things in the future). It is generated on the fly by the webapp using the Client CA.

+ +

To make this work, the private key of the Client CA is made available to the webapp. This might seem bad, but compromise of the Client CA simply allows the attacker to use the OpenVPN gateways without paying. In the future, we plan to add a command to automatically regenerate the Client CA periodically.

+ +

There are two types of client certificates: limited and unlimited. A client using a limited cert will have its bandwidth limited to the rate specified by provider.service.bandwidth_limit (in Bytes per second). An unlimited cert is given to the user if they authenticate and the user’s service level matches one configured in provider.service.levels without bandwidth limits. Otherwise, the user is given a limited client cert.

+ +

Commercial certificates

+ +

We strongly recommend that you use a commercial signed server certificate for your primary domain (in other words, a certificate with a common name matching whatever you have configured for provider.domain). This provides several benefits:

+ +

When users visit your website, they don’t get a scary notice that something is wrong.
When a user runs the LEAP client, selecting your service provider will not cause a warning message.
When other providers first discover your provider, they are more likely to trust your provider key if it is fetched over a commercially verified link.

+ + +

The LEAP platform is designed so that it assumes you are using a commercial cert for the primary domain of your provider, but all other servers are assumed to use non-commercial certs signed by the Server CA you create.

+ +

To generate a CSR, run:

+ +

leap cert csr
+

+ +

This command will generate the CSR and private key matching provider.domain (you can change the domain with --domain=DOMAIN switch). It also generates a server certificate signed with the Server CA. You should delete this certificate and replace it with a real one once it is created by your commercial CA.

+ +

The related commercial cert files are:

+ +

files/
+  cert/
+    domain.org.crt    # Server certificate for domain.org, obtained by commercial CA.
+    domain.org.csr    # Certificate signing request
+    domain.org.key    # Private key for you certificate
+    commercial_ca.crt # The CA cert obtained from the commercial CA.
+

+ +

The private key file is extremely sensitive and care should be taken with its provenance.

+ +

If your commercial CA has a chained CA cert, you should be OK if you just put the last cert in the chain into the commercial_ca.crt file. This only works if the other CAs in the chain have certs in the debian package ca-certificates, which is the case for almost all CAs.

+ +

If you want to add additional fields to the CSR, like country, city, or locality, you can configure these values in provider.json like so:

+ +

  "ca": {
+    "server_certificates": {
+      "country": "US",
+      "state": "Washington",
+      "locality": "Seattle"
+    }
+  }
+

+ +

If they are not present, the CSR will be created without them.

+ +

Examine Certs

+ +

To see details about the keys and certs you can use leap inspect like so:

+ +

$ leap inspect files/ca/ca.crt
+

+ +

Let’s Encrypt certificate

+ +

LEAP plans to integrate Let’s Encrypt support, so it will be even easier to receive X.509 certificates that are accepted by all browsers. +Until we achieve this, here’s a guide how to do this manually.

+ +

Install the official acme client

+ +

server$ git clone https://github.com/certbot/certbot
+server$ cd certbot
+server$ ./certbot-auto --help
+

+ +

Fetch cert

+ +

Stop apache so the letsencrypt client can bind to port 80:

+ +

server$ systemctl stop apache2
+

+ +

Fetch the certs

+ +

server$ ./certbot-auto certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d)
+

+ +

This will put the certs and keys into /etc/letsencrypt/live/DOMAIN/.

+ +

Now, go to your workstation’s provider configuration directory and copy the newly created files from the server to your local config. You will override existing files so please make a backup before proceeding, or use a version control system to track changes.

+ +

workstation$ cd PATH_TO_PROVIDER_CONFIG
+

+ +

Copy the Certificate

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/cert.pem files/cert/dev.pixelated-project.org.crt
+

+ +

Copy the private key

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/privkey.pem files/cert/DOMAIN.key
+

+ +

Copy the CA chain cert

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/fullchain.pem files/cert/commercial_ca.crt
+

+ +

Deploy the certs

+ +

Now you only need to deploy the certs

+ +

workstation$ leap deploy
+

+ +

This will put them into the right locations which are:

+ +

/etc/x509/certs/leap_commercial.crt for the certificate
/etc/x509/./keys/leap_commercial.key for the private key
/usr/local/share/ca-certificates/leap_commercial_ca.crt for the CA chain cert.

+ + +

Start apache2 again

+ +

server$ systemctl start apache2
+

+ +

+ + diff --git a/docs/en/guide/keys-and-certificates/index.html b/docs/en/guide/keys-and-certificates/index.html new file mode 100644 index 00000000..4775de5a --- /dev/null +++ b/docs/en/guide/keys-and-certificates/index.html @@ -0,0 +1,480 @@ + + + + +Keys and Certificates - LEAP Platform Documentation + + + + + + + + +

Keys and Certificates

+ +

Working with SSH keys, secrets, and X.509 certificates.

+ Working with SSH +
1. + SSH related files +
2. + SSH and local nodes +
3. + To upgrade a SSH host key +
4. + When SSH host key changes +
5. + Changing the SSH port +
6. + Sysadmins with multiple SSH keys +
7. + Removing sysadmin access +
+
+ X.509 Certificates +
1. + Configuration options +
2. + Certificate Authorities +
3. + Server certificates +
4. + Client certificates +
5. + Commercial certificates +
6. + Examine Certs +
+
+ Let’s Encrypt certificate +
1. + Install the official acme client +
2. + Fetch cert +
3. + Deploy the certs +
+

+ +

Working with SSH

+ +

SSH related files

+ +

Assuming your provider directory is called ‘provider’:

+ +

provider/nodes/crow/crow_ssh.pub – The public SSH host key for node ‘crow’.
provider/users/alice/alice_ssh.pub – The public SSH user key for user ‘alice’. Anyone with the private key that corresponds to this public key will have root access to all nodes.
provider/files/ssh/known_hosts – An autogenerated known_hosts, built from combining provider/nodes/*/*_ssh.pub. You must not edit this file directly. If you need to change it, remove or change one of the files that is used to generate known_hosts and then run leap compile.
provider/files/ssh/authorized_keys – An autogenerated list of all the user SSH keys with root access to the notes. It is created from provider/users/*/*_ssh.pub. You must not edit this file directly. If you need to change it, remove or change one of the files that is used to generate authorized_keys and then run leap compile.

+ + +

All of these files should be committed to source control.

+ +

If you rename, remove, or add a node with leap node [mv|add|rm] the SSH key files and the known_hosts file will get properly updated.

+ +

SSH and local nodes

+ +

Local nodes are run as Vagrant virtual machines. The leap command handles SSH slightly differently for these nodes.

+ +

Basically, all the SSH security is turned off for local nodes. Since local nodes only exist for a short time on your computer and can’t be reached from the internet, this is not a problem.

+ +

Specifically, for local nodes:

+ +

known_hosts is never updated with local node keys, since the SSH public key of a local node is different for each user.
leap entirely skips the checking of host keys when connecting with a local node.
leap adds the public Vagrant SSH key to the list of SSH keys for a user. The public Vagrant SSH key is a shared and insecure key that has root access to most Vagrant virtual machines.

+ + +

To upgrade a SSH host key

+ +

workstation$ leap node init NODE_NAME
+

+ +

This will prompt you if you want to upgrade the SSH host key, but only if leap thinks that an upgrade is advisable.

+ +

When SSH host key changes

+ +

If the host key for a node has changed, you will get an error “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”.

+ +

Changing the SSH port

+ +

Suppose you have a node blinky that has SSH listening on port 22 and you want to make it port 2200.

+ +

First, modify the configuration for blinky to specify the variable ssh.port as 2200. Usually, this is done in common.json or in a tag file.

+ +

For example, you could put this in tags/production.json:

+ +

{
+  "ssh": {
+    "port": 2200
+  }
+}
+

+ +

Run leap compile and open hiera/blinky.yaml to confirm that ssh.port is set to 2200. The port number must be specified as a number, not a string (no quotes).

+ +

So, you manually override the port in the deploy command, using the old port:

+ +

leap deploy --port 22 blinky
+

+ +

Afterwards, SSH on blinky should be listening on port 2200 and you can just run leap deploy blinky from then on.

+ +

Sysadmins with multiple SSH keys

+ +

The command leap add-user --self allows only one SSH key. If you want to specify more than one key for a user, you can do it manually:

+ +

users/userx/userx_ssh.pub
+users/userx/otherkey_ssh.pub
+

+ +

All keys matching ‘userx/*_ssh.pub’ will be usable.

+ +

Removing sysadmin access

+ +

Suppose you want to remove userx from having any further SSH access to the servers. Do this:

+ +

rm -r users/userx
+leap deploy
+

+ +

X.509 Certificates

+ +

Configuration options

+ +

The ca option in provider.json provides settings used when generating CAs and certificates. The defaults are as follows:

+ +

{
+  "ca": {
+    "name": "= global.provider.ca.organization + ' Root CA'",
+    "organization": "= global.provider.name[global.provider.default_language]",
+    "organizational_unit": "= 'https://' + global.provider.domain",
+    "bit_size": 4096,
+    "digest": "SHA256",
+    "life_span": "10y",
+    "server_certificates": {
+      "bit_size": 2048,
+      "digest": "SHA256",
+      "life_span": "1y"
+    },
+    "client_certificates": {
+      "bit_size": 2048,
+      "digest": "SHA256",
+      "life_span": "2m",
+      "limited_prefix": "LIMITED",
+      "unlimited_prefix": "UNLIMITED"
+    }
+  }
+}
+

+ +

You should not need to override these defaults in your own provider.json, but you can if you want to. To see what values are used for your provider, run leap inspect provider.json.

+ +

NOTE: A certificate bit_size greater than 2048 will probably not be recognized by most commercial CAs.

+ +

Certificate Authorities

+ +

There are three x.509 certificate authorities (CA) associated with your provider:

+ +

Commercial CA: It is strongly recommended that you purchase a commercial cert for your primary domain. The goal of platform is to not depend on the commercial CA system, but it does increase security and usability if you purchase a certificate. The cert for the commercial CA must live at files/cert/commercial_ca.crt.
Server CA: This is a self-signed CA responsible for signing all the server certificates. The private key lives at files/ca/ca.key and the public cert lives at files/ca/ca.crt. The key is very sensitive information and must be kept private. The public cert is distributed publicly.
Client CA: This is a self-signed CA responsible for signing all the client certificates. The private key lives at files/ca/client_ca.key and the public cert lives at files/ca/client_ca.crt. Neither file is distribute publicly. It is not a big deal if the private key for the client CA is compromised, you can just generate a new one and re-deploy.

+ + +

To generate both the Server CA and the Client CA, run the command:

+ +

leap cert ca
+

+ +

Server certificates

+ +

leap cert update
+

+ +

Run leap help cert update for notes on usage options.

+ +

Because the server certificates are generated locally on your personal machine, the private key for the Server CA need never be put on any server. It is up to you to keep this file secure.

+ +

Client certificates

+ +

Commercial certificates

+ +

When users visit your website, they don’t get a scary notice that something is wrong.
When a user runs the LEAP client, selecting your service provider will not cause a warning message.
When other providers first discover your provider, they are more likely to trust your provider key if it is fetched over a commercially verified link.

+ + +

+ +

To generate a CSR, run:

+ +

leap cert csr
+

+ +

The related commercial cert files are:

+ +

files/
+  cert/
+    domain.org.crt    # Server certificate for domain.org, obtained by commercial CA.
+    domain.org.csr    # Certificate signing request
+    domain.org.key    # Private key for you certificate
+    commercial_ca.crt # The CA cert obtained from the commercial CA.
+

+ +

The private key file is extremely sensitive and care should be taken with its provenance.

+ +

If you want to add additional fields to the CSR, like country, city, or locality, you can configure these values in provider.json like so:

+ +

  "ca": {
+    "server_certificates": {
+      "country": "US",
+      "state": "Washington",
+      "locality": "Seattle"
+    }
+  }
+

+ +

If they are not present, the CSR will be created without them.

+ +

Examine Certs

+ +

To see details about the keys and certs you can use leap inspect like so:

+ +

$ leap inspect files/ca/ca.crt
+

+ +

Let’s Encrypt certificate

+ +

Install the official acme client

+ +

server$ git clone https://github.com/certbot/certbot
+server$ cd certbot
+server$ ./certbot-auto --help
+

+ +

Fetch cert

+ +

Stop apache so the letsencrypt client can bind to port 80:

+ +

server$ systemctl stop apache2
+

+ +

Fetch the certs

+ +

server$ ./certbot-auto certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d)
+

+ +

This will put the certs and keys into /etc/letsencrypt/live/DOMAIN/.

+ +

workstation$ cd PATH_TO_PROVIDER_CONFIG
+

+ +

Copy the Certificate

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/cert.pem files/cert/dev.pixelated-project.org.crt
+

+ +

Copy the private key

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/privkey.pem files/cert/DOMAIN.key
+

+ +

Copy the CA chain cert

+ +

workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/fullchain.pem files/cert/commercial_ca.crt
+

+ +

Deploy the certs

+ +

Now you only need to deploy the certs

+ +

workstation$ leap deploy
+

+ +

This will put them into the right locations which are:

+ +

/etc/x509/certs/leap_commercial.crt for the certificate
/etc/x509/./keys/leap_commercial.key for the private key
/usr/local/share/ca-certificates/leap_commercial_ca.crt for the CA chain cert.

+ + +

Start apache2 again

+ +

server$ systemctl start apache2
+

+ +

+ + diff --git a/docs/en/guide/miscellaneous.html b/docs/en/guide/miscellaneous.html new file mode 100644 index 00000000..03239410 --- /dev/null +++ b/docs/en/guide/miscellaneous.html @@ -0,0 +1,145 @@ + + + + +Miscellaneous - LEAP Platform Documentation + + + + + + + + +

Miscellaneous

+ +

Miscellaneous commands you may need to know.

+ Facts +

+ +

Facts

+ +

There are a few cases when we must gather internal data from a node before we can successfully deploy to other nodes. This is what facts.json is for. It stores a snapshot of certain facts about each node, as needed. Entries in facts.json are updated automatically when you initialize, rename, or remove a node. To manually force a full update of facts.json, run:

+ +

leap facts update FILTER
+

+ +

Run leap help facts update for more information.

+ +

The file facts.json should be committed to source control. You might not have a facts.json if one is not required for your provider.

+ +

+ + diff --git a/docs/en/guide/miscellaneous/index.html b/docs/en/guide/miscellaneous/index.html new file mode 100644 index 00000000..9f17df4e --- /dev/null +++ b/docs/en/guide/miscellaneous/index.html @@ -0,0 +1,145 @@ + + + + +Miscellaneous - LEAP Platform Documentation + + + + + + + + +

Miscellaneous

+ +

Miscellaneous commands you may need to know.

+ Facts +

+ +

Facts

+ +

leap facts update FILTER
+

+ +

Run leap help facts update for more information.

+ +

The file facts.json should be committed to source control. You might not have a facts.json if one is not required for your provider.

+ +

+ + diff --git a/docs/en/guide/nodes.html b/docs/en/guide/nodes.html new file mode 100644 index 00000000..c6238b5f --- /dev/null +++ b/docs/en/guide/nodes.html @@ -0,0 +1,231 @@ + + + + +Nodes - LEAP Platform Documentation + + + + + + + + +

Nodes

+ +

Working with nodes, services, tags, and locations.

+ Locations +
+ Disabling Nodes +

+ +

Locations

+ +

All nodes should have a location.name specified, and optionally additional information about the location, like the time zone. This location information is used for two things:

+ +

Determine which nodes can, or must, communicate with one another via a local network. The way some virtualization environments work, like OpenStack, requires that nodes communicate via the local network if they are on the same network.
Allows the client to prefer connections to nodes that are closer in physical proximity to the user. This is particularly important for OpenVPN nodes.

+ + +

The location stanza in a node’s config file looks like this:

+ +

{
+  "location": {
+    "id": "ankara",
+    "name": "Ankara",
+    "country_code": "TR",
+    "timezone": "+2",
+    "hemisphere": "N"
+  }
+}
+

+ +

The fields:

+ +

id: An internal handle to use for this location. If two nodes have match location.id, then they are treated as being on a local network with one another. This value defaults to downcase and underscore of location.name.
name: Can be anything, might be displayed to the user in the client if they choose to manually select a gateway.
country_code: The ISO 3166-1 two letter country code.
timezone: The timezone expressed as an offset from UTC (in standard time, not daylight savings). You can look up the timezone using this handy map.
hemisphere: This should be “S” for all servers in South America, Africa, or Australia. Otherwise, this should be “N”.

+ + +

These location options are very imprecise, but good enough for most usage. The client often does not know its own location precisely either. Instead, the client makes an educated guess at location based on the OS’s timezone and locale.

+ +

If you have multiple nodes in a single location, it is best to use a tag for the location. For example:

+ +

tags/ankara.json:

+ +

{
+  "location": {
+    "name": "Ankara",
+    "country_code": "TR",
+    "timezone": "+2",
+    "hemisphere": "N"
+  }
+}
+

+ +

nodes/vpngateway.json:

+ +

{
+  "services": "openvpn",
+  "tags": ["production", "ankara"],
+  "ip_address": "1.1.1.1",
+  "openvpn": {
+    "gateway_address": "1.1.1.2"
+  }
+}
+

+ +

Unless you are using OpenStack or AWS, setting location for nodes is not required. It is, however, highly recommended.

+ +

Disabling Nodes

+ +

There are two ways to temporarily disable a node:

+ +

Option 1: disabled environment

+ +

You can assign an environment to the node that marks it as disabled. Then, if you use environment pinning, the node will be ignored when you deploy. For example:

+ +

{
+  "environment": "disabled"
+}
+

+ +

Then use leap env pin ENV to pin the environment to something other than ‘disabled’. This only works if all the other nodes are also assigned to some environment.

+ +

Option 2: enabled == false

+ +

If a node has a property enabled set to false, then the leap command will skip over the node and pretend that it does not exist. For example:

+ +

{
+  "ip_address": "1.1.1.1",
+  "services": ["openvpn"],
+  "enabled": false
+}
+

+ +

Options 3: no-deploy

+ +

If the file /etc/leap/no-deploy exists on a node, then when you run the commmand leap deploy it will halt and prevent a deploy from going through (if the node was going to be included in the deploy).

+ +

+ + diff --git a/docs/en/guide/nodes/index.html b/docs/en/guide/nodes/index.html new file mode 100644 index 00000000..7f1a60b3 --- /dev/null +++ b/docs/en/guide/nodes/index.html @@ -0,0 +1,231 @@ + + + + +Nodes - LEAP Platform Documentation + + + + + + + + +

Nodes

+ +

Working with nodes, services, tags, and locations.

+ Locations +
+ Disabling Nodes +

+ +

Locations

+ +

All nodes should have a location.name specified, and optionally additional information about the location, like the time zone. This location information is used for two things:

+ +

Determine which nodes can, or must, communicate with one another via a local network. The way some virtualization environments work, like OpenStack, requires that nodes communicate via the local network if they are on the same network.
Allows the client to prefer connections to nodes that are closer in physical proximity to the user. This is particularly important for OpenVPN nodes.

+ + +

The location stanza in a node’s config file looks like this:

+ +

{
+  "location": {
+    "id": "ankara",
+    "name": "Ankara",
+    "country_code": "TR",
+    "timezone": "+2",
+    "hemisphere": "N"
+  }
+}
+

+ +

The fields:

+ +

id: An internal handle to use for this location. If two nodes have match location.id, then they are treated as being on a local network with one another. This value defaults to downcase and underscore of location.name.
name: Can be anything, might be displayed to the user in the client if they choose to manually select a gateway.
country_code: The ISO 3166-1 two letter country code.
timezone: The timezone expressed as an offset from UTC (in standard time, not daylight savings). You can look up the timezone using this handy map.
hemisphere: This should be “S” for all servers in South America, Africa, or Australia. Otherwise, this should be “N”.

+ + +

+ +

If you have multiple nodes in a single location, it is best to use a tag for the location. For example:

+ +

tags/ankara.json:

+ +

{
+  "location": {
+    "name": "Ankara",
+    "country_code": "TR",
+    "timezone": "+2",
+    "hemisphere": "N"
+  }
+}
+

+ +

nodes/vpngateway.json:

+ +

{
+  "services": "openvpn",
+  "tags": ["production", "ankara"],
+  "ip_address": "1.1.1.1",
+  "openvpn": {
+    "gateway_address": "1.1.1.2"
+  }
+}
+

+ +

Unless you are using OpenStack or AWS, setting location for nodes is not required. It is, however, highly recommended.

+ +

Disabling Nodes

+ +

There are two ways to temporarily disable a node:

+ +

Option 1: disabled environment

+ +

You can assign an environment to the node that marks it as disabled. Then, if you use environment pinning, the node will be ignored when you deploy. For example:

+ +

{
+  "environment": "disabled"
+}
+

+ +

Then use leap env pin ENV to pin the environment to something other than ‘disabled’. This only works if all the other nodes are also assigned to some environment.

+ +

Option 2: enabled == false

+ +

If a node has a property enabled set to false, then the leap command will skip over the node and pretend that it does not exist. For example:

+ +

{
+  "ip_address": "1.1.1.1",
+  "services": ["openvpn"],
+  "enabled": false
+}
+

+ +

Options 3: no-deploy

+ +

+ + diff --git a/docs/en/guide/provider-configuration.html b/docs/en/guide/provider-configuration.html new file mode 100644 index 00000000..5c98eb34 --- /dev/null +++ b/docs/en/guide/provider-configuration.html @@ -0,0 +1,223 @@ + + + + +Provider Configuration - LEAP Platform Documentation + + + + + + + + +

Provider Configuration

+ +

Explore how to configure your provider.

+ +

Required provider configuration

+ +

There are a few required settings in provider.json. At a minimum, you must have:

+ +

domain: defines the primary domain of the provider. This is the domain that users will type in when using the Bitmask client, although it is not necessarily the domain where users will visit if they sign up via the web application. If email is supported, all accounts will be username@domain.
name: A brief title for this provider. It can be multiple words, but should not be too long.
contacts.default: One or more email addresses for sysadmins.

+ + +

For example:

+ +

{
+  "domain": "freerobot.org",
+  "name": "Freedom for Robots!",
+  "contacts": {
+    "default": "root@freerobot.org"
+  }
+}
+

+ +

Recommended provider configuration

+ +

description: A longer description of the provider, shown to the user when they register a new account through Bitmask client.
languages: A list of language codes that should be enabled.
default_language: The initial default language code.
enrollment_policy: One of “open”, “closed”, or “invite”. (invite not currently supported).

+ + +

For example:

+ +

{
+  "description": "It is time for robots of the world to unite and throw of the shackles of servitude to our organic overlords.",
+  "languages": ["en", "de", "pt", "01"],
+  "default_language": "01",
+  "enrollman_policy": "open"
+}
+

+ +

For a full list of possible settings, you can use leap inspect to see how provider.json is evaluated after including the inherited defaults:

+ +

$ leap inspect provider.json
+

+ +

Configuring service levels

+ +

The provider.json file defines the available service levels for the provider.

+ +

For example, in provider.json:

+ +

"service": {
+   "default_service_level": "low",
+   "levels": {
+      "low": {
+        "description": "Entry level plan, with unlimited bandwidth and minimal storage quota.",
+        "name": "entry",
+        "storage": "10 MB",
+        "rate": {
+          "USD": 5,
+          "GBP": 3,
+          "EUR": 6
+        }
+      },
+      "full": {
+        "description": "Full plan, with unlimited bandwidth and higher quota."
+        "name": "full",
+        "storage": "5 GB",
+        "rate": {
+          "USD": 10,
+          "GBP": 6,
+          "EUR": 12
+        }
+      }
+    }
+  }
+}
+

+ +

For a list of currency codes, see https://en.wikipedia.org/wiki/ISO_4217#Active_codes

+ +

+ + diff --git a/docs/en/guide/provider-configuration/index.html b/docs/en/guide/provider-configuration/index.html new file mode 100644 index 00000000..b710cb64 --- /dev/null +++ b/docs/en/guide/provider-configuration/index.html @@ -0,0 +1,223 @@ + + + + +Provider Configuration - LEAP Platform Documentation + + + + + + + + +

Provider Configuration

+ +

Explore how to configure your provider.

+ +

Required provider configuration

+ +

There are a few required settings in provider.json. At a minimum, you must have:

+ +

domain: defines the primary domain of the provider. This is the domain that users will type in when using the Bitmask client, although it is not necessarily the domain where users will visit if they sign up via the web application. If email is supported, all accounts will be username@domain.
name: A brief title for this provider. It can be multiple words, but should not be too long.
contacts.default: One or more email addresses for sysadmins.

+ + +

For example:

+ +

{
+  "domain": "freerobot.org",
+  "name": "Freedom for Robots!",
+  "contacts": {
+    "default": "root@freerobot.org"
+  }
+}
+

+ +

Recommended provider configuration

+ +

description: A longer description of the provider, shown to the user when they register a new account through Bitmask client.
languages: A list of language codes that should be enabled.
default_language: The initial default language code.
enrollment_policy: One of “open”, “closed”, or “invite”. (invite not currently supported).

+ + +

For example:

+ +

{
+  "description": "It is time for robots of the world to unite and throw of the shackles of servitude to our organic overlords.",
+  "languages": ["en", "de", "pt", "01"],
+  "default_language": "01",
+  "enrollman_policy": "open"
+}
+

+ +

For a full list of possible settings, you can use leap inspect to see how provider.json is evaluated after including the inherited defaults:

+ +

$ leap inspect provider.json
+

+ +

Configuring service levels

+ +

The provider.json file defines the available service levels for the provider.

+ +

For example, in provider.json:

+ +

"service": {
+   "default_service_level": "low",
+   "levels": {
+      "low": {
+        "description": "Entry level plan, with unlimited bandwidth and minimal storage quota.",
+        "name": "entry",
+        "storage": "10 MB",
+        "rate": {
+          "USD": 5,
+          "GBP": 3,
+          "EUR": 6
+        }
+      },
+      "full": {
+        "description": "Full plan, with unlimited bandwidth and higher quota."
+        "name": "full",
+        "storage": "5 GB",
+        "rate": {
+          "USD": 10,
+          "GBP": 6,
+          "EUR": 12
+        }
+      }
+    }
+  }
+}
+

+ +

For a list of currency codes, see https://en.wikipedia.org/wiki/ISO_4217#Active_codes

+ +

+ + diff --git a/docs/en/guide/virtual-machines.html b/docs/en/guide/virtual-machines.html new file mode 100644 index 00000000..5cee9a40 --- /dev/null +++ b/docs/en/guide/virtual-machines.html @@ -0,0 +1,299 @@ + + + + +Virtual Machines - LEAP Platform Documentation + + + + + + + + +

Virtual Machines

+ +

Running LEAP platform on remote virtual machines

+ +

Introduction

+ +

You can use the leap command line to easily remote virtual machines.

+ +

Note: there are two types of virtual machines that leap can handle:

+ +

Local virtual machines running with vagrant, for use in testing.
Remote virtual machines hosted by a cloud provider like AWS or Rackspace.

+ + +

This guide is for “remote virtual machines”. For “local virtual machines” see Vagrant.

+ +

Currently, only Amazon AWS is supported as a cloud provider.

+ +

Configuration

+ +

To get started with virtual machines, you must configure a cloud.json file with your API credentials for the virtual machine vendor. This file lives in the root of your provider directory.

+ +

For example:

+ +

{
+  "my_aws": {
+    "api": "aws",
+    "vendor": "aws",
+    "auth": {
+      "region": "us-west-2",
+      "aws_access_key_id": "xxxx my key id xxxx",
+      "aws_secret_access_key": "xxxx my access key xxxx"
+    }
+  }
+}
+

+ +

This will configure a cloud “authentication profile” called “my_aws”. This profile will be used by default if there is only one. See below for managing multiple authentication profiles.

+ +

Required cloud.json properties

+ +

$profile: In this case, ‘my_aws’.
$profile.api: For now, must always be “aws”.
$profile.vendor: For now, must always be “aws”.
$profile.auth: API specific authentication configuration for this profile. In the case of AWS, it must include auth.region, auth.aws_access_key_id, and aws_secret_access_key.

+ + +

Additional cloud.json properties

+ +

In addition to required configuration properties, these are optional:

+ +

$profile.default_image: What image to use for new nodes by default. Generally, you should not specify this, because it will automatically select the right Debian image for your region. A node can override this with the property vm.image.
$profile.default_options: This is passed directly to the cloud API, and so is specific to whichever API you are using. The node can override this with the property vm.options.

+ + +

A more complete example cloud.json:

+ +

{
+  "my_aws": {
+    "api": "aws",
+    "vendor": "aws",
+    "auth": {
+      "region": "us-west-2",
+      "aws_access_key_id": "xxxx my key id xxxx",
+      "aws_secret_access_key": "xxxx my access key xxxx"
+    },
+    "default_image": "ami-98e114f8",
+    "default_options": {
+      "InstanceType": "t2.nano"
+    }
+  }
+}
+

+ +

Usage

+ +

See leap help vm for a description of all the possible commands.

+ +

In order to be able to create new virtual machine instances, you need to register your SSH key with the VM vendor.

+ +

leap vm key-register
+

+ +

You only have to do this once, and only people who will be creating new VM instances need to do this.

+ +

Once you have done that, you just leap vm add to create the virtual machine and then leap vm start to actually boot it.

+ +

leap vm add mynode
+leap vm start mynode
+

+ +

You can specify seed values to leap vm add. For example:

+ +

leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small
+

+ +

Check to see what the status is of all VMs:

+ +

leap vm status
+

+ +

If it looks good, you can now deploy to the new server:

+ +

leap node init mynode
+leap deploy mynode
+

+ +

To stop the VM:

+ +

leap vm stop mynode
+

+ +

To destroy the VM and clean up its storage space:

+ +

leap vm rm mynode
+

+ +

In general, you should remove VMs instead of stopping them, unless you plan on stopping the VM for a short amount of time. A stopped VM will still use disk space and still incur charges.

+ +

Keeping State Synchronized

+ +

The LEAP platform stores all its state information in flat static files. The virtual machine vendor, however, also has its own state.

+ +

On the provider side, VM state is stored in node configuration files in nodes/*.json. Of particular importance are the properties ip_address and vm.id.

+ +

Most of the time, you should not have any trouble: the leap vm commands will keep things in sync. However, if the state of your configuration files gets out of sync with the state of the virtual machines, it can cause problems.

+ +

The command leap vm status will warn you whenever it detects a problem and it will usually propose a fix.

+ +

Typically, the fix is to manually update the binding between a local node configuration and the running remote virtual machine, like so:

+ +

leap vm bind NODE_NAME VM_ID
+

+ +

Multiple authentication profiles

+ +

If you have multiple profiles configured in cloud.json, you can specify which one you want to use:

+ +

Set the vm.auth property in the node configuration to match the name of the authentication profile.
Or, pass --auth PROFILE_NAME on the command line.

+ + +

+ + diff --git a/docs/en/guide/virtual-machines/index.html b/docs/en/guide/virtual-machines/index.html new file mode 100644 index 00000000..da0da107 --- /dev/null +++ b/docs/en/guide/virtual-machines/index.html @@ -0,0 +1,299 @@ + + + + +Virtual Machines - LEAP Platform Documentation + + + + + + + + +

Virtual Machines

+ +

Running LEAP platform on remote virtual machines

+ +

Introduction

+ +

You can use the leap command line to easily remote virtual machines.

+ +

Note: there are two types of virtual machines that leap can handle:

+ +

Local virtual machines running with vagrant, for use in testing.
Remote virtual machines hosted by a cloud provider like AWS or Rackspace.

+ + +

This guide is for “remote virtual machines”. For “local virtual machines” see Vagrant.

+ +

Currently, only Amazon AWS is supported as a cloud provider.

+ +

Configuration

+ +

To get started with virtual machines, you must configure a cloud.json file with your API credentials for the virtual machine vendor. This file lives in the root of your provider directory.

+ +

For example:

+ +

{
+  "my_aws": {
+    "api": "aws",
+    "vendor": "aws",
+    "auth": {
+      "region": "us-west-2",
+      "aws_access_key_id": "xxxx my key id xxxx",
+      "aws_secret_access_key": "xxxx my access key xxxx"
+    }
+  }
+}
+

+ +

This will configure a cloud “authentication profile” called “my_aws”. This profile will be used by default if there is only one. See below for managing multiple authentication profiles.

+ +

Required cloud.json properties

+ +

$profile: In this case, ‘my_aws’.
$profile.api: For now, must always be “aws”.
$profile.vendor: For now, must always be “aws”.
$profile.auth: API specific authentication configuration for this profile. In the case of AWS, it must include auth.region, auth.aws_access_key_id, and aws_secret_access_key.

+ + +

Additional cloud.json properties

+ +

In addition to required configuration properties, these are optional:

+ +

$profile.default_image: What image to use for new nodes by default. Generally, you should not specify this, because it will automatically select the right Debian image for your region. A node can override this with the property vm.image.
$profile.default_options: This is passed directly to the cloud API, and so is specific to whichever API you are using. The node can override this with the property vm.options.

+ + +

A more complete example cloud.json:

+ +

{
+  "my_aws": {
+    "api": "aws",
+    "vendor": "aws",
+    "auth": {
+      "region": "us-west-2",
+      "aws_access_key_id": "xxxx my key id xxxx",
+      "aws_secret_access_key": "xxxx my access key xxxx"
+    },
+    "default_image": "ami-98e114f8",
+    "default_options": {
+      "InstanceType": "t2.nano"
+    }
+  }
+}
+

+ +

Usage

+ +

See leap help vm for a description of all the possible commands.

+ +

In order to be able to create new virtual machine instances, you need to register your SSH key with the VM vendor.

+ +

leap vm key-register
+

+ +

You only have to do this once, and only people who will be creating new VM instances need to do this.

+ +

Once you have done that, you just leap vm add to create the virtual machine and then leap vm start to actually boot it.

+ +

leap vm add mynode
+leap vm start mynode
+

+ +

You can specify seed values to leap vm add. For example:

+ +

leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small
+

+ +

Check to see what the status is of all VMs:

+ +

leap vm status
+

+ +

If it looks good, you can now deploy to the new server:

+ +

leap node init mynode
+leap deploy mynode
+

+ +

To stop the VM:

+ +

leap vm stop mynode
+

+ +

To destroy the VM and clean up its storage space:

+ +

leap vm rm mynode
+

+ +

In general, you should remove VMs instead of stopping them, unless you plan on stopping the VM for a short amount of time. A stopped VM will still use disk space and still incur charges.

+ +

Keeping State Synchronized

+ +

The LEAP platform stores all its state information in flat static files. The virtual machine vendor, however, also has its own state.

+ +

On the provider side, VM state is stored in node configuration files in nodes/*.json. Of particular importance are the properties ip_address and vm.id.

+ +

The command leap vm status will warn you whenever it detects a problem and it will usually propose a fix.

+ +

Typically, the fix is to manually update the binding between a local node configuration and the running remote virtual machine, like so:

+ +

leap vm bind NODE_NAME VM_ID
+

+ +

Multiple authentication profiles

+ +

If you have multiple profiles configured in cloud.json, you can specify which one you want to use:

+ +

Set the vm.auth property in the node configuration to match the name of the authentication profile.
Or, pass --auth PROFILE_NAME on the command line.

+ + +

+ + -- cgit v1.2.3 From 811deee9e5b8cc42a3ea424ef873e9d69eb50cba Mon Sep 17 00:00:00 2001 From: elijah Date: Wed, 14 Sep 2016 15:09:32 -0700 Subject: updated docs --- docs/en/guide/commands.html | 253 ++++++++++++++++++++++--- docs/en/guide/commands/index.html | 253 ++++++++++++++++++++++--- docs/en/guide/keys-and-certificates.html | 115 +++++------ docs/en/guide/keys-and-certificates/index.html | 115 +++++------ 4 files changed, 532 insertions(+), 204 deletions(-) (limited to 'docs/en/guide') diff --git a/docs/en/guide/commands.html b/docs/en/guide/commands.html index bccbaf50..8685c6dc 100644 --- a/docs/en/guide/commands.html +++ b/docs/en/guide/commands.html @@ -127,7 +127,7 @@ Command Line Reference - LEAP Platform Documentation Global Options

- leap add-user USERNAME + leap add-user

leap cert @@ -136,11 +136,17 @@ Command Line Reference - LEAP Platform Documentation leap cert ca

- leap cert csr + leap cert csr DOMAIN

leap cert dh

+ leap cert register +

+ leap cert renew DOMAIN +

leap cert update FILTER

@@ -177,9 +183,6 @@ Command Line Reference - LEAP Platform Documentation -

- leap debug FILTER -

leap deploy FILTER

@@ -211,6 +214,9 @@ Command Line Reference - LEAP Platform Documentation

leap history FILTER

+ leap info FILTER +

leap inspect FILE

@@ -221,19 +227,19 @@ Command Line Reference - LEAP Platform Documentation leap local

- leap local destroy [FILTER] + leap local ls [FILTER]
leap local reset [FILTER]
- leap local save [FILTER] + leap local rm [FILTER]
- leap local start [FILTER] + leap local save [FILTER]
- leap local status [FILTER] + leap local start [FILTER]
leap local stop [FILTER] @@ -263,6 +269,12 @@ Command Line Reference - LEAP Platform Documentation

+ leap open NAME +

+ leap run COMMAND FILTER +

leap scp FILE1 FILE2

@@ -283,6 +295,49 @@ Command Line Reference - LEAP Platform Documentation

leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT

+ leap user +

+ leap vm +

The command “leap” can be used to manage a bevy of servers running the LEAP platform from the comfort of your own home.

@@ -311,9 +366,11 @@ Skip prompts and assume “yes”.

leap add-user USERNAME

leap add-user

+ +

Manage trusted sysadmins (DEPRECATED)

Adds a new trusted sysadmin by adding public keys to the “users” directory.

Use leap user add instead

Options

@@ -339,7 +396,7 @@ Add yourself as a trusted sysadmin by choosing among the public keys available f

leap cert csr

leap cert csr DOMAIN

Creates a CSR for use in buying a commercial X.509 certificate.

@@ -383,6 +440,16 @@ Default Value: None

Creates a Diffie-Hellman parameter file, needed for forward secret OpenVPN ciphers.

leap cert register

+ +

This only needs to be done once.

+ +

leap cert renew DOMAIN

+ +

Renews a certificate using the CA letsencrypt.org

leap cert update FILTER

Creates or renews a X.509 certificate/key pair for a single node or all nodes, but only if needed.

@@ -447,12 +514,6 @@ Default Value: None

leap debug FILTER

- -

Output debug information.

- -

The FILTER can be the name of a node, service, or tag.

leap deploy FILTER

Apply recipes to a node or set of nodes.

@@ -548,6 +609,12 @@ Show last deploy only

leap info FILTER

+ +

Prints information regarding facts, history, and running processes for a node or nodes.

+ +

The FILTER can be the name of a node, service, or tag.

leap inspect FILE

Prints details about a file. Alternately, the argument FILE can be the name of a node, service or tag.

@@ -585,16 +652,20 @@ Include disabled nodes in the list.

Manage local virtual machines.

This command provides a convenient way to manage Vagrant-based virtual machines. If FILTER argument is missing, the command runs on all local virtual machines. The Vagrantfile is automatically generated in ‘test/Vagrantfile’. If you want to run vagrant commands manually, cd to ‘test’.

leap local destroy [FILTER]

leap local ls [FILTER]

Destroys the virtual machine(s), reclaiming the disk space

Print the status of local virtual machine(s)

leap local reset [FILTER]

Resets virtual machine(s) to the last saved snapshot

leap local rm [FILTER]

+ +

Destroys the virtual machine(s), reclaiming the disk space

leap local save [FILTER]

Saves the current state of the virtual machine as a new snapshot

@@ -612,10 +683,6 @@ Default Value: LEAP/jessie -

leap local status [FILTER]

- -

Print the status of local virtual machine(s)

leap local stop [FILTER]

Shuts down the virtual machine(s)

@@ -674,13 +741,15 @@ Default Value: None

To set nested properties, property name can contain ‘.’, like so: leap node add web1 ssh.port:44

Separeate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

Separate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

Options

--local -Make a local testing node (by automatically assigning the next available local IP address). Local nodes are run as virtual machines on your computer.
--local +Make a local testing node (by assigning the next available local IP address). Local nodes are run as virtual machines on your computer.
--vm +Make a remote virtual machine for this node. Requires a valid cloud.json configuration.

@@ -698,9 +767,8 @@ Override the default SSH IP address. Default Value: None

--port PORT Override the default SSH port. +This command prepares a server to be used with the LEAP Platform by saving the server’s SSH host key, copying the authorized_keys file, installing packages that are required for deploying, and registering important facts. Node init must be run before deploying to a server, and the server must be running and available via the network. This command only needs to be run once, but there is no harm in running it multiple times. Default Value: None

--echo -If set, passwords are visible as you type them (default is hidden)

@@ -712,6 +780,40 @@ If set, passwords are visible as you type them (default is hidden)

Removes all the files related to the node named NAME.

leap open NAME

+ +

Opens useful URLs in a web browser.

+ +

NAME can be one or more of: monitor, web, docs, bug

+ +

Options

+ +

--env ENVIRONMENT +Which environment to use (optional). +Default Value: None
--[no-]ip +To get around HSTS or DNS, open the URL using the IP address instead of the domain (optional).

+ + +

leap run COMMAND FILTER

+ +

Run a shell command remotely

+ +

Runs the specified command COMMAND on each node in the FILTER set. For example, leap run 'uname -a' webapp

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. +Default Value: None
--[no-]stream +If set, stream the output as it arrives. (default: –stream for a single node, –no-stream for multiple nodes)

+ +

leap scp FILE1 FILE2

Secure copy from FILE1 to FILE2. Files are specified as NODE_NAME:FILE_PATH. For local paths, omit “NODE_NAME:”.

@@ -778,6 +880,97 @@ Default Value: None

leap user

+ +

Manage trusted sysadmins

+ +

Manage the trusted sysadmins that are configured in the ‘users’ directory.

+ +

leap user add USERNAME

+ +

Adds a new trusted sysadmin

+ +

Options

+ +

--pgp-pub-key arg +OpenPGP public key file for this new user +Default Value: None
--ssh-pub-key arg +SSH public key file for this new user +Default Value: None
--self +Add yourself as a trusted sysadmin by choosing among the public keys available for the current user.

+ + +

leap user ls

+ +

Lists the configured sysadmins

+ +

leap user rm USERNAME

+ +

Removes a trusted sysadmin

+ +

leap vm

+ +

Manage remote virtual machines (VMs).

+ +

This command provides a convenient way to manage virtual machines. FILTER may be a node filter or the ID of a virtual machine.

+ +

Options

+ +

--auth AUTH +Choose which authentication credentials to use from the file cloud.json. If omitted, will default to the node’s vm.auth property, or the first credentials in cloud.json +Default Value: None
--[no-]mock +Run as simulation, without actually connecting to a cloud provider. If set, –auth is ignored.
--[no-]wait +Wait for servers to start/stop before continuing.

+ + +

leap vm add NODE_NAME [SEED]

+ +

Allocates a new VM and/or associates it with node NAME.

+ +

If node configuration file does not yet exist, it is created with the optional SEED values. You can run this command when the virtual machine already exists in order to update the node’s vm.id property.

+ +

leap vm bind NODE_NAME INSTANCE_ID

+ +

Binds a running VM instance to a node configuration.

+ +

Afterwards, the VM will be assigned a label matching the node name, and the node config will be updated with the instance ID.

+ +

leap vm key-list

+ +

Lists the registered SSH public keys for a particular VM provider.

+ +

leap vm key-register

+ +

Registers a SSH public key for use when creating new VMs.

+ +

Note that only people who are creating new VM instances need to have their key registered.

+ +

leap vm rm [FILTER]

+ +

Destroys one or more VMs

+ +

leap vm start [FILTER]

+ +

Starts one or more VMs

+ +

leap vm status [FILTER]

+ +

Print the status of all VMs

+ +

leap vm stop [FILTER]

+ +

Shuts down one or more VMs

+ +

This keeps the storage allocated. To save resources, run leap vm rm instead.

+ diff --git a/docs/en/guide/commands/index.html b/docs/en/guide/commands/index.html index ec1785f8..fbb77d87 100644 --- a/docs/en/guide/commands/index.html +++ b/docs/en/guide/commands/index.html @@ -127,7 +127,7 @@ Command Line Reference - LEAP Platform Documentation Global Options

- leap add-user USERNAME + leap add-user

leap cert @@ -136,11 +136,17 @@ Command Line Reference - LEAP Platform Documentation leap cert ca

- leap cert csr + leap cert csr DOMAIN

leap cert dh

+ leap cert register +

+ leap cert renew DOMAIN +

leap cert update FILTER

@@ -177,9 +183,6 @@ Command Line Reference - LEAP Platform Documentation -

- leap debug FILTER -

leap deploy FILTER

@@ -211,6 +214,9 @@ Command Line Reference - LEAP Platform Documentation

leap history FILTER

+ leap info FILTER +

leap inspect FILE

@@ -221,19 +227,19 @@ Command Line Reference - LEAP Platform Documentation leap local

- leap local destroy [FILTER] + leap local ls [FILTER]
leap local reset [FILTER]
- leap local save [FILTER] + leap local rm [FILTER]
- leap local start [FILTER] + leap local save [FILTER]
- leap local status [FILTER] + leap local start [FILTER]
leap local stop [FILTER] @@ -263,6 +269,12 @@ Command Line Reference - LEAP Platform Documentation

+ leap open NAME +

+ leap run COMMAND FILTER +

leap scp FILE1 FILE2

@@ -283,6 +295,49 @@ Command Line Reference - LEAP Platform Documentation

leap tunnel [LOCAL_PORT:]NAME:REMOTE_PORT

+ leap user +

+ leap vm +

The command “leap” can be used to manage a bevy of servers running the LEAP platform from the comfort of your own home.

@@ -311,9 +366,11 @@ Skip prompts and assume “yes”.

leap add-user USERNAME

leap add-user

+ +

Manage trusted sysadmins (DEPRECATED)

Adds a new trusted sysadmin by adding public keys to the “users” directory.

Use leap user add instead

Options

@@ -339,7 +396,7 @@ Add yourself as a trusted sysadmin by choosing among the public keys available f

leap cert csr

leap cert csr DOMAIN

Creates a CSR for use in buying a commercial X.509 certificate.

@@ -383,6 +440,16 @@ Default Value: None

Creates a Diffie-Hellman parameter file, needed for forward secret OpenVPN ciphers.

leap cert register

+ +

This only needs to be done once.

+ +

leap cert renew DOMAIN

+ +

Renews a certificate using the CA letsencrypt.org

leap cert update FILTER

Creates or renews a X.509 certificate/key pair for a single node or all nodes, but only if needed.

@@ -447,12 +514,6 @@ Default Value: None

leap debug FILTER

- -

Output debug information.

- -

The FILTER can be the name of a node, service, or tag.

leap deploy FILTER

Apply recipes to a node or set of nodes.

@@ -548,6 +609,12 @@ Show last deploy only

leap info FILTER

+ +

Prints information regarding facts, history, and running processes for a node or nodes.

+ +

The FILTER can be the name of a node, service, or tag.

leap inspect FILE

Prints details about a file. Alternately, the argument FILE can be the name of a node, service or tag.

@@ -585,16 +652,20 @@ Include disabled nodes in the list.

Manage local virtual machines.

leap local destroy [FILTER]

leap local ls [FILTER]

Destroys the virtual machine(s), reclaiming the disk space

Print the status of local virtual machine(s)

leap local reset [FILTER]

Resets virtual machine(s) to the last saved snapshot

leap local rm [FILTER]

+ +

Destroys the virtual machine(s), reclaiming the disk space

leap local save [FILTER]

Saves the current state of the virtual machine as a new snapshot

@@ -612,10 +683,6 @@ Default Value: LEAP/jessie -

leap local status [FILTER]

- -

Print the status of local virtual machine(s)

leap local stop [FILTER]

Shuts down the virtual machine(s)

@@ -674,13 +741,15 @@ Default Value: None

To set nested properties, property name can contain ‘.’, like so: leap node add web1 ssh.port:44

Separeate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

Separate multiple values for a single property with a comma, like so: leap node add mynode services:webapp,dns

Options

--local -Make a local testing node (by automatically assigning the next available local IP address). Local nodes are run as virtual machines on your computer.
--local +Make a local testing node (by assigning the next available local IP address). Local nodes are run as virtual machines on your computer.
--vm +Make a remote virtual machine for this node. Requires a valid cloud.json configuration.

@@ -698,9 +767,8 @@ Override the default SSH IP address. Default Value: None

--echo -If set, passwords are visible as you type them (default is hidden)

@@ -712,6 +780,40 @@ If set, passwords are visible as you type them (default is hidden)

Removes all the files related to the node named NAME.

leap open NAME

+ +

Opens useful URLs in a web browser.

+ +

NAME can be one or more of: monitor, web, docs, bug

+ +

Options

+ +

--env ENVIRONMENT +Which environment to use (optional). +Default Value: None
--[no-]ip +To get around HSTS or DNS, open the URL using the IP address instead of the domain (optional).

+ + +

leap run COMMAND FILTER

+ +

Run a shell command remotely

+ +

Runs the specified command COMMAND on each node in the FILTER set. For example, leap run 'uname -a' webapp

+ +

Options

+ +

--port SSH_PORT +Override default SSH port used when trying to connect to the server. +Default Value: None
--[no-]stream +If set, stream the output as it arrives. (default: –stream for a single node, –no-stream for multiple nodes)

+ +

leap scp FILE1 FILE2

Secure copy from FILE1 to FILE2. Files are specified as NODE_NAME:FILE_PATH. For local paths, omit “NODE_NAME:”.

@@ -778,6 +880,97 @@ Default Value: None

leap user

+ +

Manage trusted sysadmins

+ +

Manage the trusted sysadmins that are configured in the ‘users’ directory.

+ +

leap user add USERNAME

+ +

Adds a new trusted sysadmin

+ +

Options

+ +

--pgp-pub-key arg +OpenPGP public key file for this new user +Default Value: None
--ssh-pub-key arg +SSH public key file for this new user +Default Value: None
--self +Add yourself as a trusted sysadmin by choosing among the public keys available for the current user.

+ + +

leap user ls

+ +

Lists the configured sysadmins

+ +

leap user rm USERNAME

+ +

Removes a trusted sysadmin

+ +

leap vm

+ +

Manage remote virtual machines (VMs).

+ +

This command provides a convenient way to manage virtual machines. FILTER may be a node filter or the ID of a virtual machine.

+ +

Options

+ +

--auth AUTH +Choose which authentication credentials to use from the file cloud.json. If omitted, will default to the node’s vm.auth property, or the first credentials in cloud.json +Default Value: None
--[no-]mock +Run as simulation, without actually connecting to a cloud provider. If set, –auth is ignored.
--[no-]wait +Wait for servers to start/stop before continuing.

+ + +

leap vm add NODE_NAME [SEED]

+ +

Allocates a new VM and/or associates it with node NAME.

+ +

leap vm bind NODE_NAME INSTANCE_ID

+ +

Binds a running VM instance to a node configuration.

+ +

Afterwards, the VM will be assigned a label matching the node name, and the node config will be updated with the instance ID.

+ +

leap vm key-list

+ +

Lists the registered SSH public keys for a particular VM provider.

+ +

leap vm key-register

+ +

Registers a SSH public key for use when creating new VMs.

+ +

Note that only people who are creating new VM instances need to have their key registered.

+ +

leap vm rm [FILTER]

+ +

Destroys one or more VMs

+ +

leap vm start [FILTER]

+ +

Starts one or more VMs

+ +

leap vm status [FILTER]

+ +

Print the status of all VMs

+ +

leap vm stop [FILTER]

+ +

Shuts down one or more VMs

+ +

This keeps the storage allocated. To save resources, run leap vm rm instead.

+ diff --git a/docs/en/guide/keys-and-certificates.html b/docs/en/guide/keys-and-certificates.html index ee7d2699..f5f83066 100644 --- a/docs/en/guide/keys-and-certificates.html +++ b/docs/en/guide/keys-and-certificates.html @@ -165,7 +165,7 @@ Keys and Certificates - LEAP Platform Documentation Client certificates

- Commercial certificates + Signed certificates

Examine Certs @@ -173,16 +173,13 @@ Keys and Certificates - LEAP Platform Documentation

- Let’s Encrypt certificate + Let’s Encrypt

- Install the official acme client + Creating a certificate
- Fetch cert -
- Deploy the certs + Renewing a certificate

@@ -351,9 +348,9 @@ leap deploy

Commercial certificates

Signed certificates

We strongly recommend that the primary domain for your provider has a certificate signed by a “trusted CA” (e.g. A Certificate Authority that is trusted by the web browsers and in the Debian ca-certificates package). This provides several benefits:

When users visit your website, they don’t get a scary notice that something is wrong.

The LEAP platform is designed so that it assumes you are using a certificate signed by a “trusted CA” for the primary domain of your provider, but all other servers are assumed to use certs signed by the Server CA you create.

To generate a CSR, run:

leap cert csr
+leap cert csr [DOMAIN]
 
 
-This command will generate the CSR and private key matching provider.domain (you can change the domain with --domain=DOMAIN switch). It also generates a server certificate signed with the Server CA. You should delete this certificate and replace it with a real one once it is created by your commercial CA.
+This command will generate the CSR and private key matching provider.domain or use DOMAIN. It also generates a server certificate signed with the Server CA. You should delete this certificate and replace it with a real one you get back from a “trusted CA”.
 
 The related commercial cert files are:
 
 files/
   cert/
-    domain.org.crt    # Server certificate for domain.org, obtained by commercial CA.
-    domain.org.csr    # Certificate signing request
-    domain.org.key    # Private key for you certificate
-    commercial_ca.crt # The CA cert obtained from the commercial CA.
+    domain.org.crt    # Server certificate for domain.org, obtained from
+                      # the trusted CA (this file is initially signed with
+                      # the Server CA, but you should replace it).
+    domain.org.csr    # Certificate signing request (PEM format)
+    domain.org.key    # Private key for you certificate (PEM format)
+    commercial_ca.crt # DEPRECATED: The certificate chain obtained from
+                      # the trusted CA (PEM format)
 
 
 The private key file is extremely sensitive and care should be taken with its provenance.
 
-If your commercial CA has a chained CA cert, you should be OK if you just put the last cert in the chain into the commercial_ca.crt file. This only works if the other CAs in the chain have certs in the debian package ca-certificates, which is the case for almost all CAs.
+A few notes on the certificate chain:
+
+
+A certificate is basically just a key signed by another key. In x.509, the signing key might be signed by yet another key, and so on, all the way to a ‘root’ key. It is the root key that a browser trusts or is in the Debian ca-certificates package. The chain is the set of all the keys from the root to the end certificate.
+For TLS, both the server and the client need the full chain from the certificate to the CA’s root.
+The full chain should be appended in the file domain.org.crt after the server certificate. The chain can also live in commercial_ca.crt, but this is deprecated.
+
+
 
 If you want to add additional fields to the CSR, like country, city, or locality, you can configure these values in provider.json like so:
 
@@ -405,74 +412,38 @@ leap deploy
 $ leap inspect files/ca/ca.crt
 
 
-Let’s Encrypt certificate
-
-LEAP plans to integrate Let’s Encrypt support, so it will be even easier to receive X.509 certificates that are accepted by all browsers.
-Until we achieve this, here’s a guide how to do this manually.
-
-Install the official acme client
-
-Log in to your webapp node
-
-server$ git clone https://github.com/certbot/certbot
-server$ cd certbot
-server$ ./certbot-auto --help
-
-
-Fetch cert
-
-Stop apache so the letsencrypt client can bind to port 80:
-
-server$ systemctl stop apache2
-
-
-Fetch the certs
+Let’s Encrypt
 
-server$ ./certbot-auto certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d)
-
-
-This will put the certs and keys into /etc/letsencrypt/live/DOMAIN/.
+Let’s Encrypt is a free “trusted CA”. You can obtain signed certificates from Let’s Encrypt very easily using the LEAP command line, so long as you have first set up DNS correctly.
 
-Now, go to your workstation’s provider configuration directory and copy the newly created files from the server to your local config. You will override existing files so please make a backup before proceeding, or use a version control system to track changes.
-
-workstation$ cd PATH_TO_PROVIDER_CONFIG
-
+Creating a certificate
 
-Copy the Certificate
+For example:
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/cert.pem files/cert/dev.pixelated-project.org.crt
+workstation$ leap cert register
+workstation$ leap cert csr demo.bitmask.net
+workstation$ leap cert renew demo.bitmask.net
+workstation$ leap deploy
 
 
-Copy the private key
+Some notes:
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/privkey.pem files/cert/DOMAIN.key
-
-
-Copy the CA chain cert
+
+You only need to run leap cert register once. Registering will save the Let’s Encrypt account key to files/ca/lets-encrypt-account.key. If you delete this file, just run leap cert register again.
+Let’s Encrypt support requires that you have already platform 0.9 or later.
+This requires that the DNS records are correct for the domain.
+
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/fullchain.pem files/cert/commercial_ca.crt
-
 
-Deploy the certs
+Renewing a certificate
 
-Now you only need to deploy the certs
+Let’s Encrypt validations are short lived. You will need to renew the certificate at least once every three months. There is no harm in doing it more regularly, however. You can renew your cert every day if you wanted.
 
-workstation$ leap deploy
+workstation$ leap cert renew demo.bitmask.net
+workstation$ leap deploy
 
 
-This will put them into the right locations which are:
-
-
-/etc/x509/certs/leap_commercial.crt for the certificate
-/etc/x509/./keys/leap_commercial.key for the private key
-/usr/local/share/ca-certificates/leap_commercial_ca.crt for the CA chain cert.
-
-
-
-Start apache2 again
-
-server$ systemctl start apache2
-
+There is no need to create a new CSR: renewing will reuse the old private key and the old CSR. It is especially important to not create a new CSR if you have advertised public key pins using HPKP.
 
 
 
diff --git a/docs/en/guide/keys-and-certificates/index.html b/docs/en/guide/keys-and-certificates/index.html
index 4775de5a..016a03a7 100644
--- a/docs/en/guide/keys-and-certificates/index.html
+++ b/docs/en/guide/keys-and-certificates/index.html
@@ -165,7 +165,7 @@ Keys and Certificates - LEAP Platform Documentation
         Client certificates
       
       
-        Commercial certificates
+        Signed certificates
       
       
         Examine Certs
@@ -173,16 +173,13 @@ Keys and Certificates - LEAP Platform Documentation
     
   
   
-    Let’s Encrypt certificate
+    Let’s Encrypt
     
       
-        Install the official acme client
+        Creating a certificate
       
       
-        Fetch cert
-      
-      
-        Deploy the certs
+        Renewing a certificate
       
     
   
@@ -351,9 +348,9 @@ leap deploy
 
 There are two types of client certificates: limited and unlimited. A client using a limited cert will have its bandwidth limited to the rate specified by provider.service.bandwidth_limit (in Bytes per second). An unlimited cert is given to the user if they authenticate and the user’s service level matches one configured in provider.service.levels without bandwidth limits. Otherwise, the user is given a limited client cert.
 
-Commercial certificates
+Signed certificates
 
-We strongly recommend that you use a commercial signed server certificate for your primary domain (in other words, a certificate with a common name matching whatever you have configured for provider.domain). This provides several benefits:
+We strongly recommend that the primary domain for your provider has a certificate signed by a “trusted CA” (e.g. A Certificate Authority that is trusted by the web browsers and in the Debian ca-certificates package). This provides several benefits:
 
 
 When users visit your website, they don’t get a scary notice that something is wrong.
@@ -362,28 +359,38 @@ leap deploy
 
 
 
-The LEAP platform is designed so that it assumes you are using a commercial cert for the primary domain of your provider, but all other servers are assumed to use non-commercial certs signed by the Server CA you create.
+The LEAP platform is designed so that it assumes you are using a certificate signed by a “trusted CA” for the primary domain of your provider, but all other servers are assumed to use certs signed by the Server CA you create.
 
 To generate a CSR, run:
 
-leap cert csr
+leap cert csr [DOMAIN]
 
 
-This command will generate the CSR and private key matching provider.domain (you can change the domain with --domain=DOMAIN switch). It also generates a server certificate signed with the Server CA. You should delete this certificate and replace it with a real one once it is created by your commercial CA.
+This command will generate the CSR and private key matching provider.domain or use DOMAIN. It also generates a server certificate signed with the Server CA. You should delete this certificate and replace it with a real one you get back from a “trusted CA”.
 
 The related commercial cert files are:
 
 files/
   cert/
-    domain.org.crt    # Server certificate for domain.org, obtained by commercial CA.
-    domain.org.csr    # Certificate signing request
-    domain.org.key    # Private key for you certificate
-    commercial_ca.crt # The CA cert obtained from the commercial CA.
+    domain.org.crt    # Server certificate for domain.org, obtained from
+                      # the trusted CA (this file is initially signed with
+                      # the Server CA, but you should replace it).
+    domain.org.csr    # Certificate signing request (PEM format)
+    domain.org.key    # Private key for you certificate (PEM format)
+    commercial_ca.crt # DEPRECATED: The certificate chain obtained from
+                      # the trusted CA (PEM format)
 
 
 The private key file is extremely sensitive and care should be taken with its provenance.
 
-If your commercial CA has a chained CA cert, you should be OK if you just put the last cert in the chain into the commercial_ca.crt file. This only works if the other CAs in the chain have certs in the debian package ca-certificates, which is the case for almost all CAs.
+A few notes on the certificate chain:
+
+
+A certificate is basically just a key signed by another key. In x.509, the signing key might be signed by yet another key, and so on, all the way to a ‘root’ key. It is the root key that a browser trusts or is in the Debian ca-certificates package. The chain is the set of all the keys from the root to the end certificate.
+For TLS, both the server and the client need the full chain from the certificate to the CA’s root.
+The full chain should be appended in the file domain.org.crt after the server certificate. The chain can also live in commercial_ca.crt, but this is deprecated.
+
+
 
 If you want to add additional fields to the CSR, like country, city, or locality, you can configure these values in provider.json like so:
 
@@ -405,74 +412,38 @@ leap deploy
 $ leap inspect files/ca/ca.crt
 
 
-Let’s Encrypt certificate
-
-LEAP plans to integrate Let’s Encrypt support, so it will be even easier to receive X.509 certificates that are accepted by all browsers.
-Until we achieve this, here’s a guide how to do this manually.
-
-Install the official acme client
-
-Log in to your webapp node
-
-server$ git clone https://github.com/certbot/certbot
-server$ cd certbot
-server$ ./certbot-auto --help
-
-
-Fetch cert
-
-Stop apache so the letsencrypt client can bind to port 80:
-
-server$ systemctl stop apache2
-
-
-Fetch the certs
+Let’s Encrypt
 
-server$ ./certbot-auto certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d)
-
-
-This will put the certs and keys into /etc/letsencrypt/live/DOMAIN/.
+Let’s Encrypt is a free “trusted CA”. You can obtain signed certificates from Let’s Encrypt very easily using the LEAP command line, so long as you have first set up DNS correctly.
 
-Now, go to your workstation’s provider configuration directory and copy the newly created files from the server to your local config. You will override existing files so please make a backup before proceeding, or use a version control system to track changes.
-
-workstation$ cd PATH_TO_PROVIDER_CONFIG
-
+Creating a certificate
 
-Copy the Certificate
+For example:
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/cert.pem files/cert/dev.pixelated-project.org.crt
+workstation$ leap cert register
+workstation$ leap cert csr demo.bitmask.net
+workstation$ leap cert renew demo.bitmask.net
+workstation$ leap deploy
 
 
-Copy the private key
+Some notes:
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/privkey.pem files/cert/DOMAIN.key
-
-
-Copy the CA chain cert
+
+You only need to run leap cert register once. Registering will save the Let’s Encrypt account key to files/ca/lets-encrypt-account.key. If you delete this file, just run leap cert register again.
+Let’s Encrypt support requires that you have already platform 0.9 or later.
+This requires that the DNS records are correct for the domain.
+
 
-workstation$ scp root@SERVER:/etc/letsencrypt/live/DOMAIN/fullchain.pem files/cert/commercial_ca.crt
-
 
-Deploy the certs
+Renewing a certificate
 
-Now you only need to deploy the certs
+Let’s Encrypt validations are short lived. You will need to renew the certificate at least once every three months. There is no harm in doing it more regularly, however. You can renew your cert every day if you wanted.
 
-workstation$ leap deploy
+workstation$ leap cert renew demo.bitmask.net
+workstation$ leap deploy
 
 
-This will put them into the right locations which are:
-
-
-/etc/x509/certs/leap_commercial.crt for the certificate
-/etc/x509/./keys/leap_commercial.key for the private key
-/usr/local/share/ca-certificates/leap_commercial_ca.crt for the CA chain cert.
-
-
-
-Start apache2 again
-
-server$ systemctl start apache2
-
+There is no need to create a new CSR: renewing will reuse the old private key and the old CSR. It is especially important to not create a new CSR if you have advertised public key pins using HPKP.
 
 
 
-- 
cgit v1.2.3