Forum OpenACS Q&A: OpenACS/.LRN on Apple's OS X Panther

I am going to be reviewing and updating the OpenACS OS X install documentation over the next few days, because I want to promote the use of OS X for .LRN based projects (OS X is a piece of cake to administer, people are not afraid of it in k-12, and Apple's hardware is getting more interesting as time progresses) and I have decided to use OS X for a KMS I am starting to work on.

Any objections to the following additions?

1. Assume OS X Panther
2. OS X developer tools as a requirement to the docs
3. Fink as an install tool so adding things like readline and imagemagick are easier.

Open question:


Posted by Vinod Kurup on
Carl, I think the additions you suggest are reasonable, but I also wanted to mention an alternative to fink. Darwinports is another package management tool for OS X which is based on the BSD ports system. One of its cool features (from our standpoint) is that it's built in Tcl and package-installation scripts (called Portfiles) are Tcl scripts.

Walter McGinnis pointed me towards using Darwinports to install OpenACS on OS X. I posted his instructions on my site and have since spent some time creating Portfiles to simplify the process.

Right now, I can do:

$ sudo port install postgresql +devel +server
$ sudo port install openacs
and I end up with an installation of OpenACS 5.0.4 at http://localhost:8000 under unix-user service0. The OpenACS portfile ensures that all of its dependencies are installed (aolserver, its modules, tdom, postgresql, tclwebtest) and then downloads the OpenACS tarball. Once all the pieces are in place, it runs the cool OpenACS script.

It's not quite perfect yet because I'm having trouble debugging a process-kill/restart problem, so currently, I have to manually restart the process after my install openacs command.

Installing in this way might be a nice way to try OpenACS out, but it's probably not a good idea for a production site, since it doesn't offer many configuration options, it ignores things like setting up CVS, and darwinports (currently) doesn't offer a way to upgrade a package. You have to uninstall the old version and then install the new version.

I've been reluctant to post about this because I haven't had time to work on it and it's still really rough (and probably incorrect in places!). The right thing to do would be to start submitting these Portfiles to the darwinports project, but frankly I've been lazy 😊

I do think recommending daemontools would be useful, but it's currently not available in fink or darwinports, so it would be another manual step.

Posted by russ m on
There's 2 questions I have about running a production site on OSX, and they're both about Postgres. I haven't actually looked into either of these issues, but would want to before deploying on OSX...

Configuring Postgres on OSX with --enable-thread-safety throws an error. Apparently this only affects thread safety of libpq when opening database connections, so if AOLserver opens the pooled database connections in the main thread it's not an issue for us...

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
configure: error:
Cannot enable threads on your platform.
Please report your platform threading info to the PostgreSQL mailing lists
so it can be added to the next release.  Report all compile flags, link flags,
functions, or libraries required for threading support.
See the comment at the top of src/port/thread.c for more information.

Also, there was discussion on the PG mailing lists a while ago (around PG 7.2 / OSX 10.1) that PG wasn't able to shut down cleanly when OSX is shut down - There's no mention of a fix in the Postgres release notes since then, but the problem looks to have been in OSX rather than PG so it may have gone away between 10.1 and 10.3...

Finally, stock PG doesn't correctly build shared libraries on OSX, so everything ends up statically linked. The Fink PG install patches this to work correctly, but the patches don't seem to have made it back to the main PG tree. (I know this isn't really a problem, but while I'm bitching)...

Posted by Andrew Piskorski on
I'm no Postgres expert but AFAIK, you should not be building PostgreSQL with any special --enable-thread-safety switches, unless you're doing it for some bizarre Mac OS-X specific reason. PostgreSQL's thread safety options have nothing at all to do with connecting to PostgreSQL from AOLserver, and never did.
Posted by russ m on
--enable-thread-safety is new in PG 7.4, and is described in the release notes like this -
libpq and ECPG applications are now fully thread-safe
While previous libpq releases already supported threads, this release improves thread safety by fixing some non-thread-safe code that was used during database connection startup. The configure option --enable-thread-safety must be used to enable this feature.
and the install guide -
Make the client libraries thread-safe. This allows concurrent threads in libpq and ECPG programs to safely control their private connection handles.
Since nspostgres gets it's Postgres-ness from libpq, there is a potential issue if libpq is not thread safe and 2 threads silmultaneously try to open connections to the database. I don't know in detail how nspostgres handles recycling database connections, and given that database connections are long-lived in AOLserver it's probably pretty hard to trigger any lossage through this if it's even possible at all, but still...