diff options
| author | Micah Anderson <micah@riseup.net> | 2017-11-21 10:05:14 -0500 |
|---|---|---|
| committer | Micah Anderson <micah@riseup.net> | 2017-11-23 08:53:14 -0500 |
| commit | 87896a7d79ecfe06d2538e719061d6e75e1d7952 (patch) | |
| tree | c95d8f821b4230155b47dce4b205c7fc58d8b126 | |
| parent | b584e92a6b654eee9427cd56d7317aa0125c92a4 (diff) | |
Docs: Update docs to prepare for 0.10.0 release
Fixes: #8427, #8812
30 files changed, 549 insertions, 141 deletions
@@ -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 -------------------------------------- @@ -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 <li> <a href="keys-and-certificates/index.html#renewing-a-certificate">Renewing a certificate</a> </li> + <li> + <a href="keys-and-certificates/index.html#issues">Issues</a> + <ol> + <li> + <a href="keys-and-certificates/index.html#certs-already-expired">Certs already expired</a> + <ol> + <li> + <a href="keys-and-certificates/index.html#install-the-official-acme-client">Install the official acme client</a> + </li> + <li> + <a href="keys-and-certificates/index.html#fetch-cert">Fetch cert</a> + </li> + <li> + <a href="keys-and-certificates/index.html#deploy-the-certs">Deploy the certs</a> + </li> + </ol> + </li> + </ol> + </li> </ol> </li> </ol></div> @@ -445,6 +464,76 @@ workstation$ leap deploy <p>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.</p> +<h2><a name="issues"></a>Issues</h2> + +<h3><a name="certs-already-expired"></a>Certs already expired</h3> + +<p>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.</p> + +<h4><a name="install-the-official-acme-client"></a>Install the official acme client</h4> + +<p>Log in to your webapp node and install the <code>certbot</code> package:</p> + +<pre><code>server$ apt install -t jessie-backports certbot +</code></pre> + +<h4><a name="fetch-cert"></a>Fetch cert</h4> + +<p>Stop apache so the letsencrypt client can bind to port 80:</p> + +<pre><code>server$ systemctl stop apache2 +</code></pre> + +<p>Fetch the certs</p> + +<pre><code>server$ certbot certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d) +</code></pre> + +<p>This will put the certs and keys into <code>/etc/letsencrypt/live/DOMAIN/</code>.</p> + +<p>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.</p> + +<pre><code>workstation$ cd PATH_TO_PROVIDER_CONFIG +</code></pre> + +<p>Copy the Certificate</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/cert.pem' files/cert/DOMAIN.crt +</code></pre> + +<p>Copy the private key</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/privkey.pem' files/cert/DOMAIN.key +</code></pre> + +<p>Copy the CA chain cert</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/fullchain.pem' files/cert/commercial_ca.crt +</code></pre> + +<h4><a name="deploy-the-certs"></a>Deploy the certs</h4> + +<p>Now you only need to deploy the certs</p> + +<pre><code>workstation$ leap deploy +</code></pre> + +<p>This will put them into the right locations which are:</p> + +<ul> +<li><code>/etc/x509/certs/leap_commercial.crt</code> for the certificate</li> +<li><code>/etc/x509/./keys/leap_commercial.key</code> for the private key</li> +<li><code>/usr/local/share/ca-certificates/leap_commercial_ca.crt</code> for the CA chain cert.</li> +</ul> + + +<p>Start apache2 again</p> + +<pre><code>server$ systemctl start apache2 +</code></pre> + +<p>Done! In the future please make sure to always renew letsencrypt certificates before they expire ;).</p> + </div> </div> </body> 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 <li> <a href="index.html#renewing-a-certificate">Renewing a certificate</a> </li> + <li> + <a href="index.html#issues">Issues</a> + <ol> + <li> + <a href="index.html#certs-already-expired">Certs already expired</a> + <ol> + <li> + <a href="index.html#install-the-official-acme-client">Install the official acme client</a> + </li> + <li> + <a href="index.html#fetch-cert">Fetch cert</a> + </li> + <li> + <a href="index.html#deploy-the-certs">Deploy the certs</a> + </li> + </ol> + </li> + </ol> + </li> </ol> </li> </ol></div> @@ -445,6 +464,76 @@ workstation$ leap deploy <p>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.</p> +<h2><a name="issues"></a>Issues</h2> + +<h3><a name="certs-already-expired"></a>Certs already expired</h3> + +<p>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.</p> + +<h4><a name="install-the-official-acme-client"></a>Install the official acme client</h4> + +<p>Log in to your webapp node and install the <code>certbot</code> package:</p> + +<pre><code>server$ apt install -t jessie-backports certbot +</code></pre> + +<h4><a name="fetch-cert"></a>Fetch cert</h4> + +<p>Stop apache so the letsencrypt client can bind to port 80:</p> + +<pre><code>server$ systemctl stop apache2 +</code></pre> + +<p>Fetch the certs</p> + +<pre><code>server$ certbot certonly --standalone --email admin@$(hostname -d) -d $(hostname -d) -d api.$(hostname -d) -d $(hostname -f) -d nicknym.$(hostname -d) +</code></pre> + +<p>This will put the certs and keys into <code>/etc/letsencrypt/live/DOMAIN/</code>.</p> + +<p>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.</p> + +<pre><code>workstation$ cd PATH_TO_PROVIDER_CONFIG +</code></pre> + +<p>Copy the Certificate</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/cert.pem' files/cert/DOMAIN.crt +</code></pre> + +<p>Copy the private key</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/privkey.pem' files/cert/DOMAIN.key +</code></pre> + +<p>Copy the CA chain cert</p> + +<pre><code>workstation$ scp 'root@SERVER:/etc/letsencrypt/live/$(hostname -d)/fullchain.pem' files/cert/commercial_ca.crt +</code></pre> + +<h4><a name="deploy-the-certs"></a>Deploy the certs</h4> + +<p>Now you only need to deploy the certs</p> + +<pre><code>workstation$ leap deploy +</code></pre> + +<p>This will put them into the right locations which are:</p> + +<ul> +<li><code>/etc/x509/certs/leap_commercial.crt</code> for the certificate</li> +<li><code>/etc/x509/./keys/leap_commercial.key</code> for the private key</li> +<li><code>/usr/local/share/ca-certificates/leap_commercial_ca.crt</code> for the CA chain cert.</li> +</ul> + + +<p>Start apache2 again</p> + +<pre><code>server$ systemctl start apache2 +</code></pre> + +<p>Done! In the future please make sure to always renew letsencrypt certificates before they expire ;).</p> + </div> </div> </body> 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 <ul> <li><a href="https://aws.amazon.com/ec2/instance-types/">Available instance types for AWS</a></li> +<li><a href="https://aws.amazon.com/pt/blogs/security/wheres-my-secret-access-key/">Where’s My Secret Access Key?</a></li> </ul> @@ -245,6 +246,11 @@ leap vm start mynode <pre><code>leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small </code></pre> +<p>For an email provider installation, you should specify the following seeds:</p> + +<pre><code>leap vm add mynode services:webapp,couchdb,soledad,mx +</code></pre> + <p>Check to see what the status is of all VMs:</p> <pre><code>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 <ul> <li><a href="https://aws.amazon.com/ec2/instance-types/">Available instance types for AWS</a></li> +<li><a href="https://aws.amazon.com/pt/blogs/security/wheres-my-secret-access-key/">Where’s My Secret Access Key?</a></li> </ul> @@ -245,6 +246,11 @@ leap vm start mynode <pre><code>leap vm add mynode services:webapp tags:seattle vm.options.InstanceType:t2.small </code></pre> +<p>For an email provider installation, you should specify the following seeds:</p> + +<pre><code>leap vm add mynode services:webapp,couchdb,soledad,mx +</code></pre> + <p>Check to see what the status is of all VMs:</p> <pre><code>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 <h2> <a href='services/tor.html'>tor</a> </h2> -<div class='summary'>Tor exit node or hidden service</div> +<div class='summary'>Tor services: relay, exit node and hidden service</div> </div> <div class=' page-summary'> <h2> 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 <ul> <li>search for the “user_id” field</li> -<li>in this example <a href="mailto:testuser@example.org">testuser@example.org</a> uses the database user-665e004870ee17aa4c94331ff3cd59eb</li> +<li>in this example <a href="mailto:testuser@example.org">testuser@example.org</a> uses the database user-665e004870ee17aa4c94331ff3cd59eb</li> </ul> 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 <ul> <li>search for the “user_id” field</li> -<li>in this example <a href="mailto:testuser@example.org">testuser@example.org</a> uses the database user-665e004870ee17aa4c94331ff3cd59eb</li> +<li>in this example <a href="mailto:testuser@example.org">testuser@example.org</a> uses the database user-665e004870ee17aa4c94331ff3cd59eb</li> </ul> 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 <h2> <a href='tor.html'>tor</a> </h2> -<div class='summary'>Tor exit node or hidden service</div> +<div class='summary'>Tor services: relay, exit node and hidden service</div> </div> <div class=' page-summary'> <h2> 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 <ol> <li>alias lists: by specifying an array of destination addresses, as in the case of “flock”, the single email will get copied to each address.</li> -<li>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 “<a href="mailto:robin@bird.org">robin@bird.org</a>”.</li> -<li>virtual domains: by specifying the full domain, as in the case of “<a href="mailto:chickadee@avian.org">chickadee@avian.org</a>”, 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.</li> +<li>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 “<a href="mailto:robin@bird.org">robin@bird.org</a>”.</li> +<li>virtual domains: by specifying the full domain, as in the case of “<a href="mailto:chickadee@avian.org">chickadee@avian.org</a>”, 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.</li> <li>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.</li> </ol> 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 <ol> <li>alias lists: by specifying an array of destination addresses, as in the case of “flock”, the single email will get copied to each address.</li> -<li>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 “<a href="mailto:robin@bird.org">robin@bird.org</a>”.</li> -<li>virtual domains: by specifying the full domain, as in the case of “<a href="mailto:chickadee@avian.org">chickadee@avian.org</a>”, 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.</li> +<li>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 “<a href="mailto:robin@bird.org">robin@bird.org</a>”.</li> +<li>virtual domains: by specifying the full domain, as in the case of “<a href="mailto:chickadee@avian.org">chickadee@avian.org</a>”, 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.</li> <li>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.</li> </ol> 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 <p><em>Essential configuration</em></p> <ul> -<li><code>openvpn.gateway_address</code>: The address that OpenVPN daemon is bound to and that VPN clients connect to.</li> <li><code>ip_address</code>: The main IP of the server, and the egress address for outgoing traffic.</li> +<li><code>openvpn.gateway_address</code>: 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.</li> </ul> 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 <p><em>Essential configuration</em></p> <ul> -<li><code>openvpn.gateway_address</code>: The address that OpenVPN daemon is bound to and that VPN clients connect to.</li> <li><code>ip_address</code>: The main IP of the server, and the egress address for outgoing traffic.</li> +<li><code>openvpn.gateway_address</code>: 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.</li> </ul> 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 <div id='title-box'> <h1>tor</h1> -<div id='summary'>Tor exit node or hidden service</div> +<div id='summary'>Tor services: relay, exit node and hidden service</div> </div> <div id='content-box'> <div id="TOC"><ol> @@ -124,33 +124,53 @@ tor - LEAP Platform Documentation <h2><a name="topology"></a>Topology</h2> -<p>Nodes with <code>tor</code> service will run a Tor exit or hidden service, depending on what other service it is paired with:</p> +<p>Nodes with <code>tor</code> service will run a Tor relay with some pre-defined settings, which can be changed with some configuration (see <em>Configuration</em> below). You can enable an exit or a hidden service with additional configuration.</p> + +<h2><a name="configuration"></a>Configuration</h2> + +<p>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.</p> <ul> -<li><code>tor</code> + <code>openvpn</code>: when combined with <code>openvpn</code> nodes, <code>tor</code> 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.</li> -<li><code>tor</code> + <code>webapp</code>: when combined with a <code>webapp</code> node, the <code>tor</code> service will make the webapp and the API available via .onion hidden service.</li> -<li><code>tor</code> stand alone: a regular Tor exit node.</li> +<li><code>tor.bandwidth_rate</code>: the max bandwidth allocated to Tor, in KB per second, when used as an exit node (default: 6550 KB/sec).</li> +<li><code>tor.type</code>: what type of tor node to make, at this moment only ‘exit’ is supported. If not specified, acts as a relay.</li> +<li><code>tor.contacts</code>: the contact information for the relay (default: the list of provider contacts)</li> +<li><code>tor.nickname</code>: the nickname of the relay (default: a combination of the node name and a hash of the family)</li> +<li><code>tor.family</code>: a list of the other nicknames that are part of the same provider</li> +<li><code>tor.hidden_service</code>: to enable a hidden service, set ‘active’ to be true (see below for an example), do <em>not</em> configure “services”: [“tor”] for the node!</li> </ul> -<p>If activated, you can list the hidden service .onion addresses this way:</p> +<p>Examples:</p> -<p> leap ls –print tor.hidden_service.address tor</p> +<p>To add a relay to a node:</p> -<p>Then just add ‘.onion’ to the end of the printed addresses.</p> +<pre><code>{ + "services": ["tor"] +} +</code></pre> -<h2><a name="configuration"></a>Configuration</h2> +<p>To enable a hidden service, without a relay, do <em>not</em> 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: <a href="https://trac.torproject.org/8742">https://trac.torproject.org/8742</a>), instead configure the node to have the following:</p> -<ul> -<li><code>tor.bandwidth_rate</code>: the max bandwidth allocated to Tor, in KB per second, when used as an exit node.</li> -</ul> +<pre><code>{ + "tor": { + "hidden_service": { + "active": true + } +} +</code></pre> +<p>If activated, you can list the hidden service .onion addresses this way:</p> + +<p> leap ls –print tor.hidden_service.address tor</p> + +<p>Then just add ‘.onion’ to the end of the printed addresses.</p> -<p>For example:</p> +<p>To enable a Tor exit node:</p> <pre><code>{ "tor": { - "bandwidth_rate": 6550 + "bandwidth_rate": 6550, + "type": "exit" } } </code></pre> 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 <div id='title-box'> <h1>tor</h1> -<div id='summary'>Tor exit node or hidden service</div> +<div id='summary'>Tor services: relay, exit node and hidden service</div> </div> <div id='content-box'> <div id="TOC"><ol> @@ -124,33 +124,53 @@ tor - LEAP Platform Documentation <h2><a name="topology"></a>Topology</h2> -<p>Nodes with <code>tor</code> service will run a Tor exit or hidden service, depending on what other service it is paired with:</p> +<p>Nodes with <code>tor</code> service will run a Tor relay with some pre-defined settings, which can be changed with some configuration (see <em>Configuration</em> below). You can enable an exit or a hidden service with additional configuration.</p> + +<h2><a name="configuration"></a>Configuration</h2> + +<p>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.</p> <ul> -<li><code>tor</code> + <code>openvpn</code>: when combined with <code>openvpn</code> nodes, <code>tor</code> 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.</li> -<li><code>tor</code> + <code>webapp</code>: when combined with a <code>webapp</code> node, the <code>tor</code> service will make the webapp and the API available via .onion hidden service.</li> -<li><code>tor</code> stand alone: a regular Tor exit node.</li> +<li><code>tor.bandwidth_rate</code>: the max bandwidth allocated to Tor, in KB per second, when used as an exit node (default: 6550 KB/sec).</li> +<li><code>tor.type</code>: what type of tor node to make, at this moment only ‘exit’ is supported. If not specified, acts as a relay.</li> +<li><code>tor.contacts</code>: the contact information for the relay (default: the list of provider contacts)</li> +<li><code>tor.nickname</code>: the nickname of the relay (default: a combination of the node name and a hash of the family)</li> +<li><code>tor.family</code>: a list of the other nicknames that are part of the same provider</li> +<li><code>tor.hidden_service</code>: to enable a hidden service, set ‘active’ to be true (see below for an example), do <em>not</em> configure “services”: [“tor”] for the node!</li> </ul> -<p>If activated, you can list the hidden service .onion addresses this way:</p> +<p>Examples:</p> -<p> leap ls –print tor.hidden_service.address tor</p> +<p>To add a relay to a node:</p> -<p>Then just add ‘.onion’ to the end of the printed addresses.</p> +<pre><code>{ + "services": ["tor"] +} +</code></pre> -<h2><a name="configuration"></a>Configuration</h2> +<p>To enable a hidden service, without a relay, do <em>not</em> 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: <a href="https://trac.torproject.org/8742">https://trac.torproject.org/8742</a>), instead configure the node to have the following:</p> -<ul> -<li><code>tor.bandwidth_rate</code>: the max bandwidth allocated to Tor, in KB per second, when used as an exit node.</li> -</ul> +<pre><code>{ + "tor": { + "hidden_service": { + "active": true + } +} +</code></pre> +<p>If activated, you can list the hidden service .onion addresses this way:</p> + +<p> leap ls –print tor.hidden_service.address tor</p> + +<p>Then just add ‘.onion’ to the end of the printed addresses.</p> -<p>For example:</p> +<p>To enable a Tor exit node:</p> <pre><code>{ "tor": { - "bandwidth_rate": 6550 + "bandwidth_rate": 6550, + "type": "exit" } } </code></pre> 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 <p>It is not possible to actually use the EIP openvpn server on vagrant nodes (see: <a href="https://leap.se/code/issues/2401">https://leap.se/code/issues/2401</a>)</p> +<p>Proxmox virtualization isn’t supported because it wants to overwrite our resolv.conf (see: <a href="https://leap.se/code/issues/8683">https://leap.se/code/issues/8683</a>)</p> + </div> </div> </body> 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 <p>It is not possible to actually use the EIP openvpn server on vagrant nodes (see: <a href="https://leap.se/code/issues/2401">https://leap.se/code/issues/2401</a>)</p> +<p>Proxmox virtualization isn’t supported because it wants to overwrite our resolv.conf (see: <a href="https://leap.se/code/issues/8683">https://leap.se/code/issues/8683</a>)</p> + </div> </div> </body> 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 @@ -115,9 +115,6 @@ Where to look - LEAP Platform Documentation <a href="where-to-look/index.html#places-to-look-for-errors">Places to look for errors</a> </li> <li> - <a href="where-to-look/index.html#is-haproxy-ok">Is haproxy ok ?</a> - </li> - <li> <a href="where-to-look/index.html#is-couchdb-accessible-through-stunnel">Is couchdb accessible through stunnel ?</a> </li> <li> @@ -216,22 +213,10 @@ Where to look - LEAP Platform Documentation </ul> -<h2><a name="is-haproxy-ok"></a>Is haproxy ok ?</h2> - -<pre><code>curl -s -X GET "http://127.0.0.1:4096" -</code></pre> - <h2><a name="is-couchdb-accessible-through-stunnel"></a>Is couchdb accessible through stunnel ?</h2> -<ul> -<li><p>Depending on how many couch nodes you have, increase the port for every test -(see /etc/haproxy/haproxy.cfg for the server/port mapping):</p> - -<p> curl -s -X GET “<a href="http://127.0.0.1:4000">http://127.0.0.1:4000</a>” - curl -s -X GET “<a href="http://127.0.0.1:4001">http://127.0.0.1:4001</a>” - …</p></li> -</ul> - +<pre><code>curl -s -X GET "http://127.0.0.1:4000" +</code></pre> <h2><a name="check-couchdb-acl-as-admin"></a>Check couchdb acl as admin</h2> @@ -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" </code></pre> <h2><a name="check-couchdb-acl-as-unpriviledged-user"></a>Check couchdb acl as unpriviledged user</h2> @@ -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" </code></pre> <h2><a name="all-urls-accessible"></a>All URLs accessible ?</h2> @@ -350,15 +335,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1: <h2><a name="is-couchdb-accessible-through-stunnel-2"></a>Is couchdb accessible through stunnel ?</h2> -<ul> -<li><p>Depending on how many couch nodes you have, increase the port for every test -(see /etc/haproxy/haproxy.cfg for the server/port mapping):</p> - -<p> curl -s -X GET “<a href="http://127.0.0.1:4000">http://127.0.0.1:4000</a>” - curl -s -X GET “<a href="http://127.0.0.1:4001">http://127.0.0.1:4001</a>” - …</p></li> -</ul> - +<pre><code>curl -s -X GET "http://127.0.0.1:4000" +</code></pre> <h2><a name="query-leap-mx"></a>Query leap-mx</h2> @@ -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" </code></pre> -<ul> -<li>you may check multiple times, cause 127.0.0.1:4096 is haproxy load-balancing the different couchdb nodes</li> -</ul> - - <h2><a name="mailspool"></a>Mailspool</h2> <ul> diff --git a/docs/en/troubleshooting/where-to-look/index.html b/docs/en/troubleshooting/where-to-look/index.html index ab3115af..63d05e45 100644 --- a/docs/en/troubleshooting/where-to-look/index.html +++ b/docs/en/troubleshooting/where-to-look/index.html @@ -115,9 +115,6 @@ Where to look - LEAP Platform Documentation <a href="index.html#places-to-look-for-errors">Places to look for errors</a> </li> <li> - <a href="index.html#is-haproxy-ok">Is haproxy ok ?</a> - </li> - <li> <a href="index.html#is-couchdb-accessible-through-stunnel">Is couchdb accessible through stunnel ?</a> </li> <li> @@ -216,22 +213,10 @@ Where to look - LEAP Platform Documentation </ul> -<h2><a name="is-haproxy-ok"></a>Is haproxy ok ?</h2> - -<pre><code>curl -s -X GET "http://127.0.0.1:4096" -</code></pre> - <h2><a name="is-couchdb-accessible-through-stunnel"></a>Is couchdb accessible through stunnel ?</h2> -<ul> -<li><p>Depending on how many couch nodes you have, increase the port for every test -(see /etc/haproxy/haproxy.cfg for the server/port mapping):</p> - -<p> curl -s -X GET “<a href="http://127.0.0.1:4000">http://127.0.0.1:4000</a>” - curl -s -X GET “<a href="http://127.0.0.1:4001">http://127.0.0.1:4001</a>” - …</p></li> -</ul> - +<pre><code>curl -s -X GET "http://127.0.0.1:4000" +</code></pre> <h2><a name="check-couchdb-acl-as-admin"></a>Check couchdb acl as admin</h2> @@ -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" </code></pre> <h2><a name="check-couchdb-acl-as-unpriviledged-user"></a>Check couchdb acl as unpriviledged user</h2> @@ -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" </code></pre> <h2><a name="all-urls-accessible"></a>All URLs accessible ?</h2> @@ -350,15 +335,8 @@ curl -s --netrc-file /etc/couchdb/couchdb-webapp.netrc -X GET "http://127.0.0.1: <h2><a name="is-couchdb-accessible-through-stunnel-2"></a>Is couchdb accessible through stunnel ?</h2> -<ul> -<li><p>Depending on how many couch nodes you have, increase the port for every test -(see /etc/haproxy/haproxy.cfg for the server/port mapping):</p> - -<p> curl -s -X GET “<a href="http://127.0.0.1:4000">http://127.0.0.1:4000</a>” - curl -s -X GET “<a href="http://127.0.0.1:4001">http://127.0.0.1:4001</a>” - …</p></li> -</ul> - +<pre><code>curl -s -X GET "http://127.0.0.1:4000" +</code></pre> <h2><a name="query-leap-mx"></a>Query leap-mx</h2> @@ -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" </code></pre> -<ul> -<li>you may check multiple times, cause 127.0.0.1:4096 is haproxy load-balancing the different couchdb nodes</li> -</ul> - - <h2><a name="mailspool"></a>Mailspool</h2> <ul> diff --git a/docs/en/tutorials/quick-start.html b/docs/en/tutorials/quick-start.html index d2670b30..d275a321 100644 --- a/docs/en/tutorials/quick-start.html +++ b/docs/en/tutorials/quick-start.html @@ -123,6 +123,9 @@ Quick Start Tutorial - LEAP Platform Documentation <a href="quick-start/index.html#install-pre-requisites">Install pre-requisites</a> </li> <li> + <a href="quick-start/index.html#the-platform-recipes">The platform recipes</a> + </li> + <li> <a href="quick-start/index.html#install-the-leap-command-line-utility">Install the LEAP command-line utility</a> </li> </ol> @@ -139,6 +142,9 @@ Quick Start Tutorial - LEAP Platform Documentation <li> <a href="quick-start/index.html#option-b-add-a-local-node">Option B: Add a local node</a> </li> + <li> + <a href="quick-start/index.html#option-c-add-a-virtual-machine-in-the-cloud">Option C: Add a virtual machine in the cloud</a> + </li> </ol> </li> <li> @@ -197,7 +203,7 @@ Quick Start Tutorial - LEAP Platform Documentation <ol> <li>A local Vagrant virtual machine: a Vagrant machine can only be useful for testing.</li> -<li>A real or paravirtualized server: The server must have Debian Jessie installed, and you must be able to SSH into the machine as root. Paravirtualization includes KVM, Xen, OpenStack, Amazon, but not VirtualBox or OpenVZ.</li> +<li>A real or paravirtualized server: The server must have Debian Jessie installed, and you must be able to SSH into the machine as root. Paravirtualization includes KVM, Xen, OpenStack, Amazon, but not VirtualBox or OpenVZ. Proxmox has an known issue <a href="https://leap.se/code/issues/8683">when changing the resolver</a></li> </ol> </li> </ol> @@ -214,15 +220,20 @@ Quick Start Tutorial - LEAP Platform Documentation <h1><a name="prepare-your-workstation"></a>Prepare your workstation</h1> -<p>In order to be able to manage your servers, you need to install the <code>leap</code> command on your workstation:</p> +<p>In order to be able to manage your servers, you need to setup the LEAP Platform on your desktop. This consists of three parts: the platform recipes, the <code>leap</code> command, and your provider instance. We will go over these step-by-step below, you can find more details in the <a href="quick-start/platform.html">platform introduction</a>.</p> <h3><a name="install-pre-requisites"></a>Install pre-requisites</h3> <p>Install core prerequisites on your workstation.</p> -<p><em>Debian & Ubuntu</em></p> +<p><em>Debian Unstable (sid)</em></p> + +<pre><code>workstation$ sudo apt-get install git rsync openssh-client openssl zlib1g-dev +</code></pre> + +<p><em>Other Debian & Ubuntu</em></p> -<pre><code>workstation$ sudo apt-get install git ruby ruby-dev rsync openssh-client openssl rake make bzip2 +<pre><code>workstation$ sudo apt-get install git ruby ruby-dev rsync openssh-client openssl rake make bzip2 zlib1g-dev </code></pre> <p><em>Mac OS</em></p> @@ -231,9 +242,38 @@ Quick Start Tutorial - LEAP Platform Documentation workstation$ ruby-install ruby </code></pre> +<h3><a name="the-platform-recipes"></a>The platform recipes</h3> + +<p>The LEAP platform recipes are a set modules designed to work together to provide you everything you need to manage your provider. You typically do not need to modify these, but do need them available for deploying your provider.</p> + +<p>To obtain the platform recipes, simply clone the git repository, and then check out the most recent stable release branch:</p> + +<pre><code>workstation$ git clone -b version/0.9.x https://leap.se/git/leap_platform +</code></pre> + +<p>If you want to get the latest development branch (Beware: it could be unstable !) you could simply use the master branch instead by:</p> + +<pre><code>workstation$ git clone https://leap.se/git/leap_platform +</code></pre> + <h3><a name="install-the-leap-command-line-utility"></a>Install the LEAP command-line utility</h3> -<p>Install the <code>leap</code> command system-wide:</p> +<p>The <code>leap</code> <a href="quick-start/guide/commands.html">command line tool</a> is what you use to manage everything about your provider.</p> + +<p>Keep these rules in mind:</p> + +<ul> +<li><code>leap</code> is run on your workstation: The <code>leap</code> command is always run locally on your workstation, never on a server you are deploying to.</li> +<li><code>leap</code> is run from within a provider instance: The <code>leap</code> command requires that the current working directory is a valid provider instance, except when running <code>leap new</code> to create a new provider instance.</li> +</ul> + + +<p>If on Debian Unstable (sid), simply do this:</p> + +<pre><code>workstation$ sudo apt install leap-cli +</code></pre> + +<p>Otherwise, you will need to do this:</p> <pre><code>workstation$ sudo gem install leap_cli </code></pre> @@ -340,14 +380,18 @@ workstation$ leap cert csr <h3><a name="option-b-add-a-local-node"></a>Option B: Add a local node</h3> -<p>Create a node, with the services “webapp” and “couchdb”, and then start the local virtual machine:</p> +<p>Create a node, with the services “webapp”, “soledad” and “couchdb”, and then start the local virtual machine:</p> -<pre><code>workstation$ leap node add --local wildebeest services:webapp,couchdb +<pre><code>workstation$ leap node add --local wildebeest services:webapp,couchdb,soledad workstation$ leap local start wildebeest </code></pre> <p>It will take a while to download the Virtualbox base box and create the virtual machine.</p> +<h3><a name="option-c-add-a-virtual-machine-in-the-cloud"></a>Option C: Add a virtual machine in the cloud</h3> + +<p>In order to create a provider using the cloud, please follow this <a href="https://leap.se/en/docs/platform/guide/virtual-machines">instructions</a>.</p> + <h1><a name="deploy-your-provider"></a>Deploy your provider</h1> <h3><a name="initialize-the-node"></a>Initialize the node</h3> diff --git a/docs/en/tutorials/quick-start/guide/commands.html b/docs/en/tutorials/quick-start/guide/commands.html new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/docs/en/tutorials/quick-start/guide/commands.html diff --git a/docs/en/tutorials/quick-start/index.html b/docs/en/tutorials/quick-start/index.html index 27b21238..ae617e1b 100644 --- a/docs/en/tutorials/quick-start/index.html +++ b/docs/en/tutorials/quick-start/index.html @@ -123,6 +123,9 @@ Quick Start Tutorial - LEAP Platform Documentation <a href="index.html#install-pre-requisites">Install pre-requisites</a> </li> <li> + <a href="index.html#the-platform-recipes">The platform recipes</a> + </li> + <li> <a href="index.html#install-the-leap-command-line-utility">Install the LEAP command-line utility</a> </li> </ol> @@ -139,6 +142,9 @@ Quick Start Tutorial - LEAP Platform Documentation <li> <a href="index.html#option-b-add-a-local-node">Option B: Add a local node</a> </li> + <li> + <a href="index.html#option-c-add-a-virtual-machine-in-the-cloud">Option C: Add a virtual machine in the cloud</a> + </li> </ol> </li> <li> @@ -197,7 +203,7 @@ Quick Start Tutorial - LEAP Platform Documentation <ol> <li>A local Vagrant virtual machine: a Vagrant machine can only be useful for testing.</li> -<li>A real or paravirtualized server: The server must have Debian Jessie installed, and you must be able to SSH into the machine as root. Paravirtualization includes KVM, Xen, OpenStack, Amazon, but not VirtualBox or OpenVZ.</li> +<li>A real or paravirtualized server: The server must have Debian Jessie installed, and you must be able to SSH into the machine as root. Paravirtualization includes KVM, Xen, OpenStack, Amazon, but not VirtualBox or OpenVZ. Proxmox has an known issue <a href="https://leap.se/code/issues/8683">when changing the resolver</a></li> </ol> </li> </ol> @@ -214,15 +220,20 @@ Quick Start Tutorial - LEAP Platform Documentation <h1><a name="prepare-your-workstation"></a>Prepare your workstation</h1> -<p>In order to be able to manage your servers, you need to install the <code>leap</code> command on your workstation:</p> +<p>In order to be able to manage your servers, you need to setup the LEAP Platform on your desktop. This consists of three parts: the platform recipes, the <code>leap</code> command, and your provider instance. We will go over these step-by-step below, you can find more details in the <a href="platform.html">platform introduction</a>.</p> <h3><a name="install-pre-requisites"></a>Install pre-requisites</h3> <p>Install core prerequisites on your workstation.</p> -<p><em>Debian & Ubuntu</em></p> +<p><em>Debian Unstable (sid)</em></p> + +<pre><code>workstation$ sudo apt-get install git rsync openssh-client openssl zlib1g-dev +</code></pre> + +<p><em>Other Debian & Ubuntu</em></p> -<pre><code>workstation$ sudo apt-get install git ruby ruby-dev rsync openssh-client openssl rake make bzip2 +<pre><code>workstation$ sudo apt-get install git ruby ruby-dev rsync openssh-client openssl rake make bzip2 zlib1g-dev </code></pre> <p><em>Mac OS</em></p> @@ -231,9 +242,38 @@ Quick Start Tutorial - LEAP Platform Documentation workstation$ ruby-install ruby </code></pre> +<h3><a name="the-platform-recipes"></a>The platform recipes</h3> + +<p>The LEAP platform recipes are a set modules designed to work together to provide you everything you need to manage your provider. You typically do not need to modify these, but do need them available for deploying your provider.</p> + +<p>To obtain the platform recipes, simply clone the git repository, and then check out the most recent stable release branch:</p> + +<pre><code>workstation$ git clone -b version/0.9.x https://leap.se/git/leap_platform +</code></pre> + +<p>If you want to get the latest development branch (Beware: it could be unstable !) you could simply use the master branch instead by:</p> + +<pre><code>workstation$ git clone https://leap.se/git/leap_platform +</code></pre> + <h3><a name="install-the-leap-command-line-utility"></a>Install the LEAP command-line utility</h3> -<p>Install the <code>leap</code> command system-wide:</p> +<p>The <code>leap</code> <a href="guide/commands.html">command line tool</a> is what you use to manage everything about your provider.</p> + +<p>Keep these rules in mind:</p> + +<ul> +<li><code>leap</code> is run on your workstation: The <code>leap</code> command is always run locally on your workstation, never on a server you are deploying to.</li> +<li><code>leap</code> is run from within a provider instance: The <code>leap</code> command requires that the current working directory is a valid provider instance, except when running <code>leap new</code> to create a new provider instance.</li> +</ul> + + +<p>If on Debian Unstable (sid), simply do this:</p> + +<pre><code>workstation$ sudo apt install leap-cli +</code></pre> + +<p>Otherwise, you will need to do this:</p> <pre><code>workstation$ sudo gem install leap_cli </code></pre> @@ -340,14 +380,18 @@ workstation$ leap cert csr <h3><a name="option-b-add-a-local-node"></a>Option B: Add a local node</h3> -<p>Create a node, with the services “webapp” and “couchdb”, and then start the local virtual machine:</p> +<p>Create a node, with the services “webapp”, “soledad” and “couchdb”, and then start the local virtual machine:</p> -<pre><code>workstation$ leap node add --local wildebeest services:webapp,couchdb +<pre><code>workstation$ leap node add --local wildebeest services:webapp,couchdb,soledad workstation$ leap local start wildebeest </code></pre> <p>It will take a while to download the Virtualbox base box and create the virtual machine.</p> +<h3><a name="option-c-add-a-virtual-machine-in-the-cloud"></a>Option C: Add a virtual machine in the cloud</h3> + +<p>In order to create a provider using the cloud, please follow this <a href="https://leap.se/en/docs/platform/guide/virtual-machines">instructions</a>.</p> + <h1><a name="deploy-your-provider"></a>Deploy your provider</h1> <h3><a name="initialize-the-node"></a>Initialize the node</h3> diff --git a/docs/en/tutorials/quick-start/platform.html b/docs/en/tutorials/quick-start/platform.html new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/docs/en/tutorials/quick-start/platform.html diff --git a/docs/en/tutorials/single-node-email.html b/docs/en/tutorials/single-node-email.html index 6678fec3..d3372f91 100644 --- a/docs/en/tutorials/single-node-email.html +++ b/docs/en/tutorials/single-node-email.html @@ -144,11 +144,13 @@ Quick email - LEAP Platform Documentation <p>In our example, we would edit <code>nodes/wildebeest.json</code>:</p> <pre><code>{ - "ip_address": "1.1.1.1", + "ip_address": "XXX.XXX.XXX.XXX", "services": ["couchdb", "webapp", "mx", "soledad"] } </code></pre> +<p>Where “XXX.XXX.XXX.XXX” should be replaced by your IP provider.</p> + <p>Here, we added <code>mx</code> and <code>soledad</code> to the node’s <code>services</code> list. Briefly:</p> <ul> diff --git a/docs/en/tutorials/single-node-email/index.html b/docs/en/tutorials/single-node-email/index.html index 45a1264f..fd501790 100644 --- a/docs/en/tutorials/single-node-email/index.html +++ b/docs/en/tutorials/single-node-email/index.html @@ -144,11 +144,13 @@ Quick email - LEAP Platform Documentation <p>In our example, we would edit <code>nodes/wildebeest.json</code>:</p> <pre><code>{ - "ip_address": "1.1.1.1", + "ip_address": "XXX.XXX.XXX.XXX", "services": ["couchdb", "webapp", "mx", "soledad"] } </code></pre> +<p>Where “XXX.XXX.XXX.XXX” should be replaced by your IP provider.</p> + <p>Here, we added <code>mx</code> and <code>soledad</code> to the node’s <code>services</code> list. Briefly:</p> <ul> diff --git a/docs/en/tutorials/vagrant.html b/docs/en/tutorials/vagrant.html index 3d4f0520..e473ce82 100644 --- a/docs/en/tutorials/vagrant.html +++ b/docs/en/tutorials/vagrant.html @@ -437,12 +437,12 @@ $ leap local save web1 <p>Clone the platform with</p> -<pre><code>git clone --recursive -b develop https://github.com/leapcode/leap_platform.git +<pre><code>git clone https://leap.se/git/leap_platform </code></pre> <p>Start the vagrant box with</p> -<pre><code>cd leap_platform +<pre><code>cd leap_platform/tests/example-provider vagrant up </code></pre> @@ -531,7 +531,7 @@ started by the bitmask client:</p> sudo apt-get install ruby-dev libxslt-dev libxml2-dev libvirt-dev # install the required plugins -vagrant plugin install vagrant-libvirt fog fog-libvirt sahara +vagrant plugin install vagrant-libvirt sahara </code></pre> <p>Log out and then log back in.</p> @@ -585,8 +585,6 @@ virsh pool-autostart vagrant <li><code>Call to virConnectOpen failed: internal error: Unable to locate libvirtd daemon in /usr/sbin (to override, set $LIBVIRTD_PATH to the name of the libvirtd binary)</code> - you don’t have the libvirtd daemon running or installed, be sure you installed the ‘libvirt-bin’ package and it is running</li> <li><code>Call to virConnectOpen failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied</code> - you need to be in the libvirt group to access the socket, do ‘sudo adduser <user> libvirtd’ and then re-login to your session.</li> <li>if each call to vagrant ends up with a segfault, it may be because you still have virtualbox around. if so, remove virtualbox to keep only libvirt + KVM. according to <a href="https://github.com/pradels/vagrant-libvirt/issues/75">https://github.com/pradels/vagrant-libvirt/issues/75</a> having two virtualization engines installed simultaneously can lead to such weird issues.</li> -<li>see the <a href="https://github.com/pradels/vagrant-libvirt/issues">vagrant-libvirt issue list on github</a></li> -<li>be sure to use vagrant-libvirt >= 0.0.11 and sahara >= 0.0.16 (which are the latest stable gems you would get with <code>vagrant plugin install [vagrant-libvirt|sahara]</code>) for proper libvirt support,</li> </ul> diff --git a/docs/en/tutorials/vagrant/index.html b/docs/en/tutorials/vagrant/index.html index 95bd6b71..181a3ccf 100644 --- a/docs/en/tutorials/vagrant/index.html +++ b/docs/en/tutorials/vagrant/index.html @@ -437,12 +437,12 @@ $ leap local save web1 <p>Clone the platform with</p> -<pre><code>git clone --recursive -b develop https://github.com/leapcode/leap_platform.git +<pre><code>git clone https://leap.se/git/leap_platform </code></pre> <p>Start the vagrant box with</p> -<pre><code>cd leap_platform +<pre><code>cd leap_platform/tests/example-provider vagrant up </code></pre> @@ -531,7 +531,7 @@ started by the bitmask client:</p> sudo apt-get install ruby-dev libxslt-dev libxml2-dev libvirt-dev # install the required plugins -vagrant plugin install vagrant-libvirt fog fog-libvirt sahara +vagrant plugin install vagrant-libvirt sahara </code></pre> <p>Log out and then log back in.</p> @@ -585,8 +585,6 @@ virsh pool-autostart vagrant <li><code>Call to virConnectOpen failed: internal error: Unable to locate libvirtd daemon in /usr/sbin (to override, set $LIBVIRTD_PATH to the name of the libvirtd binary)</code> - you don’t have the libvirtd daemon running or installed, be sure you installed the ‘libvirt-bin’ package and it is running</li> <li><code>Call to virConnectOpen failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied</code> - you need to be in the libvirt group to access the socket, do ‘sudo adduser <user> libvirtd’ and then re-login to your session.</li> <li>if each call to vagrant ends up with a segfault, it may be because you still have virtualbox around. if so, remove virtualbox to keep only libvirt + KVM. according to <a href="https://github.com/pradels/vagrant-libvirt/issues/75">https://github.com/pradels/vagrant-libvirt/issues/75</a> having two virtualization engines installed simultaneously can lead to such weird issues.</li> -<li>see the <a href="https://github.com/pradels/vagrant-libvirt/issues">vagrant-libvirt issue list on github</a></li> -<li>be sure to use vagrant-libvirt >= 0.0.11 and sahara >= 0.0.16 (which are the latest stable gems you would get with <code>vagrant plugin install [vagrant-libvirt|sahara]</code>) for proper libvirt support,</li> </ul> diff --git a/provider_base/common.json b/provider_base/common.json index 7b412fe6..1052b8e1 100644 --- a/provider_base/common.json +++ b/provider_base/common.json @@ -72,12 +72,12 @@ "nickserver": { "type": "git", "source": "https://leap.se/git/nickserver", - "revision": "origin/version/0.10" + "revision": "tags/0.10.0" }, "platform": { "apt": { "basic": "http://deb.leap.se/platform", - "component": "master" + "component": "0.10" } }, "soledad": { @@ -88,7 +88,7 @@ "webapp": { "type": "git", "source": "https://leap.se/git/leap_web", - "revision": "origin/version/0.9" + "revision": "tags/0.9.2" } } } diff --git a/tests/platform-ci/ci-build.sh b/tests/platform-ci/ci-build.sh index b2958f7c..9bdf75fb 100755 --- a/tests/platform-ci/ci-build.sh +++ b/tests/platform-ci/ci-build.sh @@ -239,6 +239,9 @@ upgrade_test() { build_from_scratch 'couchdb,soledad,mx,webapp,tor,monitor' deploy leap_info + # In 0.9 leap info did not output apt sources, so we do it manually + # but can remove it for next release + cat /etc/apt/sources.list.d/* test # Checkout HEAD of current branch and re-deploy |