Add Caddyfile.example, update README

.gitignore

@@ -0,0 +1,2 @@
+caddy-config
+

README.md

@@ -23,7 +23,7 @@ Although not required, it's recommended to create a Dataset named `apps` with a
 
 ### Installation
 
-Download the repository to a convenient directory on your FreeNAS system by changing to that directory and running `git clone https://github.com/danb35/freenas-iocage-caddy`. Then change into the new `freenas-iocage-caddy` directory and create a file called `caddy-config` with your favorite text editor. In its minimal form, it would look like this:
+Download the repository to a convenient directory on your FreeNAS system by changing to that directory and running `git clone https://github.com/danb35/freenas-iocage-caddy`. Then change into the new freenas-iocage-caddy directory and create a file called caddy-config with your favorite text editor. In its minimal form, it would look like this:
 
 ```
 JAIL_IP="192.168.1.199"
@@ -62,6 +62,8 @@ To test your installation, enter your Caddy jail IP address and port 2020 e.g. `
 ## The Caddyfile
 Caddy looks for its configuration in the Caddyfile. Its syntax is fairly simple, and is fully documented in the [Caddy Docs](https://caddyserver.com/docs/).  It's saved outside the jail in `$POOL_PATH/apps/caddy/`, so you can edit it without entering the jail.  This script installs a very basic Caddyfile which only prints "Hello, world!"; to actually act as a reverse proxy or web server, you'll need to create your own Caddyfile.  I'll discuss a few scenarios with examples of the Caddyfile below.
 
+For a more extensively-annotated Caddyfile, see `Caddyfile.example` at `/usr/local/www/Caddyfile.example` in your jail.
+
 ### Prerequisites (Let's Encrypt)
 Caddy works best when your installation is able to obtain a certificate from Let's Encrypt. When you use it this way, Caddy is able to handle all of the TLS-related configuration for you, obtain and renew certificates automatically, etc. In order for this to happen, you must meet the two requirements below:
 
@@ -112,7 +114,7 @@ sub.domain.com {
 ```
 As before, this will serve HTML pages out of `/usr/local/www/html`.  But unlike the previous example, this Caddyfile will obtain a certificate from Let's Encrypt, renew it automatically, configure TLS, and redirect HTTP to HTTPS.  
 
-The top block here is optional, but recommended.  The first directive tells Caddy to use the Let's Encrypt staging server.  Certificates issued by this server won't be trusted by your browser, but you're much less likely to exceed the rate limits.  Once you're sure your system is working properly, you can comment it out.  The second directive is an email address Let's Encrypt can use to notify you of certificate expiration or other major events.  If things are working properly, you'll very rarely get an email from them.
+The top block here is optional, but recommended.  The first directive tells Caddy to use the Let's Encrypt staging server.  Certificates issued by this server won't be trusted by your browser, but you're much less likely to exceed the [rate limits](https://letsencrypt.org/docs/rate-limits/).  Once you're sure your system is working properly, you can comment it out.  The second directive is an email address Let's Encrypt can use to notify you of certificate expiration or other major events.  If things are working properly, you'll very rarely get an email from them.
 
 In the second block, there are two changes:
 
@@ -130,11 +132,11 @@ This gets a little more complicated.  DNS validation will let you obtain a certi
 }
 
 sub.domain.com {
-	root * /usr/local/www/html
-	file_server
 	tls {
 		dns cloudflare long_api_token
 	}
+	root * /usr/local/www/html
+	file_server
 }
 ```
 Compared to the last example, the only change is the `tls{}` block.  In that block, `dns` is a required keyword, `cloudflare` is the name of the plugin being used, and `long_api_token` is a Cloudflare API token with appropriate permissions.  The reverse proxy is added as above.

includes/Caddyfile.example

@@ -1 +1,115 @@
+# Example Caddyfile
+# This file is intended to be an example, and demonstrate some common options.
+# Do not copy and use it, but rather, consider these examples.  Full
+# documentation at https://caddyserver.com/docs/caddyfile
 
+# Global options
+# The options set here will affect all code blocks below.
+
+{
+	# Use the Let's Encrypt test server.  This will issue certs that aren't
+	# trusted by your browser, but it will also make it unlikely that you'll
+	# exceed the Let's Encrypt rate limits 
+	# (see https://letsencrypt.org/docs/rate-limits/).  Comment out this line
+	# to use the production server instead.
+	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
+	
+	# Email for certificate expiration notices and other alerts from Let's
+	# Encrypt.  Optional, but recommended.
+	email you@somewhere.com
+	
+	# Debug mode.  Extensive logging, may be useful in tracking down problems.
+	# Uncomment to enable.
+	# debug
+	
+	# If you're using Caddy behind a reverse proxy, and you're serving HTTPS
+	# with Caddy, you may need to tell Caddy which site to serve clients
+	# (i.e., your reverse proxy) who don't use SNI
+	# default_sni sub.yourdomain.com
+}
+
+# All the examples below are name-based virtual hosts.  For them to work
+# properly, whatever device is providing DNS for your network (likely your
+# router) needs to point their hostnames to the IP address of your Caddy
+# jail.  Configuring this is beyond the scope of this guide.
+
+# A HTTP-only virtual host.  Specifying port 80 disables Caddy's automatic
+# HTTPS.
+
+sub1.example.com:80 {
+	
+	# Document root.  The * is required
+	root * /usr/local/www/html1
+	# Serve files from disk.  This directive is required to serve static
+	# (e.g., HTML) files.
+	file_server
+	
+	# Access log will by default go to /var/log/caddy.log as JSON unless
+	# changed
+	log {
+		output file /var/log/sub1.example.com.log
+		format single_field common_log
+	}
+	
+	# Reverse proxy Radarr and Sonarr.  You'll be able to reach them at
+	# http://sub1.example.com/radarr (or /sonarr)
+	reverse_proxy /sonarr* 192.168.1.15:8989
+	reverse_proxy /radarr* 192.168.1.15:7878
+}
+
+# A virtual host with automatic HTTPS, using HTTP validation for the cert.
+# For this to work, ports 80 and 443 must be open from the entire Internet
+# to your Caddy jail.  Caddy will automatically obtain the cert from Let's
+# Encrypt, install it, and renew it when necessary.  It will also redirect
+# HTTP to HTTPS requests.  The only difference is the lack of a port number.
+
+sub2.example.com {
+
+	root * /usr/local/html2
+	file_server
+	
+	# Access log will be in .json if another format isn't specified
+	log {
+		output file /var/log/sub2.example.com.log
+	}
+	
+	# Reverse proxy Jackett and Lidarr.  In addition to providing a nice
+	# URL as above, this will provide TLS termination (i.e., HTTPS) also.
+	# (e.g., https://sub2.example.com/jackett)
+	reverse_proxy /jackett* 192.168.1.15:9117
+	reverse_proxy /lidarr* 192.168.1.15:8686
+}
+
+# Another virtual host with automatic HTTPS, but using DNS validation for
+# the cert.  Support is currently limited to a few DNS hosts, and requires
+# a plugin that must be compiled into Caddy.  This example will use
+# Cloudflare; consult the Caddy docs for other possibilities.
+
+sub3.example.com {
+
+	# The tls directive modifies Caddy's TLS settings.  Here, it tells
+	# Caddy to obtain the cert using DNS validation, using the
+	# Cloudflare plugin, and provides the API token to authenticate.
+	tls {
+		dns cloudflare long_api_token
+	}
+
+	root * /usr/local/html2
+	file_server
+	
+	# No access log for this block
+	log {
+		output discard
+	}
+}
+
+# Some applications, like Duplicati, don't support access via a subdirectory
+# (e.g., http://yourhost/duplicati).  If you want to proxy to those, you'll
+# need a separate virtual host like this one.  This example still does
+# automatic HTTPS, using HTTP validation.
+
+dup.example.com {
+
+	# Reverse proxy all requests for this host name
+	reverse_proxy 192.168.1.16:8200
+}