Hi,

I checked out a fresh version of the HEAD and now I can't get to the homepage, http://192.168.0.100 anymore. It worked a couple of days ago.

AOLserver starts without errors (almost, see below) and listens on that IP, port 80.

These are the only errors I get during startup but they are not related, I believe:

...

[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Querying 
'select count(*) from pg_class;'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: dbinit: 
sql(localhost::dotlrn-test): 'select count(*) from pg_class'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Querying 'drop 
function __test__();'
[17/Sep/2002:11:26:10][15034.1024][-main-] Error: Ns_PgExec: 
result status: 7 message: ERROR:  RemoveFunction: function 
'__test__()' does not exist

[17/Sep/2002:11:26:10][15034.1024][-main-] Error: dbinit: 
error(localhost::dotlrn-test,ERROR:  RemoveFunction: function 
'__test__()' does not exist
): 'drop function __test__();'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Querying 
'create function __test__() returns integer as 'begin end;' 
language 'plpgsql';'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: dbinit: 
sql(localhost::dotlrn-test): 'create function __test__() returns 
integer as 'begin end;' language 'plpgsql''
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Querying 'drop 
function __test__();'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: dbinit: 
sql(localhost::dotlrn-test): 'drop function __test__();'
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Loading acs-tcl
[17/Sep/2002:11:26:10][15034.1024][-main-] Notice: Loading 
packages/acs-tcl/tcl/00-database-procs-postgresql.tcl...

...

When I request the index page, this is what I get:

[17/Sep/2002:11:32:05][15034.2051][-sched-] Notice: Running 
scheduled proc search_indexer...
[17/Sep/2002:11:32:05][15034.2051][-sched-] Debug: 
db_qd_get_fullname: following query in file: 
packages.search.tcl.search-procs proc: search_indexer
[17/Sep/2002:11:32:05][15034.2051][-sched-] Debug: PgBindCmd: sql 
= 
            select object_id, event_date, event
            from search_observer_queue
            order by event_date asc
        
[17/Sep/2002:11:32:05][15034.2051][-sched-] Notice: Querying '
            select object_id, event_date, event
            from search_observer_queue
            order by event_date asc;'
[17/Sep/2002:11:32:05][15034.2051][-sched-] Notice: dbinit: 
sql(localhost::dotlrn-test): '
            select object_id, event_date, event
            from search_observer_queue
            order by event_date asc
        '
[17/Sep/2002:11:32:05][15034.2051][-sched-] Notice: Done running 
scheduled proc search_indexer.

I noticed here that some work on the core has been going on lately. I'm mot saying that this is what broke things, but that it might have been.

Oh, I think I know what it is.  I just applied a patch to make
ForceHostP work.  If you have ForceHostP=1 the server will redirect
to the cannonical hostname (i.e. http://yourserver.com will redirect
to http://www.yourserver.com).  This is normally what you want but
if the hostname you set in your server config tcl file does not
resolve or point at the correct IP you will be hosed.

You can either fix hostname or set ForceHostP to 0 (which should
probably be the default).

Let me know if that fixes it.

You see, my server is only a dev server that I run locally so I can only get to it through 192.168.0.100 (except I can't for the moment).

I did do a total re-install - dropping and recreating the db, etc...

Jeff, I can't set the ForceHostP since I can't get to any of the urls on my setup.

The last snippet above is all I get in the log when I request the index page.

On some Debian boxes the [ns_info address] and/or (can't remember which) [ns_info hostname] does not work, so I usually just enter a valid IP...

David, the issue is not which IP is listened to, it is that
ForceHostP will issue a redirect to the "cannonical hostname"
If the hostname parameter of nssock does not translate to
something the client can resolve the redirect will fail.  It uses
[ns_conn location] to determine the url to which to redirect.
If you are going to use an IP for Address you will also need to
provide an IP or hostname for nssock's hostname parameter
(and 0.0.0.0 for hostname would probably be a bad choice unless you
are only ever going to connect from localhost).

Jeff, I updated using the statement you provided and I restarted the server, but it still doesn't work with the following in config.tcl (this is what worked before).

#set hostname               [ns_info hostname]
set hostname 127.0.0.1
#set address                [ns_info address]
set address 192.168.0.100

What do I have to change?

No luck so far (with 192.168.0.100 as both hostname and address).

debian:~# netstat -an | grep :80
tcp        0      0 192.168.0.100:80        0.0.0.0:*             LISTEN 

I sent you the log file, Jeff. Thanks.

Glarg. I was burned by this one too. The ForceHostP default should
DEFINATELY be 0.

It sounds as if you guys have fixed a variety of ills over the past 24 hours, but I wonder if something has gotten broken in the process. After a CVS update today, my server is dead in the water.

I brought this up over at this thread http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0006DJ&topic_id=12&topic=OpenACS%204%2e0%20Design but perhaps this is a more appropriate place to beg for help.

No pages get served even though the AOLServer starts OK, is listening on the correct port, and ForceHostP is 0. Any page request produces this error:

debug: RP (9.866 ms): rp_filter: setting up request: GET / 
[16/Sep/2002:14:26:44][26713.5126][-conn2-] Error: tclop: invalid return code from filter proc 'can't read "node(instance_name)": no such element in array': must be filter_ok, filter_return, or filter_break

Lars introduced instance_name in several packages/acs-tcl/tcl/ procs. I can't figure out what needs to be fixed here; it's too deep in the plumbing.

I've dropped the database and reinstalled a couple of times; the install goes fine without errors, but once it's complete, the server won't handle any more pages due to this error.

Any suggestions? Has anyone else installed from the current CVS and got it to work? TIA.

Hi Jeff! Thanks for your reply!

Here are the outputs from cvs status:

===================================================================
File: site-nodes-procs.tcl      Status: Up-to-date

   Working revision:    1.17
   Repository revision: 1.17    /cvsroot/openacs-4/packages/acs-tcl/tcl/site-nodes-procs.tcl,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: request-processor-procs.tcl       Status: Up-to-date

   Working revision:    1.21
   Repository revision: 1.21    /cvsroot/openacs-4/packages/acs-tcl/tcl/request-processor-procs.tcl,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: site-nodes-procs-oracle.xql       Status: Up-to-date

   Working revision:    1.11
   Repository revision: 1.11    /cvsroot/openacs-4/packages/acs-tcl/tcl/site-nodes-procs-oracle.xql,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: site-nodes-procs-postgresql.xql   Status: Up-to-date

   Working revision:    1.15
   Repository revision: 1.15    /cvsroot/openacs-4/packages/acs-tcl/tcl/site-nodes-procs-postgresql.xql,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

FWIW, I just installed the 4.5 tarball and it runs just fine (well it did once I'd psql'd ForceHostP to 0 as you directed above). So I'm confident the problem isn't with AOLServer or my nsd.tcl config file, or PG, or the install process itself. It could of course be some other stooooopid error I've made, but if so, I can't spot it.

Thanks!