Archive of UserLand's first discussion group, started October 5, 1998.

Troubleshooting a Nirvana Server installation

Author:Dave Winer
Posted:12/25/1998; 1:14:49 PM
Topic:Troubleshooting a Nirvana Server installation
Msg #:1729
Prev/Next:1727 / 1730

What is Nirvana Server? Nirvana Server is a codename, for the server-side of Frontier 6. You may hear us refer to it as mainResponder, it's the same thing. Frontier's server-side architecture is built around responders and the server side of Frontier 6 is implemented in a single responder, the main one, therefore its name is mainResponder. It's like main in a C program. It's a beefy responder, it defines a higher level server with subscriptions, guest databases, membership, profiling, discussion groups, etc, all the new tools you see us using here on userland.com and scripting.com. On Christmas Eve 1998 we did the first release of the software to a small group of testers. People are hitting common bumps. We'll try to smoothe them out in the future, but in the meantime here are some things to look for. Be sure your web server is turned on From Frontier's Web menu, look in the Web Server sub-menu, if the first command is called Stop then your web server is running. From a script you can tell if the web server is running by calling inetd.isDaemonRunning (@user.inetd.config.http). Perhaps we should have the cloneNirvana script check for this after it does the install? Look in user.prefs The one that trips up most installations is user.prefs.mailHost. If you've never run a script that sends email thru tcp.sendMail you probably have never set this value. Nirvana Server sends email as part of its mail loop for registering members. To get this to work set user.prefs.mailHost the the domain name of the SMTP server you use to send email. user.prefs.mailAddress and user.prefs.name are used in macros in many default NS web pages. You might want to check these values and see if they make sense. Logging settings Look in user.log.prefs. We recommend that servers only log into guest databases, not to outlines or text files. Logging to guest databases is 7-by-24, if you log to outlines you'll eventually run out of memory and your server will bog down. If you log to a text file you'll just have to parse the text file if you ever want to write scripts to operate on the data they accumulate. Restart Frontier I got cocky and thought you could completely run NS without restarting Frontier. We now know that you will get errors if you don't restart Frontier. So before wasting too much time hunting down server problems, try quitting and relaunching Frontier. This *will* cure at least one problem, described below. The new version of webserver.server depends on a new table, system.temp.Frontier, that's created at startup. At the head of the routine it loops over system.temp.Frontier.startingUp, guaranteeing that no request-processing code will execute until all guest databases have finished starting up. Unfortunately, this table is only set up in system.startup.startupScript (and it's right that it be that way) so unless you restart every HTTP request will fail! A word to the wise, save time, restart after installing the new stuff. config.mainResponder.urls We initialize the strings in this table so they'll work when you're testing the server out on the same machine. When you want to access the server from a remote location, you'll have to edit all the URLs in this table so instead of pointing thru localhost they use your domain name. We could have initialized them with your domain name, thanks to tcp.dns.getMyDomainName, but then, we found, cookies don't work reliably, at least with some web browsers. (I was using MSIE 5.0b2/Win.) Questions? If you have questions, post them as a sub-message and I'll try to incorporate the answer in this page (and in a reply to your message.)



There are responses to this message:

This page was archived on 6/13/2001; 4:46:59 PM.

© Copyright 1998-2001 UserLand Software, Inc.