Dell Community Repository Setup

[Jack Neely]

On Fri, Dec 05, 2008 at 01:32:57PM -0600, Jeff wrote:
> On Fri, Dec 5, 2008 at 12:29 PM, Jeff <jlar310 at gmail.com> wrote:
> > On Fri, Dec 5, 2008 at 11:38 AM, Jack Neely <jjneely at ncsu.edu> wrote:
> >> Folks,
> >>
> >> I'm sure we can agree that the Dell community Yum repositories are overly
> >> useful.  I'd like to include a method for my users to setup the Dell
> >> repositories from the supported set of packages I provide.  However, I
> >> can't, in good conscious tell my users to simply
> >>
> >>    wget -q -O - http://linux.dell.com/repo/community/bootstrap.cgi | bash
> >>
> >> as root.  There is no way to verify the script the user got came from
> >> Dell or has had any local testing.
> >
> > Not sure about the community repository, but with the software
> 
> Oops, I meant 'hardware' repo.
> 
> > repository (OpenManage), the bootstrap.cgi script uses server side
> > includes to be smart about the location from which it was downloaded.
> > If you mirror the repository (all or part) to a local system under
> > your control and serve it up with Apache, you can do:
> >
> > wget -q -O - http://myrepos.mydomain.com/path/to/files/bootstrap.cgi | bash
> >
> > and everything will come from your servers, including the yum
> > repository configuration for package installation and updates. Nothing
> > will ever download directly from Dell. I have not used the community
> > repo, but I would not be surprised if the bootstrap script behaved in
> > the same way.

You missed the point.  (And I've been way to busy to write back.)  Its
not about how seemingly easy it is to setup the repositories on your
machine.  Its not about easily being able to mirror the repositories and
have our machines go to our servers.

My concerns are about reproducibility and security.  If I can download
the RPMs and verify the GPG signature I know the package hasn't been
tampered with and was built by a trusted party.  I don't really care
where the packages are downloaded from as long as I can do the
verification.

In contrast, with the bootstrap script, no matter who's servers it comes
from, there is no way to verify the script, much less any changes.  Was
DNS spoofed?  Did someone break in?  

I also believe in reproducibility of my systems.  If the script changes I
will have little knowledge (whether I'm using Dell's directly, or
mirroring locally and ignoring updates to the bootstrap script) of
changes that have happened, or changes that I may need to apply to the
script.  What about changes in the setup that need to happen to pre-setup
machines?  So, this method introduces entropy to my managed machines.
Proper packages can be used to update machines configuration, reduce
entropy over the update process, and leave a trail (the old packages) of
changes.

You could GPG sign the bootstrap script.  That may take care of some
concerns but not the introduction of entropy.  Providing signed packages
with the GPG keys and yum repository configuration does.

Customers can use the new packages directly against Dell's repositories.
Customers can re-sign the repository package and include it with their
own trusted repositories to allow machines to install and access the
Dell repos as they wish.  Customers can use their own configuration
management system (or even rebuild the repository package with a define)
to specify the URL of their local mirror.  Or the mirror.cgi script can
be extended to allow customers to always find their local mirror.  (See
the Fedora MirrorManager stuff.)

In essence, the bootstrap script has many issues that make it a less
than reliable choice to manage many machines.  Proper packages to setup
the repositories like RPMFusion and Livna reduce those issues greatly
while still allowing folks to use any mirror of the repositories they
wish.

Jack Neely  

-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89