Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache, qui a probablement des droits très limités. Quel est l'utilisateur qui fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont les droits sur les fichiers problématiques ? Par quels utilisateurs et groupes sont ils lisibles ?
Bon, j'ai un problème : rien n'a été modifié ce week-end et ce lundi, ça marche. Plus aucune erreur. Ca pourrait paraitre être une bonne nouvelle, mais ça signifie aussi que je suis dans une situation instable.
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard. D'ailleurs, en accédant à cette machine via LAN, je peux lire, écrire, modifier, effacer des fichiers.
Bref, ce matin, ça marche avec le script ci-dessous et je ne sais pas pourquoi.
use strict; print "Content-type: text/htmlnn"; my $file = 'C:/TEST/stats/histo.gif'; if (! -e $file){ print $file." not found : $!"; } else { print $file." found"; } exit 0;
In article <pan.2006.04.01.12.46.27.227832@imaginet.fr>,
eflorac@imaginet.fr says...
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS
ou FAT32. L'utilisateur est loggé en administrateur au moment de la
manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache,
qui a probablement des droits très limités. Quel est l'utilisateur qui
fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont
les droits sur les fichiers problématiques ? Par quels utilisateurs et
groupes sont ils lisibles ?
Bon, j'ai un problème : rien n'a été modifié ce week-end et ce lundi, ça
marche. Plus aucune erreur. Ca pourrait paraitre être une bonne
nouvelle, mais ça signifie aussi que je suis dans une situation
instable.
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il
s'agit de l'administrateur qui est aussi déclaré pour la machine cliente
comme appartenant au groupe "Utilisateurs" standard. D'ailleurs, en
accédant à cette machine via LAN, je peux lire, écrire, modifier,
effacer des fichiers.
Bref, ce matin, ça marche avec le script ci-dessous et je ne sais pas
pourquoi.
use strict;
print "Content-type: text/htmlnn";
my $file = 'C:/TEST/stats/histo.gif';
if (! -e $file){ print $file." not found : $!"; }
else { print $file." found"; }
exit 0;
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache, qui a probablement des droits très limités. Quel est l'utilisateur qui fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont les droits sur les fichiers problématiques ? Par quels utilisateurs et groupes sont ils lisibles ?
Bon, j'ai un problème : rien n'a été modifié ce week-end et ce lundi, ça marche. Plus aucune erreur. Ca pourrait paraitre être une bonne nouvelle, mais ça signifie aussi que je suis dans une situation instable.
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard. D'ailleurs, en accédant à cette machine via LAN, je peux lire, écrire, modifier, effacer des fichiers.
Bref, ce matin, ça marche avec le script ci-dessous et je ne sais pas pourquoi.
use strict; print "Content-type: text/htmlnn"; my $file = 'C:/TEST/stats/histo.gif'; if (! -e $file){ print $file." not found : $!"; } else { print $file." found"; } exit 0;
Asterbing
In article <442e8987$0$13233$, says...
Dans l'article , a dit...
In article , says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests '-e $file' par 'GetAttributes($file, $_)' (C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl use strict; use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! GetAttributes($file, $_) ){ print $file." not found"; } else { print $file." found"; } exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState au moins depuis la version 5.005
HTH
Hum, je ne souhaite pas écrire quelque chose dépendant de l'OS : ce script doit pouvoir être installé sur plateform Win32 qu'Unix flavors (essentiellement FreeBSD).
Bon, sinon, le problème a évolué : rien n'a été modifié ce week-end (dernier script en place ci-dessous) et ce lundi, ça marche. Plus aucune erreur. Ca pourrait paraitre être une bonne nouvelle, mais ça signifie aussi que je suis dans une situation instable. J'aurais préféré avoir un vrai problème à régler :-(
use strict; print "Content-type: text/htmlnn"; my $file = 'C:/TEST/stats/histo.gif'; if (! -e $file){ print $file." not found : $!"; } else { print $file." found"; } exit 0;
In article <442e8987$0$13233$636a55ce@news.free.fr>, jl_morel@bribes.org
says...
Dans l'article <MPG.1e97afee99526c539897bf@news.tiscali.fr>, no@thanks.com a
dit...
In article <MPG.1e97a258a1c807989897bb@news.tiscali.fr>, no@thanks.com
says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le
test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur
certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et
bien dans le chemin donné pour cette station.
#!/usr/bin/perl
use strict;
print "Content-type: text/htmlnn";
my $file = "C:\TEST\stats\histo.gif";
if (! -e $file){ print $file." not found"; }
else { print $file." found"; }
exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests
'-e $file' par 'GetAttributes($file, $_)'
(C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl
use strict;
use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn";
my $file = "C:\TEST\stats\histo.gif";
if (! GetAttributes($file, $_) ){ print $file." not found"; }
else { print $file." found"; }
exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState
au moins depuis la version 5.005
HTH
Hum, je ne souhaite pas écrire quelque chose dépendant de l'OS : ce
script doit pouvoir être installé sur plateform Win32 qu'Unix flavors
(essentiellement FreeBSD).
Bon, sinon, le problème a évolué : rien n'a été modifié ce week-end
(dernier script en place ci-dessous) et ce lundi, ça marche. Plus aucune
erreur. Ca pourrait paraitre être une bonne nouvelle, mais ça signifie
aussi que je suis dans une situation instable. J'aurais préféré avoir un
vrai problème à régler :-(
use strict;
print "Content-type: text/htmlnn";
my $file = 'C:/TEST/stats/histo.gif';
if (! -e $file){ print $file." not found : $!"; }
else { print $file." found"; }
exit 0;
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests '-e $file' par 'GetAttributes($file, $_)' (C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl use strict; use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! GetAttributes($file, $_) ){ print $file." not found"; } else { print $file." found"; } exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState au moins depuis la version 5.005
HTH
Hum, je ne souhaite pas écrire quelque chose dépendant de l'OS : ce script doit pouvoir être installé sur plateform Win32 qu'Unix flavors (essentiellement FreeBSD).
Bon, sinon, le problème a évolué : rien n'a été modifié ce week-end (dernier script en place ci-dessous) et ce lundi, ça marche. Plus aucune erreur. Ca pourrait paraitre être une bonne nouvelle, mais ça signifie aussi que je suis dans une situation instable. J'aurais préféré avoir un vrai problème à régler :-(
use strict; print "Content-type: text/htmlnn"; my $file = 'C:/TEST/stats/histo.gif'; if (! -e $file){ print $file." not found : $!"; } else { print $file." found"; } exit 0;
Emmanuel Florac
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation multi-utilisateurs. L'utilisateur qui est loggé sur la console du serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le gestionnaire des processus pour avoir cette info. Toute opération effectué par le programme "httpd.exe" est faite avec les droits de cet utilisateur. Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody, je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le navigateur et encore moins avec les droits de l'utilisateur actuellement loggé sur la console de la machine. Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du système peuvent avoir des droits également divers et variés, il faut vérifier les propriétés détaillées des fichiers problématiques.
-- Sutor ne ultra Crepidam.
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il
s'agit de l'administrateur qui est aussi déclaré pour la machine cliente
comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation
multi-utilisateurs. L'utilisateur qui est loggé sur la console du
serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur
est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le
gestionnaire des processus pour avoir cette info. Toute opération
effectué par le programme "httpd.exe" est faite avec les droits de cet
utilisateur.
Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le
programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl
et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers
liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody,
je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le
navigateur et encore moins avec les droits de l'utilisateur actuellement
loggé sur la console de la machine.
Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du
système peuvent avoir des droits également divers et variés, il faut
vérifier les propriétés détaillées des fichiers problématiques.
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation multi-utilisateurs. L'utilisateur qui est loggé sur la console du serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le gestionnaire des processus pour avoir cette info. Toute opération effectué par le programme "httpd.exe" est faite avec les droits de cet utilisateur. Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody, je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le navigateur et encore moins avec les droits de l'utilisateur actuellement loggé sur la console de la machine. Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du système peuvent avoir des droits également divers et variés, il faut vérifier les propriétés détaillées des fichiers problématiques.
-- Sutor ne ultra Crepidam.
Asterbing
In article , says...
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation multi-utilisateurs. L'utilisateur qui est loggé sur la console du serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le gestionnaire des processus pour avoir cette info. Toute opération effectué par le programme "httpd.exe" est faite avec les droits de cet utilisateur. Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody, je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le navigateur et encore moins avec les droits de l'utilisateur actuellement loggé sur la console de la machine. Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du système peuvent avoir des droits également divers et variés, il faut vérifier les propriétés détaillées des fichiers problématiques.
Bon, mais quel que soit cet utilisateur associé à httpd.exe, il n'a pas changé entre vendredi et aujourd'hui... Alors, pourquoi donc cela marche-t-il maintenant ?
In article <pan.2006.04.03.19.57.16.559423@imaginet.fr>,
eflorac@imaginet.fr says...
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il
s'agit de l'administrateur qui est aussi déclaré pour la machine cliente
comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation
multi-utilisateurs. L'utilisateur qui est loggé sur la console du
serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur
est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le
gestionnaire des processus pour avoir cette info. Toute opération
effectué par le programme "httpd.exe" est faite avec les droits de cet
utilisateur.
Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le
programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl
et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers
liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody,
je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le
navigateur et encore moins avec les droits de l'utilisateur actuellement
loggé sur la console de la machine.
Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du
système peuvent avoir des droits également divers et variés, il faut
vérifier les propriétés détaillées des fichiers problématiques.
Bon, mais quel que soit cet utilisateur associé à httpd.exe, il n'a pas
changé entre vendredi et aujourd'hui... Alors, pourquoi donc cela
marche-t-il maintenant ?
Le Mon, 03 Apr 2006 10:57:36 +0200, Asterbing a écrit :
Sinon, pour ce qui est de l'utilisateur loggé du côté serveur Apache, il s'agit de l'administrateur qui est aussi déclaré pour la machine cliente comme appartenant au groupe "Utilisateurs" standard.
Non, visiblement tu n'as pas compris la notion de système d'exploitation multi-utilisateurs. L'utilisateur qui est loggé sur la console du serveur, on s'en cogne. Ce qu'on veut, c'est savoir par quel utilisateur est lancé le programme "httpd.exe" d'apache. Il faut regarder dans le gestionnaire des processus pour avoir cette info. Toute opération effectué par le programme "httpd.exe" est faite avec les droits de cet utilisateur. Quand tu utilises un navigateur pour te connecter à ton serveur, c'est le programme "httpd.exe" qui répond. Si tu lui dis de lancer un script perl et d'ouvrir un fichier, il ouvrira le fichier avec les droits particuliers liés à l'utilisateur qui fait tourner le service (Apache, httpd, nobody, je ne sais) et PAS DU TOUT avec les droits de l'utilisateur qui utilise le navigateur et encore moins avec les droits de l'utilisateur actuellement loggé sur la console de la machine. Les fichiers créés sur le disque par chaque utilisateur POTENTIEL du système peuvent avoir des droits également divers et variés, il faut vérifier les propriétés détaillées des fichiers problématiques.
Bon, mais quel que soit cet utilisateur associé à httpd.exe, il n'a pas changé entre vendredi et aujourd'hui... Alors, pourquoi donc cela marche-t-il maintenant ?
