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.
I have https://packages.cloud.google.com/yum configured as a remote repo in Artifactory.
My repo file on Centos 7.3 looks like this:
[kubernetes]
name=kubernetes
baseurl=https://artifactory.company.com/artifactory/packages.cloud.google.com-yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
When I run yum install -y kubelet it prints this error:
e7a4403227dd24036f3b0615663a37 FAILED
https://artifactory.company.com/artifactory/packages.cloud.google.com-yum/repos/kubernetes-el7-x86_64/../../pool/e7a4403227dd24036f3b0615663a371c4e07a95be5fee53505e647fd8ae58aa6-kubernetes-cni-0.5.1-0.x86_64.rpm: [Errno 14] HTTPS Error 500 - Internal Server Error
Trying other mirror.
I am pretty sure the problem is the relative path in the URL: kubernetes-el7-x86_64/../../pool
If I wget the URL it works fine because wget is resolving out the relative path before sending the HTTP request, but yum does not do this and Artifactory returns a 500 when you give it a url with ../ in it. Does anyone know how to enable relative URLs in Artifactory? Or how to get yum to resolve URLs before sending the requests?
I am running these versions:
Artifactory 5.2.0
Yum 3.4.3-150
Update: This is the HTTP response body from artifactory:
{
"errors" : [ {
"status" : 500,
"message" : "Could not process download request: Path element cannot end with a dot: packages.cloud.google.com-yum-cache/repos/kubernetes-el7-x86_64/../"
} ]
}
The remote repository should be set with the following url in Artifactory
https://packages.cloud.google.com/yum/
The baseurl on the yum client should point on the repodata folder with the following:
baseurl=http://artifactory.company.com/artifactory/yum-remote/repos/kubernetes-el7-x86_64/
(The name of the remote repository is 'yum remote')
This should work without any further configuration from the Artifactory side.
The error you have mentioned regardin the relative path 'kubernetes-el7-x86_64/../../pool' happens during the caching of the artifact.
Artifactory cannot cache to a path which contains the '..' pattern so the request is failing.
It can be solved from Artifactory side with a user plugin.
If the path contains the '..' pattern then the plugin will modify the path where the artifact will cached so it will not include this pattern.
This is now redundant as the registry retrieves paths which doesn't include '..' in them.
I use the Jenkins Artifactory plugin. Artifactory is installed beside Nginx server. Sometimes, Jenkins return an error on upload:
[main] ERROR org.jfrog.build.extractor.maven.BuildInfoClientBuilder - Failed while reading the response from: PUT https://XXXX.XXX/XX-XXXXXXX-XXX/com/XXXX/XXXX/xxxxxxxx/xxxxxxx-api/1.0.0-SNAPSHOT/xxxxxxx-api-1.0.0-SNAPSHOT-jar-with-dependencies.jar;build.timestamp=1457104033410;build.name=xxxxxxx-build;build.number=75 HTTP/1.1
org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
This error is only when the file is larger then a specific size.
This problem is an Nginx problem. When I try to use "PUT" action from an other software (ex : DNC), I have an Nginx error message, not Artifactory. This is why Artifactory is unable to understand it.
PUT https://XXXX.XXX/XX-XXXXXXX-XXX/com/XXXX/XXXX/xxxxxxxx/xxxxxxx-api/1.0.0-SNAPSHOT/xxxxxxx-api-1.0.0-SNAPSHOT-jar-with-dependencies.jar;build.timestamp=1457104033410;build.name=xxxxxxx-build;build.number=75 HTTP/1.1
Result:
<html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.8.1</center>
</body>
</html>
You need to increase the client_max_body_size in your Nginx config file: /etc/nginx/nginx.conf
# set client body size to 500M #
client_max_body_size 500M;
500M represents the maximum size of your artifact you need to upload.
more informations here: http://www.cyberciti.biz/faq/linux-unix-bsd-nginx-413-request-entity-too-large/
I'm using following documentation to configure private Docker Registry in Artifactory Cloud.
I've configured Docker Registry from UI with V2 API and force authentication.
Let's skip reverse proxy configuration for now. I'm trying to call artifactory directly to verify if it works:
curl --user test:test --connect-timeout 5 http://myaccountname-docker-dockerv2-local.artifactoryonline.com/artifactory/api/docker/dockerv2-local/v2/_ping
Notes:
test - username and password
myaccountname - my account name in Artifactory Cloud
dockerv2-local - created docker registry repository (in Artifactory notation)
I've got response:
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
I tried to use:
myaccountname.artifactoryonline.com - the same result
and this
myaccountname.artifactoryonline.com:8080
myaccountname-docker-dockerv2-local.artifactoryonline.com:8080
myaccountname.artifactoryonline.com:8081
myaccountname-docker-dockerv2-local.artifactoryonline.com:8081
I got connection timeout.
I've spent a lot of time to figure out the root cause of this problem. I need you help, guys.
Can you tell me what I've done wrong? How to fix it? Or at least give me direction to look at.