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.
Related
Been trying to run a wallet app in tails os ver 4.28 with no success. I'm getting denied error when using it with proxychains. Being a noob here, would someone assist me in letting me know what I'm doing incorrect here. I've included terminal output & proxychain config info for reference here.
amnesia#amnesia:~/Persistent$ chmod +x Neuron-v0.101.2-x86_64.AppImage
amnesia#amnesia:~/Persistent$ proxychains ./Neuron-v0.101.2-x86_64.AppImage
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-<--denied
06:16:58.553 › Network: connection dropped
|DNS-request| localhost
|DNS-request| localhost
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-|DNS-request| localhost
<><>-127.0.0.1:8114-<--denied
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-|DNS-request| localhost
<--denied
06:17:00.145 › Network: fail to connect to the network. Is CKB node running?
06:17:00.323 › Network: switched to: {
id: 'mainnet',
name: 'default node',
remote: 'http://localhost:8114',
genesisHash: '0x92b197aa1fba0f63633922c61c92375c9c074a93e85963554f5499fe1450d0e5',
type: 0,
chain: 'ckb'
}
06:17:01.453 › Main window: The main window is ready to show
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-|DNS-request| localhost
<><>-127.0.0.1:8114-<--denied
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-|DNS-request| localhost
<--denied
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-<--denied
|DNS-response| localhost is 127.0.0.1
|DNS-request| localhost
|DNS-request| localhost
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-<--denied
06:17:03.705 › CKB: external RPC on default uri not detected, starting bundled CKB node.
06:17:03.707 › CKB: Initializing node...
06:17:03.708 › CKB: init: config file detected, skip ckb init.
06:17:03.708 › CKB: starting node...
06:17:04.116 › CKB: process closed
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-|DNS-request| localhost
<><>-127.0.0.1:8114-<--denied
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-<--denied
|DNS-request| localhost
|DNS-response| localhost is 127.0.0.1
|S-chain|-<>-127.0.0.1:9050-<><>-127.0.0.1:8114-|DNS-request| localhost
<--denied
^C|DNS-response|: localhost does not exist
Aborted
proxychain.config file
#dynamic_chain
strict_chain
#random_chain
#chain_len = 2
#quiet_mode
proxy_dns
# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050
Appreciate any assistance in this matter.
So, didn't get a response from the community as of yet. I did some exploration and enabled the following in proxychains config file
enabled dynamic_chain and commented strict_chain
replace socks4 with socks5
This got rid of the denied issue, but gave me a timeout issue.
Reached out the wallet tech team for assistance. They responded stating wallet synchronization fails when it's behind a firewall, vpn, anti-virus. Wallet behind a proxy configuration also disrupts the synchronization. I had a very slim hope that this would work and that faded quickly with their response. This closes out this open question.
I solved the problem by connecting to the internet (usually not connected) and running "sudo apt-get update" . After the update was done (a few seconds) I restarted tails (USB Stick variant) and then the problem was gone.
I've got a docker-compose file with 3 services:
database
api
locust container to load test the api
This is my (simplified) docker-compose file.
version: "2.0"
services:
database:
image: ourcompany/postgres11
environment:
POSTGRES_DB: thedatabase
POSTGRES_USER: theuser
POSTGRES_PASSWORD: thepassword
api:
build: ./api
volumes:
- ./api/src:/app
ports:
- "8001:8001"
links:
- database
environment:
- DATABASE_HOST=database
- DATABASE_NAME=thedatabase
- DATABASE_USER=theuser
- DATABASE_PASSWORD=thepassword
- UWSGI_HTTP=0.0.0.0:8001
# and some more env variables
locust:
build: .
volumes:
- ./reports:/opt/reports
- ./:/opt/src
links:
- api
command: bash -c "locust -L DEBUG -f /opt/src/locustfile.py --host=http://api:8001 --no-web -c 25 -r 5 --run-time 15s"
When I run this locally on my laptop (Ubuntu 19.04) it works great. But when running this on our Jenkins CI server (Ubuntu 16.04), the locust container isn't able to call the api.
So I created this curl command to manually try the post:
curl -v -d '{"id":"260b748f-dad4-42ba-84b4-9084ea5d8304","count":"6.0","sensor":"AAG-1-4"}' -H "Content-Type: application/json" -X POST http://api:8001/v0/measurement/
I execced into the locust container on my laptop (docker exec -it ee470aaea287 bash) and tried the curl post from there, which worked perfectly (I had verbose mode enabled):
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 192.168.208.3...
* TCP_NODELAY set
* Connected to api (192.168.208.3) port 8001 (#0)
> POST /v0/measurement/ HTTP/1.1
> Host: api:8001
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 407
>
* upload completely sent off: 407 out of 407 bytes
< HTTP/1.1 201 Created
< Content-Type: application/json
< Vary: Accept
< Allow: POST, LIST, GET
< X-Frame-Options: ALLOW-FROM *
< Content-Length: 511
<
* Connection #0 to host api left intact
{"success": "true"}
I then ssh'ed into the jenkins server and ran the curl request from outside the container with api replaced by 127.0.0.1. That worked perfectly again (similar output as above).
I then execced into the locust container on the Jenkins server and tried the curl post from there:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 10.240.2.1...
* Connected to 10.240.2.1 (10.240.2.1) port 8080 (#0)
> POST http://api:8001/v0/measurement/ HTTP/1.1
> Host: api:8001
> User-Agent: curl/7.47.0
> Accept: */*
> Proxy-Connection: Keep-Alive
> Content-Type: application/json
> Content-Length: 407
>
* upload completely sent off: 407 out of 407 bytes
< HTTP/1.1 302 Moved Temporarily
< Date: Wed, 14 Aug 2019 07:18:28 GMT
* HTTP/1.1 proxy connection set close!
< Proxy-Connection: close
< Via: 1.1 localhost.localdomain
< Proxy-agent:
< Location: http://www.api.com:8001/v0/measurement/
< Content-Length: 487
< Content-Type: text/html
<
<HEAD><TITLE>Moved Temporarily</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Moved Temporarily</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: <TEXTAREA READONLY rows="2" cols="75"> The document you requested is now http://www.api.com:8001/v0/measurement/. Please update your documents and bookmarks accordingly.</TEXTAREA></B></FONT>
<HR>
<!-- default "Moved Temporarily" response (302) -->
</BODY>
* Closing connection 0
As you can see that fails with a 302 redirect. There are a couple weird things in there:
it first talks about port 8080 even though I need to connect to port 8001. I don't expose those ports manually since that could conflict with other containers on the Jenkins server. As far as I understand docker takes care of this under the hood though.
it redirects to www.api.com. What part of the system does this?
I then tried pinging the api container from within the locust container, which works perfectly:
$ ping api
PING api (192.168.32.3) 56(84) bytes of data.
64 bytes from api_1.default (192.168.32.3): icmp_seq=1 ttl=64 time=0.127 ms
64 bytes from api_1.default (192.168.32.3): icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from api_1.default (192.168.32.3): icmp_seq=3 ttl=64 time=0.065 ms
and telnet:
telnet api 8001
Trying 192.168.32.3...
Connected to api.
Escape character is '^]'.
Does anybody know how I can debug this further?
We figured out together with the thread creator that he runs a proxy in the network. Thats why it was not working.
A change in the docker environment variables does the trick:
- http_proxy=
- https_proxy=
- no_proxy=
So the proxy is disabled inside the docker-container.
OS: CentOS release 6.9 (Final)
CURL: curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Hello,
I have a host which I am trying to run a curl command from, for testing only
curl https://api.twitter.com/ -v
Returns the below
* About to connect() to api.twitter.com port 443 (#0)
* Trying 104.244.42.2... connected
* Connected to api.twitter.com (104.244.42.2) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
After some lengthy reading I have come to the conclusion this is possibly a SLL issue due to either my OS version or CURL version, or both!
First question would be is that right? Are there indeed known issues with this configuration?
Second, can I build from source a working combination? I am unable to update my OS due to legacy dependencies
Try with specific ssl/tls or cipher suits for example: curl --tlsv1.2 https://api.twitter.com/
Since you say this is for testing only, you could try -k to connect insecurely:
curl -k https://api.twitter.com/
Or, if you think it’s an outdated SSL cert bundle you could download a newer certificate and trust store from the internet and try that by using the --cert and --cacert options
Rebuild a fresh server running centos 7
Worked straight away no issues!
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 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"