I have a vcenter setup which I'm accessing using the HTML5 interface. Since a couple of days, the client is empty (not displaying the hosts or VMs or datastores). This happens on all browsers I tried.
In the browser console, I see:
XML Parsing Error: no root element found Location:
https://10.16.2.99/ui/navigator/navigate/tree Line Number 1, Column 1:
Below how it looks like:
Have you tried restarting the vsphere-client service? This is the service assigned to the vSphere (HTML5) Web Client.
Some examples on how to do this: https://kb.vmware.com/s/article/2109887
Related
I have my rails 5 website on an AWS server, everything works fine for me but i need to change region due to problems with sending emails, i created an image of my instance using the information in this web page and then i executed it specifying the new region but when i tried to access through the ipv4 address the page stays loading and doesn't show me my website that worked well in the other instance, i tried to access through the console using the key pair and all the files from my previous instance are there. my server uses nginx. what could be missing?
You may be trying to access the old IP address. When you moved the instance to a new region it will get a new IP address.
Another possibility is that the web server on the server was not started automatically. You may have to configure that to start on boot. The procedure may depend on how you set up the server.
I am doing a POC with my team as we are introducing WSO2 components and am working with the API Manager 3.0.
I seem to be having issues loading the WSO2 API Manager / API Publisher on the defined URL;
https://[ip address]/publisher
The page is not loading and I keep getting a spinning circle.
Steps I have taken:
Stop API Manager at command prompt with [Ctrl + C] command
Modified deployment.toml file specified paths for the localhost to our IP Address, API [publisher, gateway and store] URL values to use our IP Address as well.
Changed carbon.xml and api_manager.xml
Start API Manager with wso2server.bat --run command
Issues are as follows;
api_manager.xml values are reset to localhost and not the IP Address I modified it to.
The API Publisher page is not loading and I am not able to get to the API Publisher login page.
I am an administrator on the Windows Server hosting this, so all changes are made as admin.
First of all, APIM 3.0 has a new config model, where all configurations are available (only) in deployment.toml. All other configurations are populated based on that, and shouldn't be changed manually.
Second, you don't need to replace all occurrences of localhost to IP as many are local calls.
Third, the correct URL should have the port, unless you have a reverse proxy in front of API.
eg. https://[ip address]:9443/publisher
Sounds good and thanks for the input. I will give this a try and post back to the thread.
I am using the IP and Port for now with no reverse proxy but plan to add one, once I can get through this part.
Much appreciated.
I'm trying to create a web app on AWS and I'm running into port issues. I would like to have multiple apps providing different services on different ports. I've created a website (on the same instance) to receive a text query and pass it to my app on port 3000. The app listening on 3000 is written in CherryPy.
We are using a VPN to provide security for the AWS instance. When logged into the VPN, everything works fine. The web page loads, the query returns the correct data. When I disconnect from the VPN, or someone else goes to the page, the page still loads, but queries to the service time out.
I've used netstat to make sure the service is listening but I'm not sure what could be blocking traffic. I've worked through the CORS issues as evident by the fact it works when I'm signed into the VPN.
What can I check now?
When I disconnect from the VPN, or someone else goes to the page, the page still loads, but queries to the service time out.
My assumption is that the web server and the app are on the same server.
It sounds very much like the connection from web server to app is happening via a routed IP address rather than localhost. In addition to being slower, it's also hitting your firewall rules.
Configure the web server to access your app on localhost:3000 and the issue should clear up.
I actually got it working. I have an AWS instance with nginix and CherryPy. When the user goes to a web address, the nginix page loads with a form for a query string. When they submit a string, the string is POSTed to a CherryPy service running on port 3000. The CherryPy service does some computations and returns a result via JSON.
I thought I had opened up everything completely for testing, but I was having so many issues. It turned out that having CherryPy set
"Access-Control-Allow-Origin" = "*"
wasn't working, instead I needed to specifically set the origin of the calling page.
I created an ExtJS 5 application with Sencha Cmd.
I will deploy this application in a tomcat server where there are some REST web services.
I would need to use these web services but when I run the application with "sencha app watch" (on port 1841) it doesn't find the services because they are on a differente server (tomcat is on a different port).
How can I use an "external" web service with Sencha CMD?
Thanks
stefano
Here are some of the available options:
Option 1 Proxy Web Service
You could create a service on the local machine where the sencha app is that create web requests that then goto the target remote services. This is called a proxy service.
Essentially the proxy service will take a request and resubmit it to the desired target remote machine.
There is a php example here
And a C# web request example here (Although this c# example isn't exactly what you are needing. The base of the web request that would need to be submitted is in this code. )
Option 2 JsonP
The other option off the top, is if the web services on the other machine support jsonp they should be accessible. However, jsonp only supports get so if you have a full rest implementation some services will probably not work.
More information on jsonp
And an extjs request example for JsonP:
Ext.data.JsonP.request({
'url': 'url',
params: {
'param1': 'value'
},
success: function (result, request) {
//success
}
});
Option 3 Hosting multiple apps/paths on single port
However, since it seems like the tomcat server may actually be on the same machine. Is there not a way to host both the web services and the application path through tomcat?
It looks like, for instance, jetty has an option to host two apps on the same port
Option 4 Enable CORS
You can enable cross origin resource sharing on the rest application depending on the architecture/framework used.
The browser will basically send a request first to see if it can access the resource. And then the server would respond with the allowed origin domains. Once CORS is enabled then access could be granted between the two different ports/servers
Great site on CORS with instructions for enabling on most basic setups
Here is example documentation for spring
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.