Weblog Page

XoWiki: List of the available includelets

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:11 AM

This is a list of the includelets, which can be included in a xowiki page: 

XoWiki: How to save files directly in the wiki

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:08 AM

In order to save files directly in the wiki, just add a link with the content file:yourfile to a page (as for other links, between curly double brackets).

[[file:oacs-dotlrn-vienna-xowiki.pdf|XoWiki Slides from the Vienna OpenACS conference]]

When the file link is added, and the file does not exist, the wiki marks the link with a handle to upload the file. According to the current policies, everybody who is logged-in has sufficient permissions is allowed to edit pages.. 

Here is an example of a file-link, pointing to the xowiki slides from the the Vienna oacs-dotlrn conference XoWiki Slides from the Vienna OpenACS conference

OpenACS Performance Tuning

Created by OpenACS community, last modified by Benjamin Brink 30 Jun 2017, at 06:56 AM

OpenACS Performance Tuning

Here is some documentation on general OpenACS performance tuning:

• Boost_your_application_performance_to_serve_large_files
• Diagnosing Performance Problems

Much performance tuning is targeted at the subsystems level, and so you will find some specific tuning information in these pages:

• en:aolserver-admin
• en:postgresql-admin

A broad scope of causes can be attributed to OpenACS performance issues. These forum threads help identify useful diagnostic techniques and accurate testing to help narrow the scope of problem areas etc.

• AOLserver and OpenACS Benchmarks (Why is my OpenACS so slow?)
• Server Performance Benchmarks with Apache Benchmark and Traffic Jamme
• How would one handle 12,000 db backed requests per second?
• Network performance monitoring tools
• Help Needed in Setting up .LRN to Scale
• Why is [my] OpenACS becoming so slow?
• Performance Problems - what is the bottleneck?
• Postgres connections [maxed out] and OpenACS
• Performance boost for older installations

Add extra headers

Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 30 Jun 2017, at 06:53 AM

Usually you can do it with templates:
<property name="header_stuff">
....
  </property>

But sometimes you want to add it not in just one page, so you usually go to www/site-master.adp, but that is not really good to maintain modularity, so instead, now you can define within your package a tcl callback like this:

ad_proc -public -callback subsite::get_extra_headers -impl my_implementation {} {
    return the stuff that should go into the html headers
} {

    set scripts "...."
    set tags "...."

    set text_to_return $scripts
    append text_to_return $tags

    return $text_to_return

}
 

Using Pound as a reverse Proxy

Created by Nima Mazloumi, last modified by Benjamin Brink 30 Jun 2017, at 06:52 AM

Requirements: You have OpenSSL installed and created a certificate.

Assumptions:

• You have OpenACS 5.2 installed (branch oacs-5-2) under /www/service0
• Your Server has the IP-Address 1.2.3.4
• Pound is running on Port 443 under user "root" and group "users"
• AOLserver on 127.0.0.1, Port 10000
• Your certificate is under "/www/service0/certs/certificate.pem"

For an alternative of pound, see Nginx with a sample configuration from Malte.

In order to use Pound for Load-Balancing and SSL encryption follow the below steps. Call "man pound" for a detailed description of the used parameters.

1. Install Pound

   cd /opt/src
   wget http://www.apsis.ch/pound/Pound-2.1.6.tgz
   tar xzpf Pound-2.1.6.tgz
   cd Pound-2.1.6
   ./configure
   make
   make install

2. Configure Pound

   emacs /usr/local/etc/pound.cfg/usr/local/etc/pound.cfg

   User            "root"
   Group           "users"
   LogLevel        0
   Alive           10

   ListenHTTPS
               Address 1.2.3.4
               Port 443
               Cert "/www/service0/certs/certificate.pem"
               xHTTP 2
               HeadRemove "X-SSL-Request"
               HeadRemove "X-Forwarded-For"
               AddHeader  "X-SSL-Request: 1"

               Service
                   URL ".*"
                   BackEnd
                           Address 127.0.0.1
                           Port 10000
                   End
               End
   End

3. Configure AOLserver

   emacs /www/service0/etc/config.tcl

   set httpport              10000
   set address               127.0.0.1

4. Start Pound+AOLserver

Passing values up from an include

Created by irc community, last modified by Benjamin Brink 30 Jun 2017, at 06:47 AM

following dialog from irc (names changed..) shows how to trick the system to pass values from an include to the calling page. This trick needs to be turned into real documentation.

dave: you can't pass stuff up from an include
dave: you have to use upvar
dave: ie: something like this works
michael: but, yes, the order is important. i.e., if i pass a reference to an include and hope to get/use a modified value, the value will be there *after* the <include>
dave: here is what works :)
dave: if you pass a property to a master template
dave: like this
dave: <property name="foo">@foo</property>
dave: <include src="myinclude">
dave: you can upvar #[template::adp_level] foo myfoo
dave: set myfoo "something"
dave: and something will be passed up to the master
dave: but since the code is just one big script
dave: you can't modify code that happens before
dave: we discussed quite a few times a way to work around that
dave: you could upvar something which would be available AFTER the include in the script
michael: i can do the same thing by passing in a reference
dave: yeah
dave: i just though of tha t:)
dave: cool.
michael: and the value will be there after the include
michael: so i just have to move my <property> tags to the bottom of the adp
dave: although that should be documented somehow that an include is modifying stuff in the caller
dave: i don't think you do. I can't remember. did that ages ago for gp and that code is hopefully long gone :)
michael: yeah, i tried it dave:
dave: cool.
tektubby: aha! one of the 7 mysteries of OpenACS solved.
dave: putting property at the bottom works? pretty clever
michael: when referencing the variable (set to "") before the include, i get "" on the calling page
michael: after the include, i get the modified value

Permissions explored, a practical way exists

Created by openacs irc community, last modified by Benjamin Brink 29 Jun 2017, at 04:31 AM

This is from a discussion about permissions on OpenACS' irc (names changed) that took place sometime circa 2005.

ryan: How do I create a group containing other groups? 
dave: composition_rel 
ryan: For instance, I have 30 admin groups, and instead of adding user A to each one manually, I want to add her to one group, and thus all 30. 
dave: what are you trying to accomplish? 
dave: you can't do that 
ryan: crap. 
dave: it it totally non-intuitive 
dave: here is why :) 
dave: we have the Super Admin group 
dave: wait. dave: no it doesn't work 
ryan: So what is a composition_rel? I thought parties were supposed to be a super-set of groups. 
dave: let me explain :) 
dave: no 
ryan: ok, thanks :) 
dave: here is how it works. 
dave: Super Admin 
dave: then we have admins_a which is a component of super admins 
dave: maybe it can work. 
dave: question is dave: can a group dave: have a composition_rel to more than one other group 
ryan: So what is the definition of a component? 
dave: lets find out. 
dave: a component 
dave: so if Admin A is a component of Super Admin 
dave: then every member of A is a member of Super 
dave: which is NOT what you want. 
dave: you want ever member of super to have permission over all the groups "inside" it right? 
dave: but in this case every member of A would have permission over all the other components etc. 
dave: group are NOT for permissions. 
dave: that is the design weirdness 
ryan: huh? 
ryan: Now I am completely confused. 
dave: you can't use groups the way you want 
ryan: isn't the whole point of groups to avoid permissioning on individual users? 
jim: but you should be able to build a page that asks for a user and puts the user into the 30 groups 
dave: ryan, yes. 
dave: you they don't inherit the way you think 
ryan: so you set permissions on a group with a set of objects, then just add/remove users from the group, right? 
dave: its backwards to what you are thinking. 
dave: yes dave: that works 
dave: perfectly 
jim: so you can get what you want (convenience, non-tedium) but have to do it another way 
dave: but composition_rels dave: behave backwards 
dave: they are not useful for org chart models 
ryan: ah ok. 
dave: but I think it can work 
ryan: What is an application of composition_rels? 
dave: here is what you would do 
dave: if it works 
dave: create all your groups 
dave: Admin A, Admin B etc 
ryan: done. 
dave: then make one group 
dave: and give it a composition rel to all of those groups. 
dave: its upside down. 
dave: then if I am in the one group, i am in all of those other groups 
jim: so you're putting the one group into all the groups 
jim: that should work :) 
dave: yes d
ave: b/c its not _in_ 
dave: its a component. d
ave: i think that will trigger the correct permissions. 
ryan: how do components work in the data model - I want to understand this better. 
dave: well jim: it' dave: then I recommend you 1) read the acs-kenrel sql files 
jim: s a special kind of acs_rel 
dave: 2) run alot fo experiments in psql 
dave: 3) find a bug in the triggers 
dave: :) 
dave: that is how I figured it out. 
dave: sucks huh. 
dave: seriously the comments in the SQL files in acs-kernel are very illuminating. 
dave: also have you read permissions tediously explained? 
ryan: but you're it'll work? ryan: Yes. d
ave: i am not sure it'll work 
dave: but jim: we think it will work r
yan: but I could re-read it a fourth time 
dave: i don't see any rule 
dave: that disallows a group being a component of more than one group 
dave: if there is such a rule, it won't work. 
ryan: but compositions typically extend 'up' the chain of groups? 
dave: yes dave: that is what its for 
dave: so for example 
ryan: what is a practical example? 
dave: I have Main Subsite 
dave: and several other subsites 
dave: wait 
dave: actually this is an example of why it doesn't work :) 
dave: hmmm actually I have to check 
dave: not sure if susbsite groups are components of main subsite or not. 
dave: .... 
ryan: You see, I want to create this super group and then let the client admin the members... 
dave: ok there are no rel_constraints on a default install. so that should be safe. 
dave: yes d
ave: but its really a sub-group 
jim: try it with two groups and another group be a component of both groups... give each of the first two groups two different permissions... put a user into the component group... 
dave: a super group would not work the way you want. 
dave: here i what you do 
jim: see if the user has both perms 
dave: 1) create two groups 
dave: 2) create another group 
dave: 3) make the third group a component of the first two 
dave: 4) add someone to the third group 
dave: 5) check if they are a member of 1 and 2 
dave: for extra credit 
dave: apply a permission to 1 and 2 
dave: check if the members of 3 have permission on those things 
dave: if this works 
jim: 1-4 and the extra credit are what I just sed :) 
dave: i just solved the oldest OpenACS 4 riddle 
joe: As a topical aside, we changed the way we use groups in our subsites for dotcommunity. One for admins and one for members (so we don't use admin_rels). Then we use a composition rel to make admins of top level sites also admins of lower level sites, and to compositions in the opposite direction to make members of lower level sites members of the higher level ones too. 
dave: jim, yes :) 
jim: 5 is a good idea too 
ryan: ok, sounds good. Will test and get back to you. That would be very cool if it could work both ways. Obviously it is important to be able to have groups of groups... 
dave: joie: you could still use admin_rels to do that 
dave: it would work the same way. 
dave: ryan, yes if that works the way I expect it would be cool. 
dave: joie, so is the lower level admin group a component of the higher level admin group? 
joe: The problem with admin rels was that an admin of a subsite became an admin of the supersite, which isnt what we wanted. 
dave: or the other way around? 
dave: joie: yes dave: that is what I just said 
dave: the component rels go the wrong way 
dave: than what you would think intuitively 
dave: although mathematically they work correctly as specified. 
dave: damn PhDs 
dave: basically we need to write high-level functional wrappers over all this crap 
joe: So we have a composition rel going "down" for admins, and "up" for members. So the supersite admin group is a component of the subsite's admin group, and the subsite's members group is a component of the supersites members group. 
dave: so you can just call a tcl proc that tells you what happens (instead of what is does in the database) dave: joie: ah so it _does_ work. that is just what I told ryan-g to do 
dave: we need to write a tcl api to do that that is clear what is happening. 
jim: so members of the subsite become also members of the supersite 
dave: yes dave: which makes sense 
joe: Indeed. Then we frigged the acs-subsite members pages to do the "right thing". 
dave: but then admins of the subsite become admins of the supersite (if you use admin_rels) 
dave: which is why you don't want to do that. 
dave: joie: but you are right 
dave: and openacs is wrong 
dave: except I doubt there is an upgrade script that would work 
dave: damn PhDs 
dave: joie: 
why the hell didn't you tell us this before? :) 
dave: i have been trying to figure that out for 4 years 
joe: We have an upgrade script that does it somewhere. Rob wrote it. 
dave: you rock. 
joe: We weren't sure the new way was "right". 
dave: yeah dave: it is dave: b/c it makes sense dave: well 
dave: except dave: no its right. 
joe: We then got rid of admin_rels completely. 
joe: and only use membership_rels 
dave: b/c everyone expects it to work that way 
dave: yeah see 
dave: the problems is 
dave: all this stuff was experimental 
dave: and no one every finished it jim: you would need to be careful when deleting certain objects 
dave: except you did. 
dave: so now we can say "this is the way its supposed to work' We can say that because that is the way every one has expected it to work, but it never did 
dave: wow 
jim: make sure to remove all rels first then delete 
dave: i am so surprised. 
joe: The code is in the dotCommiunity download on www.dotcommunity.org. The upgrade scripts aren't there though. 
dave: this is so cool. 
dave: get them! 
dave: :) 
joe: Heh. I'll talk to Rob about it tomorrow, as not sure what he implemented.

Host Node Map

Created by Gustaf Neumann, last modified by Gustaf Neumann 30 May 2017, at 02:28 PM

The host-node-map (see /acs-admin on your OpenACS installation) is a means to map virtual host names to sub-sites or to applications. Depending on the type of mapping, different options are available.

If one maps for instance a host name to an application package instance (i.e. the root url of the application is seen under / under host-node-mapped name, then site-wide services (such as search, register, site-wide administration) might or might not be available. If one want's to offer services to non-registered users, this might be perfectly fine.

When the mapping is against a sub-site, all sub-site services will be available (e.g. /register). This type of mapping can be useful for typical virtual host setups, where different sub-sites might be equipped with different themes.

In order to setup a host-node-mapping, one has to provide multiple names (typically DNS entries) for the same machine and to define then under /acs-admin the association between host names and site nodes.

The setup is influenced by a few parameters such as UseHostnameDomainforReg and CookieDomain. When UserHostnameDomainforReg is set true (default: false), all registrations initiated at the sub-site will be redirected to the main site. In these cases, the login cookie will be issued by /register for the main site, unless the CookieDomain is set appropriately. It is currently not supported to register users on completely different domains (not sharing a common root owned y the site master).

The situation with a host-node mapping to application packages is very similar to the last paragraph. Also in these cases, the /register url (generated via ad_get_login_url) will be mapped to the nearest sub-site, which might be the main site.

When using host-node-maps, don't use mixed HTTP/HTTPS setups based on RestrictLoginToSSLP. Also the usage of the (recommended) Strict-Transport-Security setting (setup via the NaviServer config file, see e.g. openacs-config.tcl) might interfere with RestrictLoginToSSLP. So the usefulness of the parameter is nowadays somewhat limited. The general trend is to use HTTPS for the full site (and all sub-sites as well).