[enh] Document sub sub free domains + fix subpath vs subdomains

This commit is contained in:
ljf 2021-07-15 01:26:37 +02:00 committed by ljf (zamentur)
parent 8d35c21dcc
commit 72bf9c91bd
2 changed files with 15 additions and 6 deletions

View file

@ -9,9 +9,11 @@ routes:
YunoHost permet de gérer et de servir plusieurs domaines sur un même serveur. Vous pouvez donc héberger, par exemple, un blog et un Nextcloud sur un premier domaine `yolo.com`, et un client de messagerie web sur un second domaine `swag.nohost.me`. Chaque domaine est automatiquement configuré pour pouvoir gérer des services web, des courriels et une messagerie instantannée XMPP.
Les domaines peuvent être gérés dans la section 'Domaine' de la webadmin, ou via la catégorie `yunohost domain` de la ligne de commande. Chaque fois que vous ajoutez un domaine, il est supposé que vous avez acheté (ou en tout cas que vous contrôliez) le domaine, de sorte que vous puissiez gérer la [configuration DNS](/dns_config) de celui-ci. Une exception concerne les [domaines en `.nohost.me`, `.noho.st` et `ynh.fr`](/dns_nohost_me) qui sont offerts par le Projet YunoHost, et peuvent être directement intégrés avec YunoHost grâce à une configuration dynDNS automatique. (Pour limiter les abus et les coûts, une instance ne peut avoir qu'un seul domaine offert à la fois).
Les domaines peuvent être gérés dans la section 'Domaine' de la webadmin, ou via la catégorie `yunohost domain` de la ligne de commande.
Le domaine choisi lors de la postinstall est défini comme le domaine principal du serveur : c'est là que le SSO et l'interface d'administration web seront disponibles. Le domaine principal peut être modifié ultérieurement via la webadmin dans Domaines > (le domaine) > Définir par défaut, ou avec la ligne de commande `yunohost tools maindomain`.
Chaque fois que vous ajoutez un domaine, il est supposé que vous avez acheté (ou en tout cas que vous contrôlez) le domaine, de sorte que vous puissiez gérer la [configuration DNS](/dns_config) de celui-ci. Une exception concerne les [domaines en `.nohost.me`, `.noho.st` et `ynh.fr`](/dns_nohost_me) qui sont offerts par le Projet YunoHost, et peuvent être directement intégrés avec YunoHost grâce à une configuration dynDNS automatique. Pour limiter les abus et les coûts, une instance ne peut avoir qu'un seul domaine offert à la fois, toutefois vous pouvez ajouter autant de sous-domaine de celui-ci que vous le souhaitez. Par exemple, ci vous choisissez `example.ynh.fr` vous pourrez par la suite ajouter les domaines `video.example.ynh.fr` ou `www.example.ynh.fr` ou tout autre sous-domaine dont vous pourriez avoir l'utilité.
Le domaine choisi lors de la configuration initiale (post-installation) est défini comme le domaine principal du serveur : c'est là que le SSO et l'interface d'administration web seront disponibles. Le domaine principal peut être modifié ultérieurement via la webadmin dans Domaines > (le domaine) > Définir par défaut, ou avec la ligne de commande `yunohost tools maindomain`.
Enfin, il faut noter que, dans le contexte de YunoHost, il n'y a pas de hiérarchie entre les domaines qu'il connaît. Dans l'exemple précédent, on peut ajouter un troisième domaine `foo.yolo.com` - mais il serait considéré comme un domaine indépendant de `yolo.com`.
@ -41,7 +43,7 @@ yolo.com
├─── /wiki : DokuWiki (un wiki)
```
Alternativement, on peut choisir d'installer chaque application (ou certaines) sur un domaine dédié. Cela peut sembler plus joli pour les utilisateurs finaux, mais est généralement considéré comme plus compliqué et moins efficace dans le contexte de YunoHost, car vous devez ajouter un nouveau domaine à chaque fois. Néanmoins, certaines applications peuvent avoir besoin d'un domaine entier qui leur est dédié, pour des raisons techniques.
Alternativement, on peut choisir d'installer chaque application (ou certaines) sur un domaine dédié. Au delà de la question esthétique, utiliser des sous-domaines au lieu de sous-chemin permet de laisser la possibilité de déplacer un service sur un autre serveur plus facilement. Par ailleurs, certaines applications peuvent avoir besoin d'un domaine entier qui leur est dédié, pour des raisons techniques. L'inconvénient est que vous devez ajouter un nouveau domaine à chaque fois, et donc potentiellement configurer des enregistrements DNS supplémentaire, relancer le diagnostique et l'installation d'un nouveau certificat Let's Encrypt.
Si toutes les applications de l'exemple précédent étaient installées sur un domaine séparé, cela donnerait quelque chose comme ceci :
@ -51,3 +53,5 @@ cloud.yolo.com : Nextcloud (un service de cloud)
rss.yolo.com : TinyTiny RSS (un lecteur RSS)
wiki.yolo.com : DokuWiki (un wiki)
```
!!! De nombreuses applications intégrent une fonctionnalité qui vous permet de changer l'URL de votre application. Ce choix entre sous-chemin et sous-domaine peut donc dans certains cas être réversible via une simple manipulation dans l'interface d'administration.

View file

@ -9,9 +9,11 @@ routes:
YunoHost allows you to manage and serve several domains on the same server. For instance, you can host a blog and Nextcloud on a first domain `yolo.com`, and a web mail client on a second domain `swag.nohost.me`. Each domain is automatically configured to handle web services, mail services and XMPP services.
Domains can be managed in the 'Domain' section of the webadmin, or through the `yunohost domain` category of the command line. Each time you add a domain, it is expected that you bought it (or own it) on a domain registrar, so you can manage the [DNS configuration](/dns_config). The exception is the [`.nohost.me`, `.noho.st` and `ynh.fr` domains](/dns_nohost_me) which are paid for by the YunoHost Project, and can be directly integrated with YunoHost thanks to an automated dynDNS setup. (To limit costs and abuses, each instance may only have one of these domains setup at any given time).
Domains can be managed in the 'Domain' section of the webadmin, or through the `yunohost domain` category of the command line.
The domain chosen during the postinstall is defined as the main domain of the server : this is where the SSO and the web admin interface will be available. The main domain can later be changed through the web admin in Domains > (the domain) > Set default, or with the command line `yunohost tools maindomain`.
Each time you add a domain, it is expected that you bought it (or own it) on a domain registrar, so you can manage the [DNS configuration](/dns_config). The exception is the [`.nohost.me`, `.noho.st` and `ynh.fr` domains](/dns_nohost_me) which are paid for by the YunoHost Project, and can be directly integrated with YunoHost thanks to an automated dynDNS setup. To limit costs and abuses, each instance may only have one of these domains setup at any given time, however you can add as many sub-domains of it as you wish. For example, if you choose `example.noho.st` you can later add the domains `video.example.noho.st` or `www.example.ynh.noho.st` or any other sub-domain you may need.
The domain chosen during the initial configuration (post-install) is defined as the main domain of the server : this is where the SSO and the web admin interface will be available. The main domain can later be changed through the web admin in Domains > (the domain) > Set default, or with the command line `yunohost tools maindomain`.
Finally, take note that, in the context of YunoHost, there is no hierarchy between the domains it knows. In the previous example, you may add a third domain `foo.yolo.com` - but it would be considered as a domain independent of `yolo.com`.
@ -41,7 +43,9 @@ yolo.com
├── /wiki : DokuWiki (a wiki)
```
Alternatively, you may choose to install each (or some) apps on a dedicated domain. This might look prettier for end users, but is generally considered more complicated and less efficient in the context of YunoHost, since you need to add a new domain each time. Nevertheless, some apps might need an entire domain dedicated to them, for technical reasons.
Alternatively, you may choose to install each (or some) apps on a dedicated domain. Beyond the aesthetic, using sub-domains instead of sub-paths allows the possibility to move a service to another server more easily. Also, some applications may need an entire domain dedicated to them, for technical reasons. The disadvantage is that you have to add a new domain each time, and therefore potentially configure additional DNS records, restart the diagnostics and install a new Let's Encrypt certificate.
This might look prettier for end users, but is generally considered more complicated and less efficient in the context of YunoHost, since you need to add a new domain each time. Nevertheless, some apps might need an entire domain dedicated to them, for technical reasons.
If all apps from the previous example were installed on a separate domain, this would give something like this:
@ -52,3 +56,4 @@ rss.yolo.com : TinyTiny RSS (a RSS reader)
wiki.yolo.com : DokuWiki (a wiki)
```
!!! Many applications integrate a functionality that allows you to change the URL of your application. This choice between subpath and subdomain can be reversed in some cases via a simple manipulation in the administration interface.