Feature #2594
Feature #2378: Proper support for glexec - required by site vs provided by site
Native support for glexec in v3+
0%
History
#1 Updated by Parag Mhashilkar about 9 years ago
Details in #2378 (Proper support for glexec - required by site vs provided by site)
Igor's relevant comments from #2378
--------
For v3 I would propose we make glexec 1st class citizen and have a dedicated tag, e.g.:
<id_switching required="NO|OPTIONAL|YES" [type="glexec" path="blah" require_credentials="none|x509|voms"]/>
(this would also allow us to use something different than glexec, which is currently being discussed in OSG)
PS2: We will need something similar for the v3 frontend.
--------
#2 Updated by Parag Mhashilkar over 8 years ago
- Priority changed from Normal to High
#3 Updated by Burt Holzman almost 8 years ago
Parag will check to see if this really needs to go into v3.1 or if it can wait until v3.x. (If it's a change in the XML, it should probably
go into v3.1..)
#4 Updated by Parag Mhashilkar almost 8 years ago
So here is my proposal with some modifications:
- Relevant config sections
<glidein ... > <entries> <entry ... auth_method="grid_proxy|voms_proxy|..."> <sudo_tools> <sudo_tool type="glexec|NONE" required="TRUE|OPTIONAL|FALSE" path="OSG|glite|auto|path to tool" auth_method=" auth method"/> </sudo_tools> </entry> </entries> </glidein>
<frontend ... > <security ... > <sudo_tools> <sudo_tool type="glexec|NONE" use="NEVER|OPTIONAL|ALWAYS"/> </sudo_tools> <credentials> <credential absfname="path to cred" security_class="frontend" trust_domain="OSG" type="grid_proxy"/> </credentials> </security> </frontend>
- Factory
- Currently will only support type = glexec|NONE with new types supported in future as we need. * For glexec, path will override the the GLEXEC_BIN attribute and will perform same functionality
- Frontend
- sudo_tool[@use] is now equivalent to and override GLIDEIN_Glexec_Use
Changes to match making
- Frontend will only select entries that are ok with the sudo_tools configured and if it has the credential_type specified in the sudo_tool[@auth_method]
Changes to classads
- At present number of classads and contents will remain same with the sudo_tool configuration translated to the existing variables GLIDEIN_Glexec_Use & GLIDEIN_REQUIRE_GLEXEC_USE
- This may change in future based on how it works out, but hopefully changes should not affect existing semantics
Comments appreciated
#5 Updated by Anthony Tiradani almost 8 years ago
For the frontend, we should move <sudo_tools> to the group level. Otherwise, as an example, you will not be able to configure your frontend to route jobs to Fermilab and to EC2. You would need two different frontends.
#6 Updated by Burt Holzman almost 8 years ago
- Priority changed from High to Normal
- Target version changed from v3_1 to v3_x
Parag and I talked about this. We are moving this to v3.x (possibly to v4, since it does add new elements to the XML).
#7 Updated by Parag Mhashilkar almost 8 years ago
Now the master_2905 should have relevant code thats in branch_v2plus. cherry-picked commits from branch_v2plus that were missing in master. Master now support require_glidein_glexec_use as part of restrictions tag.
This will be in master when we merge master_2905 into master.
commit:54d8e9e535dcfd32e48261d0c5bd71e949f4f127
#8 Updated by Igor Sfiligoi almost 8 years ago
@Parag proposal:
So, the idea is to allow for multiple sudo tools at each and every site, and the FE decides which one to use?
If this is the case, I see two problems:
1) what is the relationship between auth_method in entry and in sudo_tool? Belongs-to? Something else?
2) What happens when you have more than one sudo_tool, and they are all REQUIRED?
3) What if a site requires at least one sudo_tool, but the FE is free to pick the one it wants?
4) What happens if the FE has several credentials, and an entry matches more than one sudo_tool... which one is used? First? RR? Random?
Bottom line, I think the basic idea is sound, but there are several details that need to be thought out.