windows service access to network before logon - java

I wrote a windows service in Java, and it starts automatically (before user login to Windows).
My problem is that it looks like the service has no access to the network before logon.
In the logs I see that before logon, I get: java.net.UnknownHostException. However, the same code works fine after logon.
I tried to define the service as "network service", it did not helped.
Can anyone please help?
BTW:
There is no WiFi involved
I looked how TeamViewer program works and I saw that they have some registry values in FirewallPolicy. and they defined their service as local system.
Which made me think maybe it has something to do with the firewall settings, however I cannot find anything in the web about it.

I just managed to solve this. The issue was that the service started before there was access to the internet. Keep in mind that the network might be accessible but the internet isn't.
I solved it by doing: (pseudo code)
while (false) {
check if http://www.example.com is accesible:
if true - break
if false - sleep for 3 seconds
}
... (rest of the code)

If the exception one gets is UnknownHostException, this would imply that somehow DNS resolution failed..
Note further that DNS resolution itself depends on IP. Hence, if the machine in question is slow to connect to the respective gateway (router), then DNS resolution has no chance of succeeding.
Hence, while you may try to resolve the host resolution in a loop with a sleep (as suggested by Kuf).. I'd suggest try to log how soon does the machine gets the IP address after the reboot (a sign of how soon it gets connected to the Network), and then go from there (additional SuperUser or ServerFault question perhaps).

Related

java webserver is not receiving requests from internet, Not Found error

I have restarted a project that i closed after it became too comfusing, the original project was a webserver run entirely from java code. I have started this back up in the hopes of making the code 100% my own using java. I have gotten to the testing stage of hosting website however whenever i try to connect from the outside world i am shutdown with an error page. I have note coded this error page and after extensive research it is viewable that the error page is originating from apache. The only problem with this is that there is no apache in the code or in the virtualbox server. I have also tested this on two different virtual servers: opensuse 13.1 and fedora 20.
The URL of the server is blends.hopto.org/beta. There should be a black background there with some arrows and a blue dot, but instead there is an error that states:
"Not Found
The requested URL /beta was not found on this server.
Additionally, a 404 Not Found error was encounted while trying to use an ErrorDocument to handle the request."
I do not get this error if i request the page from inside my local network. But i do from outside, it is not a port forwarding problem because my minecraft server works and the server is assigned to the public ip of my home router!
Thanks, any help is appreciated!
Extra info:
After positing this question i stumbled across some other problems and it seems that the error is originating from SELinux, however i have disabled SELinux and the error is still coming through!
This is not an answer. I cannot comment on StackOverflow yet but would like to help.
You said that you get an Apache error page, which means that Apache must be running on your system. You can check this by typing this in the terminal:
apachectl status
You don’t mention what port you want to serve on. Apache usually uses port 80. You could configure your homemade Java server to work on a different port, say 8080. Also, if you are using Fedora 20, then you will have to configure FirewallD to allow this.
Okay well i finally found out what the problem was after just looking over the assigned ips to devices and found it strange that our networked hard drive was assigned the very first ip always. So i logged into the hard drive and found out it had been capturing all the port 80 requests from the router in an attempt to do remote login!!! I am very excited that this problem is resolved! I will be hoping to release my WebServer API for everyone to use as it is incredibly small and gives the programmer full controll

java.net.UnknownHostException occurs after some time

I have a project in eclipse to retrieve data from a certain website. As there is too much data to be retrieved I have to keep the code running overnight. I get ajave.net.UnknownHostException after sometime. The code runs without any problem for a long time and only later the UnknownHostexception occurs. Any solution as to why this is happening?
You can only have the mac address of your server where the war is being deployed, Check it here how to get the MAC address
I have seen this error in one of my projects before. Till Java 1.5, JVM used to cache the DNS entry and did not honor the TTL values. If for some reason, the DNS entry was modified (usually the case with Akamai or other CDN networks), and the IP you were going to before is no longer available, you may hit upon this error.
Some info on this behavior is available at http://www.rgagnon.com/javadetails/java-0445.html and http://blog.andrewbeacock.com/2006/12/warning-java-caches-dns-to-ip-address.html.
What you may try is to run a iptrace when it works fine and when it starts failing from the same machine - if the IP has changed, you are hitting this scenario.
My guess is that your internet connect is probably breaking. Do you have any other logs to verify this?

FTP Client listFiles() work in some machines

I have a program that make use of FTP Client, it is running in several machines and it stoped working in one of those machines.
Making the debug I can see that the problem is on listFiles(), listNames()... But it work's perfect giving me the name of the directory when I make printWorkingDirectory() or when I make FTPReply.isPositiveCompletion(ftp.getReplyCode()) it brings me the true value.
I have also made ftp.enterLocalPassiveMode(), ftp.setFileType(FTPClient.BINARY_FILE_TYPE).
I'm lost, can you please help me?
Sounds like the data connection is blocked - most likely in a router or firewall. You need to have the machine "behind" a NAT device be the active one.
What is the exact network configuration between the two machines you have problems with?

Best way to program a server status feature

Some background information.
- Running a java server on localhost
- Running a webserver on localhost
I would like a webpage to have a 'server status' feature which lets me know whether the server is running or not. My question, what is the best way to do this?
When I launch the java server, I write a flag in the database to signify that it is running.
Javascript/PHP sockets to try and bind on the same port. (Not sure if possible yet)
Shell script to locate the program in the task list.
Thanks!
When I launch the java server, I write
a flag in the database to signify that
it is running.
would not be of much help if the server should segfault.
Maybe have a look at http://mmonit.com/monit/
what is pretty much what you are looking for
I suspect the simplest method is simply for your web service (backend) to try and connect to the port that your server is running on, and provide an automatically refreshing page that reports this status. If your server goes down then you'll get an faster notification than if you're polling (say) the process table.
Of course the fact that you can connect to the port doesn't really give you an indication of whether it's working other than it's opened a port (e.g. it may have no resources etc. to service requests) but it's a start.

Secure Debugging for Production JVMs

We have some applications that sometimes get into a bad state, but only in production (of course!). While taking a heap dump can help to gather state information, it's often easier to use a remote debugger. Setting this up is easy -- one need only add this to his command line:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=PORT
There seems to be no available security mechanism, so turning on debugging in production would effectively allow arbitrary code execution (via hotswap).
We have a mix of 1.4.2 and 1.5 Sun JVMs running on Solaris 9 and Linux (Redhat Enterprise 4). How can we enable secure debugging? Any other ways to achieve our goal of production server inspection?
Update: For JDK 1.5+ JVMs, one can specify an interface and port to which the debugger should bind. So, KarlP's suggestion of binding to loopback and just using a SSH tunnel to a local developer box should work given SSH is set up properly on the servers.
However, it seems that JDK1.4x does not allow an interface to be specified for the debug port. So, we can either block access to the debug port somewhere in the network or do some system-specific blocking in the OS itself (IPChains as Jared suggested, etc.)?
Update #2: This is a hack that will let us limit our risk, even on 1.4.2 JVMs:
Command line params:
-Xdebug
-Xrunjdwp:
transport=dt_socket,
server=y,
suspend=n,
address=9001,
onthrow=com.whatever.TurnOnDebuggerException,
launch=nothing
Java Code to turn on debugger:
try {
throw new TurnOnDebuggerException();
} catch (TurnOnDebugger td) {
//Nothing
}
TurnOnDebuggerException can be any exception guaranteed not to be thrown anywhere else.
I tested this on a Windows box to prove that (1) the debugger port does not receive connections initially, and (2) throwing the TurnOnDebugger exception as shown above causes the debugger to come alive. The launch parameter was required (at least on JDK1.4.2), but a garbage value was handled gracefully by the JVM.
We're planning on making a small servlet that, behind appropriate security, can allow us to turn on the debugger. Of course, one can't turn it off afterward, and the debugger still listens promiscuously once its on. But, these are limitations we're willing to accept as debugging of a production system will always result in a restart afterward.
Update #3: I ended up writing three classes: (1) TurnOnDebuggerException, a plain 'ol Java exception, (2) DebuggerPoller, a background thread the checks for the existence of a specified file on the filesystem, and (3) DebuggerMainWrapper, a class that kicks off the polling thread and then reflectively calls the main method of another specified class.
This is how its used:
Replace your "main" class with DebuggerMainWrapper in your start-up scripts
Add two system (-D) params, one specifying the real main class, and the other specifying a file on the filesystem.
Configure the debugger on the command line with the onthrow=com.whatever.TurnOnDebuggerException part added
Add a jar with the three classes mentioned above to the classpath.
Now, when you start up your JVM everything is the same except that a background poller thread is started. Presuming that the file (ours is called TurnOnDebugger) doesn't initially exist, the poller checks for it every N seconds. When the poller first notices it, it throws and immediately catches the TurnOnDebuggerException. Then, the agent is kicked off.
You can't turn it back off, and the machine is not terribly secure when its on. On the upside, I don't think the debugger allows for multiple simultaneous connections, so maintaining a debugging connection is your best defense. We chose the file notification method because it allowed us to piggyback off of our existing Unix authen/author by specifying the trigger file in a directory where only the proper uses have rights. You could easily build a little war file that achieved the same purpose via a socket connection. Of course, since we can't turn off the debugger, we'll only use it to gather data before killing off a sick application. If anyone wants this code, please let me know. However, it will only take you a few minutes to throw it together yourself.
If you use SSH you can allow tunneling and tunnel a port to your local host. No development required, all done using sshd, ssh and/or putty.
The debug socket on your java server can be set up on the local interface 127.0.0.1.
You're absolutely right: the Java Debugging API is inherently insecure. You can, however, limit it to UNIX domain sockets, and write a proxy with SSL/SSH to let you have authenticated and encrypted external connections that are then proxied into the UNIX domain socket. That at least reduces your exposure to someone who can get a process into the server, or someone who can crack your SSL.
Export information/services into JMX and then use RMI+SSL to access it remotely. Your situation is what JMX is designed for (the M stands for Management).
Good question.
I'm not aware of any built-in ability to encrypt connections to the debugging port.
There may be a much better/easier solution, but I would do the following:
Put the production machine behind a firewall that blocks access to the debugging port(s).
Run a proxy process on the host itself that connects to the port, and encrypts the input and output from the socket.
Run a proxy client on the debugging workstation that also encrypts/decrypts the input. Have this connect to the server proxy. Communication between them would be encrypted.
Connect your debugger to the proxy client.

Categories