Hi,

If anyone is still interested in this thread, I came up with a neat solution to get around this problem since Atlassian said it's not in their priority list to get this implemented/fixed.

The issue is : "how do you upgrade without loosing your sensitive configuration files while being able to view/retain new configuration changes".

I'm assuming that your apps are deployed in /opt/atlassian/atlassian-appname where "appname" is "confluence|jira|bitbucket|crowd|fisheye"
I'm also assuming that you have the Oracle JVM installed through your package manager. If using Debian/Ubuntu, look at https://launchpad.net/~webupd8team/+archive/ubuntu/java

First step, run "git init" in /opt/atlassian and use the following .gitignore gitignore.txt
Step two, get git to control all your configuration files
Step three, stop using the binary distributions as provided by Atlassian. Only use the zip/tar.gz instead which does not contain the JVM. Stop your application, move the folder to an archive/backup folder somewhere, uncompress the zip/tar.gz and put it at the same place
Step four, use git to review the changes
Step five, start your application to finish the upgrade process

I had a server.xml which was modified in our installation but replaced by the upgrade to 5.9.7.
It took me and an Atlassian Support person a few hours to discover this issue.
The install script already highlights changed files, so it should also use them instead of replacing them.

Wow, issue was opened in 2011? I agree that this should be handled like a bug. It is only because of my distrust of all technology that I did my own diffs after the install and discovered the server.xml omission.

And why is this still unassigned? This should be handled like a bug.

I agree. This needs to be worked on. It leaves a really bad impression if you have to recreate/change your SSL config (for example) every time Confluence is upgraded. Sometimes I think that Atlassian thinks their users are tomcat administrators. We are not. We are Confluence users and I actually expect a product I pay for to take care of these things for me. SSL config should be "set it and forget it". And it should be much easier than it is today.

I'm with Drew on this one - most customers should be running SSL at a minimum - which means that at a minimum most of your customers will have changed server.xml, web.xml and possibly have a .keystore in the directory structure. I don't think it's programmatically infeasible to diff the old vs new configurations and look for changes to certain types of areas, and make a call about how to change them. I understand that maybe the customer is running the WAR in their own Tomcat instance etc etc etc - but if we're running the atlassian installer, upgrading an atlassian instance to new-atlassian instance, then you should be able to do some of the lifting - and if things don't work or it can't work it out - flag it at that step.

The other thing that would make it easier from a sysadmin perspective would simply be saving the old files as server.xml.orig or something like that, in the same location - so that you can stumble across them easily rather than working out that you're missing something and then wandering around until you find the files you're looking for.

Another thought would be:

• If the user has changed these files, and the installer detects it - don't start the new instance - instead prompt the user with a warning at the completion of the upgrade, telling them to go find files (x,y,z) and merge any required changes before starting the daemon again.

I understand there are many different implementations that people utilize but the installer should at least understand 1 or 2 instead of none (e.g. replace files). Even if I moved to apache auth, the files it is replacing are still incorrect (keystore location, pass, etc.).

How about the other 4 items I mentioned, were those discussed? The two linked tickets only address part 2 of item #1.

Hi Drew,

We have had a fair bit of discussion around this see the linked issue (JRA-25277). There are a number of challenges with this, such as Tomcat's server.xml may change from version to version therefore we cannot just copy the old ones.

One suggestion around the SSL configuration is to use Apache for SSL rather than Tomcat. This greatly simplifies the custom Tomcat configuration needed and lets the connection between Tomcat and Apache be simple HTTP.

Using a WAR version of JIRA or Confluence might also be an option to simplify upgrades. That said, you would need to manage upgrading Tomcat periodically to ensure continued compatibility with Atlassian products, so that might only be prolonging the same problem.

Thanks,
Donna