Re: Problème PHP

2003-01-07 Par sujet Marc SCHAEFER
On Mon, Jan 06, 2003 at 09:03:16PM +0100, Francis Olof Garnier wrote:

 Est-ce que quelqu'un aurait une piste à suivre ?

Aucune. Je profite simplement de cette discussion pour te demander
si tu as déjà essayé Fink:

   http://fink.sourceforge.net/

il s'agit de packages Debian préparés pour installation via apt-get et
consorts mais *sous MacOSX*.

Par rapport à installer un système multi-boot avec Debian GNU/Linux
PPC, cela a probablement des avantages certains.

Peut-être ont-ils des packages Apache (encore que dans le cas
présent je ne pense pas que cela puisse être le problème. Juste pour
être sûr: système de fichier ufs ou hpfs ?).

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: echo off dans un service

2003-01-07 Par sujet Marc SCHAEFER
On Tue, Jan 07, 2003 at 12:28:15PM +0100, Jean-Claude Schopfer wrote:

 J'ai un chtit problème en shell (bash) : 

En fait, le problème est que stty effectue des ioctl(2)s sur un
descripteur de fichier: ces instructions de méta-données ne sont
pas des lectures et écriture.

Et une connexion réseau (un descripteur de connexion réseau, si l'on veut)
n'offre pas ces fonctionnalités: juste read(2), write(2).

 Est-ce quelqu'un a une idée ?

Deux façons:

   si on s'y connecte par telnet, il faut envoyer au client telnet
   distant WONT ECHO (une séquence d'échappement).

   lancer ton service à travers un pty (pseudo-tty), par exemple
   en créant un service qui est un login UNIX accessible par
   telnet ou ssh: telnetd s'occupera alors de la séquence WONT ECHO.

La première façon est probablement la plus simple.

 J'ai remarqué aussi q une tentative d'interruption du service
 par la partie cliente par CTRL + C|D lors du read ne fonctionne
 pas ce qui est une bonne chose. Est-ce 100 % fiable ou dois-je
 quand même traper ?

CTRL-C et D sont des touches, qui correspondent grâce au pilote
clavier et à la configuration du tty à interruption et fin de
fichier. De nouveau, un socket n'a pas ces fonctionnalités. CTRL-C,
D, DEL, CTRL-Z et autres sont des caractères qui sont transmis par
le client telnet (ou interprétés localement).

Eventuellement certains pourraient être transmis comme séquence
d'échappement TELNET que tu verrais comme une suite de caractères
dont le premier est un code non affichable.

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: echo off dans un service

2003-01-07 Par sujet Daniel Cordey
On Tuesday 07 January 2003 12:28, Jean-Claude Schopfer wrote:

 J'ai remarqué aussi q une tentative d'interruption du service
 par la partie cliente par CTRL + C|D lors du read ne fonctionne
 pas ce qui est une bonne chose. Est-ce 100 % fiable ou dois-je
 quand même traper ?

Q'utilises-tu comme client ? Suivant les clients, le mode de transmission des 
CTRL-chars peut changer. Ah... le daemon dont tu parles est lancé par 
inetd... ce qui fait qu'il n'y a pas de tty/pty pour gérer tom stty.

Daniel

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Gestions de clés avec GPG

2003-01-07 Par sujet Yann SOUCHON
Salut à tous,

Je suis en train d'étudier la mise en oeuvre d'un système pour chiffrer
les emails. Jusqu'à là, rien de bien compliqué. Le problème vient de la
gestion des clés. 
J'ai deux solutions qui me viennent à l'idée :

1. PGP.com
PGP.com fournit dans sa version Enterprise un ensemble de logiciels qui
permet de chiffrer, déchiffrer et de gérer les clés. La gestion des clés
s'effectuent grâce à leur Keyserver qui est une PKI qui fonctionne avec
LDAP.

2. GPG
Je désire proposer cette solution, mais le problème vient de la gestion
des clés. Comment gérer un millier de clés par exemple ? 
Est-ce que quelqu'un aurait une solution qui resemblerait à celle de
PGP.com ? Y a-t-il un moyen de gérer les clés grâce aux PKI OpenSource
(IDX-PKI ou NewPKI) ?

En cherchant sur Google, je suis tombé sur un email d'une présentation qui
s'est passé à Berne au mois de Juin 2002. L'auteur de cette présentation
est Marc :)
Est-ce que ta présentation pourrait m'aider ?

Toute expérience dans ce domaine est la bienvenue.

Merci d'avance,

Yann

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Gestions de clés avec GPG

2003-01-07 Par sujet Marc SCHAEFER
On Tue, Jan 07, 2003 at 02:50:33PM +0100, Yann SOUCHON wrote:
 En cherchant sur Google, je suis tombé sur un email d'une présentation qui
 s'est passé à Berne au mois de Juin 2002. L'auteur de cette présentation
 est Marc :)
 Est-ce que ta présentation pourrait m'aider ?

Elle doit être sur http://www.ch-open.ch/events/ ou qqch comme ça.

Elle devrait t'aider à comprendre les raisons qui rendent une
infrastructure de gestion de clé nécessaire. Elle ne t'aidera pas
cependant à aller plus dans le détail.

En ce qui concerne les annuaires de clé, il y en a plusieurs, comme
pgpkeyserver.net. D'ailleurs au moins pgpg4pine (PINE est un client mail
que je n'utilise plus) chargeait tout seul les clés publiques
correspondant à l'email et te disait si cela correspondait.

Mais seulement s'il existe une chaîne de signatures menant à une clé
connue comme bonne sur une clé tu n'avais pas le message `signature
bonne, mais clé non fiable'.

Pour obtenir cela, il faut soit faire signer sa clé par beaucoup de gens
connus, soit utiliser un système plus centralisé tel que SWISSKEY (dans
le domaine des certificats SSL) proposait en Suisse via les Chambres
de Commerce.

L'UBS ayant coupé le financement, SWISSKEY n'existe plus à ma
connaissance.

Et les autorités qui délivrent des certificats (VeriSign, etc) ne sont
pas fiables.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Problème PHP

2003-01-07 Par sujet Francis Olof Garnier
Aucune. Je profite simplement de cette discussion pour te demander
si tu as déjà essayé Fink:

   http://fink.sourceforge.net/

il s'agit de packages Debian préparés pour installation via apt-get et
consorts mais *sous MacOSX*.

Par rapport à installer un système multi-boot avec Debian GNU/Linux
PPC, cela a probablement des avantages certains.

Oui, je l'utilise ! Actuellement, 1872 packages sont disponibles.
J'utilise pas souvent (faut quand même lancer X11), mais y'a pas mal de
trucs intéressants (xfig, gimp, kde, ..., ..., ...).

Peut-être ont-ils des packages Apache (encore que dans le cas
présent je ne pense pas que cela puisse être le problème. Juste pour
être sûr: système de fichier ufs ou hpfs ?).
Apache est installé par défaut, c'est pas un problème. Et on trouve tout
ce qu'il faut pour installer PHP sans passer par fink.

Le système de fichier est propre à Apple, c'est du HFS+ (sauf erreur). Il
est possible d'installer OS X sur du UFS, mais ça parait pas la meilleurs
solution, d'après certains avis).



--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Problème PHP

2003-01-07 Par sujet Marc SCHAEFER
On Tue, Jan 07, 2003 at 09:25:59PM +0100, Francis Olof Garnier wrote:

 Le système de fichier est propre à Apple, c'est du HFS+ (sauf erreur). Il
 est possible d'installer OS X sur du UFS, mais ça parait pas la meilleurs
 solution, d'après certains avis).

Disons que c'est la seule pour assurer un système de fichier POSIX. Et
ne pas assurer POSIX c'est ouvrir la voie à toutes sortes d'attaques
de sécurité, notamment.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



echo off dans un service

2003-01-07 Par sujet Jean-Claude Schopfer
Hellow, 

J'ai un chtit problème en shell (bash) : 

J'ai fais un script shell de quelques lignes avec un certain moment
donné un login du style :

...
echo -eLogin: \c
read PROGLOGIN
echo -e Password: \c
stty -echo
read PROGPASSWD
stty echo
...

J'ai aussi essayé d'utiliser read -s au lieu des commandes stty mais
le résultat est le même : utilisé en local le script effectue un
echo off lors de la saisie du mot de passe, mais si je rattache
ce prog sur un port (/etc/services  /etc/inetd.conf), l'echo off
ne s'effectue pas. J'ai même un message d'erreur si j'utilise
stty (pas de message avec read -s).

Est-ce quelqu'un a une idée ?

J'ai remarqué aussi q une tentative d'interruption du service
par la partie cliente par CTRL + C|D lors du read ne fonctionne
pas ce qui est une bonne chose. Est-ce 100 % fiable ou dois-je
quand même traper ?

PS : je suis sur GNU/Linux Debian Woody

@++
JC
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.