separate meta presets for virtual hosts

[Johann150]

When using the --central-conf flag, the configuration must always be placed in the root content directory. However, when using multiple hostnames, i.e. virtual hosts, there are separate content directories for each host. Hence it would be nice if each vhost would have their own .meta file in their respective content directory, e.g. like this:

content/
├── example.com/
│   ├── .meta    <-- applies to files for example.com
│   └── index.gmi
└── example.net/
    ├── .meta    <-- applies to files for example.net
    └── index.gmi

[michaelnordmeyer]

I have implemented this and added couple more tests for secret handling. It always works in vhosts mode, even if there's just one hostname.

It errors out on launch if the .meta is found at the old central location. If it's for one hostname, it tells the user to move the .meta and other files to their given --hostname subdirectory, which they have to create. If it's for many hostnames, it tells the user to move the .meta to the respective sub directories and adapt it.

I'm still looking into the possibility of how to limit paths in .meta to avoid undefined behavior, before I push.

[michaelnordmeyer]

Sorry for not getting back the last couple of weeks. My current solution runs for a month on my server without problems: https://github.com/michaelnordmeyer/agate/tree/272-separate-meta-presets-for-virtual-hosts

[Johann150]

Since there seem to be some other things done on that branch, the relevant commit seems to be https://github.com/michaelnordmeyer/agate/commit/1c031eceef489a67f37cbdd69847edf788dfcee7

Forcing virtual hosts would break many current configurations (as can be seen by editing almost all tests) so I do not think it is a good idea.

The current behaviour is that separate host directories are only used if more than one hostname is provided on the CLI, and I think that fits the "very simple" aspect of agate's self description: If you only have one hostname (and I suspect many people have) you just have a content directory that you put stuff in and having a /content/example.com/ directory would be unnecessary hassle.

Breaking the behaviour of the central configuration flag in the multiple hostnames scenario is in my opinion a better solution, as I would expect it to be more rare. It would still present a breaking change either way.

[michaelnordmeyer]

Yes, I mentioned this and even wrote some code to at least log this. It's not a nice situation to be in.

What's missing from your rationale is that currently Agate answers on all subdomains, if you have subdomains configured. This is not an unlikely case, because most people have at least example.com and www.example.com configured. In any case, Agate will serve the same content from /content for any domain, as long as a name points to the IP Agate is running on. And most people running Agate don't know this. TLS might break, but at least robots ignore those.

To avoid all this and trigger vhost support, you have to use a fake second domain as the second hostname, which won't be served, because no DNS entry points to this IP for this fake name, and create subdirectories.

Because of this, I consider the convenience feature of having a content root directory without a subdirectory for the one specifically served domain a design flaw. At least that's how vhosts are implemented. It was a reasonable idea, but with issues.

If you don't want to break people's capsule, this is fine. I can maintain my own branch and will likely switch in the mid-term to another Gemini server anyway, because I want to reduce reliance on other people's Gemini services and host some CGI scripts.

Anyway, please don't take this as harsh or bitter. I'm more willing to break things than others, if the end result is having a more robust system for the future.

And there's still the chance to create directories for users, move .meta files around, and change the .meta content if there were multiple hostnames before. Then only the user's upload has to be changed by themselves. It's more of a notification problem than an execution problem. Maybe a version number bump to 4.0, to avoid automatic updates via cask, with a big fat warning in the release notes, will help.