Synology Besoin d'aide - Configuration plusieurs sites/domaines sur un seul NAS (DSM7)

[FuRy]

Wahhh, et beh, tu en as fait des choses ^^ et bonnes en plus de mon point de vue.
Ton pare-feu me semble bien configuré ^^

Ca me rassure un peu, je suis pas si nul que ça du coup ... LOL

Avant de tenter l'accès en SSH, regarde les permissions du dossier web depuis FileStation.

... ...

J'avais déjà vérifié les permissions du groupe http via File Station et elles me semblaient correctes.

Je viens d'y retourner et voici un screen :



Le groupe http a l'accès en lecture et en écriture. Ca me semble bon en regardant dans File Station donc.

Du coup, ça devrait suffire pour accéder à tous les fichiers et sous-dossiers du répertoire "Web" non ? Bon bah, ça c'est ce qu'on vérifiera via connexion SSH comme l'a suggéré @cooper... Je suis en train d'activer le service SSH là (plus ou moins en même temps que je répond ici).

@cooper a raison, il y a quelque chose qui bloque l'accès.

Tu ne voudrais pas faire un petit index.html tout simple dans la racine de ce dossier ? Et le même dans un dossier que tu crées pour l'occasion.
Tu reconfigures tes virtualhost pour pointer sur la racine de /web/ pour l'un, et dans le dossier pour l'autre.
Et dis-moi si ça fonctionne ou pas.

C'est déjà comme ça que je teste l'accès à mes sites via leurs noms de domaines (avec un simple fichier index.html). J'en ai un directement dans le dossier Web et j'ai 2 autres fichiers index.html de test dans les 2 sous-dossiers où y'a mes sites web.

Alors pour le test, j'ai tenté ton truc (pointer un Virtual Host vers le index.html du dossier Web, et un autre Virtual Host vers l'index.html situé dans l'un de mes sous-dossiers de sites). Ca change rien, j'ai toujours une erreur 403 comme dans ma config normale.

Et si ça ne fonctionne pas, désactive les redirections de port dans la Livebox pour le NAS, et désactive le pare-feu, et retente.

PS : et là je me dis, que cette dernière chose risque de ne pas fonctionner... car depuis ton LAN, en utilisant le nom de domaine, l'adresse IP que va voir le NAS ce sera celle de ta connexion internet... et la LB risque de ne pas aimer faire ça XD

Je trouvais très bizarre cette idée mais j'ai quand même tenté. Alors là (en enlevant les redirections de la Box et en désactivant le pare-feu), je n'ai plus l'erreur 403 certes mais je perds la protection du certif (plus de HTTPS et message qui dit "connexion non sécurisée bla bla bla"). Et si j'essaie de forcer l'accès non sécu, j'arrive pas à accéder au contenu, ça fait comme une erreur 404 (c'est pire là LOL).

Bref, test non concluant, j'ai remis les redirections de la box et réactivé le pare-feu!


On va passer à autre chose pour trouver une solution. j'espère que le test en SSH de @cooper donnera des indices ou une piste...

 

[FuRy]

Ensuite le renvoi du code HTTP 403 évoque qu'un serveur httpd répond bien mais interdit l'accès à la ressource demandée.

Bah oui c'est pas une 404 ou autre chose (qui dirait que ça ne trouve pas la ressource), c'est une 403. Ce type d'erreur (code 403) m'inspire que la ressource est trouvée mais qu'il y a une interdiction d'accès. Mais d'où vient cette interdiction du coup? C'est là le problème. Droits, permissions, on commence pourtant à avoir testé/réglé pas mal de trucs. J'espère qu'on va finir par trouver

Ensuite le renvoi du code HTTP 403 évoque qu'un serveur httpd répond bien mais interdit l'accès à la ressource demandée.
Tu parles de problèmes de lecture/écriture, c'est très bien mais as-tu vérifié que l'exécution (la possibilité de traverser une hiérarchie de répertoires) soit possible pour atteindre la ressource demandée (le fichier auquel tu souhaites accéder; ici le fichier index.html de ton domaine virtuel) ?

C'est une erreur classique concernant les permissions Unix pour les jeunes webmasters

Assures-toi que tout utilisateur puisse traverser la hiérarchie de répertoires pour accéder à la ressource demandée (le bit "x").

Je me suis connecté par SSH et j'ai surtout commencé par vérifier les permissions en Unix d'abord. J'ai pas fait ça sur un Terminal virtuel mais sur un simple PowerShell sur mon Windaube.

Je comprends et sais lire les permissions de ce type (Unix) mais par contre, je n'avais jamais été confronté aux ACLs (ça je sais pas lire les lettres correspondantes).

Du coup, voici un extrait de ta commande (juste pour l'Unix):

Je ne t'ai pas tout affiché car ça fait pas mal de lignes en tout. Là tu as juste le début pour le contenu du dossier WEB. Plus bas, on voit aussi la même chose pour les sous-dossiers des sites et leur contenu mais j'ai pas tout scroll pour faire un petit screen.

Tout ça me fait réviser un peu les commandes Nunux:

Spoiler: bla bla sur les codes " r w x " ...

On va voir si j'ai pas tout oublié mes cours... Du coup, quand je lis par exemple:

d  rwx  r-x  --- "nombre de fichiers" root  http   "taille"  "date"

- Il me semble que le d au début correspond à un dossier (le - serait pour un fichier)
- Les 3 premiers rwx signifient que le propriétaire (root) a accès en lecture, écriture et exécution
- Les r-x ensuite signifie que le groupe désigné le plus bas dans la hierarchie autorisée (http) a accès en lecture et exécution des fichiers seulement
- Et comme ensuite on a --- (aucune lettre, ni r, ni w, ni x), ça voudrait dire que les autres (hors groupes autorisés) n'ont aucun accès (ni en lecture, écriture ou éxecution)

Bref... stop le hors sujet. Ca me revient quoi...

J'ai essayé d'analyser un peu tout les logs (et surtout les sous-dossiers qu'on voit pas ici dans le screen et leurs fichiers respectifs):

- Quasiment partout le propriétaire est root (ou un de mes comptes principaux), que ce soit dans le dossier racine Web ou dans les sous dossiers de mes sites.

- Dans le dossier principal (Web), le groupe désigné est la plupart du temps root mais dans les sous-dossiers, on voit souvent les groupes http (pour le web) ou users (groupe genérique) pour les droits autorisés (doit y avoir un héritage indirect pour les sous-dossiers).

Il semblerait qu'avec le groupe http, on hérite de droits de root dans les sous-dossier (d) qui nous permettent de Read (r) et Execute (x). A priori, j'ai au minimum des permissions "Read et Execute" ou "Execute" seulement pour tous les fichiers dans les sous-dossiers.

En gros, si je suis bien la logique du truc, tous mes fichiers index.html (même dans les sous-dossiers) sont sensés être lisibles par le groupe http (au minimum) ou au pire par users.

Alors mes sites web devraient marcher!


J'ai pas screen toutes les lignes de permissions Unix ICI mais ça m'a permis de vérifier de mon côté que les permissions semblaient bonnes. Merci pour la piste @cooper.

Par contre même si à défaut de les mettre ici (car ça ferait beaucoup de noms utilisateurs etc à flouter sur le screen), j'ai aussi affiché les permissions avec les ACLs dans ma console (par curiosité): et bien ça fait vraiment beaucoup de lignes à afficher si je voulais les screen (avec tous les users, groupes etc détaillés). Mais bon je sais pas trop les lire ces logs là, c'est dommage (il faudra que j'apprenne même si ça a l'air plus complexe que l'Unix).


Bon là, de toute façon je suis naze (et ça va être dur demain matin). Alors je vais désactiver le SSH de mon NAS (j'ai pas confiance de laisser ça ouvert quand je l'utilise pas) et aller me coucher!


La suite demain !!!!!!

 

[cooper]

Bah oui c'est pas une 404 ou autre chose (qui dirait que ça ne trouve pas la ressource), c'est une 403. Ce type d'erreur (code 403) m'inspire que la ressource est trouvée mais qu'il y a une interdiction d'accès. Mais d'où vient cette interdiction du coup? C'est là le problème. Droits, permissions, on commence pourtant à avoir testé pas mal de trucs. J'espère qu'on va finir par trouver

Tu as la réponse à ta question dans la question
Le code 403 indique bien que le serveur httpd a compris la demande mais refuse l'accès à la ressource (à ne pas confondre avec un code 401).

Ce genre de problème est le plus souvent frustrant car lié à une erreur/oubli assez classique.
De plus Synology utilise nginx comme serveur httpd pour tout ce qui touche aux proxy inversés, DSM et même une interface CGI pour l'utilisation de serveurs httpd alternatifs pour WebStation et cerise sur le gâteau, l'historique n'est pas activé par défaut (que ce soit pour Apache 2.4, 2.2 ou nginx).

Tiens un truc à vérifier et à nous montrer voir :

1. qui parle sur TCP/80, toujours via ssh :

   wget -S --spider http://localhost

2. et qui écoute sur les ports qui nous préoccupes :

   netstat -t tcp -4 -lnp |grep -iE "(:80|443|915|http)"

Bref... stop le hors sujet. Ca me revient quoi...

C'est bien ça

En gros, si je suis bien la logique du truc, tous mes fichiers index.html (même dans les sous-dossiers) sont sensés être lisibles par le groupe http (au minimum) ou au pire par users.

Alors mes sites web devraient marcher!

Tout dépend des ACL sur la racine de ton hôte virtuel (ici : /volume1/web)
Par défaut DSM colle comme permissions Unix 000 ou 777 lorsque l'on change les permissions par son biais.

Pour éviter tout problème avec les ACL qui sont chiantes et inutiles de mon point de vue sur de petits systèmes avec peu d'utilisateurs/groupes, tu colles sur toute la hiérarchie de /volume1/web root comme propriétaire, avec http comme groupe et rwx pour ces deux-là pour les dossiers et rw pour les fichiers.

Pour les dossiers :

find /volume1/web -type d -print0 |xargs -0 chown root:http
find /volume1/web -type d -print0 |xargs -0 chmod 775

Et les fichiers :

find /volume1/web -type f -print0 |xargs -0 chown root:http
find /volume1/web -type f -print0 |xargs -0 chmod 644

J'ai pas screen toutes les lignes de permissions Unix ICI mais ça m'a permis de vérifier de mon côté que les permissions semblaient bonnes. Merci pour la piste @cooper.

Par contre même si à défaut de les mettre ici (car ça ferait beaucoup de noms utilisateurs etc à flouter sur le screen), j'ai aussi affiché les permissions avec les ACLs dans ma console (par curiosité): et bien ça fait vraiment beaucoup de lignes à afficher si je voulais les screen (avec tous les users, groupes etc détaillés). Mais bon je sais pas trop les lire ces logs là, c'est dommage (il faudra que j'apprenne même si ça a l'air plus complexe que l'Unix).

Tu peux retirer l'option "-R" de /bin/ls afin d'afficher uniquement le contenu de /volume1/web et non tout le contenu des sous-répertoires qu'il contient.

Concernant les permissions des ACLs, utilise dans ton shell la commande suivante pour les connaître :

synoacltool

Spoiler

OPTIONS
    ACL Entry Index: >= 0
    ACL Option: [inherit|single]
    ACL Archive Option: is_inherit,is_read_only,is_owner_group,has_ACL,is_support_ACL
    ACL Entry: [user|group|owner|everyone|authenticated_user|system]:name:[allow|deny]:permissions:inherit mode

        Example: user:root:allow:rwx-d---RWc--:fd--
        Example: owner:*:allow:rwx-d---RWc--:fd--

        Fields
            name: user/group name
            ACL Perm: rwxpdDaARWcCo
                 r: (r)ead data
                 w: (w)rite data (create file)
                 x: e(x)ecute
                 p: a(p)pend data (create dir)
                 d: (d)elete
                 D: (D)elete child (only for dir)
                 a: read (a)ttribute (For SMB read-only/hidden/archive/system)
                 A: write (A)ttribute
                 R: (R)ead xattr
                 W: (W)rite xattr
                 c: read a(c)l
                 C: write a(c)l
                 o: get (o)wner ship

            inherit mode: fdin
                 f: (f)ile inherited
                 d: (d)irectory inherited
                 i: (i)nherit only
                 n: (n)o propagate

 

[FuRy]

Spoiler

OPTIONS
    ACL Entry Index: >= 0
    ACL Option: [inherit|single]
    ACL Archive Option: is_inherit,is_read_only,is_owner_group,has_ACL,is_support_ACL
    ACL Entry: [user|group|owner|everyone|authenticated_user|system]:name:[allow|deny]:permissions:inherit mode

        Example: user:root:allow:rwx-d---RWc--:fd--
        Example: owner:*:allow:rwx-d---RWc--:fd--

        Fields
            name: user/group name
            ACL Perm: rwxpdDaARWcCo
                 r: (r)ead data
                 w: (w)rite data (create file)
                 x: e(x)ecute
                 p: a(p)pend data (create dir)
                 d: (d)elete
                 D: (D)elete child (only for dir)
                 a: read (a)ttribute (For SMB read-only/hidden/archive/system)
                 A: write (A)ttribute
                 R: (R)ead xattr
                 W: (W)rite xattr
                 c: read a(c)l
                 C: write a(c)l
                 o: get (o)wner ship

            inherit mode: fdin
                 f: (f)ile inherited
                 d: (d)irectory inherited
                 i: (i)nherit only
                 n: (n)o propagate

Mais c'est super ça: merci pour la liste de correspondances des lettres. Ca va p'tet m'aider à mieux comprendre les lignes de permissions avec ACLs.

Au top !!!

Tout dépend des ACL sur la racine de ton hôte virtuel (ici : /volume1/web)
Par défaut DSM colle comme permissions Unix 000 ou 777 lorsque l'on change les permissions par son biais.

Pour éviter tout problème avec les ACL qui sont chiantes et inutiles de mon point de vue sur de petits systèmes avec peu d'utilisateurs/groupes, tu colles sur toute la hiérarchie de /volume1/web root comme propriétaire, avec http comme groupe et rwx pour ces deux-là pour les dossiers et rw pour les fichiers.

Je crois qu'on a trouvé la solution. J'ai voulu tenter ce que tu m'as dit avant de bosser ce matin.

Pour se faire, je me suis reconnecté en SSH (en root) et j'ai dû me remémorer les commandes unix de gestion de permissions (jai pas fait avec tes lignes de commandes linkées, j'ai tenté de me souvenir et de le faire moi-même). J'avais un peu oublié ça à vrai dire et c'est pas trop mon fort à la base ces parties là: je suis un fainéant qui quand c'est possible utilise plus souvent les interfaces graphiques que les lignes de commandes. Bref...

Alors j'ai utilisé les commandes chown et chgrp pour changer le propriétaire en root et le groupe en http pour le dossier "Web", le sous dossier "Web Images" et les sous-dossiers contenant mes sites.

Je leur ai appliqué les droits avec du chmod et j'ai choisi le réglage suivant : u=rwx, g=rwx, o=x qui me semblait logique (j'ai pas écrit avec les valeurs octales).


Au début, j'ai changé les droits à la main dossiers par dossiers, fichiers par fichiers mais pour certains dossier (comme ceux de mes sites web), j'ai utilisé la récursivité -R pour appliquer aux enfants du dossier.


Bref, j'ai forcé et changé les droits de tout ce qui est contenu dans le dossier Web à la main en lignes de commande! Ca rappelle des souvenirs qui étaient partis loin. J'ai touché seulement au dossier Web du NAS (et à son contenu) mais j'ai touché aux droits de rien d'autres...

Résultat: je déconnecte le SSH après tout ça et redémarre le NAS. Et dès le premier test, mes sites s'affichent en HTTPS quand je tape leur adresses de domaines respectives:




J'ai testé d'abord sur mes appareils en LAN (avec les 2 ordis de cette pièce) et j'étais déjà heureux de voir s'afficher mes diverses pages "test" index.html (vu le temps que j'ai passé sur ce problème) et ensuite j'ai aussi testé en 4G sur un 3ème ordi et sur mon tél qui affiche tous les deux bien mes sites en HTTPS également !!!

C'est super !!!

 

[MilesTEG]

@FuRy Top ça
Vérifie quand même que tu peux encore mettre des fichiers dans /.../web/ et que tu peux encore modifier les fichiers déjà existants, avec ton utilisateur normal ^^

 

[FuRy]

Je suis content que les changements de droits du dossier Web (avec du chmod) aient réglé mon problème d'erreur 403. Mais en y réfléchissant, je trouve ça bizarre d'avoir du passer par là. Normalement ça devrait pouvoir marcher juste avec des réglages dans les paramètres du NAS. Les utilisateurs d'un NAS ne devraient pas être obligé de faire du SSH et des lignes de commandes juste pour mettre une page web en ligne. Ca reste bizarre dans mon cas!

Bon après l'essentiel c'est que ça fonctionne désormais. Mais il reste une part de mystère dans cette histoire (p'tet un truc que j'avais fait en configurant mon NAS en suivant des tutos divers et qu'il fallait pas faire, même si je vois pas quoi là...). Ca marche c'est déjà une victoire en soi.


C'est un truc assez basique de mettre un site en ligne sur un NAS mais je crie victoire car avec cette histoire de 403, ça fait un bon moment que j'essaie de m'acharner à régler le problème! J'ai perdu du temps là dessus!

@FuRy Top ça
Vérifie quand même que tu peux encore mettre des fichiers dans /.../web/ et que tu peux encore modifier les fichiers déjà existants, avec ton utilisateur normal ^^

J'ai vérifié via l'interface graphique du NAS (dans File Station) si j'avais pas foutu la merde. Ce serait con de régler un problème et d'en créer un autre oui... ^^

Effectivement je peux toujours ajouter des fichiers, les éditer, ou les supprimer (j'ai essayé avec des fichiers bidons, ça marche), enfin avec mon compte habituel.

- Mes comptes administrators et le compte root peuvent tout faire dans ce dossier (read, execute mais aussi write). Ainsi ceux que j'utilise de mon côté peuvent ajouter, modifier, supprimer des fichiers.

- Mais les comptes Utilisateurs créés (comme ma femme etc...) ne peuvent que lire et exécuter normalement (pour accéder aux sites comme le groupe http) mais sans pouvoir modifier, supprimer ou créer un fichier. C'est volontaire ça et p'tet que c'était lié à mon problème de droits originel (mes premiers réglages d'avant).

Je devrai vérifier ça sur le PC de ma femme avec son compte connecté au NAS le moment venu.


Mais bon, là maintenant il ne s'agit que d'affiner les permissions et tester les différents comptes et groupes de mon NAS! Le problème a été ciblé et l'histoire d'erreur 403 sur mes pages Web résolue !!!

 

[zypos]

. Normalement ça devrait pouvoir marcher juste avec des réglages dans les paramètres du NAS. Les utilisateurs d'un NAS ne devraient pas être obligé de faire du SSH et des lignes de commandes juste pour mettre une page web en ligne. Ca reste bizarre dans mon cas!

+ 1 là je te rejoins un utilisateur de NAS ne devrais pas avoir recours au SSH . Ton cas me laisse perplexe car dans mon cas avec deux noms de domaines et deux certificats je n'ai pas bricoler avec pour que cela fonctionne

 

[MilesTEG]

+ 1 là je te rejoins un utilisateur de NAS ne devrais pas avoir recours au SSH . Ton cas me laisse perplexe car dans mon cas avec deux noms de domaines et deux certificats je n'ai pas bricoler avec pour que cela fonctionne

Même chose pour moi, je n'ai pas le souvenir d'avoir dû bricoler les permissions du dossier web...
Bon, mon NAS vient d'une version de DSM où ça s'appelait www avant

 

[FuRy]

+ 1 là je te rejoins un utilisateur de NAS ne devrais pas avoir recours au SSH . Ton cas me laisse perplexe car dans mon cas avec deux noms de domaines et deux certificats je n'ai pas bricoler avec pour que cela fonctionne

Oui ça reste bizarre. J'ai forcément dû mal configurer un truc dans mon NAS (côté permissions) au début. C'est dommage d'avoir à rattraper ça via des commandes en SSH. Je serai bien vigilant là dessus à l'avenir.

C'est le but de tout apprentissage
On se casse les dents sur certains soucis, mais on apprend, et on progresse ^^
C'est ce que je dis à mes étudiants/élèves.

De toute façon dans mon nouveau métier de Développeur Web (reconversion pro récente là dedans), c'est plus ou moins mon crédo! On se confronte à des problèmes, bugs ou conflits à résoudre. On fait plus de résolution de problèmes que de code souvent. Parfois on galère un peu mais on finit toujours par progresser en apprenant de nos erreurs ou omissions...


J'ai toujours été autodidacte et débrouillard dans l'informatique depuis les années 80-90 (mais sans jamais non plus être un pro). Là je me suis formé aux langages du web récemment et j'ai appris beaucoup de choses (même si pas facile de refaire un BAC+3 à 42 ans...). C'est un métier en constante évolution (comme l'informatique en général de toute façon) et on passe notre temps à apprendre.

Cette erreur 403 m'a fait perdre pas mal d'heures sur 3 ou 4 jours mais elle m'a encore appris de choses (malgré son côté demeurant "un peu mystérieux" sur certains points, c'est plus ou moins réglé: ça marche quoi).

Spoiler: Plus de bla bla inutile sur le contexte et mes connaissances informatiques

Tout ce qui est Admin Sys / Config réseau etc (où je suis un peu largué) me montre une nouvelle facette du métier où j'suis pas très doué. C'est bien de savoir coder des sites mais c'est bien aussi d'apprendre à les mettre en ligne et gérer l'hébergement etc...

Si je raconte un peu plus ma vie, jusqu'à maintenant la plupart des sites que j'ai mis en ligne l'ont été sur des serveurs mutualisés où toute la config et l'environnement sont pas trop à gérer (y'a juste à s'y connecter en FTP par exemple avec filezilla pour y mettre son site mais pas autant de trucs à gérer que sur un serveur dédié). Héberger de petits sites persos sur un NAS c'est encore différent et ça m'apprend aussi des choses. Bref...

En gros, maintenant, ce problème est résolu! Je n'ai plus qu'à affiner mes permissions et faire d'ultimes vérifs de droits avant de passer à autre chose (mais au moins je peux faire fonctionner mes sites web, c'est niquel).

Mine de rien, même si c'était différent de la résolution de mon problème (ou parfois Hors sujet), tous vos conseils divers et variés m'ont permis de mieux effectuer les configurations de base de mon nouveau NAS (sécurité globale, ports, pare-feu etc...). Y'avait pas mal de trucs à gérer et à savoir pour un débutant... ^^


Un grand grand MERCI à tous
Pour vos idées, solutions et conseils
Et d'avoir pris le temps de me lire et de répondre pour m'aider !!!



PS: Vu que je débute sur ce NAS et que petit à petit je vais utiliser de nouveaux services ou fonctionnalités, j'aurai sûrement encore d'autres questions à poser ou conseils à demander (sur certains paquets etc...). Mais ce sera sur un autre Post que celui-ci !!!

MERCI ENCORE A VOUS !!!

 

[cooper]

Au début, j'ai changé les droits à la main dossiers par dossiers, fichiers par fichiers mais pour certains dossier (comme ceux de mes sites web), j'ai utilisé la récursivité -R pour appliquer aux enfants du dossier.

L'option "-R" de chown/chmod n'était pas nécessaire avec l'utilisation de find(1)
L'essentiel étant que tu ais pu remettre tout ça dans l'ordre.

Ensuite tu peux affiner le propiétaire des fichiers/dossiers maintenant que tout marche.

J'ai testé d'abord sur mes appareils en LAN (avec les 2 ordis de cette pièce) et j'étais déjà heureux de voir s'afficher mes diverses pages "test" index.html (vu le temps que j'ai passé sur ce problème) et ensuite j'ai aussi testé en 4G sur un 3ème ordi et sur mon tél qui affiche tous les deux bien mes sites en HTTPS également !!!

C'est super !!!

Good