My problem is, that I can not access my Servlet outside from my computer.
So. f.e. if I go to http://127.0.0.1:8080/TestProject/test/, it shows me my site. In my case there is some JSON- Code.
But if I want to access this Site from a computer that is remote, it doesn't work. So, again, f.e. if I go to http://192.168.1.100:8080/TestProject/test/ (thats the IP from the computer where the WildFly- Server is started), it shows me nothing.
What could be the problem?
Problem solved! You have to start the WildFly- Server like that:
standalone.sh -b 0.0.0.0
Related
I am having a mild panic attack and could use some help.
I was emailed by Google telling me I need to change my machine type in my VM Instance. So I logged in, it told me I needed to stop the instance to make that change. I stopped the instance and then realized I'm not using the deprecated F1-Micro, so I just hit Play to restart the instance.
It restarts, has the reassuring green symbol, but my wordpress site can't be accessed.
I tried connecting via SSH and it seems like the data is there, I can navigate to the wordpress folder.
Can someone please advise on what I need to do to get the site running?
Thanks!
EDIT: More Info
Checking status of NGINX server shows it is "active (running)"
When visiting the web address, it loads for a very long time and then goes to an error page that just says "This site can't be reached the site took too long to respond. try checking connection and the proxy and the firewall. ERR_CONNECTION_TIMED_OUT"
I found the issue.
The Google documentation suggests your IP address will remain. Whether that is standard or not, my IP address changed, so once I updated my DNS records I was back online.
I am facing a strange issue.
My ISP has hosted a webservice inside a virtual directory which is placed under a subdomain. now from my system (or network) I cannot access that webservice. Every time I run fiddler, I see a DNS Lookup for "my_sub_domain.com" failed. No such host is known.
But If I run it through web-sniffer.com, it is returning as Status: HTTP/1.1 200 OK
I do not understand what is wrong, Have anyone faced something like this? Is there any problem with my network settings? Can you tell me how to fix this?
If you need any more information please let me know.
This sounds like a DNS issue. Your DNS server doesn't seem to have had the A record for the subdomain propagated to it yet, whereas the DNS server used by web-sniffer.com has had it propagated to it, and thus, can see that it's returning a valid record and IP address.
While waiting for it to propagate to your DNS provider, you could add an entry to your machine's host file with the correct IP address to allow you to continue work.
My client has a website that is showing some strange behavior. The site is built in ASP.Net and used to be hosted on their internal network. It's now been moved to a different server outside their network. They have other sites hosted on the same server, some built using DotNetNuke, and some classic ASP. All these sites are hosted on one application server, with a database (SQL Server 2008) on a separate server (which is on the same network as the application server). They share the application server, and the database server.
Now that this site has been moved to the outside server, they can't access it. I can, and so can others that I work with (from different IPs, across the country). But the client can't from their network. They can access the landing page subsite.clientdomain.com (no db access), but nothing else. So, for instance, there's a link to subsite.clientdomain.com/folder. When they click that link, the URL changes to subsite.com/folder, which does not work. For myself and others not at the client site, the URL does not change and opens with no problems.
I didn't write the site, and didn't even know it existed before this problem cropped up, so I know very little more than this. Any help is appreciated.
I'm going to go with Martijn B's answer. There's a DNS issue on the internal network. Somewhere on of the DNS servers is a definition that maps http://companywebsite to an ip address like 192.168.1.20 or whatever.
I would open a command prompt on your PC and type
ping new_website_name.com
Take a look at the IP address that comes back. You can also do an nslookup on new_website_name.com that will give you more information. If you (person A) gets one IP address and Person B (inside the network) gets a different IP address....there is definitely a DNS issue on the internal network.
You're going to have to do some network tracing to determine exactly where any redirection is occurring. Given that the problem is only manifested in certain locations, it is likely that it is a function of network configuration in that location (as previously suggested). Without understanding exactly what redirection is occurring, it would be unwise to make configuration changes that might make the problem worse or introduce new issues.
A DNS server cannot AFAIK redirect to a different URL. So something is redirecting from subsite.clientdomain.com/folder to subsite.com/folder, which could be caused by a HTTP redirect. This can be triggered by the software/website itself or by IIS.
I have an ASP.NET application that I use to read the contents of a web page by a HttpWebRequest frequently. There's no problem with the remote address and my application is always working fine.
While I don't change anything, sometimes (about once a day) I get this error:
the remote name could not be resolved.
Why a previously resolved DNS name sometimes fails to be resolved?
The intermittent nature of this is going to be extremely difficult to resolve and it's going to take a configuration change instead of a code solution. (hint: read everything ;)
I would guess that the remote servers DNS is set to expire pretty often. Probably daily or maybe even every 12 hours or so. This is the TTL (time to live) setting. Admins sometimes set this to an artificially low level if they need the ability to quickly move the site to a new server.
You can determine how often it expires by going to a command prompt and running:
nslookup
set debug
www.theserverdomain.com
At the top of this will be a section that says "AUTHORITY RECORDS:" with an item under it that says "ttl".
Now, (and I'm making an educated guess here), what's probably happening when you query your DNS server to resolve that host name your server will have this value cached.
However, once it expires the your server will have to contact another server upstream to get the ip address resolution, called DNS forwarding. If there are a lot of hops between yours and the remote server OR if one of the DNS servers between the sites is overloaded then it could timeout and send back the message you are receiving.
If this is true then the ONLY thing you can do is hardcode the DNS and IP address combination in your web servers hosts file. This is usually at C:\Windows\System32\drivers\etc and is a file named "hosts". There is an example on how to properly edit this within the file itself.
Once you create the host mapping in that file, your web server will no longer have to contact the DNS server to perform name resolution and it won't matter what the TTL is set to.
The only danger here is if they move the web site to a new IP address. At which point you could simply update your hosts file again...
The first thing I would check is if DNS is no longer correctly configured or malfunctioning.
Try (from a Windows command line)
nslookup MyDnsNameHere
and see if you get the IP you would expect.
I'm setting up a (ASP.NET) website to be used internally at my company. In IIS, I've turned on Integrated Windows authentication and turned off anonymous access. Once I've done this, the website pops up the "enter your username/password" box whenever you visit the site, but won't log you in even if the username/password are correct. This happens even if you're logged in to your computer with a domain account as opposed to a local account.
However, if I enter the IP of the site in my hosts file, the site works perfectly (logs the user in without the additional challenge).
I guess I have two questions.
1) Why does the hosts entry have this affect?
2) How can I get the site to succeed without a) forcing everyone to edit their hosts file or b) the site challenging them and failing to log them in?
EDIT: I checked, and we do have our DNS server set up to point those URLs to the correct servers. That's why pinging the URL displays the right IP. However, it appears that in addition to having that DNS entry, we also have to have the hosts file entry for the site to work.
You probably are having an issue with Kerberos authentication.
Since you're using a url of Site.DomainName.com, I'm assuming DomainName.com is your AD's name also.
On the server that's running IIS, copy SetSPN.EXE from the resource kit tools and run the following:
setspn -A http/site.domainname.com IISServerName
Where SITE is your URL and IISServerName is the name of the server.
This sure sounds like a dns problem. Does the dns server know about the hostname you are using? Sounds like the dns server does not know the forward lookup (hostname to ip) for the host you are trying to connect to.
We recently set up an intranet site with windows authentication here. The network guys setup a group policy and pushed changed to IE and Firefox.
For IE, it added the site to "Intranet Sites" and for Firefox it modified the configuration file so that our intranet..com would be trusted.
So... we got it to work. Here's what happened.
While looking around at the DNS Manager on test.DOMAINNAME.com, my coworker noticed that a different site on the same server was set up as a "Host (A)" entry, whereas the site we were working on was set up as an "Alias (CNAME)" entry. Several other sites on that computer were also set up as Alias entries, and he mentioned that the one site with the Host entry was "rock-solid", and he'd had sporadic issues with at least one other site that was set up as an Alias.
We talked to the AD/DNS admin, and as a test, he switched our entries from Alias to Host, and once we cleared our local DNS caches, it worked perfectly (without requiring entries in our .hosts file).
So the question still sorta stands. This was a Win2k3 box serving as one of three internal DNS servers, and making this modification fixed our problem. If anyone can add any additional information, we'd be very grateful, but in the meantime, we're debating going back and fixing all our other sites.