If the patch would be accepted, I will send a Contributor Agreement.

@drh: do we need a CA for doc-only patches? If not, i'll apply this.

The patch will be accepted if you send a contibutor agreement. For this doc-only patch, and email scan will suffice. Send it to me: drh at sqlite dot org.

... documentation on running fossil as a service on OpenBSD.

Your additions were checked in: fossil:62073f6dbb4b6910

And are live at fossil:/doc/trunk/www/server/.

Thank you!

Hello, Thomas

Thanks for the writeup!

May I ask about the intended use-case for this setup?

Would it make sense to add a warning stating that the described setup transfers data unencrypted?

-- Kirill

I'm not Thomas but I'll give my opinion...

Would it make sense to add a warning stating that the described setup transfers data unencrypted?

If that's the case, a simple note for the Debian/Ubuntu guide can be added as well. I assume it doesn't mention it in either because this is how to run Fossil as a standalone service.

An aside to those who have commit access, I'd recommend the OpenBSD root page be updated to include the link to Thomas' guide.

... I'd recommend the OpenBSD root page be updated to include the link to Thomas' guide.

Done: https://fossil-scm.org/home/doc/trunk/www/server/openbsd/

Fossil servers run inside a benign firewall (e.g. a home, a small company LAN, etc.) generally don't need HTTPS, and often can't get it even if wanted, since self-signed certs are nearly useless these days with current browsers. Until you get to the level where running a local CA makes sense, HTTPS tends not to make sense.

Atop that, local HTTP service is one path to get to HTTPS service, by proxying through Apache or similar. You can serve HTTP over localhost only and proxy that to HTTPS for external hosts, or serve HTTP to the LAN only and proxy to HTTPS for the WAN, etc.

I agree with that one, and maybe it’s such a given that no warning is even needed.

I’m still curious about the use-case, though, and any benefit over using CGI.

If I were to have a setup on OpenBSD with fossil being served as multiple users, I think I’d go with stock https, use fossil-static port and multiple instances of slowcgi (one per user wirth custom unix sockets). With this setup each each user could have multiple repos and all repos would be served on same port without additonal proxy setup and also be locked in a chroot. The latter might or might not matter.

I’m still curious about the use-case, though, and any benefit over using CGI.

The use case of having Fossil be standalone? Probably just simplicity.

There are many ways to configure and setup Fossil, as the server page highlights. Generically speaking, they each have their pros and cons so it’s mostly what works best for the admin of Fossil. Someone may setup Fossil as described in the latest article but later determine they want to run a web server in front of it, so the user already has a document covering both of those conditions.

How you run Fossil doesn’t need to fall into those use cases exactly. My only advice would be, is if you’re going to run a Fossil instance available 24/7 on the internet (not behind a LAN or VPN), you should consider using TLS with it.

benefit over using CGI.

Connection latency should be measurably lower with fossil server versus fossil cgi, particularly on a fast LAN, as opposed to a WAN where ping time swamps this benefit.

It also saves the need for a separate HTTP server, CGI to HTTP proxying, etc.