Created by Maurizio Martignano, last modified by Maurizio Martignano 13 Sep 2017, at 02:35 PM
Windows-OpenACS (vers. 4.0.5 - September 2017) is a Windows 64 port of OpenACS 5.9.1 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 Gustaf Neumann 08 Aug 2017, at 12:18 AM
Upgrades from earlier version than OpenACS 5.8 should read upgrade-oacs-5-8.
OpenACS 5.9 requires PostgreSQL 9.0 or newer and XOTcl 2.0 or newer (part of the nsf package). XOTcl 2.0 can be installed e.g. via install-ns, or from debian sid https://packages.debian.org/sid/ , or from sources https://next-scripting.org/ . In order to check the versions of these packages already installed in your OpenACS installation, check the output of /xotcl/version-numbers in your installation.
Before upgrading to OpenACS 5.9, upgrade all packages in your current installation to recent versions in your OpenACS 5.8 installation (i.e. in the oacs-5-8 channel, especially if you are using edit-this-page, which has bugs in its data model that can complicate the oacs-5-9 installation).
In general it is always recommended to backup your current installation before overwriting it. Make e.g. a tar archive of all files of the OpenACS tree and a database dump.
After upgrading the packages in the oacs-5-8 channel, the following steps are recommended:
- Restart the server with OpenACS 5.8
- Install newest version of the source files (e.g. from the OpenACS 5.9 tar distributions, or install/upgrade from the oacs-5-9 branch from cvs),
- Upgrade the acs-core packages via package manager, restart server
- Upgrade/install application packages via package manager as needed (from file-system or from repository)
To upgrade from OpenACS 5.9.0 to OpenACS 5.9.1 it is recommended to upgrade via tar ball or via CVS. Upgrade from repository works for NaviServer, but leads to an error after the install steps with AOLserver (the installation is ok, after a restart, everything is ok).
Created by OpenACS community, last modified by Benjamin Brink 22 Jul 2017, at 11:49 PM
OpenACS for everyone
OpenACS (Open Architecture Community System) is:
- an advanced toolkit for building scalable, community-oriented web applications.
- a robust, scalable framework (see: en:openacs-system) for building dynamic content driven sites and enterprise-level web applications.
- a collection of pre-built applications and services that you can build on to create a custom web-site or application.
- derived from the ArsDigita Community System (ACS). ArsDigita (now part of Red Hat, Inc.) kindly made their work available under the GPL, making all of this possible.
Through a modular architecture, OpenACS has packages for user/groups management, content management, e-commerce, news, FAQs, calendar, forums, bug tracking, wiki (XoWiki ), full-text searching etc. See OpenACS repository.
Use the OpenACS fourms to contact the OpenACS community. We welcome your feedback and can help with your OpenACS endeavors. Commercial support is also available.
What others say about OpenACS
Others' descriptions of OpenACS
Testimonials posted to forums on OpenACS
History of OpenACS
See: History of OpenACS en:docs-history
Bibliography and Credits
See: Documentation Credits en:doc-credits
Created by OpenACS community, last modified by Benjamin Brink 07 Jul 2017, at 07:15 AM
Getting admin-level help
Setup database environment variables. See end of http://openacs.org/doc/openacs.html ,
http://openacs.org/doc/backup-recovery.html , and http://openacs.org/doc/snapshot-backup.html
For creating custom pages, see developer tutorials http://openacs.org/doc/tutorial.html
Administrating a system
These OpenACS packages are useful for diagnostics and development:
Bibliography and Credits
Created by OpenACS community, last modified by Benjamin Brink 07 Jul 2017, at 07:11 AM
Site and System Administrators - Documentation Requirements
By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.
OpenACS administrators' documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.
For each requirement below, include links to developer tutorials and other documentation for more detail.
Describe a structural overview of a working system and how the components work together. "The Layered Cake view" a general network view of system; a table showing system levels versus roles to help with understanding how the subsystems are interconnected.
Provide a comprehensive description of typical administrative processes for operating an OpenACS system responsibly, including reading logs and command line views that describe status of various active processes.
Create a list of administrative tools that are useful to administrating OpenACS, including developer support, schema-browser and api browser. Link to AOLserver's config file documentation.
Resources on high level subjects such as web services, security guidelines
Describe typical skill sets (and perhaps mapped to standardized job titles) for administrating an OpenACS system (human-resources style). For a subsite admin/moderator attributes might include trustworthy, sociable, familiarity with the applications and subsystems, work/group communication skills et cetera
Describe how to set up typical site moderation and administration including parameters, permissions, "Hello World" page
Show directory structure of a typical package, explanation of the various file types in a package (tcl,adp,xql) and how those relate to the previously described subsystems, when they get refreshed etc.
Ways to build a "Hello World" page
Show examples of how the OpenACS templating system is used, including portal sections of pages. For example, create a customised auto-refreshing startpage using lars-blogger, a photo gallery, and latest posts from a forum. This should rely heavily on documentation existing elsewhere to keep current. This would essentially be a heavily annotated list of links.
Show ways of modifying the look and feel across pages of an OpenACS website. Refer to the skins package tutorial.
Describe a methodology for diagnosing problems, finding error statements and interpreting them --for OpenACS and the underlying processes.
FAQs: Administration tasks commonly discussed on boards: admin page flow, how to change the looks of a subsite with a new master.adp, options on "user pages" , a quick introduction to the functions and processes. info about the user variables, file locations
Pull in docs from: http://openacs.org/doc/acs-admin.html
Created by OpenACS community, last modified by Benjamin Brink 07 Jul 2017, at 07:06 AM
Keeping track of the commands you run and recording their output has important diagnostic value. I like to create a literal history of my installations in a shell inside of emacs (M-x shell) so that I can save the output if needed. An alternative would be to use the script command.
Check the error logs. We point out the location of error logs for the various pieces of software. Output from those logs will help you, and help us help you. Do not worry if you feel overwhelmed by all the information in the error logs. Over time, you will find that they make more and more sense. At some point, you may actually look forward to errors so that you can run to the log and diagnose the problem.
If something goes wrong, do not panic. There are plenty of ways to get help. Here are some:
Search the forums at openacs.org - Frequently, people who have struggled through the same issue have already posted and received help with answers immediately available to you.
The bottom of each page has a link to OpenACS.org, where you can post comments and read other users comments about the contents of the page.
Post a question on the forums. Make sure you've done a search first. When you do post, be sure to include your setup information (OS, etc) as well as the exact commands that are failing with the accompanying error. If there is a SQL error in the TCL error or in the log, post that too.
Ask questions at the irc channel on freenode.net (#openacs). They're knowledgeable and quite friendly if you can keep them on topic.
If you find errors in this document or if you have ideas about making it better, please post them in the forum or BugTracker.
Created by Malte Sussdorff, last modified by Benjamin Brink 30 Jun 2017, at 06:51 AM
When running an OpenACS site a couple of packages come in handy to monitor your site and see why and where bottlenecks are located. To use them though, you need to install AOLserver with libthread support. If you are lazy as I am, just download the install script from http://cognovis.de/entwickler/tips/aolserver/aolserver45/ and get started. This will make sure that you have all the necessary ingridients installed.
Then go to your systems administration at /acs-admin and install two packages:
The first one gives you an overview over the system performance, while the latter allows you to scan the error.log for errors and have them send to you via e-mail. A little bit more detail:
The monitoring package has a couple of nice things which help you monitor you website. First and foremost you can use it to get the error logs. This is HIGHLY recommended, as your users will not report errors to you. They will just complain internally and not use your site anymore. We learned this the hard way.
Once you have monitoring installed (and mounted at e.g. /monitoring) go there and edit the parameters. There you can define who should get the error reports send and how often they are send out. NOTE: They will be send out with every restart of the server, so this gives you a pretty good idea if your server has restarted.
You can also get the TOP reports (if you have a high load on the system), which is something I usually don't use, but maybe it is of importance for you.
Last but not least (for me at least) you can view which scheduled procs are running on your server and when they are executed next time. This is really helpful to understand what is going on on your site of the things you cannot see.
XoTCL Request Monitor
The request monitor (automatically mounted under /request-monitor) will give you a performance overview of your site, how many users are online, what are the average page load times ....
If you look at the overview page you will first be delighted to see that the average times are so low. This is misleading as the quick fetches to ".css" files and so on are counted into the equation as well.
More accurate is the aggregated stats view, which allows you to see which URLs are called most often on your site and how expensive they are to load. It is a good idea to have the most often called pages be *fast*.
One thing we do as well is to run the "last 100 request" page on a continuous basis in a browser window. It refreshes every 60 seconds and if you get the sorting right you can actually get a good overview of the activity on your site (e.g. we order by execution time, so we always see how long users are waiting for their pages and if this number goes up considerably, well, then we know we have to act!).
Let me say first, anyone running an OpenACS site without daemontools and keepalive should be send to a very unpleasant place. Keepalive is the only thing preventing you from being called in the middle of the night "our site is down". Why ?
Assume your database restarts for whatever the reason. AOLserver will restart immediately (if you have daemontools), but maybe the database takes longer to come up again, so you aolserver is showing "Installation Error, check your database connection" page to your users.
Or your web server has used up too much memory (for whatever the reasons) and connections are rare (e.g. if someone is trying an attack on your site). Then keepalive will see that the server is down and issue an automatic restart. And notify you about this via e-mail. If you are smart you could actually set it up in a way that, if keepalive has to restart three times within e.g. 15 minutes, then you are send an SMS and the infernal ringtone wakes you up.
Where to configure keepalive? /web/yoursite/etc/keepalive.
Created by Byron Linares, last modified by Benjamin Brink 29 Jun 2017, at 11:57 AM
OpenACS/dotLRN windows installer how to
The installer source consists in a main Inno Setup script “installer.iss” and could be found in cvs or obtained with the installer.
There are some necessary file numbers in order to build the installer.
- tcl\bintallerw.tcl: the AOLserver configuration script
- Install.xml: this XML file control the packages installed by the OpenAcs installer
- tcl\Windows-procs.tcl: This file includes various hacks to make OpenACS work on Windows.Replaces the TCL exec command on Windows, allowing exec to be called with unix-y arguments.Index.tcl : file used for automatic installation.
- Index-org.tcl: file used for manual installation.
- Installer.tcl: file used in automatic installation.
- Installer-org.tcl: file used in manual installation.
- Stara.bat, stop.bat: batch files for starting and stopping all services.
- Tools/setx.exe, tools/reg.exe ,/tools/uzip.exe, /tools/reg.exe Windows command line tools necessary for the installation process.
- AOLserver_4-0-beta-10_2003-08-04.zip: AOLServer
- cygwin.zip: CygWin Unix environment for Windows. Cygwin.zip also contains the PostgreSQL database
- cygwin.bat: file to launch cygwin unix environment consol.
- license_en.txt: license text file.
- important.txt: extra info text file.
- Note.txt : especial notes text file.
Building the installer:
- In order to build this installer we need to place all the resources in a folder.
- Create tools and tcl folders with the files before mentioned.
- Download OpenACS, dotLRN and all desired package and place in a folder and named “oacs-dotlrn”
- Open the file installer.iss and generate the installer.
The installer.iss has to important parts:
In this section are listed all the sources for the installer, in this part you
Can change or add any source that you want.
In this section is where all commands are executed, like the cygwin installation, postgreSQL installation and AOLserver.
Section for define procedures or functions to work around the installation.
These are the main sections in the “installer.iss” script. And the sections that have to be changed form personalize the installer.
developed at the Galileo University (www.galileo.edu) by Byron Haroldo Linares Roman email@example.com as part of the E-LANE project (www.e-lane.org)
Instructions on using the installer are at: