Using sonatype nexus 2.x, how do you get the sha1 or md5 hash of a file in a "site repository" (called "raw repositories" in nexus 3) using curl?
There is a related question on SO, however it only applies to "maven" repositories, which has a different api endpoint.
Take the download link and append ?describe=info
curl -H "Accept:application/json" \
"http://nexus.example.com/nexus/service/local/repositories/foobar/content/master-5678.zip?describe=info"
The optional -H "Accept:application/json" curl flag returns json instead of xml
{
"data":{
"presentLocally":true,
"repositoryId":"foobar",
"repositoryName":"foobar",
"repositoryPath":"/master-5678.zip",
"mimeType":"application/zip",
"uploader":"bob",
"uploaded":1459458352000,
"lastChanged":1459458352000,
"size":715112200,
"sha1Hash":"d18dd27f4814e0898df98e7aa47cc08c477dfabc",
"md5Hash":"ded916cf74e7dd97e698285c2880e7a8",
"repositories":[
{
"repositoryId":"foobar",
"repositoryName":"foobar",
"path":"/master-5678.zip",
"artifactUrl":"http://nexus.example.com/nexus/content/repositories/foobar/master-5678.zip",
"canView":true
}
],
"canDelete":false
}
}
Thanks to Rich # sonatype support.
Related
So I am using vault approle with airflow as secret backend and it keeps throwing permission denied error on $Vault_ADDR/v1/auth/approle/login. I tried using approle from CLI like:
vault write auth/approle/login role_id="$role_id" secret_id="$secret_id"
and it works fine.
But if I try it using API:
curl --request POST --data #payload.json $VAULT_ADDR/v1/auth/approle/login
where payload.json contains secret and role id. It fails with permission denied.
Here is my policy:
vault policy write test-policy -<<EOF
path "kv/data/airflow/*" {
capabilities = [ "read", "list" ]
}
EOF
It works fine for reading on this path.
and role:
vault write auth/approle/role/test-role token_ttl=4h token_max_ttl=5h token_policies="test-policy"
Don't know why it is failing with API.
An important thing to mention is that I am using cloud based HCP Vault.
The problem is with your app_role authentication.You need to provide admin namespace in your url.
Change this:
curl --request POST --data #payload.json $VAULT_ADDR/v1/auth/approle/login
To this:
curl --request POST --data #payload.json $VAULT_ADDR/v1/admin/auth/approle/login
Furthermore, if you are trying to access from a third party tool like airflow then try adding "namespace=admin" in your config file.
Found the problem. HCP vault uses namespace (default = admin). Namespace was needed in url :
$VAULT_ADDR/v1/admin/auth/approle/login
but the problem still exists in Airflow's Hashicorp provider. Changing the auth_mount_point still concatenates it at the end as :
$VAULT_ADDR/v1/auth/{$auth_mount_point}
I'm trying to update the property of an artifact(In my case sample text file)
I tried the API https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-UpdateItemProperties
this is what I tried:
curl -X PATCH -uadmin:password -H '"props":{"ccs_x1_version":
"7.7.7.7"}'
"http://XXXXXXXXX:8081/artifactory/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
but was not successful, as command returns nothing, can someone help me in figuring out the right usage.
Looks like you're missing the API endpoint for using the UpdateItemProperties. You're also sending the data as malformed JSON as a header rather than data.
You need to add the endpoint: /api/metadata/ and reformat your data to a proper JSON.
{
"props" : {
"ccs_x1_version": "7.7.7.7"
}
}
According the the link provided:
Since: 6.1.0
Security: Requires a privileged user (Annotate authorisation required)
Usage: PATCH /api/metadata/{repoKey}/{itemPath}?[&recursive=1]
Produces: application/json
Sample Usage:
PATCH /api/metadata/libs-release-local/org/acme?[recursive=1]
{
"props":{
"newKey": "newValue",
"existingKey": "modifiedValue",
"toBeRemovedKey": null
}
}
If you update your request to curl -X PATCH -uadmin:password -d '{"props":{"ccs_x1_version": "7.7.7.7"}}' "http://XXXXXXXXX:8081/artifactory/api/metadata/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
This is also a new rest endpoint which is only available with the latest version of artifactory 6.1.0. If you're running an older version you're going to have to use the previous endpoint (Set Item Properties) in the official JFrog Documentation.
This is formatted curl -X PUT -uadmin:password "http://XXXXXXXXX:8081/artifactory/api/storage/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt?properties=ccs_x1_version=7.7.7.7"
Artifactory OSS
5.4.6 rev 50406900
Trying to get access token to work.
I created token...
e.g. curl -uadmin:adminpw -X POST "myserver:8081/artifactory/api/security/token" -d "username=moehoward"
Returned msg looks like success...
{
"scope" : "member-of-groups:readers api:*",
"access_token" : <very-long-string>
"expires_in" : 3600,
"token_type" : "Bearer"
}
I can see it in the gui (admin -> Security -> Access Tokens) with "Subject" = to the user ("moehoward" in the example above) and with a "Token ID" that's a lot shorter, something like...
f2eb693a-d4ff-4618-ba52-764dc975c497
To test, I tried to ping using example in the docs...
curl -umoehoward:<very-long-string> myserver:8081/artifactory/api/system/ping
Fails with a 401 (bad credentials).
I replace the token with the "token id" I see in the gui, same result.
I replace again with the hardcoded pw of the "moehoward" user and that works (responds with "OK").
I tried the "-H"Authentication: Bearer " approach using the long string and that worked. So I guess the very long string is the token and not the "Token ID" in the gui.
Q: Any idea why this works for Bearer" and not the user by name ?
So you are right that this is supposed to work for both standard authentication and the Authentication HTTP header.
I did the test on a server with the same version Artifactory OSS 5.4.6 and the following works fine here
Inject the proper variables
export SERVER=server-artifactory
export APIKEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Create and use an access token for user moehoward
curl -u "admin:$APIKEY" -X POST "http://$SERVER/artifactory/api/security/token" -d "username=moehoward" -d "scope=member-of-groups:readers" > token.log
export TOKEN=`cat token.log | jq -r '.access_token'`
curl -u "moehoward:$TOKEN" "http://$SERVER/artifactory/api/system/ping"
curl -H "Authorization: Bearer $TOKEN" "http://$SERVER/artifactory/api/system/ping"
I get "OK" from the last two commands. Can you run exactly these commands and report back?
I have personally experienced the same problem (Bearer header working, standard user credentials not working) with an old version of curl. The obvious workaround is to use Bearer, the more complex workaround is to upgrade curl (or use another tool).
What is the version of curl you use? Any curl from 2015 or more recent should work fine.
I am trying to push my zip files into Artifactory using CURL requests, but I get a status 409 error saying old metadata notation not supported anymore.
Can anyone point to correct documentation or way to do this?
root#84ddb6dc0dff:
curl -uadmin:AP6uUoG1o25Butgo7VfzRubufPB -T /myfilepath/MyZip.zip "http://My-Artifactory-Server/artifactory/MyGenericRepo/MyZip.zip"
{
"errors" : [ {
"status" : 409,
"message" : "Old metadata notation is not supported anymore: MyZip.zip"
} ]
I recently got a hubot setup for irc and works fine. I'm trying to add this script.
I'm not entirely understanding the setup instructions however. The setup instructions read
curl -H "Authorization: token <your api token>" \
-d '{"name":"web","active":true,"events":["pull_request"],"config":{"url":"<this script url>","content_type":"json"}}' \
https://api.github.com/repos/<your user>/<your repo>/hooks
I don't understand what the "url":"<this script url>" refers to. Anyone know?
I'm deploying to heroku if that helps.
Add more explanation for #MikeKusold 's answer
The curl command is to create the github hook, therefore it is set hook to the receiver for the notification.
"config": {
"url": "http://example.com/webhook",
"content_type": "json"
}
The hook is the hubot plugin, so the url path is defined in that script, see line
robot.router.post "/hubot/gh-pull-requests", (req, res) ->
Below two lines in that scripts tell you what is after the path, it has parameters room & type
user.room = query.room if query.room
user.type = query.type if query.type
Hubot itself define the port number, it route the path to the plugin as it requested, check this part in robot.coffee, the default port is 8080
Therefore the URL is like below
http://<your hubot sever>:8080/hubot/gh-pull-requests/?room=<room>&type=<type>
Actually you can use curl command to test it towards hubot directly first.
Add <HUBOT_URL>:<PORT>/hubot/gh-pull-requests?room=<room>[&type=<type>] url hook via API
That is the URL