Forum OpenACS Q&A: Not a Question but thanks to OpenACS team

Ok Ok sorry for filling this bboard with something that not very useful.

I again installed OpenACS 4 for the X dozen times, I have noticed
something great!  I would like to that guy who put the option in the
APM install page to uncheck all the boxes.  Small effort but big help!

Since I am on a thanking mode.  I would also like to thank DanW for
fixing the errors on data model loading in the install.  No more
warnings or errors on cms and workflow on Oracle.

Again thanks.  I knew I made the right decision in using OpenACS 4
rather than ACS 3.x .  Thanks!!!!!!!!


Posted by Don Baccus on
Hey, that was me, glad you like it.  Those checked boxes had been bugging me for a long time, and earlier this week Dan grumbled about them, too.  So I decided it was time to do something about it yesterday.

It's tremendously useful having someone using the toolkit for a production site.  Keep coming at us with feedback and bugs, it helps a lot.

Posted by Jun Yamog on
Thanks Don for making that change.  The site that I am working on is
not yet production but it will soon be.  Maybe the same day as OpenACS
4 goes alpha.  I have been updating my CVS almost everday and nuking
the DB about once a week. =)

Also to add the permissions UI has changed.  It used be the
inheritance is from the main site rather than the subsite.  I hated
that.  And I think by only listing the rights for that object, you dont
grant by accident bboard create on a file storage module.  That UI
update is a good
one too.

JMarsden is working on a non interactive install of the OpenACS 4.
Would anyone know if it can also non interactive install packages?
That would be great to install also the packages that you need rather
going to the APM.  Although that would make the "uncheck all boxes"
not that useful =)

Posted by Don Baccus on
One thing we've discussed is implementing a way to replicate a given installation's package set.  The notion is that once you've finished implementing your staging site, you'd like to have a simple and error-free to not only install and enable the packages involved, but also the subsite instances (i.e. mount points) and parameters.

You can dump and restore the database, of course, but ... you also end
up with reams of bboard posts saying "test!" "Testing again!"  "Damn, it broke, testing again!" etc etc etc that need to be wiped and cleaned out, along with test users.  If you've been doing intensive testing, you'll probably re-install and rebuild the structure from scratch, which is tedious and leaves room for error.

So a clean way to replicate the structure while leaving the trash behind would be nice.  This would also be useful for bundling pre-configured vertical application suites ...

Posted by Jun Yamog on
That would definitely be needed.  I think it was lacking since ACS 3.x
What we used to do in ACS 3.x is that.  For each incremental SQL
change that we did we kept a SQL file to run.  After about a period we
then compiled these SQL files into one install SQL file.  We then run
this SQL file after the bare installation.  It was not that effective.
As sometimes the complex changes in the database such as ecommerce
module was done in the admin interface.

I wonder what is the best way to solve this.

Maybe if we have the packages record the SQL calls.  Here is how it
goes.  You have to install a bare OpenACS then maybe on the config
file of aolserver there is a flag say called acs_record_steps.

You then do you interactive stuff on the admin, create folders in the
files storages ,etc.  When DB calls are made and if the package
supports it then writes a log of calls to the database.  Of course
each package has to be acs_record_steps aware.  For example file
storage records the folder name you create but does not keep the
folder id.

After you are done turn of the OpenACS and run this log to a bare
OpenACS site.  So basically it runs everything that you have done

This approach may have its benefits:

- flexible enough for each unique needs of a user and each unique
behaviour of a package.  After all its the package author who should
be aware what stuff is needed to create and what do discard.

- can be applied on a module basis.  you can just record on a single
module then run it on another site as if you administered it


- prone to human error.  Your error is recorded too and replicated
to all the sites that you run the record log.

- Each package must be aware and implement it.

- Time consuming on the first time especially if the site has lots of
state to save.  You have to go to each step the first time.


Possibly create an uber script that saves the states of all known
packages.  No work for the packages authors but a great technical feat
on who can do this uber script/dumper.


Have each package give a set of scripts to store state.  Although the
first one is more flexible.  It might be possible that the author has
not thought of all cases how his/her package should be saved.

Any other ideas on how to save the ACS state?

I think this is very useful.  Especially for sites that relies on CMS.
In the old days just copy the html files from staging to live.  How
about in CMS?  Upload the file, go through the workflow, publish it ,etc.

Posted by Jonathan Marsden on

Right now the non-interactive installer just does what the interactive one does -- that is, it installs only the packages tagged as being part of the core.  That's what it was supposed to do in ACS4, and I pretty much just ported it to OpenACS4 and stopped there.

Like you, I want to be able to install some more packages than that "out of the box", so I'll probably extend it to be able to install a set of additional packages too.  Stay tuned.  That's taking a back seat right now to minor non-porting stuff I'm doing to try and help with the first ever OpenACS 4 (pre-)alpha release.  But it is definitely something I plan to do a bit later on.

Once Don commits my changes to auto-install.tcl, if you or anyone else want to try it out and tell me whether it works as well for you as it does for me, that would be useful.  All you do is point your browser to http://yourhostname/auto-install when you first bring things up... that sets a somewhat useless set of default info for the system, but you can change that with a set of parameters to the script to suit your needs.

Funny about unchecking the boxes... I have a little installer script that would rm -rf the packages I was not interested in, so they don't show up at all in the APM 😊  That way I can do "my" install by *leaving* the boxes checked!

Posted by Don Baccus on
Oh, I committed this yesterday or the day before.  I didn't realize I was supposed to tell anyone, sorry!
Posted by Jonathan Marsden on
I think we're confused, and it is probably my fault...

Don, I just emailed you a patch file that fixes up auto-install.tcl and creates the relevant auto-install*.xql files too.  I thought I had sent it you a day or two ago, but it looks like that one escaped!