I’m in the process of upgrading and migrating Artifactory version 6.11 (zip install, housed on RH7) to the 7.35 version (housed on a new server and hostname, rpm install). I’m doing this on a cloned VM as a test, so the only thing that is different from our original system is the hostname. As the documentation recommends, I first upgraded 6.11 to 7.35 and everything seemed to go well. I followed the upgrade steps and the migration.sh script completed successfully.
The major issue I’m having is that when I go into Artifacts, the ‘url to file’ is bringing up a 502 Bad Gateway nginx error. It seems to me that a pointer is incorrect somewhere and I’m confused as to where it could be. The upgrade was successful, so I know the data is there, but Artifactory is not able to link to it properly.
Update/clarification: To improve my description: When I head into Application bar / Artifactory / Artifacts and select a repo from the left-hand column, the ‘url to file’ fails to load. I’m assuming this is the tree view?
On the server that is currently working, a url such as https://acme/artifactory/repo leads to a directory listing. However, on the new server, a url such as https://new-acme-server/artifactory/repo would lead to a 502 Bad Gateway or an nginx error if I use http (no cert is installed on the test VM, but is installed on the orignal server).
In v7.35, I went into the ‘http settings’ and switched the server provider as both nginx and apache (Tomcat was set as default) and while the site operated fine under both, the url to the repo files still fails with an nginx error, regardless of the server provider.
When I did a full system export of the original server, the documentation had me uncheck "Exclude data". I also exported the repos out as well and imported those in via a path. Everything seems to show up correctly just like on the original server, but I’m still unable to view a directory listing when I click on the url.
Could it be the location of the filestore being different? If so, how would I go about pointing it to the right location?
V7.35: /opt/jfrog/artifactory/var/data/artifactory/filestore
V6.11: /opt/artifactory/artifactory-pro-6.11.3/data/filestore
The base URL is the same as the original installation http(s)://domain/artifactory
Output from artifactory-service.log
2022-03-25T16:58:40.429Z [jfrt ] [INFO ] [3bb67ba1f30d560e] [ifactoryApplicationContext:564] [ttp-nio-8081-exec-10] - Artifactory application context set to READY by reload
2022-03-25T16:58:40.430Z [jfrt ] [INFO ] [3bb67ba1f30d560e] [c.CentralConfigServiceImpl:933] [ttp-nio-8081-exec-10] - Configuration reloaded.
2022-03-25T17:09:04.013Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:914] [http-nio-8081-exec-5] - Reloading configuration... old revision 212, new revision 213
2022-03-25T17:09:04.121Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:542] [http-nio-8081-exec-5] - New configuration with revision 213 saved.
2022-03-25T17:09:04.121Z [jfrt ] [INFO ] [708a8ae7c307ec92] [ifactoryApplicationContext:564] [http-nio-8081-exec-5] - Artifactory application context set to NOT READY by reload
2022-03-25T17:09:04.181Z [jfrt ] [INFO ] [708a8ae7c307ec92] [ifactoryApplicationContext:564] [http-nio-8081-exec-5] - Artifactory application context set to READY by reload
2022-03-25T17:09:04.181Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:933] [http-nio-8081-exec-5] - Configuration reloaded.
2022-03-25T17:36:47.707Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [aseBundleCleanupServiceImpl:84] [art-exec-20 ] - Starting to cleanup incomplete Release Bundles
2022-03-25T17:36:47.708Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [b.ReleaseBundleServiceImpl:415] [art-exec-20 ] - Finished deleting orphan/unidentified items from _intransit repository
2022-03-25T17:36:47.709Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [aseBundleCleanupServiceImpl:90] [art-exec-20 ] - Finished incomplete Release Bundles cleanup
2
Answers
Your filestore location for both Artifactory 6 and Artifactory7 is correct.
This indicates to me that the issue is with your reverse proxy.
In order to confirm, can you check the below two things.
Open your Artifactory on its IP and Port.
http://localhost:8082/ (The default port will be 8082 if you have not modified). Now go to tree view in Application tab of Artifactory and try to download a specific file. If you are able to download, then the issue is might not be with filestore or upgrade. Mostly it should be reverse proxy.
In that case, navigate to Artifactory > Administration > Artifactory > HTTP Settings > Genereate new settings > Place in reverse proxy and restart.
In the above test, if you are still not able to download, then check in the logs ($JFROG_HOME/artifactory/var/log/artifactory-service.log) if you are observing a message something similar to the below.
If yes, then it indicates that, Artifactory is not able to find the binary. If none of the above helped, post the log snippet from the above log file here while you are trying to download a file along with the file name.
For your update/clarification questions, please allow me to clarify.
In Artifactory 6.x Artifactory was acting as both the server and UI, therefore you could use the "http://acme/artifactory URL, however in Artifactory 7.x, Artifactory changed to work with multiple microservices, and the UI has moved to its own microservice (now it is named "Frontend"). You can try access the "Native Browser" by using this URL http://acme/ui/native/REPOSITORY/.
To add to the above and to Ganapathi’s reply, the URL for your Artifactory has changed from http://acme:8081/artifactory to http://acme:8082 since Artifactory is now utilizing the "router" (external port is 8082 and internal 8046) microservice to redirect all the requests to the respective microservices. You can check the full list here.
I hope this clarifies more.