PDA

View Full Version : Web Interface


benj180
May 9th, 2008, 04:40 AM
Hi again!

We have installed the web interface and configured it to run on port 5555 on our server, however the interface will not load at all even from the server itself. The service is running, we have tried http://localhost:5555, http://192.168.10.1:5555, http://127.0.0.1:5555 but no joy. we haven't restarted the server since the service was installed would this need to be done?

Kind Regards

Support Team
May 9th, 2008, 05:27 AM
Hi,

It sounds like the Web Interface service is being isolated, probably by a security program on your server that doesn't let any incoming traffic to it and this is why it doesn't answer. Please try to check the following:

1. The most common problem for this is with DEP (Data Execution Prevention). It is part of Windows Server 2003 (maybe earlier versions as well). You should open DEP settings and allow RangerMSPWebInterface service to accept connections. We have received similar reports before about the same problem and they were all fixed by changing the DEP settings.

DEP can be found under System Properties -> Advanced -> Performance - Settings -> tab DATA EXECUTION PREVENTION.

Make sure you allow the RangerMSPWebInterface service (its executable is found in <server>\RangerMSP\WebInterface\RangerMSPWebInterface.exe

2. Sometimes it is required to reboot the server for the changes to take effect.

3. Try to access the web interface and make sure you use the same IP address you use in the RangerMSPWebInterface.ini file.

4. If all this doesn't help, you should try modifying the .ini settings to 127.0.0.1 restart the service and then open a browser while running on the same server and go to http://127.0.0.1:4961 , this will let you check whether the service answers (i.e. remove the option that an external settings, like in your firewall, is incorrect).

I hope this helps.

Eitan

JoshuaB
April 14th, 2009, 08:31 PM
I'm having a simliar problem. I'm testing CommitCRM (trial) and trying to set the web interface to port 80. I have adjusted CommitWebInterface.ini to reflect 80, on WinXP box with firewall off. I've restarted the server and rebooted, but it 80 won't work. I can change to a random other number (7777) and it will work, or back to 4961 and those work, but not 80. netstat -an doesn't show 80 listening at all. Any suggestions? Thanks.

ajgyomber
April 14th, 2009, 08:45 PM
Joshua,

If you are trying to access the web interface over the Internet, I'd guess that your ISP is blocking port 80.

--AJ

raycollazo
April 15th, 2009, 12:03 AM
Do you have another web server instance running on XP? Try doing a 'telnet localhost 80' and see if you get an answer. My guess is that there is another service running on 80.
If you have IIS installed on the same machine, try disabling it and restarting CommitCRM Web service and trying it again.

Support Team
April 15th, 2009, 06:27 AM
Hi,

Thanks for your comments, all are correct. Port 80 is used as a standard port for other applications and shouldn't be used for the RangerMSP Web Interface. The way it works is that the RangerMSP Web Interface listens to a proprietary port. Port 80 is not a legal value for the RangerMSPWeb Interface port (as mentioned in the INI file above the port definition section).
The port number should comply with these conditions:

1. This port should not be in use by any other application or service.

2. The Port number should be above 1024, except Port 8080.

It is most recommended to stay with the predefined port which is 4961.

Ethan

JoshuaB
April 15th, 2009, 08:20 AM
Thank you for your reply. However, I'm curious why CommitCRM wouldn't allow you to configure any port you wanted. I feel 80 would be easier for us to access remotely as it would work by default in the browser. Have you excluded this simply for additional security?

My fault on missing this in the ini file. I didn't read it! ;) Although it does say "recommended" and not required.

Also, although the setting in the ini is ServerIP, I have specified a hostname and it appears to work. Will this cause any other problems?

Support Team
April 15th, 2009, 09:16 AM
I know the port limitation is something technical which requires using only ports larger than 1024. I'm not sure what the exact technical explanation for this is, I just know all that the ports under 1024 are considered proprietary and cannot be used for such implementations.

Yes, you can use the hostname or your DNS in the IP settings. Note that the hostname will probably work when using this on your internal network, however, if you want it to it to be accessible you should probably use your DNS. You can find more information about this in the Web Interface setup guide here.

Ethan

natrat
April 18th, 2009, 03:23 PM
One annoying thing I've found about the web interface is if you specify the WAN IP in the ini file, you are then unable to view and test the interface from within your LAN. You get the login page but it doesn't work after that. You have to change the web server IP in the .ini to the LAN IP to view/test locally. Maybe thereis some jiggery pokery you can do in the router to fix this but I don't know what it is. Just makes it tricky to see an issue or whatever that my external contractors are seeing. Is there a wast way around this? Or am i the only one who gets this issue?

JoshuaB
April 18th, 2009, 03:43 PM
Natrat,
Using the host name from my PC, while host name is in ini, and works from my own local LAN. Not sure why yours wouldn't. Like you, I wonder if it is an option/limitation of the router. If you specify public IP in your INI and use the IP from your browser, does that work?

natrat
April 18th, 2009, 05:00 PM
ummm...it's now started working, so ignore me!

nattivillin
May 29th, 2009, 09:46 AM
We are also having a problem using the web interface on our server. Should I start a new thread or continue on this one?

JoshuaB
May 29th, 2009, 10:00 AM
nattivillin,

Shoot out the details.... what's going on and what have you tried?

nattivillin
May 29th, 2009, 10:27 AM
We have several retail stores. We have static ip's at each. On the server we chose, i set the ip in the configuration file to the building's wan IP. I then forwarded the port 4961 in the router to go to the internal ip of the server. tcp and udp.

Nothing worked. I changed the ip back to local host (127.0.0.1) and i can get to the logon page internally. So i guess the CommitCRM server is running. Netstat tells me port 4961 is listening and no other connections. A port scan tells me port 4961 is open.

I changed the CommitCRM ip configuration to the server's ip and we cant connected even on the same lan. All our stores are connected via gateway vpn. Using the wan ip or the internal lan ip same results. I added CommitCRM to DEP and restarted the server. No change. I restarted the CommitCRM server on each ip change.

Did i miss anything?

Support Team
May 29th, 2009, 11:14 AM
nattivillin,

First I believe that we should make it work on your LAN, where the main server is, only then you should try to access it from the outside.

I recommend that you:

1. Charge the IP in the file to the local IP address - the IP in the server your LAN - assuming that the server is a "standard" server on this LAN - not behind any firewall/router/etc.
I also recommend that, for now, you remove and port forwarding setting.

2. Restart the RangerMSPWebInterface service.

3. Open a browser on your server and go to: http://your-lan-server-ip:4961

4. If this works, go to a client PC on the server LAN, open a browser and navigate to http://your-lan-server-ip:4961

Once this works we know that RangerMSP Web Interface is running well and is not blocked (by DEP for example).

5. I would now recommend that you setup a DNS entry instead of the IP address - on the server LAN make sure this name is translated to your local IP address (so local users will be able to access it), then make sure the name is translated to the external IP address for all remote offices.
Once the DNS is set up correctly change the .ini file and type in the domain name for the Web interface. Restart the service and make sure you can access it from your LAN PCs (open http://your-web-domain-name:4961 in your browser and wait for the login page)

6. Next you need to try accessing it from the remote sites - verify the the domain name for the Web interface translates correctly and in the remote sites and try to access it - open a browser and go to: http://your-web-domain-name:4961
If you do not get the login page make sure the the remote site can communicate to port 4961, and then, if needed, add a port forwarding so remote sites will be able to access the server where RangerMSPWebInterface is installed.

Please post back with a status update.

Ethan

nattivillin
May 29th, 2009, 12:14 PM
I changed the CommitCRM configuration to the servers ip and i can log in from any of the company pc's. (i only tried 3 but, each from different offices). Where do we set up this dns entry?

Support Team
May 29th, 2009, 12:42 PM
Thanks for the update. As it works on your LAN it should work on your WAN as well once port forwarding and dns are set up correctly.

You should first define the DNS setting on your LAN server and on each of the remote sites servers (or just one if all remote sites share a DNS server) - the name should always translate to the server where RangerMSP Web Interface is installed, locally - it will translate to a local IP address, and on remote sites it will translate to external IP address of the server.

Once the name entry is set up correctly (check with nslookup from local and remote sites), change the RangerMSPWebInterface.ini file and replace the IP address with a name - RangerMSP.mydomain.com. Restart the service and perform tests, first locally and then remotely.

Let us know how it goes.
Ethan

nattivillin
May 29th, 2009, 01:05 PM
I'm confused by the suggested configuration. If we access the web interface locally, then we can leave the settings like they are. If we want employees / customers to be able to access the web interface from the web, then we can setup a sub domain with a A record to point to our external IP. if we change the internal DNS servers to point to our own server, we are essentially reverse translating the name because netbios already resolves ip to name. The only way to change the internet dns servers to find us with commitcrm.mydomain.com is with a change at our domain registrar right?

Support Team
May 29th, 2009, 01:19 PM
With your registrar set it to the external IP address - so everyone will be able to find and reach your server from anywhere (including remote sites if they have standard Internet access, which they probably do).

However, you should overwrite these settings (for this specific sub-domain) on your LAN (where the server is) and have it translated to the local IP address of the server, not the external one, so LAN access to the Web interface will not need to go through the Internet as the server is located on the same network (you want your LAN PCs to go directly to the server).

I hope this makes sense.

Ethan

gshepherd
August 24th, 2009, 05:15 PM
we have created a subdomain with our registrar and set it to redirect to our external IP with the :4961 port , and this doesnt seem to be working. Are we doing something incorrect with GoDaddy?

Our site is not hosted on our boxes here, we used a reseller but a redirect from the registrar shouldnt matter correct? If I type in the IP and port number in my browser it comes up fine...

JoshuaB
August 24th, 2009, 09:00 PM
gshepherd, if you ping the subdomain (name.yourdomain.com), does it resolve to the same IP you are typing in?

AN-Tech
August 25th, 2009, 07:58 AM
gshepherd,

Are you trying to redirect a domain name through your registrar's DNS like CommitCRM.domain.com to an IP address and port like xxx.xxx.xxx.xxx:4961? Or are you saying you have a web page setup on a site someplace that when you go to http:// CommitCRM.domain.com it forwards to http://xxx.xxx.xxx.xxx:4961?

I think we need some more information to help.

AlexAtALCON
October 6th, 2009, 08:46 AM
CommitCRM Team,

CommitCRM is a great app, but the limitation on not using port 80 is very disappointing. Since its good enough to be customer facing, I would love to be able to have a simple URL for our customers to use (i.e. no port numbers). I STRONGLY advise you to repair this issue and allow port 80 to be used. After all, you access port 443 connections for HTTPS, so why not port 80 for HTTP?

Support Team
October 6th, 2009, 09:16 AM
Hi AlexAtALCON,

Thanks for your feedback on this. I know that the port numbers a limited in this way due to a technical limitation, however, this feedback has come up in the past and we will try to look into this again in the future. Thanks for bringing this up here.

Note that at the moment, rather than send your customers to the URL with the special port number, you can embed the web interface login page into your website. You can do this in one of the following ways:

Option 1 - sets a link that loads the RangerMSP web interface default login page.

Option 2 - allows you to use your own customized login page within your web site.

Please review this user manual page which precisely describes these options.

I hope this can help!

Sheli

lonecrow
November 30th, 2009, 04:15 PM
I would like to add my voice calling for the removal of the port 80 restriction. As far as I know one port is as good as another technically speaking. Any assignments or restrictions are simply a matter of convention.

Support Team
December 1st, 2009, 07:03 AM
Hi,

Thanks for your feedback on this.
I've added your vote to this feature request, as well as your comments.

Regards,
Reno Breen

Easy I.T.
December 2nd, 2009, 04:26 AM
Hi All,

We use a workaround to allow us to use port 80 (ie just CommitCRM.domain.com ). REDIRECTION -

We have IIS running on the same server and have a virtual site (with host header value for CommitCRM.domain.com) then for the home directory settings simple redirect it to CommitCRM.domain.com:4961

Allows for us to just type CommitCRM.domain.com and then it automatically redirects to CommitCRM.domain.com:4961

Cheers,
Jeremy

Support Team
December 2nd, 2009, 07:43 AM
Hi Jeremy,

Thanks for posting this workaround.
We'd like to take some time to test this; and if this checks out, we'd really like to make an article for this topic, for our knowledge base.

Thanks again for the help.

Reno Breen