ZENworks System Update-Catalog

4 Likes
11 months ago

Introduction

The ZENworks System Update can be performed in two ways either from Novell Control Center (NCC) or by importing the system update using the ZMAN command

  1. NCC: Register the zone in NCC. After registering, you will be getting notifications on the ZCC System Update page, whenever a new build is available. Using this notification, you can download the content.
  2. ZMAN: Download the build in one of the Primary Server. Open the terminal where you have saved the build, and then run the "ZMAN SUI <build_name>.

After importing the content into ZCC, the remaining steps are the same for both NCC and ZMAN.

System Update Workflow

SystemUpdateFlowChart.png

Workflow Process

Evaluation of Pre-requisites

After the Golbal_PRE_REQS command is executed, the prerequisite framework evaluates all the zone-wide prerequisites applicable for the update. Prerequisites can be categorized as mandatory and optional. All mandatory prerequisites must be met for an update to continue. In case one or more prerequisites are not met, then the update will move to an ERROR state. Click on the "ERROR" link to view the failed prerequisites in a tabular form. If only optional prerequisites are not met, then the super administrator will be provided the choice to either fix the errors or acknowledge and continue with the update. Even if one of the mandatory prerequisites fails, then the update will not continue until those prerequisites are met.

Refer to the following screenshots for more information:

Failed Pre-requisite.png
 
Failed Pre-requisite1.png
Pre-requisites log: You can debug this log file to verify whether the pre-requisites check is completed or not.     
 
Pre-requisitesLog.png
 

Preparing the Update

A lot of processing happens during the preparation phase. After downloading or importing the update, a queue action "system.update.preparing.stage" is created that starts the preparation of the update and involves the following steps:

  1. Moves the update status to Prepare

            This step involves the following points:            

 a. Creation of pending entries for system update content for the Satellite Servers.

 b. Creation of a recurring queue action on all the Primary Servers.

Creation of Pending Entries

For all the targeted Satellite Servers, the system update content, pending entries need to be created in zContentSyncState.For this purpose, a recurring queue action "create.su.content.pending.entry.queue.action" is created with a repeat frequency of 20 minutes. This queue action will gather all the valid system update contents and create pending entries for all the Satellite Servers by calling the stored procedure "sp_zContentSyncState_update". After creating these entries successfully, the recurring queue action will be deleted.

Creation of Recurring Queue Action

The "create.prepare.state.actions.queue.id” recurring queue action is created on all the Primary Servers.

Responsibilities of the handler for the queue action are stated below:

  • Content Replication: This is a blocking call to ensure that all the content required for the system update is available on all the Primary Servers. ZENworks continues to monitor it until there are no missing contents that should be replicated.
  • Copying web apps to Jetty folder: There is a light-weight Jetty server that is packaged with ZeUS. This Jetty server is of immense importance to monitor the system update process on the Primary Servers. As you know, we mandate the stopping of services on all the Primary Servers before the update process. Now that the services are down, we have no ZCC available to monitor the update. The enhanced System Update framework provides a "status-web app" that will be hosted on this Jetty Server. Through this web app, the administrator will be able to track and monitor the update process.
         The path of the web app is shown in the following screenshot:
 

                                    WebAppPath.png

>  Creation of Update XML: The update XML for INSTALL and PRE-INSTALL commands are also constructed as part of the preparation activity. These files can be found in the prepare folder under the ZeUS work folder:

On Linux: /var/opt/novel/zenworks/ZeUS/work 

On Windows: %ZENWORKS_HOME%/ZeUS/work

> Creation of UpdateInfo XML: The generated updateInfo.xml contains information about the update, it's identifiers, the list of updates it requires and/or supersedes, and whether it is a role-based update or not. This XML file will be inside the "prepare" folder under ZeUS "work" folder. After all the above steps are completed, the update is added to the list of prepared updates list, maintained in the "updates-prepared" file that is available in the following locations:

On Linux: "/var/opt/novell/zenworks/work/system-update"

On Windows: %ZENWORKS_HOME%/work/system-update

 

                                    InstallAndPreInstallCmd.png

2. This queue action performs the Preparing activities on the servers. After the preparation is completed on all the servers, additionally, a monitor thread is started that will move the update status to "PREPARED".

The "PREPARING" state is a link which allows you to monitor the status of all the servers. This dialog also allows you to ignore any unreachable server in the zone. 

Monitoring Thread and Ignoring servers
The Monitor Thread runs in the loader context and logging will be seen in loader-messages.log.

                                     loader-messages log.png

Every step performed during the preparation stage will be logged in to prepare-update.log in the logs folder.

Prepare-update log: The start and end of the System Update Preparation phase are tracked in Prepare-update.log.

Screenshot 1

                                   PrepareUpdateLog1.png
                                

                         Screenshot 2

                                   PrepareUpdateLog2.png
 

Ignoring Preparation of Servers

During the process of preparation of an update, the status of the update moves to "PREPARING". This is a link when clicked displays the progress of the activity (Refer to the below image).

All the Primary Servers in the zone are monitored to ensure the preparation is complete and the update is then moved to the "PREPARED" state. Only when all the Primary Servers in the zone are prepared, then the update will proceed with configuring, authorizing, and finally deploying the update. Now, if some server in the zone is unreachable or for some reason you want to ignore the preparation activity on those servers, you can go ahead and mark the server as ignored. This choice will be persisted in the prepIgnored column of zSystemUpdatePrepareStage table against that serverUID and updateUID. In this case, preparation will still proceed on the "ignored" servers, but servers will not be monitored. These servers will then have to be manually updated.
 
                        Ignore Device.png
 

Re-trigger Preparation Update

You can also re-trigger the preparation of the update by using the "Retry Prepare Update" action. When you retry the prepare update, if all the zone-wide prerequisites were met, or if only optional prerequisites were failing and the administrator chose to ignore those failures and continue, then, in these scenarios the evaluation of prerequisites will be skipped. Two entries are created in the "zOpaqueData" to keep track of this information.

The keys for the same are as follows:

  • com.microfocus.zenworks.pre.requisite.status – This entry will be set to "PASS" if all prerequisites were met.
  • skip.optional.prerequistes - This entry will be created when an administrator ignores the failing optional prerequisites and continue with the update.
Deploy Update To Devices.png
 

Schema Changes

There are several stages involved in the preparation of an update. These stages should be tracked to know the progress of the update. To track the update, a new table is introduced, which keeps track of the update preparation progress on each of the Primary Servers. This information is persisted in a new table named zSystemUpdatePrepareStage.             

 

 SystemUpdatePrepareStageTable.png

All the column names are self-explanatory except the SUID column, which is nothing but the updateUID. For a given update, this table will have one entry for each of the Primary Servers in the zone. An entry is created as soon as the preparation process starts. As already mentioned, an option is provided to ignore a server from preparation. This will be updated in this table and marked with the help of prepIgnored column. The "status" column is an interesting one. it is a bitmask that encapsulates the progress of all stages involved in the preparation process.

This table is of vital importance to track the progress of the preparation of an update. We have a monitor thread that keeps monitoring the progress on all the Primary Servers and when preparation is successful, it will move the update to the Prepared state. If a server is ignored from preparation, the prepIgnored flag is set and those servers will not be monitored.

Authorization Stage

After successful completion of the prerequisites check and preparing process on all the Primary Servers, the update is Prepared and ready for the Administrator’s authorization, which is the Awaiting Authorization stage.

          Awaiting Authorization.png
 
The Administrator can authorize the update by click on "Authorize Update" in the Action dropdown.
 
     AuthorizeUpdate.png

Configure Update Stage

After the system update is Prepared and Authorized, the Configure Update option will be shown only if the update requires inputs. If the inputs are required, the Configure Update web console is opened in a new tab, with the single sign-on, where you will be prompt for the inputs. After the inputs are provided, the data is saved into the "zSystemUpdateConfiguration" table and each page-wise inputs will be saved to the "zSystemUpdatePageInputs" table. Inputs, which are gathered, can be changed until the update is deployed to one of the devices.

Note: If there are no inputs required, then the Configure Update option will be disabled after the Administrator authorizes the update.

Ready to Deploy Update Stage

After the system update is Prepared, Authorized, and Configured, it can now be deployed to all the devices in the zone. The update can be deployed to a stage or manually selected set of devices. As soon as we deploy the update, a "stop services" Quick Task is created to stop services on all the servers and after successfully stopping the services, a Remote Method Invocation asking ZeUS to launch the preglobal jar. So, the point to note here is that going forward, ZeUS will launch the preglobal jar. Once pre-global actions are successfully executed, ZeUS will update the "globalActionsRun" flag in zSystemUpdateEx and proceed with the launch of configuration action "PreGlobalAdvanceNextStage" to advance to the next stage if an update is assigned to a Stage and is not set to postpone staging. Once this stage is completed, ZeUS will be refresh and it will launch ZENUpdater to perform the package update. Before you click Finish in the Deploy update wizard, a pop-up window will be displayed. In the pop-up window, a link will be displayed, where you can track the system update progress. The link will be similar to https://ServerFQDN:7444//systemupdate/sustatus. The FQDN in the URL can be replaced with the server IP/name where the update is in progress, and the status web app can be launched.

     Ready To Deploy Stage.png
 

Introducing the Stop Services Quick Task

When an update is deployed to a set of devices, a "stop services" quick task is created for all the servers, except the server on which the preglobal actions are executed. ZeUS will process this quick task, which goes ahead and stops the loader, server, and monitor services on the Primary Server.

On the server in which the preglobal actions are running, ZeUS stops the services without creating a quick task. On successfully stopping services, the preglobal action jar is launched.

 

Note: A stop services thread running throughout the execution of the preglobal actions. This thread will try to stop services every 10 minutes, thus ensuring that the services remain stopped.

 

If for some reason, stopping of services fails on one or more servers, the update moves to the "ERROR" state. Clicking on the Error link displays the list of servers on which the task failed. The Administrators can then either go ahead and manually stop the services or redeploy the update.

Following is a sample screenshot of the dialog that lists the servers on which stop services Quick Task had failed.

                                            Failed Servers.png

 

Note: For more information, refer to "loader-messages.log” on the device that triggers the quick task.

After successfully deploying the System Update to the device, the status will be changed to Scheduled.

              Scheduled Stage.png

 

Tracking of System Update Status

Since the System Update Loader and Monitor services are down, we will not be able to launch the ZCC to track the System Update Status. However, we have the Status Webapp option from which we can tack the System Update Status, https://ServerFQDN:7444//systemupdate/sustatus. In this URL, replace the “ServerFQDN” with the device IP on which the System Update was initiated, and open the link in a browser.

Following are the images that display the system update statuses:

Status of Updating the Schema

                 Schemaupdate.jpg

Status of Updating the Package

                    PackageUpdate_ZeusDown.jpg

We can also track the System Update Status by logging into the deployed device by clicking the ZENworks icon in the taskbar.

                         Zenworks Update.png

After completing 100 % installation of System Update, a prompt is displayed to restart the device.

                  System Reboot Prompt.png
 
Note: After the System Update is completed on the Primary Server, there is a stage where the system update reports status back to the Primary Server. This Primary Server rebuilds the deployment package, if the rebuilding package fails, then the web app status is displayed as “Error” instead of “Finish”. In these situations, you can check by logging into ZCC as shown in the below screenshot, or in “loader-message.log”.

Launch ZCC after the services are running. In ZCC, go to the System Update page, check the status, and deployed the build version on the configuration page.

For more information, see the following two images:

Screenshot 1

  SystemUpdateSuccessful.png

Screenshot 2

Deployed Build Version might take some time to reflect the data.  

Build Version after Update.png

Note: To track the individual system update status, you can see the System-update.log on the device.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

Labels:

Configuration Management
Comment List
Anonymous
Related Discussions
Recommended