dev-lxc 2.6.1 → 2.6.2

data/docs/adhoc_clusters.md

@@ -1,22 +1,22 @@
-### Adhoc Clusters
-
-dev-lxc can also manage an adhoc cluster of servers.
-
-An adhoc cluster is just a set of managed servers cloned from the specified base
-container. The servers have SSH server running, a "dev-lxc" user with "dev-lxc" password and
-passwordless sudo access.
-
-This is particularly useful when you want to use something else, such as chef-provisioning,
-to configure the servers.
-
-The number of servers, their names and their IP addresses can be changed to fit your
-particular requirements.
-
-```
-mkdir -p /root/work/clusters/delivery
-cd /root/work/clusters/delivery
-dev-lxc init --adhoc > dev-lxc.yml
-# edit dev-lxc.yml to have enough adhoc servers for a delivery cluster
-cluster-view
-dl up
-```
+### Adhoc Clusters
+
+dev-lxc can also manage an adhoc cluster of servers.
+
+An adhoc cluster is just a set of managed servers cloned from the specified base
+container. The servers have SSH server running, a "dev-lxc" user with "dev-lxc" password and
+passwordless sudo access.
+
+This is particularly useful when you want to use something else, such as chef-provisioning,
+to configure the servers.
+
+The number of servers, their names and their IP addresses can be changed to fit your
+particular requirements.
+
+```
+mkdir -p /root/work/clusters/delivery
+cd /root/work/clusters/delivery
+dev-lxc init --adhoc > dev-lxc.yml
+# edit dev-lxc.yml to have enough adhoc servers for a delivery cluster
+cluster-view
+dl up
+```

data/docs/base_containers.md

@@ -1,44 +1,44 @@
-### Base Containers
-
-The container that is used as the base container for a cluster's containers must exist before
-the cluster can be built. The cluster's containers are cloned from the base container using
-the btrfs filesystem to very quickly provide a lightweight duplicate of the container.
-
-This container provides the chosen OS platform and version (e.g. b-ubuntu-1404).
-
-A typical LXC container has minimal packages installed so `dev-lxc` makes sure that the
-same packages used in Chef's [bento boxes](https://github.com/opscode/bento) are
-installed to provide a more typical server environment.
-A few additional packages are also installed.
-
-Base containers have openssh-server installed and running with unique SSH Host Keys.
-
-Base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
-
-*Once this base container is created there is rarely a need to delete it.*
-
-### Create a dev-lxc Base Container
-
-dev-lxc is able to create base containers that have openssh-server installed and running with unique SSH Host Keys.
-
-dev-lxc base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
-
-You can see a menu of base containers that `dev-lxc` can create by using the following command.
-
-```
-dev-lxc create-base-container
-```
-
-The initial creation of base containers can take awhile so let's go ahead and start creating
-an Ubuntu 14.04 container now.
-
-```
-dev-lxc create-base-container b-ubuntu-1404
-```
-
-Note: It is possible to pass additional arguments to the underlying LXC create command.
-For example:
-
-```
-dev-lxc create-base-container b-ubuntu-1404 -o -- '--no-validate --keyserver http://my.key.server.com'
-```
+### Base Containers
+
+The container that is used as the base container for a cluster's containers must exist before
+the cluster can be built. The cluster's containers are cloned from the base container using
+the btrfs filesystem to very quickly provide a lightweight duplicate of the container.
+
+This container provides the chosen OS platform and version (e.g. b-ubuntu-1404).
+
+A typical LXC container has minimal packages installed so `dev-lxc` makes sure that the
+same packages used in Chef's [bento boxes](https://github.com/opscode/bento) are
+installed to provide a more typical server environment.
+A few additional packages are also installed.
+
+Base containers have openssh-server installed and running with unique SSH Host Keys.
+
+Base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
+
+*Once this base container is created there is rarely a need to delete it.*
+
+### Create a dev-lxc Base Container
+
+dev-lxc is able to create base containers that have openssh-server installed and running with unique SSH Host Keys.
+
+dev-lxc base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
+
+You can see a menu of base containers that `dev-lxc` can create by using the following command.
+
+```
+dev-lxc create-base-container
+```
+
+The initial creation of base containers can take awhile so let's go ahead and start creating
+an Ubuntu 14.04 container now.
+
+```
+dev-lxc create-base-container b-ubuntu-1404
+```
+
+Note: It is possible to pass additional arguments to the underlying LXC create command.
+For example:
+
+```
+dev-lxc create-base-container b-ubuntu-1404 -o -- '--no-validate --keyserver http://my.key.server.com'
+```

data/docs/configuration.md

@@ -1,203 +1,203 @@
-### dev-lxc.yml Config Files
-
-dev-lxc uses a YAML configuration file named `dev-lxc.yml` to define a cluster.
-
-The `init` command generates sample config files for various server types.
-
-Let's generate a config for a cluster with a standalone Chef Server, Supermarket server,
-Compliance server, Chef Automate server, job dispatch runner and an infrastructure node.
-
-```
-dev-lxc init --chef --compliance --supermarket --automate --runners --nodes > dev-lxc.yml
-```
-
-The contents of `dev-lxc.yml` should look like this.
-
-```
-# enable_build_snapshots automatically makes container snapshots at key times during the build process
-# default value is `true`
-#enable_build_snapshots: true
-
-# base_container must be the name of an existing container
-base_container: b-ubuntu-1404
-
-# memory_per_server sets the maximum amount of user memory (including file cache) for each server.
-# dev-lxc will set the `memory.limit_in_bytes` cgroup for each server to apply this limit.
-# If no units are specified, the value is interpreted as bytes.
-# You can use suffixes to represent larger units — k or K for kilobytes, m or M for megabytes, and g or G for gigabytes.
-# The default behavior is that no limit is set.
-#memory_per_server: 4G
-
-# list any host directories you want mounted into the servers
-#mounts:
-#  - /root/work root/work
-
-# list any SSH public keys you want added to /home/dev-lxc/.ssh/authorized_keys
-#ssh-keys:
-#  - /root/work/clusters/id_rsa.pub
-
-# DHCP reserved (static) IPs must be selected from the IP range 10.0.3.150 - 254
-
-chef-server:
-  users:          # a user's password will be the same as its username
-    - mary-admin
-    - joe-user
-  orgs:
-    demo:
-      admins:
-        - mary-admin
-      non-admins:
-        - joe-user
-  servers:
-    chef.lxc:
-      ipaddress: 10.0.3.203
-      products:
-        chef-server:
-        manage:
-        push-jobs-server:
-        reporting:
-
-compliance:
-  admin_user: admin         # the password will be the same as the username
-  servers:
-    compliance.lxc:
-      ipaddress: 10.0.3.205
-      products:
-        compliance:
-
-supermarket:
-  servers:
-    supermarket.lxc:
-      ipaddress: 10.0.3.206
-      products:
-        supermarket:
-
-automate:
-  servers:
-    automate.lxc:
-      ipaddress: 10.0.3.200
-      products:
-        delivery:
-      license_path: /path/for/automate.lxc
-      chef_org: delivery
-      enterprise_name: demo-ent
-
-runners:
-  servers:
-    runner-1.lxc:
-      products:
-        chefdk:     # downloaded only
-
-nodes:
-  chef_server_url: https://chef.lxc/organizations/demo
-  validation_client_name: demo-validator
-  # comment out or remove the validation_key path to use chef-server keys generated by dev-lxc
-  validation_key: # /path/for/ORG-validator.pem
-  servers:
-    node-1.lxc:
-      products:
-        chef:
-```
-
-The dev-lxc.yml config file is very customizable. You can add or remove mounts, products or servers,
-change ip addresses, server names, the base_container and more.
-
-As you can see there are six server types represented by six servers.
-
-1. chef-server - chef.lxc
-2. compliance - compliance.lxc
-3. supermarket - supermarket.lxc
-4. automate - automate.lxc
-5. runners - runner-1.lxc
-6. nodes - node-1.lxc
-
-#### Global Settings
-
-The global settings used by each of the server types are `enable_build_snapshots`, the `base_container`, `memory_per_server`, a list of `mounts` and a list of `ssh-keys`. These settings are described in the config comments.
-
-Be sure to set `base_container` in the `dev-lxc.yml` to an existing container's name.  
-This container will be cloned to create each container in the cluster.  
-If you don't already have a container to use as a `base_container` then you can follow the instructions in the  
-[Create a dev-lxc Base Container section](https://github.com/jeremiahsnapp/dev-lxc#create-a-dev-lxc-base-container) to create one.
-
-#### Server Specific Settings
-
-It is possible to define different values for `enable_build_snapshots`, `base_container`, `memory_per_server`, `mounts` or `ssh-keys` for a particular server type or even for a particular server as you can see in the following snippet.
-
-```
-nodes:
-  base_container: b-ubuntu-1404
-  servers:
-    node-1.lxc:
-      base_container: b-centos-6
-    node-2.lxc:
-```
-
-IP addresses from the range 10.0.3.150 - 254 can be assigned to the servers. If an IP address
-is not specified then a dynamic IP address is assigned when the server starts.
-
-#### mixlib-install Library Automatically Manages a Cache of Product Packages
-
-dev-lxc uses the [mixlib-install](https://github.com/chef/mixlib-install) library to download Chef products
-to a cache in `/var/dev-lxc` in the host instance. This cache is automatically mounted into each server when it starts.
-
-A list of Chef products to be installed can be defined for each server
-using [product names that mixlib-install understands](https://github.com/chef/mixlib-install/blob/master/PRODUCT_MATRIX.md).
-
-The channel and version of the product can be defined also.
-
-Channel can be `current`, `stable` or `unstable` with `stable` as the default.
-Version can be `latest` or a version number with `latest` as the default.
-
-For example, the following specifies the `current` channel and version `0.16.1` of the `chefdk` product.
-
-```
-nodes:
-  servers:
-    node-1.lxc:
-      products:
-        chefdk:
-          channel: current
-          version: 0.16.1
-```
-
-The `package_source` setting can be used to specify a package file on disk.
-
-```
-nodes:
-  servers:
-    node-1.lxc:
-      products:
-        chefdk:
-          package_source: /root/chefdk_0.16.1-1_amd64.deb
-```
-
-#### Chef Server Orgs/Users
-
-When defining a Chef Server you can include organizations and users that will be automatically created and associated accordingly.
-
-#### Automatic Integration Between Servers
-
-dev-lxc knows how to automatically configure Chef Server standalone, Chef Server tier topology,
-Chef Server HA 2.0 as well as Chef Automate, Chef Client, Analytics, Compliance and Supermarket.
-
-If a Chef Automate server, Compliance server, Analytics server or Supermarket server is defined in the same config file as
-a Chef Server then each server will automatically be integrated with that Chef Server.
-
-If a node server with Chef Client or Chef DK installed is defined in the same config file as
-a Chef Server then the Chef Client will automatically be configured to use that Chef Server.
-
-Alternatively, values for `chef_server_url`, `validation_client_name` and `validation_key` can
-be set in the config file either for all nodes or for each individual node.
-
-```
-nodes:
-  chef_server_url: https://chef.lxc/organizations/demo
-  validation_client_name: demo-validator
-  # comment out or remove the validation_key path to use chef-server keys generated by dev-lxc
-  validation_key: # /path/to/org/validation/key
-  servers:
-    node-1.lxc:
-      products:
-        chef:
-```
+### dev-lxc.yml Config Files
+
+dev-lxc uses a YAML configuration file named `dev-lxc.yml` to define a cluster.
+
+The `init` command generates sample config files for various server types.
+
+Let's generate a config for a cluster with a standalone Chef Server, Supermarket server,
+Compliance server, Chef Automate server, job dispatch runner and an infrastructure node.
+
+```
+dev-lxc init --chef --compliance --supermarket --automate --runners --nodes > dev-lxc.yml
+```
+
+The contents of `dev-lxc.yml` should look like this.
+
+```
+# enable_build_snapshots automatically makes container snapshots at key times during the build process
+# default value is `true`
+#enable_build_snapshots: true
+
+# base_container must be the name of an existing container
+base_container: b-ubuntu-1404
+
+# memory_per_server sets the maximum amount of user memory (including file cache) for each server.
+# dev-lxc will set the `memory.limit_in_bytes` cgroup for each server to apply this limit.
+# If no units are specified, the value is interpreted as bytes.
+# You can use suffixes to represent larger units - k or K for kilobytes, m or M for megabytes, and g or G for gigabytes.
+# The default behavior is that no limit is set.
+#memory_per_server: 4G
+
+# list any host directories you want mounted into the servers
+#mounts:
+#  - /root/work root/work
+
+# list any SSH public keys you want added to /home/dev-lxc/.ssh/authorized_keys
+#ssh-keys:
+#  - /root/work/clusters/id_rsa.pub
+
+# DHCP reserved (static) IPs must be selected from the IP range 10.0.3.150 - 254
+
+chef-server:
+  users:          # a user's password will be the same as its username
+    - mary-admin
+    - joe-user
+  orgs:
+    demo:
+      admins:
+        - mary-admin
+      non-admins:
+        - joe-user
+  servers:
+    chef.lxc:
+      ipaddress: 10.0.3.203
+      products:
+        chef-server:
+        manage:
+        push-jobs-server:
+        reporting:
+
+compliance:
+  admin_user: admin         # the password will be the same as the username
+  servers:
+    compliance.lxc:
+      ipaddress: 10.0.3.205
+      products:
+        compliance:
+
+supermarket:
+  servers:
+    supermarket.lxc:
+      ipaddress: 10.0.3.206
+      products:
+        supermarket:
+
+automate:
+  servers:
+    automate.lxc:
+      ipaddress: 10.0.3.200
+      products:
+        delivery:
+      license_path: /path/for/automate.lxc
+      chef_org: delivery
+      enterprise_name: demo-ent
+
+runners:
+  servers:
+    runner-1.lxc:
+      products:
+        chefdk:     # downloaded only
+
+nodes:
+  chef_server_url: https://chef.lxc/organizations/demo
+  validation_client_name: demo-validator
+  # comment out or remove the validation_key path to use chef-server keys generated by dev-lxc
+  validation_key: # /path/for/ORG-validator.pem
+  servers:
+    node-1.lxc:
+      products:
+        chef:
+```
+
+The dev-lxc.yml config file is very customizable. You can add or remove mounts, products or servers,
+change ip addresses, server names, the base_container and more.
+
+As you can see there are six server types represented by six servers.
+
+1. chef-server - chef.lxc
+2. compliance - compliance.lxc
+3. supermarket - supermarket.lxc
+4. automate - automate.lxc
+5. runners - runner-1.lxc
+6. nodes - node-1.lxc
+
+#### Global Settings
+
+The global settings used by each of the server types are `enable_build_snapshots`, the `base_container`, `memory_per_server`, a list of `mounts` and a list of `ssh-keys`. These settings are described in the config comments.
+
+Be sure to set `base_container` in the `dev-lxc.yml` to an existing container's name.  
+This container will be cloned to create each container in the cluster.  
+If you don't already have a container to use as a `base_container` then you can follow the instructions in the  
+[Create a dev-lxc Base Container section](https://github.com/jeremiahsnapp/dev-lxc#create-a-dev-lxc-base-container) to create one.
+
+#### Server Specific Settings
+
+It is possible to define different values for `enable_build_snapshots`, `base_container`, `memory_per_server`, `mounts` or `ssh-keys` for a particular server type or even for a particular server as you can see in the following snippet.
+
+```
+nodes:
+  base_container: b-ubuntu-1404
+  servers:
+    node-1.lxc:
+      base_container: b-centos-6
+    node-2.lxc:
+```
+
+IP addresses from the range 10.0.3.150 - 254 can be assigned to the servers. If an IP address
+is not specified then a dynamic IP address is assigned when the server starts.
+
+#### mixlib-install Library Automatically Manages a Cache of Product Packages
+
+dev-lxc uses the [mixlib-install](https://github.com/chef/mixlib-install) library to download Chef products
+to a cache in `/var/dev-lxc` in the host instance. This cache is automatically mounted into each server when it starts.
+
+A list of Chef products to be installed can be defined for each server
+using [product names that mixlib-install understands](https://github.com/chef/mixlib-install/blob/master/PRODUCT_MATRIX.md).
+
+The channel and version of the product can be defined also.
+
+Channel can be `current`, `stable` or `unstable` with `stable` as the default.
+Version can be `latest` or a version number with `latest` as the default.
+
+For example, the following specifies the `current` channel and version `0.16.1` of the `chefdk` product.
+
+```
+nodes:
+  servers:
+    node-1.lxc:
+      products:
+        chefdk:
+          channel: current
+          version: 0.16.1
+```
+
+The `package_source` setting can be used to specify a package file on disk.
+
+```
+nodes:
+  servers:
+    node-1.lxc:
+      products:
+        chefdk:
+          package_source: /root/chefdk_0.16.1-1_amd64.deb
+```
+
+#### Chef Server Orgs/Users
+
+When defining a Chef Server you can include organizations and users that will be automatically created and associated accordingly.
+
+#### Automatic Integration Between Servers
+
+dev-lxc knows how to automatically configure Chef Server standalone, Chef Server tier topology,
+Chef Server HA 2.0 as well as Chef Automate, Chef Client, Analytics, Compliance and Supermarket.
+
+If a Chef Automate server, Compliance server, Analytics server or Supermarket server is defined in the same config file as
+a Chef Server then each server will automatically be integrated with that Chef Server.
+
+If a node server with Chef Client or Chef DK installed is defined in the same config file as
+a Chef Server then the Chef Client will automatically be configured to use that Chef Server.
+
+Alternatively, values for `chef_server_url`, `validation_client_name` and `validation_key` can
+be set in the config file either for all nodes or for each individual node.
+
+```
+nodes:
+  chef_server_url: https://chef.lxc/organizations/demo
+  validation_client_name: demo-validator
+  # comment out or remove the validation_key path to use chef-server keys generated by dev-lxc
+  validation_key: # /path/to/org/validation/key
+  servers:
+    node-1.lxc:
+      products:
+        chef:
+```

data/docs/dev-lxc_version_2.md

@@ -1,10 +1,10 @@
-# dev-lxc 2.0 is Available
-
-Here are some of the new features which provide a significantly simplified and streamlined usage.
-
-* mixlib-install library is used to automatically manage a cache of product packages
-* Genuine container snapshot management (make as many snapshots as you want)
-* New "nodes" server type which auto configures nodes for a Chef Server in the same cluster
-  * Removed all xc-... bash functions because the new "nodes" server type replaces this functionality
-* Able to build Chef Server HA 2.0 cluster using chef-backend
-* Updated and simplified READMEs
+# dev-lxc 2.0 is Available
+
+Here are some of the new features which provide a significantly simplified and streamlined usage.
+
+* mixlib-install library is used to automatically manage a cache of product packages
+* Genuine container snapshot management (make as many snapshots as you want)
+* New "nodes" server type which auto configures nodes for a Chef Server in the same cluster
+  * Removed all xc-... bash functions because the new "nodes" server type replaces this functionality
+* Able to build Chef Server HA 2.0 cluster using chef-backend
+* Updated and simplified READMEs

data/docs/manage_multiple_clusters.md

@@ -1,30 +1,30 @@
-### Maintain Uniqueness Across Multiple Clusters
-
-The default cluster configs are already designed to be unique from each other but as you build
-more clusters you have to maintain uniqueness across the YAML config files for the following items.
-
-* Server names, `api_fqdn` and `analytics_fqdn`
-
-    Server names should really be unique across all clusters.
-
-    Even when cluster A is shutdown, if cluster B uses the same server names when it is created it
-	will use the already existing servers from cluster A.
-
-    `api_fqdn` and `analytics_fqdn` uniqueness only matters when clusters with the same `api_fqdn`
-	and `analytics_fqdn` are running.
-
-    If cluster B is started with the same `api_fqdn` or `analytics_fqdn` as an already running cluster A,
-	then cluster B will overwrite cluster A's DNS resolution of `api_fqdn` or `analytics_fqdn`.
-
-* IP Addresses
-
-    IP addresses uniqueness only matters when clusters with the same IP's are running.
-
-    If cluster B is started with the same IP's as an already running cluster A, then cluster B
-	will overwrite cluster A's DHCP reservation of the IP's but dnsmasq will still refuse to
-	assign the IP's to cluster B because they already in use by cluster A. dnsmasq then assigns
-	random IP's from the DHCP pool to cluster B leaving it in an unexpected state.
-
-    The `dev-lxc-platform` creates the IP range 10.0.3.150 - 254 for DHCP reserved IP's.
-
-    Use unique IP's from that range when configuring clusters.
+### Maintain Uniqueness Across Multiple Clusters
+
+The default cluster configs are already designed to be unique from each other but as you build
+more clusters you have to maintain uniqueness across the YAML config files for the following items.
+
+* Server names, `api_fqdn` and `analytics_fqdn`
+
+    Server names should really be unique across all clusters.
+
+    Even when cluster A is shutdown, if cluster B uses the same server names when it is created it
+	will use the already existing servers from cluster A.
+
+    `api_fqdn` and `analytics_fqdn` uniqueness only matters when clusters with the same `api_fqdn`
+	and `analytics_fqdn` are running.
+
+    If cluster B is started with the same `api_fqdn` or `analytics_fqdn` as an already running cluster A,
+	then cluster B will overwrite cluster A's DNS resolution of `api_fqdn` or `analytics_fqdn`.
+
+* IP Addresses
+
+    IP addresses uniqueness only matters when clusters with the same IP's are running.
+
+    If cluster B is started with the same IP's as an already running cluster A, then cluster B
+	will overwrite cluster A's DHCP reservation of the IP's but dnsmasq will still refuse to
+	assign the IP's to cluster B because they already in use by cluster A. dnsmasq then assigns
+	random IP's from the DHCP pool to cluster B leaving it in an unexpected state.
+
+    The `dev-lxc-platform` creates the IP range 10.0.3.150 - 254 for DHCP reserved IP's.
+
+    Use unique IP's from that range when configuring clusters.