| Age | Commit message (Collapse) | Author |
|---|
|
While ensuring that all hosts are deployed to the chat subdomain, I applied the
same logic to the invite pages too.
However, this broke invites as prosody's HTTP module has a check which ensures
that the page being served is on the same domain as the virtual host, meaning
that invite pages hosted under the chat subdomain would receive a 404.
So, serve invite pages from the domain itself (which is the default config in
prosody). To do this, we must direct such requests from nginx too.
|
|
I use the playbook to deploy to three different domains. Before this commit,
some instances were deployed to the root domain (e.g. example.org) and others
were deployed to a subdomain (e.g. chat.example.org), so that other
services/hosts could easily live at the root.
I would now like to enforce that all instances live under the chat. subdomain.
There is no real benefit to having this difference in deployments, having more
consistency will make reasoning about the different instances easier and allow
me to delete some extra variables, and it will also allow me to deploy separate
services to the root domains in the future if needed.
|
|
When I first made this playbook, I was a little sceptical of -or-later
licenses. However, I've come around to the idea over time.
|
|
This was originally intended for motoristic, but is no longer needed by
any domain.
|
|
|
|
This will primiarly be used for motoristic.
|
|
|
