Les « Bonnes pratiques Gentoo » proposent-elles une méthode
canonique pour faire tourner deux instances d'Apache, ou dois-je
moi-même faire une copie du RC-script?
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir
reporter moi-même sur la copie les mises à jour effectuées par Portage.
Néanmoins, c'est cette méthode qui évoquée ici:
http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml#doc_chap5
Déjà, il manque un truc dans cette page, à propos de httpd.conf. Au lieu de copier le httpd.conf et de faire quelques modifications, il vaut mieux (AMHA) créer trois fichiers : httpd.conf.commun -> le gros de la config httpd.conf.php4 -> tout ce qui est spécifique à PHP4 + un "Include httpd.conf.commun" httpd.conf.php5 -> idem pour PHP5.
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir reporter moi-même sur la copie les mises à jour effectuées par Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit script qui copie le RC-script mis à jour, en remplaçant "php4" par "php5" au passage.
On Sun, 28 Jan 2007 22:28:17 +0100, Jérémy JUST
<jeremy_just@netcourrier.com>:
Déjà, il manque un truc dans cette page, à propos de httpd.conf.
Au lieu de copier le httpd.conf et de faire quelques modifications, il
vaut mieux (AMHA) créer trois fichiers :
httpd.conf.commun -> le gros de la config
httpd.conf.php4 -> tout ce qui est spécifique à PHP4 + un
"Include httpd.conf.commun"
httpd.conf.php5 -> idem pour PHP5.
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir
reporter moi-même sur la copie les mises à jour effectuées par Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit
script qui copie le RC-script mis à jour, en remplaçant "php4" par
"php5" au passage.
Déjà, il manque un truc dans cette page, à propos de httpd.conf. Au lieu de copier le httpd.conf et de faire quelques modifications, il vaut mieux (AMHA) créer trois fichiers : httpd.conf.commun -> le gros de la config httpd.conf.php4 -> tout ce qui est spécifique à PHP4 + un "Include httpd.conf.commun" httpd.conf.php5 -> idem pour PHP5.
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir reporter moi-même sur la copie les mises à jour effectuées par Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit script qui copie le RC-script mis à jour, en remplaçant "php4" par "php5" au passage.
Jérémy JUST
Le Sun, 28 Jan 2007 22:36:31 +0100,
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir reporter moi-même sur la copie les mises à jour effectuées par Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit script qui copie le RC-script mis à jour, en remplaçant "php4" par "php5" au passage.
Je donnais cette URL comme exemple de doc officielle de Gentoo qui propose de faire la copie manuellement. Je ne compte absolument pas avoir PHP sur mes serveurs, et encore moins en avoir deux versions concurrentes.
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
-- Jérémy JUST
Le Sun, 28 Jan 2007 22:36:31 +0100,
Ce qui m'embête avec cette méthode manuelle, c'est que je vais
devoir reporter moi-même sur la copie les mises à jour effectuées par
Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit
script qui copie le RC-script mis à jour, en remplaçant "php4" par
"php5" au passage.
Je donnais cette URL comme exemple de doc officielle de Gentoo qui
propose de faire la copie manuellement. Je ne compte absolument pas
avoir PHP sur mes serveurs, et encore moins en avoir deux versions
concurrentes.
Mon but est d'avoir une instance pour un intranet/extranet et une
instance publique. Je pense que je pourrais tout faire tourner sur la
même instance, mais je serai plus serein si tout est séparé.
Ce qui m'embête avec cette méthode manuelle, c'est que je vais devoir reporter moi-même sur la copie les mises à jour effectuées par Portage.
Reporter, certes, mais ça peut être fait automatiquement : un petit script qui copie le RC-script mis à jour, en remplaçant "php4" par "php5" au passage.
Je donnais cette URL comme exemple de doc officielle de Gentoo qui propose de faire la copie manuellement. Je ne compte absolument pas avoir PHP sur mes serveurs, et encore moins en avoir deux versions concurrentes.
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
-- Jérémy JUST
Fabien LE LEZ
On Sun, 28 Jan 2007 22:52:48 +0100, Jérémy JUST :
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
On Sun, 28 Jan 2007 22:52:48 +0100, Jérémy JUST
<jeremy_just@netcourrier.com>:
Mon but est d'avoir une instance pour un intranet/extranet et une
instance publique. Je pense que je pourrais tout faire tourner sur la
même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur
privé, mieux vaut mettre une séparation franche et massive (chroot par
exemple).
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28 janvier 2007, vers 23:19, Fabien LE LEZ disait:
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
Avec deux utilisateurs différents. Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur. -- I WILL NOT INSTIGATE REVOLUTION I WILL NOT INSTIGATE REVOLUTION I WILL NOT INSTIGATE REVOLUTION -+- Bart Simpson on chalkboard in episode 7G06
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28
janvier 2007, vers 23:19, Fabien LE LEZ <gramster@gramster.com>
disait:
Mon but est d'avoir une instance pour un intranet/extranet et une
instance publique. Je pense que je pourrais tout faire tourner sur la
même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur
privé, mieux vaut mettre une séparation franche et massive (chroot par
exemple).
Avec deux utilisateurs différents. Voire opter pour une solution style
Xen s'il y a assez de mémoire sur le serveur.
--
I WILL NOT INSTIGATE REVOLUTION
I WILL NOT INSTIGATE REVOLUTION
I WILL NOT INSTIGATE REVOLUTION
-+- Bart Simpson on chalkboard in episode 7G06
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28 janvier 2007, vers 23:19, Fabien LE LEZ disait:
Mon but est d'avoir une instance pour un intranet/extranet et une instance publique. Je pense que je pourrais tout faire tourner sur la même instance, mais je serai plus serein si tout est séparé.
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
Avec deux utilisateurs différents. Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur. -- I WILL NOT INSTIGATE REVOLUTION I WILL NOT INSTIGATE REVOLUTION I WILL NOT INSTIGATE REVOLUTION -+- Bart Simpson on chalkboard in episode 7G06
Jérémy JUST
Le Sun, 28 Jan 2007 23:42:24 +0100,
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
Ce serait effectivement bien, mais quand je mets en balance les avantages que ça apporte avec la galère que c'est à mettre en place (les deux serveurs vont exécuter des programmes en Perl, ce qui voudra dire que Perl et des tas de modules devront apparaître dans le ou les chroot...), je me dis que « plus tard, peut-être ».
Avec deux utilisateurs différents.
C'est ce que je compte faire; ça me semble avoir une bonne valeur ajoutée en terme de sécurité, sans imposer aucune contrainte par ailleurs.
L'idée c'est que le serveur extranet aura accès à des scripts privés, voire à un wiki et un webmail, et que je n'ai pas envie que le serveur public puisse en appeler des bouts. Avec deux utilisateurs aux droits bien séparés, je pense que le but sera atteint.
Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot, avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
-- Jérémy JUST
Le Sun, 28 Jan 2007 23:42:24 +0100,
Si tu penses que l'accès public peut faire courir un risque au
serveur privé, mieux vaut mettre une séparation franche et massive
(chroot par exemple).
Ce serait effectivement bien, mais quand je mets en balance les
avantages que ça apporte avec la galère que c'est à mettre en place
(les deux serveurs vont exécuter des programmes en Perl, ce qui voudra
dire que Perl et des tas de modules devront apparaître dans le ou les
chroot...), je me dis que « plus tard, peut-être ».
Avec deux utilisateurs différents.
C'est ce que je compte faire; ça me semble avoir une bonne valeur
ajoutée en terme de sécurité, sans imposer aucune contrainte par
ailleurs.
L'idée c'est que le serveur extranet aura accès à des scripts privés,
voire à un wiki et un webmail, et que je n'ai pas envie que le serveur
public puisse en appeler des bouts. Avec deux utilisateurs aux droits
bien séparés, je pense que le but sera atteint.
Voire opter pour une solution style Xen s'il y a assez de mémoire sur
le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot,
avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
Si tu penses que l'accès public peut faire courir un risque au serveur privé, mieux vaut mettre une séparation franche et massive (chroot par exemple).
Ce serait effectivement bien, mais quand je mets en balance les avantages que ça apporte avec la galère que c'est à mettre en place (les deux serveurs vont exécuter des programmes en Perl, ce qui voudra dire que Perl et des tas de modules devront apparaître dans le ou les chroot...), je me dis que « plus tard, peut-être ».
Avec deux utilisateurs différents.
C'est ce que je compte faire; ça me semble avoir une bonne valeur ajoutée en terme de sécurité, sans imposer aucune contrainte par ailleurs.
L'idée c'est que le serveur extranet aura accès à des scripts privés, voire à un wiki et un webmail, et que je n'ai pas envie que le serveur public puisse en appeler des bouts. Avec deux utilisateurs aux droits bien séparés, je pense que le but sera atteint.
Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot, avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
-- Jérémy JUST
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28 janvier 2007, vers 23:59, Jérémy JUST disait:
Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot, avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
Pas sûr (pour le côté laborieux). Je ne sais pas où ça en est chez Gentoo, mais sous Debian, c'est extrêmement simple de mettre en place une machine Xen. Un script fait tout le boulot et une fois dans la machine virtuelle, plus besoin de bricoler pour installer la seconde instance d'Apache. Je pense que c'est beaucoup moins compliqué qu'un chroot. Mais comme tu dis, plus de consommation mémoire et plus de consommation disque... -- printk(KERN_WARNING "%s: Short circuit detected on the loben", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28
janvier 2007, vers 23:59, Jérémy JUST <jeremy_just@netcourrier.com>
disait:
Voire opter pour une solution style Xen s'il y a assez de mémoire sur
le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot,
avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
Pas sûr (pour le côté laborieux). Je ne sais pas où ça en est chez
Gentoo, mais sous Debian, c'est extrêmement simple de mettre en place
une machine Xen. Un script fait tout le boulot et une fois dans la
machine virtuelle, plus besoin de bricoler pour installer la seconde
instance d'Apache. Je pense que c'est beaucoup moins compliqué qu'un
chroot. Mais comme tu dis, plus de consommation mémoire et plus de
consommation disque...
--
printk(KERN_WARNING "%s: Short circuit detected on the loben",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 28 janvier 2007, vers 23:59, Jérémy JUST disait:
Voire opter pour une solution style Xen s'il y a assez de mémoire sur le serveur.
Je pense que ça sera aussi laborieux à mettre en place qu'un chroot, avec en plus l'inconvénient que la mémoire n'est plus mutualisée.
Pas sûr (pour le côté laborieux). Je ne sais pas où ça en est chez Gentoo, mais sous Debian, c'est extrêmement simple de mettre en place une machine Xen. Un script fait tout le boulot et une fois dans la machine virtuelle, plus besoin de bricoler pour installer la seconde instance d'Apache. Je pense que c'est beaucoup moins compliqué qu'un chroot. Mais comme tu dis, plus de consommation mémoire et plus de consommation disque... -- printk(KERN_WARNING "%s: Short circuit detected on the loben", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c
Paul Gaborit
À (at) Sun, 28 Jan 2007 22:28:17 +0100, Jérémy JUST écrivait (wrote):
Les « Bonnes pratiques Gentoo » proposent-elles une méthode canonique pour faire tourner deux instances d'Apache, ou dois-je moi-même faire une copie du RC-script?
Je ne connais pas les bonnes pratiques de Gentoo... mais il me semble qu'un Apache seul a tous les mécanismes nécessaires pour gérer le multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs ports, sur plusieurs interfaces ou toute combinaison des critères précédents et en ayant une configuration séparée et même des identités différentes en ce qui concerne les droits d'accès et d'exécution des CGI.
Reste le cas particulier des modules à mettre en oeuvre ou des versions d'Apache qui seraient différentes...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 28 Jan 2007 22:28:17 +0100,
Jérémy JUST <jeremy_just@netcourrier.com> écrivait (wrote):
Les « Bonnes pratiques Gentoo » proposent-elles une méthode
canonique pour faire tourner deux instances d'Apache, ou dois-je
moi-même faire une copie du RC-script?
Je ne connais pas les bonnes pratiques de Gentoo... mais il me semble
qu'un Apache seul a tous les mécanismes nécessaires pour gérer le
multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs ports, sur
plusieurs interfaces ou toute combinaison des critères précédents et
en ayant une configuration séparée et même des identités différentes
en ce qui concerne les droits d'accès et d'exécution des CGI.
Reste le cas particulier des modules à mettre en oeuvre ou des
versions d'Apache qui seraient différentes...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 28 Jan 2007 22:28:17 +0100, Jérémy JUST écrivait (wrote):
Les « Bonnes pratiques Gentoo » proposent-elles une méthode canonique pour faire tourner deux instances d'Apache, ou dois-je moi-même faire une copie du RC-script?
Je ne connais pas les bonnes pratiques de Gentoo... mais il me semble qu'un Apache seul a tous les mécanismes nécessaires pour gérer le multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs ports, sur plusieurs interfaces ou toute combinaison des critères précédents et en ayant une configuration séparée et même des identités différentes en ce qui concerne les droits d'accès et d'exécution des CGI.
Reste le cas particulier des modules à mettre en oeuvre ou des versions d'Apache qui seraient différentes...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Jérémy JUST
Le Mon, 29 Jan 2007 16:21:31 +0100,
il me semble qu'un Apache seul a tous les mécanismes nécessaires pour gérer le multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs ports, sur plusieurs interfaces ou toute combinaison des critères précédents et en ayant une configuration séparée
Je le pense aussi.
et même des identités différentes en ce qui concerne les droits d'accès et d'exécution des CGI.
Ça, je ne savais pas que c'était possible. Ça impose que le processus père (celui qui tourne en root) fasse plus de chose que raisonnable, pour pouvoir forker sous différents usernames, non?
Reste le cas particulier des modules à mettre en oeuvre ou des versions d'Apache qui seraient différentes...
Je ne suis pas dans ce cas.
Non, ma seule justification est que je me sentirai plus en sécurité avec deux instances complètement disjointes.
-- Jérémy JUST
Le Mon, 29 Jan 2007 16:21:31 +0100,
il me semble qu'un Apache seul a tous les mécanismes nécessaires pour
gérer le multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs
ports, sur plusieurs interfaces ou toute combinaison des critères
précédents et en ayant une configuration séparée
Je le pense aussi.
et même des identités différentes en ce qui concerne les droits
d'accès et d'exécution des CGI.
Ça, je ne savais pas que c'était possible.
Ça impose que le processus père (celui qui tourne en root) fasse plus
de chose que raisonnable, pour pouvoir forker sous différents
usernames, non?
Reste le cas particulier des modules à mettre en oeuvre ou des
versions d'Apache qui seraient différentes...
Je ne suis pas dans ce cas.
Non, ma seule justification est que je me sentirai plus en sécurité
avec deux instances complètement disjointes.
il me semble qu'un Apache seul a tous les mécanismes nécessaires pour gérer le multi-sites sur plusieurs IP, plusieurs noms, sur plusieurs ports, sur plusieurs interfaces ou toute combinaison des critères précédents et en ayant une configuration séparée
Je le pense aussi.
et même des identités différentes en ce qui concerne les droits d'accès et d'exécution des CGI.
Ça, je ne savais pas que c'était possible. Ça impose que le processus père (celui qui tourne en root) fasse plus de chose que raisonnable, pour pouvoir forker sous différents usernames, non?
Reste le cas particulier des modules à mettre en oeuvre ou des versions d'Apache qui seraient différentes...
Je ne suis pas dans ce cas.
Non, ma seule justification est que je me sentirai plus en sécurité avec deux instances complètement disjointes.
