Fix Directory Hardcodes, Documentation Improvements (#10)

* Improve the main crontab example.

* Remove /opt/Docker hardcodes.

* Add periods.

* Improve readability.

* Begin removing hardcoded path from the bin files.

* Update main README to no longer enforce hardcoded path. Other improvements.

* Add the load folder with a README.

* Add load folder and its README.

* Improve reverse proxy text files.

* Switch to tabs.

* Update all scripts for tabs, DOCKER_HOME, and comments.

* Let users know the directory choice is optional.

* Fix environment file.

* Add more details for the reverse proxy load balancing.

* Don't actually listen for postgres.

* Fix comments on source file.

* Be more explicit on the pathing.

Config/ReverseProxy/config/hosts/README.md

@@ -1,3 +1,2 @@
 # Upstream Host Configuration
 For systems which do not resolve well such as ignoring `/etc/hosts`.
-

Config/ReverseProxy/config/hosts/example.com

@@ -5,4 +5,3 @@ upstream example-proxy-site {
     #server 127.0.0.1:8080;
     server hyperling.com;
 }
-

Config/ReverseProxy/config/html/README.md

@@ -1,7 +1,6 @@
 # HTML Sites
-If the reverse proxy also serves static HTML sites,
-  the root directories of each can be placed here.
-Then in `../conf.d` add a file which points the domain to the HTML web root,
-  such as `/etc/nginx/html/www.website.name`.
-An example for this exists called `html.example.com`.
-It should be fairly easy to recreate for another website.
+If the reverse proxy also serves static HTML sites, the root directories of each
+can be placed here. Then in `../conf.d` add a file which points the domain to
+the HTML web root, such as `/etc/nginx/html/www.website.name`. An example for
+this exists called `html.example.com`. It should be fairly easy to recreate for
+another website.

Config/ReverseProxy/config/load.conf.d/README.md

@@ -0,0 +1,8 @@
+# Load Balancing Files
+Allow requests coming to this server to be spread amongst multiple servers based
+on port number. It does not seem possible to spread them based on `server_name`
+or other directives like a reverse proxy. The server simply listens on the port
+then runs through the upstream list to determine the destination.
+
+## Official Documentation
+http://nginx.org/en/docs/stream/ngx_stream_core_module.html

Config/ReverseProxy/config/load.conf.d/example.com

@@ -0,0 +1,15 @@
+# Example of how to load balance 4 Postgres servers for example.com. Since this
+# does not act under a reverse proxy situation, code is commented so that the
+# container does not needlessly start listening on the port.
+
+#upstream postgres_servers {
+#	server 1.2.3.1:5432;
+#	server 1.2.3.2:5432;
+#	server 1.2.3.3:5432;
+#	server 1.2.3.4:5432;
+#}
+#
+#server {
+#	listen 5432;
+#	proxy_pass postgres_servers;
+#}

Config/ReverseProxy/config/nginx.conf

@@ -66,12 +66,17 @@ http {
     include /etc/nginx/conf.d/*;
 }
 
-# TBD, going live with HTTP first.
+## TBD.
 mail {
     ## Reverse Proxied Mail Server Configurations ##
     #include /etc/nginx/mail.conf.d/*;
 }
 
+## Under Experimentation
+# So far does not seem like server_name works, only listen, so not useful as a
+# reverse proxy. Such as 2 Postgres servers needing traffic from different
+# domains, or two SMTP servers on the same IP serving two different domains.
+# Those possibilities do not seem to exist here, unfortunately.
 stream {
     ## Service Forwarding and Load Balancing ##
     # If this supports the `listen` and `server_name` directives then this may