Changing namespace on already registered SMT clients fails
This document (7005877) is provided subject to the disclaimer at the end of this document.
Environment
Subscription Management Tool 1.1
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Desktop 11
SUSE Linux Enterprise Server 10 SP3
SUSE Linux Enterprise Desktop 10 SP3
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Desktop 11
SUSE Linux Enterprise Server 10 SP3
SUSE Linux Enterprise Desktop 10 SP3
Situation
When deploying the staging functionality of Subscription Management Tool (SMT) server, clients can be configured to register against either testing, production or full repositories (or namespaces as it is also called in this context).
If a client has already been registered against e.g. the testing namespace and the register command in /etc/suseRegister.conf is modified to point to e.g. production (&namespace=none - or omitted), then it will not pick up the change after having registered against the SMT server.
Although the <zmdconfig> tag at the end of /root/.suseregister.log file shows that SMT server does send back the correct URL of the service(s), the client does not modify the zypper repository/repositories.
The problem does not exist for SUSE Linux Enterprise (SLE) 11 Service Pack 1 and later clients.
If a client has already been registered against e.g. the testing namespace and the register command in /etc/suseRegister.conf is modified to point to e.g. production (&namespace=none - or omitted), then it will not pick up the change after having registered against the SMT server.
Although the <zmdconfig> tag at the end of /root/.suseregister.log file shows that SMT server does send back the correct URL of the service(s), the client does not modify the zypper repository/repositories.
The problem does not exist for SUSE Linux Enterprise (SLE) 11 Service Pack 1 and later clients.
Resolution
The options vary for SLE 11 and SLE 10.
SLE 11
The root cause is that refresh of a service does not modify a changed URL in an already existing repository, which is a bug in the libzypp package on SLE 11.
This has been fixed in libzypp-5.30.3, which was released as a maintenance update for SLE 11 in June 2009.
Option 1 :
Update the libzypp package to at least the version above.
Option 2 :
Add the following line to the [NU]section of/etc/smt.conf on the SMT server :
changeAlias=true
This will force a change of the alias for the repo(s) in question during registration by appending the namespace name to the repository alias sent to the clients. The namespace will only be appended if it is different from none (production) - i.e testing or full.
The refresh (# zypper ref -s) after the registration process on the client will then replace the old repository with the new one.
SLE 10
This platform uses ZENworks Management Daemon (ZMD) which does not have the same functionality as the zypper package manager on SLE 11.
For this platform, the only solution is to implement the
changeAlias=true
as described above.
SLE 11
The root cause is that refresh of a service does not modify a changed URL in an already existing repository, which is a bug in the libzypp package on SLE 11.
This has been fixed in libzypp-5.30.3, which was released as a maintenance update for SLE 11 in June 2009.
Option 1 :
Update the libzypp package to at least the version above.
Option 2 :
Add the following line to the [NU]section of/etc/smt.conf on the SMT server :
changeAlias=true
This will force a change of the alias for the repo(s) in question during registration by appending the namespace name to the repository alias sent to the clients. The namespace will only be appended if it is different from none (production) - i.e testing or full.
The refresh (# zypper ref -s) after the registration process on the client will then replace the old repository with the new one.
SLE 10
This platform uses ZENworks Management Daemon (ZMD) which does not have the same functionality as the zypper package manager on SLE 11.
For this platform, the only solution is to implement the
changeAlias=true
as described above.
Additional Information
The SMT deployment guide contains an overview of the staging capabilities of SMT and how to set it up.
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7005877
- Creation Date: 30-Apr-2010
- Modified Date:28-Sep-2022
-
- Subscription Management Tool
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
