1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
In order to exploit the full possibilities of VOMS/LCMAPS the use of
LDAP as a source of user account information is recommended.
A site can do without by going through the following procedure:
The new system can be made entirely compatible with the
current poolaccount setup, but then one whould not be
surprised that you get only reduced functionality. In effect,
when a site
* pre-allocates a set of poolaccounts for each and every VO,
* pre-assigns the proper group to each (set of accounts), and
* does not use very-fine-grained group-allocations within a VO for
job execution separation
they can get away without LDAP. For many sites, this will be OK.
For example a sites supports the ATLAS, Alice and LHCb VO's,
does not want to use LDAP, but does use VOMS. That sites can
create three three groups and three sets of poolaccounts (say
"lhcb001-lhcb050", etc.) and put each poolaccount into the
proper group.
Now, a grid-mapfile on a per-VO basis will look like
"/VO=lhcb/GROUP=lhcb/*" .lhcb
"/VO=atlas/GROUP=atlas/*" .atlas
"/VO=alice/GROUP=alice/*" .alice
and a groupmapfile:
"/VO=lhcb/GROUP=lhcb/*" lhcb
"/VO=atlas/GROUP=atlas/*" atlas
"/VO=alice/GROUP=alice/*" alice
Now, the acquired credentials will (as if by chance) map
exactly on to the credentials already present in the user
directory (be it files, or NIS), and so updating of those
credentials is not needed. So that site in that config can do
without the need for updating a central userDB (like LDAP).
You can even do it a bit more fine-grained, adding an LHCb MC
prod manager like this:
"/VO=lhcb/GROUP=lhcb/mcprod .lhcbmc
"/VO=lhcb/GROUP=lhcb/* .lhcb
and a group-mapfile:
"/VO=lhcb/GROUP=lhcb/mcprod prodmc
"/VO=lhcb/GROUP=lhcb/* lhcb
and assign (statically) in /etc/passwd:
lhcbmb001:*:501:100:Blah:/home/lhcbmc001:/bin/bash
lhcbmb002:*:502:100:Blah:/home/lhcbmc002:/bin/bash
lhcbmb003:*:503:100:Blah:/home/lhcbmc003:/bin/bash
lhcb001:*:601:100:Blah:/home/lhcb001:/bin/bash
lhcb002:*:602:100:Blah:/home/lhcb002:/bin/bash
and in /etc/group
lhcb:*:100:
prodmc:*:200:lhcbmc001,lhcbmc002,lhcbmc003
This will also do the job of ensuring that the mapping
created for the fork job manager (in-process, using
posix_enf) that is used for doing the "qsub" is the same as
the one used on job execuation on a worker node.
And of course, the obvious solution for those sites that want
fine-grained authorization but do not want to use LDAP: buy
a true MPP systems with all your processors seeing the same
file systems and memory. Cray/SGI will be very happy ;-)
|
