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.
