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-migrating-from-smt b/DC-SAP-rmt-migrating-from-smt new file mode 100644 index 000000000..2c719960e --- /dev/null +++ b/DC-SAP-rmt-migrating-from-smt @@ -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-migrating-from-smt.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-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-migrating-from-smt b/DC-SLES-rmt-migrating-from-smt new file mode 100644 index 000000000..dc874ba62 --- /dev/null +++ b/DC-SLES-rmt-migrating-from-smt @@ -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-migrating-from-smt.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..112561f7f --- /dev/null +++ b/articles/rmt-installing-configuring.asm.xml @@ -0,0 +1,178 @@ + + + + + %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. Migrated from the SLE Repository Mirroring Tool + Guide and updated for the &ansible;-based configuration workflow. + + + + + + + &x86-64; + &power; + + + &productname; + + Install and configure an RMT server + How to install the Repository Mirroring Tool and configure it with the Ansible playbook workflow + Install and configure RMT + + Systems Management + + + Installation + Configuration + + Products & Solutions + + + https://bugzilla.suse.com/enter_bug.cgi + Documentation + SUSE Linux Enterprise Server &productnumber; + amrita.sakthivel@suse.com + + yes + + + + + WHAT? + + + &rmt; (Repository Mirroring Tool) is a proxy for &scc; that + mirrors software repositories and registers client systems in + your own network. + + + + + WHY? + + + A local &rmt; server saves bandwidth and time by downloading + updates once and serving them to all client systems, and keeps + registration inside your network. + + + + + EFFORT + + + It takes about 30 minutes to install &rmt; and run the + &ansible; configuration playbook on a freshly installed system. + + + + + GOAL + + + A running &rmt; server, configured with &ansible; and ready to + mirror repositories and register clients. + + + + + REQUIREMENTS + + + A newly installed &productname; system or &minvm; image. + &scc; organization credentials for mirroring. + Sufficient storage for the repositories you plan to mirror. + + + + + + + + + + + + + + + + + + + + + diff --git a/articles/rmt-migrating-from-smt.asm.xml b/articles/rmt-migrating-from-smt.asm.xml new file mode 100644 index 000000000..2dad840d6 --- /dev/null +++ b/articles/rmt-migrating-from-smt.asm.xml @@ -0,0 +1,152 @@ + + + + + %entities; +]> + + + + + + + + Introduction and important notes + + + For more information + + + + + + SMT and RMT feature comparison + + + + + + Exporting SMT data + + + Importing SMT data to RMT + + + + + + Legal Notice + + + GNU Free Documentation License + + + + + + Migrating from SMT to RMT + + 2026-07-20 + + + Initial version. Migrated from the SLE Repository Mirroring Tool + Guide and updated for the &ansible;-based configuration workflow. + + + + + + + &x86-64; + &power; + + + &productname; + + Migrate from SMT to RMT + How to migrate from the Subscription Management Tool to the Repository Mirroring Tool + Migrate from SMT to RMT + + Systems Management + + + Migration + + Products & Solutions + + + https://bugzilla.suse.com/enter_bug.cgi + Documentation + SUSE Linux Enterprise Server &productnumber; + amrita.sakthivel@suse.com + + yes + + + + + WHAT? + + + Migration moves your repository mirroring and client + registration from the legacy ⪪ on &slsa; 11 or 12 to &rmt; + on &slsa; 15. + + + + + WHY? + + + ⪪ is not available on &slsa; 15. &rmt; is its supported + successor, with a modern workflow, offline mirroring, and + &kube; deployment options. + + + + + EFFORT + + + Exporting and importing the data takes about 30 minutes, plus + mirroring time depending on repository size. + + + + + GOAL + + + An &rmt; server on &slsa; 15 that continues to serve the + repositories and registered clients previously managed by ⪪. + + + + + REQUIREMENTS + + + An existing ⪪ server on &slsa; 11 or 12. + A newly installed &slsa; 15 host for &rmt;. + + + + + + + + + + + + + + + diff --git a/articles/rmt-mirroring-repositories.asm.xml b/articles/rmt-mirroring-repositories.asm.xml new file mode 100644 index 000000000..05f64ef88 --- /dev/null +++ b/articles/rmt-mirroring-repositories.asm.xml @@ -0,0 +1,166 @@ + + + + + %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. Migrated from the SLE Repository Mirroring Tool + Guide and updated for the &ansible;-based configuration workflow. + + + + + + + &x86-64; + &power; + + + &productname; + + Mirror repositories on an RMT server + 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 + + + + + WHAT? + + + Mirroring lets an &rmt; server download &sle; and custom + repositories from &scc; and serve them to client systems in + your own network. + + + + + WHY? + + + Mirroring locally saves bandwidth, speeds up updates, and + enables offline and air-gapped scenarios where clients cannot + reach &scc; directly. + + + + + EFFORT + + + It takes about 20 minutes to enable repositories and start the + first mirroring run, plus download time depending on repository + size. + + + + + GOAL + + + A working mirror of the repositories your clients need, kept up + to date automatically or on demand. + + + + + REQUIREMENTS + + + A running and configured &rmt; server. + &scc; organization credentials. + + + + + + + + + + + + + + + + + + + diff --git a/glues/rmt-installing-intro.xml b/glues/rmt-installing-intro.xml new file mode 100644 index 000000000..90e6bb443 --- /dev/null +++ b/glues/rmt-installing-intro.xml @@ -0,0 +1,42 @@ + + + %entities; +]> + + + + + + Introduction + + + + &rmt; is included in &sls; starting with version 15. 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. + + + &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..8d322fb34 --- /dev/null +++ b/glues/rmt-installing-more-info.xml @@ -0,0 +1,37 @@ + + + %entities; +]> + + + For more information + + + + To learn more about &rmt;, refer to the following resources: + + + + + + + Repository Mirroring Tool Guide + — the complete administrator's guide to &rmt;, including client + configuration and the rmt-cli command reference. + + + + + &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..15a77e8e7 --- /dev/null +++ b/glues/rmt-mirroring-intro.xml @@ -0,0 +1,64 @@ + + + %entities; +]> + + + + + + Introduction + + + + You can mirror the installation and update repositories on the &rmt; + server. This way, you do not need to download updates on each machine, + which saves time and capacity. + + + In its default configuration, &rmt; mirrors enabled product repositories + automatically once every night. + + + By default, the mirrored repositories are stored 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. This can be done using 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/glues/rmt-smt-migration-intro.xml b/glues/rmt-smt-migration-intro.xml new file mode 100644 index 000000000..5669cc49b --- /dev/null +++ b/glues/rmt-smt-migration-intro.xml @@ -0,0 +1,84 @@ + + + %entities; +]> + + + + + + Introduction and important notes + + + + This article describes the migration from ⪪ on &slsa; 11 or 12 to &rmt; + on &slsa; 15. + + + + Read this section carefully + + Carefully read this section. It contains vital information about the + migration process. + + + + + + Use a new host + + + We recommend that you install &rmt; on a newly installed &slsa; 15 + host. &rmt; is not a complete replacement for ⪪. It has a + different workflow than ⪪ and only supports registering &sls; + 12 systems and newer. + + + + + Repository metadata and settings + + + The settings of staged repositories are not + exported from ⪪. Repositories that have been marked to be + mirrored are exported. + + + + + Custom repositories + + + It is only possible to export repositories that are marked for + mirroring. + + + + + Expired subscriptions + + + Products no longer available on the organization subscriptions will + not be available on &rmt;. + + + + + Client information + + + Systems and their activated products are exported. ⪪ client + jobs and patch status are not exported from ⪪. + + + + + diff --git a/glues/rmt-smt-migration-more-info.xml b/glues/rmt-smt-migration-more-info.xml new file mode 100644 index 000000000..41dae7adb --- /dev/null +++ b/glues/rmt-smt-migration-more-info.xml @@ -0,0 +1,37 @@ + + + %entities; +]> + + + For more information + + + + To learn more about &rmt; and the migration from ⪪, refer to the + following resources: + + + + + + + Repository Mirroring Tool Guide + — the complete administrator's guide to &rmt;. + + + + + &rmt; source code and issue tracker on GitHub. + + + + 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..f3ba24093 --- /dev/null +++ b/references/rmt-configuration-files.xml @@ -0,0 +1,269 @@ + + + %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. + + +
+ /etc/rmt.conf + + The initial configuration is performed using &ansible; as described in + . 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 the &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-smt-feature-comparison.xml b/references/rmt-smt-feature-comparison.xml new file mode 100644 index 000000000..5e2bc73e2 --- /dev/null +++ b/references/rmt-smt-feature-comparison.xml @@ -0,0 +1,299 @@ + + + %entities; +]> + + + + + + Feature comparison + + + + A side-by-side comparison of the features supported by ⪪ and &rmt; + to help you plan the migration. + + + + + Feature comparison + + + + + + + + + Feature + + + + + ⪪ + + + + + &rmt; + + + + + + + Available on &slsa; 11 + yes + no + + + Available on &slsa; 12 + yes + no + + + Available on &slsa; 15 + no + yes + + + Synchronize products with &scc; + yes + yes + + + Mirror RPMs from repositories + yes + yes + + + Selective mirroring (specifying products to mirror) + yes + yes + + + Serve RPMs via HTTP + yes + yes + + + Registration of &slea; 15 systems + yes + yes + + + Registration of &slea; 12 systems + yes + yes + + + Registration of &slea; 11 systems + yes + no + + + &redhat; 6 and earlier support + yes 1 + no + + + &redhat; 7+ support + yes 1 + yes 1 + + + Support for migrating &slea; 12 to 15 + yes 2 + yes + + + Support for migrating &slea; 15 SPx to 15 SPx+1 + yes 2 + yes + + + Staging repositories + yes + no 3 + + + Offline mirroring + yes + yes + + + NTLM Proxy support + yes + yes + + + Custom repositories + yes + yes + + + &yast; installation wizard + yes + yes + + + &yast; management wizard + yes + no + + + Client management + yes + no + + + Files deduplication + yes + yes + + + Data transfer from ⪪ to &rmt; + n/a + yes + + + Transfer registration data to &scc; + yes + yes + + + Reporting + yes + no + + + Custom TLS certificates for Web server + yes + yes + + + Clean up data from repositories that are not used any longer + yes + yes + + + Bash completion + no + yes + + + + + Available on + openSUSE + Leap 15 + + + no + yes 4 + + + + + Easy development setup + + contribution + guide + + + no + yes + + + + + 100% test + coverage + + + no + yes + + + + + Plugin + functionality + + + no + yes + + + Web server + Apache2 + Nginx + + + Platform + Perl + Ruby + + + Clean up data from repositories that are no longer used + yes + yes + + + Bash completion + no + yes + + + Option to deploy on &kube; + no + yes 5 + + + +
+ + + + + Support via &sliberty;—find more details in . + + + + + ⪪ only partially supports migrating systems to &slea; 15. &slea; + 15 is composed of multiple modules and extensions. Some modules are + not required, as they provide additional functionality. &rmt; fully + supports migrations into and within &slea; 15, therefore it only adds + the minimum of required modules. ⪪ does not fully support these + migrations, and it enables all available modules on the system. + + + + + Functionality is offered by + &smlm;. + + + + + Only available with + self-support. + + + + + Find more details in + Deploying &rmt; on top of the &kube; cluster. + + + + diff --git a/references/rmt-storage-requirements.xml b/references/rmt-storage-requirements.xml new file mode 100644 index 000000000..b65d2f969 --- /dev/null +++ b/references/rmt-storage-requirements.xml @@ -0,0 +1,49 @@ + + + %entities; +]> + + + + + + Storage requirements + + + + The storage an &rmt; server requires depends on the number of + repositories, architectures, and products you mirror. + + + + + 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 files 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..65fefaeb1 --- /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 for 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..0655efe9f --- /dev/null +++ b/tasks/rmt-configuring-with-ansible.xml @@ -0,0 +1,187 @@ + + + %entities; +]> + + + + + + &rmt; configuration 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 username 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; backend 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: + + + + + /etc/rmt/ssl/rmt-ca.crt - CA certificate + + + + + /etc/rmt/ssl/rmt-ca.key - CA private key + + + + + /etc/rmt/ssl/rmt-server.crt - Server certificate + + + + + /etc/rmt/ssl/rmt-server.key - Server private key + + + + + diff --git a/tasks/rmt-deploying-on-kubernetes.xml b/tasks/rmt-deploying-on-kubernetes.xml new file mode 100644 index 000000000..1f6152736 --- /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 top of a &kube; cluster using Helm + as the package manager. + + + + + This section describes how to deploy &rmt; on top of the &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 paths 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..bfc1d86c9 --- /dev/null +++ b/tasks/rmt-enabling-slp-announcements.xml @@ -0,0 +1,59 @@ + + + %entities; +]> + + + + + + Enabling SLP announcements + + + + Enable SLP 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..162823a20 --- /dev/null +++ b/tasks/rmt-installing-during-installation.xml @@ -0,0 +1,51 @@ + + + %entities; +]> + + + + + + Installation 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 + + + + + + + + +
+ + + 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..54666fb16 --- /dev/null +++ b/tasks/rmt-installing-existing-system.xml @@ -0,0 +1,86 @@ + + + %entities; +]> + + + + + + Installation on an existing system + + + + Install &rmt; on a running &productname; system with + zypper. + + + + + To install &rmt; on a running &productname; installation, use + zypper: + + +&prompt.sudo;zypper in rmt-server + +
+ Installation 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..b0b77bc63 --- /dev/null +++ b/tasks/rmt-mirroring-obtaining-credentials.xml @@ -0,0 +1,83 @@ + + + %entities; +]> + + + + + + Mirroring credentials + + + + Obtain the organization credentials from &scc; that &rmt; needs to + create a local mirror of the &sle; repositories. + + + + + You need organization credentials to create a local mirror of + the &sle; repositories. You can obtain the 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..481905472 --- /dev/null +++ b/tasks/rmt-mirroring-packages.xml @@ -0,0 +1,57 @@ + + + %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, use systemctl status. + + +&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. For details, see + the rmt-cli command reference. + + diff --git a/tasks/rmt-mirroring-synchronizing-metadata.xml b/tasks/rmt-mirroring-synchronizing-metadata.xml new file mode 100644 index 000000000..59efa1dea --- /dev/null +++ b/tasks/rmt-mirroring-synchronizing-metadata.xml @@ -0,0 +1,57 @@ + + + %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, use systemctl status. + + +&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. For details, see + the rmt-cli command reference. + + diff --git a/tasks/rmt-regenerating-certificates.xml b/tasks/rmt-regenerating-certificates.xml new file mode 100644 index 000000000..2a593dc94 --- /dev/null +++ b/tasks/rmt-regenerating-certificates.xml @@ -0,0 +1,103 @@ + + + %entities; +]> + + + + + + Managing TLS/SSL certificates + + + + Regenerate the TLS/SSL certificates of your &rmt; server using the + &ansible; playbook when they expire or need additional common names. + + + +
+ Regenerating HTTPS certificates + + + HTTPS certificates should be regenerated before they expire or to include + additional common alternative names. No additional actions are required + on the client machines registered to the &rmt; server if only HTTPS + certificates are regenerated. + + + + + + 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 --tags certificates + + +
+
+ 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 --tags certificates + + +
+ diff --git a/tasks/rmt-smt-exporting-data.xml b/tasks/rmt-smt-exporting-data.xml new file mode 100644 index 000000000..7b453cfdb --- /dev/null +++ b/tasks/rmt-smt-exporting-data.xml @@ -0,0 +1,54 @@ + + + %entities; +]> + + + + + + Exporting ⪪ data + + + + Export the configuration, SSL certificates, and client data from your + existing ⪪ server for import into &rmt;. + + + + + Export ⪪ data + + + Update your ⪪ server installation by running zypper + up. + + + + + To export your SSL certificates along with the rest of + the data, run smt-data-export. Remember to keep + your certificates in a safe place. + + + If you do not want to export the SSL certificates from ⪪, run + smt-data-export --no-ssl-export. + + + + + The exported configuration is now saved to + smt-data-export.TIMESTAMP.tar.gz. + Copy the file to a location that the new &rmt; server can access. + + + + diff --git a/tasks/rmt-smt-importing-data.xml b/tasks/rmt-smt-importing-data.xml new file mode 100644 index 000000000..b7a2c2609 --- /dev/null +++ b/tasks/rmt-smt-importing-data.xml @@ -0,0 +1,137 @@ + + + %entities; +]> + + + + + + Importing ⪪ data to &rmt; + + + + Import the data exported from ⪪ into a newly configured &rmt; + server and mirror the repositories. + + + + + + + To make sure your &rmt; installation is up to date, run + zypper up. + + + + + Copy the exported .tar.gz file to an empty + directory and unpack it. Then enter the new directory: + +&prompt.user;mkdir EMPTY_DIR +&prompt.user;cd EMPTY_DIR +&prompt.user;tar xf /PATH/TO/smt-data-export.TIMESTAMP.tar.gz +&prompt.user;cd smt-data-export + + + + + If you chose to export the SSL certificates from ⪪, copy the CA + private key and certificate to /etc/rmt/ssl/: + +&prompt.sudo;cp ssl/cacert.key /etc/rmt/ssl/rmt-ca.key +&prompt.sudo;cp ssl/cacert.pem /etc/rmt/ssl/rmt-ca.crt + + + + Configure &rmt; using &ansible; as described in + &rmt; configuration with &ansible;. If + you imported the ⪪ CA certificate, ensure the domain of the ⪪ + server is included in the SSL certificate configuration. + + + + + Run the &rmt; synchronization to get the products and repositories + data from &scc;. + +&prompt.sudo;rmt-cli sync + + + + Import the data from the ⪪ server. + +&prompt.sudo;rmt-data-import -d ./ + + + + Optional: if the URL of the &rmt; server changed, change the URL + parameter of clients in /etc/SUSEConnect to point + to the new &rmt; server. Alternatively, change the DNS records to + re-assign the host name to the &rmt; server. + + + + + Optional: move the mirrored repository data from ⪪ to &rmt;, and + adjust the ownership of the copied data. + +&prompt.sudo;cp -r /var/www/htdocs/repo/* /usr/share/rmt/public/repo/ +&prompt.sudo;chown -R _rmt:nginx /usr/share/rmt/public/repo + + + The path for storing custom repository data on the &rmt; server is + different from that of ⪪. With &rmt;, it replicates the + directory structure of the source server's URL into a top-level + directory structure. For example, for a source repository at + +http://download.opensuse.org/debug/distribution/leap/15.6/repo/oss + + its path on the &rmt; server corresponds to + +/usr/share/rmt/public/repo/debug/distribution/leap/15.6/repo/oss + + + + + Custom repositories on the ⪪ server are disabled by default. If + you want to mirror them to the &rmt;, enable them before mirroring. + + + + + Check for custom repositories by running: + +&prompt.sudo;rmt-cli repos custom list + + The command shows the table of all custom repositories. The first + column contains the ID of each repository and + the Mirror? column shows + false. + + + + + Enable each custom repository you want to mirror by running: + +&prompt.sudo;rmt-cli repos custom enable ID + + + + + + Update the packages in the repositories by starting the mirroring + process: + +&prompt.sudo;rmt-cli mirror + + +