Mirrors/mash-playbook
2
0
Fork 0
mirror of https://github.com/mother-of-all-self-hosting/mash-playbook synced 2024-09-20 05:51:54 +00:00
Code Issues Projects Releases Packages Wiki Activity

Update configuring-dns.md

Browse source
This commit is contained in:
Slavi Pantaleev 2023-03-15 14:39:48 +02:00 committed by GitHub
parent 1c72128c47
commit cb4970d044
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 27 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
docs/configuring-dns.md
View file

@ -1,19 +1,36 @@
# Configuring DNS
To reach your services, you'd need to do some DNS configuration. We recommend you set up at least one (sub-)domain. Each service can be hostet at a subpath of this domain or on separate (sub-)domains.
To reach your services, you'd need to do some DNS configuration.
A simple example could be this
**We recommend** that you:
| Service | Type | Host | Target |
|-----------------------|-------|---------------------|---------------------|
| Miniflux and radicale | A | `mash.example.com` | `IP of your server` |
| Nextcloud | CNAME | `cloud.example.com` | `mash.example.com` |
- create at least one generic domain (e.g. `mash.DOMAIN`) for easily hosting various services at different subpaths (e.g. `mash.DOMAIN/miniflux`, `mash.DOMAIN/radicale`, etc.)
Here you could reach the feedreader miniflux at https://mash.example.com/miniflux (if you set
`miniflux_path_prefix: /miniflux` in your `vars.yml`) and radicale at https://mash.example.com/radicale. In the example
the nextcloud has a different subdomain, so you could access it at https://cloud.example.com
- create additional domains (`CNAME` DNS records pointing to the main generic domain) for large services or services that explicitly require their own dedicated domain
Feel free to change this as you like, just make sure that you set `<service>_hostname` and `<service>_path_prefix`
Some services (like [Uptime-kuma](services/uptime-kuma.md)) require being hosted at their own dedicated domain.
Others, you can put on their own domain/subdomain or at subpaths on any domain you'd like.
As an **example** setup, consider this one:
| Service | Type | Host | Target |
|--------------------------- |-------|---------------------|---------------------|
| Miniflux, Radicale, others | A | `mash.example.com` | `IP of your server` |
| Nextcloud | CNAME | `cloud.example.com` | `mash.example.com` |
With such a setup, you could reach:
- the feedreader [Miniflux](services/miniflux.md) at `https://mash.example.com/miniflux` (if you set
`miniflux_hostname: mash.example.com` and `miniflux_path_prefix: /miniflux` in your `vars.yml`)
- the [Radicale](services/radicale.md) CalDAV/CardDAV sever at `https://mash.example.com/radicale` (if you set
`radicale_hostname: mash.example.com` and `radicale_path_prefix: /radicale` in your `vars.yml`)
- Nextcloud at its own dedicated domain, at `https://cloud.example.com`
Hosting services at subpaths is more convenient, because it doesn't require you to create additional DNS records and no new SSL certificates need to be retrieved.
Still, if you'd like each service to have its own dedicated domain (or subdomain), feel free to configure services that way by making sure that you set `<service>_hostname` and `<service>_path_prefix`
accordingly in your `vars.yml`.
Be mindful as to how long it will take for the DNS records to propagate.