Well if you're actually interested in the gory details... repo-graph to the rescue!
See attached.
- James
On Thu, 2017-06-29 at 12:59 +0100, Stephen Jones wrote:
> On 28/06/17 15:59, Winnie Lacesso wrote:
> >
> > Most of our nodes do NOT have lcg-CA installed. (Some service nodes do
> > & some WN do.) Do other sites?
>
> Hi Winnie,
>
> I've been meaning to some research on this for a very long time. So now
> I have. Daniella is right. The most important package for us, I think,
> is ca-policy-egi-core. lcg-CA still works, I think, but it is
> recommended that ca-policy-egi-core is used for new builds, while lcg-CA
> is for upgrades.
>
> The lcg-CA package (and ca-policy-egi-core) "contains" the certificates
> of certain trusted third parties (CAs) that issue certificates to our
> VOs, so that we can, in turn, trust them. Any node that must check the
> integrity of a job certificate or proxy must have the matching CA
> (trusted third party) certificate installed. There are other such
> packages (perhaps similar to and/or partly or fully replacing and/or
> overlapping lcg-CA) , and there is an (undefined?) Venn diagram
> relationship between all those packages, i.e. some CA certs could occur
> in more than one package. Here's a list of the ones I know of:
>
> a) ca-policy-egi-core
> b) ca_policy_igtf-classic
> c) ca_policy_igtf-mics
> d) ca_policy_igtf-slcs
> e) lcg-CA
> f) ca-policy-lcg
>
> Package (a) simple contains the sum of (b), (c) and (d). Package (e) is
> for upgrading older systems. And package (f) is a mystery. (Aside: note
> the mix of ca<hyphen> and ca<underscore> in the names, which does not
> thrill me!)
>
> So that's complicated enough, but that's just the start. These packages
> are usually "meta-packages". They do not contain the actual
> certificates; instead they call in the actual individual CA rpms as
> dependencies, so they are pulled in by yum.
> (Aside: There may even be hierarchical or horizontal dependency
> relationships between these meta-packages, so that one high level CA
> meta-package perhaps includes subordinate CA meta-packages, or any
> meta-package of (say) a pair pulls its partner. )
>
> So the question boils down to a) what nodes at my site need to check
> that certificates are trusted and b) what (set of?) meta-packages cover
> all the VOs I support.
>
> With respect to which nodes check integrity, I don't know. But it's OK
> to put the CA certs on all my nodes, whether they need it or not (a
> "shotgun solution".) Keeping things simple, all my nodes (near enough)
> will get the CA certs. Like I say, I've been meaning to do some research
> on this to thin it all out and restrict the CA certs to only those nodes
> (worker or server) that need them. It should not be many, now that we
> use ARGUS. Poss. just ARGUS and DPM.
>
> With respect to what meta-packages to use, as stated lcg-CA will do for
> older systems, while new builds should use ca-policy-egi-core.
>
> In practice, below is what is installed on our systems at Liverpool
> (partly as a result of historical precedent over the years). The
> ARC/Condor CE is a bit odd because it uses the slcs, classic and mics
> versions instead of the ca-policy-egi-core verison, which is likely to
> be an error but it does not cause any problems. In fact, I've just
> checked and ca-policy-egi-core simply calls in the equivalent packages.
>
> So, in short, either ca-policy-egi-core (or discrete equivalents) or
> lcg-CA (on older systems) need to be on DPM, ARGUS and possibly other
> systems that needs to check certificate integrity. The BDII and APEL
> almost certainly don't need it, and I'm not sure about WNs and CEs, so I
> put it on anyway.
>
> ARC/Condor CE:
>
> ca_policy_igtf-slcs
> ca_policy_igtf-classic
> ca_policy_igtf-mics
>
> WNs:
>
> ca-policy-lcg
> ca_policy_igtf-slcs
> ca_policy_igtf-mics
> ca-policy-egi-core
> ca_policy_igtf-classic
> lcg-CA
>
> BDII:
>
> ca-policy-egi-core
>
> APEL:
>
> ca-policy-egi-core
>
> DPM:
>
> ca-policy-egi-core
>
> ARGUS:
>
> ca-policy-egi-core
>
> Cheers,
>
> Ste
>
>
|