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