Showing 1 - 10 of 855 Postings (summary
Created by OpenACS community, last modified by Gustaf Neumann 27 Apr 2017, at 07:40 AM
See one of these:
Should you decide to install OpenACS from source using general en:openacs-system-install instructions, refer to these notes for changes:
OS X conventions
On Mac OS X type sudo su - to become root.
Use curl -L -O instead of wget
If you are running Mac OS X prior to 10.3, you should be able to install and use PostgreSQL 7.3.x. Mac OS X 10.3 requires PostgreSQL 7.4. Note: if you're installing PG on an Intel Mac, you'll need to install 8.x; 7.4.x won't compile because of a lack of "native spinlock support" -- and this is something that the PG maintainers aren't inclined to fix. See this. PG 8.0.x installs fine, as does PG 8.1 or 8.2.
Creating postgres user
Do this instead:
First make sure the gids and uids below are available (change them if they are not). To list taken uids and gids:
nireport / /groups name gid | grep "[0-9][0-9][0-9]"
nireport / /users name uid | grep "[0-9][0-9][0-9]"
Now you can install the users
sudo niutil -create / /groups/web
sudo niutil -createprop / /groups/web gid 201
sudo niutil -create / /users/postgres
sudo niutil -createprop / /users/postgres gid 201
sudo niutil -createprop / /users/postgres uid 502
sudo niutil -createprop / /users/postgres home /usr/local/pgsql
sudo niutil -create / /users/$OPENACS_SERVICE_NAME
sudo niutil -createprop / /users/$OPENACS_SERVICE_NAME gid 201
sudo niutil -createprop / /users/$OPENACS_SERVICE_NAME uid 201
mkdir -p /usr/local/pgsql
chown -R postgres:web /usr/local/pgsql /usr/local/src/postgresql-7.4.7
chmod 750 /usr/local/pgsql
Compile and install PostgreSQL
If you're using Fink:
Append --with-includes=/sw/include/ --with-libraries=/sw/lib flags to ./configure.
./configure --with-includes=/sw/include/ --with-libraries=/sw/lib
Set PostgreSQL to start on boot
tar xfz /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/files/osx-postgres-startup-item.tgz
Alternatively, one can use an XML file like the following to start PostgreSQL via launchd (specifying the postgres binary directory and database directory)
For Mac OS X Tiger (10.4.*), use:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
For Mac OS X Leopard (10.5.*), use:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Save the above files as /Library/LaunchDaemons/org.postgresql.PostgreSQL.plist and postgres will be started automatically on the next boot of the system. One can use launchctl to start the service for testing;
launchctl % load /Library/LaunchDaemons/org.postgresql.PostgreSQL.plist % start org.postgresql.PostgreSQL % ^D
To get Tcl to build on Leopard or newer
for compiling under Mac OS X Leopard or newer, use the following flags to compile Tcl:
./configure --prefix=/opt/aolserver --enable-threads --disable-corefoundation --enable-symbols
To get tDOM to build on tiger
- Download and install/update to the latest version of xcode tools (version2.2) from http://developer.apple.com/tools/xcode which updates the gcc compiler.
- Then make some additional changes to the unix/CONFIG file (after modifying the unix/CONFIG file according to instructions at en:aolserver-install, uncomment:
'CC=gcc; export CC'
- add a new line, somewhere after the first line:
When versions of AOLservers different to AOLserver 4.5 (head, including changes from Mar 22, 2008) are used, AOLserver is likely to segfault on startup due to recent changes in the Mac OS X System libraries. To avoid this, use
ulimit -n 256
in the startup script (don't use unlimited).
Created by Gustaf Neumann, last modified by Gustaf Neumann 27 Apr 2017, at 07:26 AM
This page describes how to install OpenACS with NaviServer on Unix-like systems (e.g. Linux, Mac OS X, Solaris, OmniOS) by compiling all but PostgreSQL from scratch, guided by script that collects the components from various sources, compiles it, etc.
The installation is done in two steps:
- install-ns.sh : Install NaviServer and its components for a PostgreSQL installation from scratch by obtaining the relevant sources and compiling it. The script assumes PostgreSQL to be installed (or obtainable via package managers), but installs all other components by obtaining it from the source repositories and compiling it from scratch (e.g. Tcl, tcllib, tDOM, libthread, nsf/XOTcl 2).
- install-oacs.sh : Install OpenACS from CVS/git. This script configures a (pre-installed) PostgreSQL installation for
OpenACS, adds hstore, installs OpenACS core, basic OpenACS packages, xowiki, xowf and optionally dotlrn from CVS/git and generates a config file and startup files (for Ubuntu and Fedora Core). The script assumes a pre-existing NaviServer installation, installed e.g. via install-ns.sh
These install scripts are frequently updated when now components are released or problems are detected (commit log ).
If you open the links above, use save-as in the browser to save the files. Alternatively, download the files as .zip file or clone the repository via GitHub .
git clone https://github.com/gustafn/install-ns
The scripts work under a typical Linux installation (e.g. Ubuntu, Fedora Core) as well as on Mac OS X or on OmniOS. The scripts are tested with PostgreSQL 9.1, 9.2, 9.3, 9.4 and 9.5 on Ubuntu 12.04, 13.04, 14.04, Fedora Core 18 and CentOS 7.
On a a fresh Ubuntu installation, you should be able to download the two scripts from this page and install OpenACS with NaviServer in the following steps:
bash install-ns.sh build
bash install-oacs.sh build
After running both scripts in the default configuration you will see e.g. on Ubuntu 14.04
Congratulations, you have installed OpenACS with NaviServer on your machine.
You might start the server manually with
sudo /usr/local/ns/bin/nsd -t /usr/local/ns/config-oacs-5-9.tcl -u nsadmin -g nsadmin
One can start the server manually with the mentioned command.
Alternatively, one can manage the service with upstart (Ubuntu/Debian). For upstart, the the generated startup file is in /etc/init/oacs-5-9.conf. The service can be started/managed with the following commands
sudo initctl status oacs-5-9
sudo initctl start oacs-5-9
sudo initctl stop oacs-5-9
On Fedora/CentOS or on Ubuntu installations starting with 15.04, systemd is used. The generated startup file for RedHat/Fedora is in /lib/systemd/system/oacs-5-9.service. The startup commands for systemd are
sudo systemctl status oacs-5-9
sudo systemctl start oacs-5-9
sudo systemctl stop oacs-5-9
Remember, when a new systemd service is installed, systemd requires the following command to re-scan its service files:
sudo systemctl daemon-reload
To start OpenACS automatically on every new start of the machine, issue the following command:
sudo systemctl enable oacs-5-9
When the service is running, one can use use OpenACS by browsing to http://localhost:8000/ (when the browser and server is running on the same host). The configuration file is /usr/local/ns/config-oacs-5-9.tcl and might be tailored to your needs. The access.log and error.log of this instance are in /var/www/oacs-5-9/log/
Created by Maurizio Martignano, last modified by Maurizio Martignano 26 Apr 2017, at 07:38 PM
Windows-OpenACS (vers. 3.2.0 - April 2017) is a Windows 64 port of OpenACS 5.9.0 and the latest snapshot of NaviServer and is available here.
This port installs and runs on the following systems:
- Windows 8.1,
- Windows 10,
- Windows Server 2012 R2, and
- Windows Server 2016 TP.
Created by Gustaf Neumann, last modified by Michael Aram 24 Apr 2017, at 05:15 PM
OpenACS (5.8) works with PostgreSQL 9.1 or newer out of the box, no special configurations in postgresql.conf are needed like with previous versions.
To work with PostgreSQL 9, one has to use an actual postgres driver:
OpenACS core + commonly used packages (search, forums, xowiki, ...) have been tested with PostgreSQL 9.2.4
For new installs, OpenACS 5.8 works without further considerations. When upgrading the database to PostgreSQL 9.*, one has to keep in mind, that not only the sql-install scripts have to be SQL 9.* compatible, but as well the update scripts (migration scripts). During the work for making OpenACS compatible with PostgreSQL 9.*, we did not update (all) of the migration scripts (e.g. kernel upgrades) of earlier versions, therefore one should run the upgrade scripts to OpenACS 5.7 with an PostgresSQL 8.* database.
Therefore, the following upgrade steps are recommended for upgrading from OpenACS 5.5 to 5.7 to OpenACS 5.8:
- For users of PostgreSQL versions earlier than 8.4: In case you run a version of OpenACS earlier than 5.5 then upgrade first your code to OpenACS 5.5 (oacs-5-5 branch from the CVS Repository), then dump your database and reload it into PostgreSQL 8.4 (e.g. into PostgreSQL 8.4.22, the end-of-life of which was in July 2014). Then continue with the next step below.
- For users of PostgreSQL version 8.4 (or newer before 9): Make sure, you are running Tcl 8.5, then get OpenACS 5.8 (not 5.9) and upgrade OpenACS and your used packages (e.g. via acs-admin/apm + "install packages"). Then dump the database and restore it in PostgreSQL 9.*.
Created by OpenACS community, last modified by Gustaf Neumann 24 Apr 2017, at 08:53 AM
Current topic: What approach should we use to upgrade the documentation?
See Documentation_Project for the current draft of "the plan".
Here are some recent approaches expressed in one form or another for managing the documentation in the context of "the plan":
Approach 0. Why not use docbook, which was the previous way documentation was being handled?
- docbook is open-source.
- A growing community surrounds DocBook (has mailing lists)
- A number of free and commercial tools are available for editing and publishing DocBook documents.
- docbook enables us to publish in a variety of formats.
- XML separates content from presentation: It relieves each contributor of the burden of presentation, freeing each writer to focus on content and sharing knowledge.
- docbook is well tested technology. It has been in development since the early 1990's).
problems: In 2002, Docbook still was not fully capable of representing online books as practiced by book publishers and expected from readers with regards to usability on the web. That meant DocBook did not entirely meet OpenACS publishing requirements at that time.
In 2004, Docbook released version 4.2, which complies with all the OpenACS publishing requirements. Producing a web friendly book hierarchy arguably remains DocBooks' weakest point. For example, a dynamically built document should be able to extract details of a specific reference from a bibliographic (table) and present a footnote at the point where referenced. DocBook 4.2 allows for this with bibliocoverage, bibliorelation, and bibliosource. Yet, OpenACS documentation does not follow a standard book hierarchy since most of the documentation was written before version 4.2, and re-organizing it in docbook source would be challenging.
Other problems with using docbook:
- Only developers can make changes, which makes it difficult for the rest of the community to coordinate changes and updates, especially when they are seemingly small (such as typos).
- OpenACS docbook has long documents, which puts extra stress on using consistent style to separate topics on the same page. For example, readers get confused when trying to follow the installation documents. Some instructions get missed, other instructions are done when they shouldn't have been.
- OpenACS docbook uses multiple tags for the same function and requires only certain tags to be used in certain contexts. The documentation in HTML is convoluted and displays inconsistent.
Based on the other recent suggestions, there seems to be a general consensus to move away from docbook, but perhaps keep the docbook organization.
- First: ..attempt to take the rest of Documentation over to XoWiki..
- Secondly: ..try to setup an automated versioning system. We should end up with categories such as 5.2 Documentation, 5.3 Documentation, HEAD Documentation, etc. My current thinking is that we can work on HEAD category of documentation, once 5.3 is release it becomes categorized as such and a copy of the docs gets created and re-categorized as HEAD once again. This should allow versioning and easy upgrades/editing of docs (well easy may not be the right word, docs are a lot of work)
Robert, "Secondly" is how versioning has been accomplished using docbook. This method seems to work fine, and we can do it with xowiki docs by creating a set of static pages from the xowiki ones. --Torben
Approach 2. from [en:Structure_Ideas], Robert writes:
Documentation: [move] ..the rest of the documents to XoWiki. The idea would be to have categorized documents. We would start by moving the 5.2 docs over and expanding on them. When 5.3 is release we would do an automated copy/paste of the 5.2 docs, re-categorize as 5.3 and start the editing process. This is just preliminary thinking at this point..
Robert, everyone seems to have their own way of slicing and dicing docs into categories. We ought to use the existing documentation requirements to guide how the documents are organized, and then they can be categorized any number of ways since multiple categories can be applied to each page. --Torben
STAGE A: CONVERT DOCUMENTATION TO XOWIKI (note: all api docs remain the same) Step #1. Catalog the current documentation.
(Malte writes) ..modify the script Gustaf provided to import the whole documentation in one go into a new XoWIKI instance with the structure (page_order) that has been added in XoWIKI 0.42 taken from the chapters of the documentation so that we do have an exact mirror of the documentation as it stands now. [Done, see http://openacs.org/test-doc].
Malte, why would we want an exact mirror of something that is not organized well.. too many topics per page and pages inconsistently presented.. requires a new reader to jump around to get familiarized with material. etc etc? Why not copy the docbook contents into a cleaner outline and work from there (as in approach 3 above)? --Torben
Torben, the /doc section is organized. That you do not like it is obvious and we could rework it later, but until we have the resource to rewrite the whole documentation, it makes much more sense to improve the documentation we have instead of putting it into the graveyard. And we need to come to terms. This discussion does not yield any results at the moment but keep us from doing the actual work: Improving the documentation -- Malte
[Then] ..assign categories to the documentation, allowing for an alternative view on the documents (so you could say "instead of showing the whole documentation only show the documents for a specific category"). Probably this needs some more detailed discussion with Gustaf finding out how this could be achieved in XoWIKI and what would make most sense. Ideally we could provide a different structure based on the target group (e.g. category) but this is probably shooting too far. Getting categorization and page ordering in a decent shape should provide us a lot of possibilities..
Malte, have you seen docs-admin-toc , docs-end-user-toc and docs-eng? These are outlines of existing pages in xowiki that represent a revised version of the Table of Contents (TOC) in the docbook version. Feel free to propose new pages there for us to fill in content. --Torben
Yes I have seen them. Do they resemble a book in any way to you? They are alternative structures, indeed, but you can impose them on a book view as well, any time. A book is what we need, something people can go to and start reading. If the book starts with four different pages, each outlining a different reading path, even the better. But a book it should be nevertheless, because this is how people still learn. If you do not like the book approach, that is fine, then we should open this question up for a TIP. My main goal at the moment is to finally get this done and start working. And I want to get rid of the myriads of confusing advise given at openacs.org. I have someone to work with me on that in the next two months and I want to have a clear way to go forward. So I will just TIP this. -- Malte
..port docbook pages to xowiki manually.. look at each part in detail.. separate to subsystems and how they are used (context). Why? "..the human mind can only deal with a relatively small number of independent pieces of data at one time, but if data are chunked together in appropriate ways, the mind can perform higher order abstractions, and these in turn can be chunked together, with successive abstractions, until an entire complex situation is encompassed. The systems approach addresses this property of the human mind by providing strategies for the data gathering, chunking, and abstracting process." George G. Lendaris, On Systemness and the Problem Solver: Tutorial comments 1983.
This work is in progress, with main page here: en:openacs-handbook
A systems strategy of multiple perspectives has these simple rules:
- Each xowiki page discusses a single topic.
- Topics are linked together by any number of other xowiki pages to present an ordered presentation of the topics with a common thread/topic connecting them. For example, en:openacs-system-install is a page that links together the topics of installing the component software of OpenACS. Similarly, each component software, such as en:aolserver, has its own view of some overlapping topics.
multiple perspectives meets these significant documentation requirements:
- helps identify subsystems and how OpenACS works --becomes a natural tutorial without more words.
- reduces the burden of keeping documentation up to date since there is only one place to put relevant information for a particular topic --no redundancy
- pages are not organized by a dominant category morphology that tends to address the perspectives of just a few people. Most any perspective can be represented.
- Readers do not have to filter out a bunch of information that is irrelevant to them or their task at hand.
Move all but maybe the first and last 2 items from http://openacs.org/doc/dev-guide.html to http://openacs.org/doc/acs-kernel/ (and what ever else is relevant to kernel only); and move the first item to http://openacs.org/doc/acs-admin etc. That way the core docs are presented in a consistent context with the other packages. Also, do not migrate these docs around as a package is designated part of the core (or subsequently removed from it). This would help developers see appropriate context (and meets one of the documentation requirements).
Allow documentation to link directly to the api-docs, to reduce redundancy and links go to current, local API docs. In other words, http://openacs.org/api-doc/package-view?version_id=358136 becomes: /api-doc/index?about_package_key=acs-datetime The feature has been added to OpenACS 5.3 so will be released soon.[DONE]
Move Administrator's Guide to the xowiki [in progress, see en:docs-admin and en:docs-admin-toc ], because this section:
- has the most duplicated work (topics overlap on various pages). For example, more than one page explains how to add a package, how to restart the server, how to start the server etc.
- needs to be updated most frequently because of changing installation requirements. For example, PostgreSQL requires different instructions for different revisions, external links change sporadically etc.
Incorporate the work already done in the first wiki ( http://openacs.org/wiki ), where volunteers have already added a wealth of new documentation. Note that some of this will already exist in xowiki from previous importing of docs etc. [TO DO]
We need to get rid of the myriads of different installation instructions. First of all they are not kept up to date (all of them). -- Malte
Created by Malte Sussdorff, last modified by Gustaf Neumann 24 Apr 2017, at 08:44 AM
If you have a table to be displayed on your webpage, use listbuilder (template::list::create) to create it. There is some documentation here and http://openacs.org/wiki/list%20builder which will be moved here real soon now ;).
One standard, which you should try to follow for re-usability, is to put the created list in a separate include file, so you could call it from various pages and packages. Things to keep in mind when doing this:
- Pass a list of rows so you know which columns should be displayed on your page
- Name the "orderby" field specific to the type of list: "tasks_orderby" "projects_orderby"
- You might want to do the same with filters (to be on the safe side)
Created by roc@, last modified by Gustaf Neumann 22 Apr 2017, at 02:54 PM
This are instructions to obtain OpenACS, either as a released distribution (a .tar.gz file) or from CVS.
Obtain a released version of OpenACS via .tar file:
Download from OpenACS.org: //projects/openacs/download/?versions=all
Unpack the OpenACS tarball. Usually something like this works:
tar zxvf openacs-5.9.0.tgz
Obtain OpenACS from CVS (a certain release with potential patches, or the HEAD version):
If you want to track fresh code developments between releases, or you are an OpenACS core developer, you may want to install from CVS. This is identical to downloading a distribution, except that you get the files from CVS instead of the tarball. The following commands are used to obtain the newest version of the OpenACS 5.9 branch from CVS:
cvs -d:pserver:firstname.lastname@example.org:/cvsroot login
# press enter for password
cvs -d:pserver:email@example.com:/cvsroot checkout -r oacs-5-9 acs-core
The command above checks out the core packages of OpenACS in a directory named openacs-4. For the entire OpenACS version 5.9 branch you can use the following commands (adjust as required going forward):
cvs -d:pserver:firstname.lastname@example.org:/cvsroot checkout -r oacs-5-9 openacs-4
If the the branch name (like oacs-5-9) is omitted, the the leading edge developer version (the HEAD release) is obtained
cvs -d:pserver:email@example.com:/cvsroot checkout openacs-4
In order to check out a single package (e.g. the package cronjob) from e.g. the leading edge developer version (HEAD), use
cvs -d:pserver:firstname.lastname@example.org:/cvsroot checkout openacs-4/packages/cronjob
For most OpenACS packages, CVS aliases are defined. In order to checkout e.g. the forums package from OpenACS 5.5, just use:
cvs -d:pserver:email@example.com:/cvsroot checkout -r oacs-5-9 forums
Depending, from which directory you are performing the checkout, you might have to move the checked-out package directory to the main "packages" directory of your installation.
More info here: http://www.openacs.org/test-doc/using-cvs-with-openacs
Looking for README instructions or installers? View the OpenACS Installation instructions: en:openacs-system-install, otherwise continue by setting up the OpenACS distribution:
Set up the file system for one or more OpenACS sites
For Linux Standard Base compliance and ease of backup, all of the files in each OpenACS site are stored in a subdirectory of /var/lib/aolserver, one subdirectory (SERVERROOT) per site (see: en:openacs-reference-platform). The first time you install an OpenACS site on a server, you must create the parent directory and set its permissions:
While logged in as root:
mkdir -p /var/lib/aolserver
chgrp web /var/lib/aolserver
chmod 770 /var/lib/aolserver
Move the uncompressed code to SERVERROOT and rename the directory to $OPENACS_SERVICE_NAME:
mv openacs-4 /var/lib/aolserver/$OPENACS_SERVICE_NAME
Created by OpenACS community, last modified by Gustaf Neumann 22 Apr 2017, at 02:53 PM
Install a *nix-based operating system (OS)
Follow the installation directions that come with the distribution.
There are generally 2 strategies at this point:
- Install an OS with minimum programs, or
- Install a suite of programs, for example choose between a developer set or desktop set.
We recommend installing only the OS to minimize the chances of conflicts resulting from installing 2 or more copies of one of the OpenACS system components openacs-system.
The impatient reader might want to check out the two scripts at naviserver-openacs which can be used to install OpenACS from scratch on a variety if systems (including Debian/RHEL Linux or Mac OS X), and which lists the detailed dependencies during the build process. Below, we describe in detail the steps.
Many additional programs, such as a build environment (gcc), Mail Transport Agent (MTA), and source control system, are also needed for a fully operational installation. Most of these are included with a basic OS installation.
Install some helper software
You might want to install some of these after a minimum OS install, since OpenACS administration usually assumes you have these (or alternates) installed:
- emacs or vi/vim
- bash shell (usually automatically installed with Linux distributions)
- gcc or equivalent (along with standard distribution source libraries) - if you plan to install software from source.
- ImageMagick - used by some packages for server side image processing
- aspell - used to offer spell checking in forms
*nix install guides
some helpful documentation for installing *nix flavors
*nix-based systems without installing *nix
These DEMOs install a temporary *nix OS on your system:
Or, lease a hosted system with a *nix OS and OpenACS installed on it.
See companies that host OpenACS websites.
Securing your system
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 22 Apr 2017, at 02:50 PM
Welcome to the OpenACS Wiki!
This is the OpenACS Wiki system, built with the xowiki package. This wiki contains user documentation, how-tos, and tips and tricks related to OpenACS. It also serves as a collaboration area for OpenACS contributors.
OpenACS Handbook: openacs-handbook
OpenACS Packages: packages
OpenACS Installation: openacs-system-install
Recent Wiki Page Edits:
Documentation Non-Core Packages
Tutorials for Designers
Tutorials for Administrators
Tutorials for Programmers
Created by Héctor Romojaro, Stefan Sobernig, last modified by Gustaf Neumann 20 Apr 2017, at 10:33 PM
Please, review the section on supported distributions first. Currently, the core packages (openacs, dotlrn) and their dependencies are included into the official Debian GNU/Linux repositories.
- (optional) Provide for a PostgreSQL environment: If you don't have a PostgreSQL installation at hand, provide one. You do not need to care about setting up a concrete data base. This is automatically done by the openacs and dotlrn post-install instructions. For further PostgreSQL-related set-up issue, see ...
apt-get install postgresql
If you run a remote PostgreSQL instance, remember to allow for access of the PostgreSQL Administrator (postgres) and the openacs/dotlrn user from machine hosting your OpenACS/.LRN installation.
- Install the core packages and follow the on-screen instructions:
apt-get install openacs
... or ...
apt-get install dotlrn
- (optional) To change IP address and port of the instance, please edit the file:
(optional) To control the instance using daemontools, please install the daemontools debian packages and follow the instructions on the file:
Next Steps, After Basic Installation (above)
- Héctor Romojaro
- Stefan Sobernig
- Avni M. Khatri
- Carl R. Blesius