In article <1g9wvqs.12arm691scjuioN%, (Remail) wrote:
patpro wrote:
n'oublie pas de faire une backup non chiffrée de tes fichiers
Pourquoi ?
principe universel de précaution
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
remail
patpro wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
-- Rémy Colbère
patpro <patpro@boleskine.patpro.net> wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes
copies de suavegarde doivent être cryptées.
Je crois que c'est davantage une question de point de vue.
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
-- Rémy Colbère
patpro
In article <1g9x4sx.1m09fu313q7d0mN%, (Remail) wrote:
patpro wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
oui, chacun voit midi à sa porte :)
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <1g9x4sx.1m09fu313q7d0mN%remail@alussinan.org>,
remail@alussinan.org (Remail) wrote:
patpro <patpro@boleskine.patpro.net> wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes
copies de suavegarde doivent être cryptées.
Je crois que c'est davantage une question de point de vue.
oui, chacun voit midi à sa porte :)
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
In article <1g9x4sx.1m09fu313q7d0mN%, (Remail) wrote:
patpro wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
oui, chacun voit midi à sa porte :)
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
Saïd
Remail :
patpro wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
Par exemple si Apple disparait, il y a fort a parier que le logiciel de decryptage ne sera plus maintenu et tu vas legerement galerer pour recuperer tes donnees.
Ou alors que tu saches faire le programme de decryptage toi-meme. Le mieux est donc d'utiliser un logiciel de cryptage/decryptage dont tu possedes les sources.
-- Saïd. (Le principe de precaution c'est l'open source.)
Remail :
patpro <patpro@boleskine.patpro.net> wrote:
principe universel de précaution
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes
copies de suavegarde doivent être cryptées.
Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage:
1) existera quand tu auras besoin de decrypter, mais tu peux le backupe
lui-aussi.
2) que ce logiciel puisse tourner sur le materiel qui existera au moment du
besoin.
Par exemple si Apple disparait, il y a fort a parier que le logiciel de
decryptage ne sera plus maintenu et tu vas legerement galerer pour recuperer
tes donnees.
Ou alors que tu saches faire le programme de decryptage toi-meme. Le mieux
est donc d'utiliser un logiciel de cryptage/decryptage dont tu possedes les
sources.
--
Saïd. (Le principe de precaution c'est l'open source.)
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
Par exemple si Apple disparait, il y a fort a parier que le logiciel de decryptage ne sera plus maintenu et tu vas legerement galerer pour recuperer tes donnees.
Ou alors que tu saches faire le programme de decryptage toi-meme. Le mieux est donc d'utiliser un logiciel de cryptage/decryptage dont tu possedes les sources.
-- Saïd. (Le principe de precaution c'est l'open source.)
patpro
In article , Saïd wrote:
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
...
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <slrnc43m07.1s7.saidNo@brian.lan>,
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes
copies de suavegarde doivent être cryptées.
Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage:
1) existera quand tu auras besoin de decrypter, mais tu peux le backupe
lui-aussi.
2) que ce logiciel puisse tourner sur le materiel qui existera au moment du
besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne
entacher le chiffrement, qui rendrait la récupération des données
impossible.
4) avoir la certitude qu'une dégradation partielle d'un support de
sauvegarde ne rende pas impossible le déchiffrement de la backup (un
fichier partiel est tjrs partiellement lisible, je doute qu'un bout de
fichier chiffré soit déchiffrable)
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces
vieilles backups
...
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
...
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
Saïd
patpro :
In article , Saïd wrote:
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose esperer que sur quelque chose d'aussi important Apple a bien verifie et reverifie les choses.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
...
Une guerre atomique?
-- Saïd.
patpro :
In article <slrnc43m07.1s7.saidNo@brian.lan>,
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes
copies de suavegarde doivent être cryptées.
Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage:
1) existera quand tu auras besoin de decrypter, mais tu peux le backupe
lui-aussi.
2) que ce logiciel puisse tourner sur le materiel qui existera au moment du
besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne
entacher le chiffrement, qui rendrait la récupération des données
impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose
esperer que sur quelque chose d'aussi important Apple a bien verifie et
reverifie les choses.
4) avoir la certitude qu'une dégradation partielle d'un support de
sauvegarde ne rende pas impossible le déchiffrement de la backup (un
fichier partiel est tjrs partiellement lisible, je doute qu'un bout de
fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par
blocks justement pour ce probleme. Les chiffrement que je connais consistent
a elever un entier a une puissance entiere. L'entier en question est une
agregation de donnees binaires, donc un block. Theoriquement ca n'apporte
rien de faire dependre un block des blocks precedents dans ce schema.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces
vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
C'est justement pour obéïr à ce principe que je me dis que TOUTES mes copies de suavegarde doivent être cryptées. Je crois que c'est davantage une question de point de vue.
Il faut etre sur que le logiciel de decyptage: 1) existera quand tu auras besoin de decrypter, mais tu peux le backupe lui-aussi. 2) que ce logiciel puisse tourner sur le materiel qui existera au moment du besoin.
et :
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose esperer que sur quelque chose d'aussi important Apple a bien verifie et reverifie les choses.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
...
Une guerre atomique?
-- Saïd.
patpro
In article , Saïd wrote:
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose
esperer que sur quelque chose d'aussi important Apple a bien verifie et reverifie les choses.
j'ai pas souvenir que le chiffrement de FileVault ait été choisi :) Y'a des tonnes d'autres solutions.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par
blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
Tout est en général soumis a un checksum ou a une mesure de la taille du fichier. Il faut que le soft utilisé supporte de travailler sur un fichier endommagé. C'est a vérifier avant d'adopter telle ou telle méthode.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
le darwinisme, c'est plus ce que c'etait :))
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <slrnc43n02.1sj.saidNo@brian.lan>,
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne
entacher le chiffrement, qui rendrait la récupération des données
impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose
esperer que sur quelque chose d'aussi important Apple a bien verifie et
reverifie les choses.
j'ai pas souvenir que le chiffrement de FileVault ait été choisi :)
Y'a des tonnes d'autres solutions.
4) avoir la certitude qu'une dégradation partielle d'un support de
sauvegarde ne rende pas impossible le déchiffrement de la backup (un
fichier partiel est tjrs partiellement lisible, je doute qu'un bout de
fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par
blocks justement pour ce probleme. Les chiffrement que je connais consistent
a elever un entier a une puissance entiere. L'entier en question est une
agregation de donnees binaires, donc un block. Theoriquement ca n'apporte
rien de faire dependre un block des blocks precedents dans ce schema.
Tout est en général soumis a un checksum ou a une mesure de la taille du
fichier. Il faut que le soft utilisé supporte de travailler sur un
fichier endommagé. C'est a vérifier avant d'adopter telle ou telle
méthode.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces
vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
le darwinisme, c'est plus ce que c'etait :))
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
3) avoir la certitude qu'au détour d'une mise a jour aucun bug ne vienne entacher le chiffrement, qui rendrait la récupération des données impossible.
Encore une question de confiance dans le producteur du logiciel. J'ose
esperer que sur quelque chose d'aussi important Apple a bien verifie et reverifie les choses.
j'ai pas souvenir que le chiffrement de FileVault ait été choisi :) Y'a des tonnes d'autres solutions.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par
blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
Tout est en général soumis a un checksum ou a une mesure de la taille du fichier. Il faut que le soft utilisé supporte de travailler sur un fichier endommagé. C'est a vérifier avant d'adopter telle ou telle méthode.
5) avoir la certitude qu'on oubliera pas le vieux mot de passe de ces vieilles backups
Ca c'est une regle generale du darwinisme, inutile de la reenoncer. ;-)
le darwinisme, c'est plus ce que c'etait :))
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
laurent.pertois
Remail wrote:
J'utilise en effet FileVault qui est un don du ciel. Mes données sont protégées sur mon ordinateur. Par contre, lorsque je les copie vers un support externe (clé USB là), le système décrypte les fichiers. Voilà pourquoi j'avais besoin d'un logiciel de cryptage.
Dans ce cas, fais une image-disque chiffrée sur la clé et monte l'image avant de copier sur celle-ci, les données vont ainsi passer d'une image chiffrée à une autre, en fait.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Remail <remail@alussinan.org> wrote:
J'utilise en effet FileVault qui est un don du ciel. Mes données sont
protégées sur mon ordinateur. Par contre, lorsque je les copie vers un
support externe (clé USB là), le système décrypte les fichiers. Voilà
pourquoi j'avais besoin d'un logiciel de cryptage.
Dans ce cas, fais une image-disque chiffrée sur la clé et monte l'image
avant de copier sur celle-ci, les données vont ainsi passer d'une image
chiffrée à une autre, en fait.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
J'utilise en effet FileVault qui est un don du ciel. Mes données sont protégées sur mon ordinateur. Par contre, lorsque je les copie vers un support externe (clé USB là), le système décrypte les fichiers. Voilà pourquoi j'avais besoin d'un logiciel de cryptage.
Dans ce cas, fais une image-disque chiffrée sur la clé et monte l'image avant de copier sur celle-ci, les données vont ainsi passer d'une image chiffrée à une autre, en fait.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Schmurtz
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
Ça dépend de la manière dont le cryptage est effectué. En général, avant de crypter des données, on commence par les compresser afin de limiter les redondances qui facilitent la cryptanalyse (décryptage sans le mot de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier compressé on rend illisible tout ce qui suit, sauf si la compression s'effectue blocs par blocs.
Sinon, pour crypter des données, je conseille poutôt PGP (ou son équivalent Gnu open source GPG) qui est totalement multiplateforme et très répendu. Pour rester apple-centrique, il reste les images disques cryptées qui servent d'ailleurs pour le cryptage FireVault de Panther.
-- Schmurtz
4) avoir la certitude qu'une dégradation partielle d'un support de
sauvegarde ne rende pas impossible le déchiffrement de la backup (un
fichier partiel est tjrs partiellement lisible, je doute qu'un bout de
fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par
blocks justement pour ce probleme. Les chiffrement que je connais consistent
a elever un entier a une puissance entiere. L'entier en question est une
agregation de donnees binaires, donc un block. Theoriquement ca n'apporte
rien de faire dependre un block des blocks precedents dans ce schema.
Ça dépend de la manière dont le cryptage est effectué. En général, avant
de crypter des données, on commence par les compresser afin de limiter
les redondances qui facilitent la cryptanalyse (décryptage sans le mot
de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier
compressé on rend illisible tout ce qui suit, sauf si la compression
s'effectue blocs par blocs.
Sinon, pour crypter des données, je conseille poutôt PGP (ou son
équivalent Gnu open source GPG) qui est totalement multiplateforme et
très répendu. Pour rester apple-centrique, il reste les images disques
cryptées qui servent d'ailleurs pour le cryptage FireVault de Panther.
4) avoir la certitude qu'une dégradation partielle d'un support de sauvegarde ne rende pas impossible le déchiffrement de la backup (un fichier partiel est tjrs partiellement lisible, je doute qu'un bout de fichier chiffré soit déchiffrable)
Je ne suis pas specialiste, mais j'imagine que le chiffrement se fait par blocks justement pour ce probleme. Les chiffrement que je connais consistent a elever un entier a une puissance entiere. L'entier en question est une agregation de donnees binaires, donc un block. Theoriquement ca n'apporte rien de faire dependre un block des blocks precedents dans ce schema.
Ça dépend de la manière dont le cryptage est effectué. En général, avant de crypter des données, on commence par les compresser afin de limiter les redondances qui facilitent la cryptanalyse (décryptage sans le mot de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier compressé on rend illisible tout ce qui suit, sauf si la compression s'effectue blocs par blocs.
Sinon, pour crypter des données, je conseille poutôt PGP (ou son équivalent Gnu open source GPG) qui est totalement multiplateforme et très répendu. Pour rester apple-centrique, il reste les images disques cryptées qui servent d'ailleurs pour le cryptage FireVault de Panther.
-- Schmurtz
patpro
In article <c1u48l$rtf$, Schmurtz wrote:
Ça dépend de la manière dont le cryptage est effectué. En général, avant de crypter des données, on commence par les compresser afin de limiter les redondances qui facilitent la cryptanalyse (décryptage sans le mot de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier compressé on rend illisible tout ce qui suit, sauf si la compression s'effectue blocs par blocs.
effectivement, apres un test avec gzip+openssl, un fichier compressé et chiffré est perdu si il est endommagé.
Uniquement chiffré il est récupérable avec l'option -nopad (on ne perd que le ou les blocs vérolés)
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <c1u48l$rtf$2@news.polytechnique.fr>, Schmurtz <moi@ici.com>
wrote:
Ça dépend de la manière dont le cryptage est effectué. En général, avant
de crypter des données, on commence par les compresser afin de limiter
les redondances qui facilitent la cryptanalyse (décryptage sans le mot
de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier
compressé on rend illisible tout ce qui suit, sauf si la compression
s'effectue blocs par blocs.
effectivement, apres un test avec gzip+openssl, un fichier compressé et
chiffré est perdu si il est endommagé.
Uniquement chiffré il est récupérable avec l'option -nopad (on ne perd
que le ou les blocs vérolés)
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
Ça dépend de la manière dont le cryptage est effectué. En général, avant de crypter des données, on commence par les compresser afin de limiter les redondances qui facilitent la cryptanalyse (décryptage sans le mot de passe). Je suis presque sûr que si l'on modifie un bit d'un fichier compressé on rend illisible tout ce qui suit, sauf si la compression s'effectue blocs par blocs.
effectivement, apres un test avec gzip+openssl, un fichier compressé et chiffré est perdu si il est endommagé.
Uniquement chiffré il est récupérable avec l'option -nopad (on ne perd que le ou les blocs vérolés)
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
