Attachment 3718 Details for Bug 24286

Zu migrierende Dokumentation

repository-sync_en.tex (text/x-tex), 5.59 KB, created by Moritz Muehlenhoff on 2011-11-01 11:53 CET

(hide)

Description:

Filename:

MIME Type:

Creator: Moritz Muehlenhoff

Created: 2011-11-01 11:53 CET

Size: 5.59 KB

patch

obsolete

>\subsection{Repository synchronisation}
>\label{softwareverteilung:repository-synchronisation}
>
>Operation of several local repository servers can prove practical in certain
>scenarios. For example, in UCS domain with several locations, a repository
>server can be run at each location. Without repository synchronisation, the
>administrator must ensure himself that all repositories are up-to-date, i.e.,
>all repositories must be updated manually by the administrator. This applies
>for release updates, security updates and additional packages. Repository
>synchronisation reduces maintenance down to one repository server.
>
>Alternatively, environments can also do without local repository servers
>entirely and set up a direct access to the online repository or
>synchronisation of the local repository servers can be configured with the
>online repository.
>
>One repository server is designated the master repository server in the
>repository synchronisation. Only changes such as security and release updates
>are performed in this repository; packages are added and removed
>individually. Other repository servers, so-called slave repository servers,
>check regularly to see if changes have been made on the master repository
>server and adopt them. When synchronisation is performed with the online
>repository, this is regarded as the master repository. If additional packages
>are required which are not available over the online repository, a locally
>repository server must be used for this purpose. All other local repository
>servers should be synchronised over this repository server.
>
>A slave repository server does not need to access the master directly. Slave
>repository servers can be used for the synchronisation of another slave
>repository server which retrieves changes from a superordinate repository
>server.
>
>The tool \ucsCommand{univention-repository-update} is used to import a package
>from a \ucsUCSShort{} release update onto the master repository
>server. This supports two modes:
>
>\begin{description}
>\item[\ucsCommand{univention-repository-update cdrom}] Here the repository is
>  updated with an update DVD.
>\item[\ucsCommand{univention-repository-update net}] Here the repository is
>  synchronised with another specified repository server. This is defined in
>  the \ucsUCRV{repository/mirror/server}.
>\end{description}
>
>The possibility also exists of integrating a release update into the
>repository without directly starting an update using the
>\ucsCommand{univention-repository-update} command. This can be done from
>another repository with the \emph{net} option (this can also be the online
>repository) or from an update DVD with the \emph{cdrom} option.
>
>\begin{ucsConsoleInput}
>univention-repository-update net
>
>univention-repository-update cdrom --cdrom --iso ucs_update.iso
>\end{ucsConsoleInput}
>
>When setting up repository synchronisation, the assignment to a superordinate
>server and the time will be configured by policies.
>
>As described in Section~\ref{softwareverteilung:repository-server-zuweisen},
>the repository server policy can be used to specify which repository server
>should be used for package installations for each UCS system. This policy sets
>which repository server should be used as the superordinate repository for the
>synchronisation on all UCS systems with an active local repository at the same
>time. For this reason, no repository server is entered for a master repository
>server.
>
>The time for the automatic repository replication of the individual slave
>repository servers can be defined in the \ucsMenuEntry{Repository synchronisation}
>policy. The month, weekday, day, hour and minute can be specified. The
>synchronisation with the superordinate repository server will be started
>whenever all of the settings are met.
>
>Repository synchronisation can also be configured locally on the systems using
>\ucsUCR{} variables. The \ucsUCRV{repository/mirror/server} defines the repository
>server which will serve as the source for the synchronisation. For example, to
>synchronise directly with the online repository, the \ucsUCR{} variable must
>be set to \ucsURL{apt.univention.de}. Alternatively, to synchronise with
>another local repository server, the fully qualified computer name of the
>system is given.
>
>\begin{ucsConsoleInput}
>univention-config-registry set repository/mirror/server=apt.univention.de
>\end{ucsConsoleInput}
>
>As standard, the repository is only initialised with packages for the
>architecture of the repository server. If the UCS domain is operated with
>systems of differing architectures, the architectures can be specified through
>the \ucsUCRV{repository/mirror/architectures}. The format is to be used in a
>list separated by blanks.
>
>Which standard repositories are synchronised is defined by the
>\ucsUCR{} variables \ucsCommand{\ucsBCindex{repository/online/maintained}}
>for the maintained section,
>\ucsCommand{\ucsBCindex{repository/online/unmaintained}} for the unmaintained
>section and \ucsCommand{\ucsBCindex{repository/online/hotfixes}} for the
>hotfixes. As standard, only the variable
>\ucsCommand{\ucsBCindex{repository/online/maintained}} is set to
>\emph{yes}.
>
>If repositories for components are set on the system, these are also
>synchronised by the specified server.
>
>The \ucsUCRV{repository/mirror/version/start} is used to determine as of which
>\ucsUCS{} version the repositories should be synchronised. For example,
>synchronisation as of \ucsUCSShort{} 2.1-0 can be confirmed by:
>
>\begin{ucsConsoleInput}
>univention-config-registry set repository/mirror/version/start=2.1-0
>\end{ucsConsoleInput}
>
>All changes which are made during synchronisation on a repository server are
>documented locally in the \ucsURL{/var/log/univention/repository.log} file.

Actions: View

Attachments on bug 24286: 3717 | 3718