Forum OpenACS Q&A: Multiple Instances using rpm installation

Hello Folks!

I am trying to install additional OpenACS instances on my (1Ghz, 384 MB) development box, which has one running. I used Jonathan's rpms (thanks!) on RH 7.1. Is this possible?

Unfortunately, the  HOWTO-Multiple- ACS-Installations-with-one-static-IP.html - link by Jerry Holly is broken.

My first, naive, plan was to copy the .../defaultacs directory to .../acs1, create a second database, and load a seperate instance of aolserver using a different port, e.g. 8080, with a seperate nsd.tcl file. Starting it would sound something like .../nsd -kt nsd1.tcl. Later on, I would experiment with nsvhr, nssock and nsunix.

I tried to create a second database (acs1) and simply copied /var/lib/aolserver/servers/defaultacs to ../acs2, but (of course?) this did not work. Loading the geo-tables and the data model into the second database was unsuccesful for some reason. (Of course, in a week or so I will say this all was a very stupid thing to do...)

After this, I tried to install AOLServer (3.4, because it should fix an issue with un-english characters) from the tarball - it was easy to get this one running on itself on port 8080. But... getting it to run with OpenACS (I installed a second instance in /web) was unsuccesful, e.g. because all kinds of files are in a different place in the rpm-installation.

Now, I am confused about what to do next... (Well, taking a long vacation seems a pretty good option...)

Thanks for any suggestions!

Well, after all my first plan wasn't as stupid as I thought 😉) I now know why the data-model would not load: I uncommented the wrong lines regarding rpm or other in 'postgres.sql' before running load-data-model. (Well, it was late...)
So now it works. But... there are still two issues:

1. The rpm installation makes it possible to automatically load postgresql and aolserver at startup easily (chkconfig aolserver on, chkconfig postgresql on). How can I do the same for my second instance? Should I follow the same strategy as is recorded in the docs for the 'normal' installation (something like as:1234 respawn etc.)or does the 'chkconfig' command provide another possibility?

Simply doing

# chkconfig add nsd -t /etc/aolserver/acs1.tcl -u nsadmin -g nsadmin

gives this result:
-t: unknown option

2. I have only one IP for this machine, so I should be using 'nssock' or 'nsunix' if I don't want to have urls with port numbers, which, reportedly, are features of Aolserver for port-redirection (I have not found a howto so far, or even a download).

For expample, a box which has two domains, www.foobar.com and acs1.foobar.com. The first instance runs at www.foobar.com:80, the second at acs1.foobar.com:8000. Someone types acs1.foobar.com in his browser, and the request for acs1.foobar.com:8000 could actually come in at port 80 of but will be forwarded (by a third instance of AOLServer)to port 8000. Has anyone experience with this?

Thank you Jonathan, it works..! And it sounds logical too...Well, I guess this could raise a whole new question 'should newbies be allowed to run OpenACS?' - well, I am trying to, and learning every day 😉

Well, as far as I am concerned, this method is simple enough.

I read somewhere that the problem with European characters (what a character é!) had to do with nsd8x, and that it wasn't there in nsd76. Strange how many workarounds are being offered, a bit confusing e.g. is it a Postgres problem, or AOLServer problem, or a combined problem, or no problem at all? Compiling PostgreSQL with options like

--enable-locale --enable-multibyte=UNICODE --enable-unicode-conversion

is no option for the rpm install so... I read your remark in this thread about characters etc. and will try it. Thanks!

I played some more with this...

Using PG carefully initdb'ed and run with LANG=C, and with AOLserver 3.2+ad12 or 3.3+ad13 I can *still* get incorrect display of ISO 8859-1 (Latin 1) characters from OpenACS.

However, when I get rid of OpenACS and just run the exact same copy of AOLserver... the problem disappears!

Here is what I did:

#!/bin/bash
#
# iso8859test - sets up ISO 8859-1 test pages for AOLserver and OpenACS
#

# Generate ISO 8859-1 charset table from man page
man iso_8859_1 |col -b |egrep "^ *[0-9]" >iso_8859_1.txt

# Generate head and tail for HTML test pages
cat >iso_8859_1.html.head <<EOF
<HTML>
<HEAD>
<TITLE>ISO 8859-1 Test Page</TITLE>
</HEAD>
<BODY>
<PRE>
EOF

cat >iso_8859_1.html.tail <<EOF
</PRE>
</BODY>
</HTML>
EOF

# Create ISO 8859-1 test page
cat iso_8859_1.html.head iso_8859_1.txt iso_8859_1.html.tail >iso_8859_1.html

This generates a nice HTML page containing all the non-USASCII printable characters in ISO 8859-1. Then I checked I could view this file OK in my browsers. Next I copied it to /var/www/html/ (where Apache can serve it) and to /var/lib/aolserver/servers/default/pages/ (where AOLserver can serve it) and to /var/lib/aolserver/servers/defaultacs/www/ (where OpenACS can serve it).

Apache serves it fine. OpenACS serves it with extra "A-with-circumflex" characters. But, if I do

  cd /var/lib/aolserver/servers
  mv defaultacs defaultacs.old

And then do /sbin/service aolserver restart, AOLserver can then serve it just fine.

I repeated the test using AOLserver 3.2+ad12 and 3.3+ad13, no difference was noticed.

Conclusion: Something about the way OpenACS serves plain .html files breaks ISO-8859-1 output under OpenACS 3.2.5. It looks to me as though the primary bug here is in OpenACS 3.2.5 itself, not in PG or AOLserver.

Well thank you for this exhausting coverage of the subject... I will try the suggested approach...

One of the strange things I encountered was that on a certain occasion certain characters showed up just right, and a few days later the é 's and â 's came again. Anyway, it should be possible to find a solution.

I'm spending too much time on this 😊

I just uploaded a cleaned up version of Henry Minsky's openacs-japanese-325-patches file to the SDM. It only does internationalization changes (unlike Henry's version!), and it does not have shift-jis hardwired into it anywhere.

It has not had much testing at all yet, but it would be great to see how well it works for others as well as for me. The patch is patch #44.

Claudio,

I suggest that you back out patch #43, and then apply patch #44 instead.  It is a cleaned up version of Henry's set of internationalization changes which does what my patch #43 did and a lot more.