[2627] in SIPB-AFS-requests
Re: REQ: new volume for (non afs) backup info
daemon@ATHENA.MIT.EDU (Emil Sit)
Mon Feb 3 12:25:46 1997
To: mhpower@MIT.EDU
Cc: sipb-afsreq@MIT.EDU, foley@MIT.EDU
In-Reply-To: Your message of "Sat, 01 Feb 1997 23:06:35 EST."
<9702020406.AA10845@yaz-pistachio.MIT.EDU>
Date: Mon, 03 Feb 1997 12:25:06 EST
From: Emil Sit <sit@MIT.EDU>
> >Rationale: foley and I are planning on storing backup software and
> >related stuff in AFS (as opposed to per machine) ...
>
> Could you explain more about this? For example, is the idea that any
> program that's currently run from the /usr/local/backup/bin directory
> on the local disk would instead be run from some directory in AFS?
Yes, this would allow us to have the same backup software on all
servers. The OSU system was also designed to have a single database
for all tapes, which we were considering trying out.
> Also, would the processes running these programs run aklog before
> accessing that AFS directory, or would they instead run without tokens
> and rely on that directory being readable by system:anyuser?
I was planning on creating/using AFS principals for the servers and
having them get tokens, so that they can write to the tape DB.
> execute arbitrary programs as root. As far as I know, the backup
> processes have to run as root locally (obviously they couldn't
> otherwise backup files regardless of permissions). Although there may
> be some programs run as root from AFS on all of the server machines,
As I understand it, I should be able to set things up so that
I will login anywhere, get root tickets and then the backup program
could use those tickets to rsh into whatever machine I'm backing up and
do the backup.
> the people setting up the other services on the machines have often
> gone to a lot of trouble to have as many programs as possible run from
> local disk, and some services are in the process of being changed to
> run their programs entirely from local disk.
If there's significant objection to having stuff stored in AFS, I guess
we won't do it... there didn't appear to be much objection beyond
the root auth issue that jweiss brought up when I originally suggested
this in late November. Should I ask about this on star-maintainers
again?
Now, in any case, backups aren't done over encrypted links right? So
there's probably enough information that gets sent over that would
compromise security to some extent. I think that such a compromise
would be more likely than an active AFS spoofing attack.
> ok, although I think the maximum ticket lifetime is close enough to
> the duration of some backups that it might be hard to get this working
> reliably. (I think it depends on whether any new program might be
> started after 21.25 hours without another opportunity to get tokens).
My only experience is with the anxiety backups which takes about
2.5 hours. In any case, with the srvtab, each machine should be
able to get tokens as needed, right? The person running the backup would
need to renew their root tickets though, but since we won't be backing
up multiple servers to a single tape, this shouldn't present
a problem. (i.e. they'll need to swap tapes and such anyway.)
Emil
--
Emil Sit / Bronx Science '95, MIT '99 -- ESG, SIPB.
Email: sit@mit.edu / Web: http://web.mit.edu/sit/www/
PGP KeyID: 0xE63561E9 / Fingerprint: A68FD0693EDABA19 2671EC1F22498F58
