glassfish
  1. glassfish
  2. GLASSFISH-11252

zip bundles: uuid in cfg_cache should be removed

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: packaging
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      11,252

      Description

      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.

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

      1. cfg_cache-after
        3 kB
        Snjezana Sevo-Zenzerovic
      2. cfg_cache-before
        3 kB
        Snjezana Sevo-Zenzerovic

        Activity

        ckamps created issue -
        Hide
        ckamps added a comment -

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

        Show
        ckamps added a comment - Confirmed that this issue is also present in the latest-web.zip file.
        Hide
        scatari added a comment -

        Transferring to Snjezana for further evaluation.

        Show
        scatari added a comment - Transferring to Snjezana for further evaluation.
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

        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?

        Show
        Snjezana Sevo-Zenzerovic added a comment - 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?
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

        Created an attachment (id=4038)
        Initial cfg_cache

        Show
        Snjezana Sevo-Zenzerovic added a comment - Created an attachment (id=4038) Initial cfg_cache
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

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

        Show
        Snjezana Sevo-Zenzerovic added a comment - Created an attachment (id=4039) cfg_cache after client bootstrap
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

        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.

        Show
        Snjezana Sevo-Zenzerovic added a comment - 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.
        Hide
        ckamps added a comment -

        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:

        http://wikis.sun.com/display/IpsBestPractices/Packaging+and+Install+Bundle+Checklist

        Show
        ckamps added a comment - 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: http://wikis.sun.com/display/IpsBestPractices/Packaging+and+Install+Bundle+Checklist
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

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

        Show
        Snjezana Sevo-Zenzerovic added a comment - Very well. We'll take care of this in the trunk, setting target release to 3.1.
        Hide
        ckamps added a comment -

        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.

        Show
        ckamps added a comment - 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.
        Hide
        ckamps added a comment -

        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:

        https://updatecenter2.dev.java.net/issues/show_bug.cgi?id=1955

        Show
        ckamps added a comment - 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: https://updatecenter2.dev.java.net/issues/show_bug.cgi?id=1955
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 11252 42856
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Tom Mueller made changes -
        Fix Version/s not determined [ 11149 ]
        Fix Version/s 3.1 [ 10968 ]

          People

          • Assignee:
            Snjezana Sevo-Zenzerovic
            Reporter:
            ckamps
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: