Merci pour ton aide!
As-tu une idée concernant le pb d’accès via le réseau local ?
Est-ce que cela vient aussi de la config dans le fichier sub.mydomain.com.conf sur ynh-main ?
Regarde ce que renvoie, depuis un pc de ton réseau local, dig laptop.mydomain.com
As-tu déjà eu des problèmes pour accéder sur ton réseau local à tes noms de domaines ?
As-tu un pi-hole? adguard installé?
Tu peux débuguer en mettant sur le /etc/hosts de la machine sur laquelle tu veux joindre l’adresse laptop.mydomain.com:
192.168.1.123 laptop.mydomain.com
Je n’ai pas de pc sous linux donc voici le résultat d’un commande similaire sous windows :
PS C:\Users\franc> nslookup -debug laptop.mydomain.com
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
254.1.168.192.in-addr.arpa, type = PTR, class = IN
------------
Serveur : UnKnown
Address: 192.168.1.254
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 0
QUESTIONS:
laptop.mydomain.com, type = A, class = IN
ANSWERS:
-> laptop.mydomain.com
canonical name = mydomain.com
ttl = 1884 (31 mins 24 secs)
-> mydomain.com
internet address = 82.XX.XX.XXX
ttl = 1884 (31 mins 24 secs)
------------
Réponse ne faisant pas autorité :
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 0
QUESTIONS:
laptop.mydomain.com, type = AAAA, class = IN
ANSWERS:
-> laptop.mydomain.com
canonical name = mydomain.com
ttl = 3600 (1 hour)
-> mydomain.com
AAAA IPv6 address = 2a01:XXXXXXXXXXXXXXXXXXXX
ttl = 3600 (1 hour)
------------
Nom : mydomain.com
Addresses: 2a01:XXXXXXXXXXXXXXXXXXXXXX
82.XX.XX.XXX
Aliases: laptop.mydomain.com
Oui mais seulement avec ynh-test, les domaines de type .local, après un reboot du serveur tu ne peux plus y accéder, c’est un pb connu, la parade consiste à ajouter des lignes “ip domain.local” dans le /etc/hosts de la machine avec laquelle tu veux joindre le ou les domaines .local.
Non rien de tout ça.
Je viens de le faire sur mon pc, mais ça ne donne rien, j’arrive toujours sur la page nginx Welcome etc…
Edit : après un diag sur ynh-test, j’avais un pb d’accès sous IPv4 seulement, la freebox n’a pas dû faire son boulot, j’ai reboot ynh-test pour qu’il récupère son adresse ipv4 et maintenant tout fonctionne parfaitement.
Merci beaucoup!
Y compris en navigation privée/en effaçant les cookies/depuis un autre navigateur?
Désolé de ces questions basiques…
Pas de pb! je viens d’éditer mon post précédent, pour une raison inconnue ynh-test n’avait plus d’ipv4 seulement une ipv6… Je l’ai reboot et maintenant tout fonctionne!
Merci beaucoup !
Ré-so-lu… Ouf.
Une dernière question, j’imagine que je dois répéter la même chose pour accéder à tous les sub.domain.com hébergés sur ynh-test ? Faut-il également installer Redirect sur chacun d’eux (sur le ynh-main)?
Edit : Je confirme, il faut également installer Redirect sur chacun des sub.domain.com sur le ynh-main.
Pour plus de clarté pour les futurs personnes recherchant cette solution, j’ajoute le modèle du fichier sub.domain.com.conf situé dans /etc/nginx/conf.d de la machine principale, il faudra remplacer les “sub.domain.com” par le votre :
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80;
listen [::]:80;
server_name sub.domain.com;
# access_by_lua_file /usr/share/ssowat/access.lua;
include /etc/nginx/conf.d/acme-challenge.conf.inc;
location ^~ '/.well-known/ynh-diagnosis/' {
alias /var/www/.well-known/ynh-diagnosis/;
}
location ^~ '/.well-known/autoconfig/mail/' {
alias /var/www/.well-known/sub.domain.com/autoconfig/mail/;
}
include /etc/nginx/conf.d/sub.domain.com.d/*.conf;
include /etc/nginx/conf.d/yunohost_http_errors.conf.inc;
access_log /var/log/nginx/sub.domain.com-access.log;
error_log /var/log/nginx/sub.domain.com-error.log;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name sub.domain.com;
include /etc/nginx/conf.d/security.conf.inc;
ssl_certificate /etc/yunohost/certs/sub.domain.com/crt.pem;
ssl_certificate_key /etc/yunohost/certs/sub.domain.com/key.pem;
more_set_headers "Strict-Transport-Security : max-age=63072000; includeSubDomains; preload";
# OCSP settings
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/yunohost/certs/sub.domain.com/crt.pem;
resolver 1.1.1.1 9.9.9.9 valid=300s;
resolver_timeout 5s;
location ^~ '/.well-known/autoconfig/mail/' {
alias /var/www/.well-known/sub.domain.com/autoconfig/mail/;
}
# access_by_lua_file /usr/share/ssowat/access.lua;
include /etc/nginx/conf.d/sub.domain.com.d/*.conf;
# include /etc/nginx/conf.d/yunohost_sso.conf.inc;
# include /etc/nginx/conf.d/yunohost_admin.conf.inc;
# include /etc/nginx/conf.d/yunohost_api.conf.inc;
include /etc/nginx/conf.d/yunohost_http_errors.conf.inc;
access_log /var/log/nginx/sub.domain.com-access.log;
error_log /var/log/nginx/sub.domain.com-error.log;
}
Merci encore @otm33
PS : l’idéal serait une mise à jour de l’app Redirect pour quelle modifie le sub.domain.com.conf concerné à l’installation.
Ce sera la même démarche, oui.
On est quand même sur un cas d’usage très spécifique là… 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.