Forum OpenACS Q&A: why cannot see the pages outside of my machine?

I installed the openACS, and can successfully see the default pages on
my own linux machine by Netscape using machine name and port. But I
cannot access it on any other machines.

What's the possible reasons for this problem?

Thank you very much!

--Ke

Most likely your machine does not have DNS or its hostname set correctly.

Check that the commands

   hostname
   grep `hostname` /etc/hosts
   nslookup `hostname`

all return expected and consistent information on your own machine. Then use nslookup on the other machines to look up mymachine.mydomain.com (if that is the result of the hostname command on the OpenACS server machine!). I suspect that the other machines cannot convert mymachine.mydomain.com (or whatever it really is) into an IP address using nslookup>, because you do not have DNS correctly set up for that machine.

If you are unable to set up DNS and are in a 'experimental' mood, you might find that putting an entry something like:

1.2.3.4 mymachine.mydomain.com mymachine

into /etc/hosts will act as a temporary workaround (replace 1.2.3.4 with the actual IP address of the OpenACS server concerned!).

Documentation Team: Is this in the docs and/or the FAQ? It seems like it ought to be....?

I haven't tried Jonathan's workaround, which sounds like it might easier than what I've done.

I have a few machines on a LAN at home with no DNS. As described here, I'm viewing pages served by my dev oacs box by hitting it by IP address, which did not work until I commented out all of ns_param hostname and ns_param location lines in /etc/aolserver/nsd.tcl. This isn't especially pretty, since you have to hit your site by IP address, but if you aren't interested in setting up an actual DNS entry for the dev box, it works.

Collapse
Posted by Yon Derek on
Also make sure that AOLServer is binding to an IP address and not localhost (127.0.0.1). You can run nsd -ft nsd.tcl (the key here is -f option that tells to start in a foreground mode where AOLServer dumps the info to console window). AOLServer will print a message saying that nssock has started listening on ip address x (or something similar).

You can test Jonathan's DNS theory by doing ping machine_name from the box that cannot access your site. If ping works then it's something else. If it says something like "machine unknown" then it's DNS problem.

Collapse
Posted by S. Y. on

The whole point of DNS and NIS (formerly YP) to prevent having to use a local file (/etc/hosts) and make network administrators' lives easier. However, putting IP addresses and hostnames in local files (e.g., /etc/hosts) works great if you've set up your own internal network, etc. That's why in /etc/nsswitch.conf you can see that hostnames can be resolved in a variety of ways (files, nis, dns).

Typically DNS is used to communicate information about domains, hence its name. NIS is used within organizations once network administrators get tired to managing a master /etc/hosts file that needs to be rcp/scp'ed to other machines; maybe this is thirty or forty machines or when a second subnet gets thrown in.

The basic reason for having hostnames in the first place is to make it convenient for humans to remember, i.e., so you don't *have* to type in IP addresses.

A sample master /etc/hosts:

    192.0.2.1  router gateway gw mail smtp
    102.0.2.11 server www web
    192.0.2.21 workstation1 ws1 john
    192.0.2.22 workstation2 ws2 chris
    192.0.2.101 laptop1 lt1 jane
    192.0.2.102 laptop2 lt2 pat
    192.0.2.103 laptop3 lt3 sam
    192.0.2.200 printer laserjet lj
    

Note that in the above example, I deliberately matched computer "IDs" (e.g., workstation1) with the last digit of its IP address. If I had mismashed the entire thing, it gets harder to remember.

In isolated networks at conferences I've used state names plus a few cities (we actually had fifty clients plus a few miscellaneous admin/instructor boxes).

    192.0.2.11 alabama al
    192.0.2.12 alaska ak
    192.0.2.13 arizona az
    ...
    192.0.2.101 sanfrancisco sf
    192.0.2.102 sanjose sj
    192.0.2.103 chicago
    

We actually put this file on a master drive (along with demo content, etc.) and cloned the entire drive as prep work. Boot single user, change the appropriate networking stuff, and boot up multi-user under the correct individual hostname/IP address.

Also I've done this stuff on a limited basis with /etc/passwd and /etc/group as well.

This is basic TCP/IP networking stuff that is covered in any *nix system administration manual. None of this is Web specific; it's just basic networking. Assuming you haven't disabled these services, you should be able to ping, traceroute, and (maybe) telnet to machines in your network by IP address and hostname. If you can't, your network is misconfigured, not your web server.

Note on AOLserver: if left undeclared, nsd (just like Apache) will listen on all configured network interfaces, and on all IP addresses. The main reason is declare IP addresses, etc. is to make sure that the web server doesn't listen on a particular interface (e.g., a second Ethernet card). That's also why if you're running the nscp module, that you have it configured to only listen on localhost, forcing you to telnet/slogin to the server, and (hopefully), confirming that you're a legitimate user and not some random loser.

It's helpful to play with a small 2-3 machine network setup; by learning the concepts of basic and correct TCP/IP networking, you will find that your local network will be a much easier place to inhabit.

Thanks people, that was an informative discussion.  In particular, the  info that AOLserver listens on all addresses if not provided with any specifics is new to me.  I think this may be the "right" thing to do in a default template nsd.tcl for newbies.

At the time I created the RPMs, I was (and still *am* in many ways) a relative newcomer to AOLserver and ACS, so I was trying to keep as many of the "ACS community guidelines" as I could, while also staying reasonably close to the RPM community norms (don't install into /usr/local, and so forth).  I simply assumed that the supplied sample nsd.tcl with the specified host, portname and address parameters to nssock was the most appropriate default setup, so I used it, changing
only enough to avoid needing per-machine editing, and to cope with the Linux FHS-style directory locations I wanted to use.

Now I'm older and wiser (!), I'll look into changing the supplied default config to something that makes life easier for newcomers in future RPMs.  I just did a quick check, and it looks like commenting out the host and address params for nssock is all it takes.  In which case... why were they in the default nsd.tcl (part of the OpenACS 3.x install instructions, I think) in the first place?  Does anyone know?  This isn't a criticism of whoever created it -- it's a genuine question.

As Sean points out, it is a good idea for anyone doing system admin work to understand hostname-to-IP and IP-to-hostname mapping well (personally, I prefer to avoid NIS and friends and just use DNS, since you'll have to use DNS for your external Internet-accessible hosts anyway, and so it's one less technology to worry abut if you can use DNS on the internal LAN too).  More importantly, though: if we can easily make AOLserver and so OpenACS more accessible "out of the RPM", then we should do so, to minimize unwanted and unnecessary frustration for newcomers.

Collapse
Posted by S. Y. on

The default behavior for nssock (e.g., ns_param address) is not a secret; it is clearly documented in the AOLserver Administration Guide: http://www.aolserver.com/docs/admin/con-ch3.htm. As I mentioned before, this is typical UNIX web server behavior (Apache, Netscape, NCSA httpd), and this has certainly been the case with AOLserver since version 2.3.

A typical UNIX newbie error is to alias a hostname to the loopback address (127.0.0.1 localhost); I really discourage people from messing with the loopback address. If you need to set up a bogus hostname/IP address, use a dummy network interface: that's what it's there for.

Because of its very nature, the essentials of TCP/IP networking are best learned in a workshop/classroom environment, i.e., several people working together. I'm generally a do-it-yourself type, but networking is one topic that do-it-yourselfers really lose most of the intrinsic value of working together with other people. You and others will likely make different mistakes. Learning to solve network problems together will help your networking knowledge enormously. If you've ever tried to debug a networking problem with someone else (e.g., ISP help desk), well, you probably know what it's like.

Some Linux User Groups (LUGs) apparently have install fests; these would be pretty good places to have TCP/IP network administration workshops; I don't know if groups generally do this though.

One of the biggest errors ACS/OpenACS newcomers make is not taking a methodical approach and just plowing through the ACS/OpenACS installation willy-nilly without verifying if the individual steps were correctly done (the number one and two problems were messing up the nsd.tcl and ad.ini configuration files).

As the author of the very first "ACS on Linux" tutorial, I admit that my articles certainly did not offer a great variety of tests, but I did mention some things that could be tested (e.g., serve up static HTML pages on AOLserver before compiling the ArsDigita Oracle8 database driver). If I remember correctly, there used to be a Pset 0 that required a certain amount of knowledge in a *nix environment (sort of like remedial English Composition for crappy writers like me); there was probably a section on learning Emacs. :-)

I never thought that I had the ability to teach *nix system administration in 30 minutes (or even in a couple of hours) and I clearly pointed out my shortcoming in my articles (now mercifully a part of the Great Internet Null Device in the Sky). If you don't know *nix, get a basic sysadmin book and read it.

As to why the OpenACS 3.x config files are the way that they are: it's just legacy crap. OpenACS 3.x derives from ACS Classic Tcl 3.x. Originally ACS Classic was built on http://photo.net, a "Big Iron" HP-UX server at mit.edu that had over 11 network interfaces (I remember, because the original Oracle 8.0.x to Oracle 8.1.5 upgrade failed due to a certain Oracle bug). Thus, the ACS sample nsd.ini file was built on a machine that needed to define an individual IP address and hostname, because there were other web servers running on the same machine (e.g., homepage.lcs.mit.edu - or something to that nature). A little piece of worthless ACS trivia; I can't believe I reserved some neurons to remember that... ;-)

Sean,

Thanks for the ACS history lesson :-)

While I agree that folks wanting to run OpenACS with no Unix networking background would be well advised to acquire some, and those with no system admin background would be well advised to read a good book on the topic... today's newcomers do not have that expectation.

People now seem to want a system that is very easy to install and start playing with, even withou reading the docs; only then will they be willing to make the learning investment necessary to use what they just installed more seriously.  Old-timers who grew up flipping switches to enter the bootstrap loader on a PDP, or whatever, may well feel that today's generation is asking an awful lot :-)

My next set of AOLserver RPMs will have the host and address parameters for nssock commented out, which will hopefully make "getting up and running" easier for some folks.

Collapse
Posted by S. Y. on
People now seem to want a system that is very easy to install and start playing with, even without reading the docs; only then will they be willing to make the learning investment necessary to use what they just installed more seriously. Old-timers who grew up flipping switches to enter the bootstrap loader on a PDP, or whatever, may well feel that today's generation is asking an awful lot :-)

I know, I know. (sigh) When I was maintaining my own set of documentation, there were always a few people who wanted the Macintosh-style "click the Continue button to continue" installation experience. I'm not asking people to be Michelin 3-star chefs, but those Swanson turkey pot pies sure sell well.

People, no matter how much experience they have, should anticipate the possibility of running into problems. Good luck with your updates.

Collapse
Posted by S. Y. on

A little more trivia about the ACS 3.x nsd.tcl file:

At least in 1998-99, ArsDigita typically used servers with multiple IP addresses. Machines were used to host several sites, typically a production site and a development site; other sites on the same machine also included a document or staff site and maybe a staging site. Each ACS instance was tied to a separate IP address. Some aD machines actually hosted several different client sites, but maybe no dev sites. They did not use virtual host redirecting. I have no idea what aD does nowadays.

At least in ACS 3.x, there's a lot of legacy cruft. I don't know anything about ACS 4.x/OpenACS 4.x since I've never looked at it.