> Please can you let us (UKI ROC) know your thoughts on use of
> the DAG repository as suggested in the EGEE mail below?
>
This strikes me as a rather bad idea for a number of reasons:
> -----Original Message-----
> From: Nicholas Thackray [mailto:[log in to unmask]]
> Sent: 08 August 2007 14:56
>
> As discussed at the grid operations meeting on Monday, please
> can you contact your sites to find out if they foresee any
> problems with using the DAG, third-party repository for some
> of the external dependencies of the gLite distribution. The
> benefit of this is that we will use a repository which is
> fully maintained
The Dag repository is so called because it's maintained by Dag Wieers,
who's /one guy/. He could get bored, get a new job, or get hit by a
bus at any moment. That strikes me as too much of a single point of
failure.
> and therefore fully up to date with all security patches, etc.
There are no guarantees as to the up to date-ness of DAG packages, the
whole repository runs on a highly automated best-effort basis; one
maintainer simply doesn't have the time to give proper TLC to that many
packages.
Furthermore, the updates policy for the repository is 'bump to the
latest'
not 'isolate and minimally patch'. This is at odds with the very reason
we
use SL as a base system, which is to exclude extraneous changes that
could
upset the applications.
There's also an issue of trust, security and accountability - rpm
installation scripts run as root, so installing a malicious package can
crack a machine with few restrictions. The question 'should I install
this person's package' is equivalent to 'would I give this person a root
login', and I'm not sure for how many of us the answer would be 'Yes'.
> At the moment, the repository in which these external packages are
kept
> is maintained on a best efforts basis and there have been several
> instances in the past where sites have companied of the repository
being
> out of date.
It would seem that if this needs to be done then it needs to be done
properly, and, given that it only needs to be done once for the entire
gLite using grid (if it's done centrally), that doesn't seem to much to
ask.
> If it is agreed that the DAG repository will be used, then a
> recipe will be provided for preventing updates to the OS
> being taken from the repository.
>
This is somewhat worryingly vague - the core of this is that both the
Dag repo and SL include some extra packages above what is in the RHEL
base, and some of those packages have the same names but different
contents
and versioning schemes and it's quite possible to have them each
'upgrade'
over each other's packages in ways that can cause quite subtle breakage.
It would be important to know exactly how this would be reliably
avoided.
There's also the fact that some sites may already be using the Dag repo
in ways that any such 'Don't update from Dag' recipe may break.
I'd have two alternative suggestions:
- the Fedora EPEL repository, new though it is, has a more scalable and
maintainable infrastructure in place than the Dag one so may be a
better
base, and also has a more stable updates policy (roughly in line with
the
RHEL one).
- In either case it doesn't seem to make sense to draw critical packages
from
an external repository that we don't control and that owes us nothing.
It
would seem safer to take the necessary packages from these
repositories as
a starting point, but then include them in the glite repository (or in
a
separate glite-dependencies one) after proper checks.
Ewan
|