Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, May 30, 2008 at 10:37:03AM +0200, Martin Gombac wrote: > I guess i'll just leave the encryption out for now. :-( > Regards, > M. please note that DRBD does no encryption at all, not on the device, nor on the wire. the feature you are trying to use here is intended to make sure during the DRBD handshake, that the entities talking to each other are in fact intended to do so -- using a shared secret per resource, and exchanging hash values to authenticate. the intention here is to make it unlikely that someone hacking a small perl "drbd-client" is able to trick your drbd to give im a cleartext dump of the full device - because he does not know the shared secret. if someone later manages to intercept or hijack the DRBD tcp replication connection, that is still all clear text. i.e. tcpdump of the drbd replication link always shows clear text data. if you want to have that encrypted, you need to set up some VPN, or put a dm-crypt target on top of DRBD, or both. -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please don't Cc me, but send to list -- I'm subscribed