puisque certain trouve que les programme ne doivent pas etre root comment lance apache sans etre root?
En le configurant de manière approprié:
su - web -c "apachectl start"
-- Nicolas Le Scouarnec
Stephane TOUGARD
helios wrote:
c'est comme apache les users passe pas par root les users sont directement connecter au fils sans passer par l'administrateur
Premierement, Apache (avec un seul 'p') ne tourne pas forcement sous root. C'est une configuration possible, mais pas indispensable (meme si c'est celle qu'on utilise le plus souvent).
Il m'arrive souvent de tester des config particulieres d'Apache sans compte root.
Secundo, Apache ne fait que lire des donnees et n'en ecrit pas, si bien que meme en le craquant on ne tombe que dans un environnement ou on a aucun droit en ecriture (pas tres pratique pour craquer quelque chose).
Tertio, Apache ne gere aucune separation des privileges, contrairement a pick. Hors quand un logiciel gere une separation des privilege, cela veut dire qu'a un niveau il a tous les privileges et les accorde aux utilisateurs selon leurs besoins.
Le noyau, par exemple, a tous les privileges sur le file systeme et les accorde aux utilisateur en fonctions des attributs de chaques fichiers.
pick assure une separation des privileges, ce qui veut dire que lorsque tu utilises pick, tu utilises un processus qui a tous les privileges et qui decide si oui ou non il va t'accorder X ou Y. C'est ainsi pour pick et c'est ainsi pour tous les SGBD qui assurent le meme type de fonctionnalites.
Le probleme est que le processus en question a non seulement tous les privileges sur les donnees, mais qu'il a egalement tous les privileges sur le systeme, ce que ne fait AUCUN SGBD un tant soit peu serieux.
Ce que tu n'as pas encore compris, c'est que personne ici n'a mis en doute les performances de pick, sa capacite a gerer de grandes quantites de donnees et sa fiabilite. pick est peut etre un SGBD tres efficace, mais le fait est qu'on ne le saura jamais parce qu'on ne peut pas faire confiance en un programme qui demande les droits root pour se lancer, dont la doc ne dit pas precisement ce qu'il va faire et certainement pas comment l'installer et dont les avocats et representants ont un niveau d'incompetance qui frise l'insulte.
Si au moins tes reponses etaient serieuses et competentes, si tu lisais les articles aux quels tu reponds et si tu expliquais le pourquoi du comment en reconnaissant les points faibles mais en avancant les points forts de pick, il est certains que certains sacrifieraient peut etre un vieux Pentium pour essayer (moi le premier d'ailleurs).
Tout ce que tu reussis, c'est a passer pour un con, incapable de construire une phrase, de lire un article, de poser un argument comprehensible, de mettre une virgule ou un point la ou il faut.
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios wrote:
c'est comme apache les users passe pas par root les users sont directement
connecter au fils sans passer par l'administrateur
Premierement, Apache (avec un seul 'p') ne tourne pas forcement sous
root. C'est une configuration possible, mais pas indispensable (meme si
c'est celle qu'on utilise le plus souvent).
Il m'arrive souvent de tester des config particulieres d'Apache sans
compte root.
Secundo, Apache ne fait que lire des donnees et n'en ecrit pas, si bien
que meme en le craquant on ne tombe que dans un environnement ou on a
aucun droit en ecriture (pas tres pratique pour craquer quelque chose).
Tertio, Apache ne gere aucune separation des privileges, contrairement a
pick. Hors quand un logiciel gere une separation des privilege, cela
veut dire qu'a un niveau il a tous les privileges et les accorde aux
utilisateurs selon leurs besoins.
Le noyau, par exemple, a tous les privileges sur le file systeme et les
accorde aux utilisateur en fonctions des attributs de chaques fichiers.
pick assure une separation des privileges, ce qui veut dire que lorsque
tu utilises pick, tu utilises un processus qui a tous les privileges et
qui decide si oui ou non il va t'accorder X ou Y. C'est ainsi pour pick
et c'est ainsi pour tous les SGBD qui assurent le meme type de
fonctionnalites.
Le probleme est que le processus en question a non seulement tous les
privileges sur les donnees, mais qu'il a egalement tous les privileges
sur le systeme, ce que ne fait AUCUN SGBD un tant soit peu serieux.
Ce que tu n'as pas encore compris, c'est que personne ici n'a mis en
doute les performances de pick, sa capacite a gerer de grandes quantites
de donnees et sa fiabilite. pick est peut etre un SGBD tres efficace,
mais le fait est qu'on ne le saura jamais parce qu'on ne peut pas faire
confiance en un programme qui demande les droits root pour se lancer,
dont la doc ne dit pas precisement ce qu'il va faire et certainement pas
comment l'installer et dont les avocats et representants ont un niveau
d'incompetance qui frise l'insulte.
Si au moins tes reponses etaient serieuses et competentes, si tu lisais
les articles aux quels tu reponds et si tu expliquais le pourquoi du
comment en reconnaissant les points faibles mais en avancant les points
forts de pick, il est certains que certains sacrifieraient peut etre un
vieux Pentium pour essayer (moi le premier d'ailleurs).
Tout ce que tu reussis, c'est a passer pour un con, incapable de
construire une phrase, de lire un article, de poser un argument
comprehensible, de mettre une virgule ou un point la ou il faut.
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans
la gueule depuis que tu postes tes stupidites sur ce forum, tu sois
encore la pour repondre. C'est a croire que tu n'as aucune fierte.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
c'est comme apache les users passe pas par root les users sont directement connecter au fils sans passer par l'administrateur
Premierement, Apache (avec un seul 'p') ne tourne pas forcement sous root. C'est une configuration possible, mais pas indispensable (meme si c'est celle qu'on utilise le plus souvent).
Il m'arrive souvent de tester des config particulieres d'Apache sans compte root.
Secundo, Apache ne fait que lire des donnees et n'en ecrit pas, si bien que meme en le craquant on ne tombe que dans un environnement ou on a aucun droit en ecriture (pas tres pratique pour craquer quelque chose).
Tertio, Apache ne gere aucune separation des privileges, contrairement a pick. Hors quand un logiciel gere une separation des privilege, cela veut dire qu'a un niveau il a tous les privileges et les accorde aux utilisateurs selon leurs besoins.
Le noyau, par exemple, a tous les privileges sur le file systeme et les accorde aux utilisateur en fonctions des attributs de chaques fichiers.
pick assure une separation des privileges, ce qui veut dire que lorsque tu utilises pick, tu utilises un processus qui a tous les privileges et qui decide si oui ou non il va t'accorder X ou Y. C'est ainsi pour pick et c'est ainsi pour tous les SGBD qui assurent le meme type de fonctionnalites.
Le probleme est que le processus en question a non seulement tous les privileges sur les donnees, mais qu'il a egalement tous les privileges sur le systeme, ce que ne fait AUCUN SGBD un tant soit peu serieux.
Ce que tu n'as pas encore compris, c'est que personne ici n'a mis en doute les performances de pick, sa capacite a gerer de grandes quantites de donnees et sa fiabilite. pick est peut etre un SGBD tres efficace, mais le fait est qu'on ne le saura jamais parce qu'on ne peut pas faire confiance en un programme qui demande les droits root pour se lancer, dont la doc ne dit pas precisement ce qu'il va faire et certainement pas comment l'installer et dont les avocats et representants ont un niveau d'incompetance qui frise l'insulte.
Si au moins tes reponses etaient serieuses et competentes, si tu lisais les articles aux quels tu reponds et si tu expliquais le pourquoi du comment en reconnaissant les points faibles mais en avancant les points forts de pick, il est certains que certains sacrifieraient peut etre un vieux Pentium pour essayer (moi le premier d'ailleurs).
Tout ce que tu reussis, c'est a passer pour un con, incapable de construire une phrase, de lire un article, de poser un argument comprehensible, de mettre une virgule ou un point la ou il faut.
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Vincent Bernat
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005, vers 13:38, "helios" disait:
moi je le sait que c'est comme pick mais toi tu comprends que l'usage de pick de root est celui d'appache
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on veut le faire écouter sur le port 80, il y a un processus qui tourne sous root. Ce processus se contente de donner la requête à un des fils. Son code est très simple et audité régulièrement.
PICK ne peut pas tourner entièrement en utilisateur. PICK tourne _entièrement_ sous root parce qu'il "travaille au niveau 0" (entre autres absurdités que vous avez pu débiter). --
pick administration tourne sous root le reste la partie users en users comme apache
Comment la partie user réussit-elle à écrire dans la base (qui est dans un raw device, connerie n°6, je vous le rappelle) ? Elle s'adresse à la partie administration ? Dans ce cas, le backend tourne sous root, le frontend sous un user non privilégié. Avec Apache, le backend tourne en grand majorité avec un user non privilégié (voire en totalité) et le frontend, y'en a pas, c'est un serveur web, pas un machin hybride à gestion d'imprimantes de niveau 0 intégrées.
Si elle ne s'adresse pas à la partie administration, eh bien elle tourne sous root. Si c'est elle qui effectue la requête au niveau 0, elle tourne aussi sous root. Bref, tout tourne sous root et c'est une bouse infâme au niveau sécurité.
C'est quand même amusant de voir que les concepteurs de PICK réécrivent d'OS en OS la gestion des utilisateurs qui est une partie atttribuée au userland mais gardent la gestion de la mémoire virtuelle qui est normalement faite par le noyau. -- BOFH excuse #3: electromagnetic radiation from satellite debris
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005,
vers 13:38, "helios" <helios@com02.com> disait:
moi je le sait que c'est comme pick mais toi tu comprends que l'usage de
pick de root est celui d'appache
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on
veut le faire écouter sur le port 80, il y a un processus qui tourne
sous root. Ce processus se contente de donner la requête à un des
fils. Son code est très simple et audité régulièrement.
PICK ne peut pas tourner entièrement en utilisateur. PICK tourne
_entièrement_ sous root parce qu'il "travaille au niveau 0" (entre
autres absurdités que vous avez pu débiter).
--
pick administration tourne sous root le reste la partie users en users comme
apache
Comment la partie user réussit-elle à écrire dans la base (qui est
dans un raw device, connerie n°6, je vous le rappelle) ? Elle
s'adresse à la partie administration ? Dans ce cas, le backend tourne
sous root, le frontend sous un user non privilégié. Avec Apache, le
backend tourne en grand majorité avec un user non privilégié (voire en
totalité) et le frontend, y'en a pas, c'est un serveur web, pas un
machin hybride à gestion d'imprimantes de niveau 0 intégrées.
Si elle ne s'adresse pas à la partie administration, eh bien elle
tourne sous root. Si c'est elle qui effectue la requête au niveau 0,
elle tourne aussi sous root. Bref, tout tourne sous root et c'est une
bouse infâme au niveau sécurité.
C'est quand même amusant de voir que les concepteurs de PICK
réécrivent d'OS en OS la gestion des utilisateurs qui est une partie
atttribuée au userland mais gardent la gestion de la mémoire virtuelle
qui est normalement faite par le noyau.
--
BOFH excuse #3:
electromagnetic radiation from satellite debris
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005, vers 13:38, "helios" disait:
moi je le sait que c'est comme pick mais toi tu comprends que l'usage de pick de root est celui d'appache
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on veut le faire écouter sur le port 80, il y a un processus qui tourne sous root. Ce processus se contente de donner la requête à un des fils. Son code est très simple et audité régulièrement.
PICK ne peut pas tourner entièrement en utilisateur. PICK tourne _entièrement_ sous root parce qu'il "travaille au niveau 0" (entre autres absurdités que vous avez pu débiter). --
pick administration tourne sous root le reste la partie users en users comme apache
Comment la partie user réussit-elle à écrire dans la base (qui est dans un raw device, connerie n°6, je vous le rappelle) ? Elle s'adresse à la partie administration ? Dans ce cas, le backend tourne sous root, le frontend sous un user non privilégié. Avec Apache, le backend tourne en grand majorité avec un user non privilégié (voire en totalité) et le frontend, y'en a pas, c'est un serveur web, pas un machin hybride à gestion d'imprimantes de niveau 0 intégrées.
Si elle ne s'adresse pas à la partie administration, eh bien elle tourne sous root. Si c'est elle qui effectue la requête au niveau 0, elle tourne aussi sous root. Bref, tout tourne sous root et c'est une bouse infâme au niveau sécurité.
C'est quand même amusant de voir que les concepteurs de PICK réécrivent d'OS en OS la gestion des utilisateurs qui est une partie atttribuée au userland mais gardent la gestion de la mémoire virtuelle qui est normalement faite par le noyau. -- BOFH excuse #3: electromagnetic radiation from satellite debris
Vincent Bernat
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005, vers 13:41, "helios" disait:
Ce qui ne t'a sans doute pas échappé, c'est qu'à un moment donné on passe par "Pick-root", et donc si on parvient à planter celui-ci *avant* qu'il ne lance un Pick-fils, on a les droits root. Ceci n'arrive pas avec Apache car à aucun moment on est en contact avec Apache-root.
c'est comme apache les users passe pas par root les users sont directement connecter au fils sans passer par l'administrateur
Et comme de toute façon, les fils tournent sous root pour pouvoir utiliser le "niveau 0", la "mémoire virtuelle" et accéder aux raw devices, tout le monde est root et une faille dans le bousin permet de passer root directement. Et sans faille, on peut utiliser les exploits locaux puise que le bidule donne un shell à tout le monde.
Mais à part ça, c'est blindé niveau sécu. -- panic("kmem_cache_init(): Offsets are wrong - I've been messed with!"); 2.2.16 /usr/src/linux/mm/slab.c
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005,
vers 13:41, "helios" <helios@com02.com> disait:
Ce qui ne t'a sans doute pas échappé, c'est qu'à un moment donné on
passe par "Pick-root", et donc si on parvient à planter celui-ci *avant*
qu'il ne lance un Pick-fils, on a les droits root. Ceci n'arrive pas
avec Apache car à aucun moment on est en contact avec Apache-root.
c'est comme apache les users passe pas par root les users sont directement
connecter au fils sans passer par l'administrateur
Et comme de toute façon, les fils tournent sous root pour pouvoir
utiliser le "niveau 0", la "mémoire virtuelle" et accéder aux raw
devices, tout le monde est root et une faille dans le bousin permet de
passer root directement. Et sans faille, on peut utiliser les exploits
locaux puise que le bidule donne un shell à tout le monde.
Mais à part ça, c'est blindé niveau sécu.
--
panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
2.2.16 /usr/src/linux/mm/slab.c
OoO Peu avant le début de l'après-midi du vendredi 29 juillet 2005, vers 13:41, "helios" disait:
Ce qui ne t'a sans doute pas échappé, c'est qu'à un moment donné on passe par "Pick-root", et donc si on parvient à planter celui-ci *avant* qu'il ne lance un Pick-fils, on a les droits root. Ceci n'arrive pas avec Apache car à aucun moment on est en contact avec Apache-root.
c'est comme apache les users passe pas par root les users sont directement connecter au fils sans passer par l'administrateur
Et comme de toute façon, les fils tournent sous root pour pouvoir utiliser le "niveau 0", la "mémoire virtuelle" et accéder aux raw devices, tout le monde est root et une faille dans le bousin permet de passer root directement. Et sans faille, on peut utiliser les exploits locaux puise que le bidule donne un shell à tout le monde.
Mais à part ça, c'est blindé niveau sécu. -- panic("kmem_cache_init(): Offsets are wrong - I've been messed with!"); 2.2.16 /usr/src/linux/mm/slab.c
Nicolas George
Vincent Bernat , dans le message , a écrit :
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on veut le faire écouter sur le port 80, il y a un processus qui tourne sous root.
Ce « processus » peut parfaitement être la pile réseau de l'OS hôte, d'ailleurs.
Vincent Bernat , dans le message <m34qadvohe.fsf@neo.luffy.cx>, a
écrit :
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on
veut le faire écouter sur le port 80, il y a un processus qui tourne
sous root.
Ce « processus » peut parfaitement être la pile réseau de l'OS hôte,
d'ailleurs.
Apache peut tourner entièrement en utilisateur. Dans le cas où l'on veut le faire écouter sur le port 80, il y a un processus qui tourne sous root.
Ce « processus » peut parfaitement être la pile réseau de l'OS hôte, d'ailleurs.
helios
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
vu les questions de certains et leur reponses j'ai decouverts que certain
des soit disant expert autoproclame en SGBD confondent : donnee lien champ article attribut fichier bref ne connaisse pas le vocabulaire de gestion de donnes confondent redondance d'information et donnees presente plusieur fois
ne comprennent pas ce qu'est une relation de 1-n ou 1-1
alors en matiere de stupidite ......
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans
la gueule depuis que tu postes tes stupidites sur ce forum, tu sois
encore la pour repondre. C'est a croire que tu n'as aucune fierte.
vu les questions de certains et leur reponses j'ai decouverts que certain
des soit disant expert autoproclame en SGBD confondent : donnee lien champ
article attribut fichier bref ne connaisse pas le vocabulaire de gestion de
donnes confondent redondance d'information et donnees presente plusieur fois
ne comprennent pas ce qu'est une relation de 1-n ou 1-1
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
vu les questions de certains et leur reponses j'ai decouverts que certain
des soit disant expert autoproclame en SGBD confondent : donnee lien champ article attribut fichier bref ne connaisse pas le vocabulaire de gestion de donnes confondent redondance d'information et donnees presente plusieur fois
ne comprennent pas ce qu'est une relation de 1-n ou 1-1
alors en matiere de stupidite ......
Stephane TOUGARD
helios wrote:
alors en matiere de stupidite ......
Non mais, je tiens a te rassurer, on en dit tous. Mais toi, t'es quand meme completement hors concours.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios wrote:
alors en matiere de stupidite ......
Non mais, je tiens a te rassurer, on en dit tous. Mais toi, t'es quand
meme completement hors concours.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
Non mais, je tiens a te rassurer, on en dit tous. Mais toi, t'es quand meme completement hors concours.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Vincent Bernat
OoO En ce début d'après-midi nuageux du vendredi 29 juillet 2005, vers 14:02, Stephane TOUGARD disait:
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
Il y a certaines questions auxquelles il ne répond pas. Je crois qu'il faut y coller l'un de ces mots-clefs : - niveau 0 - séparation des privilèges - mémoire virtuelle -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En ce début d'après-midi nuageux du vendredi 29 juillet 2005, vers
14:02, Stephane TOUGARD <stephane@unices.org> disait:
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans
la gueule depuis que tu postes tes stupidites sur ce forum, tu sois
encore la pour repondre. C'est a croire que tu n'as aucune fierte.
Il y a certaines questions auxquelles il ne répond pas. Je crois qu'il
faut y coller l'un de ces mots-clefs :
- niveau 0
- séparation des privilèges
- mémoire virtuelle
--
die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En ce début d'après-midi nuageux du vendredi 29 juillet 2005, vers 14:02, Stephane TOUGARD disait:
Ce qui me surprend le plus, c'est qu'avec tout ce que tu t'es pris dans la gueule depuis que tu postes tes stupidites sur ce forum, tu sois encore la pour repondre. C'est a croire que tu n'as aucune fierte.
Il y a certaines questions auxquelles il ne répond pas. Je crois qu'il faut y coller l'un de ces mots-clefs : - niveau 0 - séparation des privilèges - mémoire virtuelle -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
Guillaume
Stephane Zuckerman a wroté :
On peut d'ailleurs le faire tourner sur un port non privilegie en tant qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache, c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette technique et pourquoi n'est elle pas systématiquement employée ?
L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse sur le port 80 ("well-known ports", tout ça).
Ben oui, mais si on _redirige_ le trafic, genre avec iptables ?
-- Guillaume, intéressé aussi.
Stephane Zuckerman a wroté :
On peut d'ailleurs le faire tourner sur un port non privilegie en tant
qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache,
c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette
technique et pourquoi n'est elle pas systématiquement employée ?
L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse
sur le port 80 ("well-known ports", tout ça).
Ben oui, mais si on _redirige_ le trafic, genre avec iptables ?
On peut d'ailleurs le faire tourner sur un port non privilegie en tant qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache, c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette technique et pourquoi n'est elle pas systématiquement employée ?
L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse sur le port 80 ("well-known ports", tout ça).
Ben oui, mais si on _redirige_ le trafic, genre avec iptables ?
-- Guillaume, intéressé aussi.
Stephane Zuckerman
Stephane TOUGARD nous narrait:
On peut d'ailleurs le faire tourner sur un port non privilegie en tant qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache, c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette technique et pourquoi n'est elle pas systématiquement employée ? L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse
sur le port 80 ("well-known ports", tout ça).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Stephane TOUGARD nous narrait:
On peut d'ailleurs le faire tourner sur un port non privilegie en tant
qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache,
c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette
technique et pourquoi n'est elle pas systématiquement employée ?
L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse
sur le port 80 ("well-known ports", tout ça).
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
On peut d'ailleurs le faire tourner sur un port non privilegie en tant qu'user normal et rediriger le port 80 vers le port d'ecoute d'Apache, c'est une solution extremement sure.
Tiens c'est intéressant.
Vu que je suis newbie avec apache, y a-t'il des inconvénients à cette technique et pourquoi n'est elle pas systématiquement employée ? L'inconvénient majeur c'est que l'usage veut que le trafic Web se fasse
sur le port 80 ("well-known ports", tout ça).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
