I am trying to enable to Write_http plugin in collectd for Splunk, the problem is when I try to curl externally
curl http://10.xx.xxx.x:8088/services/collector/raw -H "Authorization: Splunk 2c396ad4-f518-416f-83cd-e37596228792" -d {"test":"value"}
It works. But when I do the same in
collectd plugin
<Plugin write_http>
<Node "node-http-1">
URL "http://10.xx.xxx.x:8088/services/collector/raw?channel=2c396ad4-f518-416f-83cd-e37596228792"
Header "Authorization: Splunk 2c396ad4-f518-416f-83cd-e37596228792"
Format "JSON"
Metrics true
StoreRates true
I get
[error] write_http plugin: curl_easy_perform failed with status 56: Recv failure: Connection reset by peer
is it because of the curl version of collectd?
Just check the port in global settings in http data inputs in splunk.
It must be 8080 by default. Change the port in collect.conf accordingly in write_http plugin.
Hope it works for you!
Related
I have a script that sends POST requests to Apache load balancer to change status_D parameter of the specified worker. This is supposed to enable or disable worker (0 - enable, 1 - disable).
This used to work, but not anymore. Script is in Perl, but I tried sending the same request using curl, same result - status does not change.
If I open load balancer web page in browser and change it from there - it works.
I even captured browser's POST request parameters from the Apache log, copied and pasted them into curl command, but it still did not work, which makes me think that parameters are fine, but perhaps something has changed in Apache or proxy_balancer_module recently? Apache version is 2.4.52.0.1.
In new versions you need to add the referer in the http request.
curl -s -o /dev/null -XPOST "http://${server}:${port}/${manager}?" \
-H "Referer: http://${server}:${port}/${manager}?b=${balancer}&w=${worker}&nonce=${nonce}" -d b="${balancer}" \
-d w="${worker}" -d nonce="${nonce}" -d w_status_D=1
I have problems to get Bearer access token in Jmeter. Problem's cause most probably is in
server authentication - do not really understand how to properly setup this in Jmeter.
curl consist of several parts:
curl -X POST -v https://xxxx.xxx.xx.lv/token -u
"d123c9e3-4e91-46db-931e-37e8a52b8c8d:0e7cb8ad50fe3686de05fcf46815abc0a9d7cd095c23f75446d933ccxyxy"
-d "grant_type=password" -d "username=xxxxxxx" -d "password=xxxxxx" -d "scope=scop"
I have tried to use HTTP AuthorizationManager, HTTP Request and HTTP Header Manager without any successful results. Any advices?
Thanks!
Tatjana
I think you should do something like:
HTTP Request sampler:
these protocol and Server Name bits can be moved to HTTP Request Defaults so you won't have to specify them for each and every HTTP Request sampler
HTTP Authorization Manager:
In general since JMeter 5.1 it's possible to create a test plan from curl command line, the option lives under "Tools -> Import from cURL" main menu entry:
I'm trying to use Kubernetes API from inside a pod. Going to list/watch pods and custom defined resources.
Construct url as "https://KUBERNETES_SERVICE_HOST:KUBERNETES_SERVICE_PORT_HTTPS"
Authorization header = "Bearer /var/run/secrets/kubernetes.io/serviceaccount/token"
CaCert = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
When running inside minikube, the request fails with "Error: connect ETIMEDOUT 10.96.0.1:443"
Same code running in GCP fails with: "Error: unable to verify the first certificate"
If you are using curl, you can skip certificate checks with the -k flag.
Try
curl -k https://10.96.0.1:443/api/v1/namespaces -H "Authorization: Bearer <content of /var/run/secrets/kubernetes.io/serviceaccount/token here>"
In the code I inherited there is a REST call that sets up user permissions for a virtual host in a rabbitmq installation. On my developer box I have latest RabbitMQ server installed, 3.7.7. The client software uses a Spring RestTemplate to query the host. It generates a PUT request to http://localhost:15672/api/permissions/myhost/administrator with a payload of
{"read":".*","write":".*","configure":".*"}
and an HTTP header Content-Type:application/json;charset=UTF-8
This all looks reasonable to me - but the response is
HTTP/1.1 415 Unsupported Media Type
This code is years old, and I suspect it is my RabbitMQ installation that is too new for it, but I'd like to rather make the code future-proof than to install an RabbitMQ from 2015 ...
I have googled extensively on this issue but all I found was some bug about doubled headers in the rabbitmq client software that is not in use here. I traced it into apache httpclient classes and there is nothing on the sender side that smells.
Any suggestions what is wrong?
It turned out that the Apache HttpClient was adding a second content-type header to the message, caused the rejection on RabbitMQ Management plugin.
Yes, content type should not be applied
curl -s -i -u guest:guest -H "content-type: application/json" -H "content-type: application/json" -X POST --data '{"properties":{"delivery_mode":2},"routing_key":"program.*","payload":"{\"id\":\"123456\"}","payload_encoding":"string"}' 'http://127.0.0.1:15672/api/exchanges/%2F/my-exchange/publish'
return HTTP/1.1 415 Unsupported Media Type
Without content-type or just one :
curl -s -i -u guest:guest -H "content-type: application/json" -X POST --data '{"properties":{"delivery_mode":2},"routing_key":"program.*","payload":"{\"id\":\"123456\"}","payload_encoding":"string"}' 'http://127.0.0.1:15672/api/exchanges/%2F/my-exchange/publish'
return HTTP/1.1 200 OK
I started a fuseki sever with the command:
./fuseki-server --gzip=yes --update --loc=DB /dataset
Then, after posting some data, I tried to download the gzipped content with the command:
curl -X GET \
-H "Accept: application/x-gzip" \
-H "Accept-Encoding: gzip" \
http://localhost:3030/dataset
But the content was not gzipped. Do I need additional headers/configuration to make gzipping work?
The standalone Fuseki 2.4.0 does not support gzip encoding in the standalone server. The feature seems to have got lost at some time.
Recorded as:
https://issues.apache.org/jira/browse/JENA-1200
You can set it if you use the Fuseki WAR file by configuring Apache Tomcat or Eclipse Jetty or other webapp container server.