Dell Community Repository Setup

[Kaj Niemi]

Hi,

On Dec 18, 2008, at 21:47, Jack Neely wrote:

> 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.


The place I work at has similar concerns and we do not utilize the  
bootstrap scripts at all. Instead we have created meta packages that  
get installed as part of the installation sequence and that contain  
the .repo files for all the Dell repositories but pointing at our own  
servers instead. Also our packages contain sufficient provides and  
obsoletes to make sure that Dell's don't override ours by accident if  
one would happen to get installed somehow.

Basically the process goes something like this:

- automagical mirroring of dell's repositories
- someone looks through the diff of changed files
- run a rhel4 compatible createrepo (rather recent change, I/someone  
else reported it to the mailing list)
- mirror the mirror to testing
- make sure dependencies are met during installation
- mirror the mirror to production
- enjoy

This has worked quite well so far for both OMSA and firmware updates  
and we are quite pleased with the results. Hands down the easiest way  
of distributing and installing management utilities and ensuring sw  
upgrades happen on time.

:)



Kaj
-- 
Kaj J. Niemi
<kajtzu at basen.net>
FI +358 45 63 12000
KSA +966 5 45 24 3277



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3833 bytes
Desc: not available
Url : http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20081219/76abff38/attachment.p7s