I'm currently running both versions (but I did not install
openacs with them, but upgraded my running verison of aolserver).
Instructions are available there also. Please test them, beat on them,
and poke them with a stick. If there are any problems report them here
or send me an email (mkovach@alal.com). I'm more than happy to
listen to suggestions and work with packagers to create a easy
"stage 1" installation. With a little work it should not be that hard
to create a relatively painless command line to http://host
installation process.
From the web page:
Currently this is a temporary location for my aolserver distributions.
To make a short story long, I've been looking to add some mime support
for webmail to aolserver (mainly for
OpenACS 4. I've also done some testing on OpenACS 4.
I got a bit frustrated having to download source for the
AOLServer installation so I
packaged
this up a bit. Basically I grapped ArsDigita's AOLserver 3.3.1ad13
removed
some of their stuff, modified things a bit for my use. This is very
specific to the 'way I do things'. I'm open to changes. Just let me know.
I have the following patches applied:
*BSD exec patch
Vinod's ns_uuencode patche
uid/gid from Jon Griffith
Merge some of Vinod's any my changes for nsxml
I've compiled on OpenBSD 2.8 and SuSE 7.3 with postgres. I ran into
some client needs and have not been able to test more. Oracle was
fine before, I don't think I broke it. I should be able to test more
over the next few days unless somebody beats me to it.
Minor changes were needed for nsxml and the postgres driver, all Makefile
related. You may still have to tweak things for your system.
run ./conf-clean this should clean everything up for you.
Simular to the way DJB (qmail,tinydns, etc. author) I tend to keep
files in conf-*.
shag:/home/shag/source/root:23$ more conf-db
postgresql
this can be postgresql, oracle or 'both'
shag:/home/shag/source/root:24$ more conf-inst
/home/shag/aolserver
### Location to install
shag:/home/shag/source/root:25$ more conf-make
gmake
### name for gnu make on your system
shag:/home/shag/source/root:26$ more conf-oacs
/web/oacs
###
Your OpenACS install directory (not used yet)
To build OpenACS with Oracle and PostgreSQL drivers and install it on
/usr/local/aolserver you would do the following:
echo "/usr/local/aolserver" > conf-inst
echo "both" > conf-db
echo "gmake" > conf-make
./conf
./conf will start the build. You must have libxml, postgres, oracle, etc.
already installed. Logs are in log/.
What I would really like to do is create a standard source tree (or trees)
to build the necessay software to install OpenACS. Once AOLserer is
built to need requirements I think we should freeze this code and
work on creating binaries, OS specific packages, and a source tree that
can easily be installed. I can build just about any package format
expect BSD ports (I've just never had too). I'd like to add an
options conf-dist so that package maintainers can all pull from the
same base.
When OpenACS 4 is in beta, I'll add the steps to the config script to
install the OpenACS code in /web/, create a /.tcl
file and show the user the steps to create the database. After that
they should be able to just create the database, start aolserver
and start the install.
Okay, I'm tired. Looking forward to everybody's comments and I really
hope people find this useful.
Well, I've been putting together an AOLServer 3.4.2 port for the
purposes of running OpenACS on
OpenBSD 3.0 (-current, though it should work on -stable).
Feel free to have a look if you're interested in using the ports
mechanism yourself.
At present, it includes the *BSD exec patch, Vinod's ns_uuencode patch,
and Jon Griffith's uid/gid patch. what patches have you made to nsxml
(other than makefile)?
It is still a work in progress as I slog through the installation
process, but I believe it is getting close. If you (or anyone else)
wants to have a look, I'd be happy to hear feedback.
<blockquote> What I would really like to do is create a standard source tree (or
trees) to build the necessay software to install OpenACS. Once
AOLserver is built to need requirements I think we should freeze
this code and work on creating binaries, OS specific packages, and
a source tree that can easily be installed. I can build just about
any package format expect BSD ports (I've just never had too). I'd
like to add an options conf-dist so that package maintainers can
all pull from the same base.
</blockquote>
Well, that's mightily generous AND impressive, Matt...as long as we don't make that a REQUIREMENT for use of OpenACS. (ie, using AOLServer from "our" tree). Take a Debian linux distribution, for example. Debian already HAS a AOLServer 3.4.2 install, managed by a Debian maintainer, included in the standard distribution. I'd much prefer to be able to use the existing AOLServer package, even if I have to use their source package, and patch it. That make sense? I guess I'm just not clear as to whether or not you're trying to make some conveniences (which are great, as long as they don't preclude the "ordinary" use of OpenACS), or a new way of packaging OpenACS to require the use of "our" version of AOLServer (I wouldn't think that would be a good idea...)
No, I don't want to make it a requirement, that would be silly :)
What would be nice is to work worth the Debian maintainer to have
a OpenACS-able AOLserver (maybe a aolserver-openacs-contrib package?).
What I'm trying to do here is have a convience for people and make sure we have a base server that we know works.
It could be possible that down the road a patch is needed for operation of a certain moulde that hasn't made it into AOLserver's code yet. If that happens we can offer an alternative. It is also my hope to have OpenACS -be able- to deliver a fairly easy all-in-one install package to help new people get to working with OpenACS instead of following the install.
I never had the intent of making this a requirement, I simply made it as a convience for me and shared it with everybody else. My hope is that we can use this as a base to -offer- to others.
I don't have enough time to be that power hungry!!!!
Along with the mentioned patches, 3.4.2 needs Henry Minsky's patches for i18n stuff, I think. Check one of the other, recent threads for more info.
Ken ...
Stock 3.4.2 should work as long as you don't need Henry's stuff. Vinod wrote acs-mail to work in the presence of the broken version of ns_uuencode, but the Tcl code involved's very, very slow. But most OpenACS 4 sites aren't going to be sending out large number of e-mail attachments anyway. Those that do, though, need Vinod's working ns_uuencode.
With the stock version you'll also want to upgrade the PG and ora8 drivers (I need to put up my version of ora8 soon). And you'll need to add nsxml.
Mat's work is intended to make it really easy to grab an AOLserver that has all the pieces you need ready to go. It's not meant to require you to use our bundled up copy.
Sweet!! Sounds outstanding. And, to clarify, I didn't THINK that we were trying to go the "required" route...just wanted to check. Mat, kudos to you for doing all that work...you will indeed be making it very easy for a total "newbie" to get up and running with OpenACS. I congratulate you!
On a (somewhat) related note...does anyone know "Eric Van Buggenhaut"? He's listed as the Debian maintainer for openacs 3.2.5 in Debian unstable, but I don't see him in the openacs.org directory. (Also doesn't look like there's been any work on package bugs, etc. recently). I'm in the VERY beginnings of becoming a Debian maintainer myself, so I might be able at some point to sponsor some of the auxiliary packages. But I'd love to hook up with Eric if possible, to see what the deal is...
Matt, a standard source tree to build all OpenACS software like you
suggest would totally rock.
For example, I personally love Debian packages and apt-get, but I
won't use them for anything OpenACS related - I'm responsible for
using many of the same tools on Solaris as well, so I'd rather always
install from sources so my procedures can be the same on both
platforms. And being able to use a canonical "OpenACS and related
necessary stuff" source tree rather than rolling my own all the time
(which is what I do now) sounds very nice.
And of course, using your tree to then generate packages for multiple
platforms would make it an even more valuable resource.
