Forum OpenACS Q&A: Naviserver upgrade issue on RHEL 7.9

Hi Michael,

My first guess is that this comes from a binary mismatch (C based components compiled with a different Tcl version).

Compile with debug enabled in a fresh build dir, such as e.g. with the following command:

sudo with_debug_flags=1 build_dir=/usr/local/ns-src \
     bash install-ns.sh build

If you still see a crash, run nsd under gdb and show me the backtrace. If there is then still some problem, i will try to install somewhere a VM with RHEL 7.9.

all the best
-g

Glad that the clean install helped for the original problem!

Concerning the redirects: Maybe the following can shed light on this.

Add the following code to the end of packages/acs-tcl/tcl/utilities-procs.tcl, effectively redefining ad_returnredirect to be verbose.

d_proc -public ad_returnredirect {
    {-message {}}
    {-html:boolean}
    {-allow_complete_url:boolean}
    target_url
} {
    Write the HTTP response required to get the browser to redirect to
    a different page, to the current connection. This does not cause
    execution of the current page, including serving an ADP file, to
    stop. If you want to stop execution of the page, you should call
    ad_script_abort immediately following this call.

    <p>

    This proc is a replacement for ns_returnredirect, but improved in
    two important respects:
    <ul>
    <li>
    When the supplied target_url isn't complete, (e.g. /foo/bar.tcl or
    foo.tcl) the prepended location part is constructed by looking at
    the HTTP 1.1 Host header.
    </li>
    <li>
    If a URL relative to the current directory is supplied
    (e.g. foo.tcl) it prepends location and directory.
    </li>
    </ul>

    @param message A message to display to the user. See
                   util_user_message.

    @param html Set this flag if your message contains HTML. If
                specified, you're responsible for proper quoting of
                everything in your message. Otherwise, we quote it for
                you.

    @param allow_complete_url By default we disallow redirecting to
                              URLs outside the current host. This is
                              based on the currently set host header
                              or the hostname in the config file if
                              there is no host header. Set
                              allow_complete_url if you are
                              redirecting to a known safe external web
                              site. This prevents redirecting to a
                              site by URL query hacking.

    @see util_user_message
    @see ad_script_abort
} {
    ad_log warning "ad_returnredirect allow_complete_url $allow_complete_url target_url <$target_url>"
    if {$message ne ""} {
        #
        # Leave a hint, that we do not want to be consumed on the
        # current page.
        #
        set ::__skip_util_get_user_messages 1
        util_user_message -message $message -html=$html_p
    }

    if { [util_complete_url_p $target_url] } {
        ns_log notice "ad_returnredirect is complete <$target_url>"
        # http://myserver.com/foo/bar.tcl style - just pass to ns_returnredirect
        # check if the hostname matches the current host
        if {[util::external_url_p $target_url] && !$allow_complete_url_p} {
            error "Redirection to external hosts is not allowed."
        }
        set url $target_url
    } elseif { [util_absolute_path_p $target_url] } {
        #
        # The URL is an absolute path such as: /foo/bar.tcl
        #
        set url [expr {[::acs::icanuse "relative redirects"] ? "" : [util_current_location]}]
        append url $target_url
        ns_log notice "ad_returnredirect path is absolute, updated URL <$url>"
    } else {
        #
        # URL is relative to current directory.
        #
        set url [expr {[::acs::icanuse "relative redirects"] ? "" : [util_current_location]}]
        append url [ad_urlencode_folder_path [util_current_directory]]
        if {$target_url ne "."} {
            append url $target_url
        }
        ns_log notice "ad_returnredirect path is relative, updated URL <$url>"
    }

    # Sanitize URL to avoid potential injection attack
    regsub -all -- {[\r\n]} $url "" url

    ns_log notice "ad_returnredirect final redirect to <$url>"
    ns_returnredirect $url
}

I can't exclude that NaviServer 4.99.31 might contribute to the problem. To try with NaviServer 5, rebuild with

sudo with_debug_flags=1 version_ns=GIT build_dir=/usr/local/ns5-src \
     bash install-ns.sh build

all the best
-g

I was able to move past that issue with SSL. I installed the optional openssl11 packages then went in and modified src/naviserver/include/Makefile.global

and changed the following lines to reference the newer version.

OPENSSL_LIBS = -L/usr/lib64/openssl11 -lssl -lcrypto
CFLAGS += -I/usr/include/openssl11 -I/usr/include

I am in the process of trying to work through some Tcl errors but do not seem to be dealing with redirects under NS5 any more.

I will follow up with any other questions as I come across them. Thanks.

Making progress on our upgrade. One issue I wanted to run by you Gustaf relates to the upgrade logic for xowiki. We're at v0.89 from 5.8 days. Our xotcl core is at 0.126 and we're upgrading to Naviserver 5 with Nsf 2.4.

The Tcl upgrade logic has a lot of these types of upgrades:

::$package_id import-prototype-page "page-type"

Ours is failing at the first version upgrade that includes an invocation of this method - 0.96.

::11675808: unable to dispatch method 'import-prototype-page'
while executing
"error "[self]: unable to dispatch method '$m'""

Hoping you can point us in the right direction on this.

Thanks for the help, Gustaf!

We are running on top of a base of 5.8.0. If my memory is correct, we hit some issues bringing xowiki up to the version shipped with 5.8 and left it where it was as it was working.

So we aren't trying to make a massive leap from 5.4. We did make an attempt to move to 5.9.1 but ran into unrelated stack issues (which resulted in the creation of this thread) abandoned that in favor of jumping to 5.10. We have seen some inconsistencies across the upgrades even within versions. For example, 5.9 removes acs_object_context_index but we hit scripts in the 5.9 series that were still referencing it, sometimes indirectly. (If curious, I can share a diff...)

We eventually decided to try to move directly to 5.10 and that's where we are at the moment. Aside from the Xowiki issues and an adjustments to DML to account for the acs_object_context_index issues mentioned, we're very close.

Is there anything else we'd need for those deprecated aliases to work? We hit a new error when upgrading Xowiki with the deprecated procs in place:

invalid non-positional argument '-with_child_rels', valid are: -dbn, -name, -parent_id, -item_id, -locale, -creation_date, -creation_user, -context_id, -creation_ip, -item_subtype, -content_type, -title, -description, -mime_type, -nls_language, -text, -data, -relation_tag, -is_live, -storage_type, -package_id;
should be "::acs::dc call content_item new ?-dbn /value/? -name /value/ ?-parent_id /int32/? ?-item_id /int32/? ?-locale /value/? ?-creation_date /value/? ?-creation_user /int32/? ?-context_id /int32/? ?-creation_ip /value/? ?-item_subtype /value/? ?-content_type /value/? ?-title /value/? ?-description /value/? ?-mime_type /value/? ?-nls_language /value/? ?-text /value/? ?-data /value/? ?-relation_tag /value/? ?-is_live /value/? ?-storage_type /value/? ?-package_id /int32/?"
::acs::dc ::acs::db::nsdb-postgresql->call
invoked from within
"::acs::dc call content_item new -name ${:name} -parent_id ${:parent_id} -creation_user $creation_user -creation_ip $creatio..."
("uplevel" body line 25)

We also got the following error several times, when packages invoked a Tcl callback (I believe):

invalid command name "::xowiki::Package"
while executing
"::xowiki::Package is_xowiki_p $package_id"
(procedure "::callback::subsite::parameter_changed::impl::xowiki" line 3)

Thanks for all of your help!