Release Notes

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 version number for the package looks like this:

SpecificationVersion(ImplementationVersion)[sha256=abcd1234]

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.

Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...

Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...

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.

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:

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:

These fixes are related to Bugzilla 781964/CVE-2012-0052 and Bugzilla 783008/CVE-2012-0062.

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.

Some improvements have been made to the way that the CLI works: