Forum OpenACS Q&A: New OpenACS

1: New OpenACS

Posted by Joe Oldak on 09/12/22 03:16 PM

Hi all,

I currently maintain the Voice Online Communities system which is built on dotCommunity - a fork of OpenACS 5.2 - though since then it's undergone a lot of changes. And of course OpenACS has undergone even more changes. Certainly the code is sufficiently different that updating to 5.10 is probably impossible, no matter how much I might like to! 😊

The application is hosted using an old version of Linux (Ubuntu 10.04) and PostgreSQL (8.4), and uses AOLServer. It has a newer version of Linux as a front end server for https, and also has a Varnish cache in front of it.

I'm looking to overhaul the hosting environment to use up to date Linux and PostgreSQL, and maybe also NaviServer, depending on the amount of work required to upgrade the codebase. The key things I want to gain are: A fully supported platform with all the latest security patches, latest OpenSSH, latest packages such as ImageMagick and AWStats that dotCommunity makes use of, better performance, improved development environment, access to latest build tools, etc.

I thought I would start out with the newest Ubuntu LTS version (22.04) and get a stock version of OpenACS running on there using these instructions, then try moving our code onto it and seeing what breaks. That is, unless there's an obvious better route! Is there a currently accepted Best Practice for OpenACS installation and hosting?

So I'm on the lookout for any advice anyone has if they've tried doing similar. The things I'm most worried about are:

Switching from AOLServer to NaviServer and having everything completely break. Maybe I should stick with AOLServer??
Switching from PostgreSQL 8.4 to the latest version and having everything completely break. I certainly don't want to stick with this ancient PostgreSQL if I don't need to. At the very least I'd like to get some of the performance gains from the recursive permissions lookups etc. I realise there'll be a lot of SQL rewriting required, but using OpenACS 5.10 as a template I can hopefully update our code appropriately.

It might be that in order to work with new PostgreSQL and NaviServer I should take the core packages from OpenACS 5.10 and cherry pick the key changes in our dotCommunity codebase into that, rather than start with our code and pick the OpenACS changes into it. I think either way it's going to be a pretty big and messy job.

As an aside, if anyone is interested in what Voice Online Communities does, you're welcome to apply for a website on there and have a play!

Thanks

Joe

2: Re: New OpenACS (response to 1)

Posted by Jon Griffin on 09/12/22 03:33 PM

When I was still actively working for clients I had a similar situation. I don't remember exactly what versions of everything, but I do know that the hardest part, and reason I didn't do the upgrade, was postgres upgrades. There are many gotchas.

You are in for a painstaking task, unless someone else knows something I didn't.

3: Re: New OpenACS (response to 2)

Posted by Joe Oldak on 09/12/22 04:13 PM

That's interesting. I'll do some experimenting first but maybe an option would be to use a new Linux (so as to get all the latest packages/tools/security updates) but to build an old AOLServer/PostgreSQL from source, so as to benefit from the new platform without breaking too much of the application.

4: Re: New OpenACS (response to 1)

Posted by Jon Griffin on 09/12/22 04:16 PM

The problem is going to be in the changes to OACS and PG 9+, importing the old data will be the issue.

5: Re: New OpenACS (response to 1)

Posted by Dave Bauer on 09/12/22 05:04 PM

Joe,

I have updated a few older OpenACS systems over the years. What is easiest is to come up with a planned staged upgrade between the multiple compatible versions from where you are to where you want to go.

So, the first step is to upgrade PostgreSQL to the newest version compatible with whatever OpenACS you have. And then upgrade to the newest OpenACS that is compatible with that version of PostgreSQL. Repeat.

If you have made changes to the core openacs packages, this can be a little trickier. If you have isolated your changes into your own custom packages, a little easier. You might need to create an upgrade script if you used PostgreSQL features that have changed, I find that is typically rare for custom code, an of course, the OpenACS packages should have the appropriate upgrade scripts to help along the way.

As you said testing your custom code alongside the newest OpenACS/PostgreSQL combo would be a good test to determine if you need to upgrade your code.

I hope this is somewhat helpful and encouraging.

6: Re: New OpenACS (response to 1)

Posted by Brian Fenton on 09/13/22 03:28 PM

Hi Joe

Voice looks great, by the way! We moved from AOLserver to Naviserver about 5 years ago, and it really was a pretty smooth transition. I highly recommend doing it, as Naviserver has so many improvements. We were on Windows but it should be much easier on Linux.

Like you we were on an old OpenACS fork and in the end after much debate, we decided against upgrading OpenACS itself.

We use Oracle, so I can't really comment on the Postgres side of things.

Brian

7: Re: New OpenACS (response to 6)

Posted by Joe Oldak on 09/13/22 06:09 PM

Thanks for the helpful comments.

After spending a day experimenting, my current thinking is to use new Linux but keep PostgreSQL 8.4 (for now at least), and update only what is necessary in our code to work with NaviServer. Then look at incorporating more OpenACS updates and new db versions as a longer term project.

Looking at the documentation, I think the ns_cache_transaction features of NaviServer could be very useful - I've always found it annoying that when a transaction is aborted the cache is left in a potentially wrong state!

Cheers

Joe

8: Re: New OpenACS (response to 1)

Posted by Malte Sussdorff on 09/20/22 05:32 PM

What I can recommend is getting Naviserver in a docker container with the latest Operating System underneath it, get PostgreSQL 8.4 from the docker hub container and then run all of this in a new environment.

This will get around the issue / incompatibility of newest OS and PG 8.4 while keeping your environment secur(ish) as anything you expose to the outside runs on the latest Versions of the OS.

We did this with multiple old systems where we did not touch the Database or the OpenACS code.

You will run into more warnings in the Error.log due to AOLserver calls being deprecated in Naviserver, but these are few and you can easily use SED on your code to search and replace those instances (as you already mentioned your code is so heavily customized it does not make sense for you to Upgrade OpenACS, so this additional bit of code change wont make a difference I'd wager.