From 87896a7d79ecfe06d2538e719061d6e75e1d7952 Mon Sep 17 00:00:00 2001 From: Micah Anderson Date: Tue, 21 Nov 2017 10:05:14 -0500 Subject: Docs: Update docs to prepare for 0.10.0 release Fixes: #8427, #8812 --- CHANGES.md | 130 ++++++++++++++++++++++ README.md | 7 ++ docs/en/guide/keys-and-certificates.html | 89 +++++++++++++++ docs/en/guide/keys-and-certificates/index.html | 89 +++++++++++++++ docs/en/guide/virtual-machines.html | 6 + docs/en/guide/virtual-machines/index.html | 6 + docs/en/services.html | 2 +- docs/en/services/couchdb.html | 2 +- docs/en/services/couchdb/index.html | 2 +- docs/en/services/index.html | 2 +- docs/en/services/mx.html | 4 +- docs/en/services/mx/index.html | 4 +- docs/en/services/openvpn.html | 2 +- docs/en/services/openvpn/index.html | 2 +- docs/en/services/tor.html | 48 +++++--- docs/en/services/tor/index.html | 48 +++++--- docs/en/troubleshooting/known-issues.html | 2 + docs/en/troubleshooting/known-issues/index.html | 2 + docs/en/troubleshooting/where-to-look.html | 47 ++------ docs/en/troubleshooting/where-to-look/index.html | 47 ++------ docs/en/tutorials/quick-start.html | 58 ++++++++-- docs/en/tutorials/quick-start/guide/commands.html | 0 docs/en/tutorials/quick-start/index.html | 58 ++++++++-- docs/en/tutorials/quick-start/platform.html | 0 docs/en/tutorials/single-node-email.html | 4 +- docs/en/tutorials/single-node-email/index.html | 4 +- docs/en/tutorials/vagrant.html | 8 +- docs/en/tutorials/vagrant/index.html | 8 +- provider_base/common.json | 6 +- tests/platform-ci/ci-build.sh | 3 + 30 files changed, 549 insertions(+), 141 deletions(-) create mode 100644 docs/en/tutorials/quick-start/guide/commands.html create mode 100644 docs/en/tutorials/quick-start/platform.html diff --git a/CHANGES.md b/CHANGES.md index 3dc66746..41317b48 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -1,3 +1,133 @@ +Platform 0.10 +------------------------------------------------ + +The main focus for Platform 0.10 was to update of all client-side daemons to +newest releases, like Soledad and OpenVPN. This introduces a *compatibility +change*: by setting the platform version to 0.10, it also requires client 0.9.4 +or later. We also switched the development branch to the 'master' branch and are +creating a branch called 0.10.x to push hot-fixes during the 0.10 life-cycle. + +Note: This will be the last major release of the LEAP Platform for Debian +Jessie. We will continue to support 0.10 with minor releases with important +security and bug fixes, but the next major release will require an upgrade to +Stretch. + +New Features: + +* Tor single-hop onion service capability. +* `leap info` is now run after deploy +* Timestamps are added to deployments +* Missing ssh host keys are generated on node init +* Private networking support for local Vagrant development +* Static sites get lets encrypt support +* add command `leap node disable`, `leap node enable`, `leap ping` + +Notable Changes: + +* Removed haproxy because we don't support multi-node couchdb installations anymore (#8144). +* Disable nagios notification emails (#8772). +* Fix layout of apt repository (#8888) +* Limit what archive signing keys are accepted for the leap debian repository packages (#8425). +* Monitor the Webapp logs for errors (#5174). +* Moved development to the master branch. +* Rewrite leap_cli ssh code +* Debian wheezy was fully deprecated +* Restructure package archives to enable auto packaging, and CI testing +* Significant CI improvements +* Troubleshooting information added to `leap user ls` +* Couchdb service is no longer required on soledad nodes (#8693) +* Tor service refactored (#8864), and v3 hidden service support added (#8879) +* Fixed unattended-upgrades (#8891) +* Alert on 409 responses for webapp +* Many other issues resolved, full list: https://0xacab.org/groups/leap/milestones/platform-010?title=Platform+0.10 + +Upgrading: + +If you have a node with the service 'tor' defined, you will need to change it to +be either 'tor-relay', or 'tor-exit'. Look in your provider directory under the +nodes directory for any .json file that has a 'services' section with 'tor' +defined, change that to the correct tor service you are wanting to deploy. + +Make sure you have the correct version of leap_cli + + workstation$ sudo gem install leap_cli --version=1.9 + +If you are upgrading from a version previous to 0.9, please follow those upgrade +instructions before upgrading to 0.10. + +Prepare your platform source by checking out the 0.10.x branch: + + workstation$ cd leap_platform + workstation$ git fetch + workstation$ git checkout 0.10.x + +Then, deploy: + + workstation$ cd $PROVIDER_DIR + workstation$ leap deploy + workstation$ leap test + +After deployment, if the leap test does not succeed, you should +investigate. Please see below for some post-deployment upgrade steps that you +may need to perform. + +Starting with Soledad Server 0.9.0, the CouchDB database schema was changed to +improve speed of the server side storage backend. If you provided email, you +will need to run the migration script, otherwise it is unnecessary. Until you +migrate, soledad will refuse to start. + +To run the migration script, do the following (replacing $PROVIDER_DIR, +$COUCHDB_NODE, $MX_NODE, and $SOLEDAD_NODE with your values): + +First backup your couchdb databases, just to be safe. NOTE: This can take some +time and will place several hundred megabytes of data into +/var/backups/couchdb. The size and time depends on how many users there are on +your system. For example, 15k users took approximately 25 minutes and 308M of +space: + + workstation$ leap ssh $COUCHDB_NODE + server# cd /srv/leap/couchdb/scripts + server# ./cleanup-user-dbs + server# time ./couchdb_dumpall.sh + + Once that has finished, then its time to run the migration: + + workstation$ cd $PROVIDER_DIR + workstation$ leap run 'systemctl leap_mx stop' $MX_NODE + workstation$ leap run --stream '/usr/share/soledad-server/migration/0.9/migrate.py --log-file /var/log/leap/soledad_migration --verbose --do-migrate' $SOLEDAD_NODE + wait for it to finish (will print DONE) + rerun if interrupted + workstation$ leap deploy + workstation$ leap test + +Known Issues: + +If you have been deploying from our master branch (ie: unstable code), you might +end up with a broken sources line for apt. If you get the following: + WARNING: The following packages cannot be authenticated! + +Then you should remove the files on your nodes inside +/var/lib/puppet/modules/apt/keys and deploy again. (#8862, #8876) + +* When upgrading, sometimes systemd does not report the correct state of a + daemon. The daemon will be not running, but systemd thinks it is. The symptom + of this is that a deploy will succeed but `leap test` will fail. To fix, you + can run `systemctl stop DAEMON` and then `systemctl start DAEMON` on the + affected host (systemctl restart seems to work less reliably). + +Includes: + +* leap_web: 0.9.2 +* nickserver: 0.10.0 +* leap-mx: 0.10.1 +* soledad-server: 0.10.5 + +Commits: https://0xacab.org/groups/leap/milestones/platform-010?title=Platform+0.10 + +For details on about all the changes included in this release please consult the +[LEAP platform 0.10 milestone](https://0xacab.org/leap/platform/milestones/7 ). + + Platform 0.9 -------------------------------------- diff --git a/README.md b/README.md index 6e5cb68d..06a4ea0c 100644 --- a/README.md +++ b/README.md @@ -37,6 +37,13 @@ For a live deployment of the platform, the number of servers that is required depends on your needs and which services you want to deploy. At the moment, the LEAP Platform supports servers with a base Debian Jessie installation. +Upgrading +============================= + +If you are upgrading from a previous version of the LEAP Platform, take special +care to follow the instructions detailed in the CHANGES.md to move from one +release to the next. + Troubleshooting ============================= diff --git a/docs/en/guide/keys-and-certificates.html b/docs/en/guide/keys-and-certificates.html index f5f83066..95c08cb9 100644 --- a/docs/en/guide/keys-and-certificates.html +++ b/docs/en/guide/keys-and-certificates.html @@ -181,6 +181,25 @@ Keys and Certificates - LEAP Platform Documentation
  • Renewing a certificate
    • +
  • + Issues +
      +
    1. + Certs already expired +
        +
      1. + Install the official acme client +
        2. +
      2. + Fetch cert +
        3. +
      3. + Deploy the certs +
        4. +
      +
      2. +
    +
    • @@ -445,6 +464,76 @@ workstation$ leap deploy

    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.

    +

    Issues

    + +

    Certs already expired

    + +

    When a cert is already expired, you can get into a possible deadlock situation on your servers which you can only resolve manually at the moment.

    + +

    Install the official acme client

    + +

    Log in to your webapp node and install the certbot package:

    + +
    server$ apt install -t jessie-backports certbot
+
    + +

    Fetch cert

    + +

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

    + +
    server$ systemctl stop apache2
+
    + +

    Fetch the certs

    + +
    server$ certbot 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/$(hostname -d)/cert.pem' files/cert/DOMAIN.crt
+
    + +

    Copy the private key

    + +
    workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/privkey.pem' files/cert/DOMAIN.key
+
    + +

    Copy the CA chain cert

    + +
    workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/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:

    + + + + +

    Start apache2 again

    + +
    server$ systemctl start apache2
+
    + +

    Done! In the future please make sure to always renew letsencrypt certificates before they expire ;).

    + diff --git a/docs/en/guide/keys-and-certificates/index.html b/docs/en/guide/keys-and-certificates/index.html index 016a03a7..95279270 100644 --- a/docs/en/guide/keys-and-certificates/index.html +++ b/docs/en/guide/keys-and-certificates/index.html @@ -181,6 +181,25 @@ Keys and Certificates - LEAP Platform Documentation
  • Renewing a certificate
    • +
  • + Issues +
      +
    1. + Certs already expired +
        +
      1. + Install the official acme client +
        2. +
      2. + Fetch cert +
        3. +
      3. + Deploy the certs +
        4. +
      +
      2. +
    +
    • @@ -445,6 +464,76 @@ workstation$ leap deploy

    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.

    +

    Issues

    + +

    Certs already expired

    + +

    When a cert is already expired, you can get into a possible deadlock situation on your servers which you can only resolve manually at the moment.

    + +

    Install the official acme client

    + +

    Log in to your webapp node and install the certbot package:

    + +
    server$ apt install -t jessie-backports certbot
+
    + +

    Fetch cert

    + +

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

    + +
    server$ systemctl stop apache2
+
    + +

    Fetch the certs

    + +
    server$ certbot 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/$(hostname -d)/cert.pem' files/cert/DOMAIN.crt
+
    + +

    Copy the private key

    + +
    workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/privkey.pem' files/cert/DOMAIN.key
+
    + +

    Copy the CA chain cert

    + +
    workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/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:

    + + + + +

    Start apache2 again

    + +
    server$ systemctl start apache2
+
    + +

    Done! In the future please make sure to always renew letsencrypt certificates before they expire ;).

    + diff --git a/docs/en/guide/virtual-machines.html b/docs/en/guide/virtual-machines.html index c522c181..28be3211 100644 --- a/docs/en/guide/virtual-machines.html +++ b/docs/en/guide/virtual-machines.html @@ -220,6 +220,7 @@ Virtual Machines - LEAP Platform Documentation @@ -245,6 +246,11 @@ leap vm start mynode 
    leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small
    +

    For an email provider installation, you should specify the following seeds:

    + +
    leap vm add mynode services:webapp,couchdb,soledad,mx
+
    +

    Check to see what the status is of all VMs:

    leap vm status
diff --git a/docs/en/guide/virtual-machines/index.html b/docs/en/guide/virtual-machines/index.html
index 4b2a2e0f..20d45a77 100644
--- a/docs/en/guide/virtual-machines/index.html
+++ b/docs/en/guide/virtual-machines/index.html
@@ -220,6 +220,7 @@ Virtual Machines - LEAP Platform Documentation
 
 
 
 
@@ -245,6 +246,11 @@ leap vm start mynode
 
    leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small
 
    
 
+
    For an email provider installation, you should specify the following seeds:
    
+
+
    leap vm add mynode services:webapp,couchdb,soledad,mx
+
    
+
 
    Check to see what the status is of all VMs:
    
 
 
    leap vm status
diff --git a/docs/en/services.html b/docs/en/services.html
index 55211e64..8237b3e4 100644
--- a/docs/en/services.html
+++ b/docs/en/services.html
@@ -235,7 +235,7 @@ Services - LEAP Platform Documentation
 
    
 tor
 
    
-
    Tor exit node or hidden service
    
+
    Tor services: relay, exit node and hidden service
    
 
 
    
 
    
diff --git a/docs/en/services/couchdb.html b/docs/en/services/couchdb.html
index de50a692..43f7cfac 100644
--- a/docs/en/services/couchdb.html
+++ b/docs/en/services/couchdb.html
@@ -215,7 +215,7 @@ couchdb - LEAP Platform Documentation
 
 
      
 
    • search for the “user_id” field
      • 
-
    • in this example testuser@example.org uses the database user-665e004870ee17aa4c94331ff3cd59eb
      • 
+
    • in this example testuser@example.org uses the database user-665e004870ee17aa4c94331ff3cd59eb
      • 
 
    
 
 
diff --git a/docs/en/services/couchdb/index.html b/docs/en/services/couchdb/index.html
index 9eb7fcb8..b48c4eb7 100644
--- a/docs/en/services/couchdb/index.html
+++ b/docs/en/services/couchdb/index.html
@@ -215,7 +215,7 @@ couchdb - LEAP Platform Documentation
 
 
      
 
    • search for the “user_id” field
      • 
-
    • in this example testuser@example.org uses the database user-665e004870ee17aa4c94331ff3cd59eb
      • 
+
    • in this example testuser@example.org uses the database user-665e004870ee17aa4c94331ff3cd59eb
      • 
 
    
 
 
diff --git a/docs/en/services/index.html b/docs/en/services/index.html
index 6d5c68e1..261cd11b 100644
--- a/docs/en/services/index.html
+++ b/docs/en/services/index.html
@@ -235,7 +235,7 @@ Services - LEAP Platform Documentation
 
    
 tor
 
    
-
    Tor exit node or hidden service
    
+
    Tor services: relay, exit node and hidden service
    
 
    
 
    
 
    
diff --git a/docs/en/services/mx.html b/docs/en/services/mx.html
index 8f5a36da..aa41186a 100644
--- a/docs/en/services/mx.html
+++ b/docs/en/services/mx.html
@@ -156,8 +156,8 @@ mx - LEAP Platform Documentation
 
 
      
 
    1. alias lists: by specifying an array of destination addresses, as in the case of “flock”, the single email will get copied to each address.
      2. 
-
    2. chained resolution: alias resolution will recursively continue until there are no more matching aliases. For example, “flock” is resolved to “robin”, which then gets resolved to “robin@bird.org”.
      3. 
-
    3. virtual domains: by specifying the full domain, as in the case of “chickadee@avian.org”, the alias will work for any domain you want. Of course, the MX record for that domain must point to appropriate MX servers, but otherwise you don’t need to do any additional configuration.
      4. 
+
    4. chained resolution: alias resolution will recursively continue until there are no more matching aliases. For example, “flock” is resolved to “robin”, which then gets resolved to “robin@bird.org”.
      5. 
+
    5. virtual domains: by specifying the full domain, as in the case of “chickadee@avian.org”, the alias will work for any domain you want. Of course, the MX record for that domain must point to appropriate MX servers, but otherwise you don’t need to do any additional configuration.
      6. 
 
    6. local delivery: for testing purposes, it is often useful to copy all incoming mail for a particular address and send those copies to another address. You can do this by adding “@deliver.local” as one of the destination addresses. When “@local.delivery” is found, alias resolution stops and the mail is delivered to that username.
      7. 
 
    
 
diff --git a/docs/en/services/mx/index.html b/docs/en/services/mx/index.html
index e8e06e80..048f5198 100644
--- a/docs/en/services/mx/index.html
+++ b/docs/en/services/mx/index.html
@@ -156,8 +156,8 @@ mx - LEAP Platform Documentation
 
 
      
 
    1. alias lists: by specifying an array of destination addresses, as in the case of “flock”, the single email will get copied to each address.
      2. 
-
    2. chained resolution: alias resolution will recursively continue until there are no more matching aliases. For example, “flock” is resolved to “robin”, which then gets resolved to “robin@bird.org”.
      3. 
-
    3. virtual domains: by specifying the full domain, as in the case of “chickadee@avian.org”, the alias will work for any domain you want. Of course, the MX record for that domain must point to appropriate MX servers, but otherwise you don’t need to do any additional configuration.
      4. 
+
    4. chained resolution: alias resolution will recursively continue until there are no more matching aliases. For example, “flock” is resolved to “robin”, which then gets resolved to “robin@bird.org”.
      5. 
+
    5. virtual domains: by specifying the full domain, as in the case of “chickadee@avian.org”, the alias will work for any domain you want. Of course, the MX record for that domain must point to appropriate MX servers, but otherwise you don’t need to do any additional configuration.
      6. 
 
    6. local delivery: for testing purposes, it is often useful to copy all incoming mail for a particular address and send those copies to another address. You can do this by adding “@deliver.local” as one of the destination addresses. When “@local.delivery” is found, alias resolution stops and the mail is delivered to that username.
      7. 
 
    
 
diff --git a/docs/en/services/openvpn.html b/docs/en/services/openvpn.html
index e5fe1128..1a420e21 100644
--- a/docs/en/services/openvpn.html
+++ b/docs/en/services/openvpn.html
@@ -133,8 +133,8 @@ openvpn - LEAP Platform Documentation
 
    Essential configuration
    
 
 
      
-
    • openvpn.gateway_address: The address that OpenVPN daemon is bound to and that VPN clients connect to.
      • 
 
    • ip_address: The main IP of the server, and the egress address for outgoing traffic.
      • 
+
    • openvpn.gateway_address: A secondary address on the same machine (sharing the same interface, or on a separate interface). The OpenVPN daemon is bound to this address and VPN clients connect to it.
      • 
 
    
 
 
diff --git a/docs/en/services/openvpn/index.html b/docs/en/services/openvpn/index.html
index 4a9dc993..23866436 100644
--- a/docs/en/services/openvpn/index.html
+++ b/docs/en/services/openvpn/index.html
@@ -133,8 +133,8 @@ openvpn - LEAP Platform Documentation
 
    Essential configuration
    
 
 
      
-
    • openvpn.gateway_address: The address that OpenVPN daemon is bound to and that VPN clients connect to.
      • 
 
    • ip_address: The main IP of the server, and the egress address for outgoing traffic.
      • 
+
    • openvpn.gateway_address: A secondary address on the same machine (sharing the same interface, or on a separate interface). The OpenVPN daemon is bound to this address and VPN clients connect to it.
      • 
 
    
 
 
diff --git a/docs/en/services/tor.html b/docs/en/services/tor.html
index f649c086..1f6ce112 100644
--- a/docs/en/services/tor.html
+++ b/docs/en/services/tor.html
@@ -110,7 +110,7 @@ tor - LEAP Platform Documentation
 
    
 
    tor
    
 
-
    Tor exit node or hidden service
    
+
    Tor services: relay, exit node and hidden service
    
 
    
 
    
 
      
@@ -124,33 +124,53 @@ tor - LEAP Platform Documentation
 
 
      Topology
      
 
-
      Nodes with tor service will run a Tor exit or hidden service, depending on what other service it is paired with:
      
+
      Nodes with tor service will run a Tor relay with some pre-defined settings, which can be changed with some configuration (see Configuration below). You can enable an exit or a hidden service with additional configuration.
      
+
+
      Configuration
      
+
+
      By default, if a node has service ‘tor’ configured, it will run a tor relay (not an exit). The relay will be configured with bandwidth limitations, contacts, a nickname and a family. The defaults for these (shown below), can be overridden as desired.
      
 
 
        
-
      • tor + openvpn: when combined with openvpn nodes, tor will create a Tor exit node to provide extra cover traffic for the VPN. This can be especially useful if there are VPN gateways without much traffic.
        • 
-
      • tor + webapp: when combined with a webapp node, the tor service will make the webapp and the API available via .onion hidden service.
        • 
-
      • tor stand alone: a regular Tor exit node.
        • 
+
      • tor.bandwidth_rate: the max bandwidth allocated to Tor, in KB per second, when used as an exit node (default: 6550 KB/sec).
        • 
+
      • tor.type: what type of tor node to make, at this moment only ‘exit’ is supported. If not specified, acts as a relay.
        • 
+
      • tor.contacts: the contact information for the relay (default: the list of provider contacts)
        • 
+
      • tor.nickname: the nickname of the relay (default: a combination of the node name and a hash of the family)
        • 
+
      • tor.family: a list of the other nicknames that are part of the same provider
        • 
+
      • tor.hidden_service: to enable a hidden service, set ‘active’ to be true (see below for an example), do not configure “services”: [“tor”] for the node!
        • 
 
      
 
 
-
      If activated, you can list the hidden service .onion addresses this way:
      
+
      Examples:
      
 
-
         leap ls –print tor.hidden_service.address tor
      
+
      To add a relay to a node:
      
 
-
      Then just add ‘.onion’ to the end of the printed addresses.
      
+
      { 
+ "services": ["tor"]
+}
+
      
 
-
      Configuration
      
+
      To enable a hidden service, without a relay, do not specify the tor service (it is not considered secure to have a node configured as a relay and a hidden service at the same time, see: https://trac.torproject.org/8742), instead configure the node to have the following:
      
 
-
        
-
      • tor.bandwidth_rate: the max bandwidth allocated to Tor, in KB per second, when used as an exit node.
        • 
-
      
+
      {
+  "tor": {
+    "hidden_service": {
+    "active": true
+  }
+}
+
      
 
+
      If activated, you can list the hidden service .onion addresses this way:
      
+
+
         leap ls –print tor.hidden_service.address tor
      
+
+
      Then just add ‘.onion’ to the end of the printed addresses.
      
 
-
      For example:
      
+
      To enable a Tor exit node:
      
 
 
      {
   "tor": {
-    "bandwidth_rate": 6550
+    "bandwidth_rate": 6550,
+    "type": "exit"
   }
 }
 
      
diff --git a/docs/en/services/tor/index.html b/docs/en/services/tor/index.html
index 8fecf152..a6380d90 100644
--- a/docs/en/services/tor/index.html
+++ b/docs/en/services/tor/index.html
@@ -110,7 +110,7 @@ tor - LEAP Platform Documentation
 
      
 
      tor
      
 
-
      Tor exit node or hidden service
      
+
      Tor services: relay, exit node and hidden service
      
 
      
 
      
 
        
@@ -124,33 +124,53 @@ tor - LEAP Platform Documentation
 
 
        Topology
        
 
-
        Nodes with tor service will run a Tor exit or hidden service, depending on what other service it is paired with:
        
+
        Nodes with tor service will run a Tor relay with some pre-defined settings, which can be changed with some configuration (see Configuration below). You can enable an exit or a hidden service with additional configuration.
        
+
+
        Configuration
        
+
+
        By default, if a node has service ‘tor’ configured, it will run a tor relay (not an exit). The relay will be configured with bandwidth limitations, contacts, a nickname and a family. The defaults for these (shown below), can be overridden as desired.
        
 
 
          
-
        • tor + openvpn: when combined with openvpn nodes, tor will create a Tor exit node to provide extra cover traffic for the VPN. This can be especially useful if there are VPN gateways without much traffic.
          • 
-
        • tor + webapp: when combined with a webapp node, the tor service will make the webapp and the API available via .onion hidden service.
          • 
-
        • tor stand alone: a regular Tor exit node.
          • 
+
        • tor.bandwidth_rate: the max bandwidth allocated to Tor, in KB per second, when used as an exit node (default: 6550 KB/sec).
          • 
+
        • tor.type: what type of tor node to make, at this moment only ‘exit’ is supported. If not specified, acts as a relay.
          • 
+
        • tor.contacts: the contact information for the relay (default: the list of provider contacts)
          • 
+
        • tor.nickname: the nickname of the relay (default: a combination of the node name and a hash of the family)
          • 
+
        • tor.family: a list of the other nicknames that are part of the same provider
          • 
+
        • tor.hidden_service: to enable a hidden service, set ‘active’ to be true (see below for an example), do not configure “services”: [“tor”] for the node!
          • 
 
        
 
 
-
        If activated, you can list the hidden service .onion addresses this way:
        
+
        Examples:
        
 
-
           leap ls –print tor.hidden_service.address tor
        
+
        To add a relay to a node:
        
 
-
        Then just add ‘.onion’ to the end of the printed addresses.
        
+
        { 
+ "services": ["tor"]
+}
+
        
 
-
        Configuration
        
+
        To enable a hidden service, without a relay, do not specify the tor service (it is not considered secure to have a node configured as a relay and a hidden service at the same time, see: https://trac.torproject.org/8742), instead configure the node to have the following:
        
 
-
          
-
        • tor.bandwidth_rate: the max bandwidth allocated to Tor, in KB per second, when used as an exit node.
          • 
-
        
+
        {
+  "tor": {
+    "hidden_service": {
+    "active": true
+  }
+}
+
        
 
+
        If activated, you can list the hidden service .onion addresses this way:
        
+
+
           leap ls –print tor.hidden_service.address tor
        
+
+
        Then just add ‘.onion’ to the end of the printed addresses.
        
 
-
        For example:
        
+
        To enable a Tor exit node:
        
 
 
        {
   "tor": {
-    "bandwidth_rate": 6550
+    "bandwidth_rate": 6550,
+    "type": "exit"
   }
 }
 
        
diff --git a/docs/en/troubleshooting/known-issues.html b/docs/en/troubleshooting/known-issues.html
index 607970b1..72c64f96 100644
--- a/docs/en/troubleshooting/known-issues.html
+++ b/docs/en/troubleshooting/known-issues.html
@@ -232,6 +232,8 @@ users/userx/otherkey_ssh.pub
 
 
        It is not possible to actually use the EIP openvpn server on vagrant nodes (see: https://leap.se/code/issues/2401)
        
 
+
        Proxmox virtualization isn’t supported because it wants to overwrite our resolv.conf (see: https://leap.se/code/issues/8683)
        
+
 
      
 
      
 
diff --git a/docs/en/troubleshooting/known-issues/index.html b/docs/en/troubleshooting/known-issues/index.html
index eee3b120..3d3d05a8 100644
--- a/docs/en/troubleshooting/known-issues/index.html
+++ b/docs/en/troubleshooting/known-issues/index.html
@@ -232,6 +232,8 @@ users/userx/otherkey_ssh.pub
 
 
      It is not possible to actually use the EIP openvpn server on vagrant nodes (see: https://leap.se/code/issues/2401)
      
 
+
      Proxmox virtualization isn’t supported because it wants to overwrite our resolv.conf (see: https://leap.se/code/issues/8683)
      
+
 
    
 
    
 
diff --git a/docs/en/troubleshooting/where-to-look.html b/docs/en/troubleshooting/where-to-look.html
index a1207aca..93cbbe97 100644
--- a/docs/en/troubleshooting/where-to-look.html
+++ b/docs/en/troubleshooting/where-to-look.html
@@ -114,9 +114,6 @@ Where to look - LEAP Platform Documentation
       
  • 
         Places to look for errors
       
    • 
-      
  • 
-        Is haproxy ok ?
-      
    • 
       
  • 
         Is couchdb accessible through stunnel ?
       
    • 
@@ -216,22 +213,10 @@ Where to look - LEAP Platform Documentation
 
 
 
-
    Is haproxy ok ?
    
-
-
    curl -s -X  GET "http://127.0.0.1:4096"
-
    
-
 
    Is couchdb accessible through stunnel ?
    
 
-
      
-
    • Depending on how many couch nodes you have, increase the port for every test
-(see /etc/haproxy/haproxy.cfg for the server/port mapping):
      
-
-
        curl -s -X  GET “http://127.0.0.1:4000”
-  curl -s -X  GET “http://127.0.0.1:4001”
-  …
      • 
-
    
-
+
    curl -s -X  GET "http://127.0.0.1:4000"
+
    
 
 
    Check couchdb acl as admin
    
 
@@ -240,8 +225,8 @@ cat /srv/leap/webapp/config/couchdb.yml.admin  # see username and password
 echo "machine 127.0.0.1 login admin password <PASSWORD>" > /etc/couchdb/couchdb-admin.netrc
 chmod 600 /etc/couchdb/couchdb-admin.netrc
 
-curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4096"
-curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4096/_all_dbs"
+curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4000"
+curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4000/_all_dbs"
 
    
 
 
    Check couchdb acl as unpriviledged user
    
@@ -250,8 +235,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4
 echo "machine 127.0.0.1 login webapp password <PASSWORD>" > /etc/couchdb/couchdb-webapp.netrc
 chmod 600 /etc/couchdb/couchdb-webapp.netrc
 
-curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4096"
-curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4096/_all_dbs"
+curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4000"
+curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4000/_all_dbs"

    All URLs accessible ?

    @@ -350,15 +335,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:

    Is couchdb accessible through stunnel ?

    - - +
    curl -s -X  GET "http://127.0.0.1:4000"
+

    Query leap-mx

    @@ -398,15 +376,10 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1: echo "machine 127.0.0.1 login leap_mx password <PASSWORD>" > /etc/couchdb/couchdb-leap_mx.netrc chmod 600 /etc/couchdb/couchdb-leap_mx.netrc -curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4096/_all_dbs" # pick one "user-<hash>" db -curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4096/user-de9c77a3d7efbc779c6c20da88e8fb9c" +curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4000/_all_dbs" # pick one "user-<hash>" db +curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4000/user-de9c77a3d7efbc779c6c20da88e8fb9c" - - -

    Mailspool

    -

    Is haproxy ok ?

    - -
    curl -s -X  GET "http://127.0.0.1:4096"
-
    -

    Is couchdb accessible through stunnel ?

    - - +
    curl -s -X  GET "http://127.0.0.1:4000"
+

    Check couchdb acl as admin

    @@ -240,8 +225,8 @@ cat /srv/leap/webapp/config/couchdb.yml.admin # see username and password echo "machine 127.0.0.1 login admin password <PASSWORD>" > /etc/couchdb/couchdb-admin.netrc chmod 600 /etc/couchdb/couchdb-admin.netrc -curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4096" -curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4096/_all_dbs" +curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4000" +curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4000/_all_dbs"

    Check couchdb acl as unpriviledged user

    @@ -250,8 +235,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-admin.netrc -X GET "http://127.0.0.1:4 echo "machine 127.0.0.1 login webapp password <PASSWORD>" > /etc/couchdb/couchdb-webapp.netrc chmod 600 /etc/couchdb/couchdb-webapp.netrc -curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4096" -curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4096/_all_dbs" +curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4000" +curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:4000/_all_dbs"

    All URLs accessible ?

    @@ -350,15 +335,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1:

    Is couchdb accessible through stunnel ?

    - - +
    curl -s -X  GET "http://127.0.0.1:4000"
+

    Query leap-mx

    @@ -398,15 +376,10 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1: echo "machine 127.0.0.1 login leap_mx password <PASSWORD>" > /etc/couchdb/couchdb-leap_mx.netrc chmod 600 /etc/couchdb/couchdb-leap_mx.netrc -curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4096/_all_dbs" # pick one "user-<hash>" db -curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4096/user-de9c77a3d7efbc779c6c20da88e8fb9c" +curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4000/_all_dbs" # pick one "user-<hash>" db +curl -s --netrc-file /etc/couchdb/couchdb-leap_mx.netrc -X GET "http://127.0.0.1:4000/user-de9c77a3d7efbc779c6c20da88e8fb9c" - - -

    Mailspool