Showing 81 - 90 of 692 Postings (
summary)
Created by OpenACS community, last modified by Gustaf Neumann 25 Sep 2019, at 10:13 PM
This is Approach 4 of the en:Documentation_Project as defined in Documentation_Project_Discussion. Users benefit when they can read docs the way the brain likes to work. Contributions to various OpenACS topics that further the plan are welcome.
Background
See Documentation history
Goal
to write superb documentation, so that users, developers and administrators of OpenACS installations can enjoy working with and using the system (with fewer headaches! =)
Scope
OpenACS documentation, a systems view as a collection of subsystems and their parts.
API Documentation: there are no plans to move the API docs to XoWiki. That should remain as is.
DocBook docs at: https://openacs.org/doc/index.html are evolving separately at en:New_Documentation_Process
Requirements
Requirements is about setting specifications and milestones we can verify, and includes exploration of scenarios, use cases etc.
Here are documentation requirements for:
Available resources
- volunteers dedicated to regularly managing and updating the documentation
- other volunteers who contribute arguably more valuable documentation less frequently (such as magazine articles ;) (and may need some assistance etc. to have their work fit into docs well.)
- openacs.org website, including use of xowiki
- open-source software, text editors, spell checkers, HTML code validators etc.
- Approaches in docs management explored. See en:Documentation_Project_Discussion
Strategy
Strategy is about creating an approach to doing work. It guides behavior and tactical decisions on the work effort.
Shape ongoing documentation efforts by using principles of continual improvement and following general requirements to re-engineer documentation production and management.
OpenACS documentation development is subject to constraints of the software project development and release methods and cycles (the section called “Using CVS with OpenACS”). Essentially, all phases of work may be active to accommodate the asynchronous nature of multiple subprojects evolving by the efforts of a global base of participants with culturally diverse time references and scheduling idiosyncrasies.
The documentation strategy is to use methods that inspire collaborating or obtaining guidance or feedback (peer review) to distribute the workload and increase the overall value of output for the OpenACS project.
subdivide by 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.
XoWiki docs can use a systems strategy of multiple perspectives to help identify subsystems and how OpenACS works.
Each XoWiki page discusses a single topic.
These topics are pieced 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.
XoWiki documents organized by subsystems (and how they are used) are easy to update and maintain since there is only one place to put relevant information for a particular topic.
Pages are not encumbered by a maze of categories that tend to only address one or a few perspectives, since pages link to related pages, and a page that addresses each perspective can link to overlapping topics.
In an ideal world, XoWiki will be able to export a page and all the pages that link to it, to any depth of the linkage tree, to form one document. That way, innumerable documents, each with a valid perspective, can be built for a specific purpose.
Work Breakdown Structure
Or Objectives and Key Results (OKRs) is about explicitly stating the way to implement the strategy as a set of milestones and the methods to use.
Allow document writers to reference package API via api-doc by using package_url, or find the local package_id so a link can be supplied from the local documentation to current, up-to-date API and SQL docs, like: https://openacs.org/api-doc/package-view?version_id=358136 use links like this: /api-doc/index?about_package_key=acs-datetime The feature has been added to cvs head (OpenACS 5.3.x) so will be released soon.[DONE]
Iterate through each topic on each docbook page.
- Port the docbook pages to xowiki manually, because it allows me to look at each part in details and separate to subsystem/object context. Here is the process:
- Browse to docbook url (something in this tree: https://openacs.org/doc/)
- View page source
- Copy the relevant part of source
- Paste that source to your favorite text editor (not word processor).
- Edit the page source, removing DIV tags and TARGET="_blank" attributes. Look for any immediate way to improve the document, make additional edits, check for spelling etc.
- In a browser, open or create the xowiki page. Choose "Source" to view source html. Be sure to make Name starting with "en:"
- Paste edited source into the xowiki page, repeat editing if needed
- Click "ok" to post the xowiki changes.
- That's it! (repeat)
Example documentation outline in wiki
These pages contain links to other pages where items are discussed in context:
These pages describe various OpenACS subsystems, and link to external documents where possible and appropriate. Note that an "OpenACS system" en:openacs-system page that outlines the system and ties these together is part of the end-user docs.
Auxiliary systems
| en:ide-emacs |
gnu emacs as IDE |
| [en:ide-emacs-nxml] |
gnu emacs nXML Mode |
| [en:ide-emacs-psgml] |
gnu emacs PSGML Mode |
| en:ide-vi |
vi/vim as IDE |
Verification
This is where we measure how well this plan was implemented. Success is measured by
- A) verifying if the project has met the established goals and requirements, and
- B) reviewing for ongoing problem areas etc.
Observations then help to modify the plan for the next documentation revision.
OpenACS follows verification through different means on different projects, but in all cases, the OpenACS community verifies the project as a success through feedback including bug reports, user and administrator comments, and code changes.
Related links and sources
https://www.divio.com/blog/documentation/
Created by Dirk Gomez, last modified by Gustaf Neumann 25 Sep 2019, at 10:05 PM
This page is mostly obsolete. Please refer to the newer guides for Ubuntu and Debian or the generic generic installer script.
Goal
Get all required software to run OpenACS into the next release of Ubuntu Server and Debian
Dates
- Debian: Dates are not published. Release cycle ~2 years. The required packages mostly exist already in unstable
- Ubuntu: Next Debian Import Freeze for the Hardy Heron (Ubuntu 8.04) release is December 13th 2007 at which point new versions of packages will be automatically imported from Debian unstable. After this date, packages will only be imported from Debian in this way by explicit request from a developer.
Prior Work
As far as we know to this point, there are several bodies of work, including Dirk Gomez's, Jim Lynch's, and some others. While our goal is to combine, for now I'll just put a list and as we begin to work together, we'll combine how we decide to.
- work of Jim Lynch
- A pair of scripts and some other stuff available as an arch repository (see applicable documentation on gnu arch and below for specifics on this project). Essentially, the plan is to package by taking everything in an openacs tarball except the packages/ dir, put that into a package called openacs-base, put each openacs package into its own package whose name is specified in the .info file and make a metapackage called openacs-core which installs all of the above.
- Overall, I want to be able to:
- feed an openacs tarball to one of these scripts and have it then generate a pile of debian packages which represent the entire tarball, and
- be able to package any openacs package that wouldn't otherwise come in (say) an openacs core tarball.
- Upon installation, there will be a script which builds a service by copying all of core into a dir specified in part by the user and in part based on the service name. In this process, the config file and startup scripts are established as well as the daemontools "run" script. A database for the service is created, and the service is started. From there, the new site admin will visit the site with the browser, fill out the form and hit "install data model" as is normal, and you end up with a running service after aolserver is hammered.
- All non-core packages can be built into debian packages as well, identically to the packaging of core packages.
- To get: (HI! Can someone besides me (jiml at cvs.openacs) see if this works?)
the archive's physical location is
http://jam.sessionsnet.org:7000/~jim/{archives}/jim@jsn.org--2004-pub
the archive name (valid once you register the archive) is
jim@jsn.org--2004-pub
and the category, branch and version is specified as
openacs-deb-packager--mainline--0.1
so you would feed the physical location to "tla register-archive", and then you can "tla get jim@jsn.org--2004-pub/openacs-deb-packager--mainline--0.1".
- combination (eventual goal hopefully)
List of Packages
The following table list the packages, and version, needed to install OpenACS 5.3/5.4 or .LRN 2.3/2.4
| Package |
Version in debian/etch |
Version in debian/sid (unstable) |
Recommended Version |
| aolserver4 |
4.0.10-7 |
4.5.0-14 |
-- |
| aolserver4-nspostgres |
4.0-3 |
4.0-4+b1 |
-- |
| aolserver4-nssha1 |
0.1-1 |
0.1-1.0.1 |
-- |
| aolserver4-nsxml |
1.5-1 |
1.5-1.0.1 |
NONE don't use nsxml |
| aolserver4-nsopenssl |
3.0beta22-3 |
3.0beta22-3+b1 |
-- |
| aolserver4-nscache |
1.5-1 |
1.5-1.0.1 |
-- |
| aolserver4-dev |
4.0.10-7 |
4.5.0-14 |
-- |
| tdom |
0.7.8-5 |
N.A. |
0.8.2 ?? |
| htmldoc |
1.8.27-2 |
1.8.27-2+b1 |
-- |
| tcllib |
1.8-1 |
1.10-dfsg-2 |
1.10 |
| daemontools-installer |
0.76-9.2 |
0.76-9.2 [contrib] |
-- |
| postgresql-8.1 |
8.1.9 |
postgresql-8.1 (8.1.10-1) AND postgresql (8.2.5-4) |
I think Ubuntu has 8.2 now |
| postgresql-client-8.1 |
8.1.9 |
postgresql-client-8.1 (8.1.10-1) AND postgresql-client (8.2.5-4) |
-- |
| postgresql-contrib-8.1 |
8.1.9 |
postgresql-contrib-8.1 (8.1.10-1) AND postgresql-contrib (8.2.5-4) |
-- |
| xotcl |
1.6.0 |
1.6.1 |
1.6.1 |
| tclthread |
20030827-2 |
2.6.5 |
2.6.5 |
Verifying installability on Debian 4rc3 sid/unstable
Basic installation steps for oacs-5-4 based on Debian 4rc3 unstable/sid:
- Existing binary dependencies in Debian 4rc3 unstable/sid repository (Feb 26, 2008)
~$ aptitude install tcllib postgresql-8.2 aolserver4 aolserver4-nscache aolserver4-nssha1 aolserver4-nspostgres tclthread tcllib
- Missing binary dependencies in Debian 4rc3 unstable/sid repository (Feb 26, 2008: tdom 0.8.x, xotcl):
a) tdom
# build dependencies: tdom
aptitude install tcl-dev aolserver4-dev
# fetch tdom 0.8.3
cd /tmp
cvs -z3 -d:pserver:anonymous@cvs.tdom.org:/usr/local/pubcvs co tdom
cd tdom/unix
# build tdom 0.8.3
../configure --enable-threads --disable-tdomalloc --prefix=/usr/lib/aolserver4 --exec-prefix=/usr/lib/aolserver4 --with-aolserver=/usr/include/aolserver4 --with-tcl=/usr/lib
make install
b) xotcl (based on forthcoming Debian distribution)
# fetch temporary i386 builds from http://media.wu-wien.ac.at/download/debian
wget http://media.wu-wien.ac.at/download/debian/xotcl_1.6.0-1_i386.deb
wget http://media.wu-wien.ac.at/download/debian/aolserver4-xotcl_1.6.0-1_i386.deb
# package install
dpkg -i xotcl_1.6.0-1_i386.deb
dpkg -i aolserver4-xotcl_1.6.0-1_i386.deb
- OpenACS as such ...
useradd oacs-5-4 mkdir /home/oacs-5-4 chown -R oacs-5-4.www-data /home/oacs-5-4 usermod -g web oacs-5-4 usermod -d /home/oacs-5-4 oacs-5-4
cd /home/oacs-5-4 cvs -d :pserver:anonymous@cvs.openacs.org:/cvsroot co -r oacs-5-4 openacs-4 mv openacs4/* . su - postgres createuser -U postgres -s oacs-5-4 exit su - oacs-5-4 createdb -E UNICODE -U oacs-5-4 oacs-5-4
4. Set PostgreSQL backward compatibility flags (in postgresql.conf)
5. Whatever remains to be done (aolserver instance, edit config.tcl, ...)
Findings/ Issues related to dependency ensemble
Resurrecting tDOM Debian Package
Access to Debian source package (via svn/svn-buildpackage)
- SVN Browser at Debian Tcl/Tk Repository
- Steps to get your local working copy and build it using svn-buildpackage:
# 1. svn checkout to <current_dir>/tdom svn co svn://svn.debian.org/svn/pkg-tcltk/tdom/ # 2. create a dir for the original tarballs mkdir tarballs (<current_dir>/tarballs) cd tarballs # grab the orig tarball from the link:
wget openacs.org/xowiki/file/tdom_0%2e8%2e3%2eorig%2etar%2egz?m=download
mv tdom_0.8.3.orig.tar.gz?m=download tdom_0.8.3.orig.tar.gz
# 3. make sure you have svn-buildpackage and pbuilder installed and set-up # 4. build binaries from source package on trunk cd ../tdom/trunk
# When building the package, you have to use --svn-ignore when you have local changes that haven't been committed; otherwise you will get an error.
svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore
# voilà
# When you're ready to see lintian warning/errors, add --svn-lintian to the build package command:
svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore --svn-lintian
# For linda warnings/erros, add --svn-linda to the build package command
svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore --svn-linda
- References on svn-buildpackage
http://workaround.org/moin/SvnBuildpackage
http://debianpaket.de/svn-buildpackage
- Auxiliary stuff
The orig file
Issues of legacy source package
- [Fixed] [carl] lintian warnings: "tdom: changelog should mention nmu"
Problem:
W: tdom source: changelog-should-mention-nmu
W: tdom source: source-nmu-has-incorrect-version-number 0.8.3-1
Fix:
The maintainer should be Avni Khatri and Carl Blesius <tdom@blesius.org>. Modify debian/changelog to reflect this. This has been fixed temporarily, but since a few us of will be committing, we will have to review the uploader/maintainer names later.
- [Fixed] [avni] lintian warnings: "tdom: bad distribution in changes file"
Problem:
E: tdom_0.8.3-1_source.changes: bad-distribution-in-changes-file UNRELEASED
Fix:
modify debian/changelog: change UNRELEASED to unstable on line 1
- [Fixed (local issue)][avni] lintian warnings: "tdom: directory pwd/../build-area does not exist"
Problem:
W: Build-result Directory pwd/../build-area does not exist
Fix: To avoid using the --buildresult flag, you might put the following
line into your ~/.pbuilderrc:
BUILDRESULT=.../build-area
(make sure you replace the "..." by your directory walk to the actual
build-area dir)
- [Fixed by geoxito] [avni] lintian warnings: "tdom: package-contains-empty-directory *"
Problem:
W: tdom: package-contains-empty-directory usr/bin/
W: tdom: package-contains-empty-directory usr/sbin/
Fix:
the answer/ solution is simple. you have, simplisticly speaking, two ways of creating the "virtual" directory structures. By virtual, I refer to the the paths created under debian/tdom which then go into the binary (*.deb) packages. Either do it manually in the debian/rules file or use template files under debian. look at debian/dirs ... it contains two entries: usr/bin, usr/sbin ... voilà ... these are default settings, created the first time the original author debianized the package. but tdom is a so-called "internal library" package in debian jargon, there will never be anything in bin or sbin. so, simply remove the file or empty it!!!!
- [Fixed]
Which version to package: 0.8.2 / 0.8.3? it is going to be CVS Head/ 0.8.3
- [Fixed] [geoxito] Installation paths not compliant with Debian Tcl/Tk policy
Study http://pkg-tcltk.alioth.debian.org/tcltk-policy.html/
and make sure that you change debian/rules etc. accordingly.
Most importantly, tcl package reside under /usr/lib/tcltk and not /usr/lib/ directly.
- [Fixed] [mr_calvin] Dedicated tdom-dev binary package. There needs to be a dedicated development binary package.
Fix:
- Add tdom-dev entry in debian/control
- debian/rules needs to copy following files into tdom-dev paths:
/usr/include/tdom.h
/usr/lib/tdomConfig.sh
/usr/lib/tdom0.8.2/libtdomstub0.8.2.a
- Btw. change the include path to /usr/include/tdom/*
and subsequently change the path settings in tdomConfig.sh through search/replace operations in debian/rules
(see my xotcl examples in http://svn.debian.org/viewsvn/pkg-tcltk/xotcl/trunk/debian/rules?rev=544&view=markup). watch out for perl commands in there ...
- [Fixed] [avni] Further lintian clean-up:
Problem:
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/dom.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/domDoc.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/domNode.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/expat.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/expatapi.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/tdomcmd.3.gz invalid option -wmac
> W: tdom: manpage-has-errors-from-man usr/share/man/man3/tnc.3.gz invalid option -wmac
Fix: seems to be fixed now.
- [Fixed] [mr_calvin] Expat integration: Using internal (expat 2.0.1 or 1.95) or external (1.95) libexpat (as provided by Debian); comment by Debian Tcl/Tk maintainers:
"As far as I understand, the current version uses internal expat. I
think it's unacceptable. We should use libexpat from Debian. An
example of patches which allow to use system-wide expat could be found
at svn://bamboo.nes.ru/debian/tcl/tdom/trunk"
- [Fixed] [geoxito] Create tdom-doc package if possible. Fix: Not really needed, because there is no other tdom documentation apart the manpages.
Installing packages
These are instructions for installing the alpha dotlrn and openacs packages on debian (and ubuntu).
- Build and install tdom packages (see above, on "Resurrecting tdom").
- Set up a postgresql 8.2 server, and allow access for postgresql administrator user and openacs/dotlrn user from the machine where you are installing dotlrn/openacs (no need to create the dotlrn/openacs user and database).
- Modify your /etc/apt/sources.list file:
# debian sid deb http://debian.adenu.ia.uned.es/apt sid main # Ubuntu Hardy deb http://debian.adenu.ia.uned.es/apt hardy main
- Update the package list and install:
# apt-get update - dotLRN # apt-get install dotlrn
- OpenACS # apt-get install openacs
After that, just follow the instructions on the install ant have fun!
Created by Gustaf Neumann, last modified by Gustaf Neumann 25 Sep 2019, at 11:53 AM
NaviServer is a fork of AOLserver. While the goal of the AOLserver community is stability (no code changes unless necessary), NaviServer is targeted toward further development and extensions (implementing new features required by state of the art web server environments, see NEWS).
Availability
Using NaviServer with OpenACS
Created by Gustaf Neumann, last modified by Gustaf Neumann 25 Sep 2019, at 11:40 AM
Libthread is the standard Tcl thread library developed by Zoran Vasiljevic and provides optional functionality for OpenACS. Threads created by the Tcl thread library are executed in an event loop, which makes it easy to send commands to such threads. xotcl-core provides support for the the thread library and uses it for example for background delivery of large files. Also the chat package uses libthread when it is installed. The xotcl-request-monitor depends on libthread.
The advantage of libthead over NaviServer/AOLserver threads is that the threads created by libthread are waiting in an event loop for incoming requests, which eases some types of applications.
INSTALLATION:
In case, NaviServer was installed via install-ns, one can skip the section installation steps. Also the provided configuration script is already set up correctly for usage. The instruction below is for cases, where install-ns was not used.
1. Get and install libthread:
download libthread e.g. from
https://downloads.sourceforge.net/sourceforge/tcl/thread2.8.2.tar.gz
untar it and go to you platform specific directory (eg. thread2.8.2/unix)
# cd unix
# ../configure --enable-threads \
--prefix=/usr/local/ns \
--exec-prefix=/usr/local/ns \
--with-naviserver=/usr/local/ns
use --prefix --exec-prefix --with-naviserver with the path pointing to the directory, where NaviServer is installed.
The setup for AOLserver is similar, but different paths are used.
make
make install
You should now have installed libthread2.8.2.so (check for /usr/local/ns/lib/thread*/libthread* )
2) Adjusting the AOLserver/NaviServer configuration file to use libthread
Open the configuration file
restart nsd and check the error log, whether libthread was loaded successfully.
Created by OpenACS community, last modified by Gustaf Neumann 25 Sep 2019, at 11:16 AM
the free, open-source, multi-threaded, scalable, Tcl-enabled, web/application server used by some of the world's busiest websites, such as AOL.com, Mapquest.com, Netscape.com, and Moviefone.com. Other sites that run on AOLserver: http://panoptic.com/wiki/aolserver/Sites_That_Run_On_AOLserver
What others say about AOLserver
Using AOLserver with OpenACS
Notes on upgrading AOLserver 4.5.1 ( or greater )
- All the ns_cache* API is from AOLserver 4.5.1 on, part of the core, therefore loading nscache.so in your config file is not longer required. Doing otherwise could lead to syntax errors while doing some calls to the API.
Created by OpenACS community, last modified by Gustaf Neumann 17 Sep 2019, at 10:05 AM
Prerequisites to installing OpenACS
You will need a computer with at least these minimum specifications:
- 256MB RAM (much more if you will be running Oracle)
- 1GB free space on the computer's hard disk (much more if you will be running Oracle)
- a compatible, Unix-like operating system en:os-nix installed.
All of the software mentioned is open-source and available without direct costs, except for Oracle. You can obtain a free copy of Oracle for development purposes (see: en:oracle-install).
All of the required software is installed on various version of recent Linux versions, when you are using naviserver-openacs. The sections below are if we want to go your own way and for legacy issues.
Each version of OpenACS only works with certain versions of the component software. Determine which versions you will be using by reviewing the en:openacs-compatibility-matrix.
These components in-turn depend on other software and parts of the OS. Here is a list of minimum required versions. For production systems, use the latest stable release:
- GNU/Linux. The installation assumes a Linux kernel of 2.2.22 or newer, or 2.4.14 or newer.
- glibc 2.2 or newer. You need recent versions of these libraries for Oracle to build and work properly. For Unicode support, you need glibc 2.2 or newer. glibc should be included in your operating system distribution.
- GNU Make 3.76.1 or newer and gcc. PostgreSQL and AOLserver require gmake/gcc to compile.
OpenACS has a variety of packages that may require other software to be installed. Review the individual package documentation for other requirements. Also, OpenACS is commonly deployed with other related applications. For your convenience, here is a short list of some of these:
- tclwebtest - a tool for testing web interfaces via tcl scripts.
- ns_pam - provides PAM capabilities for AOLserver. You need this if you want OpenACS users to authenticate through a PAM module (such as RADIUS).
- pam_radius - provides RADIUS capabilities for PAM. You need this if you want to use RADIUS authentication via PAM in OpenACS.
- ns_ldap - provides LDAP capabilities for AOLserver. You need this if you want to use LDAP authentication in OpenACS.
- OpenFTS - Adds full-text-search to PostgreSQL and includes a driver for AOLserver. You need this if you want users to be able to search for any text on your site. For PostgreSQL 7.4.x and higher, full text search is also available via tsearch2.
- Analog - examines web server request logs, looks up DNS values, and produces a report. You need this if you want to see how much traffic your site is getting.
- Balance - "a simple but powerful generic tcp proxy with round robin load balancing and fail-over mechanisms." You need this or something equivalent if you are running a high-availability production site and do not have an external load balancing system.
- Daemontools -You need this if you want AOLserver and qmail to run "supervised," meaning that they are monitored and automatically restarted if they fail. An alternative would be to run the services from inittab.
- en:mta
- qmail - You need this (or a different Mail Transport Agent) if you want your web server to send and receive email.
- ucspi-tcp - listens for incoming TCP connections and hands them to a program. We use it instead of inetd, which is insecure. You need this if you are running qmail.
- DocBook (docbook-xml, docbook-xsl, libxslt, xsltproc) - for writing or editing docbook style documentation.
- en:source-control
- search uses these utilities to index file contents: http://wagner.pp.ru/~vitus/software/catdoc/ and http://poppler.freedesktop.org/ based on xpdf.
next: en:openacs-system-install
Created by Markus Moser, last modified by Markus Moser 29 Jul 2019, at 06:28 PM
Prerequisites
A package for OpenACS exists in the Arch User Repository: https://aur.archlinux.org/packages/openacs/
Several AUR helper applications exist for automating compiling and installing AUR packages. In case you are not familiar with installing AUR packages, read the documentation on the Arch Linux Wiki: https://wiki.archlinux.org/index.php/AUR_helpers
Installation
Let's start with installing postgres. Postgres is automatically pulled in as a dependency of openacs, but you should verify before installing openacs that everything is working. In case anything goes wrong with your postgres installation, OpenACS will run into errors when trying to setup the database after installation.
➤ sudo pacman -S postgresql
Let's start the service and check if it runs correctly.
➤ sudo systemctl start postgresql
➤ sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (running) since ....
A fresh installation of postgres might require to run initdb first:
➤ sudo -u postgres -i
[postgres]➤ initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'
Now let's install OpenACS.
Needless to say, you can replace yaourt (which is deprecated) in the following command with your preferred AUR helper application.
➤ yaourt -S openacs
In case you are wondering, this will also take care of dependencies.
After the installation we can start it conveniently with systemd:
➤ sudo systemctl start openacs
➤ sudo systemctl status openacs
Before you start the OpenACS (5.9.1 release) bootstrap installer for the first time on a system running Postgres 11, make sure the following change from the cvs is applied: http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/acs-kernel/sql/postgresql/postgresql.sql?r1=1.51&r2=1.52
Have fun with OpenACS!
Created by Gustaf Neumann, last modified by Gustaf Neumann 27 Jul 2019, at 02:38 PM
Created by OpenACS community, last modified by Gustaf Neumann 16 Jul 2019, at 10:13 AM
The OpenACS project was born when Don Baccus, Ben Adida, and others decided to port ACS from Oracle to PostgreSQL, thus making it a fully open-source solution. With OpenACS 4, Oracle and PostgreSQL support were combined in one code base and with OpenACS 5, support for internationalization and localization has been added.
A vibrant and productive community has sprung up around the OpenACS software and there are many volunteer contributors as well as a commercial companies able to provide support, hosting, and custom development. Many of the production users are actively funding and contributing work back to the project. Formal, consensus driven governance has been established (with semi-annual elections) which ensures the project serves the needs of it's constituents.
More detailed analysis:
- Michael Aram, Stefan Koch, Gustaf Neumann: Long-Term Analysis of the Development of the Open ACS Community Framework, in: Francisco José García-Peñalvo, Alicia García-Holgado (ed) , Open Source Solutions for Knowledge Management and Technological Ecosystems, IGI GLobal, 2017.
- Neophytos Demetriou, Stefan Koch, Gustaf Neumann: The Development of the OpenACS Community, in: Miltiadis Lytra and Ambjörn Naeve (ed) , Open Source for Knowledge and Learning Management: Strategies Beyond Tools, Idea Group Publishing, 2006 . [BibTex, pdf]
Original version by Ben Adida
In the Beginning ...
Back in the summer of 1995, Philip Greenspun, Brian Tivol and I spent a few weeks in New York working at Hearst Publishing developing the Multimedia Newsstand. The tools available at the time were pretty pathetic. Netscape was at version 1.1 (barely), and about 30% of our visitors were still using v0.9.
Philip had done his homework, though, and had chosen NaviServer as our web server platform. NaviServer was the brainchild of Jim and Doug, two amazing hackers who immediately understood how to build server-side web technology:
- Built-in, simple, string-oriented, scripting language: Tcl,
- Efficient multi-threading,
- Simple and abstracted database access and connection pooling.
We set out to create a web site with daily editorials, magazine sales and ordering, customer tracking, and quite a few more pieces. In about 12 weeks, it was up and running and happy. The Illustra RDBMS would crap out every now and then thanks to the Elan License Manager (among other problems), but overall Hearst was happy. The numerous utility procedures that we created and used that summer came together into what is now the utilities.tcl file in your ACS installation. The information so far should allow you to guess the reason why bt_mergepiece is called bt_mergepiece.
Driving the Idea
It was Philip who then started to use NaviServer (later GNNserver, now AOLserver, all the same product) and Illustra to create a host of services that became greenspun.com, in addition to the early versions of photo.net. Philip created the initial versions of bboard, classified, neighbor-to-neighbor, and many other pieces all in order to manage the growing photo.net community.
Philip continued to push AOLserver, eventually dropping Illustra by hiring Cotton Seed, another hard-core hacker, to write an Oracle driver. Oracle brought a whole new level of scalability and reliability to the thousands of lines of Tcl code already written. At that time, in early 1998, Philip officially created ArsDigita, LLC, in order to push the consulting work he was already doing. He brought on 6 people (Philip, Olin, Cotton, Terence, Ulla, and myself) to carry the initial ArsDigita flag (although I had almost nothing to do with the setup of ArsDigita to begin with).
Philip brought on Jin Choi, one of the only people I know who deserves the title of "monster hacker." Together they went ahead and built entirely new services based on AOLserver/Oracle. The most famous of these was, of course, scorecard.org, an amazing site that anyone claiming to understand web scalability should take a look at (30 db-backed hits/second on Earth day running on one Sun Ultra 2).
And There Was A Toolkit...
It was right around that time that Philip convinced me to come back and work full-time for ArsDigita. Jin, Eve, Tracy, Philip and I worked through the summer of 1998 on various projects (Levi Strauss, Cognet, ASME, Greentravel now away.com), while Philip kept talking about his grand-integration goal: combining all of these pieces into the ArsDigita Community System.
Soon enough, the ACS was real. The first release was posted on December 8th, 1998, after a huge packaging, debugging, and integration effort led by Philip. The ACS became the backbone of all ArsDigita projects, and many hackers around the world started using it.
With the rise of open-source software and the realization that good software can still be free, many people started wondering if the ACS could be made to run on some RDBMS other than Oracle. An Interbase port of the ACS v2.1 was created, but Interbase still cost money at the time (although it should be open-source and free by end of 2000). Many cheered for MySQL, but the lack of transaction and subselects makes it unacceptable for a true ACS (or for any critical system, for that matter).
PostgreSQL
In December 1999, a small group of ACS hackers came together on SourceForge to create the ACS port to PostgreSQL. Following true open-source methods, we gave write permissions to anyone who showed enough competence to help out. The group soon grew to more than 20 people, with about 5 active developers.
The initial name of the project, ACS/pg, was changed to OpenACS as the group realized that there was a need to push porting to possibly other databases than PostgreSQL (Interbase?). OpenACS further represents the importance of a fully open-sourced system that truly works in symbiosis with the Open-Source community.
Philip and his team have done a tremendous job creating the processes and data model necessary to build scalable, reliable online communities. OpenACS hopes to bring this tremendous contribution to the world of fully open-sourced systems, available to anyone interested in building their own online community.
See: https://openacs.org/about/history
Other Accounts that could be incorporated
Created by Gustaf Neumann, last modified by Gustaf Neumann 25 Apr 2019, at 09:54 AM
Package Specification Summary for Package: richtext-ckeditor4
| Summary: |
Richtext editor plugin for integrating CKeditor 4 with acs-templating |
| Description: |
|
| Maturity: |
Mature |
| This package depends on: |
acs-templating acs-tcl attachments |
| Packages that depend on richtext-ckeditor4: |
xowiki |
| Package parameters: |
- SCAYT
- Fully featured "Spell Check As You Type" based on WebSpellChecker.net. Please note that the spellchecked words are transferred to that site, so you might be cautious to activate this feature for confidential content. (default false, type string, scope instance)
|
Bug Tracker Summary for Package: richtext-ckeditor4
There is no package with the name "richtext-ckeditor4" known to bug-tracker.
Code Metrics Summary for Package: richtext-ckeditor4
| # Tcl Procs |
9 |
| # Tcl Lines |
667 |
| # Tcl Blank Lines |
91 |
| # Tcl Comment Lines |
135 |
| # Automated Tests |
0 |
| # Stored Procedures |
PG: 0 ORA: 0 |
| # SQL Lines |
PG: 0 (blank 1 comments 0)
ORA: 0 (blank 1 comments 0) |
| # ADP pages |
1 |
| # ADP lines |
11 |
| # Include pages (richtext-ckeditor4/lib/) |
1 |
| # Documentation pages |
0
|
| # Documentation lines |
0 |
| Browse Source |
API-browser |
| Github Repository: |
https://github.com/openacs/richtext-ckeditor4/tree/oacs-5-10
|
In general, the CKEditor can be used via CDN (zero configuration, default) or via local files. One can use /acs-admin/ (section "Site-wide Service Administration" to download a version to your local site to reduce latency or to use local modifications. By default, the "standard" preset is downloaded. By altering the variable "ck_package" in packages/richtext-ckeditor4/tcl/richtext-procs, one can download other presets as well (see https://ckeditor.com/presets-all).
The CKEditor widget can be used at least in two scenarios: (a) as a richtext-widget or (b) within xowiki as a class of a form-field.
- (a) Here is an example for the use of the richtext widget configured for ckeditor4, showing some options:
text:richtext(richtext),nospell,optional
{label "CKEditor"}
{html {rows 15 cols 50}}
{options {
editor ckeditor4
plugins wsc
extraAllowedContent "u;span{color}"}
}
This minimal example should work with the "standard" distribution of CKEditor and adds the "wsc" (Web Spell Checker) plugin, and allows the tag <u>u and <span style="color:...">...</span> to be used in the content. Otherwise, these flags are removed by the context filter of the editor (for details, see CKEditor documentation). Additional "options" are "skin" and "customConfig", where the latter refers to a JavaScript file which can be used for detailed configuration (for more details, see https://docs.ckeditor.com/#!/guide/dev_configuration).
Note, that the usual constraints for richtext widgets holds like for all other richtext implementations (e.g. the editor will only be activated, if UseHtmlAreaForRichtextP is set to true).
- (b) when used as a form-field within xowiki forms, there are detailed config options available: mode, displayMode, skin, toolbar, CSSclass, uiColor, allowedContent, customConfig, extraPlugins, extraAllowedContent, templatesFiles, templates, contentsCss, imageSelectorDialog, and additionalConfigOptions. A short introduction to form-fields is in http://alice.wu-wien.ac.at:8000/xowiki-doc/#forms. One should set the PreferredRichtextEditor (xowiki global parameter) to ckeditor4.
