On Wed, Apr 7, 2010 at 12:41 PM, Angus Clarke <angusc@xxxxxxxxxxxxxxx> wrote: > Hi all > > > > I am tasked with setting up a yum repository server to handle multiple > releases of RedHat Enterprise clients (RHEL3, RHEL4, RHEL5 etc) and for > multiple architectures (well, just i386 and x86_64) > > > > We do not want to offer the entire distribution tree to clients, instead > offering a subset of RPMS. > > I am happy creating repositories from the installation CDs for each release > and architecture; however my issue arises when considering management of the > associated update repositories. On the yum webserver, we are looking at some > directory tree like: > > > > /var/www/html/repos/ <top level> > > > > …3/i386/os > > …3/i386/updates > > …3/x64/os > > …3/x64/updates > > > > …4/i386/os > > …4/i386/updates > > …4/x64/os > > …4/x64/updates > > > > …5/i386/os > > …5/i386/updates > > …5/x64/os > > …5/x64/updates > > > > We only update certain packages, indeed blanket package updates are out of > the question for us. > > > > I envisage us dropping an updated RPM (for example open-ssl) into the update > repos and then running some command to check the update repo integrity. For this particular point repoclosure is your friend. > Is > there any elegant way of checking for issues - specifically RPM dependency > issues? Remember that the update repos will likely be for a different RedHat > release and architecture than that of the webserver it is all running on. > > > > Any pointers gladly received > > ~A > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended recipient > dissemination or copying of this email is prohibited. If you have received > this in error, please notify the sender by replying by email and then delete > the email completely from your system. > > > > Any views or opinions are solely those of the sender. This communication is > not intended to form a binding contract unless expressly indicated to the > contrary and properly authorised. Any actions taken on the basis of this > email are at the recipient's own risk. > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxx > http://lists.baseurl.org/mailman/listinfo/yum > > -- Steve Traylen _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
