A broad SSL recipe?

[pmario]

@Michael_Jinks

“docker”, now. I hadn’t found that to be presumed. I know what it is, but, what’s special about using it in this context? Metaphorical question… unless.

It’s not needed to go with docker, if you don’t want to start many of them. The nice part though is, that it’s easy to create “throw away” containers for testing, without the need to install all the TW related stuff at the main system.

On the other hand docker has to be installed on the main system …

@Michael_Jinks

In this context, do docker and monit overlap, for instance? Should I use both? FWIW, my project is much smaller than many, and my repetition tool of choice is Salt. Does that imply overlap, somehow? No idea and I don’t expect anybody else to do the work of answering that, unless.

If you use Salt as your orchestration system, you will be able to use it to orchestrate docker. So Salt imo is a layer above it. I would search for docker at: Salt Table of Contents if you consider it.

It’s possible to use monit with docker, but docker or docker-compose should handle restarting crashed containers already.

@Michael_Jinks

Would it be enough, for example, as the absolute minimum, to have nginx holding the SSL keys and treating TiddlyWiki as a hosted app?

I think so.

You can use nginx in a basic configuration as a file server to host “read only” single file wikis over HTTPS … As Tony mentioned, with a bit of PHP it would be possible to save them back.

You can also use nginx and WebDav to save back single file wikis. TiddlyWiki has a WebDav saver built in. The WebDav saver uses ETags to check if the wiki can be saved back. Handling ETags can be a bit ticky, if you enable server side compression.

So for the first run I would send the wiki uncompressed until I’m sure that everything works. And then experiment with server side compression, to minimize data transfer.

@Michael_Jinks

My guess is no, there’s some further piece (node.js?), but I’m not sure why, and obviously I don’t yet understand why other tools (docker, monit, etc.) are necessary in this context.

We – the devs – use nodejs to build TiddlyWiki. There is a development server, that can also be used to save single tiddlers back to the filesystem. This mechanism is know as “TiddlyWiki nodejs server”. It’s perfectly fine to use it on your private network. BUT as soon as you create a web-facing version you need to take care about server security.

If you consider to use it, you should configure nginx as a reverse proxy, that handles all the web requests, the certificate stuff and serving additional files.

@Michael_Jinks

Yes! Thanks again. But again I gripe; I’m still reading there, and the question I still have is, what are the abstract pieces we need to do this? TiddlyWiki is an application, so we need some web server to host it, nginx is preferred. HTTPS is (way) better than HTTP, nginx does that. Would that by itself be enough for one’s first go-round?

As I wrote a relatively easy way would be to use nginx as a WebDav server and single file wikis which can be saved back to directories. If you have additional assets like images, nginx can handle them fine as a file-server.

hope that makes sense
Mario

PS: I assume, you know, that on a web server all incoming ports must be closed, except those you need for your app. AND The app needs authentication and authorisation.

PPS:
As we did some development with the WebDav saver, I did use a docker image for local testing, because it’s easy to “throw away” when I don’t need it anymore. See: GitHub - ionelmc/docker-webdav: NGINX WebDAV container · GitHub … The version I used was older. I didn’t test the latest one yet. … I wouldn’t use this for production, but it can show you a working nginx WebDav configuration.

PPPS:
Additional info about WebDav here at Talk: Use WebDAV for saving a single file wiki