[458] in arla-drinkers
Re: Arla Re: Developers needed: hooks for GNU Queue.
daemon@ATHENA.MIT.EDU (Love)
Tue Jan 5 01:10:41 1999
From owner-arla-drinkers@stacken.kth.se Tue Jan 05 06:10:40 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 11192 invoked from network); 5 Jan 1999 06:10:39 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 5 Jan 1999 06:10:39 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id HAA25246
for arla-drinkers-list; Tue, 5 Jan 1999 07:05:59 +0100 (MET)
Received: from elixir.e.kth.se (1073744992@elixir.e.kth.se [130.237.48.5])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id HAA25242;
Tue, 5 Jan 1999 07:05:56 +0100 (MET)
Received: from anchor.s3.kth.se (anchor.s3.kth.se [130.237.43.59])
by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id HAA26883;
Tue, 5 Jan 1999 07:05:55 +0100 (MET)
Received: (lha@localhost) by anchor.s3.kth.se (8.8.7/8.6.6) id HAA04776; Tue, 5 Jan 1999 07:05:55 +0100 (MET)
From: Love <lha@stacken.kth.se>
To: Werner Krebs <werner.krebs@yale.edu>
cc: Magnus Ahltorp <map@stacken.kth.se>, queue-tips@bofur.csb.yale.edu,
arla-drinkers@stacken.kth.se
Subject: Re: Arla Re: Developers needed: hooks for GNU Queue.
References: <199901050601.HAA25225@sundance.stacken.kth.se>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Jan 1999 07:05:55 +0100
In-Reply-To: owner-arla-drinkers@stacken.kth.se's message of Tue, 5 Jan 1999 07:01:24 +0100 (MET)
Message-ID: <amsodqs18c.fsf@anchor.s3.kth.se>
Lines: 32
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
Werner Krebs <werner.krebs@yale.edu> writes:
> Yes, this is exactly what we are looking for.
>
> The only issue is encryption; GNU Queue does not currently have hooks
> for a secure socket library (although support is planned).
>
> Does Arla provide any kind of encryption facilities (e.g., Kerberos,
> etc.) to support this?
Arla uses Kerberos, and the tokens in arla is accully striped down kerberos
tickets. To be able to use arla with any security in mind use have to fetch
kerberos.
> The only other issues would be determining which token(s) to send (all
> of them, preferably) and quickly determining whether or not alra
> is running on a client (so that the same binary can decide whether or
> not it wants to accept incoming arla tokens and alert the other end
> during negotiation when alra is not supported.)
That is not a problem. Since the ``server'' knows where the files
are going to stored (?) I could pass over the tokens that the other side
need. Or just pass over all tokens. I don't see that this a problem.
It's just a configuration problem.
There is a afs-nfs translators (only *bsd so far (it should be possible
to do it with linux 2.0, but I have not had a look on that yet).
Note that the nfs code is alpha, and there is no way for the users
to insert the tokens yet.
Love
