Forum OpenACS Q&A: Failure to connect to AOLServer from another PC

I completed the RPM Installation of OpenACS, Postgresql, and AOLServer
from the RPM's provided by Jonathan Marsden, all installed on RedHat
7.1. After an initial glitch the installation proceeded smoothly. I am
able to connect and modify the OpenACS installation from the local
machine operating on port 8000. I have made a Wimpy Point
presentation, added bulletin boards and items. In fact I have played
with just about all the modules through the main admin page. Only a
few glitches noted here and there...My problem, I cannot get any other
machine to connect and display the initial logon page. My local
machine will not connect using "localhost:8000", but does connect with
it's own name "saturn:8000". From another machine I am able to ping
the AOLServer machine successfully. The service IS up and running. I
am posting this messsage from the AOLServer laptop, so I am assuming
the network settings are fine. AOLServer is NOT serving the pages to a
remote client. I am at a loss to explain what is happening here, while
I am not new to Linux, I am new to the Redhat 7.1 version, with 5.2
being the last version I have any real experience with...

Thanks for your time...

Gil Price

Yep, that was it! I hated asking the question as I was sure it had been asked and answered before, but a visual search through the bboard didn't turn up the proper thread.

Thanks Ola,

Gil

This really comes down to ensuring that servers have correct IP
addresses, hostnames, /etc/hosts entries, and DNs entries.  Right?

I made this config item default to the host name because that is what
works for the huge majority of cases -- if you have no host name at
all the RH default is localhost.localdomain or some such thing, which
/etc/hosts says is 127.0.0.1, so even that degenerate case was taken
care of.

I'm unclear why a server machine would have a hostname of 'saturn' in
todays Internetworked world -- surely it would be more like
'saturn.somedomain.com' or whatever?

I'd go as far as to suggest that rather than haing your AOLserver
config point to the raw IP address (will you remember that when you
relocate the server in six months time?), it would be more appropriate
to ensure your DNS setup for the server is correct and matches the
hostname of the machine concerned.

As far as I can tell, what you have found is really a workaround for
inconsistent or missing domain name service... am I right?

Ola, I think your problem is a configuration issue on your LAN. I have no trouble connecting to http://www.infogettable.net from here. In an IPChains/IP Masquerading setup, it can be a little tricky to get the LAN routing working right.

The quickest, easiest way to get this to work from local machines would be to add an entry to /etc/hosts on each machine, which points to the local address of the webserver (make sure your firewall is configured to allow connects on the local interface, but it probably is).

C:WINNTsystem32driversetchosts.

As the originator of this thread, let me add a few things, the laptop was named saturn, in the domain of .sc.rr.com, while the laptop was off of any network it would connect to ACS with either http://saturn:8000 or as http://saturn.sc.rr.com:8000. Once it was connected back to my LAN behind the router connected to my cable modem it was not accessable from another machine as either of the 2 URL's above, or by it's IP address (http://10.104.168.27:8000). I do not have a DNS behind my router, and this IP address is not set up in DNS as it is in the "private network" class. Ola's suggestion was just the ticket for me to complete my "proof of concept" to myself. This laptop also must travel to other network segments throughout the southeast for show and tells. Ola's suggestion will allow quick modification to the nsd.tcl file and allow others in these temporary locations to connect and try out the system before a decision is made to go live and commit resources in our organization. Using a server at the office, I am configuring another machine using the RPM installation for RH 7.1, this one will be registered properly on one of the WAN DNS. I had already used the modified "hosts" file to connect, but don't relish this as a solution for an enterprise of 5000+ employees.

I must say, I love the RPM installation, and will be having more questions as I get into the ACS more. Thanks all for your help in getting me moving along.

Jonathan,

I totally agree with you, but in the WAN I operate in, I am but a small cog on the far edges of the network. I am in a field office of a much larger organization (WAN) that stretches from Singapore to Brussels with many stops in between. I'm using my laptop as a proof of concept for office managers in one small part of the WAN. If they decide to go ahead with a test implementation, then a true server with a FQDN and DNS registration will be installed at our regional hub in Atlanta and serve just the needs of the southeast for 12 months or so. Based on need or success of the pilot implementation, the system (OPENACS) will then be moved to the center of the WAN and will be made available to all on the WAN.

Your post about "split horizon DNS" intrigues me though. As I'm not an Administrator at the Domain level, I'll research the concept and then float it up to the Domain Admins in OKC.

Thanks for your valuable input and of course for the RPM packages...I've successfully installed them on 4 seperate machines with minimal problems so far...

Thanks,