upgrading artifactory from 5.5.2 to 5.6.0 fails during "emigration from artifactory to access" with:
2017-11-17 11:27:38,614 [art-init] [INFO ] (o.a.s.a.e.AccessSecurityEmigratorImpl:42) - Starting emigration from artifactory to access
2017-11-17 11:27:39,485 [art-init] [ERROR] (o.a.c.ConvertersManagerImpl:216) - Conversion failed. You should analyze the error and retry launching Artifactory. Error is: HTTP response
status 403:{
"errors" : [ {
"code" : "FORBIDDEN",
"message" : "Logged in 'jfac#01btna61r80s0n0y2ydfda1tyy/users/admin' is not an admin."
} ]
}
After restart, all user permissions and especially admin privileges are gone.
How do I restore previous user permissions or downgrade to previous version?
Worked around it by re-installing the previous version 5.5.2 and restoring all data and settings from backup.
see also:
https://www.jfrog.com/jira/browse/RTFACT-15289
Related
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
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.
2022-03-24T20:15:35.072Z [jfrt ] [WARN ] [2a73d62655afd1ad] [.r.ArtifactoryResponseBase:136] [http-nio-8081-exec-9] - Sending HTTP error code 500: Could not process download request: Binary provider has no content for '165c79f8dff2f9e7d3ccadcbc295f7ef8e6e95f0'
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.
When a team member restores nuget packages using donet, artifactory enters a loop with the errors below until the memory overflows.
The problem only happens when he adds in his Nuget.Config the tag protocolVersion="3"
<add key="Company" value="https://repo.company.com/artifactory/api/nuget/v3/rdi-nuget-virtual" protocolVersion="3" />
In the tests we noticed that the use of the protocolversion=3 tag causes this.
This tag is necessary because the download of the file is much faster
Anyone have an idea what it could be?
Could you help me please?
logs below
Version jfrog: 7.29.8 rev 72908900
2022-01-11T14:00:57.263Z [jfrt ] [WARN ] [6cdecc92eaf486c7] [.r.ArtifactoryResponseBase:136] [ttp-nio-8081-exec-43] - Sending HTTP error code 403: Download request for repo:path 'nuget-remote-cache:.nuGetV3/feed.json' is forbidden for user: 'lcunha'.
2022-01-11T14:00:57.264Z [jfrt ] [ERROR] [6cdecc92eaf486c7] [etV3VirtualAndRemoteCommon:274] [ttp-nio-8081-exec-43] - Failed to download resource in repo: nuget-remote, at url: https://api.nuget.org/v3/index.json. HTTP STATUS CODE: 403
2022-01-11T14:00:57.264Z [jfrt ] [ERROR] [6cdecc92eaf486c7] [etV3VirtualAndRemoteCommon:133] [ttp-nio-8081-exec-43] - Failed to convert artifactory url (https://repostaging.companysoftware.com:443/artifactory/api/nuget/v3/company-nuget-virtual/registration-semver2) to original remote url for repo: nuget-remote, package: xunit.core
java.lang.NullPointerException: null
at java.base/java.util.Objects.requireNonNull(Objects.java:221)
2022-01-11T14:01:56.786Z [jfrou] [ERROR] [2016c910242342cc] [external_topology.go:82 ] [main ] - Failed fetching external topology from Access: Get "http://localhost:8040/access/api/v1/topology": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2022-01-11T14:02:04.871Z [jfrou] [WARN ] [7f3fb3a30ade9665] [local_topology.go:268 ] [main ] - Readiness test failed with the following error: "required node services are missing or unhealthy"
2022-01-11T14:02:09.877Z [jfrou] [ERROR] [7f3fb3a30ade9665] [local_topology.go:128 ] [main ] - periodic send heartbeat failed for 4 consecutive times. Last error: failed sending heartbeat information to Access: failed closing Access grpc client: closing heartbeat client and waiting for response timed-out
java.lang.OutOfMemoryError: Java heap space
-XX:OnOutOfMemoryError="kill -9 %p"
Executing /bin/sh -c "kill -9 3974"...
2022-01-11T14:02:11.185Z [jfrou] [WARN ] [5a89519a8048b91d] [local_topology.go:268 ] [main ] - Readiness test failed with the following error: "required node services are missing or unhealthy"
2022-01-11T14:02:11.196Z [jfrou] [ERROR] [79bb63bc55c1ed15] [external_topology.go:82 ] [main ] - Failed fetching external topology from Access: Get "http://localhost:8040/access/api/v1/topology": read tcp 127.0.0.1:55970-127.0.0.1:8040: read: connection reset by peer
2022/01/11 14:02:11 httputil: ReverseProxy read error during body copy: read tcp 127.0.0.1:56788->127.0.0.1:8045: read: connection reset by peer
2022/01/11 14:02:11 httputil: ReverseProxy read error during body copy: read tcp 127.0.0.1:56788->127.0.0.1:8045: read: connection reset by peer
2022/01/11 14:02:11 httputil: ReverseProxy read error during body copy: read tcp 127.0.0.1:56788->127.0.0.1:8045: read: connection reset by peer
2022-01-11T14:02:11.208Z 35[jfob ] [WARN ] [1ed879c85a5af005] [access_join.go:70 ] [main ] - Refreshing platform config change events gRPC stream - target server is unavailable - if issue persists check communication with access [access_client]
/opt/jfrog/artifactory/app/bin/artifactory.sh: line 359: 3974 Killed $TOMCAT_HOME/bin/catalina.sh run
Can you share your setup?
-The application server is the CentOS Linux release 7.9.2009 (Core)
-MySQL as backend Database
-Also, we are using the Apache as reverse proxy to apply the SSL certificate.
How are you running Artifactory?
-The Artifactory is container based: releases-docker.jfrog.io/jfrog/artifactory-pro:7.29.8
How much resources to you give it? Memory and CPU
The server has allocated:
2 vCPU
16 GB RAM
SSD
What are the java memory settings? Mostly interested in heap settings (Xms and Xmx)?
We are using the standard configuration. No changes were made in the Xms and Xms parameters.
As you are using Artifactory v7.x? You may refer to our System Requirements wiki page for the recommended hardware based on your environment.
Also, from on the error message shared, it looks like the user does not have proper permissions hence we see 403 errors. Please do validate and assign the required permissions to the user and let us know the results.
Sending HTTP error code 403:
Download request for repo:
path 'nuget-remote-cache:.nuGetV3/feed.json' is forbidden for user: 'lcunha'.
I have created an AQL that gives me a number of artifacts I want to delete from Artifactory. I can run a search command with the jfrog-cli on it, and get the correct list of artifacts:
jfrog rt s --spec search-aql.json
When I try to delete the same artifacts with the same AQL, everything seems fine:
The artifacts are listed
I get a questions of whether to delete them or not.
I answer yes, and the command goes on to log the deletion of each item.
Each item seems to be returned and printed to my console, followed by this message:
[Error] Artifactory response: 200 OK
Binaries are also printed to the console, so the console output is really messy.
In the end, I get a summary:
{
"status": "failure",
"totals": {
"success": 0,
"failure": 68
}
}
[Error] Artifactory response: 200 OK
With the same user, I can delete individual artifacts using the REST API, so the user does have the necessary rights to do deletion.
I am on version 1.38.2 of the JFrog CLI and 7.2.1 of Artifactory.
Can anybody help me understand what is wrong or how to debug this problem?
Update 2020/08/06:
When setting the log level to debug as suggested by #Prostagma, I get two extra lines of logging for each artifact. Here is an example of logging for two artifacts:
[Info] [Thread 1] Deleting <path>/<artifact>.jar.sha512
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar.sha512
[Error] Artifactory response: 200 OK
<sha512 hash>
[Info] [Thread 0] Deleting <path>/<artifact>.jar
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar
[Error] Artifactory response: 200 OK
<binary contents of <artifact>.jar
More detailed answer to whomever encounter this issue in the future -
By diving into the code we can see that the CLI expects to get status 204 from Artifactory after deletion:
https://github.com/jfrog/jfrog-client-go/blob/v0.12.0/artifactory/services/delete.go#L110
In some installations, there may be a proxy that changes the response codes, for example when Artifactory returns 204, it may change the status code to 200.
Please make sure that your proxy doesn't change the status codes returned from Artifactory.
I am using an Artifactory server. I am trying to store a folder of third party files in my repo.
I was able to upload a zipfile and explode it so I have my files in MY_REPO/MY_FOLDER/
I am trying to recursively download the contents of the folder using:
jfrog rt dl --recursive MY_REPO/MY_FOLDER
I have enabled debug and I get:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","path": {"$ne": "."},"$or": [{"$and":[{"path": {"$match": "MY_FOLDER"},"name": {"$match": "*"}}]},{"$and":[{"path": {"$match": "MY_FOLDER/*"},"name": {"$match": "*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I have tried variations of MY_FOLDER, MY_FOLDER/, MY_FOLDER/. and with/without recursive. I get the same error.
I know I have permissions because I can upload a file:
jfrog rt u TEST_FILE MY_FOLDER
succeeds just fine. But I can't turn around and pull it down:
jfrog rt dl MY_FOLDER/TEST_FILE
results in:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","$or": [{"$and":[{"path": {"$match": "."},"name": {"$match": "MY_FILE"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I'm not certain what isn't working, there's nothing on StackOverflow, JFrog dox or elsewhere with issues using jfrog cli. :(
My jfrog-cli.conf looks like this:
{
"artifactory": [
{
"url": "https://SITE_NAME:PORT_NUM/artifactory/list/MY_REPO/",
"user": "USERNAME",
"serverId": "MY_REPO",
"isDefault": true,
"apiKey": "API_KEY_FROM_ARTIFACTORY"
}
],
"Version": "1"
}
UPDATED
I was running version 1.22.1 for Windows 64-bit. I am now using jfrog cli version 1.34.1 for Windows 64-bit. Per first comment I updated to the latest binary and tried running a search, both with and without MY_FOLDER:
jfrog rt s TEST_FILE and
jfrog rt s MY_FOLDER/TEST_FILE
Both return the same results. I enabled DEBUG and with the newer binary I actually seem to get two errors. The older binary just reported the 405 error. The newer one reports a 404 (Not Found) then reports the error as a 405 Method Not Allowed.
[Debug] Sending usage info...
[Info] Searching artifacts...
[Debug] Searching Artifactory using AQL query:
items.find({"$or":[{"$and":[{"repo":"TEST_FILE","path":{"$match":"*"},"name":{"$match":"*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","modified","created","property")
[Debug] Sending HTTP POST request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/search/aql
[Debug] Sending HTTP GET request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/system/version
[Debug] Artifactory response: 404 Not Found
{
"errors": [
{
"status": 404,
"message": "File not found."
}
]
}
[Error] Artifactory response: 405 Method Not Allowed
Which is still odd because I'm looking for a file I just uploaded. I even deleted the uploaded file and re-uploaded to verify the newer cli can still upload files. I tried a wildcard search to find all files but it returned the same error.
I can also see the file where it is supposed to be using the Artifactory web interface, and download the file and delete it. So Artifactory knows it's there and I have access to it. :-/
The url in your configuration should only contain the base url of Artifactory, i.e: "SITE_NAME:PORT_NUM/artifactory".
You should provide the directory path in the upload and download commands.
Use the ping command to verify your setup works, then progress from there.
BTW: The reason the upload works but download fails is by coincidence. The upload command just uses the upload REST API which expects a path (which you provided in your config), but the download command first sends a search request that does not expect a path, so it fails.
Since upgrading to 6.8.7 using the rpm on RHEL 7, using systemctl start artifactory fails
Looking in the log its failing at this point
2019-03-16 09:50:28,952 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-16 09:50:29,379 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-16 09:50:30,625 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:41) - Unrecognized ErrorsModel by Access. Original message: Failed on executing /api/v1/system/ping, with response: Not Found
2019-03-16 09:50:30,634 [art-init] [ERROR] (o.a.s.a.AccessServiceImpl:364) - Could not ping access server: {}
org.jfrog.access.client.AccessClientHttpException: HTTP response status 404:Failed on executing /api/v1/system/ping, with response: Not Found
Previously we would get
2019-03-13 09:56:06,293 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-13 09:56:06,787 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-13 09:56:24,068 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:360) - Got response from Access server after 17280 ms, continuing.
Any suggestions on debugging whether this access server has started ?
Further to this I found logs showing when it worked it used to start a jar file
2019-03-08 09:19:11,609 [localhost-startStop-2] [INFO ] (o.j.a.AccessApplication:48) - Starting AccessApplication v4.1.48 on hostname.nexor.co.uk with PID 5913 (/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-4.1.48.jar started by artifactory in /)
Now when i look I find /opt/jfrog/artifactory/tomcat/webapps/access/ is empty so there is no jar file to run
The rpm did deliver an access.war file and that is there
$ ls -l /opt/jfrog/artifactory/webapps
total 104692
-rwxrwxr-x. 1 root root 51099759 Mar 14 12:14 access.war
-rwxrwxr-x. 1 root root 56099348 Mar 14 12:14 artifactory.war
Is there some manual step I can run to expand this war file to get the jar (as you can guess I am not up on my java apps)
Eventually got it working by deleting the empty /opt/jfrog/artifactory/tomcat/webapps/access directory and a new one containing the required jar files got created.
Not sure why this happened but that got it working for me
I had similar problem on CentOS 7, the solution was downgrade the newly updated java packages by running this command:
yum downgrade java-1.8.0*
After that restart the artifactory:
systemctl restart artifactory
Try changing the port number under your tomcat\conf\server.xml from 8081 to a different, unused port. Then, restart the Artifactory service to ensure the change takes effect.