Bonne pratique : où mettre le DocumentRoot ?

axel584 · Le 08/03/2015, à 19:55

Bonjour,
J'ai une petite machine personnelle où je voudrai faire du développement php (principalement pour apprendre à utiliser symfony2)
Je voulais savoir quel était le meilleur endroit pour mettre mon DocumentRoot.
Si je le met dans /var/www (comme il est par défaut), je suis obligé d'utiliser sudo pour modifier les fichiers ou intervenir dessus.
Si je le met dans mon /home/axel/www là, j'ai des messages d'erreurs du type "Forbidden You don't have permission to access / on this server."

Mais histoire de faire les choses proprement, je voulais savoir quel est l'endroit conseillé pour mettre ses fichiers php.

Merci pour vos conseils.

Axel

Rufus T. Firefly · Le 08/03/2015, à 20:41

Tu peux le mettre où tu veux.
Si c'est pour bidouiller /home/axel/www convient très bien. Avec les permissions par défaut, qui autorisent "autres" à lire les fichiers, donc aussi apache (qui est un "autre" parmi d'autres de ce point de vue).
Le tout c'est de créer un virtual host adéquat.
Tu peux copier le virtual host par défaut (dans /etc/apache2/sites-available) sous un autre nom. Et tu modifies celui-ci pour tenir compte de ce que tu as décidé, par exemple :

	ServerName toto
	DocumentRoot /home/axel/www/toto
...
	<Directory /home/axel/www/toto/>
...

Je ne donne pas plus d'indications, parce que le détail dépend de la version d'apache (2.4 et 2.2 c'est assez différent, voir ici : http://httpd.apache.org/docs/2.4/ )
N'oublie pas de l'activer (sudo a2ensite ton_site) et de relancer apache

Si c'est pour du sérieux, tu peux faire pareil en local, mais tu installes le site en ligne dans /srv qui est prévu pour... Comme ça tu bidouilles et tu testes en local, et quand c'est bon tu transfères dans /srv. Par exemple...

Dernière modification par Rufus T. Firefly (Le 08/03/2015, à 20:45)

axel584 · Le 09/03/2015, à 09:15

Bonjour,
J'ai Apache 2.4 sur Ubuntu 14.4 LTS.
J'ai un peu du mal à comprendre comment fonctionne la configuration. J'ai bien compris le fait que chaque "site" soit séparé dans un virtual host, mais je ne comprends pas :
- s'il faut une balise <Directory> différente pour chacun d'eux dans le fichier /etc/apache2/apache2.conf
- Quels sont les droits qu'il faut indiquer sur le répertoire /home/axel/www (suivant les sites, je vois du 777,755 ou 644) ?
- Faut il également mettre les mêmes droits sur les autres répertoires parents (/home et /home/axel) ?

J'ai toujours un message "Forbidden You don't have permission to access / on this server."

Merci pour ton aide,

Axel

HP · Le 09/03/2015, à 12:08

En mode de développement, c'est une très mauvaise idée d'utiliser apache… php fonctionne parfaitement en mode serveur (en dev).

tiramiseb · Le 09/03/2015, à 12:48

Salut,

En dev, tu fais ce que tu veux, mais bon cf le commentaire de HP.
En prod, pour que ce soit parfaitement propre il faut mettre les sites sous /srv.

Rufus T. Firefly · Le 09/03/2015, à 12:50

La question essentielle est sémantique. De quoi et de qui parle-t-on ?
Parce qu'en fait il y a plusieurs "intervenants" dans cette histoire et ils jouent des rôles assez différents.

D'abord il y a axel. Lui, ce qu'il cherche à faire, c'est de bidouiller dans des fichiers html/php/css etc. Ça, bien sûr, tu peux le faire chez toi (/home/axel) sans difficultés et sans rien changer. Là-dedans tu peux créer un nouveau répertoire (clic droit), tu peux créer des fichiers, les ouvrir, les modifier, enregistrer tout ça... Et pour cause : ils t'appartiennent, par défaut.
Il suffit d'ouvrir un terminal et de faire :

ls -l

Pour les répertoires tu as quelque chose comme ça :

drwxr-xr-x  2 axel axel

d = directory
rwx pour le propriétaire, r-x pour le groupe du propriétaire et pour les autres (ceux qui ne sont pas le propriétaire et qui n'appartiennent pas à son groupe). Pourquoi r-x ? x permet d'exécuter, en l'occurrence d'ouvrir et de faire la liste de ce qu'il y a dedans et r permet de lire. Si r n'y est pas, on peut voir ce qu'il y a dedans mais on ne peut rien lire (ouvrir)...
A quoi s'ajoutent les droits de chaque fichier :

-rw-r--r--  1 axel axel

Ce sont les mêmes que pour les répertoires : le propriétaire peut lire et écrire (donc modifier), le groupe et les autres ne peuvent que lire.

Second intervenant : Tartempion à Zanzibar qui tape une adresse dans son navigateur (ou toi, quand tu tapes une adresse localhost dans le tien). Via des chemins plus ou moins tortueux, cette requête http arrive sur le port 80 (par défaut) de ta bécane et là, il y a le troisième intervenant qui écoute.

Troisième intervenant : apache.
Il décortique la requête et en conclue qu'on lui demande tel fichier de tel site. Il va chercher dans les virtual hosts si le site en question existe (ServerName, ServerAlias...), et si oui, où sont rangés ses fichiers (DocumentRoot). S'il trouve le fichier demandé, il va le lire, le traiter éventuellement (php), et envoyer tout ça au navigateur de Tartempion à Zanzibar...
Ce qui suppose que apache ait le droit de lire le fichier demandé !

Si tu met tes sites dans /home/axel (ou un sous-répertoire pour que ça fasse moins bordel), par défaut "autres" a le droit de tout lire. Et parmi ces "autres", il y a apache, bien sûr.

Essaye la chose suivante :
1) créer un répertoire test (clic droit -> nouveau répertoire, test
2) ouvre ton éditeur de texte (gedit ou autre) et crée un nouveau fichier qui contient :

<?php
   phpinfo();
?>

Enregistre-le dans le répertoire test sous le nom de index.php (il sera lu automatiquement par apache)

Ensuite tu crées un virtual host dans /etc/apache2/sites-available.
Ça, il faut le faire en mode super utilisateur. Tu relances ton éditeur avec gksudo et tu fabriques le fichier suivant :

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	ServerName test
	DocumentRoot /home/axel/test

	<Directory /home/axel/test/>
		Options FollowSymLinks Indexes MultiViews
		Require all granted
	</Directory>
</VirtualHost>

Puis tu enregistres dans /etc/apache2/sites-available sous le nom de test.conf
J'ai fait au plus simple : bien sûr tu peux paramétrer des tas de trucs là-dedans. Voir ici : http://httpd.apache.org/docs/2.4/fr/
Reste à activer le site (ça crée un lien symbolique dans /etc/apache2/sites-enabled) :

sudo a2ensite test

Puis à recharger la configuration d'apache, pour qu'il en tienne compte

sudo service apache2 reload

Normalement, si tu ne t'es pas planté (ou moi, quelque part), tu peux taper localhost/test dans ton navigateur...

NB : il n'y a aucune raison de bidouiller dans apache2.conf. Si tu regardes la fin de ce fichier, tu verras :

# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

Je pense qu'il n'y a pas besoin d'explication.

Edit : effectivement, si tu veux mettre des sites en ligne (accessibles de l'extérieur), il vaut mieux les mettre dans /srv.
Mais du coup tu les donnes à www-data (apache) et tu n'es pas censé les bidouiller, pendant qu'ils sont en ligne. Donc tu continues à bidouiller chez toi, et quand c'est bon tu transfères dans /srv... Mais c'est un peu l'étape suivante, quand tu commences à maîtriser tout ça...

Dernière modification par Rufus T. Firefly (Le 09/03/2015, à 12:57)

Rufus T. Firefly · Le 09/03/2015, à 13:04

HP a écrit :

En mode de développement, c'est une très mauvaise idée d'utiliser apache… php fonctionne parfaitement en mode serveur (en dev).

S'il n'y a que du php, oui.
Mais s'il s'agit de faire un site, il y a généralement aussi autre chose...

tiramiseb · Le 09/03/2015, à 14:32

De toute façon, PHP pour faire des sites web dynamiques c'est so "XXe siècle"...
On ne fait plus des sites basés sur l'arborescence de fichiers, de nos jours

Rufus T. Firefly · Le 09/03/2015, à 14:41

tiramiseb a écrit :

De toute façon, PHP pour faire des sites web dynamiques c'est so "XXe siècle"...
On ne fait plus des sites basés sur l'arborescence de fichiers, de nos jours

Ah ! Et on fait comment ? Parce que moi j'en suis encore au XX siècle...

tiramiseb · Le 09/03/2015, à 15:02

Pour ma part, j'utilise le framework Flask en Python.
Il y a différents autres frameworks aussi, menfin ce n'est pas mon domaine de prédilection.
Sinon, NodeJS est à la mode...

Rufus T. Firefly · Le 09/03/2015, à 15:09

Ce n'est que ça : on prend des usines à gaz toute faites qu'on configure... C'est pas drôle...
Et moi qui pensais que tu parlais de datadesign responsive monopage, de préférence vintage gamifié, flat, et peut-être même avec une touche de social design ? Less is more, n'est-il pas ?

Dernière modification par Rufus T. Firefly (Le 09/03/2015, à 15:11)

tiramiseb · Le 09/03/2015, à 15:19

Ce n'est que ça : on prend des usines à gaz toute faites qu'on configure... C'est pas drôle...

C'est là qu'on voit que tu ne connais pas : ce ne sont pas des usines à gaz.
Flask pèse 271 ko une fois installé. Une usine à gaz de 271 ko, vraiment !?

Il y a des frameworks usines à gaz, ça ne veut pas dire que tous sont des usines à gaz.

Il y a des motos qui pèsent 300kg à sec, ça ne veut pas dire que toutes les motos pèsent 300 kg.

Rufus T. Firefly · Le 09/03/2015, à 15:56

C'est vrai. Je ne connais pas. Un jour j'avais installé joomla : plus de 30 Mo ! Comme les sites que je fais moi-même doivent arriver à peine aux alentours d'une centaine de ko pour les très gros (bases mysql, images, polices de caractères et autres fanfreluches non comprises, bien sûr)... C'est vrai que ce n'est pas mon boulot et que je fais ça pour m'amuser (même si ça me sert, aussi). Alors par exemple entre ajax et la programmation directe de XMLHttpRequest, je préfère bidouiller avec XMLHttpRequest... C'est plus drôle, je trouve...

tiramiseb · Le 09/03/2015, à 16:16

Bah justement, j'utilise Flask parce que c'est fun.
Et je trouve aussi qu'AngularJS est fun... bien plus que de faire du XMLHttpRequest à la main, mais en effet là on est plutôt dans l'usine à gaz.

Je tiens toutefois à réagir sur ta phrase suivante : « entre ajax et la programmation directe de XMLHttpRequest ». ajax est un concept, c'est tout. Tu penses certainement à un framework javascript qui enrobe ajax...

Rufus T. Firefly · Le 09/03/2015, à 16:55

Ben oui, des machins comme JQuery et autres... que je n'utilise pas davantage... Pour cliquer sur une liste et chercher ce qui correspond à l'item sélectionné, il n'y a vraiment pas besoin de tout ça...

HP · Le 09/03/2015, à 16:56

Rufus T. Firefly a écrit :

HP a écrit :
En mode de développement, c'est une très mauvaise idée d'utiliser apache… php fonctionne parfaitement en mode serveur (en dev).
S'il n'y a que du php, oui.
Mais s'il s'agit de faire un site, il y a généralement aussi autre chose...

Quel est cet autre chose ?
Et pourquoi ne pourrait-il pas être servi par un serveur PHP ?
Sais tu utiliser PHP (Ruby, Python, autre) en tant que serveur ?
Sais tu que Apache n'est pas le seul serveur web existant ?

Rufus T. Firefly · Le 09/03/2015, à 17:04

J'ai toujours utilisé apache comme serveur html mais je sais qu'il y en a d'autres.
Si tu as la doc à propos de php en serveur, je suis preneur...

HP · Le 09/03/2015, à 17:09

http://google.fr/?q=php+as+a+web+server

Rufus T. Firefly · Le 09/03/2015, à 17:48

Merci, mais après essai, ça ne fonctionne pas. J'ai du louper quelque chose...

~/www/facture$ php -S localhost:8000
PHP 5.6.6-2 Development Server started at Mon Mar  9 16:35:30 2015
Listening on http://localhost:8000
Document root is /home/rufus/www/facture
Press Ctrl-C to quit.

Et quand je tape http://localhost:8000/ ou http://localhost:8000/index.php dans firefox : échec de la connexion... Et le terminal n'affiche rien de plus...

Dernière modification par Rufus T. Firefly (Le 09/03/2015, à 17:52)

tiramiseb · Le 09/03/2015, à 18:29

Ben oui, des machins comme JQuery et autres...

Oui, JQuery est une usine à gaz et n'apporte pas énormément de choses.
Pour moi JQuery est du même accabit que PHP : très utilisé, très populaire, mais vraiment pas propre et inférieur à pas mal d'autres technologie.

Mais regarde AngularJS, côté frontend. Ou regarde Flask côté backend. Ça, ce sont des technos sexy !

axel584 · Le 09/03/2015, à 21:07

Merci beaucoup HP.
Je pense que la solution du server php me sera grandement utile.
En fait, je me demandais surtout comment fonctionne les "bonnes pratiques". Car je sais qu'il y a souvent plusieurs façons de faire les choses, et que chaque solution a ses avantages et inconvénients et si demain je suis amené à travailler avec d'autres personnes sur un projet php, il est préférable d'apprendre "la bonne façon de faire".

Quels sont les contraintes de l'utilisation du serveur interne php ? Est ce que ça permet de tout faire fonctionner (Symfony, JQuery etc.) ? Est ce qu'il y a des différences quand on doit passer en prod ? (je ne dis pas que je vais balancer ce que j'ai fait directement en prod sans tester, mais si y'a bcp de différences, ça peut être pénible)

Merci pour tes conseils,

Axel

HP · Le 09/03/2015, à 21:20

axel584 a écrit :

Quels sont les contraintes de l'utilisation du serveur interne php ?

Pas de contrainte particulière… après faut s'en servir pour se faire une idée

axel584 a écrit :

Est ce que ça permet de tout faire fonctionner (Symfony, JQuery etc.) ?

Oui.

axel584 a écrit :

Est ce qu'il y a des différences quand on doit passer en prod ?

Oui. Mais c'est assez léger… cf. 1 (s'en servir pour se faire une idée).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/03/2015, à 19:55

Bonne pratique : où mettre le DocumentRoot ?

#2 Le 08/03/2015, à 20:41

Re : Bonne pratique : où mettre le DocumentRoot ?

#3 Le 09/03/2015, à 09:15

Re : Bonne pratique : où mettre le DocumentRoot ?

#4 Le 09/03/2015, à 12:08

Re : Bonne pratique : où mettre le DocumentRoot ?

#5 Le 09/03/2015, à 12:48

Re : Bonne pratique : où mettre le DocumentRoot ?

#6 Le 09/03/2015, à 12:50

Re : Bonne pratique : où mettre le DocumentRoot ?

#7 Le 09/03/2015, à 13:04

Re : Bonne pratique : où mettre le DocumentRoot ?

#8 Le 09/03/2015, à 14:32

Re : Bonne pratique : où mettre le DocumentRoot ?

#9 Le 09/03/2015, à 14:41

Re : Bonne pratique : où mettre le DocumentRoot ?

#10 Le 09/03/2015, à 15:02

Re : Bonne pratique : où mettre le DocumentRoot ?

#11 Le 09/03/2015, à 15:09

Re : Bonne pratique : où mettre le DocumentRoot ?

#12 Le 09/03/2015, à 15:19

Re : Bonne pratique : où mettre le DocumentRoot ?

#13 Le 09/03/2015, à 15:56

Re : Bonne pratique : où mettre le DocumentRoot ?

#14 Le 09/03/2015, à 16:16

Re : Bonne pratique : où mettre le DocumentRoot ?

#15 Le 09/03/2015, à 16:55

Re : Bonne pratique : où mettre le DocumentRoot ?

#16 Le 09/03/2015, à 16:56

Re : Bonne pratique : où mettre le DocumentRoot ?

#17 Le 09/03/2015, à 17:04

Re : Bonne pratique : où mettre le DocumentRoot ?

#18 Le 09/03/2015, à 17:09

Re : Bonne pratique : où mettre le DocumentRoot ?

#19 Le 09/03/2015, à 17:48

Re : Bonne pratique : où mettre le DocumentRoot ?

#20 Le 09/03/2015, à 18:29

Re : Bonne pratique : où mettre le DocumentRoot ?

#21 Le 09/03/2015, à 21:07

Re : Bonne pratique : où mettre le DocumentRoot ?

#22 Le 09/03/2015, à 21:20

Re : Bonne pratique : où mettre le DocumentRoot ?

Pied de page des forums