Forum OpenACS Q&A: Multiple Instances using rpm installation
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!
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).
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?
# 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?
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 onwould (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?
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!
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...
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.
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!
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.
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 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.
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.
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.