Filtered by date 2008-02-17, 61 - 70 of 111 Postings (
all,
summary)
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
Starting with Version 4.5, all OpenACS core packages support automatic upgrade. That means that, if you have OpenACS 4.5 or better, you should always be able to upgrade all of your core packages automatically. If you haven't changed anything, no manual intervention should be required. If you are running OpenACS prior to 4.5, upgrading will require manual effort.
If all of these conditions are true:
-
Your OpenACS Core is 5.0.0 or later
-
You do not keep your OpenACS site in a local CVS repository
-
You do not have any custom code
then you can upgrade automatically using the automated installer in the OpenACS Package Manager (APM), and you can probably skip the rest of this chapter. To upgrade directly from the OpenACS repository using the APM:
-
Browse to the Installer.
-
Click install or upgrade under "Install from OpenACS Repository" and select the packages to install or upgrade.
-
The APM will download the requested packages from OpenACS.org, install the files on your hard drive, run any appropriate database upgrade scripts, and prompt you to restart the server. After restarting the server again, the upgrade is complete.
It's always a good idea to precede an upgrade attempt with a snapshot backup.
Table5.1.Assumptions in this section
| name of OpenACS user |
$OPENACS_SERVICE_NAME |
| OpenACS server name |
$OPENACS_SERVICE_NAME |
| Root of OpenACS file tree |
/var/lib/aolserver/$OPENACS_SERVICE_NAME |
| Database backup directory |
/var/lib/aolserver/$OPENACS_SERVICE_NAME/database-backup |
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
The simplest way to start and stop and OpenACS site is to run the startup shell script provided, /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/daemontools/run. This runs as a regular task, and logs to the logfile. To stop the site, kill the script.
A more stable way to run OpenACS is with a "keepalive" mechanism of some sort, so that whenever the server halts or is stopped for a reset, it restarts automatically. This is recommended for development and production servers.
The Reference Platform uses Daemontools to control AOLserver. A simpler method, using init, is here.
-
Daemontools must already be installed. If not, install it.
-
Each service controlled by daemontools must have a directory in /service. That directory must have a file called run. It works like this:
-
The init program starts every time the computer is booted.
-
A line in init's configuration file, /etc/inittab, tells init to run, and to restart if necessary, svscanboot.
-
svscanboot checks the directory /service every few seconds.
-
If it sees a subdirectory there, it looks for a file in the subdirectory called run. If it finds a run file, it creates a supervise process
-
supervise executes the run script. Whenever the run script stops, supervise executes it again. It also creates additional control files in the same directory.
Hence, the AOLserver instance for your development server is started by the file /service/$OPENACS_SERVICE_NAME/run. But we use a symlink to make it easier to add and remove stuff from the /service, so the actual location is /var/lib/aolserver/$OPENACS_SERVICE_NAMEetc/daemontools/run.
Daemontools creates additional files and directories to track status and log. A daemontools directory is included in the OpenACS tarball at /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/daemontools. To use it, first ill any existing AOLserver instances. As root, link the daemontools directory into the /service directory. Daemontools' svscan process checks this directory every five seconds, and will quickly execute run.
[$OPENACS_SERVICE_NAME etc]$ killall nsd
nsd: no process killed
[$OPENACS_SERVICE_NAME etc]$ emacs /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/daemontools/run
[$OPENACS_SERVICE_NAME etc]$ exit
[root root]# ln -s /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/daemontools/ /service/$OPENACS_SERVICE_NAME
Verify that AOLserver is running.
[root root]# ps -auxw | grep nsd$OPENACS_SERVICE_NAME 5562 14.4 6.2 22436 15952 ? S 11:55 0:04 /usr/local/aolserver/bin/nsd -it /var/lib/aolserver/$OPENACS_SERVICE_NAME/etc/config.tcl -u serve
root 5582 0.0 0.2 3276 628 pts/0 S 11:55 0:00 grep nsd
[root root]#
-
The user $OPENACS_SERVICE_NAME can now control the service $OPENACS_SERVICE_NAME with these commands:
-
svc -d /service/$OPENACS_SERVICE_NAME - Bring the server down
-
svc -u /service/$OPENACS_SERVICE_NAME - Start the server up and leave it in keepalive mode.
-
svc -o /service/$OPENACS_SERVICE_NAME - Start the server up once. Do not restart it if it stops.
-
svc -t /service/$OPENACS_SERVICE_NAME - Stop and immediately restart the server.
-
svc -k /service/$OPENACS_SERVICE_NAME - Sends the server a KILL signal. This is like KILL -9. AOLserver exits immediately. If svc -t fails to fully kill AOLserver, use this option. This does not take the server out of keepalive mode, so it should still bounce back up immediately.
-
Install a script to automate the stopping and starting of AOLserver services via daemontools. You can then restart a service via restart-aolserver $OPENACS_SERVICE_NAME
[root root]# cp /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/files/restart-aolserver-daemontools.txt /usr/local/bin/restart-aolserver
[root root]# chmod 755 /usr/local/bin/restart-aolserver
[root root]#
-
At this point, these commands will work only for the root user. Grant permission for the web group to use svc commands on the $OPENACS_SERVICE_NAME server.
[root root]# /usr/local/bin/svgroup web /service/$OPENACS_SERVICE_NAME
[root root]#
-
Verify that the controls work. You may want to tail -f /var/lib/aolserver/$OPENACS_SERVICE_NAME/log/$OPENACS_SERVICE_NAME-error.log in another window, so you can see what happens when you type these commands.
Most of this information comes from Tom Jackson's AOLserver+Daemontools Mini-HOWTO.
Table6.1.How it Works
| Program |
Invoked by this program ... |
... using this file |
Where to find errors |
Log goes to |
Use these commands to control it |
| svscanboot |
init |
/etc/inittab |
ps -auxw | grep readproctitle |
n/a |
|
| aolserver |
|
/service/$OPENACS_SERVICE_NAME/run |
/var/lib/aolserver/$OPENACS_SERVICE_NAME/log/error.log |
/var/lib/aolserver/$OPENACS_SERVICE_NAME/log/$OPENACS_SERVICE_NAME.log |
svc -k /service/$OPENACS_SERVICE_NAME |
| postgresql |
Redhat init scripts during boot |
/etc/init.d/postgresql |
/usr/local/pgsql/data/server.log |
|
service postgresql start (Red Hat), /etc/init.d/postgresql start (Debian) |
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
Once you get your OS installed, it's imperative that you secure your installation. As Jon Griffin repeatedly warns us, "No distribution is secure out of the box." The Reference Platform implements some basic precautions, but security is a process, not a condition. If you are responsible for a computer hooked to the internet, you are responsible for learning some rudiments of security, such as monitoring the state of a computer, maintaining patch levels, and keeping backups. We recommend these resources:
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
User locale is a property of ad_conn, ad_conn locale. The request processor sets this by calling lang::conn::locale, which looks for the following in order of precedence:
-
Use user preference for this package (stored in ad_locale_user_prefs)
-
Use system preference for the package (stored in apm_packages)
-
Use user's general preference (stored in user_preferences)
-
Use Browser header (Accept-Language HTTP header)
-
Use system locale (an APM parameter for acs_lang)
-
default to en_US
For ADP pages, message key lookup occurs in the templating engine. For TCL pages, message key lookup happens with the _ function. In both cases, if the requested locale is not found but a locale which is the default for the language which matches your locale's language is found, then that locale is offered instead.
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
-
The OpenACS Kernel, which handles system-wide necessities such as metadata, security, users and groups, subsites, and package management and deployment.
-
The OpenACS Core, which comprises all the other packages that ship with the kernel and are most frequently needed by users, such as templating, forums, and user registration/management. The packages tend to be developed and distributed with the kernel.
-
OpenACS Application packages, which typically provide user-level web services built on top of the Kernel and Core. Application packages are developed separately from the Kernel, and are typically released independently of it.
This document provides a high level overview of the kernel package. Documentation for other packages on this server
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
Skip down for instructions on Deleting a PostgreSQL tablespace.
Should it become necessary to rebuild a tablespace from scratch, you can use the drop user command in SVRMGRL with the cascade option. This command will drop the user and every database object the user owns.
SVRMGR> drop user $OPENACS_SERVICE_NAME cascade;
If this does not work because svrmgrl "cannot drop a user that is currently connected", make sure to kill the AOLserver using this user. If it still does not work, do:
SVRMGR> select username, sid, serial# from v$session where lower(username)='$OPENACS_SERVICE_NAME';
and then
SVRMGR> alter system kill session 'sid, serial#';
where sid and serial# are replaced with the corresponding values for the open session.
Use with caution!
If you feel the need to delete everything related to the service, you can also issue the following:
SVRMGR> drop tablespace $OPENACS_SERVICE_NAME including contents cascade constraints;
Dropping a PostgreSQL tablespace is easy. You have to stop any AOLserver instances that are using the database that you wish to drop. If you're using daemontools, this is simple, just use the 'down' flag (-d). If you're using inittab, you have to comment out your server in /etc/inittab, reread the inittab with /sbin/init q, and then restart-aolserver $OPENACS_SERVICE_NAME .
Then, to drop the db, just do:
[$OPENACS_SERVICE_NAME ~]$ dropdb $OPENACS_SERVICE_NAME
DROP DATABASE
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
-
Update Translations.the section called âHow to Update the translationsâ
-
Rebuild the Changelog.Rebuild the Changelog. I use a tool called cvs2cl. Run this command from the package root to automatically generate a Changelog file in the same dir. We generate two changelogs, one for the minor branch and one for the most recent release. The example below is for OpenACS 5.0.2:
cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
cvs2cl -F oacs-5-0 --delta openacs-5-0-0-final:oacs-5-0 -f ChangeLog
cvs2cl -F oacs-5-0 --delta openacs-5-0-1-final:oacs-5-0 -f ChangeLog-recent
-
Update Version Numbers.The version numbers in the documentation and in the packages must be updated. This should only happen after a release candidate is approved.
-
Update /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/xml/variables.ent with the new version number.
-
Add new section in /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/xml/for-everyone/release-notes.xml
-
Regenerate all HTML docs
cd /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/xml
make
-
Update /var/lib/aolserver/$OPENACS_SERVICE_NAME/readme.txt with the new version number
-
Update version number and release date in all of the core packages. Use /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/files/update-info.sh with the new version number and the release date as arguments. Run it from /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages:
cd /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages
./acs-core-docs/www/files/update-info 5.2.12006-01-16
-
Install a new site using the modified code and verify that the automated tests pass.
-
Commit changes to CVS
-
Tag the files in CVS.The steps to this point should have ensured that the head of the current branch contains the full set of code to release. Now we need to tag it as the code to be released.
-
Check out OpenACS Core. The files must be checked out through a cvs account with write access and should be a checkout from the release branch. In this example, we are assuming this is being done as a local user on openacs.org (which make the checkout and tagging operations much faster).
cd /var/tmp
cvs -d /cvsroot checkout -r oacs-5-0 acs-core
If doing .LRN, repeat with the dotlrn cvs tree.
cd /var/tmp
mkdir dotlrn-packages
cd dotlrn-packages
cvs -d /dotlrn-cvsroot checkout -r dotlrn-2-0 dotlrn-all
-
Tag the tree. If it's a final release of core, move or create the appropriate openacs-major-minor-compat tag. (Ie, if releasing 5.0.3 final, move the openacs-5-0-compat flag.)
cd /var/tmp/openacs-4
cvs tag -F openacs-5-0-0a1
cvs tag -F openacs-5-0-compat
Branching
When we feature-freeze on HEAD as part of the release process, we are blocking new development. To avoid this, we branch the code at this point, so that new work can continue on HEAD while the branch is stabilized for release. However, branching means that bug fixes have to be synchronized between HEAD and the branch, and bug fixes tend to be more frequent right at this time. Therefore, our actual branch point is as late as possible - essentially, we do not branch until and unless new feature work is actively blocked by the feature freeze. Branching is almost the same as tagging, except for the flag and slightly different tag nomenclature. To see the list of old branches, cvs status -v somefile.
cvs tag -b oacs-5-0
If doing .LRN: Since the .LRN packages aren't all in one module, we iterate through all of the modules. Log in first (cvs login) so that you don't have to log in for each module.
cd /var/tmp/dotlrn-packages
for dir in *; do ( cd $dir && cvs tag dotlrn-2-0-2-final ); done
for dir in *; do ( cd $dir && cvs tag -F openacs-5-0-compat ); done
Note that for the compat tag we use the -F flag which will force the tag to the new version (just in case someone has created the tag already on another version). Excercise care when doing this since you don't want to inadvertently move a prior release tag. Also if the tagging goes horribly wrong for some reason you can delete the tag via "cvs tag -d <symbolic_tag>".
-
Apply the final tag across the tree. First, check out the entire OpenACS tree, getting the most recent stable version of each package. This is most simply done on openacs.org:
cd /var/tmp
cvs -d /cvsroot checkout -r openacs-5-1-compat openacs-4
cd openacs-4
cvs tag openacs-5-1-2-final
-
Make the tarball(s).
-
openacs-core.
-
Go to a new working space and export the tagged files.
mkdir /var/tmp/tarball
cd /var/tmp/tarball
cvs -d /cvsroot export -r openacs-5-0-0a1 acs-core
-
Generate the tarball.
cd /var/tmp/tarball
mv openacs-4 openacs-5.0.0a1
tar cz -f openacs-5.0.0a1.tar.gz openacs-5.0.0a1
-
dotlrn.
-
Go to a new working space and export the tagged files. (was getting errors here trying to use -d, so gave up and just moved things from openacs-4 to openacs at the end)
mkdir /var/tmp/dotlrn-tarball
cd /var/tmp/dotlrn-tarball
cvs -d /cvsroot export -r openacs-5-0-0a1 acs-core
cd /var/tmp/dotlrn-tarball/openacs-4/packages
cvs -d /cvsroot export -r openacs-5-0-0a1 dotlrn-prereq
cvs -d /dotlrn-cvsroot export -r dotlrn-2-0-0a1 dotlrn-core
-
Copy the dotlrn install.xml file, which controls which packages are installed on setup, to the root location:
cp /var/tmp/dotlrn-tarball/openacs-4/packages/dotlrn/install.xml /var/tmp/dotlrn-tarball/openacs-4
-
Generate the tarball
cd /var/tmp/dotlrn-tarball
mv openacs-4 dotlrn-2.0.0a1
tar cz -f dotlrn-2.0.0a1.tar.gz dotlrn-2.0.0a1
-
Test the new tarball(s).Download the tarballs just created and install them and make sure everything looks okay and that automated tests pass.
-
Update Web site.Update the different places on OpenACS.org where we track status.
-
Clean Up.Clean up after yourself.
cd /var/tmp
rm -rf tarball dotlrn-tarball dotlrn-packages openacs-5.0.0a1
rm -rf /var/tmp/openacs-4
Here is a shell script that automates packaging the tarball (it's a bit out of date with the new steps - I've been doing everything manually or with little throwaway scripts as detailed above until the process is stabilized).
#!/bin/bash
# if TAG=1 create the cvs tags otherwise assume they exist.
TAG=1
# What release version are we building; version format should be
# dashes rather than dots eg. OACS_VERSION=5-0-0b4
OACS_VERSION=5-0-0b4
DOTLRN_VERSION=2-0-0b4
OACS_BRANCH=oacs-5-0
DOTLRN_BRANCH=dotlrn-2-0
DOTLRN_CVSROOT=/dotlrn-cvsroot
OACS_CVSROOT=/cvsroot
#
# Nothing below here should need to change...
#
BASE=/var/tmp/release-$OACS_VERSION
mkdir $BASE
if [ ! -d $BASE ]; then
echo "Failed creating base dir $BASE"
exit 1
fi
cd $BASE
if [ $TAG -eq 1 ]; then
# Checkout and tag the release
cvs -d $OACS_CVSROOT checkout -r $OACS_BRANCH openacs-4
cd openacs-4
cvs tag -F openacs-$OACS_VERSION
cd ../
# Checkout and tag the dotlrn release
mkdir dotlrn-packages
cd dotlrn-packages
cvs -d $DOTLRN_CVSROOT checkout -r $DOTLRN_BRANCH dotlrn-all
for dir in *; do ( cd $dir && cvs tag -F dotlrn-$DOTLRN_VERSION ); done
cd ../
#
# Should check for .sql .xql .adp .tcl .html .xml executable files and squak if found.
#
fi
# Generate tarballs...
#
# openacs
#
mkdir tarball
cd tarball
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION acs-core
mv opeancs-4 openacs-${OACS_VERSION//-/.}
tar -czf ../openacs-${OACS_VERSION//-/.}.tar.gz openacs-${OACS_VERSION//-/.}
cd ..
# dotlrn
#
mkdir dotlrn-tarball
cd dotlrn-tarball
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION acs-core
cd openacs-4/packages
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION dotlrn-prereq
cvs -d $DOTLRN_CVSROOT export -r dotlrn-$DOTLRN_VERSION dotlrn-core
cd ../..
cp -f openacs-4/packages/dotlrn/install.xml openacs-4
mv openacs-4 dotlrn-${DOTLRN_VERSION//-/.}
tar -czf ../dotlrn-${DOTLRN_VERSION//-/.}.tar.gz dotlrn-${DOTLRN_VERSION//-/.}
# Clean up after ourselves...
cd $BASE && rm -rf dotlrn-tarball tarball openacs-4 dotlrn-packages
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
By Malte Sussdorff
OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.
To be able to use PHP software with AOLserver (and OpenACS), you have to install PHP with AOLserver support. Get the latest version from www.php.net. For convenience we get version 4.3.4 from a mirror
[root root]# cd /usr/local/src
[root src]# wget http://de3.php.net/distributions/php-4.3.4.tar.gz
[root src]# tar xfz php-4.3.4.tar.gz
[root src]# cd php-4.3.4
[root php-4.3.4]# cd php-4.3.4
[root php-4.3.4]# ./configure --with-aolserver=/usr/local/aolserver/ --with-pgsql=/usr/local/pgsql --without-mysql
[root php-4.3.4]# make install
Once installed you can enable this by configuring your config file. Make sure your config file supports php (it should have a php section with it). Furthermore add index.php as the last element to your directoryfile directive.
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
By Jeff Davis
OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.
Best practices in writing OpenACS automated tests
-
Special characters in Tcl. Try strings starting with a -Bad and strings containing [BAD], {, \077, and $Bad. For user input, [BAD] should never be evaluated, \077 should not be turned into a ? and $Bad should not be interpolated. The string -Bad [BAD] \077 { $Bad should be valid user input, should pass through the system unaltered, and if it isn't that's a bug.
-
Quoting issues.Put some html in plain text fields and make sure the result is properly quoted anywhere it shows up (I use "<b>bold</b>" usually). Look out especially for quoting errors in the context bar and in round trips via an edit form. For fields that disallow html tags you can use & to check that the field is quoted properly. If it is not displayed as & then the quoting for the field is incorrect. (It's not clear whether this should be considered an error but given that data for text fields can come from various sources if it's text it should be properly quoted and we should not rely on input validation to prevent XSS security holes.)
-
Whitespace input.Check that whitespace is not considered valid input for a field if it does not make sense. For example, the subject of a forum post is used to construct a link and if it is " " it will have a link of <a href="..."> </a> which would not be clickable if whitespace was allowed as a valid input.
-
Doubleclick. Make sure that if you submit a form, use the back button, and submit again that the behavior is reasonable (correct behavior depends on what the form is for, but a server error is not reasonable).
-
Duplicate names. Make sure that if a duplicate name is entered that there is a reasonable error rather than a server error. Check for insert, move, copy, and rename.
Created by Gustaf Neumann, last modified by Gustaf Neumann 17 Feb 2008, at 07:08 AM
If you plan to write or edit any documentation with emacs, install a customized emacs configuration file with DocBook commands in the skeleton directory, so it will be used for all new users. The file also fixes the backspace -> help mis-mapping that often occurs in terminals.
[root tmp]# cp /tmp/openacs-5.2.3rc1/packages/acs-core-docs/www/files/emacs.txt /etc/skel/.emacs
cp: overwrite `/etc/skel/.emacs'? y
[root tmp]#
Debian users:
apt-get install psgml
Note: The new nxml mode for emacs, when used in combination with psgml, provides a pretty good set of functionality that makes DocBook editing much less painless. In particular, nxml does syntax testing in real-time so that you can see syntax errors immediately instead of in the output of the xsltproc hours or days later. For debian, apt-get install nxml.
