I have created a Java Web Application using Jetty (in Eclipse, using OSGI etc.). The application itself runs quite well (when being tested locally), so I wanted to run it on an Azure virtual machine in order to be accessible for external users (for testing reasons).
What I did so far:
created an Azure account
create a virtual machine with Windows Server running in it
downloaded all my eclipse files etc. to the virtual machine
started the application (in fact in eclipse, not the compiled jar) in the virtual machine; the application is published to port 8080
so, when i run a webbrowser in the VM and connect to localhost:8080, everything works well
but when I try to access the website from external (using my assigned domain of the VM, something.cloudapp.net:8080), it does not work
I also created endpoints in the azure management console for this VM (80, 8080, etc.)
Does anyone ever tried to run a java webapp on Azure or has a hint what could go wrong here?
By default, windows servers in Azure have the windows firewall enabled. This would block external connections to port 8080 by default. Try adding an appropriate exception to the windows firewall rules.
According to your description, I think you have correctly configured the new endpoints for the network traffic of Java Webapp. If not or incorrectly does, please refer to the article https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-create-nsg-arm-pportal/ to configure again.
Then, as #CtrlDot said, you need to configure the firewall for allowing the inbound traffic on Windows Server.
As reference, please see the article about allowing inbound traffic to a specified TCP or UDP port on Windows Server to do it.
Related
I am running a Spring Boot application that I exported from Eclipse as an executable JAR. I have tested it on local host on a Windows machine, both in Eclipse and as an executable JAR.
On my local Windows machine, I can connect to the executable JAR’s REST API using RESTClient for Firefox. The executable also successfully sends a message to a remote server when it initialises on my windows device.
I am trying to deploy the executable to a CentOS device to test it. I have allowed all traffic through the firewall by setting the default for Input to accept using IP tables (I know, a very bad idea, but the device won't be alive for more than a few mins for a demo).
The executable JAR runs on the CentOS system. It says it is listening on port 8080, it successfully sends information to another remote server when initialised; but I cannot access the REST API delivered by the Spring application.
The executable launches on the CentOS server without any complication. I can ping the centOS server, I can SSH into the server; but when I try using RESTCLient to access the machine, I am told that the URL is invalid, and when I try make a GET request using my browser I am told the connection was reset. On the console for the spring application nothing registers when I try and make a connection to the device.
Can I deploy the application to the CentoOS server in this way or does it need additional permissions to listen to a port? Please Advises!
Do you have a firewall activated?
So you have to open the port in the firewall settings:
firewall-cmd --zone=public --add-port=8080/tcp --permanent
Then remember to reload the firewall for changes to take effect.
firewall-cmd --reload
Can I use the Apache Guacamole API to allow a Java program to access a specific port on a Guacamole server's connection? When I say connection, I mean a machine that the Guacamole server is connected to - a machine that would show up in the Guacamole web interface.
Background:
I set up an Ubuntu virtual machine as a local Guacamole server/client. The virtual machine also runs a series of centOS (LXD) containers, each with a respective IP address. Outside of the virtual machine, on the host machine on the same network, I am able to access the Guacamole web interface via a web browser and SSH into the centOS containers just fine.
Let's say I have a Java program on my host machine that needs to communicate with one of those centOS containers. Is it possible to use the Guacamole API to allow the Java program on the host machine to programmatically access a specific port on one of the Guacamole connections/centOS containers?
If so, how would I go about doing that? I'd appreciate any specific examples or documentation related to this. If there's a better way to go about this, please let me know.
Thanks.
I am not sure if this is the correct forum to ask this question, please redirect me if this is not so.
I have this arrangement for doing work:
1) VMWare installed, which has virtual images, mainly AS, Linux OS.
2) The host OS is windows i,e. Virtual box is installed in Windows OS.
3) Eclipse and other tools installed in host OS; where we check out code, do development work etc.
Now I have following questions/doubts:
1) In our Host OS, we have putty application from which we are able to connect to cent OS (which runs in Virtual box); we access that 127.0.0.1. How is this possible? Usually 127.0.0l.1 refers to the "localhost", how come using 127.0.0.1 is able to connect to the Guest OS running in virtual box?
2) As the web-application gets deployed in Jboss AS (which again is running in Virtual box), I have need to debug the application, i.e., to check the flow of control in eclipse. Since Eclipse is running in host OS, and the Jboss is running in Virtual box (where .war is deployed), how can I be able to see the flow of control i.e. put break points in eclipse.
EDIT:
When I run the virtual box, it automatically runs the Jboss AS during start-up, and as such I am not sure if I have any control over providing any special instructions because Jboss gets started automatically while starting the virtual appliance (Cent OS, Jboss)
Any help really appreciated.
Anything running in the Guest OS will see the Guest OS as localhost (127.0.0.1).
In order to debug remotely, you need to be able to address the JVM instance's debugger port, which means that you need to address the Guest OS.
Assuming you can already do that to access the web-site hosted by JBoss AS, you just need to open the debug port when starting JBoss, and refer to that from Eclipse, e.g. start JBoss with this argument:
-agentlib:jdwp=transport=dt_socket,address=GUESTOS:8000,server=y,suspend=n
Where GUESTOS is IP of the Guess OS (not 127.0.0.1), then specify the following values in the Eclipse Remove Java Application debug configuration:
Host: GUESTOS
Port: 8000
Port number can be whatever you want it to be.
I am currently implementing a single signon solution for a customer that is based on Java, Tomcat and Kerberos.
Users are to access the URL of an intranet Tomcat application from their client browsers, the Tomcat application acquires the users' credentials via Kerberos and redirects them to the actual web application.
Our customer's environment is a typical mixture of a Windows AD server acting as the KDC and Linux Tomcat application servers. The SSO functionality is supposed to be used from both Windows and Linux clients. This is what appears to be different from most answers I can find on the net where people have Linux web application servers but only use Windows clients.
Now, in my local setup I get some strange behaviour. My development environment is a Tomcat 7.0.26 running from MyEclipse 8.6 under Windows 7. My test environment is a Tomcat 7.0.26 or 7.0.53 behind an Apache web server on a Centos 6 machine. I have set up the AD server correctly, generated the necessary keytab files etc. and everything is running smoothly in the development environment. I can access the Tomcat application from both Linux and Windows clients using IE and Firefox, Kerberos authentication proceeds and I get redirected properly.
When deploying the Tomcat application on the test server this keeps working when trying to sign on from Windows clients. However, when I try to access the test server from a Linux client (I have tried from Linux Mint 13 and Ubuntu 13.10), I get the following error:
javax.servlet.ServletException: GSSException: No credential found for: 1.3.6.1.5.2.51.3.6.1.5.2.5 usage: Accept
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:233)
I have to admit that I do not properly understand this message. Does it point to a problem with the credentials supplied by the client or a problem with the application server negotiating with the KDC? I have done some research on this problem and have found out that the indicated oid 1.3.6.1.5.2.5 stands for GSS_IAKERB_MECHANISM and not GSS_KRB5_MECHANISM or GSS_SPNEGO_MECHANISM which I find strange. Also, nobody else appears to have exactly the same problem.
I have tried switching from MIT Kerberos to Heimdal Kerberos and back. I have tried Firefox and Chromium, on the application server I have switched between Tomcat 7.0.26 and 7.0.53, the problem still persists. I am using the latest spnego.jar.
Now: Calls from Linux to the Tomcat running on the Windows development machine succeed and calls from Linux clients to the Linux application server fail with the same error message for both browsers tried.
Any ideas on this one?
GSS_IAKERB_MECHANISM means that the client is not able to determine the realm/kdc to create a service ticket and asks the server to serve as an intermediate to the target KDC. Check Wireshark traffic. Your task now is to analyze why the client is not able to create a service ticket for that SPN. I have observed this issue on Heimdal on FreeBSD with Microsoft KDC.
So the problem ist not your Tomcat instance.
I've had a Spring 3.x application running on Solaris (5.10) in a VMWare VM for quite a while. My application registers some mbeans. I've been able to connect remotely to the VM from VisualVM and view data in the "Monitor" tab, and I've been able to see and manipulate my application mbeans in the MBeans tab.
My server was recently moved to another VMWare VM, although the host name and IP address didn't change. We got it all working, I thought, until I noticed some odd behavior when I tried to connect to the VM from VisualVM on my desktop. When I first tried it, I thought it was working fine, but when I looked closer I noticed that there was no "Monitor" tab, and when I looked at the MBeans tab, it didn't have any of my application mbeans.
I can run a local WebLogic instance, and I don't see these issues when I connect locally with VisualVM.
It doesn't seem like it would be a firewall problem. The connection succeeded. In the "Overview" tab I can see all the basic property settings.
Why would my remote connection have "degraded" functionality?
It looks like your remote is connected to the wrong MBeanServer, which is to say, rather than connecting to the WebLogic Domain Runtime Server, you are connecting to the JVM's platform MBeanServer. I'm not certain, but I think you should be able to connect to any of the three MBeanServers running in the WebLogic instance, as outlined here.
There is also an option to register your Weblogic Domain MBeans in the platform MBeanServer.