We use an Apache HTTP server with a Websphere Application Server 8.5
Requests to HTTP servers work on default port 80
I have configured port 2021 on http.conf + in default host in Websphere and everything works. The only 'problem' i have is that we need port info in the URL.
http://oursite/index.html works
http://oursite/myApp.jsp doesn't work
When i add the portnumer to the request it works.
I understand that this extra port is needed to tell HTTP server that this request should be forwarded to Websphere. But customers are complaining that the port we used is blocked by their firewall and some customers refuse to add this port to give access.
Now i tried to add port 80 to the Websphere config (default host) and this seems to work.
Is it really needed to config an additional port ?
*:80 is in the "default_host" by default. Whatever host and port your clients will use to address the proxy must be present in the virtual host that your application is deployed to -- otherwise it won't be handled by the WAS Plug-in.
It sounds like someone removed that *:80 alias from the default host, mistakenly thinking it only needed to be there if the application server explicitly listened on port 80. That is misguided.
Related
Good day,
I want to connect to my kafka server from the internet. Kafka installed on the virtual server and all servers hidden behind a nginx.
I updated kafka settings (server.properties).
Added: listeners=PLAINTEXT://:9092
I can connect to kafka server from local network via ip address 10.0.0.1:9092, but unable connect from internet by domain name.
Response from kafka: java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Topic test-topic not present in metadata after 60000 ms.
Nginx: [26/Nov/2019:12:38:25 +0100] "\x00\x00\x00\x14\x00\x12\x00\x02\x00\x00\x00\x00\x00" 400 166 "-" "-" "request_time=1.535" "upstream_response_time=-" "upstream_connect_time=-" "upstream_header_time=-"
nginx conf:
server {
listen 9092;
server_name site.name;
# Max Request size
client_max_body_size 20m;
location / {
proxy_pass http://10.0.0.1:9092;
}
}
Does anyone know what the problem is?
Kafka doesn't use http protocol for communication, so it can't be fronted by an HTTP reverse proxy.
You'll have to use nginx stream definition blocks for TCP proxying
(I've not tried this personally)
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/
unable connect from internet by domain name.
Sounds like an issue with your advertised.listeners configuration. Note that there is no clear way to "hide" Kafka behind a proxy since your clients are required to communicate directly with each broker individually (therefore defeating the purpose of having
Ngnix unless you want to use one Nginx server or open a new port, per broker), and would therefore also require Kafka to know that it would need to "advertise" the proxy rather than its own address.
If you really want to expose Kafka to the public web, you should really be using SSL/SASL listeners, not PLAINTEXT
If you want to use HTTP, then you can install Kafka REST Proxy, then put Nginx in front of that. Then your clients would use http rather than standard kafka libraries
I need to setup a reverse proxy server which would distribute traffic to the backend servers based on the incoming HOST header.
I opted for HAproxy for this but after setting up everything I realized that HAproxy reads the configuration just once when the service starts and continues to use the backend IP address unless it has been reloaded/restarted.
This is an issue for me since in my case if the backend server reboots it will have a different IP address and I dont have control on which IP address it gets.
I am thinking of moving to nginx server but before I go through all the setup I would like to know if we have the same issue with Nginx or not?
Meaning: If in the configuration file I have specific the name of backend server and if the related IP address changes, will Nginx refresh its dns cache to identify the new IP address?
(When the backend server changes IP, it is automatically updated in the hosts file of proxy server)
Yes, nginx will do the job. See 'resolve' option here:
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server
Theres a server in a customer that runs a nginx, a salt master daemon from saltstack and a secret web app that does secret things.
Considerations:
In this scenario, theres only one ip, only one server and multiple DNS records available;
I have nginx running in port 80;
And salt master running in 6453;
A domain.example.com binding to that IP, exposing my nginx 80 port, that points to the secret webapp;
otherdomain.example.com binding to the same IP, exposing my nginx 80 port, that I want to use to proxy salt port.
That customer has a machine in other place, that does need to connect to the salt and the internet connection is provided by a secret organization and they only allow connections to port 80, no negotiation possible.
My question:
Is possible to use nginx to redirect the otherdomain.example.com 80 port to the 6453 port? I tried the following:
server {
listen 80;
server_name otherdomain.example.com;
proxy_pass 127.0.0.1:6453;
}
But that doesn't work as expected. It is possible? There's some way to do this using nginx?
The error I got from log was:
"proxy_pass" directive is not allowed here
proxy_pass needs to be specified within a location context, and is fundamentally a Web Thing. It only comes into play after the web headers are sent and interpreted.
Things like what you're trying to accomplish are commonly done using HAProxy in tcp mode, although there is a tcp proxy module that also does similar things.
However, I don't think you're going to be very successful, as ZMQ does not participate in the protocol (HTTP Host: headers) that easily allows you to tell the web requests apart from the non-web requests (that come in on the same port).
My recommendation is to either find some way to use another port for this, a second IP address, or write a tricky TCP proxier that'll identify incoming HTTP and/or ZMQ connections and transparently forward them to the correct local port.
I have a ASP.NET MVC site set up in IIS7 on Win2K8 with a single SSL binding on Port 443. The team in charge of the server only has port 443 open for security reasons, but this shouldn't be any issue because that's the only binding I have and I'm not making any regular HTTP calls on port 80.
When I call my site, my main login page (using forms authentication) comes up in the browser (over HTTPS) which looks fine. However, as soon as I try to login I get the following error:
[SocketException (0x274d): No connection could be made because the target machine actively refused it 10.x.123.123:80]
Ok that is the correct IP assigned to the site, but I'm not making any calls on port 80. Why would I get this error if all I need is a SSL binding on port 443? Am I required to have port 80 open as well? I'm not making any calls internally that use port 80, unless MVC is doing something I'm unaware of that requires port 80.
When digging into the code it turns out that our service turned around and made additional REST calls to other parts of the same service using a HTTP url, thus causing the error.
Since I configured IIS to only allow SSL traffic and I had internal calls to a HTTP URL the error was generated. The root cause was that I forgot we were making RESTful calls within the code and those URLs had to be updated to their respective HTTPS counterpart.
I would like to use tomcat to serve a web page. The webpage will make a connection using websockets over port 80. Does this mean I need a java servlet (hosted by tomcat) to listen for a websocket connection? Or can I use some other application to say written in erlang to listen for the websocket connections.
I'm confused about whether if I use tomcat to serve the webpage, I'm also forced to use it to listen for websockets over port 80. I would have tomcat and the erlang app on the same machine.
The WebSocket server could be listening on some other port than the one used to serve your HTML page (80 presumably) and might even be on a separate domain/server. As long as it respects the specification, you could use any language/framework to write a WebSocket server.
There are issues of Cross Domain scripting which is usually blocked by Web Clients. However, i ask my self, why don't you let your favorite Erlang web server like Yaws or Mochiweb serve that very page from which web socket requests will be initiated?
On the same server, you can have both Tomcat and another Web server running. You can let Tomcat be on Port 80, while the other Erlang web server on say port 8080. Let the page that points to your web sockets page have the link as say: Click here to start web sockets application
You can as well do port forwarding and stuff like that on your Server room firewall (router) to map requests incoming on one port to another