I've just compared the list of RPMs installed on one (older) machine
using lcg-CA and another (newer one) using ca-policy-egi-core: they are
identical (apart from the lcg-CA metapackage itself of course).
John
On 01/08/2017 09:38, Sam Skipsey wrote:
> In any case I would recommend people ensure they have trust anchors
> consistent with supporting things to do with the WLCG IOTA CA, as it's
> also a good idea to boost adoption of it, even if we didn't need
> compliance (which I would assume we do).
>
> Sam
>
> On Tue, 1 Aug 2017 at 08:54 Andrew Lahiff <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>
> However, as mentioned in the EGI Trust Anchors release broadcast
> yesterday:
>
> Sites that need compliance with the WLCG policy should install BOTH
> packages,
> or you will miss out the CERN WLCG IOTA CA specific exception.
>
> I don't know if UK sites need to comply with WLCG policy or not. I
> would have guessed that we do?
>
> Regards,
> Andrew.
>
>
> ________________________________________
> From: Testbed Support for GridPP member institutes
> [[log in to unmask] <mailto:[log in to unmask]>] on
> behalf of sjones [[log in to unmask]
> <mailto:[log in to unmask]>]
> Sent: Thursday, June 29, 2017 6:36 PM
> To: [log in to unmask] <mailto:[log in to unmask]>
> Subject: Re: Do sites need lcg-CA installed?
>
> Thanks James,
>
> The graph is mind blowing, at first glance.
>
> I'm So glad we don't have to remember all those relationships.
>
> Rule: ca-policy-egi-core for new build designs. lcg-CA for old stuff
> just to keep it going.
>
> Cheers,
>
> Ste
>
> On 2017-06-29 15:29, James Adams wrote:
> > 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
> >>
> >>
>
|