diff options
Diffstat (limited to 'docs/en/services')
| -rw-r--r-- | docs/en/services/couchdb.html | 2 | ||||
| -rw-r--r-- | docs/en/services/couchdb/index.html | 2 | ||||
| -rw-r--r-- | docs/en/services/mx.html | 4 | ||||
| -rw-r--r-- | docs/en/services/mx/index.html | 4 | ||||
| -rw-r--r-- | docs/en/services/tor.html | 2 | ||||
| -rw-r--r-- | docs/en/services/tor/index.html | 2 | ||||
| -rw-r--r-- | docs/en/services/webapp.html | 38 | ||||
| -rw-r--r-- | docs/en/services/webapp/index.html | 38 |
8 files changed, 50 insertions, 42 deletions
diff --git a/docs/en/services/couchdb.html b/docs/en/services/couchdb.html index 43f7cfac..3b79fa22 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 b48c4eb7..6fc4b03d 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/mx.html b/docs/en/services/mx.html index aa41186a..6a690a4a 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 048f5198..3fed61b4 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/tor.html b/docs/en/services/tor.html index 1f6ce112..bdd88514 100644 --- a/docs/en/services/tor.html +++ b/docs/en/services/tor.html @@ -144,7 +144,7 @@ tor - LEAP Platform Documentation <p>To add a relay to a node:</p> -<pre><code>{ +<pre><code>{ "services": ["tor"] } </code></pre> diff --git a/docs/en/services/tor/index.html b/docs/en/services/tor/index.html index a6380d90..0ae2ab30 100644 --- a/docs/en/services/tor/index.html +++ b/docs/en/services/tor/index.html @@ -144,7 +144,7 @@ tor - LEAP Platform Documentation <p>To add a relay to a node:</p> -<pre><code>{ +<pre><code>{ "services": ["tor"] } </code></pre> diff --git a/docs/en/services/webapp.html b/docs/en/services/webapp.html index 6c853c22..ece18f38 100644 --- a/docs/en/services/webapp.html +++ b/docs/en/services/webapp.html @@ -199,7 +199,6 @@ webapp - LEAP Platform Documentation <ul> <li><code>webapp.engines</code>: A list of the engines you want enabled in leap_web. Currently, only “support” is available, and it is enabled by default.</li> -<li><code>webapp.invite_required</code>: If true, registration requires an invite code. Default is <code>false</code>.</li> </ul> @@ -218,33 +217,38 @@ webapp - LEAP Platform Documentation <h2><a name="invite-codes"></a>Invite codes</h2> -<p>Enabling the invite code functionality will require new users to provide a valid invite code while signing up for a new account. This is turned off by default, allowing all new users to create an account.</p> +<p>The invite code functionality will require new users to provide a valid invite code while signing up for a new account. This is turned on by default since platform version 0.10. When switching it off, anyone will be able to create a new account.</p> -<p>Set the <code>invite_code</code> option to <code>true</code> in <code>services/webapp.json</code>:</p> +<p>Because even the first (admin) user that registers needs to have an invite code at hand, you´ll have to generate one:</p> -<pre><code>{ - "webapp": { - "invite_required": true - } -} +<pre><code>workstation$ leap run invite + = [bumblebee] running `cd /srv/leap/webapp; RAILS_ENV=production bundle exec rake "generate_invites[1,1]"` + = [bumblebee] pgae-aaub + = [bumblebee] complete in 5.031s. </code></pre> -<p>This only works with LEAP platform 0.8 or higher.</p> +<p>Where <code>bumblebee</code> should be replaced with the name of your webapp node. You can now browse to <a href="https://example.com">https://example.com</a> (replace with your domain) and register your first user, by using the invite code you just generated. If you added your user as an admin user (see above), you can now also generate new invite codes from within the web application.</p> -<p>Run <code>leap deploy</code> to enable the option.</p> +<p>It is possible to specify both <strong>NUM</strong>, the amount of codes to generate and <strong>USES</strong>: an optional parameter: by default all new invite codes can be used once and will then become invalid. If you provide another value, you can set how often it can be used before they’re invalidated. To generate 2 codes that can be both reused 3 times you can run this:</p> -<p>You can then generate invite codes by logging into the web application with an admin user.</p> +<pre><code>workstation$ leap run invite 2,3 prodcution + = [bumblebee] running `cd /srv/leap/webapp; RAILS_ENV=production bundle exec rake "generate_invites[2,3]"` + = [bumblebee] pgae-aaub +</code></pre> + +<p>psau-2qwbs + = [bumblebee] complete in 5.031s.</p> -<p>Alternately, you can also generate invite codes with the command line:</p> +<p>If you want to open up registration to the world, you can set the <code>enrollment_policy</code> option to <code>open</code> in <code>provider.json</code>:</p> -<pre><code>workstation$ leap ssh bumblebee -bumblebee# cd /srv/leap/webapp/ -bumblebee# sudo -u leap-webapp RAILS_ENV=production bundle exec rake "generate_invites[NUM,USES]" +<pre><code>{ + "enrollment_policy": "open" +} </code></pre> -<p>Where <code>bumblebee</code> should be replaced with the name of your webapp node.</p> +<p>This only works with LEAP platform 0.8 or higher. The default enrollment policy changed from open to invite with the platform 0.10.</p> -<p>The <strong>NUM</strong> specifies the amount of codes to generate. The <strong>USES</strong> parameter is optional: By default, all new invite codes can be used once and will then become invalid. If you provide another value for <strong>USES</strong>, you can set a different amount of maximum uses for the codes you generate.</p> +<p>Run <code>leap deploy</code> to disable the option.</p> <h2><a name="customization"></a>Customization</h2> diff --git a/docs/en/services/webapp/index.html b/docs/en/services/webapp/index.html index acdc098c..0ae8b90e 100644 --- a/docs/en/services/webapp/index.html +++ b/docs/en/services/webapp/index.html @@ -199,7 +199,6 @@ webapp - LEAP Platform Documentation <ul> <li><code>webapp.engines</code>: A list of the engines you want enabled in leap_web. Currently, only “support” is available, and it is enabled by default.</li> -<li><code>webapp.invite_required</code>: If true, registration requires an invite code. Default is <code>false</code>.</li> </ul> @@ -218,33 +217,38 @@ webapp - LEAP Platform Documentation <h2><a name="invite-codes"></a>Invite codes</h2> -<p>Enabling the invite code functionality will require new users to provide a valid invite code while signing up for a new account. This is turned off by default, allowing all new users to create an account.</p> +<p>The invite code functionality will require new users to provide a valid invite code while signing up for a new account. This is turned on by default since platform version 0.10. When switching it off, anyone will be able to create a new account.</p> -<p>Set the <code>invite_code</code> option to <code>true</code> in <code>services/webapp.json</code>:</p> +<p>Because even the first (admin) user that registers needs to have an invite code at hand, you´ll have to generate one:</p> -<pre><code>{ - "webapp": { - "invite_required": true - } -} +<pre><code>workstation$ leap run invite + = [bumblebee] running `cd /srv/leap/webapp; RAILS_ENV=production bundle exec rake "generate_invites[1,1]"` + = [bumblebee] pgae-aaub + = [bumblebee] complete in 5.031s. </code></pre> -<p>This only works with LEAP platform 0.8 or higher.</p> +<p>Where <code>bumblebee</code> should be replaced with the name of your webapp node. You can now browse to <a href="https://example.com">https://example.com</a> (replace with your domain) and register your first user, by using the invite code you just generated. If you added your user as an admin user (see above), you can now also generate new invite codes from within the web application.</p> -<p>Run <code>leap deploy</code> to enable the option.</p> +<p>It is possible to specify both <strong>NUM</strong>, the amount of codes to generate and <strong>USES</strong>: an optional parameter: by default all new invite codes can be used once and will then become invalid. If you provide another value, you can set how often it can be used before they’re invalidated. To generate 2 codes that can be both reused 3 times you can run this:</p> -<p>You can then generate invite codes by logging into the web application with an admin user.</p> +<pre><code>workstation$ leap run invite 2,3 prodcution + = [bumblebee] running `cd /srv/leap/webapp; RAILS_ENV=production bundle exec rake "generate_invites[2,3]"` + = [bumblebee] pgae-aaub +</code></pre> + +<p>psau-2qwbs + = [bumblebee] complete in 5.031s.</p> -<p>Alternately, you can also generate invite codes with the command line:</p> +<p>If you want to open up registration to the world, you can set the <code>enrollment_policy</code> option to <code>open</code> in <code>provider.json</code>:</p> -<pre><code>workstation$ leap ssh bumblebee -bumblebee# cd /srv/leap/webapp/ -bumblebee# sudo -u leap-webapp RAILS_ENV=production bundle exec rake "generate_invites[NUM,USES]" +<pre><code>{ + "enrollment_policy": "open" +} </code></pre> -<p>Where <code>bumblebee</code> should be replaced with the name of your webapp node.</p> +<p>This only works with LEAP platform 0.8 or higher. The default enrollment policy changed from open to invite with the platform 0.10.</p> -<p>The <strong>NUM</strong> specifies the amount of codes to generate. The <strong>USES</strong> parameter is optional: By default, all new invite codes can be used once and will then become invalid. If you provide another value for <strong>USES</strong>, you can set a different amount of maximum uses for the codes you generate.</p> +<p>Run <code>leap deploy</code> to disable the option.</p> <h2><a name="customization"></a>Customization</h2> |