View · Index

Weblog Page

Filtered by category Subsystems Documentation, 51 - 60 of 86 Postings (all, summary)

for developers

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:44 PM

OpenACS for developers

Features

Besides the quality components of Openacs (See: en:openacs-system), OpenACS has these enterprise-quality features for developers:

will be pulling in docs from here: https://openacs.org/doc/acs-package-dev.html and https://openacs.org/doc/acs-plat-dev.html

Integrated Development Environments (IDE)

These text editors are commonly used when coding on OpenACS:

Bibliography and Credits

See en:doc-credits.

References to this Page: en:F._A._Q., en:Introduction, en:home, en:Documentation_Project_Discussion, en:Documentation_Project_Plan, en:docs-eng-toc, en:websites-db Categories: HOME (OpenACS.org), Documentation (OpenACS.org), Subsystems Documentation (OpenACS.org)

Source control

Created by OpenACS community, last modified by Gustaf Neumann 20 Apr 2017, at 06:22 PM

 
A Source Control system keeps track of all of the old versions of your files. It lets you recover old files, compare versions of file, and identify specific versions and groupings of files such as for controlled deployment.

the OpenACS reference platform and the OpenACS.org repository (where you can get patched and development code in between releases) use cvs.

This is a place to add notes about other source controls and services used by the community..

 

Guidelines

First READ the official cvs rules https://openacs.org/forums/message-view?message_id=185506

These rules apply whichever source control tool OpenACS is using at the time. As of this writing, we are still using CVS.

 

  1. Don't mix bug fixes and new work
  2. Don't commit code before it is tested in a clean environment (new working copy)
  3. If possible, have someone else test your fix
  4. Branch when necessary, don't be afraid of it (but ask OCT first)

1. Don't mix bug fixes and

  • Be liberal with working copies. If you need to merge custom code into OpenACS, checkout a new working copy. Don't be stingy. Disk space is cheap. This prevents many problems by reducing accidental commits.
    • bottom line: don't mix bug fixes and new work! If you have a checkout of OpenACS you are developing some new package or feature for an existing package, and you run into a bug, fix the bug in a clean checkout of OpenACS. This is the only sane way to make sure you 1) actually fix the bug and 2) don't commit other changes that don't pertain to the bug fix.

2. Don't commit code before it is tested in clean environment

  • Review your changes before committing. If possible ask someone else to look. Do a cvs -qn update to see if the commit is not changing any files you did not expect. Use cvs diff to compare your changes to the respository.
  • So for committing code back to OpenACS from your local repository you should have 2 copies
    • 1) your local code
    • 2) a working copy of OpenACS HEAD
  • You should make all changes in the working copy and fully test it, running automated tests and checking to make sure you did not accidentally change something or add in client specific  code that is not reusable by OpenACS.

3. If possible, have someone else test your fix

  • this should be self-evident, a second pair of eyes always helps to find something you missed.
  • if another person is not possible, write an automated test, in fact, write one anyway! 

4. Branch when necessary, don't be afraid of it (but ask OCT first)

  • Large projects should be done on a branch. This is a pain with CVS, but it is the only sensible way to do this. Examples include any project that will span a major release cycle. It is the responsibility of the person doing the branch to keep up to date with HEAD and to merge and have the code tested. It is sensible to test in a working copy BEFORE committing the code.

Ideas

Here is my heretical idea. I think we must have another branch. Here is how it would work.

1) developer has a working copy.

2) develop commits code to HEAD

3) code is merged to testing branch

4) code is tested

5) code is moved to release branch

Yes, this is extra work. I believe it is worth it. It is a serious pain with CVS. We started using svnmerge.py for Subversion on our private repository and I saw immediate improvements in process. In this case I think having a well defined process AND tools that facilitate the process are key. OpenACS lacks a well defined process, discipline, and tools to facilitate the process. I believe we need to work harder to define this process and I would like to collaborate with the community on this.


 

References to this Page: en:docs-install Categories: Subsystems Documentation (OpenACS.org)

OpenACS subsystem

Created by OpenACS community, last modified by Gustaf Neumann 14 Apr 2017, at 11:55 AM

OpenACS subsystem

..consists of a collection of tcl/adp/xql files that are interpreted by the other main components of OpenACS (en:openacs-system)

References to this Page: en:openacs-system, en:Documentation_Project_Plan, en:docs-end-user-toc, en:docs-eng-toc Categories: Subsystems Documentation (OpenACS.org)

Install AOLserver

Created by OpenACS community, last modified by Gustaf Neumann 14 Apr 2017, at 11:06 AM

Get AOLserver and modules Download AOLserver and modules from CVS. Install Tcl if it is not installed yet.

Comments:

  • one should base the documentation on releases, not on head versions. So, just relying on the head version of github is not recommended for beginners.
  • newer versions of aolserver have ns_cache included (4.5.1 or newer). no need for the extra module listed below.
  • using "aolserver40r10" as name for the install directory is strange, especially, when the release is not 4.0.10
[root root]# mkdir -p /usr/local/src/aolserver40r10/
[root root]# git clone git://github.com/aolserver/aolserver.git /usr/local/src/aolserver40r10/aolserver/
[root root]# git clone git://github.com/aolserver/nssha1.git /usr/local/src/aolserver40r10/nssha1/
[root root]# git clone git://github.com/aolserver/nspostgres.git /usr/local/src/aolserver40r10/nspostgres/
[root root]# git clone git://github.com/aolserver/nsoracle.git /usr/local/src/aolserver40r10/nsoracle/
[root root]# cd /usr/local/src/aolserver40r10
[root root]# cvs -z3 -d:pserver:anonymous@aolserver.cvs.sourceforge.net:/cvsroot/aolserver co nscache

Download en:tdom, tcllib, and XOTcl.

[root aolserver]# cvs -z3 -d:pserver:anonymous@cvs.tdom.org:/usr/local/pubcvs co tdom
[root aolserver]# wget http://heanet.dl.sourceforge.net/sourceforge/tcllib/tcllib-1.10.tar.bz2
[root aolserver]# wget http://media.wu-wien.ac.at/download/xotcl-1.6.7.tar.gz

 

Configure, compile and install AOLserver. Many people need to run more than one version of AOLserver in parallel. This section accommodates future upgrades by installing AOLserver 4 in /usr/local/aolserver40r10.

[root aolserver]# cd /usr/local/src/aolserver40r10/aolserver
[root aolserver]# ./configure --prefix=/usr/local/aolserver40r10 \
				--with-tcl=/usr/local/lib/ \
				--enable-threads
[root aolserver]# make
[root aolserver]# make install

If this is the only version of AOLserver in use, or is the default version, create a symlink. If not, then be sure to use /usr/local/aolserver40r10 instead of /usr/local/aolserver in future steps and check any scripts and makefiles you run to ensure they use the correct path.

[root aolserver]# ln -s /usr/local/aolserver40r10 /usr/local/aolserver

Configure, compile and install the modules.

OpenACS looks for the Oracle driver at /usr/local/aolserver/bin/ora8.so, but some versions of nsoracle may create nsoracle.so instead. In that case, you can symlink (ln -s nsoracle.so ora8.so) to fix it.

  1. Install nscache

    [root aolserver]# cd /usr/local/src/aolserver40r10/nscache
[root nscache]# make install AOLSERVER=/usr/local/aolserver40r10

  2. Install nsoracle (if you want to use Oracle)

    [root nscache]# cd ../nsoracle
[root nsoracle]# make install AOLSERVER=/usr/local/aolserver40r10

  3. Install nspostgres (if you want to use Postgres)

    [root nscache]# cd ../nspostgres
[root nspostgres]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
[root nspostgres]# make install POSTGRES=LSB \
				ACS=1 \
				INST=/usr/local/aolserver40r10 \
				AOLSERVER=/usr/local/aolserver40r10

     You might try POSTGRES=PG_CONFIG if that does not work.

     

    If you get errors like:

    nspostgres.c: In function `Ns_PgTableList':
nspostgres.c:679: warning: passing arg 3 of `Tcl_DStringAppend' as signed due to prototype

    then PostGreSQL is probably not in the standard location.

    [jiml at cvs openacs here.] There are -new- (as of within 2nd quarter 2007) changes to nspostgres, there have been expansions of the ways to locate postgres, and changes to some error reporting. Please read the README and the Makefile. The nspostgres build can now use postgres's pg_config to locate a particular postgres installation. [jiml out]

    The location of PostGreSQL is very dependent on which method was used to install it. To correct the problem, replace LSB with the path to the path to your PostGreSQL installation. Often this is /usr/local/pgsql.

    Another possibility is that you may need to set the LD_LIBRARY_PATH environmental variable. You may still get warnings, but sometimes this will fix things enough to work.

    [root nspostgres]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib

    You can use the ldd command to verify that all libraries are linked in: ldd /usr/local/src/aolserver40r10/nspostgres/nspostgres.so

    If you run into problems with libpq.a do the following (and repeat the step above)

    [root nspostgres]# ranlib /usr/local/pgsql/lib/libpq.a

    If you run into problems with the linker, edit the Makefile. Add -lnsdb to the MODLIBS var.

    MODLIBS = -L$(PGLIB) -lpq -lnsdb

  4. Install nssha1

    [root nspostgres]# cd ../nssha1

    Now install nssha1:

    [root nssha1]# make install NSHOME=/usr/local/aolserver40r10

    If the make fails you will have to edit nssha1.c. Comment out the following 2 lines (lines 139-140):

    // typedef unsigned int u_int32_t;
// typedef unsigned char u_int8_t;

  5. Install tDOM Note, if you use bash31 you need to apply a patch, see https://openacs.org/forums/message-view?message_id=369867 for details.

    [root nssha1]# cd ../tDOM-0.8.0/unix

    Edit the CONFIG file. Uncomment the instructions meant for AOLserver 4, but edit it to look like this:

    ../configure --enable-threads --disable-tdomalloc --prefix=/usr/local/aolserver40r10 --with-tcl=/usr/local/src/aolserver40r10/tcl-8.4.14/unix

    Now you can compile and configure tDOM

    [root unix]# sh CONFIG
[root unix]# make install

  6. Install tcllib

    [root aolserver]# cd /usr/local/src/aolserver40r10
[root aolserver]# tar xvfj tcllib-1.10.tar.bz2
[root aolserver]# cd tcllib-1.10
[root aolserver]# ./configure --prefix=/usr/local/aolserver40r10
[root aolserver]# make install

  7. Install XOTcl

    [root aolserver]# cd /usr/local/src/aolserver40r10
[root aolserver]# tar xvfz xotcl-1.6.7.tar.gz
[root aolserver]# cd xotcl-1.6.7/
[root aolserver]# export CC=gcc
[root aolserver]# ./configure --enable-threads --enable-symbols \
				--prefix=/usr/local/aolserver40r10 \
				--exec-prefix=/usr/local/aolserver40r10 \
				--with-tcl=/usr/local/src/aolserver40r10/tcl8.4.14/unix
[root aolserver]# make
[root aolserver]# make install-aol

 

Add a database-specific wrapper script. This script sets database environment variables before starting AOLserver; this allows the AOLserver instance can communicate with the database. There is one script each for Oracle and PostgreSQL. They don't conflict, so if you plan to use both databases, install both. Note that this section requires you to have the OpenACS, which you can get through CVS, through a tarball, or by other means. You can come back to this section after you acquire the OpenACS code, but don't forget to come back. (Note to maintainers: this should be moved to the next page and integrated into the text there)

  • Oracle

    [root aolserver]# cd /usr/local/aolserver40r10/bin
[root bin]# cp /tmp/openacs-5.2.0d1/packages/acs-core-docs/www/files/nsd-oracle.txt ./nsd-oracle
[root bin]# chmod 750 nsd-oracle
[root bin]#

  • PostgreSQL

    [root aolserver]# cd /usr/local/aolserver40r10/bin
[root bin]# cp /var/tmp/openacs-5.2.0d1/packages/acs-core-docs/www/files/nsd-postgres.txt ./nsd-postgres
[root bin]# chmod 755 nsd-postgres
[root bin]#

You may need to edit these scripts if you are not using /usr/local/aolserver as the directory of Aolserver4.

Test AOLserver. We will use the sample-config.tcl file provided in the AOLserver distribution to test AOLserver. This test will use the nobody user and web group. The sample-config.tcl configuration writes to the default log locations, so we need to give it permission to do so or it will fail. Grant the web group permission to write to /usr/local/aolserver/log and /usr/local/aolserver/servers.

[root root]# cd /usr/local/aolserver
[root aolserver]# chown -R root.web log servers
[root aolserver]# chmod -R g+w log servers
[root aolserver]# ls -l
total 32
drwxr-sr-x    2 root     root         4096 Mar  8 12:57 bin
drwxr-xr-x    3 root     root         4096 Mar  8 10:34 include
drwxr-sr-x    3 root     root         4096 Mar  8 10:34 lib
drwxrwsr-x    2 root     web          4096 Mar  8 10:31 log
drwxr-sr-x    3 root     root         4096 Mar  8 10:31 modules
-rw-r--r--    1 root     root         7320 Mar 31  2001 sample-config.tcl
drwxrwsr-x    3 root     web          4096 Mar  8 10:31 servers
[root aolserver]#

Note: AOLserver4.x does not include a default start page, so we create one for this test. Type echo "Welcome to AOLserver" > /usr/local/aolserver40r10/servers/server1/pages/index.html

Now, run AOLserver using the sample configuration to verify it runs without errors. This configuration attempts to automatically get the machine's IP address and hostname. It will then start up the server at port 8000 of that IP address.

[root aolserver]# ./bin/nsd -t sample-config.tcl -u nobody -g web
[root aolserver]# [08/Mar/2003:15:07:18][31175.8192][-main-] Notice: config.tcl: starting to read config file...
[08/Mar/2003:15:07:18][31175.8192][-main-] Warning: config.tcl: nsssl not loaded -- key/cert files do not exist.
[08/Mar/2003:15:07:18][31175.8192][-main-] Warning: config.tcl: nscp not loaded
-- user/password is not set.
[08/Mar/2003:15:07:18][31175.8192][-main-] Notice: config.tcl: finished reading
config file.

The first warning, about nsssl, can be ignored. We will not be using nsssl; we will be using nsopenssl instead. The nssl error happens because we have not fully configured secure connections to use nsopenssl. The nscp warning means that without a user and password in the sample-config.tcl file, the administrative panel of AOLserver will not load. We do not plan to use it and can ignore that error as well. Any other warning or error is unexpected and probably indicates a problem.

Test to see if AOLserver is working by starting Mozilla or Lynx on the same computer and surfing over to your web page. If you browse from another computer and the sample config file didn't guess your hostname or ip correctly, you will get a false negative test.

[root aolserver]# lynx localhost:8000

You should see a "Welcome to AOLserver" page. If this does not work, try browsing to http://127.0.0.1:8000/. If this still does not work, read the en:aolserver-admin section on "Troubleshooting AOLserver". Note that you will not be able to browse to the web page from another machine, because AOLserver is only listening to the local address.

Shutdown the test server:

[root aolserver]# killall nsd
[root aolserver]#

The killall command will kill all processes with the name nsd, but clearly this is not a good tool to use for managing your services in general. We cover this topic in en:aolserver-admin section.

Set up the file system for one or more OpenACS Sites

This should already have been done, according to the instructions at the bottom of this page: en:Get_the_Code

Set up a user account for each site.

AOLserver needs to be started as the root user if you want to use port 80. Once it starts, though, it will drop the root privileges and run as another user, which you must specify on the command line. This user should have as few privileges as possible, because if an intruder somehow breaks in through AOLserver, you do not want the intruder to have any ability to do damage to the rest of your server.

At the same time, AOLserver needs to have write access to some files on your system in order for OpenACS to function properly. So, we run AOLserver with a different user account for each different service. Create the username as $OPENACS_SERVICE_NAME.

The password should be blank, to prevent login by password, for increased security. The only way to log in will be with ssh certificates. The only people who should log in are developers for that specific instance. Add this user, and put it in the $OPENACS_SERVICE_NAME group so that it can use database and server commands associated with that group. (If you don't know how to do this, type man usermod. You can type groups to find out which groups a user is a part of)

[root root]# useradd $OPENACS_SERVICE_NAME

You also need to set up a group called web.

[root root]# groupadd web

Then change the user to be a part of this group:

[root root]# usermod -g web $OPENACS_SERVICE_NAME

ref: https://openacs.org/doc/aolserver4.html

References to this Page: en:aolserver, en:openacs-system-install-osx, en:tcl-install, en:tdom-programming, en:aolserver45, en:Documentation_Project_Plan, en:docs-admin-toc Categories: Subsystems Documentation (OpenACS.org)

Comments

End-users - Requirements

Created by Torben Brosten, last modified by Michael Aram 25 Nov 2016, at 12:08 PM

Documentation Requirements for End-users

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 end-user documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.

  • End-users should not have to read docs to use the system.

  • Include how to get help. How and where to find answers, contact others, what to do if one gets an AOLserver or other error when using the system. Include types of available support (open-source, private commercial etc.) including references.

  • Explain/foster understanding of the overall structure of the system. This would be an overview of the system components, how it works, and how to find out more or dig deeper... To promote the system by presenting the history of the system, and writing about some tacit knowledge re: OpenACS.org and the opensource culture.

  • Introduce and inspire readers about the uses, benefits, and the possibilities this system brings (think customer solution, customer cost, convenience, value). A comprehensive community communications system; How this system is valuable to users; Reasons others use OpenACS (with quotes in their own words) "...the most important thing that the ACS does is manage users, i.e. provide a way to group, view and manipulate members of the web community. -- Talli Somekh, September 19, 2001" using it to communicate, cooperate, collaborate... OpenACS offers directed content functionality with the OpenACS templating system. ... OpenACS is more than a data collection and presentation tool. OpenACS has management facilities that are absent in other portals. ...The beauty of OpenACS is the simplicity (and scalability) of the platform on which it is built and the library of tried and tested community building tools that are waiting to be added. It seems that most portals just add another layer of complexity to the cake. See Slides on OACS features...a set of slides on OACS features that can be used for beginners who want to know OACS is about and what they can do with it. Screen captures that highlight features. Example shows BBoard, calendar, news, file storage, wimpy point, ticket tracking. An OpenACS tour; an abbreviated, interactive set of demo pages.

  • From a marketing perspective,

    • differentiate "product" by highlighting features, performance quality, conformance to standards, durability (handling of technological obsolescence), reliability, repairability, style of use, design (strategy in design, specifications, integrated, well-matched systems etc).

    • differentiate "service" by highlighting software availability (licensing and completeness from mature to early adopters or development versions), community incident support, project collaborative opportunities, and contractor support availability

    • differentiate price (economic considerations of opensource and features)

    • Discussion and details should rely on meeting criteria of design, completeness of implementation, and related system strengths and weaknesses. Marketing should not rely on comparing to other technologies. Competitive analysis involves mapping out strengths, weaknesses, opportunities and threats when compared to other systems for a specific purpose, and thus is inappropriate (and becomes stale quickly) for general documentation.

    • When identifying subsystems, such as tcl, include links to their marketing material if available.

    • create an example/template comparison table that shows versions of OpenACS and other systems (commonly competing against OpenACS) versus a summary feature list and how well each meets the feature criteria. Each system should be marked with a date to indicate time information was gathered, since information is likely volatile.

     

  • To build awareness about OpenACS, consider product differentiation: form, features, performance quality, conformance quality (to standards and requirements), durability, reliability, repairability, style, design: the deliberate planning of these product attributes.

  • Include jargon definitions, glossary, FAQs, site map/index, including where to find Instructions for using the packages. FAQ should refer like answers to the same place for consistency, brevity and maintainability.

  • Explain/tutorial on how the UI works (links do more than go to places, they are active), Page flow, descriptions of form elements; browser/interface strengths and limitations (cookies, other)

  • Discuss criteria used to decide which features are important, and the quality of the implementation from a users perspective. Each project implementation places a different emphasis on the various criteria, which is why providing a framework to help decide is probably more useful than an actual comparison.

Package documentation requirements have additional requirements.

  • A list of all packages, their names, their purposes, what they can and cannot do (strengths, limitations), what differentiates them from similar packages, minimal description, current version, implementation status, author/maintainers, link(s) to more info. Current version available at the repository.

  • Include dependencies/requirements, known conflicts, and comments from the real world edited into a longer description to quickly learn if a package is appropriate for specific projects.

  • Create a long bulleted list of features. Feature list should go deeper than high-level feature lists and look at the quality of the implementations (from the user's perspective, not the programmer's). Example issues an end-user may have questions about: Ticket Tracker and Ticket Tracker Lite, why would I want one of them vs the other? And, before I specify to download and install it, what credit card gateways are supported by the current e-commerce module? There are some packages where the name is clear enough, but what are the limitations of the standard package?

  • End-user docs should not be duplicative. The package description information and almost everything about a package for administrators and developers is already described in the package itself through two basic development document templates: a Requirements Template and Detailed Design Document.

References to this Page: en:Marketing_Docs_Index, en:Documentation_Project_Plan Categories: Subsystems Documentation (OpenACS.org)

Nagios Monitoring

Created by Malte Sussdorff, last modified by Gustaf Neumann 26 Oct 2016, at 01:13 PM

To monitor your server with Nagios you can use the check_http command.

Use

check_http -h <yourip> -u /SYSTEM/dbtest -s "success"

To obtain the HTTP critical status if OpenACS can't return success, which can be either because the server isn't running or the database connection has failed.

Categories: Subsystems Documentation (OpenACS.org)

Installing OpenACS on debian

Created by OpenACS community, last modified by Gustaf Neumann 21 Oct 2016, at 08:53 AM

This information is deprecated. Please refer to Installing OpenACS on debian.

The quicksheet versions:

You should know what you're doing when you use them.

notes

Tcl development headers are required for compiling Tcl packages yourself.

apt-get install tcl8.4-dev

Should you decide to Install OpenACS from source using general en:openacs-system-install instructions, refer to these notes for changes:

Installing Postgresql

Debian stable user should install PostGreSQL from source as detailed below, or they should use the www.backports.org backport for Postgres to get a more current version. Debian unstable users: the following process has been known to work (but you should double-check that the version of PostGreSQL is 7.3 or above):

For Debian stable users, you can use backports, by adding this line to the /etc/apt/sources.list


 

deb http://www.backports.org/debian stable bison postgresql openssl openssh tcl8.4 courier debconf spamassassin tla diff patch neon chkrootki

and perform this actions:

apt-get update
apt-get install postgresql postgresql-dev postgresql-doc
ln -s /usr/include/postgresql/ /usr/include/pgsql
ln -s /var/lib/postgres /usr/local/pgsql
ln -s /usr/include/pgsql /usr/local/pgsql/include
su postgres -c "/usr/lib/postgresql/bin/createlang plpgsql template1"

..and proceed to the next section.

Installing PostgreSQL's Tsearch2


 

apt-get install postgresql-contrib

Creating the Postgres user.

Use adduser instead of useradd. Type man adduser for more info.

Compiling PostgreSQL

On debian woody (stable, 3.0), do:

./configure --without-readline --without-zlib

Set PostgreSQL to start on boot

[root ~]# cp /var/tmp/packages/acs-core-docs/www/files/postgresql.txt /etc/init.d/postgresql
[root ~]# chown root.root /etc/init.d/postgresql
[root ~]# chmod 755 /etc/init.d/postgresql
[root ~]# 
cp /var/tmp/openacs-5.2.0d1/packages/acs-core-docs/www/files/postgresql.txt /etc/init.d/postgresql
chown root.root /etc/init.d/postgresql
chmod 755 /etc/init.d/postgresql

Test the script

[root ~]# /etc/init.d/postgresql stop
Stopping PostgreSQL: ok
[root ~]#

If PostgreSQL successfully stopped, then use the following command to make sure that the script is run appropriately at boot and shutdown.

[root ~]# update-rc.d postgresql defaults
 Adding system startup for /etc/init.d/postgresql ...
   /etc/rc0.d/K20postgresql -> ../init.d/postgresql
   /etc/rc1.d/K20postgresql -> ../init.d/postgresql
   /etc/rc6.d/K20postgresql -> ../init.d/postgresql
   /etc/rc2.d/S20postgresql -> ../init.d/postgresql
   /etc/rc3.d/S20postgresql -> ../init.d/postgresql
   /etc/rc4.d/S20postgresql -> ../init.d/postgresql
   /etc/rc5.d/S20postgresql -> ../init.d/postgresql
[root ~]# /etc/init.d/postgresql start
Starting PostgreSQL: ok
[root ~]#

Debian defaults to starting all services on runlevels 2-5.

Installing Tcl

You can apt-get install tcl8.4-dev if you have the right version (stable users will need to add tcl8.4 to their sources.list file as described in the "Install Postgresql" section above. You will have to use /usr/lib/tcl8.4/ instead of /usr/local/lib when you try to find the tcl libraries, however.

apt-get install tcl8.4 tcl8.4-dev

 

and proceed to installing aolserver.

When installing aolserver, replace --with-tcl=/usr/local/lib/ with --with-tcl=/usr/lib/tcl8.4.

Installing AOLserver

To install AOLserver you can use apt command:

apt-get install aolserver4 aolserver4-nscache aolserver4-nspostgres aolserver4-nssha1 tdom

After installing AOLserver, You need to make the following symbolic link:

ln -s /usr/lib/aolserver4 /usr/local/aolserver

 

 

References to this Page: en:docs-admin-toc Categories: Subsystems Documentation (OpenACS.org)

Boost your application performance to serve large files!

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 16 Oct 2016, at 12:38 PM

In order to speed up file-deliveries, one can use the background delivery methods provided by xotcl-core. The main advantage is that with background delivery the costly connection threads are just used for permission checking and locating the file, and the time-consuming spooling of the file to the client is implemented in an asynchronous background delivery thread. Therefore, connection thread are not blocked, it is possible to spool simultaneously several hundred (thousand?) files with only a few connection threads configured.

We use this in production since several years. For example today (no semester yet) we had so far 150.000 file deliveries by background delivery.

The asynchrounous background delivery requires a small patch (2 changes, one is a backport from naviserver) and the tcl thread library (by zoran). The application code is in XOTcl is only a few lines of code and is included in xotcl-core (bgdelivery-procs.tcl).

One needs the following patch to

The patch is already included in the current head version of aolserver 4.5 and in NaviServer.

With this patch and xotcl-core, one can replace
   ns_returnfile 200 $mime_type $filename

by
   ad_returnfile_background 200 $mime_type $filename

e.g. in cr_write_content in acs-content-repository/tcl/revision-procs.tcl to activate it and to deliver files from the content-repository (file-store) in the background.

The connection thread is only used for permission management, localization of the file and writing the the reply header, the actual delivery of the file is performed via asynchronous io without using up many resources. This can handle probably a couple of thousand concurrent file deliveries without running out of resources.

Check the files that has been served since the last reboot of your NaviServer/aolserver using this method from the developer support shell:

   bgdelivery do set delivery_count


Original thread:
https://openacs.org/forums/message-view?message_id=482221

 

 

References to this Page: en:openacs-performance-tuning, en:libthread Categories: Subsystems Documentation (OpenACS.org)

Upgrade between PostgreSQL versions

Created by Gustaf Neumann, last modified by Gustaf Neumann 20 Sep 2016, at 02:06 PM

The probably easiest way to upgrade between PostgreSQL versions is as follows (described here from 9.4 to 9.5, based on the directory structure as provided by Mac Ports)

DATE=`date +"%Y-%m-%d"`
# Dump all databases from pg 9.4
PGBIN=/opt/local/lib/postgresql94/bin
sudo -u postgres $PGBIN/pg_dumpall | gzip -9 > ~/pg-dump-all-$DATE.gz

Then stop pg 9.4, start pg 9.5, then reload the dump:

# Restore all databases and roles from dump into pg 9.5
PGBIN=/opt/local/lib/postgresql95/bin
gunzip < ~/pg-dump-all-$DATE.gz |  $PGBIN/psql -U postgres

voilà, start OpenACS, and everything works fine.

In case there is a problem with restoring the dump in PostgreSQL 9.5 due to the "=>" operator of hstore, one has to update the version of hstore at least to 1.1 before dump/restore (the current version of hstore is 1.4; for details see hstore-upgrade).

In case, you want to upgrade your legacy OpenACS installation from PostgreSQL 8.* to 9, read upgrade-oacs-5-8.

 

 

Categories: Subsystems Documentation (OpenACS.org)

Postgres 8.1.x to 9.1

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 08 Jul 2016, at 02:25 PM

PostgreSQL 8.x (e.g. 8.1.* and later up to 9.1) require a few changes in the configuration file for backward compatibility (see below).

Note that OpenACS 5.8 or newer works with PostgreSQL 9.1 (or newer) out of the box, the special configurations for postgresql.conf described below are not needed anymore.

1. Configure postgres8 with all compatibility ON in postgresql.conf:

 add_missing_from = on 
 regex_flavor = extended 
 default_with_oids = on

2. If you are upgrading an OpenACS site between versions 4.5.2 to 5.2 and not continuing to 5.3, then: After the createdb step to create the OpenACS database, generate the next function before you import the pre-existing OpenACS database.

From your shell prompt enter:

psql <dbname>

From the psql prompt enter the follow plpgsql code to create the bitfromint4 function:

 

 create or replace function bitfromint4 (integer) 
 returns bit varying as ' 
 begin 
    return $1::bit(32); 
 end;' language 'plpgsql' immutable strict;

Exit psql:

\q 

This is the original thread 

For a full script on how to install PG 8.2 with ltree and tsearch2 look at Malte's install script 

References to this Page: en:OpenACSInstallGuide, en:postgresql-install, en:Debian_Ubuntu_installation Categories: Subsystems Documentation (OpenACS.org)
Next Page
previous November 2024
Sun Mon Tue Wed Thu Fri Sat
27 28 29 30 31 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Popular tags

17 , 5.10 , 5.10.0 , 5.10.1 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , compatibility , CSP , CSRF , cvs , debian , docker , docker-compose , emacs , engineering-standards , exec , fedora , FreeBSD , guidelines , host-node-map
No registered users in community xowiki
in last 30 minutes
Contributors

OpenACS.org