Showing 181 - 190 of 693 Postings (
summary)
Created by Kenneth Wyrick, last modified by Benjamin Brink 29 Jun 2017, at 11:38 AM
Next-Steps
After following:
Debian Installation Instructions
A. Installing Daemontools
Documentation
nano /usr/share/doc/openacs|dotlrn/README.daemontools on openacs package.
apt-get install daemontools daemontools-run
B. Configuring Daemontools and Using SVC
1) Change the "StartDaemon" value to "no" in /etc/default/:
# OpenACS
nano /etc/default/openacs
... or ...
# .LRN
nano /etc/default/dotlrn
2) Stop the daemon:
# OpenACS
/etc/init.d/openacs stop
... or ...
# .LRN
/etc/init.d/dotlrn stop
3) Link daemontools dotlrn|openacs script:
# OpenACS
ln -s /usr/share/openacs/etc/daemontools /etc/service/openacs
... or ...
# .LRN
ln -s /usr/share/dotlrn/etc/daemontools /etc/service/dotlrn
Now you can control the dotlrn service using the svc command:
* To start the service: svc -u /etc/service//openacs or dotlrn
* To stop the service: svc -d /etc/service//openacs or dotlrn
* To restart the service: svc -t /etc/service/openacs or dotlrn
C. If There's Problems Purge and Reinstall
apt-get remove --purge openacs or dotlrn
apt-get install openacs or dotlrn
D. To configure the instance to listen on a different IP than 127.0.0.1
Edit the config.tcl file:
nano /etc/openacs|dotlrn/config.tcl
Change the following parameters to fit your needs:
set hostname Your hostname
set address to Your public IP
E. Backup and Restore (to be filled in)
and found that I had to figure out how to:
su - $OPENACS_SERVICE_NAME
pg_dump -f /var/lib/aolserver/$OPENACS_SERVICE_NAME/database-backup/before_upgrade_to_4.6.dmp openacs-dev
ls -al /var/lib/aolserver/$OPENACS_SERVICE_NAME/database-backup/before_upgrade_to_4.6.dmp
exit
The $OPENACS_SERVICE_NAME
which I thought would be "dotlrn"
turned out to be "www-data"
Next I found there was no /var/lib/aolserver but there are /var/lib/dotlrn and /var/lib/postgresql
The default paths show the locations that were decided upon (in early 2004) so below we will try to document were things are in a standard dotlrn installation, now.
| a work in progress |
|
| |
|
| OpenACS service |
dotlrn |
| OpenACS service account |
www-data |
| OpenACS database name |
dotlrn |
| SERVERROOT |
/usr/share/dotlrn/www |
| Database backup directory |
/var/backups/ |
| Service config files |
/usr/share/dotlrn/etc/config.tcl |
| Service log files |
/usr/share/dotlrn/log/ |
| PostgreSQL directory |
/usr/lib/postgresql/8.3/main |
| AOLserver directory |
/usr/lib/aolserver4 |
| Backup Script |
/usr/share/dotlrn/etc/backup.sh |
F. Installing Packages (to be filled in)
1. From .LRN CVS
a) Create a local repository
b) Download to your local repository
G. View the Log File
nano /var/log/aolserver4/dotlrn/error.log
H. Mail Server (to be filled in)
- Installation
- configuration
Created by Benjamin Brink, last modified by Benjamin Brink 29 Jun 2017, at 11:33 AM
It's imperative that you secure your installation. As Jon Griffin repeatedly warns us, "No distribution is secure out of the box."
A Reference Platform implements some basic precautions, but security is a process, not a condition. If you are responsible for a computer hooked to the internet, you are responsible for learning some rudiments of security, such as monitoring the state of a computer, maintaining patch levels, and keeping backups.
We recommend these resources:
Content Security Policies (CSP)
OpenACS supports CSP starting with version 5.9.1.
Created by OpenACS community, last modified by Benjamin Brink 29 Jun 2017, at 11:30 AM
Follow the installation directions that come with the distribution.
There are generally 2 strategies at this point:
- Install an OS with minimum programs, or
- Install a suite of programs, for example choose between a developer set or desktop set.
Precaution
For a quick installation, we recommend the two scripts at naviserver-openacs. These will install OpenACS from scratch on a variety of systems (including Debian/RHEL Linux or Mac OS X). Detailed dependencies are listed during the build process.
For other ways to install or try OpenACS See openacs-system-install.
Steps for manually installing OpenACS
We recommend installing only the OS to minimize the chances of conflicts resulting from installing 2 or more copies of one of the OpenACS system components (openacs-system).
Many additional programs, such as a build environment (gcc), Mail Transport Agent (MTA), and source control system, are also needed for a fully operational installation. Most of these are included with a basic OS installation.
Install some helper software
You might want to install some of these after a minimum OS install, since OpenACS administration usually assumes you have these (or alternates) installed:
- wget
- emacs or vi/vim
- bash shell (usually automatically installed with Linux distributions)
- gcc or equivalent (along with standard distribution source libraries) - if you plan to install software from source.
- ImageMagick or GraphicsMagick - used by some packages for server side image processing
- aspell - used to offer spell checking in forms
*nix install guides
some helpful documentation for installing *nix flavors
Next, secure your system: system-security
Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 10:36 AM
The OpenACS Documentation is organized as follows:
- Core Documentation ( 1:1 direct copy of what exists )
- Package Documentation ( 1:1 direct copy of what exists )
- Subsystems Documentation ( systems multiple-perspectives view )
Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 29 Jun 2017, at 10:33 AM
This is Approach 3 of the en:Documentation_Project as defined in en:Documentation_Project_Discussion.
Official documentation will go into openacs.org/test-doc (to be renamed) generate from there the html pages for documentation, therefore the first result is to update the documentation to reflect current tools, version, correct commands, all done within that wiki instance
The process for generating technical documentation is:
- Update that documentation wiki instance named doc-head
- Once the documentation is ready, freeze it doing a export/import process from /doc/head to a new instance (i.e. /doc/5-5-0)
- No write permissions for the public will be granted to this frozen instances
- Use an alternate template to distinguish between /doc/head and the frozen ones
- Generate the static html documentation based on the wiki-frozen instance (/doc/5-5-0)
- Using as template_file the view-oacs-docs
- Available here: http://alice.wu-wien.ac.at:8000/xowiki/listing?m=list
- Have to be placed on www dir of xowiki package
- Also the parameter top_includelet have to be in blank for the wiki-frozen instance
- Example on how the doc will be available in the wiki-frozen instance: http://alice.wu-wien.ac.at:8000/test-doc/for-everyone
- Options for the static content:
- One large HTML file and/or (book-print prototype)
- One HTML file per chapter and/or (tutorial-advance prototype)
- Same granularity as in /doc/head
- Get the documentation using wget
- The html files will not have an extension, this may cause them to not be interpreted as html and returned as plain text on some web servers, to be safe, rename the files to have an extension. Run the following script on the directory containing the static html files.
- Commit into the CVS, branch and tag appropriately following the branch/tag conventions for the specific release.
- Add a link of this new /doc/5-5-0 into online documentation index openacs.org/doc and a map it in the site map to /doc/current
Then the process can start again for the next documentation release.
To-Do
Still missing a way to transform to independent html files with index / navigation within it (right now only produces a one big html). (done by Gustaf)- New /doc has to have a link to the various online (xowiki) frozen versions of the documentation.
- Document the document formatting/markup rules in the wiki instance and the static documentation.
- Probably there is already formats for technical documentation available, produced, or at least some guidelines.
- Openacs.org/doc will be replaced with the wiki-documentation (/test-doc instance renamed to /doc/head)
- Provide an index to link to all frozen documentation releases.
- Current /doc can be renamed to /doc-5-1
- Assign someone to udpate the documentation, follow the process and release documentation.
Following moved to this context, which is using approach discussed by Malte below:
Malte here:
Instead of doing it manually (though this does have some merit), I would go and modify the script Gustaf provided to import the whole documentation in one go into a new XoWIKI instance with the structure (page_order) that has been added in XoWIKI 0.42 taken from the chapters of the documentation so that we do have an exact mirror of the documentation as it stands now.
Once this is achieved we could go on and assign categories to the documentation, allowing for an alternative view on the documents (so you could say "instead of showing the whole documentation only show the documents for a specific category"). Probably this needs some more detailed discussion with Gustaf finding out how this could be achieved in XoWIKI and what would make most sense. Ideally we could provide a different structure based on the target group (e.g. category) but this is probably shooting too far. Getting categorization and page ordering in a decent shape should provide us a lot of possibilities.
- One can use the follwing script to generate the page objects and load it via xowiki/admin/import into an xowiki instance; this can be improved in many places, but gives you the idea
- # by Gustaf Neumann
- # load doc pages into xowiki -gustaf neumann
# for tdom
lappend auto_path /usr/local/aolserver4/lib
package require tdom
package require XOTcl; namespace import ::xotcl::*
package require xotcl::serializer
set docpath /usr/local/openacs-4/packages/acs-core-docs/www/
namespace eval ::xowiki {
Class create Page -parameter { {lang en} {description ""} {text ""}
{nls_language en_US} {mime_type text/html} name title text }
set c 0
foreach docpage [glob $docpath/*.html] {
set f [open $docpage r]; set data [read $f]; close $f
dom parse -html $data doc
$doc documentElement root
set content ""
foreach n [$root selectNodes //body/*] { append content [$n asHTML] \n }
set p [Page create page[incr c] -name en:[file tail $docpage] \
-title [[$root selectNodes //title] asText] \
-text [list $content text/html]]
puts [::Serializer deepSerialize $p]
}
}
Suggestion by Rob Taylor:
1a. Move all but maybe the first and last 2 items from https://openacs.org/doc/dev-guide.html to https://openacs.org/doc/kernel/dev-guide.html and refer to them in context of the kernel package (or whatever package their code is in). That helps developers see appropriate context. (This will likely require a board discussion and TIP
Created by Gustaf Neumann, last modified by Benjamin Brink 29 Jun 2017, at 04:35 AM
See: The OpenACS Directory
Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:34 AM
See Also: openacs-release-status openacs-todo
Next Meeting: 2010-04-28 18:00 CET/CEST Convert to your local time
Agenda
- Next OCT Election (May 2010)
- OpenACS 5.6 Release Beta Weekend 2010-04-25
Previous Meetings
2008
Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 29 Jun 2017, at 04:32 AM
Agenda:
1. Zen vs. acs-core
1.1. Site master template will have to be changed to be compatible with package changes for zen
In particular content pages need to be wrapped in <div class="main"> (or id= or something)
Solution: we do <div class="main"><slave></div>
1.2. CSS
Don propose we duplicate CSS at the moment rather than try to integrate .lrn zen theme css and core - our schedule's tight as tight can be and this would be faster
Someone has to do it (next meeting we'll determine who does what and probably the overall work plan)
Change to be done in oacs-5-3.
Sharing a single css file comes for 5.4
2. oacs 5.3.1 release
2.1. The zen work above
2.2. Greek translations
2.3. Nothing more other than critical bug fixes that hopefully are well-tested
2.4 Target date: 1st. march alpha.
2.5. NOTICE: people who upgrade existing sites will have to change their layout! To what extent is something we have to figure out in the next OCT meeting.
2.6. To work on the layout enhancements:
check this page:
signup for something
contact: honchos@dotlrn.org which is the people leading the effort.
.lrn mtg every tuesday at 1700 GMT
2.7. We don't have time to deal with UI clean-up for 5.3.1
Present: lee, don, dave, roc.
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.
Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 04:28 AM
See: OpenACS News Section
