Bigtop
  1. Bigtop
  2. BIGTOP-1096

alternatives within the alternatives-managed sub-directory could be harmful

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 0.7.0
    • Component/s: general
    • Labels:
      None

      Description

      I see that Oozie (at least) today creates a second level alternatives managed subdir (tomcat conf) under something that is already managed by an alternatives mechanism (oozie conf). This looks like it could be a problem if the user switches the top level one (oozie conf).

        Activity

        Hide
        Sean Mackrory added a comment -

        Since the second level alternatives point to the top level symlink (e.g. /etc/oozie/conf) the actual file it points to shouldn't ever be a broken symlink, unless tomcat_deployment does not exist under whatever new configuration they point to. The only way I see that happening accidentally is if a user who has already changed which configuration the symlink points to upgrades. In which case, I think they'll just need to add the new configuration directory, just like they would need to with any new configuration file. We should definitely document that in a "release note" or something, but am I missing a bigger problem?

        Show
        Sean Mackrory added a comment - Since the second level alternatives point to the top level symlink (e.g. /etc/oozie/conf) the actual file it points to shouldn't ever be a broken symlink, unless tomcat_deployment does not exist under whatever new configuration they point to. The only way I see that happening accidentally is if a user who has already changed which configuration the symlink points to upgrades. In which case, I think they'll just need to add the new configuration directory, just like they would need to with any new configuration file. We should definitely document that in a "release note" or something, but am I missing a bigger problem?
        Hide
        Roman Shaposhnik added a comment -

        Here's what I'm talking about:

        # apt-get install oozie
        # cp -r /etc/oozie/conf.dist /etc/oozie/conf.mycluster
        # update-alternatives --install /etc/oozie/conf oozie-conf /etc/oozie/conf.mycluster 100
        update-alternatives: using /etc/oozie/conf.mycluster to provide /etc/oozie/conf (oozie-conf) in auto mode
        

        At this point we get into a very confusing situation wrt. where the tomcat-conf is picked from

        Show
        Roman Shaposhnik added a comment - Here's what I'm talking about: # apt-get install oozie # cp -r /etc/oozie/conf.dist /etc/oozie/conf.mycluster # update-alternatives --install /etc/oozie/conf oozie-conf /etc/oozie/conf.mycluster 100 update-alternatives: using /etc/oozie/conf.mycluster to provide /etc/oozie/conf (oozie-conf) in auto mode At this point we get into a very confusing situation wrt. where the tomcat-conf is picked from
        Hide
        Sean Mackrory added a comment - - edited

        Personally I don't find it confusing because it will look under whatever the current oozie config directory is. So /etc/oozie/conf.mycluster/tomcat-deployment would be used in this case. I wouldn't be opposed to, say, making it a peer directory, if you think that would be less confusing. So for all the components, tomcat configuration would be copied from /etc/<component>/tomcat_deployment, and in Oozie's case that would an alternatives symlink just like /etc/<component>/conf. If people seem to find that more robust, I'll go ahead and implement / test that.

        edit: Actually, the more I think about it the more I really like that - that solves the problem of existing configurations getting upgraded because it's a new directory entirely. If anybody has had to mess with the Tomcat configuration they're hosed anyway, and this way everybody would just inherit the default configuration unless they take further action.

        Show
        Sean Mackrory added a comment - - edited Personally I don't find it confusing because it will look under whatever the current oozie config directory is. So /etc/oozie/conf.mycluster/tomcat-deployment would be used in this case. I wouldn't be opposed to, say, making it a peer directory, if you think that would be less confusing. So for all the components, tomcat configuration would be copied from /etc/<component>/tomcat_deployment, and in Oozie's case that would an alternatives symlink just like /etc/<component>/conf. If people seem to find that more robust, I'll go ahead and implement / test that. edit: Actually, the more I think about it the more I really like that - that solves the problem of existing configurations getting upgraded because it's a new directory entirely. If anybody has had to mess with the Tomcat configuration they're hosed anyway, and this way everybody would just inherit the default configuration unless they take further action.
        Hide
        Sean Mackrory added a comment -

        This patch breaks the configuration out so that the tomcat configuration is parallel to the rest of the configuration. I've tested Oozie and Sqoop especially, but the layout in all the components appears correct and basic operations are still working.

        Thank you for this idea - now that I've seen it I think this is much cleaner and safer.

        Show
        Sean Mackrory added a comment - This patch breaks the configuration out so that the tomcat configuration is parallel to the rest of the configuration. I've tested Oozie and Sqoop especially, but the layout in all the components appears correct and basic operations are still working. Thank you for this idea - now that I've seen it I think this is much cleaner and safer.
        Hide
        Sean Mackrory added a comment -

        Would be good to get this in in 0.7.0 since it fixes poor design that's only introduced in 0.7.0 anyway.

        Show
        Sean Mackrory added a comment - Would be good to get this in in 0.7.0 since it fixes poor design that's only introduced in 0.7.0 anyway.
        Hide
        Roman Shaposhnik added a comment -

        +1

        Show
        Roman Shaposhnik added a comment - +1
        Hide
        Sean Mackrory added a comment -

        Some package tests are failing because /etc/oozie doesn't get cleaned up. I thought this was because of the problem this patch fixes - the path was wrong preventing the new tomcat-deployment alternatives from getting cleaned up.

        On a fresh install I still have the problem however. The alternatives are removed, but the raw config files remain (although the symlinks to /usr/lib/oozie/webapps get deleted). I've compared the hashes of the package contents, the contents immediately after install, and the contents after removing the package, and I don't see any other modification. These aren't files that are created or deleted in scripts - they're entirely within the package archive. I'm quite stumped...

        Show
        Sean Mackrory added a comment - Some package tests are failing because /etc/oozie doesn't get cleaned up. I thought this was because of the problem this patch fixes - the path was wrong preventing the new tomcat-deployment alternatives from getting cleaned up. On a fresh install I still have the problem however. The alternatives are removed, but the raw config files remain (although the symlinks to /usr/lib/oozie/webapps get deleted). I've compared the hashes of the package contents, the contents immediately after install, and the contents after removing the package, and I don't see any other modification. These aren't files that are created or deleted in scripts - they're entirely within the package archive. I'm quite stumped...
        Hide
        Roman Shaposhnik added a comment -

        Sean Mackrory there appears to be some sort of a bug/feature of update-alternatives --remove when more than one alternative is registered. The good news is that there's an easy workaround (which also simplifies your patch somewhat – which is always welcome). Just replace this:

              update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.http || :
              update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.https || :
        

        wit this:

            update-alternatives --remove-all oozie-conf
        

        Could you please do this for ALL of the components you've updated with tomcat conf alternatives on the DEB side?

        Show
        Roman Shaposhnik added a comment - Sean Mackrory there appears to be some sort of a bug/feature of update-alternatives --remove when more than one alternative is registered. The good news is that there's an easy workaround (which also simplifies your patch somewhat – which is always welcome). Just replace this: update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.http || : update-alternatives --remove oozie-tomcat-conf ${conf_tomcat}.https || : wit this: update-alternatives --remove-all oozie-conf Could you please do this for ALL of the components you've updated with tomcat conf alternatives on the DEB side?
        Hide
        Sean Mackrory added a comment -

        I'm not sure I understand what you're saying. Replacing the two commands for removing the tomcat-related alternatives with one remove-all command does not resolve the problem for me. I assume the command as you're typed it as a typo, and you meant "--remove-all oozie-tomcat-conf". As before, all the alternatives symlinks are removed but all the actual configuration files remain. All the other components only have one Tomcat-related alternative, so I don't see the benefit of using remove-all in those components, and in fact this then forcefully de-registers any configurations that the user may have added, so I don't think we should do it unless it solves a bigger problem.

        Show
        Sean Mackrory added a comment - I'm not sure I understand what you're saying. Replacing the two commands for removing the tomcat-related alternatives with one remove-all command does not resolve the problem for me. I assume the command as you're typed it as a typo, and you meant "--remove-all oozie-tomcat-conf". As before, all the alternatives symlinks are removed but all the actual configuration files remain. All the other components only have one Tomcat-related alternative, so I don't see the benefit of using remove-all in those components, and in fact this then forcefully de-registers any configurations that the user may have added, so I don't think we should do it unless it solves a bigger problem.
        Hide
        Sean Mackrory added a comment -

        So it turns out, if you forget that apt-get purge != apt-get remove, you end up doing something silly when testing.

        Show
        Sean Mackrory added a comment - So it turns out, if you forget that apt-get purge != apt-get remove, you end up doing something silly when testing.
        Hide
        Roman Shaposhnik added a comment -

        +1. Please commit it ASAP.

        Show
        Roman Shaposhnik added a comment - +1. Please commit it ASAP.
        Hide
        Sean Mackrory added a comment -

        Pushed!

        Show
        Sean Mackrory added a comment - Pushed!

          People

          • Assignee:
            Sean Mackrory
            Reporter:
            Roman Shaposhnik
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development