Release Notes
JBoss Operations Network 3.0.1
for release information
Copyright © 2012 Red Hat, Inc
March 18, 2012
Abstract
These release notes contain important information about fixed bugs, known issues, and other technical notes available at the time that JBoss Operations Network 3.0.1 was released.
JBoss Operations Network 3.0.1 is a bug fix release which addresses numerous issues from JBoss ON 3.0.
1. Notable Changes in 3.0.1
While JBoss ON 3.0.1 is primarily a bug fix release, there have been some changes in JBoss ON functionality related to those bug fixes and that address recent security updates.
1.1. Improved Version and Package Management
Packages are uniquely identified in JBoss ON based on their version number Before JBoss ON 3.0.1, the method to calculate the package version ID number was a combination of the package name and the package version, where the package version could be derived from the package manifest or from a user-supplied value. However, this method of calculating the version could be inconsistent and could easily lead to collisions that prevented packages from being properly uploaded and deployed. Yet, the version number itself is critical to maintaining package data.
Starting in JBoss ON 3.0.1, there are two package version numbers:
- A display version number, a user-friendly string that is used to identify the package in the UI and CLI but which does not have to be unique.
- A unique internal version number. This string is a calculated SHA-256 checksum based on the package contents and, optionally, the specification and implementation versions given in the
META-INF/MANIFEST.MFfile.
Note
Existing packages are automatically updated to use the new version scheme. The agent re-discovers all of the content and then generates the appropriate version number based on the SHA-256 hash and the relevant information in the package's
META-INF/MANIFEST.MF file.
A version number for the package looks like this:
SpecificationVersion(ImplementationVersion)[sha256=abcd1234]
If the
META-INF/MANIFEST.MF file does not contain either the specification version or the implementation version, then only one is used. If neither exists, the SHA is used.
Important
For unexploded (archived) content, the checksum is recalculated with every package discovery scan and compared to the checksum in inventory.
For exploded WARs and EARs, the calculated SHA-256 checksum is added to the
MANIFEST.MF file. This allows the agent to check the file during discovery scans to verify the version of the package quickly.
Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...
Because the content deployment process edits the
META-INF/MANIFEST.MF file, the deployed content is not exactly identical to the content packages that were uploaded.
Versioning only matters to content knit with a resource, like EARs and WARs. Other types of content stored in content sources (like CLI scripts used for alerting) do not track versions. Content deployed in bundles handles versioning through the bundle definition, not the content system.
1.2. Changes to Agent Registration
When the JBoss ON agent starts up, it registers with the JBoss ON server. The JBoss ON server creates an entry based on the given agent name, IP address, and port number. The JBoss ON server also creates a randomly-generated string, a security token, which is also associated with the agent name and with the IP address and port number pair. The agent sends its security token to the server when it restarts as a form of pseudo-authentication.
Prior to JBoss ON 3.0.1, the server allowed an agent to re-register using the same agent name, from a different IP address and port, without the security token. An unapproved agent could use the name and identity of an approved agent. The JBoss ON server simply treated the new agent as if it were the original agent.
The JBoss ON server now verifies the agent identity through the security token before allowing registration changes:
- An agent cannot re-register with an existing agent name without the corresponding security token.
- An agent cannot re-register with an existing IP address/port combination without the corresponding security token.
The agent security token is persisted in the agent's Java preferences and remains even if the agent is restarted or uninstalled. The agent command-line options have been updated to help manage the security token in the agent preferences:
- The
--cleanconfighas been been changed so that it clears all agent configuration, except the security token. This allows the agent to be re-registered easily at a later time. - The
--fullcleanconfighas been added to clean all configuration, including the security token.
These fixes are related to Bugzilla 781964/CVE-2012-0052 and Bugzilla 783008/CVE-2012-0062.
1.3. New and Changed Remote API Methods
The ContentManagerRemote interface has been updated to accommodate the changes in how the content system handles version numbers. One method is deprecated (
void deployPackages), and two new methods have been added (PackageVersion createPackageWithDisplayVersion and void deployPackagesWithNote).
The details of changes between 3.0.0 and 3.0.1 is available with the API at https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.1/html/API/index.html.
1.4. CLI Changes
Some improvements have been made to the way that the CLI works:
- The CLI (in interactive mode) now properly accepts and interprets arguments with spaces.
- The
updateBackingContentmethod for now accepts a defined version number to use with the uploaded package.
