Servicio de indice de repositorios

Saltar a: navegación, buscar

Introducción

El Servicio de Indice de Repositorios (RIS por su nombre en inglés) es un protocolo cliente-servidor para manejo de repositorios de paquetes. Basado en la información provista por el cliente vía URI, el servidor responde con un índice de repositorios en XML. El cliente entonces usa esta información para manejar los repositorios del servicio en el sistema.

El Servicio de Indice de Repositorios es una extensión del Servicio de actualizaciones de Novell (NU) empleado en el manejo de actualizaciones de SUSE Linux Enterprise. Comparado a los servicios NU, RIS no requiere autenticación. El indice de repositorios puede ser generado basado en la información contenida en la URI, como parámetros, rutas, así como credenciales.

Especificación

Servidor

La tarea principal del servidor es proveer el archivo repoindex.xml el cual se espera en <RIS-URI>/repo/repoindex.xml, donde RIS-URI es la URI base del servicio.

Libzypp mantiene el esquema RNC del archivo repoindex.xml. Las URI de los repositorios en el archivo XML deben apuntar a repositorios de software comunes (como rpmmd, yast u otros); no deben apuntar a otros servicios.

Cliente

El cliente es responsable de manejar los servicios definidos en el sistema, manejar la colección de repositorios pertenecientes al servicio, y, más importante aún, recibir el índice de repositorios desde la URI especificada y actualizar las definiciones de repositorios del sistema de acuerdo al índice. Las siguientes subsecciones describen las responsabilidades del cliente con más detalle.

Agregar Servicios

El cliente debe crear y guardar un archivo .service basado en los datos provistos por el usuario, conteniendo al menos los atributos obligatorios. Una vez hecho, el servicio debe ser conocido por el cliente. El cliente puede (pero no es necesario que) refresque el servicio automáticamente.

Eliminar Servicios

Eliminar un servicio significa eliminar todos sus repositorios del sistema. El cliente no necesita leer el índice de repositorios para completar esta tarea.

Refrescar Servicios

Por cada servicio habilitado en el sistema, la tarea del cliente es leer el índice de repositorios apuntado por la URI del servicio y actualizar los repositorios del sistema de acuerdo a este.

  • Los repositorios relevantes para el sistema objetivo (coincide la distribución objetivo) y no encontrados en el deben ser agregados. Para prevenir conflictos con los alias, el cliente debe tener algún método de desambiguación, como preceder los alias con el nombre del servicio o algo similar. Todos los atributos encontrados en el índice deben ser llenados en el repositorio nuevo.
  • Los repositorios encontrados en el sistema pero no en el índice deben ser eliminados.
  • Los repositorios de índices y sistema se asocian entre sí usando alias y distribución destino.
  • El estado habilitado de repositorios del sistema no se debe tocar. La responsabilidad de habilitar o deshabilitar los repositorios deseados se le debería dejar al usuario. La excepción es si el alias del repositorio está listado en los atributos repostoenable o repostodisable del archivo .service, en cuyo caso el cliente debería habilitar/deshabilitar los correspondientes repositorios. Los nuevos repositorios añadidos se deberían añadir deshabilitados.
  • Las URI de repositorios que ya existan en el sistema y que coincidan se deben actualizar de acuerdo al índice.
  • Opcionalmente, se pueden actualizar otros atributos, pero si el cliente elige hacerlo debería advertir a los usuarios de que cualquier cambio en los repositorios de servicio se perderá en el siguiente refresco.

Los servicios deshabilitados deben ser ignorados.

Deshabilitar Servicios

Deshabilitar un servicio significa deshabilitar todos sus repositorios en el sistema y deshabilitar el servicio mismo. Los servicios deshabilitados aun son conocidos por el sistema, pero son ignorados cuando se refrescan los servicios.

El cliente no necesita leer el índice para completar esta tarea.

Habilitar Servicios

Habilitar un servicio significa habilitar solo el servicio (haciendo que no sea ignorado durante el refrescado). Los repositorios del servicio no deben ser habilitados, a no ser que el cliente implemente un mecanismo para guardar el estado de los repositorios antes de deshabilitar el servicio y restaurar el estado al habilitar el servicio de nuevo.

Autenticación

Si la URI obliga a autenticarse, el cliente debe pedirle al usuario que proporcione las credenciales o recupere unas guardadas anteriormente. Esas credenciales se usan entonces para todos los repositorios del servicio, en caso de que requieran autenticación también.

Archivo .service

Sirve para almacenar información sobre el servicio en el sistema. El archivo está en formato INI, con una sección que tiene el alias del servicio por nombre y los siguientes atributos:

.service file attributes
name description value required default
name Descriptive name of the service. string no <empty>
url URL of the service URL yes <N/A>
type Service type ris (for Repository Index Service) or NONE no (should be detected) NONE
enabled Enabled status 1 or 0 no 0
autorefresh Whether the service should be refreshed automatically when used. 1 or 0 no 0
repostoenable List of repositories which should get enabled during service refresh. The client should remove this attribute from the .service file after the refresh. comma-separated list of repository aliases no <empty>
repostodisable List of repositories which should get disabled during service refresh. The client should remove this attribute from the .service file after the refresh. comma-separated list of repository aliases no <empty>

Si un atributo no está presente en el archivo .service, se usaría el valor por defecto listado. Si type no está presente o es NONE, se debería detectar cuando fuera necesario y eventualmente se debería respaldar en el archivo .service. Una vez que type esté presente y sea conocido, el cliente debería emitir un mensaje de error si se detecta otro tipo de servicio al acceder a la URL de dicho servicio.

Ejemplos

repoindex.xml

Supongamos que tenemos un servicio que proporciona los repositorios principales para la versión actual de openSUSE en http://somesoftwaresite.org/current/opensuse. El archivo repoindex.xml puede parecerse a lo siguiente: 

<?xml version="1.0"?>
<repoindex>
  <repo alias="repo-non-oss" name="openSUSE 12.2 Oss" description="Main openSUSE 12.2 repository"
        url="http://download.opensuse.org/distribution/12.2/repo/non-oss/" distro_target="opensuse-12.2" priority="99"/>
  <repo alias="KDE:Extra" name="KDE:Extra" description="KDE4 Extra" 
        url="http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_12.2/" priority="99"/>
  <repo alias="repo-ati" name="repo-ati" description="Drivers ATI" 
        url="http://geeko.ioda.net/mirror/amd-fglrx-legacy/openSUSE_12.2/" priority="99"/>
  <repo alias="repo-debug" name="openSUSE-12.2-Debug" description="Debug" 
        url="http://download.opensuse.org/debug/distribution/12.2/repo/oss/" priority="99"/>
  <repo alias="repo-debug-update" name="openSUSE-12.2-Update-Debug" description="Debug Update" 
        url="http://download.opensuse.org/debug/update/12.2/" priority="99"/>
  <repo alias="repo-debug-update-non-oss" name="openSUSE-12.2-Update-Debug-Non-Oss" description="Non OSS Debug Update" 
        url="http://download.opensuse.org/debug/update/12.2-non-oss/" priority="99"/>
  <repo alias="repo-libdvdcss" name="repo-libdvdcss" description="Libcss" 
        url="http://opensuse-guide.org/repo/12.2/" priority="99"/>
  <repo alias="repo-oss" name="openSUSE-12.2-Oss" description="OSS" 
        url="http://download.opensuse.org/distribution/12.2/repo/oss/" priority="99"/>
  <repo alias="repo-packman" name="packman" description="Packman"  
        url="http://packman.inode.at/suse/openSUSE_12.2/" priority="99"/>
  <repo alias="repo-source" name="openSUSE-12.2-Source" description="Source" 
        url="http://download.opensuse.org/source/distribution/12.2/repo/oss/" priority="99"/>
  <repo alias="repo-update" name="openSUSE-12.2-Update" description="Update" 
        url="http://download.opensuse.org/update/12.2/" priority="99"/>
  <repo alias="repo-update-non-oss" name="openSUSE-12.2-Update-Non-Oss" description="Upadte Non Oss" 
        url="http://download.opensuse.org/update/12.2-non-oss/" priority="99"/>
  <repo alias="security" name="security" description="Security" 
        url="http://download.opensuse.org/repositories/security/openSUSE_12.2" priority="99"/>
</repoindex>

El cliente podría coger la URI del servicio, buscar el índice y añadir los repositorios openSUSE-15.6-Oss, openSUSE-15.6-Non-Oss y openSUSE-15.6-Update al sistema, haciéndolos disponible para instalaciones. Justo después de la publicación de openSUSE 15.6, los administradores del servicio podrían actualizar el índice con los repositorios actuales. El cliente podría borrar los antiguos y añadir los nuevos al refrescarse.

Otro ejemplo puede ser un servicio de acceso restringido para clientes de un distribuidor de software propietario. El archivo repoindex.xml se puede generar dinámicamente en base a una acreditación y la base de datos de productos comprados. Los repositorios en sí deberían solicitar la autenticación en este caso. 

<repoindex>
  <repo alias="company-foo" name="Company's Foo"
        path="products/foo" distro_target="sle-11-i386" priority="20"/>
  <repo alias="company-bar" name="Company's Bar"
        path="products/bar" distro_target="sle-11-i386" priority="20"/>
  <repo alias="company-foo-upd" name="Company's Foo Updates"
        path="products/foo/updates" distro_target="sle-11-i386" priority="1"/>
</repoindex>

El cliente tomaría la URI del servicio, se autenticaría, buscaría el índice y añadiría los repositorios al sistema. El distribuidor podría actualizar el índice en base a las compras del cliente. El cliente sincronizaría el índice al refrescarse.

.service

[best]
[Mewtwo]
name=Mewtwo
enabled=1
autorefresh=0
url = http://192.168.0.10/
type = ris
Obtenido de «https://es.opensuse.org/index.php?title=Servicio_de_indice_de_repositorios&oldid=16678»