Something I have been struggling with for a while, but I'm not able to come up with a proper solution.
This is the situation:
Host 1 - IBM HTTP Server, Customization Toolbox and WAS Plugins
Host 2 - WAS + Application
These are the steps I executed to configure the plugin and propagate it from Websphere:
1. I used the Customization Toolbox, selected the correct WAS Plugins directory and created a new Web Server Plugin
2. I copied the new configureSERVER.bat to my Application Server on Host 2, and configured the current profile.
3. On Host 1, I created an Administrator account.
When I open the WAS-console on Host 2, I can see the actual Web Server, so that went ok. When I select "Generate plugin" and "Propagate Plugin", I get no errors. I checked the HTTP Server, and indeed, my plugin-cfg.xml is neatly created and exists.
To make sure everything is all right, I opened the http://HOST1/snoop on Host 1 and I saw the correct diagnostics. So far, so good.
After that, I deployed my application, which runs on port 9044. However, this application runs on HTTPS, so we need to make sure that the IBM HTTP Server accepts SSL connections. I generated my own selfsigned certificate, imported it in the httpd.conf and restarted the server. (If someone is interested, I'll put some more details on how to do this).
Now, when I open https://HOST1/snoop I can see the diagnostics, which is good news. It means it accepts connections on https and reroutes it to Host 2. But the problem is, I have no idea how to access my application, which is running on port 9044.
Something that puzzles me is the details when I run the snoop-servlet.
When I run it via http (so without SSL), this is the output:
Local address XXX.XXX.XXX.XXX
Local host XXXXXXXXXX
Local port 9080
That is correct, because the port on Websphere is 9080 for that particular servlet. However, when I open https://HOST1/snoop (so, via SSL), this is what being generated:
Local address XXX.XXX.XXX.XXX
Local host XXXXXXXXXX
Local port 9044
So, apparently, 443 is being rerouted to 9044 on the second host, but the Snoop servlet runs on 9443, not 9044 (which is my application). But, then I wonder, why can I access the servlet, if it is running on another port.
So, if there's anyone who can give me some guidance, that would be nice.
This is the VHOST:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:9080"/>
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:5060"/>
<VirtualHost Name="*:5061"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:9044"/>
</VirtualHostGroup>
Event though you have 2 ports (I'm assuming you created custom transport chain and assign 9044 port to it), you added that port to default_host, which is visible in the VirtualHostGroup in the plugin. Your application is probably mapped also to the default_host, so it is available using all ports - 9080, 9443 and 9044. Second transport should be visible in the plugin config for your server with port 9044. Since it is also ssl transport plugin could choose that one to route request to your server. There is no way to force plugin to use specific port for communication to WAS for given application.
However you didn't specify what you actually want to achieve? Since your app should now be available via https.
Related
I am currently running a service with systemctl, and it is running as an http proxy, not normal http. Is this something that Google does? I am using port 8080 and I can't connect to it via http. My daemon is using port 8080, while using the type http-proxy (I am seeing this with the command nmap -sV -sC -p 8080 35.208.25.61 -vvvv -Pn). Instead, I want the daemon I'm running (wings.service) to use http, so it can use that type of connection to connect to my panel.
The panel is part of a piece of software along with the daemon, it's called pterodactyl. Anyways, I have tried everything on what to do, and I think this problem that I am addressing is the problem that causes dysfunction on my panel. I might just have to move to a different service to host my bots for discord.
Let me know if there's anything I can do to fix this.
As per I can understand you are unable to access the panel via web URL.
Pterodactyl web server can be installed using NGINX or Apache web servers, and both web servers by default listed on port 80 based on Pterodactyl web server installation guide, so you must enable HTTP port 80 traffic on your Compute Engine VM instance
The default firewall rules on GCP do not allow HTTP or HTTPS connections to your instances. However, it is fairly simple to add a rule that does allow them following this steps:
1.-Go to the VM instances page.
2.- Click the name of the desired instance.
3.- Click Edit button at the top of the page.
4.- Scroll down to the Firewalls section.
5.- Check the Allow HTTP or Allow HTTPS options under your desired VPC network.
6.- Click Save.
Note: The Pterodactyl panel and Daemon installation are not the same for each operating system, if after checking the VPC firewall rules on the VM settings and also the status of the web server in the instance (NGINX or Apache) you still cannot access your panel, please provide a step by step list with all commands you followed to complete the installation, including the OS version you used.
I have a front-end deployed on Netlify and a back-end is deployed on localhost which is exposed using ngrok.
Is it possible to link them so that when I click on the Netlify link, it would send request to my localhost server exposed from ngrok ?
Netify can proxy to a dynamic backend, that is an intended use case. The problem we'll have is using "localhost" - netlify needs a valid hostname to connect to. So, if your ngrok is exposed (not firewalled) at some public IP, you can put that into your redirects configuration:
/backend-stuff-in-this-path/* https://1.2.3.4/:splat 200!
will send all requests to the path /backend-stuff-in-this-path/ANYTHING to the server at 1.2.3.4/ANYTHING
This may not be incredibly useful since your machine will change IP addresses sometimes one presumes, but if you were using localhost anyway, you weren't planning to put it in production quite yet. Note that redirects are deploy-specific, so you do need to redeploy to change the location if your IP changes.
I'm new to web development. I'm planning to move my wordpress site to aws, says it's "example.com". I'm also planning to create a subdomain "xxx.example.com" using spring boot. I'm wondering is that possible?
Yes it's possible but remember only one process can only listen to a port (80 for http, 443 for https) in a machine.
Two options:
Have subdomain on a different machine with different IP address for it. So you can have Wordpress on one machine and your spring application on another.
Host in same machine and have one process (Apache, or a load balancer) listen to traffic for both and send it in appropriately. This is achieved with the ProxyPass command in Apache. Having a webserver in front of an application server is often recommended anyway as can be better for security and performance reasons.
There is a third option, which is to use a non-standard port (e.g. 8443) but that just makes your URL look messy (https://xxx.subdomain.com:8443). Which might be fine if you just want to test for your own sake but not great for production applications.
I have a Asp.net website hosted through Ultidev, and am using DynDns to assign a hostname (web address) to the site. My question is, is their a setting or configuration or something that I can change to go to www.yoursitename.org and my page load? Or must you always specify the port to connect to in order to connect to your site www.yoursitename.org:12345
Assuming you have already configured your router to forward port 80 (standard http port) traffic to you host computer, and opened PC firewall to allow inbound port 80 connections, then what you need to do is to run "[UltiDev Web Server Explorer][1]" and there add combination of the www.yoursitename.org and port 80 as shown on the screenshots below. One thing to note that if port 80 is already occupied in the exclusive mode by an another web server (Apache, etc.), you will see that when saving UWS configuration, the www.yoursitename.org:80 will disappear. If it didn't disappear, then the site:port combination was available and now will be used.
I have successfully setup IIS on my local development machine (dev branch - setup as localdev.me) but when I went to setup another branch (hotfix - setup as localhotfix.me) I am running into issues. The issues are due to the way the site is setup. The subdomain of the url is used to determine which Database to connect to. So going to host.localdev.me will connect to the host database. So in IIS I have the following settings for the bindings of the site.
Type Host Name Port IP Address
http localdev.me 80 *
http *.localdev.me 80 *
I can ping localdev.me with any subdomain and I get the loopback address as expected. When I then setup the hotfix branch (exactly the same as the dev but with the following bindings) I get name not resolved errors.
Type Host Name Port IP Address
http localhotfix.me 80 *
http *.localhotfix.me 80 *
Is there a reason the first setup would work and not the second? What is perhaps even stranger if I tell IIS to stop I can still ping subdomains on localdev.me and get the loopback address.
I could always get it working by manually specifying the host name in my windows hosts file but I would rather not do that as I would need to go in and edit the file every time we add a new subdomain.
EDIT: These are the specific errors I am getting.
ping localhotfix.me
Ping request could not find host localhotfix.me. Please check the name and try again.
EDIT2: I have a solution that works fairly well. It requires Acrylic DNS and installation of the Microsoft Loopback Adapter. I set the loopback adapter to a valid IP Address and set the DNS server to 127.0.0.1 then edit the AcrylicHosts file to contain entries for each domain with a wildcard. Once I did all of this I was able to ping localhotfix.me along with *.localhotfix.me. I believe the reason localdev.me worked is because it is a valid domain. The name would resolve at which point I believe IIS was able to take over. But thats really just an educated guess. But kindof makes sense as to why it worked for one and not the other.
The reason *.localdev.me works without a hosts file is because the public DNS for that domain resolves to 127.0.0.1 as long as it is not localdev.me or www.localdev.me. You can check this using nslookup *.localdev.me (replace the asterisk with anything except www) while your hosts file is empty. On the other hand, *.localhotfix.me is not registered in public DNS at all, which is why you'd need a hosts file entry for those.