Forum OpenACS Development: OpenACS 5.10.0 beta 1 available

Collapse
Posted by Gustaf Neumann on
Dear all,

on openacs.org is now a beta release of OpenACS 5.10.0 [1]. This new
release is one of the largest in OpenACS history and differs from
OpenACS 5.9.1 by the following statistics

3442 files changed, 120847 insertions(+), 92002 deletions(-)

The release contains several security improvements and new functions,
several new packages were added, and 370 bugs noted in the bug tracker
have been fixed.

For a partial summary of changes, please check the release notes [2],
for the more detailed list of changes since the release of OpenACS
5.9.1, see [3]. Many changes/enhancements of the application packages
are just contained in the detailed log.

These changes were contributed by 7 committers ...

- Antonio Pisano
- Gustaf Neumann
- Günter Ernst
- Hector Romojaro
- Michael Aram
- Stefan Sobernig
- Thomas Renner

... and additional 13 patch/bugfix providers

- Felix Mödritscher
- Florian Mosböck
- Frank Bergmann
- Franz Penz
- Hanifa Hasan
- Keith Paskett
- Markus Moser
- Maurizio Martignano
- Monika Andergassen
- Nathan Coulter
- Rainer Bachleitner
- Stephan Adelsberger
- Tony Kirkham

All packages of the release were tested with PostgreSQL 13.* and Tcl 8.6.*.

I would be happy if we could release the final OpenACS 5.10 release next week,
but I would like to get some feedback before this. In the future, we should
aim for shorter release intervals!

-gn

[1] https://openacs.org/projects/openacs/download/?&updated=1m
[2] https://openacs.org/doc/release-notes
[3] https://openacs.org/changelogs/ChangeLog-5.10.0

Collapse
Posted by Frank Bergmann on
Hi!

Congrats, this looks like a lot of work well done!

In order to test compatibility I have created a new instance based on a recent ]project-open[ V5.1 image (code + data, based on OpenACS 5.9.1, NSD 4.99.8 and PG 10.17) and made sure it worked. Then I have replaced all OpenACS packages with the ones from the OpenACS 5.10.0b1 tarball.

The first issue is an "invalid argument" error in 00-proc-procs.tcl. I assume that is due to the NaviServer version. So I'm trying to get the latest NaviServer now for CentOS 8.

Collapse
Posted by Frank Bergmann on
Hi!

To speedup things: Is there a binary NaviServer "distro" available for download somewhere that would work with CentOS 8 and Debian? Also, we would later need the same NaviServer version for Windows 10 and Windows Server 2016+.

Cheers
Frank

Collapse
Posted by Antonio Pisano on
Dear Frank,

the recommended way to install Naviserver on most Linux distributions is via the install-ns script, as explained here https://openacs.org/xowiki/naviserver-openacs.

For what concerns Windows, you should probably get in contact with Maurizio: https://openacs.org/xowiki/openacs-system-install-windows-server

All the best

Collapse
Posted by Frank Bergmann on
Hi Antonio,

Thanks, got NaviServer running on CentOS 8, and I've seen that Maurizio has the same version compiled for Windows, that's great.

So I'm one step further, I could see the login page, but I get an error after login from "security::validated_host_header". 192.168.0.176 is the IP of the DEV server running the instance, but I'm access it using http://localhost:8002. I don't see no bad...

I seem to remember this error, it is possible we disabled validated_host_header in OpenACS 5.9.1.

If you want to reproduce the bug: We've got the ]po[ V5.1 CentOS VM available for download (for VMware player or ESXi): https://sourceforge.net/projects/project-open/files/project-open/V5.1/ -> project-open-VMware-Community-5.1.0.0.0.zip

Cheers
Frank

Error: rp_handler no-script-abort: errorMsg Could not parse URL "http://192.168.0.176:/";: invalid authority while serving POST /register/ HTTP/1.1
: ad_url /register/ maps to file /web/openacs510/packages/acs-subsite/www/register/index.adp
: NONE
: Could not parse URL "http://192.168.0.176:/";: invalid authority
: while executing
: "ns_parseurl $location"
: (procedure "util::split_location" line 4)
: invoked from within
: "util::split_location [ad_url] .proto systemHost systemPort"
: (procedure "security::validated_host_header" line 85)
: invoked from within
: "security::validated_host_header"
: (procedure "util_current_location" line 74)
: invoked from within
: "util_current_location"

Collapse
Posted by Gustaf Neumann on
The URL "http://192.168.0.176:/"; is invalid according to the RFC.
The URL would be valid "http://192.168.0.176/";. This looks like sloppy URL generation to me.
Collapse
Posted by Frank Bergmann on
Interesting, somebody seems to have anticipated this in utilities-procs.tcl line #1983:

ns_log Error "util_current_location got invalid information from driver '[ns_conn location]'"

However, the split_location check breaks completely instead of just returning 0...

Cheers
Frank

Collapse
Posted by Frank Bergmann on
I've temporarily disabled the ns_parseurl call.

Now I get:

can't read "current_host": no such variable
    while executing "ad_get_node_id_from_host_node_map $current_host"
    (procedure "security::get_register_subsite" line 7)
    invoked from within "security::get_register_subsite"
    (procedure "::nsf::procs::ad_get_login_url" line 4)
    invoked from within "ad_get_login_url -return"
    (procedure "::nsf::procs::auth::require_login" line 17)
    invoked from within "auth::require_login"

Cheers
Frank

Collapse
Posted by Antonio Pisano on
The call cannot just be disabled, as it is expected to provide the values that you are finding to be missing shortly afterwards.

I think your best bet should be to try Gustaf's suggestion and fix the URL.

Collapse
Posted by Frank Bergmann on
Have a look, the URL is coming directly from [ns_conn location]! Try a regexp or whatever to fix/work around the situation, but please make it work. These are regression bugs from our perspective, because you have broken stuff that used to work.

Cheers
Frank

Collapse
Posted by Antonio Pisano on
ns_parseurl became stricter in recent Naviserver and won't parse URLs that do not comply with the RFC. However, I have never experienced the issue you report on a regular installation, so I suspect a problem with your configuration or some local modification.

We can try and help you troubleshoot the problem if you want. Can you please show an excerpt of your config.tcl file where you show the address and port you have defined for your server? Can you also try first on an installation consisting only of OpenACS 5.10 beta?

Collapse
Posted by Frank Bergmann on
Hi Antonio,

won't parse URLs that do not comply with the RFC

I understand.

suspect a problem with your configuration

I would reformulate and say that our configuration might be outside your usual test coverage 😊 However, it worked with OACS 5.9.1 or earlier, so you somehow broke compatibility.

I understand this is an instance of the "works on my system" problem. It's very, very common...

help troubleshoot

Here is the default config script:
http://po51demo.project-open.net/config.vanilla.txt

I guess there will be a total of ~20 issues in OACS 5.10, about 15 old ones (5.9.1 and earlier) and ~5 new ones (just guessing). I can provide you with a development system to allow you to quickly reproduce these issues.

Bests
Frank

Collapse
Posted by Antonio Pisano on
The default config script is not helpful, as it does not reproduce the situation that brings to the broken URL. My speculation is that this has something to do with the way host and port are configured on the instance that is "misbehaving". The URL ends up with an invalid ":" at the end, which is at the core of your problem, and you should try and find out why.

Concerning new and existing issues, please report them in the bug tracker, if you did not already and we will try to address them. If they are severe enough, they might be fixed before the 5.10 release.

Collapse
Posted by Frank Bergmann on
Hi Antonio,

I found this old posting from March 2021, the validated_host_header cause the same issue already in 5.9.1 (but not in the previous one):

https://openacs.org/forums/message-view?message_id=5513615

Cheers
Frank

Collapse
Posted by Malte Sussdorff on
I had this behavior when running OpenACS behind NGINX I think in SSL mode. So if your reverse proxy handles SSL and you „only“ run Naviserver in HTTP mode yet have https configured in the parameters of OpenACS this might be the reason for the problem. I‘d need to dig up the details if this is of interest, but maybe open a new topic?
Collapse
Posted by Raul Rodriguez on
How do we upgrade from 5.9.1 to 5.10.0?
Collapse
Posted by Gustaf Neumann on
Hi Raul,

How do we upgrade from 5.9.1 to 5.10.0?
The steps are essentially the same as upgrading from OpenACS 5.8 to 5.9. I have written down the steps on the following wiki page [1]. For testing these steps, i installed a fresh version of OpenACS 5.9.1 and performed the upgrade steps (in my case based on the version in CVS).

all the best
-gn

[1] https://openacs.org/xowiki/upgrade-oacs-5-10

Collapse
Posted by Malte Sussdorff on
Congratulations! Personally I guess I am most excited about the xooauth and dynamic blueprint part, though I did realize from reading the changes how much of what we do nowadays is just writing RESTful services and customer specific callbacks.
Collapse
Posted by Gustaf Neumann on
OpenACS.org runs now with OpenACS 5.10.0 beta 1
Collapse
Posted by Maurizio Martignano on
Dear Gustaf and all the others,
kudos for the release of OpenACS 5.10.0 (beta 1).

I'd just like to mention that this version of OpenACS is also available in my Windows port (https://spazioit.com/pages_en/sol_inf_en/windows-openacs_en/).

All the best and again kudos to everybody,
Maurizio

Collapse
Posted by Markus Moser on
I've updated the Arch Linux package in the Arch User Repository.
https://aur.archlinux.org/packages/openacs/

Enjoy!