diff options
Diffstat (limited to 'doc/guide')
| -rw-r--r-- | doc/guide/commands.md | 559 | ||||
| -rw-r--r-- | doc/guide/config.md | 360 | ||||
| -rw-r--r-- | doc/guide/domains.md | 129 | ||||
| -rw-r--r-- | doc/guide/en.haml | 4 | ||||
| -rw-r--r-- | doc/guide/environments.md | 75 | ||||
| -rw-r--r-- | doc/guide/getting-started.md | 145 | ||||
| -rw-r--r-- | doc/guide/keys-and-certificates.md | 272 | ||||
| -rw-r--r-- | doc/guide/miscellaneous.md | 14 | ||||
| -rw-r--r-- | doc/guide/nodes.md | 87 | ||||
| -rw-r--r-- | doc/guide/provider-configuration.md | 79 |
10 files changed, 0 insertions, 1724 deletions
diff --git a/doc/guide/commands.md b/doc/guide/commands.md deleted file mode 100644 index 2ddacb83..00000000 --- a/doc/guide/commands.md +++ /dev/null @@ -1,559 +0,0 @@ -@title = 'Command Line Reference' -@summary = 'A copy of leap --help' - -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 <node-filter> 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 - -Log in to the specified node with an interactive shell using mosh (requires node to have mosh.enabled set to true). - - - -**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 - -Log in to the specified node with an interactive shell. - - - -**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/doc/guide/config.md b/doc/guide/config.md deleted file mode 100644 index bcea26c4..00000000 --- a/doc/guide/config.md +++ /dev/null @@ -1,360 +0,0 @@ -@title = "Configuration Files" -@summary = "Understanding and editing the configuration files." - -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). - -<table class="table table-striped"> -<tr> - <td><code>Leapfile</code></td> - <td>If present, this file tells <code>leap</code> that the directory is a provider directory. This file is usually empty, but can contain global options.</td> -</tr> -<tr> - <td><code>~/.leaprc</code></td> - <td>Evaluated the same as Leapfile, but not committed to source control.</td> -</tr> -<tr> - <td><code>provider.json</code></td> - <td>Global options related to this provider. See [[provider-configuration]].</td> -</tr> -<tr> - <td><code>provider.ENVIRONMENT.json</code></td> - <td>Global options for the provider that are applied to only a single environment.</td> -</tr> -<tr> - <td><code>nodes/NAME.json</code></td> - <td>The configuration file for node called NAME.</td> -</tr> -<tr> - <td><code>common.json</code></td> - <td>All nodes inherit from this file. In other words, any options that appear in <code>common.json</code> will be added as default values to each node configuration, value that can be locally overridden.</td> -</tr> -<tr> - <td><code>services/SERVICE.json</code></td> - <td>The properties in this configuration file are applied to any node that includes SERVICE in its <code>services</code> property.</td> -</tr> -<tr> - <td><code>services/SERVICE.ENVIRONMENT.json</code></td> - <td>The properties in this configuration file are applied to any node that includes SERVICE in its services and has environment equal to ENVIRONMENT.</td> -</tr> -<tr> - <td><code>tags/TAG.json</code></td> - <td>The properties in this configuration file are applied to any node that has includes TAG in its <code>tags</code> property.</td> -</tr> -<tr> - <td><code>tags/TAG.ENVIRONMENT.json</code></td> - <td>The properties in this configuration file are applied to any node that has includes TAG in its <code>tags</code> property and has <code>environment</code> property equal to ENVIRONMENT.</td> -</tr> -<tr> - <td><code>secrets.json </code></td> - <td>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 <code>leap compile</code> or <code>leap deploy</code>. 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.</td> -</tr> -<tr> - <td><code>facts.json</code></td> - <td>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 <code>leap facts update</code> to periodically regenerate the facts.json file.</td> -</tr> -<tr> - <td><code>files/*</code></td> - <td>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 <code>files</code> directory.</td> -</tr> -<tr> - <td><code>users/USER/</code></td> - <td>A directory that stores the public keys of the sysadmin with name USER. This person will have root access to all the servers.</td> -</tr> -</table> - -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): - -1. common.json - - load defaults: `provider_base/common.json` - - load provider: `bitmask/common.json` -2. service "webapp" - - load defaults: `provider_base/services/webapp.json` - - load provider: `bitmask/services/webapp.json` -3. tag "production" - - load defaults: `provider_base/tags/production.json` - - load provider: `bitmask/tags/production.json` -4. tag "northwest-us" - - load: `bitmask/tags/northwest-us.json` -5. 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/doc/guide/domains.md b/doc/guide/domains.md deleted file mode 100644 index 914bce33..00000000 --- a/doc/guide/domains.md +++ /dev/null @@ -1,129 +0,0 @@ -@title = "Domains" -@summary = "How to handle domain names and integrating LEAP with existing services." -@toc = true - -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: - -1. You must configure `webapp.domain` for nodes with the `webapp` service. -2. 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: - -1. Modify the LEAP webapp so that it does not create users with the same name as users in the legacy system. -2. 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/doc/guide/en.haml b/doc/guide/en.haml deleted file mode 100644 index 61c24ea8..00000000 --- a/doc/guide/en.haml +++ /dev/null @@ -1,4 +0,0 @@ -- @nav_title = "Guide" -- @title = "Platform Guide" - -= child_summaries
\ No newline at end of file diff --git a/doc/guide/environments.md b/doc/guide/environments.md deleted file mode 100644 index 752e0608..00000000 --- a/doc/guide/environments.md +++ /dev/null @@ -1,75 +0,0 @@ -@title = "Working with environments" -@nav_title = "Environments" -@summary = "How to partition the nodes into separate environments." - -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 => https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html#_specifying_ranges]] 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.
\ No newline at end of file diff --git a/doc/guide/getting-started.md b/doc/guide/getting-started.md deleted file mode 100644 index 6236cba0..00000000 --- a/doc/guide/getting-started.md +++ /dev/null @@ -1,145 +0,0 @@ -@title = 'Getting Started' -@summary = 'An overview of the LEAP Platform' -@toc = true - - -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 [[commands]] 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 [[commands]] 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 [[config]] 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: - -1. **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](https://puppetlabs.com/puppet/puppet-open-source/) or [Chef](http://www.opscode.com/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/doc/guide/keys-and-certificates.md b/doc/guide/keys-and-certificates.md deleted file mode 100644 index a6862a6a..00000000 --- a/doc/guide/keys-and-certificates.md +++ /dev/null @@ -1,272 +0,0 @@ -@title = "Keys and Certificates" -@summary = "Working with SSH keys, secrets, and X.509 certificates." - -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: - -1. `known_hosts` is never updated with local node keys, since the SSH public key of a local node is different for each user. -2. `leap` entirely skips the checking of host keys when connecting with a local node. -3. `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: - -1. **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`. -2. **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. -3. **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: - -1. When users visit your website, they don't get a scary notice that something is wrong. -2. When a user runs the LEAP client, selecting your service provider will not cause a warning message. -3. 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](https://letsencrypt.org/) 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/letsencrypt/letsencrypt - server$ cd letsencrypt - server$ ./letsencrypt-auto --help - -Fetch cert ----------- - -Stop apache so the letsencrypt client can bind to port 80: - - server$ systemctl stop apache2 - -Fetch the certs - - server$ ./letsencrypt-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/DOMAIN.key - -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/doc/guide/miscellaneous.md b/doc/guide/miscellaneous.md deleted file mode 100644 index c38c007c..00000000 --- a/doc/guide/miscellaneous.md +++ /dev/null @@ -1,14 +0,0 @@ -@title = "Miscellaneous" -@summary = "Miscellaneous commands you may need to know." - -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/doc/guide/nodes.md b/doc/guide/nodes.md deleted file mode 100644 index 5135f3ba..00000000 --- a/doc/guide/nodes.md +++ /dev/null @@ -1,87 +0,0 @@ -@title = "Nodes" -@summary = "Working with nodes, services, tags, and locations." - -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](https://en.wikipedia.org/wiki/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](http://www.timeanddate.com/time/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/doc/guide/provider-configuration.md b/doc/guide/provider-configuration.md deleted file mode 100644 index 08cfd1dd..00000000 --- a/doc/guide/provider-configuration.md +++ /dev/null @@ -1,79 +0,0 @@ -@title = "Provider Configuration" -@summary = "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 |