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 --- 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 +- 26 files changed, 406 insertions(+), 138 deletions(-) create mode 100644 docs/en/tutorials/quick-start/guide/commands.html create mode 100644 docs/en/tutorials/quick-start/platform.html (limited to 'docs') 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. +
      3. + Fetch cert +
      4. +
      5. + Deploy the certs +
      6. +
      +
    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. +
      3. + Fetch cert +
      4. +
      5. + Deploy the certs +
      6. +
      +
    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. -
    3. 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”.
    4. -
    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. +
    7. 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”.
    8. +
    9. 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.
    10. 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.
    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. -
    3. 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”.
    4. -
    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. +
    7. 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”.
    8. +
    9. 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.
    10. 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.
    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