various minor edits.

5 files changed, 41 insertions, 39 deletions

diff --git a/pages/docs/platform/guide/keys-and-certificates.md b/pages/docs/platform/guide/keys-and-certificates.md
index e0fd314..092589d 100644
--- a/pages/docs/platform/guide/keys-and-certificates.md
+++ b/pages/docs/platform/guide/keys-and-certificates.md
@@ -4,7 +4,7 @@
 Working with SSH
 ================================
 
-Whenever the `leap` command nees to push changes to a node or gather information from a node, it tunnels this command over SSH. Another way to put this: the security of your servers rests entirely on SSH. Because of this, it is important that you understand how `leap` uses SSH.
+Whenever the `leap` command needs to push changes to a node or gather information from a node, it tunnels this command over SSH. Another way to put this: the security of your servers rests entirely on SSH. Because of this, it is important that you understand how `leap` uses SSH.
 
 SSH related files
 -------------------------------
@@ -33,6 +33,15 @@ Specifically, for local nodes:
 2. `leap` entirely skips the checking of host keys when connecting with a local node.
 3. `leap` adds the public Vagrant SSH key to the list of SSH keys for a user. The public Vagrant SSH key is a shared and insecure key that has root access to most Vagrant virtual machines.
 
+To upgrade a SSH host key
+-------------------------------
+
+Most servers will have more than one SSH host key. Sometimes, the server will have a better SSH host key than the one you have on file. In order to upgrade to the better SSH host key, simply re-run the init command:
+
+    workstation$ leap node init NODE_NAME
+
+This will prompt you if you want to upgrade the SSH host key, but only if `leap` thinks that an upgrade is advisable.
+
 When SSH host key changes
 -------------------------------
 
@@ -86,13 +95,6 @@ Suppose you want to remove `userx` from having any further ssh access to the ser
 X.509 Certificates
 ================================
 
-NOTE: the following files are extremely sensitive and must be carefully protected:
-
-* `files/ca/ca.key`
-* `files/<domain>.key` (where "domain" is the primary domain of the provider).
-
-These files must be kept private and you must not lose them. All the other key files can be regenerated if you lose them or if they are compromised.
-
 Configuration options
 -------------------------------------------
 
diff --git a/pages/docs/platform/services/en.md b/pages/docs/platform/services/en.md
index aa4ffc7..5d0fec5 100644
--- a/pages/docs/platform/services/en.md
+++ b/pages/docs/platform/services/en.md
@@ -7,14 +7,11 @@
 
 Every node (server) must have one or more `services` defined that determines what role the node performs. For example:
 
-
-```
-  cat nodes/stallman.json
-  {
-    "ip_address": "199.99.99.1",
-    "services": ["webapp", "tor"]
-  }
-```
+    workstation$ cat nodes/stallman.json
+    {
+      "ip_address": "199.99.99.1",
+      "services": ["webapp", "tor"]
+    }
 
 Here are common questions to ask when adding a new node to your provider:
 
diff --git a/pages/docs/platform/services/webapp.md b/pages/docs/platform/services/webapp.md
index 556a5d1..1c06d71 100644
--- a/pages/docs/platform/services/webapp.md
+++ b/pages/docs/platform/services/webapp.md
@@ -23,7 +23,8 @@ Topology
 
 Currently, the platform only supports a single `webapp` node, although we hope to change this in the future.
 
-`webapp` nodes communicate heavily with `couchdb` nodes.
+* `webapp` nodes communicate heavily with `couchdb` nodes, but the two can be on separate servers.
+* The `monitor` service, if enabled, must be on the same node as `webapp`.
 
 Configuration
 --------------------------
@@ -35,6 +36,7 @@ Essential options:
 Other options:
 
 * `webapp.engines`: A list of the engines you want enabled in leap_web. Currently, only "support" is available, and it is enabled by default.
+* `webapp.invite_required`: If true, registration requires an invite code. Default is `false`.
 
 For example, `services/webapp.json`:
 
@@ -49,9 +51,9 @@ By putting this in `services/webapp.json`, all the `webapp` nodes will inherit t
 There are many options in `provider.json` that also control how the webapp behaves. See [[provider-configuration]] for details.
 
 Invite codes
-------------
+-------------------
 
-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. To turn on invite codes, follow these steps after making sure that LEAP webapp and LEAP platform are both v0.8 or greater:
+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.
 
 Set the `invite_code` option to `true` in `services/webapp.json`:
 
@@ -61,28 +63,21 @@ Set the `invite_code` option to `true` in `services/webapp.json`:
       }
     }
 
-At the moment, you need to use the develop branch of the webapp to use this feature. Add this to your webapp node config file:
-
-    "sources": {
-      "webapp": {
-        "type": "git",
-        "source": "https://leap.se/git/leap_web",
-        "revision": "origin/develop"
-      }
-    }
-
+This only works with LEAP platform 0.8 or higher.
 
 Run `leap deploy` to enable the option.
 
-You can then generate invite codes by running the following rake task from the webapp directory:
+You can then generate invite codes by logging into the web application with an admin user.
+
+Alternately, you can also generate invite codes with the command line:
 
-```
-cd /srv/leap/webapp/
-sudo -u leap-webapp RAILS_ENV=production bundle exec rake generate_invites[x,y]
-```
+    workstation$ leap ssh bumblebee
+    bumblebee# cd /srv/leap/webapp/
+    bumblebee# sudo -u leap-webapp RAILS_ENV=production bundle exec rake "generate_invites[NUM,USES]"
 
-The *x* specifies the amount of codes to generate. The *y* parameter is optional: By default, all new invite codes can be used once and will then become invalid. If you provide another value for *y*, you can set a different amount of maximum uses for the codes you generate.
+Where `bumblebee` should be replaced with the name of your webapp node.
 
+The **NUM** specifies the amount of codes to generate. The **USES** parameter is optional: By default, all new invite codes can be used once and will then become invalid. If you provide another value for **USES**, you can set a different amount of maximum uses for the codes you generate.
 
 Customization
 ---------------------------
diff --git a/pages/docs/platform/troubleshooting/tests.md b/pages/docs/platform/troubleshooting/tests.md
index 383fe7b..607f924 100644
--- a/pages/docs/platform/troubleshooting/tests.md
+++ b/pages/docs/platform/troubleshooting/tests.md
@@ -8,15 +8,15 @@ At any time, you can run troubleshooting tests on the nodes of your provider inf
 
 To run tests on FILTER node list:
 
-    leap test run FILTER
+    workstation$ leap test run FILTER
 
 For example, you can also test a single node (`leap test elephant`); test a specific environment (`leap test development`), or any tag (`leap test soledad`).
 
 Alternately, you can run test on all nodes (probably only useful if you have pinned the environment):
 
-    leap test
+    workstation$ leap test
 
-The tests that are performed are located in the platform under the tests directory. 
+The tests that are performed are located in the platform under the tests directory.
 
 ## Testing with the bitmask client
 
diff --git a/pages/docs/platform/troubleshooting/where-to-look.md b/pages/docs/platform/troubleshooting/where-to-look.md
index b6fd144..c92fba8 100644
--- a/pages/docs/platform/troubleshooting/where-to-look.md
+++ b/pages/docs/platform/troubleshooting/where-to-look.md
@@ -9,6 +9,15 @@ General
 * Please increase verbosity when debugging / filing issues in our issue tracker. You can do this with adding i.e. `-v 5` after the `leap` cmd, i.e. `leap -v 2 deploy`.
 * We use the `example.org` domain for documentation purposes here, please replace it with the you domain.
 
+Firewall
+=======================
+
+Every node in your provider has its own restrictive firewall, but you might have a network firewall in place as well that is not managed by LEAP platform. To see what ports and addresses must be open, run this command:
+
+    workstation$ leap compile firewall
+
+If any of those are blocked, then your provider will not work.
+
 Webapp
 ======
 
@@ -24,7 +33,6 @@ Places to look for errors
 Is haproxy ok ?
 ---------------
 
-
     curl -s -X  GET "http://127.0.0.1:4096"
 
 Is couchdb accessible through stunnel ?