[GLASSFISH-11252] zip bundles: uuid in cfg_cache should be removed Created: 04/Dec/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: ckamps Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: HTML File cfg_cache-after     HTML File cfg_cache-before    
Issuezilla Id: 11,252


Using latest-glassfish.zip from Dec 3, the file
glassfishv3/.org.opensolaris,pkg/cfg_cache has uuid entries for each
publisher/repo, but it should not. The uuid = lines need to be removed from the
cfg_cache file prior to shipping the .zip file.

The uuids will be automatically generated by the pkg(5) tooling as those tools
are used to manage the installation.

Excluding the UUIDs from the pre-installed image is important because the UUIDs
enable us to report on unique installation instances. If the same UUIDs are
hardcoded across installations, then our reporting sees much fewer instances
than exist.

origin = http://pkg.glassfish.org/v3/stable/
ssl_key = None
ssl_cert = None
uuid = 24019f82-dfd5-11de-83d8-0003ba2efce4
repo.related_uris = []

Comment by ckamps [ 04/Dec/09 ]

Confirmed that this issue is also present in the latest-web.zip file.

Comment by scatari [ 04/Dec/09 ]

Transferring to Snjezana for further evaluation.

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

I am confused. This is what distribution assembly document says:

"If you are using a universal image along with the pkg(5) Java Bootstrap
facility, then the publisher UUID will be reset automatically when the bootstrap
is executed. The Java Bootstrap facility also has an input value for determining
whether anonymous information should be sent to the server. If this is set, then
the send-uuid property will be set to true within the image. "

All GF zip files, both the standalone image and the one used for installer
payload are universal images, without bundled client. So, they would fall under
this section and shouldn't this mean that bootstrap overrides initial UUID
values. Did that change?

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Created an attachment (id=4038)
Initial cfg_cache

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Created an attachment (id=4039)
cfg_cache after client bootstrap

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

I'll take the liberty of closing this issue since I just verified that client
bootstrap still properly updates all initial UUID values. "Before" and "after"
cfg_cache files are being attached.

Comment by ckamps [ 04/Dec/09 ]

You are correct in that the bootstrap code will reset all of the UUIDs. Sorry
about that. This issue is not a P3 for that reason.

However, it's still a relevant issue in those cases where a user has multiple
images installed and is using tools from another image to manage the
non-bootstrapped image. In this case, the uuids won't get reset because the
bootstrap is never used. Lowering to a P4 because although the exposure is
less, it's still an issue.

This situation will become more common because we have numerous pkg(5) product
distributions with their own copies of pkg(5) tools: various versions of GF v3,
v3 bundled in various IDEs, Web Space, MQ, Web Stack, etc.

Since the Python pkg(5) code will set the uuid on all publishers when uuid = is
not present, it's actually a better practice to not include uuid = at all in the
pre-installed images. So when someone points Update Tool to an image that has
not been bootstrapped, that image will get new UUIDs when the uuid = lines are
not already present. If they're already present, the hardcoded factory UUIDs
will remain in effect.

Although the install image checklist already calls for removing the uuid =
settings, we'll update the Install Image Assemblers guide with this information.
Here's the checklist document:


Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Very well. We'll take care of this in the trunk, setting target release to 3.1.

Comment by ckamps [ 05/Dec/09 ]

The plot thickens. Changing to RFE. Ironically, even if we wanted to modify the
GF cfg_cache to exclude the uuid = settings, it will not work. Until we make
some enhancements to how the Java API and bootstrap work, excluding uuid = in
the GF bundles installerless zip bundles is not feasible. Once the UC project
files an RFE to address some gaps on the UC side, we'll update this RFE with a
pointer to that issue.

Excluding uuid = in product bundles that don't make use of the pkg(5) Java API
apart from perhaps the initial bootstrap (e.g. Web Space, MQ, Web Stack, etc)
continues to be a recommended best practice because the pkg(5) Python API will
always automatically add the uuid settings.

Here's why excluding uuid = in the cfg_cache won't work with GF zip bundles today:

1) The bootstrap doesn't currently automatically add uuids when no uuid =
entries exist. It only resets uuid = entries when they exist. In the GF case,
this gap wouldn't matter that much because of the next aspect.

2) When start-domain is executed, the GF code uses the pkg(5) Java API to set
the uuids to the same value so as to align with the uuid used to identify and
potentially register the installation of GF. However, due to the behavior of
the Java API, it appears this setting only takes effect when the uuid = entries
already exist.

(I have not tested the installer-wrapped GF bundles to see how they would behave
with uuid = not present).

As a result of this investigation, the UC team is looking into enhancing the
bootstrap and pkg(5) Java API to better handle cases where uuid = is not present
at all.

Related issues:

1) Double uuids for same installation:

Given the behavior today where start-domain effectively resets the uuids a
second time for the same installation, our backend usage reporting is probably
counting more unique installations than actually exist. Perhaps this issue is
limited to the use of GF zip bundles. The UC team will look into the reporting
system impact.

2) Running bootstrap after start-domain overwrites sync'd uuids:

This is actually a very likely scenario:

  • User downloads zip and expands it.
  • User knows nothing about bin/updatetool and starts the domain.
  • During start-domain, uuids are set and sync'd.
  • Later on, user executes bin/updatetool which in turn executes the bootstrap.

At this point the bootstrap overwrites the sync'd up uuids as set via
start-domain. Another start-domain will sync the uuids again, but in the
meantime, a series of updates or installs may have occurred via the Update Tool
with the unsync'd uuids.

Comment by ckamps [ 05/Jan/10 ]

In the upcoming UC 2.3 Update 1 and 2.4 releases, the absence of "uuid ="
settings from the cfg_cache will result in UUIDs being automatically assigned or
assigned via the setAuthority() method of the Image.java class.

This means that this RFE to remove the factory UUIDs from the GF bundles can be
addressed in GF 3.1 as long as 2.3 U1 or greater of the toolkit pkg-client.jar
is used.

Here's the toolkit issue that was fixed:


Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Thu Jul 02 10:44:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.