(Illustration by Gaich Muramatsu)
On Tue, Nov 02, 1999 at 12:08:02PM -0500, Greg Troxel wrote: > I have a coda server and several clients set up. In order for me to > feel comfortable putting real data on it, I need to address the issues > of backups and security. > While coda has a backup scheme, it doesn't seem to be integrated with > amanda (http://www.amanda.org/), and thus it would be annoying for me > to use it. I looked at amanda, and it should be possible to have a modified dumper, as it is described in their doc/INTERNALS document, on the backup server. This essentially does the same thing as 'backup' in Coda is doing, but talks only to a single server (and single volume?). Coda backups are true snapshots of the state on the server. The first pass clones all modified vnodes in an active to a read-only backup copy. The second pass (dump) pulls all (or only the recently modified) vnodes and data over an rpc2/sftp connection to a holding disk on the backup host. After the data is `secure' (which in this case is 'on the holding disk') the vnodes in the backup volume are marked ancient, so that the next incremental dump will actually be a next higher level incremental. In a way this already resembled the amanda scheme reasonably closely, but it would be nice to have true multilevel incrementals (I believe there already should be a patch for this lying around somewhere). And a modified amdumper that pulls in a coda-volume, instead of a tarball. > In the glorious future, it will be easier to plug in other > schemes to amanda etc. and all will be simple. But for now, I settled > on using Gnu tar to do a hackish but adequate job. Basically, I did > > 1. put in a cronjob for root on the (single) server to clog from a > file as a user that can read everything that should be backed up > 2. configured amanda normally on the box > 3. configured the amanda server to dump each volume with gnu tar > > Except for some silly mistakes while configuring, this seems to work. > I know that really I should clone the volumes and back up the clones, > and I should figure out how to use the coda backup program, since I > lose all metadata. To address the latter, I wrote a simple script to > list the acls. Should I need the backups, I'll write something to put > them back! But this gets me the files, and that's the first-order > need. This is basically what 'backup' does, except this doesn't retry when a server is temporarily unreachable. srv=codaserver vol=non-replicated volume id if [incremental] then ; inc=-i ; else inc= ; fi # lock and backup the volume volutil -h $srv lock $volid volutil -h $srv backup $volid # figure out the backup's volumeid.. volutil -h $srv info $volid /tmp/x bckvol=`grep backupId /tmp/x | sed 's/.*backupId = \(.*\), .*/\1/'` # dump the backup volume volutil -h $srv dump $inc $bckvol /backups/$vol.backup Currently a restored backup is a readonly non-replicated volume. So it is mostly useful to rescue data, just like your solution with tar. Hopefully we will someday be able to twiddle the right bits to turn a backup volume back into a single read-write replica. Then resolution to can be used to repopulate the fully replicated volume on the other servers. > The second issue is security. Coda tokens (xor, I believe) are not > adequate. My current plan is to use IPSEC for all coda traffic, and > use the coda auth underneath it. However, this won't work across > firewalls that block AH/ESP. I'd like to use the krbsupport.c K5 > support, but also have the rpc2 security be at least DES. Any > hints/code for this would be most welcome. Robert Watson has a pile of very important but again incompatible changes for rpc2 which improve the authentication, `encoding', and integrity checking for rpc2 and sftp packets. But there are also other things like venus's codacon port that need to be blocked, or at least modified to only allow limited/localhost access. > It appears that coda lacks strong authentication due to export > control. Since in theory only encryption is regulated, I can't see > how including strong authentication but no confidentiality support > would run afoul of the rules as written. While I'd like both, it's > really the lack of authentication that bothers me the most. I'm > unfortunately not big on copious spare time, but I thought I would > mention this here. > > Greg Troxel <gdt_at_ir.bbn.com> > > > #!/bin/sh > cd /coda > find . -type d | while read d; do \ > echo $d > cfs la $d > cfs la $d > $d/.save-acl-data > ls -l $d/.save-acl-data > done This is unreliable when find is using leaf optimization. It will skip subtrees, as volume mountpoints appear as symlinks during the initial readdir. F.i. gnu-find needs a -noleaf flag. The 'volmunge' perlscript might be interesting, as it does not cross volume mountpoints and only walks within a single volume. JanReceived on 1999-11-03 18:09:45