Add comments

manuscript/recipies/autopirate.md

@@ -477,3 +477,5 @@ Log into each of your new tools at its respective HTTPS URL. You'll be prompted
 ## Chef's Notes
 
 1. In many cases, tools will integrate with each other. I.e., Radarr needs to talk to SABnzbd and NZBHydra, Ombi needs to talk to Radarr, etc. Since each tool runs within the stack under its own name, just refer to each tool by name (i.e. "radarr"), and docker swarm will resolve the name to the appropriate container. You can identify the tool-specific port by looking at the docker-compose service definition.
+
+## Your comments?

manuscript/recipies/duplicity.md

@@ -164,3 +164,5 @@ Nothing will happen. Very boring. But when the cron script fires (daily), duplic
 
 1. Automatic backup can still fail if nobody checks that it's running successfully. I'll be working on an upcoming recipe to monitor the elements of the stack, including the success/failure of duplicity jobs.
 2. The container provides the facility to specify an SMTP host and port, but not credentials, which makes it close to useless. As a result, I've left SMTP out of this recipe. To enable email notifications (if your SMTP server doesn't require auth), add ```SMTP_HOST```, ```SMTP_PORT```, ```EMAIL_FROM``` and ```EMAIL_TO``` variables to duplicity.env
+
+## Your comments?

manuscript/recipies/ghost.md

@@ -69,3 +69,5 @@ Create your first administrative account at https://**YOUR-FQDN**/admin/
 548K	/var/data/ghost/
 [root@ds1 ghost]#
 ```
+
+## Your comments?

manuscript/recipies/gitlab-runner.md

@@ -60,3 +60,6 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 
 1. You'll note that I setup 2 runners. One is locked to a single project (this cookbook build), and the other is a shared runner. I wanted to ensure that one runner was always available to run CI for this project, even if I'd tied up another runner on something heavy-duty, like a container build. Customize this to your use case.
 2. Originally I deployed runners in the same stack as GitLab, but I found that they would frequently fail to start properly when I launched the stack. I think that this was because the runners started so quickly (and GitLab starts so slowly!), that they always started up reporting that the GitLab instance was invalid or unavailable. I had issues with CI builds stuck permanently in a "pending" state, which were only resolved by restarting the runner. Having the runners deployed in a separate stack to GitLab avoids this problem.
+
+
+## Your comments?

manuscript/recipies/gitlab.md

@@ -132,3 +132,6 @@ Log into your new instance at https://[your FQDN], with user "root" and the pass
 A few comments on decisions taken in this design:
 
 1. I use the **sameersbn/gitlab:latest** image, rather than a specific version. This lets me execute updates simply by redeploying the stack (and why **wouldn't** I want the latest version?)
+
+
+## Your comments?

manuscript/recipies/gollum.md

@@ -128,3 +128,6 @@ Authenticate against your OAuth provider, and then start editing your wiki!
 ## Chef's Notes
 
 1. In the current implementation, Gollum is a "single user" tool only. The contents of the wiki are saved as markdown files under /var/data/gollum, and all the git commits are currently "Anonymous"
+
+
+## Your comments?

manuscript/recipies/huginn.md

@@ -143,3 +143,6 @@ Log into your new instance at https://**YOUR-FQDN**. You'll need to use the "Sig
 ## Chef's Notes
 
 1. I initially considered putting an oauth proxy in front of Huginn, but since the invitation code logic prevents untrusted access, and since using a proxy would break oauth for sevices like Twitter integration, I left it out.
+
+
+## Your comments?

manuscript/recipies/kanboard.md

@@ -78,3 +78,6 @@ Log into your new instance at https://**YOUR-FQDN**. Default credentials are adm
 
 1. The default theme can be significantly improved by applying the [ThemePlus](https://github.com/phsteffen/kanboard-themeplus) plugin.
 2. Kanboard becomes more useful when you integrate in/outbound email with [MailGun](https://github.com/kanboard/plugin-mailgun), [SendGrid](https://github.com/kanboard/plugin-sendgrid), or [Postmark](https://github.com/kanboard/plugin-postmark).
+
+
+## Your comments?

manuscript/recipies/mail.md

@@ -170,3 +170,5 @@ Launch the mail server stack by running ```docker stack deploy docker-mailserver
 1. One of the elements of this design which I didn't appreciate at first is that since the config is entirely file-based, **setup.sh** can be run on any container host, provided it has the shared data mounted. This means that even though docker-mailserver was not designed with docker swarm in mind, it works perfectl with swarm. I.e., from any node, regardless of where the container is actually running, you're able to add/delete email addresses, view logs, etc.
 
 2. If you're using sieve with Rainloop, take note of the [workaround](https://discourse.geek-kitchen.funkypenguin.co.nz/t/mail-server-funky-penguins-geek-cookbook/70/15) identified by [ggilley](https://discourse.geek-kitchen.funkypenguin.co.nz/u/ggilley)
+
+## Your comments?

manuscript/recipies/miniflux.md

@@ -70,3 +70,6 @@ Log into your new instance at https://**YOUR-FQDN**. Default credentials are adm
 
 1. I chose [saghul/miniflux](https://hub.docker.com/r/saghul/miniflux/)'s over the "official" [miniflux/miniflux](https://hub.docker.com/r/miniflux/miniflux/) image, because currently the official image doesn't log to stdout (which you want, for docker logging commands), and because I have an expectation that nginx is more lightweight (faster) than apache.
 2. Find the bookmarklet under the "about" page. I know, it took me ages too.
+
+
+## Your comments?

manuscript/recipies/piwik.md

@@ -92,4 +92,4 @@ Launch the Piwik stack by running ```docker stack deploy piwik -c <path -to-dock
 
 Log into your new instance at https://**YOUR-FQDN**, and follow the wizard to complete the setup.
 
-## Chef's Notes
+## Your comments?

manuscript/recipies/template.md

@@ -109,3 +109,5 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 ## Chef's Notes
 
 1. If you wanted to expose the Wekan UI directly, you could remove the oauth2_proxy from the design, and move the traefik-related labels directly to the wekan container. You'd also need to add the traefik network to the wekan container.
+
+## Your comments?

manuscript/recipies/tiny-tiny-rss.md

@@ -134,3 +134,5 @@ There are several TTRSS containers available on docker hub, none of them "offici
 1. Docker swarm looses the docker-compose concept of "dependencies" between containers. In the case of this stack, the application server typically starts up before the database container, which causes the database autoconfiguration scripts to fail, and brings up the app in a broken state. To prevent this, I  include "[wait-for](https://github.com/Eficode/wait-for/)", which (combined with "S6_BEHAVIOUR_IF_STAGE2_FAILS=2"), will cause the app container to restart (and attempt to auto-configure itself) until the database is ready.
 
 2. The upstream git URL [changed recently](https://discourse.tt-rss.org/t/gitlab-is-overbloated-shit-garbage/325/6), but my experience of the new repository is that it's **SO** slow, that the initial "git clone" on setup of the container times out. To work around this, I created [my own repo](https://github.com/funkypenguin/tt-rss.git), cloned upstream, pushed it into my repo, and pointed the container at my own repo with TTRSS_REPO. I don't get the _latest_ code changes, but at least the app container starts up. When upstream git is performing properly, I'll remove TTRSS_REPO to revert back to the "rolling release".
+
+## Your comments?

manuscript/recipies/wekan.md

@@ -142,3 +142,6 @@ Log into your new instance at https://**YOUR-FQDN**, with user "root" and the pa
 ## Chef's Notes
 
 1. If you wanted to expose the Wekan UI directly, you could remove the oauth2_proxy from the design, and move the traefik-related labels directly to the wekan container. You'd also need to add the traefik network to the wekan container.
+
+
+## Your comments?