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.

Jan