Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 13 Aug 2009 22:10:19 -0400
From:      Steve Bertrand <steve@ibctech.ca>
To:        "questions@freebsd.org" <questions@freebsd.org>
Subject:   Managing encrypted disks
Message-ID:  <4A84C78B.4070206@ibctech.ca>
next in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
Hi all,

I boot many of my storage machines from thumb drives that contain /boot
and /etc/fstab. Everything else is loaded/mounted from GELI encrypted
disks within the box.

Backups/archives on some of these boxes are not within the standard
AMANDA regimen. They are under special (manual) backup routines. I have
three 'standard' procedures:

- a remote backup server will temporarily attach and mount a GELI
encrypted partition and "rsync" (via SSH) the data from the live server,
and then umount and detach the drive when rsync completes

- rsync is run continuously from the live storage server over SSH to a
remote backup server (ie: hot spare (essentially))

- a local drive (local, relative to the site... eg: a USB/IDE drive
directly connected) is (GELI) attached, mounted, and the original
contents are then rsync'd

The objective of these methods is to ensure that if the hardware is
unplugged and moved without authorization, I'll have enough time to make
critical decisions before the data could possibly be retrieved. (GELI is
protected by keys which are not on site, and by passphrase).

What I'd like to know, is if it's possible to somehow check to see if
there are any GELI 'attach'ed disks on a given system that have not yet
been mounted (or, iow, were umount'd, but were left attached).

#dmesg doesn't say much in this regard, and I couldn't find out by
listing /dev either.

Any tricks to find out what GELI knows? I want to automate everything
except the insertion of the keys, which will always be manual. Knowing
how to identify what is attached but not mounted would be a good start.


Steve


[-- Attachment #2 --]
0	*H
010	+0	*H
00CK9AbxIUw0
	*H
0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
090507231610Z
100507231610Z0B10UThawte Freemail Member10	*H
	steve@ibctech.ca0"0
	*H
0
DZ杙<2IⵀfrsE6q?0.>
S@Œ!V?A\Q
r-aZ
Ōf/0{OYQhɏߴ
F_\Q0BF=<_.a*3epeY|tݼcvlҷ+@piQA{2E9WN4[Z`h6VM/zPbd(GC^K6XV4j<t-0+0U0steve@ibctech.ca0U00
	*H
æ|85aQz-*3HG		.s*Fw*`HvFw;9ytƘn0taC/:WC+LÙ{Oq 1n00CK9AbxIUw0
	*H
0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
090507231610Z
100507231610Z0B10UThawte Freemail Member10	*H
	steve@ibctech.ca0"0
	*H
0
DZ杙<2IⵀfrsE6q?0.>
S@Œ!V?A\Q
r-aZ
Ōf/0{OYQhɏߴ
F_\Q0BF=<_.a*3epeY|tݼcvlҷ+@piQA{2E9WN4[Z`h6VM/zPbd(GC^K6XV4j<t-0+0U0steve@ibctech.ca0U00
	*H
æ|85aQz-*3HG		.s*Fw*`HvFw;9ytƘn0taC/:WC+LÙ{Oq 1n0?0
0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
030717000000Z
130716235959Z0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA00
	*H
0Ħ<UsUNʙZhup[v:aQP
0cZ,p+Z?qV˯<6$*+w=+>@dקe*TH<a@dr`00U00CU<0:08642http://crl.thawte.com/ThawtePersonalFreemailCA.crl0U0)U"0 010UPrivateLabel2-1380
	*H
HP.
fgCL!6-6/P p<ab:~t%Pb'qW%ݩ9 Oe_N4[5MwV!x!5$F]_eO1d0`0v0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAK9AbxIUw0	+0	*H
	1	*H
0	*H
	1
090814021019Z0#	*H
	1 E3`Za̜=T0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0	+71x0v0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAK9AbxIUw0*H
	1xv0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAK9AbxIUw0
	*H
6zf?cv3Ȫ (rxS*	5y-gdcWر\vAYdOݢ6"6: m@,qYWl&j}|οkFˌ+"KkEp"4޻SpEAP_/3~[aT	4.&aoi;_>P3;X*s‹U|wjÏC&L#]a-

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A84C78B.4070206>