Showing 21 - 30 of 230 Postings (summary)

here

Created by Gustaf Neumann, last modified by Gustaf Neumann 06 Nov 2016, at 09:43 AM

-- acceptance-sql.txt by philg@mit.edu and jsc@arsdigita.com
--                      (Philip Greenspun and Jin Choi)

-- SQL commands to test an Oracle installation
-- for adequate privileges and capacity
-- run as the same user as the Web user

-- creating a table
create table foo (
	foo_key	integer primary key,
	random	varchar(1000)
);

-- creating an index
create index foo_on_random on foo ( random );

-- inserting some rows
insert into foo values (1, '1');
insert into foo values (2, '2');
insert into foo values (3, '3');
insert into foo values (4, '4');
insert into foo values (5, '5');
insert into foo values (6, '6');
insert into foo values (7, '7');
insert into foo values (8, '8');
insert into foo values (9, '9');
insert into foo values (10, '10');
insert into foo values (11, null);
insert into foo values (12, null);
insert into foo values (13, null);
insert into foo values (14, null);
insert into foo values (15, null);
insert into foo values (16, null);
insert into foo values (17, null);
insert into foo values (18, null);
insert into foo values (19, null);
insert into foo values (20, null);

-- create another table to work with
create table bar as select foo_key + 1 as bar_key, random from foo;

-- joins
select b.random from foo f, bar b where f.foo_key = b.bar_key and f.random like '3%';

-- update
update foo set foo_key = foo_key + 100 where random is null;

-- should return 10
select count(*) from foo where foo_key > 100;

-- create a sequence
create sequence foo_sequence start with 200;

-- test whether truncate works
truncate table bar;

drop table bar;


-- test 1) whether has privileges to create a procedure
--  and 2)  whether rollback segments are adequately sized

-- create a pl/sql procedure
create or replace procedure thrash_database(v_number_of_rows IN integer)
AS
  i	integer;
BEGIN
  FOR i IN 1..v_number_of_rows LOOP
    insert into foo (foo_key, random) values (foo_sequence.nextval, 'abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij');
  END LOOP;
END thrash_database;
/
show errors

-- we think any Oracle installation ought to be able to handle
-- 100,000 rows of 500 bytes each

execute thrash_database(100000);

select count(*) from foo;

commit;

delete from foo;
commit;

drop table foo;
drop sequence foo_sequence;
drop procedure thrash_database;

-- make sure that NLS_DATE_FORMAT is correct by 
-- seeing that the following command returns
-- YYYY-MM-DD (e.g., 1999-05-22)

select sysdate from dual;

Name	Content Type	Last Modified	By User	Size (Bytes)
acceptance-sql.txt	text/plain	2016-11-06 09:43:31+01	Gustaf Neumann	2915

References to this Page: en:oracle Categories: beginner (Audience)

How Internationalization/Localization works in OpenACS

Created by Gustaf Neumann, last modified by Gustaf Neumann 02 Feb 2016, at 04:36 PM

This document describes how to develop internationalized OpenACS packages, including writing new packages with internationalization and converting old packages. Text that users might see is "localizable text"; replacing monolingual text and single-locale date/time/money functions with generic functions is "internationalization"; translating first generation text into a specific language is "localization." At a minimum, all packages should be internationalized. If you do not also localize your package for different locales, volunteers may use a public "localization server" to submit suggested text. Otherwise, your package will not be usable for all locales.

The main difference between monolingual and internationalized packages is that all user-visible text in the code of an internationalized package are coded as "message keys." The message keys correspond to a message catalog, which contains versions of the text for each available language. Script files (.adp and .tcl and .vuh), database files (.sql), and APM parameters are affected.

Other differences include: all dates read or written to the database must use internationalized functions. All displayed dates must use internationalized functions. All displayed numbers must use internationalized functions.

Localizable text must be handled in ADP files, in TCL files, and in APM Parameters. OpenACS provides two approaches, message keys and localized ADP files. For ADP pages which are mostly code, replacing the message text with message key placeholders is simpler. This approach also allows new translation in the database, without affecting the file system. For ADP pages which are static and mostly text, it may be easier to create a new ADP page for each language. In this case, the pages are distinguished by a file naming convention.

OpenACS does not have a general system for supporting multiple, localized versions of user-input content. This document currently refers only to internationalizing the text in the package user interface.

If the request processor finds a file named filename.locale.adp, where locale matches the user's locale, it will process that file instead of filename.adp. For example, for a user with locale tl_PH, the file index.tl_PH.adp, if found, will be used instead of index.adp. The locale-specific file should thus contain text in the language appropriate for that locale. The code in the page, however, should still be in English. Message keys are processed normally.

Internationalizing templates is about replacing human readable text in a certain language with internal message keys, which can then be dynamically replaced with real human language in the desired locale. Message keys themselves should be in ASCII English, as should all code. Three different syntaxes are possible for message keys.

"Short" syntax is the recommended syntax and should be used for new development. When internationalizing an existing package, you can use the "temporary" syntax, which the APM can use to auto-generate missing keys and automatically translate to the short syntax. The "verbose" syntax is useful while developing, because it allows default text so that the page is usable before you have done localization.

The short: #package_key.message_key#

The advantage of the short syntax is that it's short. It's as simple as inserting the value of a variable. Example: #forums.title#
The verbose: <trn key="package_key.message_key" locale="locale">default text</trn>

The verbose syntax allows you to specify a default text in a certain language. This syntax is not recommended anymore, but it can be convenient for development, because it still works even if you haven't created the message in the message catalog yet, because what it'll do is create the message key with the default text from the tag as the localized message. Example: <trn key="forum.title" locale="en_US">Title</trn>
The temporary: <#message_key original text#>

This syntax has been designed to make it easy to internationalize existing pages. This is not a syntax that stays in the page. As you'll see later, it'll be replaced with the short syntax by a special feature of the APM. You may leave out the message_key by writing an underscore (_) character instead, in which case a message key will be auto-generated by the APM. Example: <_ Title>

We recommend the short notation for new package development.

In adp files message lookups are typically done with the syntax #package_key.message_key#. In Tcl files all message lookups *must* be on either of the following formats:

Typical static key lookup: [_ package_key.message_key] - The message key and package key used here must be string literals, they can't result from variable evaluation.
Static key lookup with non-default locale: [lang::message::lookup $locale package_key.message_key] - The message key and package key used here must be string literals, they can't result from variable evaluation.
Dynamic key lookup: [lang::util::localize $var_with_embedded_message_keys] - In this case the message keys in the variable var_with_embedded_message_keys must appear as string literals #package_key.message_key# somewhere in the code. Here is an example of a dynamic lookup: set message_key_array { dynamic_key_1 #package_key.message_key1# dynamic_key_2 #package_key.message_key2# } set my_text [lang::util::localize $message_key_array([get_dynamic_key])]

Translatable texts in page TCL scripts are often found in page titles, context bars, and form labels and options. Many times the texts are enclosed in double quotes. The following is an example of grep commands that can be used on Linux to highlight translatable text in TCL files:

# Find text in double quotes
find -iname '*.tcl'|xargs egrep -i '"[a-z]'

# Find untranslated text in form labels, options and values
find -iname '*.tcl'|xargs egrep -i '\-(options|label|value)'|egrep -v '<#'|egrep -v '\-(value|label|options)[[:space:]]+\$[a-zA-Z_]+[[:space:]]*\\?[[:space:]]*$'

# Find text in page titles and context bars
find -iname '*.tcl'|xargs egrep -i 'set (title|page_title|context_bar) '|egrep -v '<#'

# Find text in error messages
find -iname '*.tcl'|xargs egrep -i '(ad_complain|ad_return_error)'|egrep -v '<#'

You may mark up translatable text in TCL library files and TCL pages with temporary tags on the <#key text#> syntax. If you have a sentence or paragraph of text with variables and or procedure calls in it you should in most cases try to turn the whole text into one message in the catalog (remember that translators is made easier the longer the phrases to translate are). In those cases, follow these steps:

For each message call in the text, decide on a variable name and replace the procedure call with a variable lookup on the syntax %var_name%. Remember to initialize a tcl variable with the same name on some line above the text.
If the text is in a tcl file you must replace variable lookups (occurences of $var_name or ${var_name}) with %var_name%
You are now ready to follow the normal procedure and mark up the text using a tempoarary message tag (<#_ text_with_percentage_vars#>) and run the action replace tags with keys in the APM.

The variable values in the message are usually fetched with upvar, here is an example from dotlrn: ad_return_complaint 1 "Error: A [parameter::get -parameter classes_pretty_name] must have <em>no</em>[parameter::get -parameter class_instances_pretty_plural] to be deleted" was replaced by: set subject [parameter::get -localize -parameter classes_pretty_name] set class_instances [parameter::get -localize -parameter class_instances_pretty_plural] ad_return_complaint 1 [_ dotlrn.class_may_not_be_deleted]

This kind of interpolation also works in adp files where adp variable values will be inserted into the message.

Alternatively, you may pass in an array list of the variable values to be interpolated into the message so that our example becomes:

set msg_subst_list [list subject [parameter::get -localize -parameter classes_pretty_name] class_instances [parameter::get -localize -parameter class_instances_pretty_plural]]

ad_return_complaint 1 [_ dotlrn.class_may_not_be_deleted $msg_subst_list]

When we were done going through the tcl files we ran the following commands to check for mistakes:

# Message tags should usually not be in curly braces since then the message lookup may not be
# executed then (you can usually replace curly braces with the list command). Find message tags
# in curly braces (should return nothing, or possibly a few lines for inspection)
find -iname '*.tcl'|xargs egrep -i '\{.*<#'

# Check if you've forgotten space between default key and text in message tags (should return nothing)
find -iname '*.tcl'|xargs egrep -i '<#_[^ ]'

# Review the list of tcl files with no message lookups
for tcl_file in $(find -iname '*.tcl'); do egrep -L '(<#|\[_)' $tcl_file; done

When you feel ready you may vist your package in the package manager and run the action "Replace tags with keys and insert into catalog" on the TCL files that you've edited to replace the temporary tags with calls to the message lookup procedure.

Most date, time, and number variables are calculated in TCL files. Dates and times must be converted when stored in the database, when retrieved from the database, and when displayed. All dates are stored in the database in the server's timezone, which is an APM Parameter set at /acs-lang/admin/set-system-timezone and readable at lang::system::timezone.. When retrieved from the database and displayed, dates and times must be localized to the user's locale.

Some parameters contain text that need to be localized. In this case, instead of storing the real text in the parameter, you should use message keys using the short notation above, i.e. #package_key.message_key#.

In order to avoid clashes with other uses of the hash character, you need to tell the APM that the parameter value needs to be localized when retrieving it. You do that by saying: parameter::get -localize.

Here are a couple of examples. Say we have the following two parameters, taken directly from the dotlrn package.

Parameter Name	Parameter Value
class_instance_pages_csv	#dotlrn.class_page_home_title#,Simple 2-Column;#dotlrn.class_page_calendar_title#,Simple 1-Column;#dotlrn.class_page_file_storage_title#,Simple 1-Column
departments_pretty_name	#departments_pretty_name #

Then, depending on how we retrieve the value, here's what we get:

Command used to retrieve Value	Retrieved Value
parameter::get -localize -parameter class_instances_pages_csv	Kurs Startseite,Simple 2-Column;Kalender,Simple 1-Column;Dateien,Simple 1-Column
parameter::get -localize -parameter departments_pretty_name	Abteilung
parameter::get -parameter departments_pretty_name	#departments_pretty_name#

The value in the rightmost column in the table above is the value returned by an invocation of parameter::get. Note that for localization to happen you must use the -localize flag.

The locale used for the message lookup will be the locale of the current request, i.e. lang::conn::locale or ad_conn locale.

Developers are responsible for creating the keys in the message catalog, which is available at /acs-lang/admin/

this is a <> test

Created by Gustaf Neumann, last modified by Gustaf Neumann 20 Oct 2015, at 11:07 AM

...

testing links

Created by Gustaf Neumann, last modified by Gustaf Neumann 20 Oct 2015, at 11:06 AM

a link: this is a test

a link: this is <> test

a link: this is <a> test

Categories

Created by Gustaf Neumann, last modified by Gustaf Neumann 15 Oct 2015, at 12:09 PM

extended by Nima Mazloumi

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.

You can associate any ACS Object with one or more categories. In this tutorial we'll show how to equip your application with user interface to take advantage of the Categories service.

We'll start by installing the Categories service. Go to /acs/admin and install it. This step won't be necessary for the users of your applications because you'll create a dependency with the Package Manager which will take care that the Categories service always gets installed when your application gets installed.

Now that we have installed the Categories service we can proceed to modifying our application so that it can take advantage of it. We'll do it in three steps:

The Categories service provides a mechanism to associate one or more category trees that are relevant to your application. One example of such tree is a tree of geographical locations. Continents are on the top of such tree, each continent containing countries etc. Another tree might contain market segments etc. Before users of your application can take advantage of the Categories service there needs to be a way for administrators of your application to choose which category trees are applicable for the application.

The way to achieve this is is to provide a link to the Category Management pages. Add the following snippet to your /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/myfirstpackage/www/admin/index.tcl file:
```
		  set category_map_url [export_vars -base "[site_node::get_package_url -package_key categories]cadmin/one-object" { { object_id $package_id } }]
          
```
and the following snippet to your /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/myfirstpackage/www/admin/index.adp file:
```
   			<a href="@category_map_url@"<#categories.Site_wide_Categories#</a>
          
```
The link created by the above code (category_map_url) will take the admin to the generic admin UI where he can pick category trees that make sense for this application. The same UI also includes facilities to build and edit category trees. Notice that the only parameter in this example is package_id so that category trees will be associated with the object identified by this package_id. The categorization service is actually more general than that: instead of package_id you could use an ID of some other object that serves as a "container" in your application. For example, if your discussion forums application supports multiple forums you would use forum_id to associate category trees with just that one forum rather than the entire application instance.

Once the category trees have been selected users need a way to categorize items. The easiest way to do this is by adding the category widget type of the form builder to note-edit.tcl. To achieve this we'll need to use the -extend switch to the ad_form command. Here's the "meat" of the note-edit.tcl page:

			    #extend the form to support categories
			    set package_id [ad_conn package_id]
			
    			category::ad_form::add_widgets -form_name note -container_object_id $package_id -categorized_object_id [value_if_exists item_id]

    			ad_form -extend -name note -on_submit {
        			set category_ids [category::ad_form::get_categories -container_object_id $package_id]
    			} -new_data {
    				....
					category::map_object -remove_old -object_id $item_id $category_ids
            		db_dml insert_asc_named_object "insert into acs_named_objects (object_id, object_name, package_id) values ( :item_id, :title, :package_id)"
	    		} -edit_data {
            		....
        			db_dml update_asc_named_object "update acs_named_objects set object_name = :title, package_id = :package_id where object_id = :item_id"
        			category::map_object -remove_old -object_id $item_id $category_ids
    			} -after_submit {
        				ad_returnredirect "."
        				ad_script_abort
    			}

While the category::ad_form::add_widgets proc is taking care to extend your form with associated categories you need to ensure that your items are mapped to the corresponding category object yourself. Also since the categories package knows nothing from your objects you have to keep the acs_named_objects table updated with any changes taking place. We use the items title so that they are listed in the categories browser by title.

Make sure that you also delete these entries if your item is delete. Add this to your corresponding delete page:

			db_dml delete_named_object "delete from acs_named_objects where object_id = :item_id"

note-edit.tcl requires a note_id to determine which record should be deleted. It also looks for a confirmation variable, which should initially be absert. If it is absent, we create a form to allow the user to confirm the deletion. Note that in entry-edit.tcl we used ad_form to access the Form Template commands; here, we call them directly because we don't need the extra features of ad_form. The form calls itself, but with hidden variables carrying both note_id and confirm_p. If confirm_p is present, we delete the record, set redirection back to the index, and abort script execution.

The database commands:

[$OPENACS_SERVICE_NAME@yourserver www]$ emacs note-delete.xql

<?xml version="1.0"?>
<queryset>
  <fullquery name="do_delete">
    <querytext>
      select samplenote__delete(:note_id)
    </querytext>
  </fullquery>
  <fullquery name="get_name">
    <querytext>
      select samplenote__name(:note_id)
    </querytext>
  </fullquery>
</queryset>

And the adp page:

[$OPENACS_SERVICE_NAME@yourserver www]$ emacs note-delete.adp

<master>
<property name="title">@title@</property>
<property name="context">{@title@}</property>
<h2>@title@</h2>
<formtemplate id="note-del-confirm"></formtemplate>
</form>

The ADP is very simple. The formtemplate tag outputs the HTML form generated by the ad_form command with the matching name. Test it by adding the new files in the APM and then deleting a few samplenotes.

We will now make categories optional on package instance level and also add a configuration page to allow the package admin to enable/disable categories for his package.

Go to the APM and create a number parameter with the name "EnableCategoriesP" and the default value "0".

Add the following lines to your index.tcl:

          set return_url [ns_conn url]
          set use_categories_p [parameter::get -parameter "EnableCategoriesP"]

Change your to this:

			<a href=configure?<%=[export_url_vars return_url]%>>Configure</a>
			<if @use_categories_p@>
   			<a href="@category_map_url@"<#categories.Site_wide_Categories#</a>
   			</if>

Now create a configure page

          	ad_page_contract {
    			This page allows an admin to change the categories usage mode.
			} {
    			{return_url ""}
			}

			set title "Configure category mode"
			set context [list $title]
			set use_categories_p [parameter::get -parameter "EnableCategoriesP"]

			ad_form -name categories_mode -form {
    			{enabled_p:text(radio)
        			{label "Enable Categories"}
        			{options {{Yes 1} {No 0}}}
        			{value $use_categories_p}
    			}
    			{return_url:text(hidden) {value $return_url}}
    			{submit:text(submit) {label "Set Mode"}}
			} -on_submit {
    			parameter::set_value  -parameter "EnableCategoriesP" -value $enabled_p
    			if {![empty_string_p $return_url]} {
        			ns_returnredirect $return_url
    			}
			}

and add this to its corresponding ADP page

          	<master>
			<property name="title">@title@</property>
			<property name="context">@context@</property>

			<formtemplate id="categories_mode"></formtemplate>

Reference this page from your admin page

		#TCL:
		set return_url [ad_conn url]

		#ADP:
		<a href=configure?<%=[export_url_vars return_url]%>>Configure</a>

Change the note-edit.tcl:

		# Use Categories?
		set use_categories_p [parameter::get -parameter "EnableCategoriesP" -default 0]
		if { $use_categories_p == 1 } {
			# YOUR NEW FORM DEFINITION
		} else {
    		# YOUR OLD FORM DEFINITION
		}

You can filter your notes using categories. The below example does not support multiple filters and displays a category in a flat format.

The first step is to define the optional parameter category_id for index.tcl:

 	  	ad_page_contract {
  		YOUR TEXT
		} {
			YOURPARAMS
    		{category_id:integer,optional {}}
		}

Now you have to check whether categories are enabled or not. If this is the case and a category id is passed you need to extend your sql select query to support filtering. One way would be to extend the mfp::note::get proc to support two more swiches -where_clause and -from_clause.

 	  	set use_categories_p [parameter::get -parameter "EnableCategoriesP" -default 0]

		if { $use_categories_p == 1 && [exists_and_not_null category_id] } {

			set from_clause "category_object_map com, acs_named_objects nam"
			set_where_clause "com.object_id = qa.entry_id and
								nam.package_id = :package_id and
								com.object_id = nam.object_id and
								com.category_id = :category_id"
			
			...
								
    		mfp::note::get \
    		-item_id $item_id \
    		-array note_array \
    		-where_clause $where_clause \
    		-from_clause $from_clause
    		
    		...
		} else {
    		# OLD STUFF
		}

Also you need to make sure that the user can see the corresponding categories. Add the following snippet to the end of your index page:

 	  # Site-Wide Categories
		if { $use_categories_p == 1} {
    		set package_url [ad_conn package_url]
    		if { ![empty_string_p $category_id] } {
        		set category_name [category::get_name $category_id]
        		if { [empty_string_p $category_name] } {
            		ad_return_exception_page 404 "No such category" "Site-wide \
          			Category with ID $category_id doesn't exist"
            		return
        		}
        		# Show Category in context bar
        		append context_base_url /cat/$category_id
        		lappend context [list $context_base_url $category_name]
        		set type "all"
    		}

    		# Cut the URL off the last item in the context bar
    		if { [llength $context] > 0 } {
        		set context [lreplace $context end end [lindex [lindex $context end] end]]
    		}

    		db_multirow -unclobber -extend { category_name tree_name } categories categories {
        		select c.category_id as category_id, c.tree_id
        		from   categories c, category_tree_map ctm
        		where  ctm.tree_id = c.tree_id
        		and    ctm.object_id = :package_id
    		} {
        		set category_name [category::get_name $category_id]
        		set tree_name [category_tree::get_name $tree_id]
    		}
		}

and to the corresponding index ADP page:

		<if @use_categories_p@>
 			<multiple name="categories">
           		<h2>@categories.tree_name@
           		<group column="tree_id">
             		<a href="@package_url@cat/@categories.category_id@?@YOURPARAMS@&category_id=@categories.category_id@">@categories.category_name@
           		</group>
         	</multiple>
		<a href="@package_url@view?@YOURPARAMS@">All Items</if>

Finally you need a an index.vuh in your www folder to rewrite the URLs correctly, the section called âUsing .vuh files for pretty urlsâ:

 	  	set url /[ad_conn extra_url]

		if {[regexp {^/+cat/+([^/]+)/*} $url \
          ignore_whole category_id]} {
          rp_form_put category_id $category_id
		}
		rp_internal_redirect "/packages/YOURPACKAGE/www/index"

Now when ever the user select a category only notes that belong to this category are displayed.

Workshop Announcement

Created by Gustaf Neumann, last modified by Unregistered Visitor 10 Jan 2014, at 12:14 PM

@event@

Abstract: @_text@
@detail_link@

Talk Announcement

Created by Gustaf Neumann, last modified by Unregistered Visitor 10 Jan 2014, at 12:14 PM

@event@

Abstract: @_text@
@detail_link@

News Item

Created by , last modified by Unregistered Visitor 10 Jan 2014, at 12:14 PM

@image_url@ @_text@
@detail_link@

Book

Created by Gustaf Neumann, last modified by Gustaf Neumann 18 Aug 2010, at 08:31 PM

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

Book

Creator: Gustaf Neumann

Deactivated for now.

\{{book -menu_buttons "edit copy create delete"}}

Install AOLserver 3.3oacs1

Created by Gustaf Neumann, last modified by Gustaf Neumann 24 Apr 2009, at 11:00 AM

by Vinod Kurup

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.

We recommend the use of AOLserver 4.0.1 or later. These instructions are retained as a resource.

Debian users: we do not recommend installing Debian packages for Aolserver or Postgres. Several people have reported problems while trying to install using apt-get instead of from source. If you have the time to debug these and submit what you did, that's great, but if not, you should stick to installing from source.

Unpack the Aolserver tarball.Download the aolserver tarball and unpack it.

[root root]# cd /usr/local/src
[root src]# wget --passive http://uptime.openacs.org/aolserver-openacs/aolserver3.3oacs1.tar.gz
--15:38:08--  http://uptime.openacs.org/aolserver-openacs/aolserver3.3oacs1.tar.gz
           => `aolserver3.3oacs1.tar.gz'
Resolving uptime.openacs.org... done.
Connecting to uptime.openacs.org[207.166.200.199]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,858,074 [application/x-compressed]

100%[====================================>] 3,858,074     66.56K/s    ETA 00:00

15:39:05 (66.56 KB/s) - `aolserver3.3oacs1.tar.gz' saved [3858074/3858074]
[root src]# tar xzf aolserver3.3oacs1.tar.gz
[root src]#

This section also relies on some OpenACS files, which you can get with the section called "Unpack the OpenACS tarball".

Compile AOLserver.Compile and install AOLserver. First, prepare the installation directory and the source code. The message about BUILD-MODULES can be ignored.
```
root@yourserver root]# mkdir -p /usr/local/aolserver
[root root]# cd /usr/local/src/aolserver
[root aolserver]# ./conf-clean
cat: BUILD-MODULES: No such file or directory
Done.
[root aolserver]#mkdir -p /usr/local/aolserve
```
If you are using Oracle, edit conf-db and change postgresql to oracle, or to the word both if you want both drivers installed. In order to get nsoracle to compile, you may need to su - oracle, and then su (without the -) root to set the environment variables properly.

conf-inst should contain the location where AOLserver is to be installed. Overwrite the tarball's default value with our default value, /usr/local/aolserver:
```
[root aolserver]# echo "/usr/local/aolserver" > conf-inst
[root aolserver]#
```
conf-make should contain the name of the GNU Make command on your system. It defaults to gmake. Debian users: ln -s /usr/bin/make /usr/bin/gmake.

Set an environment variable that the nspostgres driver Makefile needs to compile correctly and run conf, which compiles AOLserver, the default modules, and the database driver, and installs them.

Debian users, see warning above, but if you do use apt-get for AOLserver 3.3+ad13 and postgresql from apt-get may need to make these symlinks: ln -s /usr/include/postgresql/ /usr/include/pgsql and ln -s /usr/lib/postgresql /usr/local/pgsql)
```
[root aolserver]# export POSTGRES=/usr/local/pgsql; ./conf
Building in /usr/local/aolserver
with the following modules:
aolserver
nscache
nsrewrite
nssha1
nsxml
pgdriver
==================================================================
Starting Build Sat Mar  8 10:28:26 PST 2003
Running gmake in aolserver/; output in log/aolserver.log
(several minute delay here)
Running gmake in nscache/; output in log/nscache.log
Running gmake in nsrewrite/; output in log/nsrewrite.log
Running gmake in nssha1/; output in log/nssha1.log
Running gmake in nsxml/; output in log/nsxml.log
Running gmake in nspostgres/; output in log/nspostgres.log
Creating  ...
==================================================================
Done Building Sat Mar  8 10:31:35 PST 2003
[root aolserver]# 
```
This takes about 5 minutes. It builds aolserver, several modules, and the database driver. (Upgraders, note that the postgres database driver has changed from postgres.so to nspostgres.so). All of the results are logged to files in /usr/local/src/aolserver/log. If you run into problems running AOLserver, check these files for build errors.

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.

Oracle

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

stgreSQL

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

Install tDOM.Download the tDOM tarball, unpack it, adjust the configuration file to match our patched distribution of aolserver, and compile it.

[root root]# cd /usr/local/src
[root src]# wget --passive http://www.tdom.org/tDOM-0.7.8.tar.gz
--16:40:58--  http://www.tdom.org/tDOM-0.7.8.tar.gz
           => `tDOM-0.7.8.tar.gz'
Resolving www.tdom.org... done.
Connecting to www.tdom.org[212.14.81.4]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 826,613 [application/x-compressed]

100%[====================================>] 826,613      138.06K/s    ETA 00:00

16:41:04 (138.06 KB/s) - `tDOM-0.7.8.tar.gz' saved [826613/826613]

[root src]# tar xzf tDOM-0.7.8.tar.gz
[root src]# cd tDOM-0.7.8/unix
[root unix]#

Edit the file CONFIG and change this section:

# ----------------------------------------------------
# aolsrc="/usr/src/aolserver-3.4"
# ../configure --enable-threads --disable-tdomalloc  #   --with-aolserver=$aolsrc  #   --with-tcl=$aolsrc/tcl8.3.4/unix

# ----------------------------------------------------
aolsrc="/usr/local/src/aolserver/aolserver"
../configure --enable-threads --disable-tdomalloc  --with-aolserver=$aolsrc  --with-tcl=$aolsrc/tcl8.3.2/unix

And configure and compile:

[root unix]# sh CONFIG
creating cache ./config.cache
checking for memmove... yes
  (many lines omitted)
creating Makefile
creating tdomConfig.sh
[root unix]# make
gcc -pipe -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DTCL_THREADS=1
-DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1
  (many lines omitted)
          -Wl,-rpath,/usr/local/lib -o tcldomsh; fi
[root unix]# cp libtdom0.7.8.so /usr/local/aolserver/bin/
[root unix]# cd /usr/local/aolserver/bin/
[root bin]# ln -s libtdom0.7.8.so libtdom.so
[root bin]#

Install nsopenssl (OPTIONAL)
Install Full Text Search with OpenFTS (OPTIONAL)
Install nspam (OPTIONAL)
Test AOLserver.In order to test AOLserver, we'll run it using the sample-config.tcl file provided in the AOLserver distribution, under 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/aolserver40r8/servers/server1/pages/index.html

Now, we'll run a quick test to ensure AOLserver is running correctly. We'll use the sample config file provided with AOLserver. This file will attempt to guess your 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 won't be using nsssl; we'll be using nsopenssl instead, and we haven't fully configured it yet. The nscp warning refers to the fact that, without a user and password in the config file, the administrative panel of AOLserver won't load. We don't plan to use it and can ignore that error as well. Any other warning or error is unexpected and probably a problem.

Test to see if AOLserver is working by starting Mozilla or Lynxon 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'll get a false negative test.
```
[root aolserver]# lynx localhost:8000
```
You should see a "Welcome to AOLserver" page. If this doesn't work, try going to http://127.0.0.1:8000/. If this still doesn't work, check out the Troubleshooting AOLserver section below. 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 the Keep AOLserver alive section.
Troubleshooting.If you can't view the welcome page, it's likely there's a problem with your server configuration. Start by viewing your AOLserver log, which is in /usr/local/aolserver/log/server.log. You should also try to find lines of the form:
```
[01/Jun/2000:12:11:20][5914.4051][-nssock-] Notice: nssock: listening on http://localhost.localdomain:8000 (127.0.0.1:8000)
[01/Jun/2000:12:11:20][5914.4051][-nssock-] Notice: accepting connections
```
If you can find these lines, try entering the URL the server is listening on. If you cannot find these lines, there must be an error somewhere in the file. Search for lines beginning with the word Error instead of Notice.

The sample-config.tcl file grabs your address and hostname from your OS settings.
```
set hostname        [ns_info hostname]
set address         [ns_info address]
```
If you get an error that nssock can't get the requested address, you can set these manually. If you type 0.0.0.0, AOLserver will try to listen on all available addresses. Note: ns_info address doesn't appear to be supported in current versions of AOLserver.
```
set hostname        [ns_info hostname]
#set address         [ns_info address]
set address 0.0.0.0
```
Install Analog web file analyzer. (OPTIONAL)

Weblog

Book