Archiva
  1. Archiva
  2. MRM-523

Appearance Actions do not work when ${user.home} is invalid.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0-beta-2
    • Fix Version/s: 1.1
    • Component/s: system
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The reliance on maven core components with regards to Appearance / Company Info / Edit Pom actions, prevents server installations without a valid user $HOME directory. ( such as /dev/null )

      We should migrate away from maven core components at our earliest opportunity.

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          not critical.

          it's just a local repository assumption (we should instead pass in a repository to store in) - there are other points in archiva that use user.home and would be similarly affected

          Show
          Brett Porter added a comment - not critical. it's just a local repository assumption (we should instead pass in a repository to store in) - there are other points in archiva that use user.home and would be similarly affected
          Hide
          Brett Porter added a comment -

          a related issue is the creation of ~/.m2/archiva directory for a single metadata file during this process.

          Show
          Brett Porter added a comment - a related issue is the creation of ~/.m2/archiva directory for a single metadata file during this process.
          Hide
          Joakim Erdfelt added a comment -

          Actually, no.

          We have mitigated all other $

          {user.home}

          situations.
          And we have 2 known users now that run Archiva on a Unix environment with a homeless user (a common security practice).

          Show
          Joakim Erdfelt added a comment - Actually, no. We have mitigated all other $ {user.home} situations. And we have 2 known users now that run Archiva on a Unix environment with a homeless user (a common security practice).
          Hide
          Brett Porter added a comment -

          no to "not critical", or no to the creation of ~/.m2/archiva (which I still see)?

          Does the server fail to start, or do the appearance actions just not work (I couldn't get a failure other than to try and edit the logo)?

          Show
          Brett Porter added a comment - no to "not critical", or no to the creation of ~/.m2/archiva (which I still see)? Does the server fail to start, or do the appearance actions just not work (I couldn't get a failure other than to try and edit the logo)?
          Hide
          Joakim Erdfelt added a comment -

          The creation of $HOME/.m2/archiva is a result of reliance on the maven core components, and should be filed as a separate bug.

          This wasn't filed as critical, just major.

          If someone decides to enter the appearance screens, as they are now, that whole process fails.
          Once the appearance screens have been activated, then the logs fill up ridiculously fast with the exceptions, all tracked down to the appearance / logo logic attempting to resolve content, on every access to every screen in the application.

          This is a severe problem.
          We must address it.
          Maybe not for the next pre-1.0 release, but definitely before 1.0 final.

          Show
          Joakim Erdfelt added a comment - The creation of $HOME/.m2/archiva is a result of reliance on the maven core components, and should be filed as a separate bug. This wasn't filed as critical, just major. If someone decides to enter the appearance screens, as they are now, that whole process fails. Once the appearance screens have been activated, then the logs fill up ridiculously fast with the exceptions, all tracked down to the appearance / logo logic attempting to resolve content, on every access to every screen in the application. This is a severe problem. We must address it. Maybe not for the next pre-1.0 release, but definitely before 1.0 final.
          Hide
          Brett Porter added a comment -

          suggested workaround to avoid the log spam: set -Duser.home in the wrapper (or HOME in the env) before running to an effectively-homeless but writeable location (eg /tmp/archiva-home) - the account can still have no real home, this is just to tell Java where to treat $HOME.

          Will fix this properly in 1.x - I would suggest:

          • sourcing from the managed repositories instead of remote
          • proxying if necessary
          • not needing a local repository
          • when saving a new POM, allow selection of the managed repository to store to

          This makes the actions more specific to Archiva, so might need to come up with something easier to work with there so we don't diverge from what is used in Continuum.

          Show
          Brett Porter added a comment - suggested workaround to avoid the log spam: set -Duser.home in the wrapper (or HOME in the env) before running to an effectively-homeless but writeable location (eg /tmp/archiva-home) - the account can still have no real home, this is just to tell Java where to treat $HOME. Will fix this properly in 1.x - I would suggest: sourcing from the managed repositories instead of remote proxying if necessary not needing a local repository when saving a new POM, allow selection of the managed repository to store to This makes the actions more specific to Archiva, so might need to come up with something easier to work with there so we don't diverge from what is used in Continuum.
          Hide
          James William Dumay added a comment -

          Move to 1.1.x

          Show
          James William Dumay added a comment - Move to 1.1.x
          Hide
          James William Dumay added a comment -

          Moving to 1.2

          Show
          James William Dumay added a comment - Moving to 1.2

            People

            • Assignee:
              James William Dumay
              Reporter:
              Joakim Erdfelt
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: