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!

Collapse
Posted by Don Baccus on
Running two or more ACS instances on a site is very easy.  Your last set of problems seem to be due to files going in different places due to mixing the RPM install with tarballs, as you point out.

You just need to remember to:

1. have the two instances listen on different IPs or different ports on the same IP (if you get tired of typing "8000" or whatever at your browser remember that it is very easy to multihost local IPs on a single NIC in Unixland).

2. two different pageroots

3. two different PG databases

4. remember that the database pools in your .tcl init file has to point to the right database for each instance

that's really just about all there is to it.  Lately I've been routinely running an Oracle and PG instance of OpenACS 4, so I can check on stuff back-and-forth between the two (takes lots of memory to run Oracle and PG together in an efficient way, other than that it's no big deal).

Collapse
3: It works, but... (response to 1)
Posted by Hans Gaasenbeek on
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?

Collapse
Posted by Jonathan Marsden on
Hans, I've not tried to do this from the RPMs "for real", but it should be perfectly possible.

The way to do the init stuff with chkconfig would be to copy /etc/rc.d/init.d/aolserver to /etc/rc.d/init.d/aolserver2 and then edit it to use the copied and edited /etc/aolserver/nsd.tcl, perhaps /etc/aolserver/nsd2.tcl or whatever you prefer. Then

  /sbin/chkconfig aolserver2 on
would (as far as I know) work fine.

In fact, it might be quite practical to create a script that sets this up, copying and editing as needed, for aolserver2 to aolserver999 or whatever, and include it in the next version of my RPMs.

Would it be useful to the community for me to create such a script?

BTW, is the "issue with non-English characters" a problem in AOLserver3.3+ad13? If it is, could you explain it further please?

Collapse
5: (response to 1)
Posted by Hans Gaasenbeek on

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!

Collapse
6: Non-English characters (response to 1)
Posted by Jonathan Marsden on
Glad it worked!

There are (I believe) multiple issues with non-USASCII characters that are tripping people up at the moment, hence the confusion.

Both PG and AOLserver have made changes in their locale/charset handling recently. BTW, the PG 7.1.2 RPMs are compiled with --enable-multibyte and --enable-locale, but not (as far as I can see) --enable-unicode-conversion. You can look at the .spec file from the postgresql SRPM to see exactly how the PG RPMs are configured and compiled.

One way to check how your PG installation is set regarding locale is to install the postgresql-contrib RPM, and then run

  su - postgres
  /usr/lib/pgsql/contrib/pg_controldata/pg_controldata

What you want is to see that the LC_COLLATE: and LC_CTYPE: values shown are both C. If they are, then, at least for single-byte charsets such as 8859-1, PG is fine and you can look at AOLserver if you are seeing 'foreign' chars incorrectly displayed.

Oh, and it looks like PG 7.1.3 was released a few days ago... now I need to check *that* out...

Collapse
Posted by Jonathan Marsden on
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.

A little more playing shows that this (incorrect display of Latin1 characters in .html files) is caused by OpenACS reading the contents of such files into a TCL string and then outputting it.  TCL 8.x uses Unicode for strings, and this is where the fun starts.

Henry Minsky's AOLserver patches that explicitly set the OutputEncoding and so forth should solve this, at least for sites needing only a single character encoding (eg. Latin1) for the entire site.
I'll try to get an AOLserver 3.3+ad13 RPMset built that includes Henry's patches, and an nsd.tcl that uses the new parameters they provide.

BTW, it seems that this whole thing has been discussed before (ie. I am going over old ground here...!) -- I'd just not realized that the difference in handling .html files was directly related to the TCL 8.x stuff, until I actually read the code where OpenACS deals with serving .html files!

Collapse
9: rpms, charactersets (response to 1)
Posted by Hans Gaasenbeek on
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.

Collapse
10: Still more on charsets (response to 1)
Posted by Jonathan Marsden on
OK... more details on why .html files containing Latin-1 characters are served fine by AOLserver alone, but not by OpenACS 3.2.5. And a patch!

All the AOLserver internationalization features work, as long as content is sent to the client using ns_return and friends. Which it usually is.

However, when outputting .html files, OpenACS tries to 'optimize' things, and doesn't use ns_return at all. As a result, the internationalization features never kick in, and the Unicode TCL string containing the body of the .html file is not converted back to a more common charset at all.

Comments in the OpenACS TCL code (in ad-html.tcl and ad-utilities.tcl.preload) say this "saves a packet". Which it would... but apparently this is at the expense of messing up internationalization.

I have a small patch that seems to work (ie. after applying it, .html files containing Latin-1 chars are served so that the browser displays them correctly).

Downside: It sends the entire page at once, including any associated comments and links. This could mean a perceived delay for the end user, compared to the old way in which the body of the page was output before the comments and links were.

Overall, I prefer correctness to speed... but if someone else could look this over and show me the "better way" to get both the split display and the correct charset in the output, that would be great! My patch is now available as https://openacs.org/sdm/one-patch.tcl?patch_id=43 in the SDM.

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.

Collapse
12: Still more on charsets (response to 1)
Posted by Claudio Pasolini on
Jonathan,
I applied your patch #43 but it resolves only one half of the problem. Special non US characters now are output correctly, but if I enter them in a form's input field they become corrupted after receiving them in a TCL script.

Claudio Pasolini

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.