Hi,
>>> BTW. The scheme with many sgm/prd accounts broke dcache too.
>>
>> A fix for that is on the PPS:
>>
>> https://savannah.cern.ch/patch/?1155
>>
>> If you want to try it already, the rpm is available here:
>>
>>
>> http://cern.ch/eticssoft/repository/org.glite/d-cache-lcg/6.2.0/noarch/
>>
>
> Ahhh! We do near the same in our dcache.kpwd.
> Glad to hear it is a right way to go.
> Will wait to a new release from Oven.
Regarding dCache, I just thought... even if we have multiple sgm/prd
accounts in the WNs, why do we want them in dCache, if, after all, every
user will get mapped to user 001 in her group? I see no traceability
gain there (unless I miss something). Wouldn't it be easier to keep the
old scheme for the dCache nodes (ops001, opssgm and opsprd, all under
group ops) and forget about secondary groups there?
This unless a site allows dcap access to dCache with PNFS mounted, but I
think this is not common.
In what respects WNs, maybe an alternative to init scripts would be that
the VOs run "chmod -R g+w <VO_sw_area>" after every SW installation (and
ignore all errors for the files their current user doesn't own). This
should fix any permission troubles caused by tarballs/RPMs and allow for
later updates by other sgm users. Of course, this requires to check
previously that the site is using pool accounts for sgm, but this could
even be a env var set by yaim or whatever.
Anyway, if ACLs work OK (with NFS and all), I think they are a nicer
solution, so my vote would go for that one. If that will be the way to
go, then probably YAIM can build a script that shows how to set those
ACLs for the usual/trivial case, and for the supported VOs. Even if
sites prefer that this is not run automatically by YAIM, it ca be useful
as an example.
Cheers,
Antonio.
|