May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Suse 10 Enterprise Registration Problems


SLES Registration

Recommended Links  

Moving systems to new  activation code at the end of support contract

SLES Documentation

SLES Registration suse_register Red Carpet System information Startup and shutdown



Novell for some reason provides new registration code each year so batch reregistration is a must in Suse environment. The best way to deal with it is to use installation server, but for small site there is also a possibility to use suse_register

In general, Suse 10 registration is a convoluted process that often breaks. I personally was rarely successful in registering servers the first time I tried and most often ended calling Novell support (which is free for registration). It is really a torture if you have a proxy with password authentication. I strongly recommend to create a shadow proxy server without authentication for this case and allow access to it from only Suse 10 servers.  Please note that this situation did not improve from SP1 to SP3.

In this particular situation (proxy with the authentication) as for the ease of registration Red Carpet (now ZENworks) should probably be called the "Slam the Door Shut " and this name should tattooed somewhere on Miguel de Icaza body (along with Microsoft's logo for bringing .NET affluence to hungry Unix masses ;-).

Novell had to thoroughly test this Zen/Rug infrastructure for complex cases like described above. The issues involving Zen/Rug/YaST is a really p.i.t.a., while the rest of SuSE 10 is good or, at least, bearable.

Sometimes registered server disappears from Novell customer server and you need to reregister it.

To reregister stop the zmd service, delete the deviceid & secret files from /etc/zmd, start the zmd service, then try running the NCC Configuration utility again. For example:

cd /etc/zmd
# deviceid secret trusted-certs zmd.conf
rm deviceid secret
service zmd restart
rczmd restart

You can use suse_register  to  register automatically if you have no proxy or proxy without authentication. There are three prerequisites for running this script if you are in a proxied environment:

1.  You proxy should accept Novell domain (or at least selected sites used like and without authentication.

2.  You need to populate proxy setting in YAST and to add  two lines with your proxy information to /etc/profile, for example:

export http_proxy=""
export https_proxy=""

 3. You need to create ~root/.curlrc with the same information


Top Visited
Past week
Past month


Old News ;-)

SLED10SP2 Online Update signing key error - NOVELL FORUMS

On Sat, 24 May 2008 16:46:01 GMT
EnviroTO <[email protected]> wrote:

> I did a clean install of SP2 but registering online update sources
> fails with:
> Refresh Failed: Failed to parse XML metadata: Key verification for
> '/repodata/repomd.xml
> (file:/var/cache/zmd/web/files/$RCE/SLED10-SP2-Pool/sled-10-i586/)'
> failed 'SuSE Package Signing Key <[email protected]>' (A84EDAE89C800ACA)
> I don't remember a "Pool" update source before but I cant seem to
> remove it completely from rug either because it shares the same server
> as "Updates". No key issues on other sources.

Did you accept all the keys when requested?

I have;
[email protected]:~$
ls /var/cache/zmd/web/files/\$RCE/
SLE10-SDK-SP2-Online SLE10-SDK-SP2-Updates
SLE10-SP2-Debuginfo-Updates SLED10-SP2-Online SLED10-SP2-Updates

What does rug ca and rug sl show from the CLI, if it shows up there can
you try rug sd <repo number from output of rug sl>

If you look in via YaST->Software->Installation Source maybe you need
to remove from here as well..

Cheers Malcolm °Ώ° (Linux Counter #276890)
SLED 10.0 SP2 x86_64 Kernel
up 1 day 22:51, 0 users, load average: 0.01, 0.03, 0.12

Novell Customer Center registration problem - NOVELL FORUMS

On Wed, 28 May 2008 19:26:02 +0000, swicklund wrote:

> If I select to the check box to enter registration codes then click next I get a server error.
> None of the installed products can be registered at the Novell registration server.
> My server stopped downloading updates, so I deleted its registration. Now I am trying to re-register it.

Stop the zmd service, delete the deviceid & secret files from /etc/zmd,
start the zmd service, then try running the NCC Configuration utility

Joe Marton
Novell Support Forum SysOp
Novell does not officially monitor these forums!

Problem with suse_register - NOVELL FORUMS

On Wed, 07 Mar 2007 02:26:42 +0000, haych.c wrote:

> I can see all three of the servers. One server works, two don't. I have
> tried removing the broken ones and re-registering them. They do re-appear
> in customer centre wit han active status but still dont work on the
> system.

Interesting. I would remove all three, not just the two broken ones. Then pick a broken one and following the following TIDs to clear secrets, database, and cache before rerunning suse_register: 3303599, 3181469, and 3818394.

Joe Marton
Novell Support Forum SysOp
Novell does not officially monitor these forums!


Software Management-Registration - openSUSE

Version 13, 19 December 2006.

This paper describes how the registration process is implemented on Linux systems. What happens on is documented elsewhere.

The registration process is invoked in one of the following ways:

1. During interactive installation, the user will be asked if they want to connect to the network and retrieve updates. This will cause interactive registration (see below). The user may skip this process, in which case the system will not be updated and the ZMD update facility will not be configured.

2. During scripted installation (i.e. with autoyast) registration may be completely scripted using the registration utility (see below). As with interactive installation, this may be skipped.

3. Manually calling the registration utility from YaST. When running in a graphical mode (i.e., webconsole or when YaST can realize an HTML widget), the registration process may be interactive.

4. Manually calling the registration utility from the command-line.

5. When the user attempts to use a ZMD-related command and ZMD is not configured, an error message will be generated prompting them to register in order to configure the update service. They will then need to manually register using one of the entry points described above. Optionally, if appropriate, the command may invoke a wrapper script that will call the registration utility.

Registration Utility: suse_register

suse_register [ options ] [-a parameter=value ...]

The suse_register utility collects system configuration and user information needed to connect the system to network-delivered services from Novell and configure the patch and update service. The information is supplied to a registration service at, and will return an XML-structured file with the information needed to configure ZMD for patch and update.


-i | --interactive – launch web browser and interactively collect registration information

--product <product> - product to register

-p | --list-parameters – contact the registration service for a list of parameters

--xml-output – print results in XML to stdout (for scripting)

-n | --no-optional – don't submit passively collected optional system information

-f | --force-registration – mark all parameters mandatory which are required for registration even though registration itself might be optional

--no-hw-data – never submit hardware data, even if they are mandatory

-L file | --log=file – log XML blocks sent to and received from the registration service to file

--locale=locale – force messages to a specific language and encoding

-b path | --browser=path – use web browser specified by path for interactive registration

--no-proxy – don't use proxies, even if the appropriate environment variables are set

--xml-output – print XML output

-h | -? | --help – print command-line syntax help




List Products

At the beginning of each call, suse_register will ask the server so send a list of known products. This happens by calling the URL .

The server return a list of products, for example:

<?xml version="1.0" encoding="UTF-8"?>
<productlist xmlns=""
  <privacy url=""
           description="Novell Privacy Statement"
  <product>Novell Linux Desktop</product>
  <product>SUSE Linux</product>
  <product>SUSE SLES</product>

List Parameters

When invoked with the --list-parameters option, the suse_register command will contact the registration service at, supplying the desired encoding and language identifiers for textual descriptions of the parameters. The content includes the product information.

<?xml version="1.0" encoding="UTF-8"?>
<listparams xmlns="">
    <product version="10.1" release="Beta9" arch="i686"><![CDATA[SUSE LINUX]]></product>

The encoding and language specifiers are supplied using HTML form post or get methods, and are passed using the encoding and lang identifiers, respectively. The default values for encoding and language are derived from the LANG locale variable, and may be set in the runtime environment using the LANG environment variable. An appropriate value may also be passed on the command line using the --locale option. This value is structured as lang.encoding. The value for lang may require normalization by suse_register in order to conform to IETF RFC 3066. For example, en_US would be transformed to en-US. The value for encoding must be UTF-8; in instances where other character encodings are required, suse_register must normalize or de-normalize message strings.

The registration service will then return an XML structured document with a list of parameters, their description, and a command that may be used to collect the desired information (if applicable). The registration service may modify the language and encoding to match supported message catalogs. For example, if suse_register passes lang="en-GB", the registration service may change the language value to en because a single English language message catalog is supported.

The tag privacy has an url and a description attribute. The url is the link to the current privacy policy of Novell. The description a short description about the policy.

<?xml version="1.0" encoding="utf-8"?>
<paramlist xmlns="" lang="en">
    <param id="ostype"
           description="Operating System Type"
           command="lsb_release -sd"/>
    <param id="osversion"
           description="Operating System Version"
           command="lsb_release -sr"/>
    <param id="processor"
           description="Processor Type"
           command="uname -p"/>
    <param id="platform"
           description="Hardware Platform Type"
           command="uname -i"/>
    <param id="timezone"
           description="Timezone Offset from GMT"
           command="date +'%z'"/>
    <param id="username"
           description="Novell Account User Name"/>
    <!-- etc. -->
    <privacy url=""
             description="Submit information to help you manage systems in the Customer Center."

If suse_register was invoked with the --xml-output option, then the returned file will be sent to stdout. Otherwise, a human-readable version of the parameter list will be printed to stdout.



In all other cases, the suse_register command will send an XML structured document to the registration service at .

The registration service may respond with a redirect, in which case the request is resubmitted to the indicated URL.

The URL should contain the protocol version of suse_register, e.g. version=1.0, as query option.

The XML document will contain a globally-unique identifier (GUID) for the device provided by ZMD and any collected parameters. The ZMD GUID is one of two randomly-generated "unique" numbers that the system and the ZLM server will exchange with each other. The other is a registration code that will be passed back later in the process.

For virtualization the GUID of the Domain-0 could be provide inside the <host>...</host> element. This could be understand as a "link" to the entitlement of Domain-0. More about this is defined in an separate document.

At a minimum, the suse_register command will passively collect the products, the processor and hardware platform type, and the timezone. The products are used for update catalog selection. The timezone information is used to select an update server. The XML document will also include the desired language and encoding specifiers, as outlined above.

The mirrors tag ask for maximal count of mirrors returned by the registration server. If this value is missing in the request, the value is "1" . Update sources with the same catalog name are defined to be mirrors with the same content.

The product has the following attributes: version, release (might be empty) and arch. The value is the product name.

<?xml version="1.0" encoding="UTF-8"?>
<register xmlns=""
          lang="en" accept="optional" force="registration">
    <product version="10" release="" arch="i686">
    <param id="processor">i686</parameter>
    <param id="platform">i386</parameter>
    <param id="timezone">US/Mountain</parameter>
    <mirrors count="5" />

It is possible to register more that one product. suse_register will submit the set intersection of server known products (i.e., products returned from a listproducts command), installed products, and any products provided via the --product command line parameter.

If the supplied information is sufficient to complete registration of the system, then the registration service will send back and XML structured document with configuration information for ZMD.

<?xml version="1.0" encoding="UTF-8"?>
<zmdconfig xmlns="" lang="en">
    <param id="update_inventory">true</param>
    <service id="novell-emea"
             description="Novell Network European Update Service"
        <param id="url">
        <param id="regcode">fade4badbeeffeed</param>
        <param name="catalog">sle-10-common-i586</param>
        <param name="catalog">sle-10-server-i586</param>
        <param name="catalog">sle-10-sdk-i586</param>
        <param name="catalog">sle-10-unsupported-i586</param>
    <service id="mirror1"
             description="Mirror 1 in Germany"
        <param id="url">
        <param name="catalog">SUSE-Linux-10.1-Update</param>

The registration code returned for a particular update service is not the activation code; it is one of two randomly-generated "unique" numbers that ZMD on the system and a Novell-hosted ZLM server exchange with each other. Types other than "zenwork" may not have a registration code. The other is the ZMD GUID that was provided earlier in the process. By using two randomly-generated numbers, a different activation code may be assigned to a system at without having to update the system.

The server returned is either a best-guess appropriate server hosted by Novell, where "best" is determined by the timezone information supplied to the registration process, or, when possible, a company-hosted update server. In order to provide a company hosted update server, an interactive registration process must have been used so that the user could provide the necessary Novell user name and password.

The only other option currently defined is to have ZMD update the hardware and software inventory information. If optional (inventory) parameters are sent to the registration service, this will be set. If optional parameters are not sent (i.e., if the --no-optional command-line option is used), then this option will be unset. This option is a global ZMD parameter so it is send outside of a service tag.

The set of catalogs returned are based on the product information provided. For Novell-hosted update servers, Novell-defined catalogs are returned (defined elsewhere). For customer-hosted update servers, customer-defined catalogs are returned. For SUSE Linux (not enterprise) the best of a list of university mirrors are returned.


Need Info

The registration service may require additional information before completing the registration. In such cases, the registration service will return an XML structured document with a list of parameters that must be supplied to complete the registration process.

<?xml version="1.0" encoding="utf-8"?>
<needinfo xmlns="" lang="en"
    <param id="indentification" class="mandatory"
	     description="Identify System Owner">
            <param id="email" description="E-Mail Address"/>
            <param id="elogin" description="Novell Account Login">
                <param id="username" description="Username"/>
                <param id="password" description="Password"/>
            <param id="custid" description="Customer Number"/>
    <param id="sysident" description="System Identification">
        <param id="hostname" description="Hostname" command="uname -n"/>
        <!-- etc. -->
    <param id="hw_inventory" description="Hardware Inventory">
        <param id="cpu" description="CPU Details" command="hwinfo --cpu"/>
        <!-- etc. -->
    <!-- etc. -->
    <privacy url=""
             description="Submit information to help you manage systems in the Customer Center."

The above <needinfo> response is also sent by the service if the accept="optional" attribute is specified in the <register> request made by suse_register. This attribute should always be specified on the first <register> request made, and tells the service that respond back with optional parameters is allowed even if all mandatory parameters were already met. Whether the server really returns with a <needinfo> dependents on the business logic of the product.

If the –no-optional parameter is given, accept="mandatory" is included in the first register request.

If the –force-registration parameter is given, force="registration" is included in the first register request. In this case the server knows that the user wants a registration. Customers still would like to be able to register because they might get additional services by Novell other than patches, for example specific NTS services.

To suppress any interactive <needinfo> parameters force="batch" can be added to the <register> request by using --batch commandline parameter. When it is impossible for the server to perform the registration in this case, and error is returned.

The suse_register command will then passively collect information for all parameters where a command property is specified unless the --no-optional option is specified. If --no-optional is specified, then only parameters of class "mandatory" where a command property is specified shall be collected. The command must be one of hwinfo, lsb_release or uname; the command name will be substituted with a command-path determined by suse_register. All other command names will be rejected. lsb_release might not be installed. In this case an empty value is returned back to the server.

There are some additional "virtual" commands which are directly implemented in suse_register. These "virtual" commands are: zmd-secret, zmd-ostarget and installed-desktops .

Interactive parameters may be logically grouped by nesting parameter blocks (<param>...</param>) inside other parameter blocks, as shown in the example above. Where a choice one of a set of possible parameters is required, then the parameter blocks shall be contained within a a selection block (<select>...</select>). Note that a selection block masks inheritance of the mandatory class property.

A selection block (<select>...</select>) is forbidden if a command property is specified below.

If any information was passively collected, the registration request will be resubmitted to the registration service before suse_register continues.

If suse_register reaches a state where it does not have and cannot passively collect a value for a mandatory parameter, and the --interactive option has not been set, then it will terminate with an exit code and a diagnostic message. The diagnostic message will contain the XML "need information" block when the --xml-output option is specified, or printed in human-readable form otherwise. When the --no-optional option is used, optional parameters will be stripped from the diagnostic message.

When suse_register is invoked with the --interactive option, the utility will launch a web browser to collect the needed registration information and exchange it with The script will wait for the browser to exit before continuing, so the HTML exchange between the browser and should attempt to close the browser, and advise the user that the browser must be closed in order to continue the registration process.

Because suse_register is a command-line tool, a text browser is started when the --interactive parameter is given. If the --browser option is given, it cannot be sure that calling this browser really blocks the terminal until the browser is closed, and in that case suse_register will exit with a message to restart suse_register if the registration in the browser has completed.

The privacy tag has the same information as in command=listparams.


Standard Assumption for User Identification

In the general case an e-mail address is used as a rendezvous point for subsequent subscription management information functions at It is used in place of Novell "eLogin" account information for usability (e.g., in cases where the user does not yet have a Novell account, can't remember the information, etc.). The activation code, if provided, enables completion of the registration process without the registering user having to subsequently visit

Richer workflows may be implemented using autoyast scripting or interactive registration.


Privacy Policy

Documentation and interactive user interfaces should explain that the required system information (ZMD GUID, hardware architecture tag, operating system type, OEM edition, and timezone) are required to complete the registration process, and Novell reserves the right to use this information for aggregate reporting. However, no personal- or company-identifying information will be shared outside Novell.

Documentation and interactive user interfaces should explain that the optional system information is collected and stored at, but is not used by Novell in any way or shared with any party. It is simply collected for the convenience of the user in managing their systems and subscriptions. While users are encouraged to permit transmittal of this information for their own use, they are not required to do so.


Provisional Registration and Re-Registration

If an activation code is not supplied when suse_register is run, then will automatically allocate an evaluation activation code according to current Novell business policies. The registering user may subsequently assign as permanent activation code using web-based tools at, or using the suse_register process.

The suse_register command may be re-run at any time in order to submit an activation code for this system via the command-line, change the setting for inventory transmittal, or change the identifying information. The system information at will then be updated accordingly. This provides a mechanism for finding "lost systems" in the registration process.


Server Errors

If an error on the server occurs, it will send an HTTP error with a HTML error message page. Javascript in the error message page is not allowed.


Exit Codes

0 – registration or list command completed

1 – more information needed, not interactive

>= 2 – error

ZENworks/Red Carpet

Novell ZENworks Configuration Management is based on policy-based approach to automate software setup and updates. According to Wikipedia

Linux Management initially leveraged the Red Carpet software package (ZENworks Linux Management versions up to 6.6.2) which manages RPM packages installed on Linux workstations and servers. After a complete rewrite (version 7 and upwards), the tool extended its functionality from Software Management to Asset Management, Policy Enforcement, and System Imaging. As of 2008, Linux Management handles software installation, updates and rollbacks with varying degrees of reliability [I would say very low reliability --NNB]. Novell provides updates with bug-fixes and security patches on RPMs distributed with its commercial ( SUSE) Linux products.

Recommended Links



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019