Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
<Mode fanboy>
Dâtâfaçon, Apache, câest tout pourri, ç a bouffe plein de CPU et
de RAM, lighty câest âachement mieux.
</>
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
<Mode fanboy>
Dâtâfaçon, Apache, câest tout pourri, ç a bouffe plein de CPU et
de RAM, lighty câest âachement mieux.
</>
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
<Mode fanboy>
Dâtâfaçon, Apache, câest tout pourri, ç a bouffe plein de CPU et
de RAM, lighty câest âachement mieux.
</>
less /tmp/TST/apache2/sites-available/default […]
^^^^^^^^^
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
c’était bien le cas dans Squeeze.
Ça ressemble à une régression de sécurité.
Questions :
1. Est-ce que default est toujours servi quand il y a un autre
site « enabled » ?
2. Est-ce qu’il y a quelque chose à ce propos dans le(s)
changelog ? dans le BTS ?
<Mode fanboy>
D’t’façon, Apache, c’est tout pourri, ça bouffe plein de CPU et
de RAM, lighty c’est ’achement mieux.
</>
less /tmp/TST/apache2/sites-available/default […]
^^^^^^^^^
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
c’était bien le cas dans Squeeze.
Ça ressemble à une régression de sécurité.
Questions :
1. Est-ce que default est toujours servi quand il y a un autre
site « enabled » ?
2. Est-ce qu’il y a quelque chose à ce propos dans le(s)
changelog ? dans le BTS ?
<Mode fanboy>
D’t’façon, Apache, c’est tout pourri, ça bouffe plein de CPU et
de RAM, lighty c’est ’achement mieux.
</>
less /tmp/TST/apache2/sites-available/default […]
^^^^^^^^^
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
c’était bien le cas dans Squeeze.
Ça ressemble à une régression de sécurité.
Questions :
1. Est-ce que default est toujours servi quand il y a un autre
site « enabled » ?
2. Est-ce qu’il y a quelque chose à ce propos dans le(s)
changelog ? dans le BTS ?
<Mode fanboy>
D’t’façon, Apache, c’est tout pourri, ça bouffe plein de CPU et
de RAM, lighty c’est ’achement mieux.
</>
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
Justement non, un server http digne de ce nom _devrait_ bloquer
toutes les requêtes ne concernant pas un vhost désigné (et d°
pour l'accès par adresse IP).
Je viens de faire le test avec nginx en virant tous les symlinks
de site-enabled: aucun accès possible; et pour cause, les ports
utilisés se trouvent dans les *.conf de site-available et pas
ailleurs.
Alors ton PB ne viendrait-il pas du contenu de ports.conf, qui
contient des directives qui, sans doute, ne devraient pas s'y
trouver?
(enfin bon, la logique d'apache2 lui reste propre).
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
Justement non, un server http digne de ce nom _devrait_ bloquer
toutes les requêtes ne concernant pas un vhost désigné (et d°
pour l'accès par adresse IP).
Je viens de faire le test avec nginx en virant tous les symlinks
de site-enabled: aucun accès possible; et pour cause, les ports
utilisés se trouvent dans les *.conf de site-available et pas
ailleurs.
Alors ton PB ne viendrait-il pas du contenu de ports.conf, qui
contient des directives qui, sans doute, ne devraient pas s'y
trouver?
(enfin bon, la logique d'apache2 lui reste propre).
En revanche, le « nouveau » vhost "test" est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost "test".
Mais j'imagine que ça c'est normal, non ? Le paramètre
"ServerName" sert à apache pour trouver le meilleur vhost
à desservir en fonction de la requête, mais si rien ne
matche, il va quand même prendre un vhost (activé) pour
desservir des pages. J'ai bon ?
Justement non, un server http digne de ce nom _devrait_ bloquer
toutes les requêtes ne concernant pas un vhost désigné (et d°
pour l'accès par adresse IP).
Je viens de faire le test avec nginx en virant tous les symlinks
de site-enabled: aucun accès possible; et pour cause, les ports
utilisés se trouvent dans les *.conf de site-available et pas
ailleurs.
Alors ton PB ne viendrait-il pas du contenu de ports.conf, qui
contient des directives qui, sans doute, ne devraient pas s'y
trouver?
(enfin bon, la logique d'apache2 lui reste propre).
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
nginx et apache2 sont 2 logiciels distincts. Ce n'est pas parce
que l'un se comporte d'une certaine manière que l'autre doit
faire de même. Si on commence à partir sur des comparaisons,
on est mal barré. :-)
> (enfin bon, la logique d'apache2 lui reste propre).
Et c'est justement cette logique là (celle d'apache2) que
je cherche à comprendre.
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
nginx et apache2 sont 2 logiciels distincts. Ce n'est pas parce
que l'un se comporte d'une certaine manière que l'autre doit
faire de même. Si on commence à partir sur des comparaisons,
on est mal barré. :-)
> (enfin bon, la logique d'apache2 lui reste propre).
Et c'est justement cette logique là (celle d'apache2) que
je cherche à comprendre.
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
nginx et apache2 sont 2 logiciels distincts. Ce n'est pas parce
que l'un se comporte d'une certaine manière que l'autre doit
faire de même. Si on commence à partir sur des comparaisons,
on est mal barré. :-)
> (enfin bon, la logique d'apache2 lui reste propre).
Et c'est justement cette logique là (celle d'apache2) que
je cherche à comprendre.
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
Hem, qu'un svr http se permette de renvoyer une page par
défaut alors qu'il n'a aucune conf de vhost me paraît
_extrêmement_ plus inquiétant que... [re-couic]
Je conçois que quelqu'un reste attaché à un daemon, surtout si
cet attachement est lié au pro (difficile de migre rapidement)
mais si apache2 fait effectivement comme tu le décris, je
trouve ça très dangereux.
Bon, là ça devient stérile parce qu'on suppute (de luxe,
mais on suppute qd même), alors ne reste plus qu'à analyser
le(s) source(s), ou plus exactement tracer ce qu'il fait
avec un debugger.
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
Hem, qu'un svr http se permette de renvoyer une page par
défaut alors qu'il n'a aucune conf de vhost me paraît
_extrêmement_ plus inquiétant que... [re-couic]
Je conçois que quelqu'un reste attaché à un daemon, surtout si
cet attachement est lié au pro (difficile de migre rapidement)
mais si apache2 fait effectivement comme tu le décris, je
trouve ça très dangereux.
Bon, là ça devient stérile parce qu'on suppute (de luxe,
mais on suppute qd même), alors ne reste plus qu'à analyser
le(s) source(s), ou plus exactement tracer ce qu'il fait
avec un debugger.
si une
requête ne matche avec aucun "ServerName" d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
Hem, qu'un svr http se permette de renvoyer une page par
défaut alors qu'il n'a aucune conf de vhost me paraît
_extrêmement_ plus inquiétant que... [re-couic]
Je conçois que quelqu'un reste attaché à un daemon, surtout si
cet attachement est lié au pro (difficile de migre rapidement)
mais si apache2 fait effectivement comme tu le décris, je
trouve ça très dangereux.
Bon, là ça devient stérile parce qu'on suppute (de luxe,
mais on suppute qd même), alors ne reste plus qu'à analyser
le(s) source(s), ou plus exactement tracer ce qu'il fait
avec un debugger.
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
Ãa veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
Ãa veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
Ãa veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
D'après
http://www.linux-france.org/prj/edu/archinet/systeme/ch16s02.html
c'est 'default'.
Ça veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est (en partie) là que nous ne sommes plus d'accord,
un peu comme la policy par défaut d'un firewall.
Pour ma part , je préfère (et de loin) le tout interdit
et on ne laisse passer que ce dont on a besoin, au on
laisse tout passer et on interdit le cas échéant.
Te coller une ouverture sur "un site par défaut" me
semble un manque flagrant de liberté autant qu'un
risque de sécurité si tu ne le sais pas.
Sans compter que
http://httpd.apache.org/docs/current/fr/suexec.html
dans la Sion "Utilisation de suEXEC" indique que si
tu n'as pas de directive 'SuexecUserGroup' , ce sont
les droits par défaut dudit 'server Pal' qui sont
utilisés (et s'il n'est pas présent, ce sont les droits
de root???)
Comprenons nous bien, je me tape que tu t'accroches à
apache2 comme un perdu
ce que je conteste (entre autres)
c'est qu'il impose le passage par un 'server Pal' obligatoire.
(un peu comme si ton garagiste exigeait d'être payé en
avance, uniquement en cash et en coupures de €5).
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
D'après
http://www.linux-france.org/prj/edu/archinet/systeme/ch16s02.html
c'est 'default'.
Ça veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est (en partie) là que nous ne sommes plus d'accord,
un peu comme la policy par défaut d'un firewall.
Pour ma part , je préfère (et de loin) le tout interdit
et on ne laisse passer que ce dont on a besoin, au on
laisse tout passer et on interdit le cas échéant.
Te coller une ouverture sur "un site par défaut" me
semble un manque flagrant de liberté autant qu'un
risque de sécurité si tu ne le sais pas.
Sans compter que
http://httpd.apache.org/docs/current/fr/suexec.html
dans la Sion "Utilisation de suEXEC" indique que si
tu n'as pas de directive 'SuexecUserGroup' , ce sont
les droits par défaut dudit 'server Pal' qui sont
utilisés (et s'il n'est pas présent, ce sont les droits
de root???)
Comprenons nous bien, je me tape que tu t'accroches à
apache2 comme un perdu
ce que je conteste (entre autres)
c'est qu'il impose le passage par un 'server Pal' obligatoire.
(un peu comme si ton garagiste exigeait d'être payé en
avance, uniquement en cash et en coupures de €5).
C'est quoi le "serveur principal" ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de "serveur
principal", je ne vois pas.
D'après
http://www.linux-france.org/prj/edu/archinet/systeme/ch16s02.html
c'est 'default'.
Ça veut juste dire qu'il faut bien prendre la peine de
définir un site par défaut qui attraper tout ce qui
ne s'adressera pas aux vhosts qu'on a définis.
C'est (en partie) là que nous ne sommes plus d'accord,
un peu comme la policy par défaut d'un firewall.
Pour ma part , je préfère (et de loin) le tout interdit
et on ne laisse passer que ce dont on a besoin, au on
laisse tout passer et on interdit le cas échéant.
Te coller une ouverture sur "un site par défaut" me
semble un manque flagrant de liberté autant qu'un
risque de sécurité si tu ne le sais pas.
Sans compter que
http://httpd.apache.org/docs/current/fr/suexec.html
dans la Sion "Utilisation de suEXEC" indique que si
tu n'as pas de directive 'SuexecUserGroup' , ce sont
les droits par défaut dudit 'server Pal' qui sont
utilisés (et s'il n'est pas présent, ce sont les droits
de root???)
Comprenons nous bien, je me tape que tu t'accroches à
apache2 comme un perdu
ce que je conteste (entre autres)
c'est qu'il impose le passage par un 'server Pal' obligatoire.
(un peu comme si ton garagiste exigeait d'être payé en
avance, uniquement en cash et en coupures de €5).