[35733] in Kerberos
Re: installing auks with torque
daemon@ATHENA.MIT.EDU (Matthieu Hautreux)
Mon Feb 3 15:47:12 2014
MIME-Version: 1.0
In-Reply-To: <52DC7F44.4060208@rampaginggeek.com>
Date: Mon, 3 Feb 2014 21:46:56 +0100
Message-ID: <CAChPGiAu4Eo2eA42k6Hfz0TARZm5XKc2P5DcRG8Ro4KBfSiVdg@mail.gmail.com>
From: Matthieu Hautreux <matthieu.hautreux@gmail.com>
To: Jason Edgecombe <jason@rampaginggeek.com>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
2014-01-20 Jason Edgecombe <jason@rampaginggeek.com>:
> Hi everyone,
>
> We're trying to set up a Linux compute cluster using torque. I would
> like the jobs to be able to access each user's AFS space by caching the
> user's Kerberos tickets/access.
>
> One solution is auks:
> http://workshop.openafs.org/afsbpw10/talks/wed_3/hautreux_kerberos_hpc.pdf
> https://github.com/hautreux/auks
>
> According to https://twiki.ppe.gla.ac.uk/bin/view/Main/TorqueAuks ,
> auks needs to be installed on the KDC, but I don't see any need for this
> based on my limited understanding of auks and a cursory glance at some
> of the auks code. As far as I can tell, auks is like multiple hosts
> sharing a ticket cache with k5start.
>
> Can anyone clarify if the auks daemon really needs to be on the KDC? I'm
> resistant to installing extra services on the KDC's.
>
Based on my understanding of what is explained on this wiki, they are using
auks on the KDC because they regularly dump all the keytabs of their users,
acquire tickets and push them to the auks daemon. It is not necessary to
put the auks daemon on the KDC, as you guessed it is a kind of distributed
credential cache with ACL enabling particular principals to get what they
want from this cache.
You could consider following the instruction of this wiki but only use auks
as a cache and replace the KDC cron logic by an automatic "auks -a" when
your users submit their jobs using torque submission CLI. (I guess that a
kind of submit prolog could do that transparently, I am not familiar with
torque).
>
> If anyone has any other ideas to pull off a job scheduler with Kerberos
> & AFS access, then I'm open to that as well.
>
Sorry, no other ideas, that is why I wrote auks and did not follow what was
going on on that subject after that :)
Regards,
Matthieu
>
> Thanks,
> Jason
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
