I am trying to use jenkins api on localhost, but the jenkins server is sending "Empty reply from server". Any idea what's wrong ?
curl http://localhost:8080/job/test/lastBuild/api/json?token=testing -v
* About to connect() to localhost port 8080 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /job/test/lastBuild/api/json?token=testing HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.2
> Host: localhost:8080
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection #0
I found the reason, httpport was set to "-1" because of which jenkins was sending an empty reply.
Before -
JENKINS_ARGS="--httpPort=-1"
After -
JENKINS_ARGS="--httpPort=65530"
Related
I have Linux EC2 instance when i am trying to download a file but getting 403
wget https://plugins.gradle.org/m2/org/springframework/data/spring-data-releasetrain/Moore-
SR1/spring-data-releasetrain-Moore-SR1.pom
Above giving me me HTTP 403 error.How should i trace where its blocking me to download ?
All proxies are set properly in my Ec2.
I tried traceroute but its not give me IPs. How to troubleshoot where its blocking me to download.
I have also open all outbound traffic in security group of EC2 but no luck.
Curl in debug mode give me below
$curl -v repo.jfrog.org
* About to connect() to proxy myproxy.xxx.com port 8080 (#0)
* Trying 1**.10*.**.**...
* Connected to myproxy.xxx.com (1**.10*.**.**) port 8080 (#0)
* Establish HTTP proxy tunnel to repo.jfrog.org:443
> CONNECT repo.jfrog.org:443 HTTP/1.1
> Host: repo.jfrog.org:443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 913
< X-RBT-SCAR: 10.1**.5.2**:1141466989:1000
<
* Received HTTP code 403 from proxy after CONNECT
* Connection #0 to host myproxy.xxx.com left intact
curl: (56) Received HTTP code 403 from proxy after CONNECT
I'm trying to run Jhipster Gateway (5.0 - springboot 2.0) as an executable war.
Per https://www.jhipster.tech/production/ and https://www.jhipster.tech/profiles/, I have:
Configured the production profile and built using
mvn -Pprod package
which looks to successfully build the war with the following directories:
META-INF/
org/
org/springframework/
org/springframework/boot/
org/springframework/boot/loader/
org/springframework/boot/loader/util/
org/springframework/boot/loader/jar/
org/springframework/boot/loader/archive/
org/springframework/boot/loader/data/
app/
content/
i18n/
swagger-ui/
swagger-ui/dist/
swagger-ui/dist/css/
swagger-ui/dist/images/
swagger-ui/dist/lib/
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/com/
WEB-INF/classes/com/cheetah/
WEB-INF/classes/com/cheetah/gateway/
WEB-INF/classes/com/cheetah/gateway/aop/
WEB-INF/classes/com/cheetah/gateway/aop/logging/
WEB-INF/classes/com/cheetah/gateway/client/
WEB-INF/classes/com/cheetah/gateway/config/
WEB-INF/classes/com/cheetah/gateway/config/apidoc/
WEB-INF/classes/com/cheetah/gateway/config/audit/
WEB-INF/classes/com/cheetah/gateway/config/ssl/
WEB-INF/classes/com/cheetah/gateway/domain/
WEB-INF/classes/com/cheetah/gateway/gateway/
WEB-INF/classes/com/cheetah/gateway/gateway/accesscontrol/
WEB-INF/classes/com/cheetah/gateway/gateway/ratelimiting/
WEB-INF/classes/com/cheetah/gateway/gateway/responserewriting/
WEB-INF/classes/com/cheetah/gateway/repository/
WEB-INF/classes/com/cheetah/gateway/security/
WEB-INF/classes/com/cheetah/gateway/security/oauth2/
WEB-INF/classes/com/cheetah/gateway/service/
WEB-INF/classes/com/cheetah/gateway/service/dto/
WEB-INF/classes/com/cheetah/gateway/service/mapper/
WEB-INF/classes/com/cheetah/gateway/web/
WEB-INF/classes/com/cheetah/gateway/web/rest/
WEB-INF/classes/com/cheetah/gateway/web/rest/errors/
WEB-INF/classes/com/cheetah/gateway/web/rest/util/
WEB-INF/classes/com/cheetah/gateway/web/rest/vm/
WEB-INF/classes/config/
WEB-INF/classes/config/liquibase/
WEB-INF/classes/config/liquibase/changelog/
WEB-INF/classes/i18n/
WEB-INF/classes/META-INF/
WEB-INF/classes/templates/
WEB-INF/lib/
META-INF/maven/
META-INF/maven/com.cheetah.gateway/
META-INF/maven/com.cheetah.gateway/gateway/
WEB-INF/lib-provided/
The application log shows it come up successfully (service is running on 7000)
java -jar gateway-0.0.1-SNAPSHOT.war --spring.profiles.active=prod
----------------------------------------------------------
Application 'gateway' is running! Access URLs:
Local: http://localhost:7000
External: http://192.168.222.33:7000
Profile(s): [prod]
----------------------------------------------------------
but when I try to hit 7000 from a browser, there is no response / UI
curl -v localhost:7000
* Rebuilt URL to: localhost:7000/
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7000 (#0)
> GET / HTTP/1.1
> Host: localhost:7000
> User-Agent: curl/7.50.3
> Accept: */*
>
* Curl_http_done: called premature == 0
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
However, I can get the UI to start on 9000 by running
yarn start
But I don't think this is required for a production environment. What am I missing? Thanks for your help.
Is there any command line API change in Debian 9 curl?
Recently I started to use Debian 9 (9.4, from Debian 8.x) and a script involving curl stopped working. I connect to internet through a squid proxy on localhost connected to a parent proxy.
My environment variables are configured like this
root#server:~# printenv | grep -i proxy
HTTP_PROXY=http://127.0.0.1:3128
FTP_PROXY=http://127.0.0.1:3128
https_proxy=https://127.0.0.1:3128
http_proxy=http://127.0.0.1:3128
HTTPS_PROXY=https://127.0.0.1:3128
ftp_proxy=http://127.0.0.1:3128
When I use wget, it works:
root#server:~# wget https://www.google.com.cu
--2018-03-14 09:08:53-- https://www.google.com.cu/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 11.12K --.-KB/s in 0.001s
2018-03-14 09:08:54 (14.9 MB/s) - ‘index.html’ saved [11389]
when I use curl, this is what I get
root#server:~# curl -v https://www.google.com.cu
* Rebuilt URL to: https://www.google.com.cu/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
I know these two commands are not equivalent, this is just to illustrate the HTTPS transfer problem.
I need to use curl because the script uses a web API, so it needs to use POST instead of GET request, and to set some headers and data to the POST request. (api.dropboxapi.com is the target site)
This all used to work on Debian 8 without a hitch, and besides wget WORKS, only curl is failing with the debian version change. All the other HTTPS clients seem unaffected (FF, Chrome, Edge, wget all seems to work as always)
Is there any workaround, fix, command line option change or whatever for making debian 9's version of curl work?
There must be a way, I can't conceive curl can't make a HTTPS connection to google. There must be a command line or something that allows the connection.
Output of "curl -V"
root#server:~# curl -V
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
Output of "curl --insecure" as suggested
root#server:~# curl --insecure -v https://www.google.com.cu
* Rebuilt URL to: https://www.google.com.cu/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
"curl -v https://www.google.com.cu --sslv2" output
root#server:/etc/squid# curl -v https://www.google.com.cu --sslv2
* Rebuilt URL to: https://www.google.com.cu/
* Trying 192.168.4.65...
* TCP_NODELAY set
* Connected to (nil) (192.168.4.65) port 81 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Many, many thanks to Michael Hampton. It turns out the problem was in the proxy configuration. It should say
https_proxy=http://127.0.0.1:3128
HTTPS_PROXY=http://127.0.0.1:3128
So curl was trying to connect to squid using TLS and failing of course.
Original answer in https://serverfault.com/questions/901626/debian-version-change-affecting-scripts-using-curl-and-https
Trying to execute the spark program using YARN RESTAPI in HORTONWORKS 2.5
i have followed this link: https://community.hortonworks.com/content/kbentry/28070/starting-spark-jobs-directly-via-yarn-rest-api.html
Issue I'm facing is :
In the 5step: Request an application ID from YARN
curl -ikvu "knoxuser:knoxpwd" -X POST "https://$KNOX_SERVER:8443/gateway/default/resourcemanager/v1/cluster/apps/new-application"
Error:
About to connect() to $KNOX_SERVER port 8443 (#0) * Trying 53.244.194.234... connected * Connected to $KNOX_SERVER (53.244.194.234) port 8443 (#0) * successfully set certificate verify
locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS
handshake, Client hello (1): * error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol * Closing connection
#0 curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Where do I find the url or I'm going wrong in the url part in the command?
Please let me know, it would be great help to me.
I have a node app running in a Centos 7 based VM on port 5000. When I open a browser within the VM, I can access http://localhost:5000. I am forwarding port 5000/TCP in Virtualbox too. Until very recently, I was able to access the same URL on my host. I am able to SSH into the machine, so I can assume guest addition is not to blame.
When I curl from the host, I get the following output:
curl -v http://localhost:5000
* Rebuilt URL to: http://localhost:5000/
* Trying ::1...
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.46.0
> Accept: */*
>
* Recv failure: Connection was reset
* Closing connection 0
curl: (56) Recv failure: Connection was reset
Curl from the guest is successful:
curl -v localhost:5000
* About to connect() to localhost port 5000 (#0)
* Trying ::1...
* Connected to localhost (::1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache="Set-Cookie, Set-Cookie2"
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-XSS-Protection: 1; mode=block
< Content-Type: text/html; charset=utf-8
< Content-Length: 13545
< ETag: W/"34e9-XRkZVDhS9RNYciepFhTD7A"
< Vary: Accept-Encoding
< Date: Wed, 10 Aug 2016 17:11:16 GMT
< Connection: keep-alive
<
<!DOCTYPE html>...
Port forwarding settings are shown below - only SSH works, although I have tried adding and removing host IP to the services I want to access.
How can I troubleshoot this further?
Might this be a problem with the latest version of virtualbox?
Turns out I had downloaded a newer version of the Vagrant Box which now enabled the firewall where previously it was not. A lazy workaround was to:
sudo systemctl stop firewalld
sudo systemctl disable firewalld
Alternatively, to allow traffic outbound on port 5000 only
firewall-cmd --zone=public --add-port=5000/tcp --permanent
Stopping the Firewall Daemon in VM machine just worked for me. Thanks #Harry King
sudo systemctl stop firewalld
Curl result before disable:
* Recv failure: Connection was reset
* Closing connection 0
curl: (56) Recv failure: Connection was reset
After disable:
< HTTP/1.1 404
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 30 Oct 2020 06:47:43 GMT
<
{"timestamp":1604040463217,"status":404,"error":"Not Found","message":"No message available","path":"/"}* Connection #0 to host 127.0.0.1 left intact