- I OpenACS For Everyone
- I.1 High level information: What is OpenACS?
- I.1.1 Overview
- I.1.2 OpenACS Release Notes
- I.2 OpenACS: robust web development framework
- I.2.1 Introduction
- I.2.2 Basic infrastructure
- I.2.3 Advanced infrastructure
- I.2.4 Domain level tools
- I.1 High level information: What is OpenACS?
- II Administrator's Guide
- II.2 Installation Overview
- II.2.1 Basic Steps
- II.2.2 Prerequisite Software
- II.3 Complete Installation
- II.3.1 Install a Unix-like system and supporting software
- II.3.2 Install Oracle 10g XE on debian
- II.3.2.1 Install Oracle 8.1.7
- II.3.3 Install PostgreSQL
- II.3.4 Install AOLserver 4
- II.3.5 Quick Install of OpenACS
- II.3.5.1 Complex Install OpenACS 5.3
- II.3.6 OpenACS Installation Guide for Windows2000
- II.3.7 OpenACS Installation Guide for Mac OS X
- II.4 Configuring a new OpenACS Site
- II.4.1 Installing OpenACS packages
- II.4.2 Mounting OpenACS packages
- II.4.3 Configuring an OpenACS package
- II.4.4 Setting Permissions on an OpenACS package
- II.4.5 How Do I?
- II.4.6 Configure OpenACS look and feel with templates
- II.5 Upgrading
- II.5.1 Overview
- II.5.2 Upgrading 4.5 or higher to 4.6.3
- II.5.3 Upgrading OpenACS 4.6.3 to 5.0
- II.5.4 Upgrading an OpenACS 5.0.0 or greater installation
- II.5.5 Upgrading the OpenACS files
- II.5.6 Upgrading Platform components
- II.6 Production Environments
- II.6.1 Starting and Stopping an OpenACS instance.
- II.6.2 AOLserver keepalive with inittab
- II.6.3 Running multiple services on one machine
- II.6.4 High Availability/High Performance Configurations
- II.6.5 Staged Deployment for Production Networks
- II.6.6 Installing SSL Support for an OpenACS service
- II.6.7 Set up Log Analysis Reports
- II.6.8 External uptime validation
- II.6.9 Diagnosing Performance Problems
- II.7 Database Management
- II.7.1 Running a PostgreSQL database on another server
- II.7.2 Deleting a tablespace
- II.7.3 Vacuum Postgres nightly
- II.8 Backup and Recovery
- II.8.1 Backup Strategy
- II.8.2 Manual backup and recovery
- II.8.3 Automated Backup
- II.8.4 Using CVS for backup-recovery
- II.A Install Red Hat 8/9
- II.B Install additional supporting software
- II.B.1 Unpack the OpenACS tarball
- II.B.2 Initialize CVS (OPTIONAL)
- II.B.3 Add PSGML commands to emacs init file (OPTIONAL)
- II.B.4 Install Daemontools (OPTIONAL)
- II.B.5 Install qmail (OPTIONAL)
- II.B.6 Install Analog web file analyzer
- II.B.7 Install nspam
- II.B.8 Install Full Text Search
- II.B.9 Install Full Text Search using Tsearch2
- II.B.10 Install Full Text Search using OpenFTS (deprecated see tsearch2)
- II.B.11 Install nsopenssl
- II.B.12 Install tclwebtest.
- II.B.13 Install PHP for use in AOLserver
- II.B.14 Install Squirrelmail for use as a webmail system for OpenACS
- II.B.15 Install PAM Radius for use as external authentication
- II.B.16 Install LDAP for use as external authentication
- II.B.17 Install AOLserver 3.3oacs1
- II.C Credits
- II.C.1 Where did this document come from?
- II.C.2 Linux Install Guides
- II.C.3 Security Information
- II.C.4 Resources
- II.2 Installation Overview
- III For OpenACS Package Developers
- III.9 Development Tutorial
- III.9.1 Creating an Application Package
- III.9.2 Setting Up Database Objects
- III.9.3 Creating Web Pages
- III.9.4 Debugging and Automated Testing
- III.10 Advanced Topics
- III.10.1 Write the Requirements and Design Specs
- III.10.2 Add the new package to CVS
- III.10.3 OpenACS Edit This Page Templates
- III.10.4 Adding Comments
- III.10.5 Admin Pages
- III.10.6 Categories
- III.10.7 Profile your code
- III.10.8 Prepare the package for distribution.
- III.10.9 Distributing upgrades of your package
- III.10.10 Notifications
- III.10.11 Hierarchical data
- III.10.12 Using .vuh files for pretty urls
- III.10.13 Laying out a page with CSS instead of tables
- III.10.14 Sending HTML email from your application
- III.10.15 Basic Caching
- III.10.16 Scheduled Procedures
- III.10.17 Enabling WYSIWYG
- III.10.18 Adding in parameters for your package
- III.10.19 Writing upgrade scripts
- III.10.20 Connect to a second database
- III.10.21 Future Topics
- III.11 Development Reference
- III.11.1 OpenACS Packages
- III.11.2 OpenACS Data Models and the Object System
- III.11.3 The Request Processor
- III.11.4 The OpenACS Database Access API
- III.11.5 Using Templates in OpenACS
- III.11.6 Groups, Context, Permissions
- III.11.7 Writing OpenACS Application Pages
- III.11.8 Parties in OpenACS
- III.11.9 OpenACS Permissions Tediously Explained
- III.11.10 Object Identity
- III.11.11 Programming with AOLserver
- III.11.12 Using Form Builder: building html forms dynamically
- III.12 Engineering Standards
- III.12.1 OpenACS Style Guide
- III.12.2 Release Version Numbering
- III.12.3 Constraint naming standard
- III.12.4 ACS File Naming and Formatting Standards
- III.12.5 PL/SQL Standards
- III.12.6 Variables
- III.12.7 Automated Testing
- III.13 CVS Guidelines
- III.13.1 Using CVS with OpenACS
- III.13.2 OpenACS CVS Concepts
- III.13.3 Contributing code back to OpenACS
- III.13.4 Additional Resources for CVS
- III.14 Documentation Standards
- III.14.1 OpenACS Documentation Guide
- III.14.2 Using PSGML mode in Emacs
- III.14.3 Using nXML mode in Emacs
- III.14.4 Detailed Design Documentation Template
- III.14.5 System/Application Requirements Template
- III.15 TCLWebtest
- III.16 Internationalization
- III.16.1 Internationalization and Localization Overview
- III.16.2 How Internationalization/Localization works in OpenACS
- III.16.4 Design Notes
- III.16.5 Translator's Guide
- III.D Using CVS with an OpenACS Site
- III.9 Development Tutorial
- IV For OpenACS Platform Developers
- IV.17 Kernel Documentation
- IV.17.1 Overview
- IV.17.2 Object Model Requirements
- IV.17.3 Object Model Design
- IV.17.4 Permissions Requirements
- IV.17.5 Permissions Design
- IV.17.6 Groups Requirements
- IV.17.7 Groups Design
- IV.17.8 Subsites Requirements
- IV.17.9 Subsites Design Document
- IV.17.10 Package Manager Requirements
- IV.17.11 Package Manager Design
- IV.17.12 Database Access API
- IV.17.13 OpenACS Internationalization Requirements
- IV.17.14 Security Requirements
- IV.17.15 Security Design
- IV.17.16 Security Notes
- IV.17.17 Request Processor Requirements
- IV.17.18 Request Processor Design
- IV.17.19 Documenting Tcl Files: Page Contracts and Libraries
- IV.17.20 Bootstrapping OpenACS
- IV.17.21 External Authentication Requirements
- IV.18 Releasing OpenACS
- IV.18.1 OpenACS Core and .LRN
- IV.18.2 How to Update the OpenACS.org repository
- IV.18.3 How to package and release an OpenACS Package
- IV.18.4 How to Update the translations
- IV.17 Kernel Documentation
- V Tcl for Web Nerds
- V.1 Tcl for Web Nerds Introduction
- V.2 Basic String Operations
- V.3 List Operations
- V.4 Pattern matching
- V.5 Array Operations
- V.6 Numbers
- V.7 Control Structure
- V.8 Scope, Upvar and Uplevel
- V.9 File Operations
- V.10 Eval
- V.11 Exec
- V.12 Tcl for Web Use
- V.13 OpenACS conventions for TCL
- V.14 Solutions
- VI SQL for Web Nerds
- VI.1 SQL Tutorial
- VI.1.1 SQL Tutorial
- VI.1.2 Answers
- VI.2 SQL for Web Nerds Introduction
- VI.3 Data modeling
- VI.3.1 The Discussion Forum -- philg's personal odyssey
- VI.3.2 Data Types (Oracle)
- VI.3.4 Tables
- VI.3.5 Constraints
- VI.4 Simple queries
- VI.5 More complex queries
- VI.6 Transactions
- VI.7 Triggers
- VI.8 Views
- VI.9 Style
- VI.10 Escaping to the procedural world
- VI.11 Trees
- VI.1 SQL Tutorial
IV.18.1 OpenACS Core and .LRN
-
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.
.LRN: this must be repeated for .LRN modules (dotlrn-core in the dotlrn cvs tree) and for any modified modules in the .LRN prerequisites (dotlrn-prereq in openacs cvs tree). My current working model is that I bulk-update .LRN and OpenACS core but that I don't touch dotlrn-prereq modules - I just use the most recent release and it's up to individual package developers to tag and release those packages when they change. This model is already broken because following it means that dotlrn-prereqs don't get new translations.
-
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.
-
Release Status for the current version - something like http://openacs.org/projects/openacs/5.0/milestones
-
Home page of openacs.org
-
Post a new news item
-
-
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