[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] HTCondor with kerberized home directories


the implementation in 8.8 is supposed to be a little bit enhanced compared to the one in my talk in terms of having the complete token housekeeping on the scheduler. 

The tokens will then be distributed with the jobs to the workernodes and remotley updated (prolonged) if needed by the scheduler which is realized by replacing the token, hence it would also work after reboot of the workernode I guess. 

Looking forward to see this feature in wider usage, feel free to send e-mail in case of problems/questions once you started testing it ! 


Christoph Beyer
DESY Hamburg

Notkestr. 85
Building 02b, Room 009
22607 Hamburg

mail: christoph.beyer@xxxxxxx

----- UrsprÃngliche Mail -----
Von: "Oliver Freyermuth" <o.freyermuth@xxxxxxxxxxxxxx>
An: "htcondor-users" <htcondor-users@xxxxxxxxxxx>, "Christoph Beyer" <christoph.beyer@xxxxxxx>
Gesendet: Dienstag, 12. Juni 2018 10:11:55
Betreff: Re: [HTCondor-users] HTCondor with kerberized home directories


Am 12.06.2018 um 10:00 schrieb Beyer, Christoph:
> Hi,
> there is an implementation for handling of security tokens in HTCondor that can be used to integrate HTCondor into a KRB/AFS environment. 
> It is available in the development branch (currently 8.7.8) and is currently partly reengineered to become a fully documented and supported feature in the next stable release which will be 8.8. due autumn this year. 

this is really good news, thanks for letting us know! 
Early autumn might be fine, we could e.g. educate our users to use dedicated submission nodes which are not rebooted for each security update in the meantime. 

> The early version of this implementation is productive at CERN and DESY, here is a talk about it: 
> https://agenda.hep.wisc.edu/event/1201/session/9/contribution/40/material/slides/0.pdf
> There is another technical talk about it from Zach that is currently not online but should be available through the HTCondor team. 

This would be interesting to see. 
If I understand the schematics correctly, the implementation would also allow to ship the Kerberos TGT back to the submission node if it has been rebooted and lost access to the kerberized filesystems,
since it's kept in the "credential_shepherd"? 
That's our main concern, since the compute nodes (starters) can access the filesystem by unix auth. 

In a later stage, we planned to also have compute nodes where Kerberos is required - so also this part of the implementation is extremely welcome! :-) 

> The current implementation involves a bit of scripting hence if you are not in a hurry it would probably be wise to wait for 8.8 but if you want to start right away I can send you a recipe and would be open for questions ....

Since we don't have a test setup yet, but only a production one (we need to change this urgently this year, but - lack of manpower...), I think we have no other choice than to wait for 8.8
in any case. So we only need to find a way to survive until autumn ;-). 


> Best
> Christoph