|
|
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 | |||||||
| Registration Problems | Recommended Books | Reference | ||||
| System information | Startup and shutdown | Red Carpet | autoyast | Humor |
Etc |
The registration process is invoked in one of the following ways:
Syntax:
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 Novell.com, and Novell.com will return an XML-structured file with the information needed to configure ZMD for patch and update.
Options
 |
 |
 |
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!
|
|
|
Version 13, 19 December 2006.This paper describes how the registration process is implemented on Linux systems. What happens on Novell.com 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 Novell.com, and Novell.com will return an XML-structured file with the information needed to configure ZMD for patch and update.
Options
-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
[edit]
Description
[edit]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 https://secure-www.novell.com/center/regsvc/?command=listproducts .
The server return a list of products, for example:
<?xml version="1.0" encoding="UTF-8"?> <productlist xmlns="http://www.novell.com/center/xml/regsvc10" lang="en-US"> <privacy url="http://www.novell.com/company/policies/privacy/" description="Novell Privacy Statement" class="informative"/> <product>Novell Linux Desktop</product> <product>SUSE Linux</product> <product>SUSE SLES</product> </productlist>[edit]List Parameters
When invoked with the --list-parameters option, the suse_register command will contact the registration service at https://secure-www.novell.com/center/regsvc/?command=listparams, 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="http://www.novell.com/xml/center/regsvc-1_0"> <product version="10.1" release="Beta9" arch="i686"><![CDATA[SUSE LINUX]]></product> </listparams>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="http://www.novell.com/center/xml/regsvc10" 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="http://www.novell.com/company/policies/privacy/" description="Submit information to help you manage systems in the Customer Center." class="informative"/> </paramlist>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.
[edit]Registration
In all other cases, the suse_register command will send an XML structured document to the registration service at https://secure-www.novell.com/center/regsvc/?command=register .
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 Novell.com 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="http://www.novell.com/xml/center/regsvc-1_0" lang="en" accept="optional" force="registration"> <guid>1badbeef4abadb01</guid> <host>564894af454e9d12</host> <product version="10" release="" arch="i686"> <![CDATA[SUSE-Linux-Enterprise-Server-i386]]> </product> <param id="processor">i686</parameter> <param id="platform">i386</parameter> <param id="timezone">US/Mountain</parameter> <mirrors count="5" /> </register>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="http://www.novell.com/xml/regsvc10" lang="en"> <guid>1badbeef4abadb01</guid> <param id="update_inventory">true</param> <service id="novell-emea" description="Novell Network European Update Service" type="zenworks"> <param id="url"> https://dublin.network.novell.com/zlm7/ </param> <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> <service id="mirror1" description="Mirror 1 in Germany" type="yum"> <param id="url"> ftp://ftp.suse.com/pub/suse/i386/update/10.1 </param> <param name="catalog">SUSE-Linux-10.1-Update</param> </service> </zmdconfig>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 Novell.com 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.
[edit]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="http://www.novell.com/xml/regsvc10" lang="en" href="https://secure-www.novell.com/center/regsvc?command=interactive&guid=1badbeef4ab"> <param id="indentification" class="mandatory" description="Identify System Owner"> <select> <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> <param id="custid" description="Customer Number"/> </select> </param> <param id="sysident" description="System Identification"> <param id="hostname" description="Hostname" command="uname -n"/> <!-- etc. --> </param> <param id="hw_inventory" description="Hardware Inventory"> <param id="cpu" description="CPU Details" command="hwinfo --cpu"/> <!-- etc. --> </param> <!-- etc. --> <privacy url="http://www.novell.com/company/policies/privacy/" description="Submit information to help you manage systems in the Customer Center." class="informative"/> </needinfo>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 Novell.com. The script will wait for the browser to exit before continuing, so the HTML exchange between the browser and Novell.com 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.
[edit]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 Novell.com. 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 Novell.com.
Richer workflows may be implemented using autoyast scripting or interactive registration.
[edit]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 Novell.com, 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.
[edit]Provisional Registration and Re-Registration
If an activation code is not supplied when suse_register is run, then Novell.com 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 Novell.com, 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 Novell.com will then be updated accordingly. This provides a mechanism for finding "lost systems" in the registration process.
[edit]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.
[edit]Exit Codes
0 registration or list command completed
1 more information needed, not interactive
>= 2 error
Version 13, 19 December 2006.This paper describes how the registration process is implemented on Linux systems. What happens on Novell.com 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 Novell.com, and Novell.com will return an XML-structured file with the information needed to configure ZMD for patch and update.
Options
-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
[edit]
Description
[edit]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 https://secure-www.novell.com/center/regsvc/?command=listproducts .
The server return a list of products, for example:
<?xml version="1.0" encoding="UTF-8"?> <productlist xmlns="http://www.novell.com/center/xml/regsvc10" lang="en-US"> <privacy url="http://www.novell.com/company/policies/privacy/" description="Novell Privacy Statement" class="informative"/> <product>Novell Linux Desktop</product> <product>SUSE Linux</product> <product>SUSE SLES</product> </productlist>[edit]List Parameters
When invoked with the --list-parameters option, the suse_register command will contact the registration service at https://secure-www.novell.com/center/regsvc/?command=listparams, 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="http://www.novell.com/xml/center/regsvc-1_0"> <product version="10.1" release="Beta9" arch="i686"><![CDATA[SUSE LINUX]]></product> </listparams>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="http://www.novell.com/center/xml/regsvc10" 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="http://www.novell.com/company/policies/privacy/" description="Submit information to help you manage systems in the Customer Center." class="informative"/> </paramlist>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.
[edit]Registration
In all other cases, the suse_register command will send an XML structured document to the registration service at https://secure-www.novell.com/center/regsvc/?command=register .
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 Novell.com 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="http://www.novell.com/xml/center/regsvc-1_0" lang="en" accept="optional" force="registration"> <guid>1badbeef4abadb01</guid> <host>564894af454e9d12</host> <product version="10" release="" arch="i686"> <![CDATA[SUSE-Linux-Enterprise-Server-i386]]> </product> <param id="processor">i686</parameter> <param id="platform">i386</parameter> <param id="timezone">US/Mountain</parameter> <mirrors count="5" /> </register>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="http://www.novell.com/xml/regsvc10" lang="en"> <guid>1badbeef4abadb01</guid> <param id="update_inventory">true</param> <service id="novell-emea" description="Novell Network European Update Service" type="zenworks"> <param id="url"> https://dublin.network.novell.com/zlm7/ </param> <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> <service id="mirror1" description="Mirror 1 in Germany" type="yum"> <param id="url"> ftp://ftp.suse.com/pub/suse/i386/update/10.1 </param> <param name="catalog">SUSE-Linux-10.1-Update</param> </service> </zmdconfig>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 Novell.com 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.
[edit]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="http://www.novell.com/xml/regsvc10" lang="en" href="https://secure-www.novell.com/center/regsvc?command=interactive&guid=1badbeef4ab"> <param id="indentification" class="mandatory" description="Identify System Owner"> <select> <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> <param id="custid" description="Customer Number"/> </select> </param> <param id="sysident" description="System Identification"> <param id="hostname" description="Hostname" command="uname -n"/> <!-- etc. --> </param> <param id="hw_inventory" description="Hardware Inventory"> <param id="cpu" description="CPU Details" command="hwinfo --cpu"/> <!-- etc. --> </param> <!-- etc. --> <privacy url="http://www.novell.com/company/policies/privacy/" description="Submit information to help you manage systems in the Customer Center." class="informative"/> </needinfo>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 Novell.com. The script will wait for the browser to exit before continuing, so the HTML exchange between the browser and Novell.com 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 Novell.com. 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 Novell.com.
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 Novell.com, 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 Novell.com 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 Novell.com, 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 Novell.com 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
Society
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
Quotes
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
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
History:
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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haters 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. www.softpanorama.org 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 |
Disclaimer:
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
