Software Repositories Management

Table of Contents

1. RPM Repositories Layout
   1. Repository Directories
   2. Associated Templates
2. Updating RPM Repositories

This page is under construction, based on a french version of this documentation....

SCDB provides an optional, lightweight alternative to Quattor SWrep used to serve software packages (RPMs or Solaris PKGs). It requires no additional component to the base SCDB, relying on http server to serve RPMs.

SCDB Software repositories are implemented through directories associated with templates describing directories contents. These templates are maintained through SCDB standard management tool, based on ant.

This page describes SCDB software repositories layout and management operations related to them.

RPM Repositories Layout

Repository Directories

A software repositoryis a container for an arbitrary set of software packages (usually grouped by topic, e.g. OS, middleware...). There is no limit in the number of repositories that can be configured and used at the same time.

In SCDB, every repository corresponds to one specific directory in http server document area. For example, if your Quattor http server is configured with document root /www/quattor, you can create a directory /www/quattor/packages to store software repositories. In this directory, you could create the following repositories :

• ca : production version of CA RPMs
• grid/glite-xxx and grid/lcg-xxxx : RPMs for gLite version xxx and LCG version xxx. For gLite, the recommendation is to create 3 repositories (as subdirectories of grid/glite-xxx) matching the 3 APT repositories : External, Release-xxx, update.
• lemon : RPMs for Lemon
• os : directory root for OS related RPMs. The recommendation is to use one subdirectory for each OS version/architecture combination and for each version/architecture, to create 2 sub-directories base (to receive a copy of the OS standard distribution, e.g. CD-Rom) and update to receive updates to base RPMs. Base RPMs repository will be the the directory containing RPMs in standard distribution.
• quattor : Quattor related RPMs, except ncm-components. This is generally the root for Quattor related repositories, with one repository per Quattor version/archicture.
• ncm-components : ncm-components RPMS.
• site : Miscellanous RPMs used at local site.

This is the repository layout used in examples provided with QWG templates.

Associated Templates

Pour chaque repository, il y a un template associé décrivant le contenu du repository. Lors de la compilation des profils, la disponibilité d'un RPM utilisé dans le profil est vérifiée en utilisant le contenu de ce template et non pas le contenu réel du répertoire.

Les templates associés aux repositories se trouve dans le répertoire cfg/sites/grif/repository du repository Quattor.

La création d'un template pour un nouveau repository se fait en copiant un template existant, en supprimant la variable content et en editant les autres informations (y compris le commentaire).

Tout ajout ou retrait de RPM dans un repository nécessite la mise à jour des templates associés avec la procédure décrite ci-dessous.

Updating RPM Repositories

La mise à jour d'un repository consiste à ajouter ou supprimer un ou des RPMs d'un repository ou à créer ou supprimer un repository. Dans tous les cas, la procédure à suivre est la même et nécessite un accès local à la machine quattorsrv.lal.in2p3.fr. Les différentes étapes sont :

• Mise à jour du répertoire correspondant au repository : cela consiste à créer le répertoire si on créée un nouveau repository et à mettre/supprimer les fichiers .rpm.
• Création du template associé au repository (nouveau repository uniquement) : voir ci-dessus.
• Mise à jour des templates associés : pour cela il faut avoir un copie local à jour du repository Quattor et utiliser la commande ant suivante :

  ant update.rep.templates
  

Le résultat de la commande ant est une nouvelle version des templates associés à tous les repositories qui doit être compilée et déployée suivant la procédure standard (y compris svn commit).

Remarque : Tant qu'on ne supprime pas de RPM dans un repository, l'exécution de cette commande est non destructive et n'a aucun impact sur les versions déjà installées tant que le profil d'une machine n'est pas modifié pour utiliser explicitement la nouvelle version.