I am working on a script where I am creating VM and assigning available IP address to it given by concerned team. I need to integrate Infoblox API functionality with this
Once the IP is assigned,
I have to find the status of that particular IP address and
This part I got the request
https://url/wapi/v2.10.5/ipv4address?ip_address=10.1.0.0
Update the status of that IP from "Unused" to "Used".
Can you please help me with this. Need the API request to modify the status value against IP address
Sample API Response
[
{
"_ref": "ipv4address/Li5pcHY0X2FkZHJlc3MkMTAuMTI0LjExLjIvMA:10.1.1.2",
"ip_address": "10.1.1.2",
"is_conflict": false,
"mac_address": "",
"names": [],
"network": "10.1.1.0/7",
"network_view": "default",
"objects": [],
"status": "UNUSED",
"types": [],
"usage": []
}
]
I was trying a PUT request like below
``` https://url/wapi/v2.10.5/record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmNvbS5pbmZvLndhcGlhbGlhcw:10.124.11.2/default?_return_fields%2B=aliases&_return_as_object=1" -d '{"status": ["Used"]}'
```
but it is giving error
**{
"Error": "AdmConProtoError: Invalid value for _return_as_object: 1\" -d '{\"status\": [\"Used\"]}'",
"code": "Client.Ibap.Proto",
"text": "Invalid value for _return_as_object: 1\" -d '{\"status\": [\"Used\"]}'"
}**
Related
I have ELK cloud v. 7.13.2 and trying to create alert rule with slack action via REST API. This is my curl invocation:
curl -u ****** -s -H 'kbn-xsrf: true' -H 'Content-Type: application/json' https://***********.westeurope.azure.elastic-cloud.com:9243/api/alerting/rule -X POST -d #src/rules/cpu_utilization.json
I am expecting that new rule is created, but unfortunately I am getting following error:
{
"statusCode": 400,
"error": "Bad Request",
"message": "Invalid action groups: default"
}
The contents of src/rules/cpu_utilization.json are:
{
"params": {
"nodeType": "host",
"criteria": [
{
"comparator": ">",
"timeSize": 1,
"metric": "cpu",
"threshold": [
80
],
"timeUnit": "m"
}
],
"sourceId": "default"
},
"consumer": "alerts",
"schedule": {
"interval": "1m"
},
"tags": [],
"name": "CPU2",
"throttle": "1000d",
"enabled": true,
"rule_type_id": "metrics.alert.inventory.threshold",
"notify_when": "onThrottleInterval",
"actions": [
{
"group": "default",
"id": "fce4c27f-d22a-4209-858c-253a06511c1b",
"params": {
"message": "{{alertName}} - {{context.group}} is in a state of {{context.alertState}}\n\nReason:\n{{context.reason}}"
}
}
]
}
Documentation says clearly:
Properties of the action objects:
group
(Required, string) Grouping actions is recommended for escalations for different types of alerts. If you don’t need this, set this value to default.
Is this a bug in ELK or I am doing something wrong? I am able to use API for other purposes, like listing rules, deleting rules etc. I am also capable of creating a rule without an action, but this doen`t seem to be too useful...
OKAY, I got an answer from ELK support. Apparently, you can use another endpoint to list all rule types GET /api/alerting/rule_types. Then you need to find your type and lookup property default_action_group_id - it will hold the correct value. Eg. in the above example it was:
"default_action_group_id": "metrics.inventory_threshold.fired"
For some reason, I keep getting these weird issues.....
In this case, I have a Key and Endpoint URL for the Automation Account stored as Secrets in a KeyVault (I don't know of a away to extract it natively from Automation Account using ARM).
I can extract these values perfectly and they they are published to the Template that runs a PowerShell extension to pull a DSC Configuration.
For example as seen as an Input deploying the Template:
"RegistrationUrl":"https://ase-agentservice-prod-1.azure-automation.net/accounts/e0799801-a8da-8934-b0f3-9a43191dd7e6"
However, I receive the following error (note the Url in the Error with 3 forward slashes)
"code": "VMExtensionProvisioningError",
"message": "VM has reported a failure when processing extension 'dscLcm'.
Error message: "DSC Configuration 'ConfigureLCMforAAPull' completed with error(s). Following are the first few: The attempt to 'get an action' for AgentId 11A5A267-6D00-11E7-B07F-000D3AE0FB1B from server URL https://ase-agentservice-prod-1.azure-automation.net///accounts/e0799801-a8da-8934-b0f3-9a43191dd7e6/Nodes(AgentId='11A5A267-6D00-11E7-B07F-000D3AE0FB1B')/GetDscAction failed with server error 'ResourceNotFound(404)'.
For further details see the server error message below or the DSC debug event log with ID 4339.
ServerErrorMessage:- 'No NodeConfiguration was found for the agent.'\"."
The Endpoint Url is passed as a Secure String. I tried passing it a normal string - Same problem.
The Key and Endpoint are feed into the Template as Parameters:
"dscKeySecret": {
"type": "securestring",
"metadata": {
"description": "Key for PowerShell DSC Configuration."
}
},
"dscUrlSecret": {
"type": "securestring",
"metadata": {
"description": "Url for PowerShell DSC Configuration."
}
},
These values are used to create a parameter to be passed to the next template that runs the VM Extension.
"extn-settings": {
"value": {
"configuration": {
"url": "[concat(variables('urls').dscScripts, '/', 'lcm-aa-pull', '/', 'lcm-aa-pull', '.zip')]",
"script": "[concat('lcm-aa-pull', '.ps1')]",
"function": "ConfigureLCMforAAPull"
},
"configurationArguments": {
"registrationKey": {
"username": "dsckeySecret",
"password": "[parameters('dscKeySecret')]"
},
"registrationUrl": "[parameters('dscUrlSecret')]",
"configurationMode": "ApplyAndMonitor",
"configurationModeFrequencyMins": 15,
"domain": "[variables('names').domain]",
"name": "dscLcm",
"nodeConfigurationName": "[variables('names').config.ad]",
"rebootNodeIfNeeded": true,
"refreshFrequencyMins": 30
},
"protectedSettings": null,
}
}
The next template receives the Parameters and used in the Properties of the VM's Resources section:
"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.22",
"autoUpgradeMinorVersion": true,
"settings": {
"configuration": "[parameters('extn-settings').configuration]",
"configurationArguments": "[parameters('extn-settings').configurationArguments]"
},
"protectedSettings": "[parameters('extn-settings').protectedSettings]"
}
So why is the Url being corrupted with the the first '/' being changed to '///'?
I don't why the Endpoint Url has 3 x '/', but that wasn't the issue.... I wish I found the issue before I posted this question...
I found the Node Configuration Name was wrong with a spelling mistake (hang head in shame)
Thanks anyway!
Recently I build presto with cluster mode, 1 coordinator & 1 worker, it works.
Then I repackage "presto-main-0.148.jar" without any change , and replace it to production environment, it doesn't work! Always get response with "No worker nodes available"
I search the Server.log and see below messages:
ERROR Discovery-0 io.airlift.discovery.client.CachingServiceSelector Cannot
connect to discovery server for refresh (collector/general): Lookup
of collector failed for
ht*p://10.3.2.33:18080/v1/service/collector/general
ERROR Discovery-0 io.airlift.discovery.client.CachingServiceSelector Cannot
connect to discovery server for refresh (presto/general): Lookup of
presto failed for ht*p://10.3.2.33:18080/v1/service/presto/general
INFO Discovery-1 io.airlift.discovery.client.CachingServiceSelector Discovery
server connect succeeded for refresh (collector/general)
INFO Discovery-2 io.airlift.discovery.client.CachingServiceSelector Discovery
server connect succeeded for refresh (presto/general)
So I guess discover server is not started,But I use command curl "h*tp://10.3.2.33:18080/v1/service/collector/general",
and get response below, and I also get coordinator status as 'ACTIVE'
{
"environment": "presto_**_flt",
"services": [
{
"id": "954e886d-7506-4f00-b954-eeab49209835",
"nodeId": "4c0f2596-7e6e-11e6-ae22-56b6b6499611",
"type": "presto",
"pool": "general",
"location": "/4c0f2596-7e6e-11e6-ae22-56b6b6499611",
"properties": {
"node_version": "a0e36ae",
"coordinator": "false",
"http": "h*tp://10.3.2.24:18080",
"http-external": "h*tp://10.3.2.24:18080",
"datasources": "hive,system"
}
},
{
"id": "6790b522-cd17-48ef-b077-e4e8fa97e310",
"nodeId": "4c0f2366-7e6e-11e6-ae22-56b6b6499611",
"type": "presto",
"pool": "general",
"location": "/4c0f2366-7e6e-11e6-ae22-56b6b6499611",
"properties": {
"node_version": "c34bef3-dirty",
"coordinator": "true",
"http": "h*tp://10.3.2.33:18080",
"http-external": "h*tp://10.3.2.33:18080",
"datasources": ""
}
}
]
}
I think this is because that you have two different node_version in these two services.
If you are repackaging presto-main or any other component, make sure you are using the same binaries on all the nodes.
Zendesk API documentation states that when creating a ticket through the API, the status field can be set to "new" (https://developer.zendesk.com/rest_api/docs/core/tickets#create-ticket), yet if I call the API with the following command specifying a value for status, it creates a token yet still sets status to be the default value of open:
curl -u <username>/token:<api_token> https://<subdomain>.zendesk.com/api/v2/tickets.json -d '{"ticket": {"subject":"test subject", "comment": { "body": "test body" }, "status": "new" } }' -H "Content-Type: application/json" -v POST
The relevant part of the response body is:
"ticket": {
"url": "https://<subdomain>.zendesk.com/api/v2/tickets/60.json",
"id": 60,
"external_id": null,
"via": {
"channel": "api",
"source": {
"from": {},
"to": {},
"rel": null
}
},
"created_at": "2016-05-05T13:30:01Z",
"updated_at": "2016-05-05T13:30:01Z",
"type": null,
"subject": "test subject",
"raw_subject": "test subject",
"description": "test body",
"priority": null,
"status": "open",
"recipient": null,
"requester_id": 5917202647,
"submitter_id": 5917202647,
"assignee_id": 5917202647,
"organization_id": 3740197137,
"group_id": 28473587,
"collaborator_ids": [],
"forum_topic_id": null,
"problem_id": null,
"has_incidents": false,
"due_at": null,
"tags": [],
"custom_fields": [],
"satisfaction_rating": null,
"sharing_agreement_ids": [],
"fields": [],
"brand_id": 1090897,
"allow_channelback": false
}
Am I doing something wrong?
So it turns out that if you assign a ticket to a group with only one member/agent, the ticket automatically gets assigned to that lone agent. As such, any ticket that's already assigned to a specific agent, is automatically set to open instead of new.
Because I was using a test subdomain, I was the only agent and so it was auto-updating the status from "new" to "open".
Hmm, I made the same API call (with my creds/subdomain) and it worked, setting the "status" to any option I choose (new, pending, solved).
Have you confirmed that all your credentials and subdomain are correctly inputted? Also, check the API settings in your Zendesk account. Try creating a new token and Save the settings.
If the API token still doesn't work, maybe try authenticating with password or making the request by means other than curl.
I'm trying to add an ssh key via GitHub's v3 API, but it doesn't seem to be working.
What I'm doing is based on the instructions given here.
More specifically, I'm using the following:
KEY=$( cat ~/.ssh/id_rsa.pub )
TITLE=${KEY/* }
# the '/* ' above deletes every character in $KEY up to and including the last
# space.
JSON=$( printf '{"title": "%s", "key": "%s"}' "$TITLE" "$KEY" )
TOKEN=$( cat /path/to/tokenfile )
curl -s -d "$JSON" "https://api.github.com/user/keys?access_token=$TOKEN"
When I run the above, the response I get is:
{
"message": "Not Found"
}
...and, sure enough, when I check in my GitHub account, $KEY is not among the ssh-keys listed1.
What am I doing wrong?
Additional details
I get the same "message": "Not Found" response if I just run
curl -s "https://api.github.com/user/keys?access_token=$TOKEN"
If I replace the -s above with -i I see that, indeed, the returned status is 404 Not Found. And yet, the returned status for
curl -i "https://api.github.com/user/keys"
is 401 Unauthorized.
1 I know that the access token in $TOKEN is fine, and therefore it is not the reason for the "message": "Not Found" response, because
curl -s "https://api.github.com/user/repos?access_token=$TOKEN"
returns the correct information, and
curl -s "https://api.github.com/user/repos"
returns
{
"message": "Requires authentication"
}
Does your access token have "user" scope? A relevant excerpt from the docs:
Management of public keys via the API requires that you are authenticated through basic auth, or OAuth with the ‘user’ scope.
If your token does not have "user" scope, you will get a 404 response with a message of "Not Found".
To see the scopes associated with your tokens, use the "Authorizations" API:
curl -u <username> https://api.github.com/authorizations
In the example response below, the first authorization has "user" scope, but the second one does not.
enter code here
[
{
"id": 123,
"url": "https://api.github.com/authorizations/123",
"app": {
"name": "Foo",
"url": "https://foo.example.com/",
"client_id": "REDACTED-ID-1"
},
"token": "REDACTED-TOKEN-1",
"note": null,
"note_url": null,
"created_at": "2013-02-18T18:24:00Z",
"updated_at": "2013-05-06T14:17:00Z",
"scopes": [
"repo",
"user"
]
},
{
"id": 456,
"url": "https://api.github.com/authorizations/456",
"app": {
"name": "Bar",
"url": "https://bar.example.com/",
"client_id": "REDACTED-ID-2"
},
"token": "REDACTED-TOKEN-2",
"note": "for stuff",
"note_url": null,
"created_at": "2013-04-16T12:20:00Z",
"updated_at": "2013-05-13T21:28:00Z",
"scopes": [
"public_repo"
]
}
]
If you determine that this is the source of your problem, then you can resolve it in one of two ways:
Create a new token that has "user" scope, or
Update your existing token to add the "user" scope to it: "add_scopes": [ "user" ]
As of February 2014 the "user" scope no longer provides enough access to manage a user's SSH keys. The scope must be defined as:
read:public_key - provides read access to the user’s SSH keys
write:public_key - allows an app to read existing keys and create new ones
admin:public_key - enables an app to read, write, and delete keys