-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Monday 2007-09-24 at 08:19 +0100, richard (MQ) wrote:
> Carlos E. R. wrote:
>
> > Ah! Before I forget: I wrote to '/etc/sysconfig/kernel' this line:
> >
> > MODULES_LOADED_ON_BOOT="cryptoloop twofish"
> >
> > I think this should work to load those two modules instead of using
> > boot.local
>
> It will, but it will be over-written on upgrade. The point about
> /etc/boot.local is that it is (supposed to be!) protected when upgrading
> (and is also easy to backup / restore manually). Same applies to a
> number of other files with similar names (I think this is specific to
> OpenSuSE ?)
Mmmm...
If it is overwritten on upgrade, it is a bug and should be reported. Files
in that directory are parsed. For instance, I ended with an almost broken
/etc/sysconfig/SuSEfirewall2 after several cascaded upgrades; I had to
locate the original file, copy it over, and add my changes with and
editor. I still have to do the same for the cups config file, there have
been chages which didn't apply.
Yes, there are a number of files in /etc/init.d that belong to the user
and are not replaced. At most, they would be moved to file.rpmold or
somthing like that.
To keep slightly on topic for this list, I was scared/confused by the
comentary on encription changes appearing in the release notes of RC1.
(The rest of this email is probably OT for this list)
> > My procedure is simpler. First I create an empty file:
> >
> > nimrodel:~ # nice dd if=/dev/zero of=crypta_f_dvd \
> > bs=1MB count=4700
> ...
>
> > I didn't think to randomize it, as I suppose the encryption thing will do
> > its
> > work. The file has the exact size of a DVD image. Then I encrypt it via
> > loop:
>
> As a general principle, you should use a fresh (different) random set
> for each such encrypted file / disc, so that an attacker has less to go
> on when trying to crack it (e.g. by comparing encrypted files & looking
> for correlations). The extra security is probably rather irrelevant here...
However, I suppose that when creating the filesystem on top, and after the
encription, almost every original byte will be overwritten. Or that's what
I thought, at least. Those that are untouched contains no data of the
present backup and are irrelevant. Maybe in my case they contain data from
the previous backup.
Well, to be really secure, you have to keep a very long key in another
media, like a memory card. To get back the data, you need then the
encrypted data, the usb key, and the password: they need to stole both and
force the password out of you, which is quite difficult to happen for a
normal thief.
However, I'm unsure how to create those beasties. Documentation seems to
be scarce and written for crackers.
> > And I create the XFS filesystem on the loop device:
>
> Just out of interest - why XFS?
Heh! :-)
Good question.
Well, I choosed it because it has the lowest directory and fixed structure
reserved ahead of time. Less reserved sectors, more space for your data. I
think they are reserved and created as you write your files.
Reiserfs, for instance, is the worst in this respect: so much so that the
utilities usually refuse to prepare a reiserfs smaller than 100 MB.
Ext2 is good, but ext3 has to keep a journal somewhere (xfs too, I think).
Difficult to create a plain ext2 without journal by mistake: I tried.
I did some measurements storing some quite large files and it came out
that xfs had the biggest free space left, so that I could store 12 of my
data sets instead of 11, meaning less DVDs were needed.
The snag is that I can not mount simultaneously one of those DVDs and the
backup image: it appears XFS has some kind of ID, and it refuses to mount
because there is already one XFS filesystem with that ID mounted.
And I do not know what will happen the day I get a scratch on a DVD: will
it be mountable? O repairable?
> > The problem nowdays is that DVDs are too small for making backups of a 300
> > GiB
> > HD :-(
>
> Quite so. Even HD DVDs (when they finally become mainstream) are tiny in
> comparison.
Yes... my normal backups go to an usb HD enclosure now.
- --
Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFG95DqtTMYHG2NR9URAiPWAJ4jwW6lOxsYjpG23XIkNkNV+EagHQCdEEUi
6Y0V3OFxQjEBKXGhDtd4Uo8=
=8RDr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
