diff --git a/DC-SAP-rmt-installing-configuring b/DC-SAP-rmt-installing-configuring new file mode 100644 index 000000000..3df52dd8a --- /dev/null +++ b/DC-SAP-rmt-installing-configuring @@ -0,0 +1,15 @@ +# This file originates from the project https://github.com/openSUSE/doc-kit +# This file can be edited downstream. + +## Basics +MAIN="rmt-installing-configuring.asm.xml" +SRC_DIR="articles" +IMG_SRC_DIR="images" + +PROFOS="sles4sap" +#PROFCONDITION="16.0" +#PROFCONDITION="suse-product;beta" +#PROFCONDITION="community-project" + +STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns" +FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse-ns" \ No newline at end of file diff --git a/DC-SAP-rmt-mirroring-repositories b/DC-SAP-rmt-mirroring-repositories new file mode 100644 index 000000000..457a675d9 --- /dev/null +++ b/DC-SAP-rmt-mirroring-repositories @@ -0,0 +1,18 @@ +# This file originates from the project https://github.com/openSUSE/doc-kit +# This file can be edited downstream. + +## Basics +MAIN="rmt-mirroring-repositories.asm.xml" +SRC_DIR="articles" +IMG_SRC_DIR="images" + +## Profiling +PROFOS="sles4sap" +#PROFCONDITION="16.0" +#PROFARCH="x86_64;zseries;power;aarch64" + +## stylesheet location +STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns" +FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2021-ns" + +DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat" \ No newline at end of file diff --git a/DC-SLES-rmt-installing-configuring b/DC-SLES-rmt-installing-configuring new file mode 100644 index 000000000..6ad44573a --- /dev/null +++ b/DC-SLES-rmt-installing-configuring @@ -0,0 +1,18 @@ +# This file originates from the project https://github.com/openSUSE/doc-kit +# This file can be edited downstream. + +## Basics +MAIN="rmt-installing-configuring.asm.xml" +SRC_DIR="articles" +IMG_SRC_DIR="images" + +## Profiling +PROFOS="sles" +#PROFCONDITION="16.0" +#PROFARCH="x86_64;zseries;power;aarch64" + +DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat" + +## stylesheet location +STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns" +FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2021-ns" diff --git a/DC-SLES-rmt-mirroring-repositories b/DC-SLES-rmt-mirroring-repositories new file mode 100644 index 000000000..f086b7167 --- /dev/null +++ b/DC-SLES-rmt-mirroring-repositories @@ -0,0 +1,18 @@ +# This file originates from the project https://github.com/openSUSE/doc-kit +# This file can be edited downstream. + +## Basics +MAIN="rmt-mirroring-repositories.asm.xml" +SRC_DIR="articles" +IMG_SRC_DIR="images" + +## Profiling +PROFOS="sles" +#PROFCONDITION="16.0" +#PROFARCH="x86_64;zseries;power;aarch64" + +DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat" + +## stylesheet location +STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns" +FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2021-ns" diff --git a/articles/rmt-installing-configuring.asm.xml b/articles/rmt-installing-configuring.asm.xml new file mode 100644 index 000000000..bbf1d8736 --- /dev/null +++ b/articles/rmt-installing-configuring.asm.xml @@ -0,0 +1,142 @@ + + + + + %entities; +]> + + + + + + + + Introduction to installing RMT + + + For more information + + + + + + RMT storage requirements + + + RMT configuration files + + + + + + Installing RMT during system installation + + + Installing RMT on an existing system + + + Deploying RMT on Kubernetes + + + Configuring RMT with Ansible + + + Enabling SLP announcements + + + Accessing SCC from behind a firewall + + + Managing TLS/SSL certificates + + + + + + Legal Notice + + + GNU Free Documentation License + + + + + + Installing and configuring an RMT server + + 2026-07-20 + + + Initial version. + + + + + + + &x86-64; + &power; + + + &productname; + + Install and configure a SUSE RMT server + Learn how to install the Repository + Mirroring Tool and configure it with the Ansible playbook workflow + Install and configure an RMT server + on &suselinux; + + Systems Management + + + Installation + Configuration + + Products & Solutions + + + https://bugzilla.suse.com/enter_bug.cgi + Documentation + SUSE Linux Enterprise Server &productnumber; + amrita.sakthivel@suse.com + + yes + + + &rmt; (Repository Mirroring Tool) is a proxy system that mirrors software repositories and registers client machines within a private network. By acting as a local intermediary for &scc;, &rmt; enables administrators to manage package updates and client registrations locally without direct external Internet access for every system, significantly enhancing network security and reducing bandwidth usage. + + + REQUIREMENTS + + + A newly installed &productname; &productnumber; system or &minvm; image to host the &rmt; server. + Valid &scc; organization credentials. + Sufficient local storage space (approximately 1.5 times the size of all enabled repositories). + + + + + + + + + + + + + + + + + + + + + diff --git a/articles/rmt-mirroring-repositories.asm.xml b/articles/rmt-mirroring-repositories.asm.xml new file mode 100644 index 000000000..e9d26b278 --- /dev/null +++ b/articles/rmt-mirroring-repositories.asm.xml @@ -0,0 +1,131 @@ + + + + + %entities; +]> + + + + + + + + Introduction to mirroring with RMT + + + For more information + + + + + + Obtaining mirroring credentials + + + Synchronizing repository metadata + + + Mirroring packages + + + Enabling and disabling mirroring of repositories + + + Deleting mirrored data + + + Adding custom repositories + + + Exporting and importing repositories + + + + + + Legal Notice + + + GNU Free Documentation License + + + + + + Mirroring repositories on an RMT server + + 2026-07-20 + + + Initial version. + + + + + + + &x86-64; + &power; + + + &productname; + + Mirror repositories on an RMT server + Learn how to mirror, synchronize, and manage SUSE and custom repositories on a Repository Mirroring Tool server + Mirror repositories with RMT + + Systems Management + + + Configuration + + Products & Solutions + + + https://bugzilla.suse.com/enter_bug.cgi + Documentation + SUSE Linux Enterprise Server &productnumber; + amrita.sakthivel@suse.com + + yes + + + + Repository Mirroring Tool (RMT) repository mirroring downloads software packages and metadata from SUSE Customer Center (SCC) or custom sources directly to a local RMT server. + Mirroring optimizes network bandwidth usage and speeds up updates by serving registered client machines locally, eliminating individual external downloads. + It also enables seamless package transfers to disconnected or air-gapped environments + + + + REQUIREMENTS + + + A running &rmt; server on &productname; &productnumber;, configured with &ansible;. + Active &scc; organization credentials. + + + + + + + + + + + + + + + + + + + diff --git a/glues/rmt-installing-intro.xml b/glues/rmt-installing-intro.xml new file mode 100644 index 000000000..9eb9e9fe6 --- /dev/null +++ b/glues/rmt-installing-intro.xml @@ -0,0 +1,49 @@ + + + %entities; +]> + + + + + + Introduction + + + + This article describes how to run an &rmt; server on + &productname; &productnumber;. Install &rmt; directly during the + installation of &productname; or install it on a running system. After the + packages are installed, use &ansible; to do an initial configuration. + + + The &rmt; server registers client systems running &slea; 12 and newer, + including &productname; &productnumber; itself. To run the &rmt; + server on &slea; 15 instead, where it is configured with &yast; rather + than &ansible;, see the + Repository Mirroring Tool Guide for &slsa; 15. + + + &rmt; server conflicts with installation server + + Configuring a server to be an &rmt; server installs and configures the + NGINX Web server, listening on port 80. + + + However, configuring a machine to be an installation server automatically + installs the Apache Web server and configures it to listen on port 80. + + + Do not try to enable both these functions on the same server. It is not + possible for a single server to host both simultaneously. + + + diff --git a/glues/rmt-installing-more-info.xml b/glues/rmt-installing-more-info.xml new file mode 100644 index 000000000..bcbcf5e56 --- /dev/null +++ b/glues/rmt-installing-more-info.xml @@ -0,0 +1,39 @@ + + + %entities; +]> + + + For more information + + + + To learn more about &rmt;, refer to the following resources: + + + + + + + Repository Mirroring Tool Guide for &slsa; 15 + — the complete administrator's guide to &rmt;, including client + configuration and the rmt-cli command reference. + It documents the &slea; 15 version of &rmt;, which is configured + with &yast; instead of &ansible;. + + + + + &rmt; source code and issue tracker on GitHub. + + + + diff --git a/glues/rmt-mirroring-intro.xml b/glues/rmt-mirroring-intro.xml new file mode 100644 index 000000000..8ff4d02e3 --- /dev/null +++ b/glues/rmt-mirroring-intro.xml @@ -0,0 +1,56 @@ + + + %entities; +]> + + + + + + Introduction + + + + You can mirror the installation and update repositories on the &rmt; + server. This eliminates the need to download updates on every machine, saving time and bandwidth. + + + By default, &rmt; automatically mirrors enabled product repositories once every night and stores the mirrored repositories in + /var/lib/rmt/public/repo. + + + Change the default location of the mirrored repositories + + To change the default location of the mirrored repositories, point the + /usr/share/rmt/public/repo symbolic link to the + desired directory. Use the command ln -sfn TARGET + /usr/share/rmt/public/repo + + + (Replace TARGET with the desired destination). Make + sure that the target has read and write permissions for the + rmt user and nginx group. + + + + When enabled repositories are fully mirrored, you can register your client + systems against &rmt; by running SUSEConnect --url + https://&rmt;_HOSTNAME on the client + machine. After successful registration, the repositories from the &rmt; + server are used by Zypper on the client machine. + + + &sls; 11 clients + + &rmt; does not support clients with &sls; versions 11 and older. + + + diff --git a/glues/rmt-mirroring-more-info.xml b/glues/rmt-mirroring-more-info.xml new file mode 100644 index 000000000..477dedec2 --- /dev/null +++ b/glues/rmt-mirroring-more-info.xml @@ -0,0 +1,38 @@ + + + %entities; +]> + + + For more information + + + + To learn more about mirroring with &rmt;, refer to the following resources: + + + + + + + The rmt-cli command reference + — the full list of subcommands for managing repositories, + products, and mirroring. + + + + + Repository Mirroring Tool Guide + — the complete administrator's guide to &rmt;. + + + + diff --git a/images/rmt_installation.png b/images/rmt_installation.png new file mode 100644 index 000000000..693df13b1 Binary files /dev/null and b/images/rmt_installation.png differ diff --git a/images/scc_eye_icon.png b/images/scc_eye_icon.png new file mode 100644 index 000000000..0cc00525a Binary files /dev/null and b/images/scc_eye_icon.png differ diff --git a/references/rmt-configuration-files.xml b/references/rmt-configuration-files.xml new file mode 100644 index 000000000..79307a59a --- /dev/null +++ b/references/rmt-configuration-files.xml @@ -0,0 +1,268 @@ + + + %entities; +]> + + + + + + &rmt; configuration files + + + + Reference of the options in the main &rmt; configuration file + /etc/rmt.conf and of the SSL certificate + locations used by &rmt;. + + + + + The main &rmt; configuration file is /etc/rmt.conf. + Configuration is performed using the &ansible; playbooks provided in the + ansible-rmt-server package. + + +
+ Main configuration file <filename>/etc/rmt.conf</filename> + + The initial configuration is performed using &ansible;. Only the + proxy configuration needs to be entered manually. The other configuration + parameters are documented for reference. + + + All available configuration options can be found in the + /etc/rmt.conf file. + + +
+ Mirroring settings + + The mirroring section lets you adjust mirroring + behavior. + + + + mirror_src + + + Decides whether to mirror source RPM packages (architecture is + src). + + + + + dedup_method + + + Creates hard links during mirroring when set to hardlink. + If the file system does not support hard links, it can be set to copy instead. + Possible values: hardlink, + copy. + + + + +
+
+ HTTP client settings + + The http_client section defines the global HTTP + connection settings of &rmt;. + + + + verbose + + + Enables additional debug output to the &systemd; journal. + + + + + proxy + + + The proxy server URL including the protocol and the port number. For + example: http://proxy_url:8080. + + + + + noproxy + + + A list of domains that should not go through the + proxy, separated by commas. For example: + localhost.mylocaldomain. + + + + + proxy_auth + + + This setting determines the + proxy authentication mechanism. Possible values are: + , , + , , + , , + . + + + + + proxy_user + + + The proxy server user name. + + + + + proxy_password + + + The proxy server password. + + + + + low_speed_limit + + + Lower speed limit when a download should be aborted in bytes/sec. + + + + + low_speed_time + + + Time until a download gets aborted, when download speed is below + low_speed_limit. + + + + +
+
+ Settings for accessing &suse; repositories + + The scc section contains your mirroring + credentials for contacting &scc;. To obtain your mirroring + credentials, see + Mirroring credentials. + + + Valid configuration keys for the section are: + + + + username + + + Mirroring credentials user name. + + + + + password + + + Mirroring credentials password. + + + + +
+
+ Web server settings + + The web_server section lets you tune the performance of your &rmt; server. + + + + min_threads + + + Specifies the minimum number of threads that an &rmt; server worker should spawn. + + + Acceptable values: Integer greater than or equal to 1. + + + + + max_threads + + + Specifies the maximum number of threads that an &rmt; server worker should spawn. + + + Acceptable values: Integer greater than or equal to 1. + + + + + workers + + + Specifies the number of Web workers for &rmt;. + + + Acceptable values: Integer greater than or equal to 1. + + + + +
+
+ +
+ SSL certificates and HTTPS + + By default access to API endpoints consumed by + &suse;Connect is limited to HTTPS only. nginx is + configured to use an SSL certificate and a private key from the following + locations: + + + + Certificate: /etc/rmt/ssl/rmt-server.crt + + + Private key: /etc/rmt/ssl/rmt-server.key + + + + The &ansible; playbook generates a custom certificate authority which + is used to sign HTTPS certificates. This means that to register, + this certificate authority must be trusted by the client machines: + + + + + For registrations during installation from the media or with + &yast; Registration module, a message will appear, prompting to + trust the server certificate. + + + + + For registering a client system on the command line, use the + rmt-client-setup script. For details, see + Configuring clients with rmt-client-setup. + + + +
+ diff --git a/references/rmt-storage-requirements.xml b/references/rmt-storage-requirements.xml new file mode 100644 index 000000000..59ad0b5d8 --- /dev/null +++ b/references/rmt-storage-requirements.xml @@ -0,0 +1,50 @@ + + + %entities; +]> + + + + + + Storage requirements + + + + The storage an &rmt; server requires depends on the number of + repositories and architectures that you mirror, and the number of products you enable. + + + + + Downloaded packages are stored in + /usr/share/rmt/public/repo, which is a symbolic link + to /var/lib/rmt/public/repo/. + + + + The amount of storage your &rmt; server requires depends on several + variables: the number of repositories and architectures that you mirror, + and the number of products that are enabled. + As a general guide, 1.5 + times the total size of all enabled repositories should be sufficient. + This is about 200 GB per &sle; release, including all extensions. + + + &rmt; mirroring fails when <filename>/tmp</filename> runs out of space + + When &rmt; mirrors repositories from &scc;, it writes large temporary files in /tmp. + If /tmp is too small, or is part of the /root file system, and + this file system is small in size, /tmp quickly runs out of space, resulting in a mirroring failure. + For more information, refer to . + + + diff --git a/tasks/rmt-accessing-scc-behind-firewall.xml b/tasks/rmt-accessing-scc-behind-firewall.xml new file mode 100644 index 000000000..bbf7d4734 --- /dev/null +++ b/tasks/rmt-accessing-scc-behind-firewall.xml @@ -0,0 +1,83 @@ + + + %entities; +]> + + + + + + Accessing &scc; from behind a firewall + + + + Allow the &rmt; server to reach &scc; when it is located behind a + firewall that does not support host name allowlisting. + + + + + If the &rmt; server is behind a firewall and cannot access &scc; + directly, you need to allow connections to the following domains on both + 80 and 443 ports on the firewall. + + + + + scc.suse.com + + + + + updates.suse.com + + + + + installer-updates.suse.com + + + + + If the firewall you are using does not support host name + allowlisting—such as &firewalld;—you need to allow connections + to the corresponding IP addresses as described in the following steps. + + + + + Resolve the IP address of the domain, for example, + installer-updates.suse.com. + +&prompt.user;nslookup installer-updates.suse.com +[...] +Address: 152.199.22.115 + + + + Add firewall rules for ports 80 and 443 for each discovered IP + address. + +&prompt.sudo;firewall-cmd --permanent --zone=public \ + --add-rich-rule='rule family="ipv4" source address="152.199.22.115" \ + port protocol="tcp" port="80" accept' +&prompt.sudo;firewall-cmd --permanent --zone=public \ + --add-rich-rule='rule family="ipv4" source address="152.199.22.115" \ + port protocol="tcp" port="443" accept' + + + + Reload the firewall configuration. + +&prompt.sudo;firewall-cmd --reload + + + diff --git a/tasks/rmt-configuring-with-ansible.xml b/tasks/rmt-configuring-with-ansible.xml new file mode 100644 index 000000000..72b2edbf6 --- /dev/null +++ b/tasks/rmt-configuring-with-ansible.xml @@ -0,0 +1,183 @@ + + + %entities; +]> + + + + + + Configuring &rmt; with &ansible; + + + + Configure &rmt; with the playbooks and roles provided by the + ansible-rmt-server package. + + + + + Configure &rmt; with &ansible; as described in the following procedure. + The ansible-rmt-server package provides pre-built + playbooks and roles for automated &rmt; configuration. It is assumed that + this procedure is executed on a newly installed system. + + + + + + Navigate to the &ansible; configuration directory: + +&prompt.root;cd /usr/share/ansible/rmt + + + + + Create the configuration file group_vars/all.yml + based on the provided example: + +&prompt.root;cp group_vars/all.yml.example group_vars/all.yml + + + + + Edit group_vars/all.yml and configure the + following variables: + + + + rmt_db_username + + + Database user name for &rmt; (default: rmt) + + + + + rmt_db_password + + + Secure password for the &rmt; database user + + + + + RMT_ORGANIZATION_USERNAME + + + Your &scc; organization credentials. To retrieve your + credentials, refer to + Mirroring credentials. + + + + + RMT_ORGANIZATION_PASSWORD + + + Your &scc; organization password + + + + + + + Example configuration: + +--- +rmt_db_username: rmt +rmt_db_password: "your_secure_password" + +rmt: + RMT_ORGANIZATION_USERNAME: "your_scc_username" + RMT_ORGANIZATION_PASSWORD: "your_scc_password" + + + + + Run the &ansible; playbook to configure &rmt;: + +&prompt.root;ansible-playbook site.yml + + + The playbook will automatically perform the following tasks: + + + + Install required dependencies (MariaDB, nginx, Python modules) + + + Configure and start the MariaDB database service + + + Create the &rmt; database and database user + + + Generate SSL certificates for HTTPS + + + Configure nginx virtual hosts + + + Create /etc/rmt.conf configuration file + + + Run database migrations + + + Start and enable the &rmt; server service + + + + + + + On systems with SELinux in enforcing mode, allow nginx to connect to + the &rmt; back end service: + +&prompt.root;setsebool -P httpd_can_network_connect 1 + + + + + Verify the installation by checking the API health status: + +&prompt.root;curl -s http://localhost/api/health/status +{"state":"online"} + + + + + SSL certificate locations + + The &ansible; playbook generates SSL certificates at the following + locations: + + + +CA certificate + /etc/rmt/ssl/rmt-ca.crt + + + CA private key + /etc/rmt/ssl/rmt-ca.key + + + Server certificate + /etc/rmt/ssl/rmt-server.crt + + + Server private key + /etc/rmt/ssl/rmt-server.key + + + + diff --git a/tasks/rmt-deploying-on-kubernetes.xml b/tasks/rmt-deploying-on-kubernetes.xml new file mode 100644 index 000000000..db441014f --- /dev/null +++ b/tasks/rmt-deploying-on-kubernetes.xml @@ -0,0 +1,319 @@ + + + %entities; +]> + + + + + + Deploying &rmt; on top of the &kube; cluster + + + + Deploy &rmt; on a &kube; cluster using Helm + as the package manager. + + + + + This section describes how to deploy &rmt; on a &kube; cluster. + It uses Helm as the package manager to interact with + the &kube; cluster. Find more details about using Helm at + . + + +
+ Prerequisites + + + + Running &kube; cluster + + + + + helm command configured to interact with the + cluster + + + +
+ +
+ Application components + + Each component of the &rmt; application is deployed in its own + container. &rmt; consists of the following components: + + + + &rmt; server + + + Containerized version of the &rmt; application server with the + ability to pass its configuration via Helm values. Storage is + done on a volume that is allocated to the &kube; cluster. You + need to adjust the size of the storage depending on the number of + repositories you need to mirror. + + + + + &mariadb; + + + The database back-end for &rmt;. No post-installation task is + needed since &rmt; creates the required database and tables + at start-up. If passwords are not + specified in the values.yaml file, they are + generated automatically. + + + + + nginx + + + A Web server configured for &rmt; routes. Having a properly + configured Web server allows you to target your Ingress traffic + (for &rmt;) to this nginx service directly. You do not need to + configure Ingress for &rmt; -specific path handling, as nginx is + configured to take care of this itself. + + + + +
+ +
+ The <filename>values.yaml</filename> file + + The &rmt; chart includes the values.yaml file + where all parameters are documented and their default values are + defined. You can override these values by providing your own values + file, for example: + +&prompt.user;cat << EOF > rmt-config.yaml +--- +app: + storage: + class: local-path + scc: + enabled: false + username: "UXXXXXXX" + password: "PASSXXXX" + products_enable: + - SLES/15.3/x86_64 + - sle-module-python2/15.3/x86_64 + products_disable: + - sle-module-legacy/15.3/x86_64 + - sle-module-cap-tools/15.3/x86_64 +db: + storage: + class: local-path +ingress: + enabled: true + hosts: + - host: chart-example.local + paths: + - path: "/" + pathType: Prefix + tls: + - secretName: rmt-cert + hosts: + - chart-example.local +EOF + + + + + The local-path storage class is only available in + Rancher workloads. To make the Helm chart succeed, you need to install the + local-path storage provisioner by running the following + command: + +&prompt.user;kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.26/deploy/local-path-storage.yaml + + + + And to install &rmt;, run: + +&prompt.user;helm install rmtsle oci://registry.suse.com/suse/rmt-helm -f rmt-config.yaml + +
+ Required values + + + Key: app.scc.password + + + Type: string + + + Default: + nil + + + Description: &scc; proxy password. The password string needs to be + put inside quotes. If the quote character " is part of the + string, it has to be escaped with \. + + + + + Key: app.scc.username + + + Type: string + + + Default: + nil + + + Description: &scc; proxy user name. The user name string needs to be + put inside quotes. If the quote character " is part of the + string, it has to be escaped with \. + + + + + Key: app.scc.products_enable + + + Type: list + + + Default: + [] + + + Description: list of + products to enable for mirroring + + + + + Key: app.scc.products_disable + + + Type: list + + + Default: + [] + + + Description: list of + products to disable for mirroring + + + + + Key: app.storage.class + + + Type: string + + + Default: + "" + + + Description: Kubernetes + storageclass. + + + + + Key: db.storage.class + + + Type: string + + + Default: + "" + + + Description: Kubernetes + storageclass. + + + + + Key: ingress.enabled + + + Type: bool + + + Default: + false + + + Description: Ingress Enabled + + + + + Key: ingress.hosts[0] + + + Type: object + + + Default: + {"host":"chart-example.local","paths":[{"path":"/","pathType":"Prefix"}]} + + + Description: DNS name at + which the &rmt; service will be accessible from clients + + + + + Key: ingress.tls[0].hosts[0] + + + Type: string + + + Default: + "chart-example.local" + + + Description: DNS name at + which the &rmt; service will be accessible from clients + + + + + Key: ingress.tls[0].secretName + + + Type: string + + + Default: + "rmt-cert" + + + Description: TLS Ingress + Certificate + + + + +
+
+ diff --git a/tasks/rmt-enabling-slp-announcements.xml b/tasks/rmt-enabling-slp-announcements.xml new file mode 100644 index 000000000..e11677f73 --- /dev/null +++ b/tasks/rmt-enabling-slp-announcements.xml @@ -0,0 +1,59 @@ + + + %entities; +]> + + + + + + Enabling SLP announcements + + + + Enable SLP (Service Location Protocol) announcements so that clients can discover the &rmt; + service on the network. + + + + + &rmt; includes the SLP service description file + /etc/slp.reg.d/rmt-server.reg. To enable SLP + announcements of the &rmt; service, follow these steps: + + + + + + If &firewalld; is running, open relevant ports and reload the + &firewalld; configuration: + +&prompt.sudo;firewall-cmd --permanent --add-port=427/tcp +success +&prompt.sudo;firewall-cmd --permanent --add-port=427/udp +success +&prompt.sudo;firewall-cmd --reload + + + + Verify that the SLP server is installed and install it if it is not: + +&prompt.sudo;zypper install openslp-server + + + + Enable and start the SLP service: + +&prompt.sudo;systemctl enable slpd.service +&prompt.sudo;systemctl restart slpd.service + + + diff --git a/tasks/rmt-installing-during-installation.xml b/tasks/rmt-installing-during-installation.xml new file mode 100644 index 000000000..9789e32a3 --- /dev/null +++ b/tasks/rmt-installing-during-installation.xml @@ -0,0 +1,52 @@ + + + %entities; +]> + + + + + + Installation &rmt; during system installation + + + + Install &rmt; while installing &productname; by selecting the + rmt-server package. + + + + + To install it during installation, select the + rmt-server package. Package selection can be + found in Installation Settings when selecting + Software. + + +
+ &rmt; pattern + + &rmt; pattern installation + + + + + + + +
+ + + Check for available &rmt; updates immediately after installing &sls; + using the zypper patch command because &suse; + continuously releases maintenance updates for &rmt;. + + diff --git a/tasks/rmt-installing-existing-system.xml b/tasks/rmt-installing-existing-system.xml new file mode 100644 index 000000000..f6f7070f3 --- /dev/null +++ b/tasks/rmt-installing-existing-system.xml @@ -0,0 +1,86 @@ + + + %entities; +]> + + + + + + Installing &rmt; on an existing system + + + + Install &rmt; on a running &productname; system with + zypper. + + + + + To install &rmt; on a running &productname; installation, use the + zypper command: + + +&prompt.sudo;zypper in rmt-server + +
+ Installing &rmt; on &minvm; + + &minvm; is a minimal customizable operating system that is + designed for specific usage scenarios, for example, to be run as: + + + + + A container host + + + + + A virtual machine guest + + + + + An appliance base system + + + + + A small server image + + + + + &minvm; image is a good choice for being used as an &rmt; server. You + can download &minvm; images for &kvm;, &xen;, &hyperv;, &vmware;, + and OpenStack from the public &sls; download page at + . Find more + information on &minvm; at + . + + + Installing &rmt; on &minvm; is the same as installing it on an + existing system. To install &rmt; on + &minvm;, run the following command from the &minvm; command line as + &rootuser;: + +&prompt.root;zypper install rmt-server ansible-rmt-server nginx mariadb + + Hardware requirements + + When installing &rmt; on &minvm;, be aware that it requires a minimum + of 100 GB disk space, depending on the products you select to mirror. + Another requirement is a CPU with at least two cores and 2 GB of RAM. + + +
+ diff --git a/tasks/rmt-mirroring-custom-repositories.xml b/tasks/rmt-mirroring-custom-repositories.xml new file mode 100644 index 000000000..a42dec657 --- /dev/null +++ b/tasks/rmt-mirroring-custom-repositories.xml @@ -0,0 +1,97 @@ + + + %entities; +]> + + + + + + Adding custom repositories + + + + Mirror repositories that are not provided by &scc;, such as + third-party or &obs; repositories, with your &rmt; server. + + + + + You can mirror custom repositories with the &rmt; server. These + repositories are not provided by &scc;. Repositories can be provided + by, for example, the &obs;, third-party vendors, or created with + createrepo. + + + + Custom repositories can either be stand-alone, or you can attach them to + products. This allows you to connect multiple repositories with one + command on a client registered to the &rmt; server. + + + + The following example procedure illustrates the mirroring of a + third-party repository. + + + + + + Add the remote repository to the &rmt; server. Replace + URL with the URL to the repository. + Replace NAME with a name of your choice + for the repository. + +&prompt.root;rmt-cli repos custom add URL NAME + + + + List all custom repositories to get the ID of the new repository. + +&prompt.root;rmt-cli repos custom list + + + + Optionally attach the new custom repository to a product. For + example, if the new custom repository is required by all desktop + clients, it can be attached to the &sled; product. + +&prompt.root;rmt-cli repos custom attach REPOSITORY_ID PRODUCT_ID + + Replace REPOSITORY_ID with the ID of the + new custom repository. Replace PRODUCT_ID + with the ID of a product you want the repository to be attached to. + If you need to retrieve the PRODUCT_ID, + use the command rmt-cli products list --all. + + + + When custom repositories are associated with a product, clients + registering with that product see it as disabled. To enable the + repository, find its ID with the command zypper + lr and run: + +&prompt.root;zypper mr -e REPO_ID + + + + + Enable mirroring of the new custom repository. + +&prompt.root;rmt-cli repos custom enable REPOSITORY_ID + + + + + To get a list of all available custom repositories commands, see + the rmt-cli command reference. + + diff --git a/tasks/rmt-mirroring-deleting-data.xml b/tasks/rmt-mirroring-deleting-data.xml new file mode 100644 index 000000000..1aaa1c4b4 --- /dev/null +++ b/tasks/rmt-mirroring-deleting-data.xml @@ -0,0 +1,72 @@ + + + %entities; +]> + + + + + + Deleting mirrored data + + + + Reclaim disk space by removing the mirrored data of repositories that + are no longer enabled. + + + + + After you disable the mirroring of a repository or product as described + in , the mirrored data + remains on your local hard disk. This includes the mirrored RPM + packages. + + + + To delete disabled repository data, use the command rmt-cli + repos clean. With this command, &rmt; verifies that only enabled + repositories are mirrored and provides a way to delete invalid data. + + + + Before removing any data, the command lists the affected repositories and + requires the user to input yes to continue. + + +&prompt.sudo;rmt-cli repos clean +RMT found locally mirrored files from the following repositories which are not marked to be mirrored: + +SLE-Product-SLES15-Updates for sle-15-x86_64 +SLE-Product-SLES15-Pool for sle-15-x86_64 +SLE15-Installer-Updates for sle-15-x86_64 + +Would you like to continue and remove the locally mirrored files of these repositories? +Only 'yes' will be accepted. + +Enter a value: yes + +Deleted locally mirrored files from repository 'SLE-Product-SLES15-Updates for sle-15-x86_64'. +Deleted locally mirrored files from repository 'SLE-Product-SLES15-Pool for sle-15-x86_64'. +Deleted locally mirrored files from repository 'SLE15-Installer-Updates for sle-15-x86_64'. + +Clean finished. An estimated 157 MB were removed. + + + + Manually remove repository data + + To delete disabled repository data, manually remove its corresponding + directory: + +&prompt.sudo;rm -r /usr/share/rmt/public/repo/SUSE/Products/PRODUCT/VERSION/ARCHITECTURE/ + + diff --git a/tasks/rmt-mirroring-enabling-disabling-repositories.xml b/tasks/rmt-mirroring-enabling-disabling-repositories.xml new file mode 100644 index 000000000..fa6cd6770 --- /dev/null +++ b/tasks/rmt-mirroring-enabling-disabling-repositories.xml @@ -0,0 +1,163 @@ + + + %entities; +]> + + + + + + Enabling and disabling mirroring of repositories + + + + Control which repositories &rmt; mirrors, either per product or per + individual repository. + + + + + You can enable or disable the mirroring of repositories individually or + by product. You can specify one or more repositories or products at once. + When repositories are enabled, their packages are downloaded and updated + during the mirroring process. To enable or disable mirroring of + repositories, you either need the product string or ID, or the repository + name or ID. Enabling or disabling a product is desired, because this + automatically enables or disables all repositories associated with the + product. + + +
+ Using products + + To enable or disable all repositories of a product, use the + rmt-cli products enable + ID and rmt-cli products + disable ID commands. To retrieve + an ID for an enabled product, use the rmt-cli products + list command. To get the ID of a disabled + product that is still available, run the rmt-cli products list --all + command. + + + Example: + +&prompt.sudo;rmt-cli products list --all ++------+----------------------+---------+--------+--------------+--------------- +| ID | Product | Version | Arch | Mirror? | Last mirrored ++------+----------------------+---------+--------+--------------+--------------- +[...] +| 1743 | SUSE Package Hub | 15 | x86_64 | Don't Mirror | +| | PackageHub/15/x86_64 | | | | +[...] + +&prompt.sudo;rmt-cli products enable 1743 +Found product by target 1743: SUSE Package Hub 15 x86_64. +Enabling SUSE Package Hub 15 x86_64: + SUSE Package Hub 15 x86_64: + Enabled repository SLE-Module-Packagehub-Subpackages15-Pool. + Enabled repository SLE-Module-Packagehub-Subpackages15-Updates. + Enabled repository SUSE-PackageHub-15-Pool. + Enabled repository SUSE-PackageHub-15-Standard-Pool.. + +&prompt.sudo;rmt-cli products disable 1743 +Found product by target 1743: SUSE Package Hub 15 x86_64. +Disabling SUSE Package Hub 15 x86_64: + SUSE Package Hub 15 x86_64: + Disabled repository SLE-Module-Packagehub-Subpackages15-Pool. + Disabled repository SLE-Module-Packagehub-Subpackages15-Updates. + Disabled repository SUSE-PackageHub-15-Pool. + Disabled repository SUSE-PackageHub-15-Standard-Pool. + + To clean up downloaded files, run 'rmt-cli repos clean' + + Enabling and disabling multiple products at once + + To enable or disable multiple products at once, specify a + space-delimited list of their IDs or product strings, for example: + +&prompt.sudo;rmt-cli products enable 1743 SLES/15/x86_64 SLES/12 +Found product by target 1743: SUSE Package Hub 15 x86_64. +Enabling SUSE Package Hub 15 x86_64: + SUSE Package Hub 15 x86_64: + Enabled repository SLE-Module-Packagehub-Subpackages15-Pool. + Enabled repository SLE-Module-Packagehub-Subpackages15-Updates. + Enabled repository SUSE-PackageHub-15-Pool. + Enabled repository SUSE-PackageHub-15-Standard-Pool. +Found product by target SLES/15/x86_64: SUSE Linux Enterprise Server 15 x86_64. +Enabling SUSE Linux Enterprise Server 15 x86_64: + SUSE Linux Enterprise Server 15 x86_64: + Enabled repository SLE-Product-SLES15-Pool. + Enabled repository SLE-Product-SLES15-Updates. + Enabled repository SLE15-Installer-Updates. + Basesystem Module 15 x86_64: + Enabled repository SLE-Module-Basesystem15-Pool. + Enabled repository SLE-Module-Basesystem15-Updates. + Server Applications Module 15 x86_64: + Enabled repository SLE-Module-Server-Applications15-Pool. + Enabled repository SLE-Module-Server-Applications15-Updates. +Found product by target SLES/12: SUSE Linux Enterprise Server 12 x86_64. +Enabling SUSE Linux Enterprise Server 12 x86_64: + SUSE Linux Enterprise Server 12 x86_64: + Enabled repository SLES12-Pool. + Enabled repository SLES12-Updates. + +
+ +
+ Using repositories + + To enable or disable mirroring of specific repositories, use the + rmt-cli repos enable ID + and rmt-cli repos disable + ID commands. To retrieve an ID for + an enabled repository, use the rmt-cli repos + list command. If you need to get the ID of a disabled + but accessible repository, execute the command + rmt-cli repos list --all. + + + Example: + +&prompt.sudo;rmt-cli repos list --all ++--------+-------------------------+-------------------------------------------+ +| ID | Name | Description | ++--------+-------------------------+-------------------------------------------+ +[...] +| 3061 | SUSE-PackageHub-15-Pool | SUSE-PackageHub-15-Pool for sle-15-x86_64 | +[...] ++--------+-------------------------+-------------------------------------------+ + +&prompt.sudo;rmt-cli repos enable 3061 +Repository by ID 3061 successfully enabled. + +&prompt.sudo;rmt-cli repos disable 3061 +Repository by ID 3061 successfully disabled. + +To clean up downloaded files, please run 'rmt-cli repos clean' + + Enabling and disabling multiple repositories at once + + To enable or disable multiple repositories at once, specify a + space-delimited list of their IDs, for example: + +&prompt.sudo;rmt-cli repos enable 2526 3263 +Repository by ID 2526 successfully enabled. +Repository by ID 3263 successfully enabled. + +&prompt.sudo;rmt-cli repos disable 2526 3263 +Repository by ID 2526 successfully disabled. +Repository by ID 3263 successfully disabled. + +To clean up downloaded files, run 'rmt-cli repos clean' + +
+ diff --git a/tasks/rmt-mirroring-exporting-importing.xml b/tasks/rmt-mirroring-exporting-importing.xml new file mode 100644 index 000000000..4d8d29d81 --- /dev/null +++ b/tasks/rmt-mirroring-exporting-importing.xml @@ -0,0 +1,149 @@ + + + %entities; +]> + + + + + + Exporting and importing repositories + + + + Transfer repository data and mirrored packages between two &rmt; + servers, for example, to feed a disconnected server in an air-gapped + network. + + + + + &rmt; has built-in functions to import and export data about available + repositories and the mirrored packages. For example, this can be used to + speed up the setup of a new &rmt; server by locally copying already + mirrored RPM packages. + + + + Another use case is the offline mode. It allows the + transfer of data to a disconnected &rmt; server, for example, to provide + updates to computers in an air-gapped network. + + + + The following procedure describes the transfer of data and mirrored RPMs + between two &rmt; servers with a USB drive. The server + sun is connected to &scc;, while + sirius is a server in an air-gapped network. + + + + + + Log in on the server sun. + +&prompt.root;rmt-cli sync +&prompt.root;rmt-cli mirror + + + + Connect a USB drive, assumed to be /dev/sdb and + mount it, for example, in /mnt/external. + +&prompt.root;mount /dev/sdb1 /mnt/external + + + + + + Export the data about available repositories and products. + +&prompt.root;rmt-cli export data /mnt/external/ + + + + Export the list of enabled repositories. The exported file is + required for exporting the repositories in the next step. + +&prompt.root;rmt-cli export settings /mnt/external/ + + + + Export mirrored RPM packages. Depending on the size of mirrored + repositories, this can take a long time. + +&prompt.root;rmt-cli export repos /mnt/external/ + + + + + + Unmount and unplug the disk from sun and go to + sirius. + +&prompt.root;umount /mnt/external + + + + If not yet done, set up &rmt; on sirius by configuring + the &ansible; variables. In case of an offline &rmt; setup, leave the + organization credentials empty in + /usr/share/ansible/rmt/group_vars/all.yml and run + the playbook. + + + + + Connect the USB drive to sirius and mount it in + /mnt/external. + +&prompt.root;mount /dev/sdb1 /mnt/external + + + + + + Import the metadata about available repositories and products. + +&prompt.root;rmt-cli import data /mnt/external/ + + + + Import mirrored RPM packages. Depending on the size of mirrored + repositories, this can take a long time. + +&prompt.root;rmt-cli import repos /mnt/external/ + + + + + + Enable repositories as required on the sirius. For + details, see + . + + + + + + Exporting enabled settings from air-gapped server + + If your air-gapped server (sirius) has many enabled + repositories, or if the enabled repositories change frequently, we + recommend exporting the repository settings from this server. + + + The server connected to &scc; (sun) can then + import the exported settings. This ensures that sun + downloads all data required by sirius. + + + diff --git a/tasks/rmt-mirroring-obtaining-credentials.xml b/tasks/rmt-mirroring-obtaining-credentials.xml new file mode 100644 index 000000000..f48ee7bd1 --- /dev/null +++ b/tasks/rmt-mirroring-obtaining-credentials.xml @@ -0,0 +1,82 @@ + + + %entities; +]> + + + + + + Mirroring credentials + + + + Obtain the organization credentials from &scc; that &rmt; needs to + create a local mirror of the &sle; repositories. + + + + + To create a local mirror of the &sle; repositories, obtain your organization credentials from &scc;. + + + + To get the credentials from &scc;, follow these steps: + + + + + + Visit &scc; at and log in. + + + + + If you are a member of multiple organizations, select the + organization you want to work with from the sidebar on the left. + + + + + Select Proxies in the top menu. + + + + + The credentials are displayed in the top right corner. + + + + + To see the password, click the + Eye icon + + + + + + + + icon. + + + + + + The obtained credentials should be configured in + /usr/share/ansible/rmt/group_vars/all.yml before running + the &ansible; playbook, or added directly to the + /etc/rmt.conf file after installation. + For more information about the + /etc/rmt.conf file, see + /etc/rmt.conf. + + diff --git a/tasks/rmt-mirroring-packages.xml b/tasks/rmt-mirroring-packages.xml new file mode 100644 index 000000000..45123c5d6 --- /dev/null +++ b/tasks/rmt-mirroring-packages.xml @@ -0,0 +1,56 @@ + + + %entities; +]> + + + + + + Mirroring packages + + + + Download the packages of enabled repositories to your &rmt; server, + either on a schedule or manually. + + + + + Packages for enabled repositories are mirrored on your &rmt; server. + Packages are downloaded periodically once a day. But the download can + also be triggered manually at any time. + + + + The periodic mirroring is activated by the &systemd; timer + rmt-server-mirror.timer. To show its status, for + example, the next running time: + + +&prompt.root;systemctl status rmt-server-mirror.timer +● rmt-server-mirror.timer - RMT Mirror timer + Loaded: loaded (/usr/lib/systemd/system/rmt-server-mirror.timer; enabled; vendor preset: disabled) + Active: active (waiting) since Fri 2018-06-22 04:22:34 EDT; 2h 34min ago + Trigger: Sat 2018-06-23 02:17:57 EDT; 19h left + +Jun 22 04:22:34 d31 systemd[1]: Started RMT Mirror timer. + + + If the timer is not enabled or started, start it manually. + + +&prompt.sudo;systemctl enable --now rmt-server-mirror.timer + + To update the mirrored packages manually, use the rmt-cli + mirror command. + + diff --git a/tasks/rmt-mirroring-synchronizing-metadata.xml b/tasks/rmt-mirroring-synchronizing-metadata.xml new file mode 100644 index 000000000..afcb780cd --- /dev/null +++ b/tasks/rmt-mirroring-synchronizing-metadata.xml @@ -0,0 +1,56 @@ + + + %entities; +]> + + + + + + Synchronizing repository metadata + + + + Keep the local &rmt; database up to date with product and repository + information from &scc;. + + + + + The local &rmt; database needs to be updated periodically with the + information downloaded from &scc;. This includes information about + available products and repositories. + + + + The synchronization is activated by the &systemd; timer + rmt-server-sync.timer. To view its status, for + example, the next running time: + + +&prompt.sudo;systemctl status rmt-server-sync.timer +● rmt-server-sync.timer - RMT Sync timer + Loaded: loaded (/usr/lib/systemd/system/rmt-server-sync.timer; enabled; vendor preset: disabled) + Active: active (waiting) since Fri 2018-06-22 04:22:34 EDT; 2h 34min ago + Trigger: Sat 2018-06-23 03:53:00 EDT; 20h left + +Jun 22 04:22:34 d31 systemd[1]: Started RMT Sync timer. + + If the timer is not enabled or started, start it manually. + + +&prompt.sudo;systemctl enable --now rmt-server-sync.timer + + + To update the &rmt; database manually, use the rmt-cli + sync command. + + diff --git a/tasks/rmt-regenerating-certificates.xml b/tasks/rmt-regenerating-certificates.xml new file mode 100644 index 000000000..3cceda743 --- /dev/null +++ b/tasks/rmt-regenerating-certificates.xml @@ -0,0 +1,118 @@ + + + %entities; +]> + + + + + + Managing TLS/SSL certificates + + + + Regenerate the TLS/SSL certificates of your &rmt; server using the + &ansible; playbook when they expire. + + + +
+ Regenerating HTTPS certificates + + + HTTPS certificates should be regenerated before they expire. No + additional actions are required on the client machines registered to the + &rmt; server if only HTTPS certificates are regenerated. + + + + Certificates generated by the playbook are self-signed + + The playbook generates a self-signed server certificate that carries + neither a common name nor subject alternative names, and that is not + signed by the CA certificate in + /etc/rmt/ssl/rmt-ca.crt. Clients that verify host + names reject such a certificate. If your clients verify the server + certificate, issue one yourself with a common name, the required + subject alternative names and a signature from your CA, then store it + as /etc/rmt/ssl/rmt-server.crt together with its + key in /etc/rmt/ssl/rmt-server.key. Note that any + subsequent run of the playbook overwrites both files. + + + + + + + Stop nginx and rmt-server services. + +&prompt.root;systemctl stop nginx +&prompt.root;systemctl stop rmt-server + + + + Remove previously generated certificates. + +&prompt.root;rm /etc/rmt/ssl/rmt-server.* + + + + Regenerate certificates using the &ansible; playbook: + +&prompt.root;cd /usr/share/ansible/rmt +&prompt.root;ansible-playbook site.yml + + +
+
+ Regenerating CA certificates and HTTPS certificates + + + CA certificates can be regenerated after they have expired or in case of + security issues. + + + + Import CA certificate on all clients + + The newly generated CA certificate must be imported on all clients + registered to the &rmt; server. This can be done by running the + rmt-client-setup script on the client machines as + described in + Configuring clients with rmt-client-setup. + + + + + + + Stop nginx and rmt-server services. + +&prompt.root;systemctl stop nginx +&prompt.root;systemctl stop rmt-server + + + + Remove previously generated CA and HTTPS certificates. + +&prompt.root;rm /etc/rmt/ssl/rmt-ca.* +&prompt.root;rm /etc/rmt/ssl/rmt-server.* + + + + Regenerate certificates using the &ansible; playbook: + +&prompt.root;cd /usr/share/ansible/rmt +&prompt.root;ansible-playbook site.yml + + +
+