Forum OpenACS Development: error on browsing to / on new oacs-5.8, pg-9.1, naviserv-4.9.9

Request notifications

I looked at "Main Site" subsite params, they look good... is this what's suppoed to happen? And therefore to get a working /, we have to do something?

here's text or err msg:

no active adp
    while executing
"ns_adp_puts {<li>The Naviserver <a href="nsstats.tcl">Statistics page</a> can be
                    useful in resolving performance issues.}"
    ("uplevel" body line 53)
    invoked from within
"uplevel {
set __adp_output {}; set __ad_conn_locale [ad_conn locale]
append __adp_output "<html>
<head>
  <title>Default Page for Naviserver Installa..."
    (procedure "template::code::adp::/home/mu-new/inst/pages/index" line 2)
    invoked from within
"template::code::${template_extension}::$__adp_stub"
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 6)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$extra_url""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
            rp_serve_abstract_file "$root/$extra_url"
            set tcl_url2file([ad_conn url]) [ad_conn file]
            set tcl_url2path..."

Hi Jim,

Can you tell us in some more detail, what your setup is? There is no naviserv-4.9.9, what are you actually using?

My first guess is that the startup file you are using is msiconfigured. NaviServer is shipped with a preconfigured startup file for OpenACS. You can save yourself headache, if you use this as a basis for your setup. In the startup script, point "serverroot" to the openacs installation (same as sample aolserver default config file). From the errors above it looks to me, as if you are pointing it to the default page dir of plain naviserver (without OpenACS).

You might consider to use the automated installation scripts [2] to get a fully preconfigured setup for several operating systems. The scripts installs by default the head version; replace "oacs_core_version=HEAD" in install-oacs.sh by "oacs_core_version=oacs-5-8" to get acs-core from the oacs-5-8 branch.

Hope this help
-gn

[1] https://bitbucket.org/naviserver/naviserver/src/89c38a7a5436b9d962fd1ee97afc44a44e34cfec/openacs-config.tcl
[2] http://openacs.org/xowiki/naviserver-openacs

"hope this help" it probably will as always...

you're right, not naviserv-4.9.9, but: naviserver-4.99.5.tar.gz.

Also I used the config file from (my server root)/etc/config.tcl, and had to adjust it several times so far...

-Jim, who is checking all of this out. Any other info you would like?

Thanks Gustaf,

I edited the config file from the naviserver source dir and everything's fine now, browsing / gives me the "main site" subsite index.

-Jim

Glad this worked. Maybe, we should
- add a sanity check in the config file in CVS, that complains if it is tried under Naviserver (this would avoid complex error messages as above), and
- add as well a sample config-file for NaviServer to CVS...
another thing that could be done is factor the piece of the config file where the openacs installer puts the settings, and have the remainder -- which would have content specific to either naviserv or aolserver -- would call the factored piece, which would work with either.

what do you think?

The Tcl variables at the start of the config files are the common part which is typically needed for the configuration. The remainder of the config file is there as a documentation, what a user could change, what features are available and could be activated. In my opinion the best we can do is use the same set of Tcl and let people to copy this section if they want to move around between the servers. The documentational character is important: Look for example at the minimal config file of NaviServer [1], which is sufficient for non-db setups for NaviServer. On one hand it is nice, on the other hand, many people are lost when they want to modify the setup of the server.

If there would be a big outer "if" around one section for AOLServer and NaviServer, the documentational aspects suffer; people might be confused and change variable in the wrong part, miss dependencies between parts etc. If there are many ifs around the pieces which are different for the servers, this is also more work to maintain this large config file; having ifs around optional and commented out sections (e.g. for spooler threads) is strange; describing e.g. alternate ways to configure a server (e.g. per-server or global drivers in NaviServer, multiple servers or virtual servers in NaviServer, the configuration for various SSL drivers, etc.) is hard.

I've spent quite some time in the past to figure out why a certain change in a config file does not work as i would expect, finding often, that the parameter in question is not used at all by the server; Often it is not clear, what the defaults of some parameters are, especially when they change between versions of the server. That lead to the development of /admin/nsstats?@page=configparams (nsstats [2] is installed by the the installer in [3]) and the changes in NaviServer to track default values in the config database. A common burden is the legacy cruft and the legends documented in config files about necessary setups, which might have been important in ancient versions of the servers but lost its importance over the years, or which might be still useful for some old versions of drivers, modules etc.

Therefore i think, having a "nice", lean, cleaned-up config file is better than a single large one that tries to fit all purposes and legends.

Actually, i think the main problem is that many people "love" their old config files and do not dare to change anything, because they think that every change might endanger the stability of the system. In my experience this is rather an alarm signal. When people are not daring the touch anything in a code it is a good indicator that this piece of code is overly complicated and should be overworked.

-gustaf

[1] https://bitbucket.org/naviserver/naviserver/src/22487f6dbb7d7454c74244a57ab92256b0c3af64/simple-config.tcl
[2] https://bitbucket.org/naviserver/nsstats
[3] http://openacs.org/xowiki/naviserver-openacs

I miscommunicated the shape of what I was thinking... yeah, the ifs would be very confusing.

Let me try to describe the idea more clearly:

right now, we have the openacs config file in $server/etc/config.tcl, and the openacs config in the naviserv source.

Each has a section of the variables the end user would change to get a basic set up, and these are at the top of each file.

Then, each file continues to their end with sections that are either preconfigured or commented out (like the ssls).

What I'm proposing is to simply split the etc/config.tcl at the point where the top parameters are, and then you have a file with only the commonly altered parameters, and another, with the rest. At the top of this file (non-common params) would additionally have a statement including the file with the common parameters.

The naviserv file would have this same include statement, replacing the common parameters.

Is that more clear? and if so, what do you think?

-Jim

In regards to your summary paragraphs,

Therefore i think, having a "nice", lean, cleaned-up config file is better than a single large one that tries to fit all purposes and legends.

Absolutely. In that way, configuration stays accessable.

Actually, i think the main problem is that many people "love" their old config files and do not dare to change anything, because they think that every change might endanger the stability of the system. In my experience this is rather an alarm signal. When people are not daring the touch anything in a code it is a good indicator that this piece of code is overly complicated and should be overworked.

Yes. In my own case, I would always use the most current, not daring to try my old config on the new server version. Your indication is still the same.

Perhaps people would be less nervous if they saw that while aolserver/naviserv has its own config params, and that it is the loading of most (?) modules that adds additional params which would then be recognized in the config file, if they could see it's not just a monolithic, incomprehensible and uncontrollable mess (the perception of which we inherit from arsDigita days), but a fairly logical structure, they might be less nervous and more bold and confidently able to know and set their own params.

One can certainly move towards a openacs configuration file based on tcl-vars only, that calls at the end the config scripts for the appropriate server. Sounds at first sight like a good idea.

However, this common part can address just the intersection of the functionality of the servers, and not the more advanced parts (e.g. spooler threads, writer threads, static gzip delivery, etc.). The server capabilities change as well the the setting of common parameters (we tend to use now more connection threads with naviserver, but wee still need rather less memory). If a user has to look into two different files, and a maintainer has to maintain extra files, some advantages fades probably. I am not sure, how much further development will happen with aolserver (which is a fine product, which serves with its frozenness perfectly the expectations of some sites).

I will personally not put effort this way (there are so many other things to do), but certainly everyone else can...

all the best
-gustaf neumann

I just stumbled upon the same error using an old aolserver config file with NaviServer. Although it generally seems to be the right thing to start with the openacs-config.tcl from the NaviServer repository (as Gustaf suggests) and tweak it afterwards, I wanted I note that the missing piece – in my case – was this snippet:
ns_section "ns/server/${server}/fastpath"
	ns_param	  serverdir  ${homedir}
	ns_param  pagedir    ${pageroot}
Michael, thank you, I also got that same cryptic "no active adp" error, and the fix was indeed adding that fastpath ns_section.  AOLserver apparently does not need it but NaviServer definitely does.