On Wed, Oct 27, 2010 at 07:48:23PM +0200, Jean-Yves F. Barbier wrote:
ça n'est pas du tout conseillé: il peut y avoir des effets de bord en
superposant 2 encryptions qui rendent le total moins sûr qu'une seule
couche.
Tu as des sources là dessus? Ça serait embêtant, mettre des
tunnels dans des
Re,
On Wed, Oct 27, 2010 at 07:48:23PM +0200, Jean-Yves F. Barbier wrote:
utiliser le lecteur d'empreintes digitales intégré ? :-)
mauvaise option: la plupart embarquent une eeprom qui conserve des infos
qui ne devraient pas l'être (sans compter certains enfoirés de
constructeurs, tel
On Thu, 28 Oct 2010 13:22:12 +0200, JF Straeten jfstrae...@scarlet.be
wrote:
utiliser le lecteur d'empreintes digitales intégré ? :-)
mauvaise option: la plupart embarquent une eeprom qui conserve des infos
qui ne devraient pas l'être (sans compter certains enfoirés de
Re,
On Thu, Oct 28, 2010 at 02:11:39PM +0200, Jean-Yves F. Barbier wrote:
[...]
Tu aurais l'un ou l'autre lien ?
marrant ça, mais surtout typique des forums/mls fr: systématiquement
on quémande les links en évitant soigneusement les effort personnels
de recherche - l'école est finie...
On Thu, 28 Oct 2010 14:53:11 +0200, JF Straeten jfstrae...@scarlet.be
wrote:
Re,
On Thu, Oct 28, 2010 at 02:11:39PM +0200, Jean-Yves F. Barbier wrote:
[...]
Tu aurais l'un ou l'autre lien ?
marrant ça, mais surtout typique des forums/mls fr: systématiquement
on quémande les
On Thu, 28 Oct 2010 15:57:09 +0200, Yves Rutschle
debian.anti-s...@rutschle.net wrote:
On Thu, Oct 28, 2010 at 03:05:00PM +0200, Jean-Yves F. Barbier wrote:
rien de personnel, c'est juste une constatation de longue date.
Ok, j'imagine que tu vas donc également ignorer ma demande
de
Bonjour à tous,
Le 28/10/2010 16:29, Jean-Yves F. Barbier a écrit :
On Thu, 28 Oct 2010 15:57:09 +0200, Yves Rutschle
debian.anti-s...@rutschle.net wrote:
On Thu, Oct 28, 2010 at 03:05:00PM +0200, Jean-Yves F. Barbier wrote:
rien de personnel, c'est juste une constatation de longue date.
Le mardi 26 octobre 2010 à 22:00:13, Kevin Hinault a écrit :
[…]
La on a la même chose partout :
fdisk de base :
# /sbin/fdisk.distrib -l /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
[…]
Oui euh, mais là, ce qui m’intéressait, c’était les tables
complètes. Suivant le logiciel
Le 27 octobre 2010 10:38, Sylvain L. Sauvage
sylvain.l.sauv...@free.fr a écrit :
Oui euh, mais là, ce qui m’intéressait, c’était les tables
complètes. Suivant le logiciel et le mode utilisé (p.ex.
compatibilité avec DOS pour fdisk), le secteur de début de
partition diffère. En mode «
Le 27 octobre 2010 08:28, Yves Rutschle
debian.anti-s...@rutschle.net a écrit :
On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote:
Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
l'entièreté du volume avec luks
Au fait, vous (Goldy, Kevin, JY) utilisez luks pour vous
On Wed, 27 Oct 2010 08:28:27 +0200, Yves Rutschle
debian.anti-s...@rutschle.net wrote:
On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote:
Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
l'entièreté du volume avec luks
Au fait, vous (Goldy, Kevin, JY) utilisez luks
Re,
On Wed, Oct 27, 2010 at 03:33:45PM +0200, Yves Rutschle wrote:
Le chiffrement du disque n'a aucun effet sur le reste des
menaces que tu listes.
Modulo quand même le fait que Jean-Yves ne déchiffre qu'en fonction de
ses besoins d'accès aux datas et uniquement pour le temps limité de
leur
Re,
On Wed, Oct 27, 2010 at 04:23:00PM +0200, Yves Rutschle wrote:
[...]
Tant que le déchiffrement ne se fait pas, les datas sont safe, non ?
Oui.
Ah, ça me rassure :-)
Pour le reste, je partage ton avis.
Mais dans un cas particulier comme celui-ci (une question en amène une
autre...),
On Wed, 27 Oct 2010 19:32:22 +0200, JF Straeten jfstrae...@scarlet.be
wrote:
Non, ici, je voulais dire dans le cas de Jean-Yves (utilisation
ponctuelle, à la demande), y a-t-il une raison de crypter plutôt toute
une partition que de monter un répertoire avec encfs ?
non, pas spécialement,
On Tue, 26 Oct 2010 20:32:20 +0200, Kevin Hinault hina...@gmail.com wrote:
J'ai un RAID 1 tout bête (en mirroring donc) depuis quelques mois qui
tournait pas mal mais il est un peu spécial : chacun des deux disques
est chiffré avec luks et le raid contient des LVM, c'est à dire un
pas terr
Le mardi 26 octobre 2010 à 20:32:20, Kevin Hinault a écrit :
Bonjour à tous,
’soir,
[…]
gnu-fdisk me dit ça :
[…]
Disk /dev/dm-4: 1000 GB, 1000194048000 bytes
[…]
Alors que le fdisk de base sur Debian me dit :
# /sbin/fdisk.distrib -l /dev/dm-4
Disk /dev/dm-4: 1000.2 GB, 1000201188352
Le 26/10/2010 20:47, Jean-Yves F. Barbier a écrit :
pas terr comme organisation, mixer raid lvm, c'est multiplier
les risques de pertes de données par au moins 10 - Sans compter
l'overhead rajouté par le fait que chaque membre de l'array a sa
propre encryption (quel intérêt, à part bouffer
Le 26/10/2010 20:47, Jean-Yves F. Barbier a écrit :
pas terr comme organisation, mixer raid lvm, c'est multiplier
les risques de pertes de données par au moins 10 - Sans compter
l'overhead rajouté par le fait que chaque membre de l'array a sa
propre encryption (quel intérêt, à part bouffer
Le 26 octobre 2010 20:56, Sylvain L. Sauvage
sylvain.l.sauv...@free.fr a écrit :
Soit 524288 octets = 512 kio de différence.
Que disent(-ils sur) les couches inférieures (notamment les
/dev/sd*) ?
Bonne idée, je n'ai pas pensé à vérifer :
La on a la même chose partout :
fdisk de base :
#
On Tue, 26 Oct 2010 21:53:14 +0200, Kevin Hinault hina...@gmail.com wrote:
...
Quant à la RAM et au CPU, les performances sont très bonnes de ce côté
là.
Wai, c'est aussi le leit-motiv de ceux qui font les javascripts qui
bloquent 100% de mon vieux CPU (mais 1% sur un 8 cores avec 100MB de
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle
debian.anti-s...@rutschle.net wrote:
ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais
endroit et c'est râpé (loi de Murphy oblige, ça arrive plus souvent que
les stats ne le suppute.)
sans compter que la réunion de 2
Le 26 octobre 2010 22:12, Jean-Yves F. Barbier 12u...@gmail.com a écrit :
Donc tu as d'abord créé ton raid et puis tu l'a chiffré et mis du lvm
par-dessus c'est bien ça ?
C'est juste pour mon info perso et pour le futur puisque dans le cas
présent
Une meilleure question à se poser: au prix
On Tue, 26 Oct 2010 22:19:53 +0200
Jean-Yves F. Barbier 12u...@gmail.com wrote:
ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais
endroit et c'est râpé (loi de Murphy oblige, ça arrive plus souvent que
les stats ne le suppute.)
sans compter que la réunion de 2
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle
debian.anti-s...@rutschle.net wrote:
On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote:
Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y
ait le moindre problème sur le disque, uniquement en le sortant et en le
Le 26 octobre 2010 22:00, Kevin Hinault hina...@gmail.com a écrit :
Le 26 octobre 2010 20:56, Sylvain L. Sauvage
sylvain.l.sauv...@free.fr a écrit :
Donc a priori il suffirait de trouver où j'ai perdu les 512ko... Piste
intéressante merci !!
Tu utilises directement /dev/sd. ou tu as fait
On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault hina...@gmail.com wrote:
Hum moi c'est ce qui m'a permis de sauver mes données et de détecter
mon problème de disque rapidement :
la couche physique du disque était abimée, ce qui générait des erreurs
logiques dans la couche chiffrement et
Le 26 octobre 2010 23:05, Jean-Yves F. Barbier 12u...@gmail.com a écrit :
On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault hina...@gmail.com wrote:
Hum moi c'est ce qui m'a permis de sauver mes données et de détecter
mon problème de disque rapidement :
la couche physique du disque était
On Tue, 26 Oct 2010 22:30:10 +0200, JC jc2...@aygalenq.net wrote:
ça n'est pas une question de bug, il suffit qu'un seul bit saute au
mauvais endroit et c'est râpé (loi de Murphy oblige, ça arrive plus
souvent que les stats ne le suppute.)
sans compter que la réunion de 2 couches
28 matches
Mail list logo
