Remarks for #1608, #1609

Author: michaelklishin

site/access-control.md

@@ -77,13 +77,16 @@ new user accounts with generated credentials instead.
 ## <a id="default-state" class="anchor" href="#default-state">Default Virtual Host and User</a>
 
 When the server first starts running, and detects that its
-database is uninitialised or has been deleted, it
+database is uninitialised or has been reset or deleted (the node is a "blank node"), it
 initialises a fresh database with the following resources:
 
  * a [virtual host](./vhosts.html) named <code>/</code> (a slash)
  * a user named <code>guest</code> with a default password of <code>guest</code>, granted full access to the <code>/</code> virtual host
 
-It is advisable to [pre-configure a new user with a generated username and password](#seeding) or [delete](rabbitmqctl.8.html#delete_user)
+If a blank node [imports definitions on boot](/definitions.html#import-on-boot-nuances),
+this default user will not be created.
+
+It is **highly recommended** to [pre-configure a new user with a generated username and password](#seeding) or [delete](rabbitmqctl.8.html#delete_user)
 the `guest` user or at least [change its password](rabbitmqctl.8.html#change_password)
 to reasonably secure generated value that won't be known to the public.
 

site/definitions.md

@@ -146,13 +146,39 @@ definitions.https.url = https://raw.githubusercontent.com/rabbitmq/sample-config
 definitions.tls.versions.1 = tlsv1.2
 </pre>
 
+### <a id="import-on-boot-nuances" class="anchor" href="#import-on-boot-nuances">Nuances of Boot-time Definition Import</a>
 
 Definition import happens after plugin activation. This means that definitions related
 to plugins (e.g. dynamic Shovels, exchanges of a custom type, and so on) can be imported at boot time.
 
 The definitions in the file will not overwrite anything already in the broker.
-However, if a blank (uninitialised) node imports a definition file, it will
-not create the default virtual host and user.
+
+If a blank (uninitialised) node imports a definition file, it will
+not create the default virtual host and user. In **test or QA**  environments,
+an equivalent default user can be created via the same definitions file.
+
+For **production** systems a new user with unique credentials must be created and used instead.
+
+The below snippet demonstrates how the definitions file can be modified to
+"re-create" the default user that would only be able to connect from `localhost` by default:
+
+<pre class="lang-javascript">
+    "users": [
+        {
+            "name": "guest",
+            "password": "guest",
+            "tags": ["administrator"]
+        }
+    ],
+    "permissions":[
+        {
+            "user":"guest",
+            "vhost":"/",
+            "configure":".*",
+            "read":".*",
+            "write":".*"}
+    ],
+</pre>
 
 ### <a id="import-on-boot-skip-if-unchanged" class="anchor" href="#import-on-boot-skip-if-unchanged">Avoid Boot Time Import if Definition Contents Have Not Changed</a>