I think the minimum install requires PostgreSQL, AOLserver and OpenACS. I can't imagine it takes more than an hour to get all of that installed, even if you compile PostgreSQL and AOLserver from source.
So it seems the problem is the large number of steps. I think different people have worked out scripts to automate much of that. I haven't personally used the install doc in quite some time, so I admit I am not that familiar with all the steps.
The large number of steps came about because we tried to be very detailed in the instructions. The intent is to make it easier.
Yes, it's a lot of steps to do manually. The solution is to use binary packages and scripts that take care of installation.
I don't know what the state of RPMs and DEBs for OpenACS are. I know there are good AOLserver Debian packages out there, and I remember Gentoo ebuilds too. I think I remember someone mentioning having created OpenACS RPMs as well.
So perhaps we could write a script that would download the binary packages, install them, and setup the configuration according to some answers. Debian packages have this capability built-in, but RPMs don't. Don't know about ebuilds.
Then someone could put together a Windows installer, but that would require making OpenACS PostgreSQL 8-ready, since it's a lot harder to install PostgreSQL for cygwin.
Luis, would you like to take on the lead on making this happen?
P.S.: Luis, just a suggestion, it's a good idea to put some paragraphs in what you're writing to aid readability
Although there are many pages in the install documents, any one installation uses maybe 15% of it, with the remaining instructions having to do with platforms that do not concern the trial installer. Filtering through these various versions is a real hassle; I still get confused by them sometimes.
Perhaps we should explore re-arranging the installation docs to something like this:
1. Description of an installed system with no platform specifics, ie. a summary.
2. Generic install instructions for a unix system, including description of a reference platform
2.a notes for installing on a RedHat linux system
2.b notes for installing on a SuSE linux system
2.c notes for installing on a Debian linux system
2.d notes for installing on a FreeBSD system
2.e notes for installing on a Solaris system
2.f quick loading demo knoppix
3. Generic install instructions for a MacOSX system, including description of a reference platform
3.a notes for installing on a X 10.3
3.b notes for installing on a X 10.2
3.c notes for installing on a X 10.1
4. Generic install instructions for an MSWindows system, including specifics of a reference platform
4.a notes for installing on an XP
4.b notes for installing on a Windows2000 platform
4.c notes for installing with VMware
That way, installation amounts to following recipe instructions for a particular platform, and if there is a problem, more help is immediately available by comparing with a reference platform description.
I will gladly help with this.
So actually, I don't think more docs are really going to help and Luis is right. It may take a week or more to install openACS if you -while building the platform- go wrong somewhere. There is so much to learn when you are forced to solve a problem during installation. New instructions won't help in my opinion.
I've used the documentation quit a bit. If I follow the instructions, it will take me a morning to install everything. Joel's "cut'n paste" blocks really cut down the time needed to install. Still I'm much happier with the FreeBSD installer (download, 'make install', go drink coffee, return and experience openACS). We need an installer that prevents users from going wrong in the first place. Luckily it seems to have priority: http://openacs.org/forums/message-view?message%5fid=251367
Aldert, where do I find Joel's "cut 'n paste" and the FreeBSD one? I just need to make the new version run by Thursday.
Something like this is what we need: http://www.ncs.gr/openacs/
That and the idea of the FreeBSD someone is already doing. That's it! Just make it run, go have a coffe and come back to enjoy OpenACS! That's what I'm talking about.
I don't think adding more documentation to the current one would help. It will just rearange the set of instructions in a different way... and please, correct me if that is not your vision.
Please, make sure every body sees and tries this:
This guy did a GREAT job. It took me 5 minutes... yes you read it well, 5 minutes to install the whole thing. I think he is the one who should be leading this project. In a way it is good since I have a new born boy (thank you! :) ) who is consuming my time right now.
The only thing that he needs help with is the Linux and Mac installation. The windows one worked in my Windows 2003 server just fine!
So there you have it.
That means that only people with a license to ZeroG will be able to work on that installer and make future improvements to it.
There are several open source installer builders out there. I haven't worked with any of them, so I can't say how good X or Y are, but relying on a proprietary product doesn't sound like a good path.
I presume InstallAnywhere will become a hurdle, though, and what versions of postgreSQL/TCL/Bison are being used (those take most of the installation time). Is changing versions as easy as changing the config file (and downloading the source)? Can additional scripts be run to add software or adapt installation?
It does look great (and candidate for a micro-grant?) but I'm not familiar with JAVA.
I think we should really look into darwinports (http://darwinports.opendarwin.org/docs/ch01s03.html) since that would offer full flexibility (except for windows?). Is there anybody that has tried it and do we have a "general" OCT opinion about demo's and full server installers (graphical installer, ports, RPM, knoppix etc..)?
It seems Vlassis got stuck with Linux development in August '04 due to his MSc dissertation and less experience with Linux, but I could be wrong. A graphical installer is probably a good user experience, but I haven't tried it (yet).
> ...a week...
It does not take a week to have a running system: it might well take much longer and, just to witness an extreme case, I happen not to have been able to install it at all. How was it possible? Well, you all are supposed to be smart, skilled, informed, trained, and have plenty of time. In my case, I'm just an ignorant.
OpenACS (ACS, actually) was originally built, and meant to be used, by active and proficient developers. And things still are the same, now: which means that, unless you are a developer, and rather practiced, you cannot adopt OpenACS, probably. Daemontools, tDOM, Linux, regular expressions, AOLserver, tcl, PostgreSQL, OpenFTS, qmail, and tons of other quite technical things... It's a wonderful tangle. By the time I started learning something, things changed, versions evolved, and I had to start from scratch again. At every step the path splits in two, and then branches again, and again, and you find yourself asking things through the net, and studing the most disparate things,... You might laugh at me for I've not even been able to install debian by myself. But this is not the point, here.
I experienced, right in this place, the most kind and helpul people. Nevertheless, I am forced to admit that the most basic requirement for the toolkit is still lacking: an easy install. And, writing "easy" I just mean that. Such a point of view is quite possibly not fully understood by the many of you who are computer expert.
Today, many tools have been shaped to allow *everybody* (literally) to run a richly featured database-driven site.
OpenACS is maybe sound, no doubt better than other products, but it seriously risks to left behind. It risks to be left to an élite. I am afraid that Luis Garcia was quite right.
P.S. Some may ask why I'm still here...
One feature of the extremely detailed install documentation is that you get to set every aspect of the installation yourself. That is compile the applications from source, create users to own those applications, decide where they will be installed.
THat is a huge amount of work, and often not necessary if you can install the application from an RPM, DEB etc..
So I think it is worthwhile to emphasize that if you install PostgreSQL, installing from a package is fine etc. Having packages for all the requirements is even better, and having a package that brings them all together is the best.
I would prefer a debian package that requires all the others instead of a Java installer. Same for any other distribution. I think even OS X has some sort of package manager. For windows, the Java installer is a great idea.
I agree with Roberto in that point. If you have to pay a license fee then you loose the "Open" part of the name right there. But what that shows is the concept of what has to become. It must be that easy. Otherwise, like Luigi explains it, you are at risk of extinction; so you must evolve.
Guys, I don't keep statistics of how many times this application is downloaded etc., but it may be interested to see how many times this thing was downloaded 2 or 3 years ago and nowadays. I can see something though since the last time I visited and downloaded OpenACS. It was at the beginnings of 2003 (March I think) and that was version 4.6.X or so, maybe an earlier one. Back then I remember seeing the number of members you show on the front page, and please correct me if I'm wrong; but I think it was about 8K... which is about the same number there is nowadays... So, I guess at some point you may have lost steam.
The documentation is very very good. And manually skipping some parts, following the different needs, is not a problem.
Please keep the documentation the way it is, well detailed, for it is useful, really. [Implicit thanks to those who wrote it.]
Maybe turning it into a wiki, or taking serious note of comments at the bottom of every page (by automatically opening a ticket, perhaps), could help improve the whole thing. Let me make a plain example about it, just one, small: please give a look at page http://openacs.org/doc/openacs-5-1/individual-programs.html, one of the most basic pages. You will find a rather long list of software (by the time you finish reading it, you are already upset, as a beginner). But then, look please, you reach the very bottom of the page and read the comment that Eric left more than six months ago...
What does that comment mean? Is the documentation really wrong? If so, I'm lost in a nightmare. Or is the comment wrong? And nobody in this community took care of pointing this out after more than six months, by writing a second comment, or deleting Eric's one? Do you know what this mean? It means that the newcomer has to start and find out by himself where the bug is...
Quite negative. Overall, it also gives a very bad impression to the newcomer.
> I would prefer a debian package... -- DaveMe too.
The problem with the installation process was identified as the one of highest priority in the recent dotLRN board meeting. There is another thread like this in the dotLRN forum
I think some solutions are getting close to what we need. We need to finish them up: meaning they should be well tested, run in several platforms and be maintained. e-lane has also made some contributions with the debian distro and the Knowppix CD. But we need to identify the solution and advertise it in the home page and docs.
The consortium would probably fund some development if needed.
I'll throw in another interesting approach: InstallBase or Bitrock.
InstallBase (TK based with BSD license):
And maybe get its major developer Damon Courtney involved?
"About: InstallBase MPI is a multi-platform GUI installer designed to work on Windows, Mac, and virtually any flavor of Unix/Linux. Using a full-featured, easy-to-use install builder, it builds a single binary executable for each platform that can be easily distributed without any other third-party ibraries or applications. The install is entirely self-contained."
"Each pane of the install can be completely customized, right down to the actual code that creates it."
Bitrock (if it suits the need). A proprietary product but with free licences for opensource projects:
Maybe a text mode (also/only) installer is the best choice. Though I do not have direct experience, I've heard that servers might not have X-something installed.
And also, text can more easily be reproduced and commented in documentation, forums, verbal questions, irc, emails,... There will always be some need for this
If I may ask, what is the intended audience for this installer? Here are some potential users to consider:
Who is willing to put this on the OCT agenda?
Is anybody aware of a better online TK-howto except for this one:
What would really help is if a few people came forward and said they could give X number of hours a week to make this happen. Then we can all coordinate our work and solve it.
GAH! the install docs still say you need to install bison... This is not the case unless you're installing from a CVS checkout of PG or you've hacked the PG parser yourself (which I doubt anyone here has a need to do)...
It's been removed from the list of required software, but can someone with CVS commit remove the "Install Bison" section from Ch. 3 of the install documentation?
The real problem I'm focussing on is the anarchie in the community that will result in nice packages/suggestions (xcms, projectmanager, ams, xotcl-rm/core, installers, knoppix, new portal, documentation, templates, UAB, patches, chat, mail, etcetera) but the lack of central guidance. We never know what the status of packages/bugs/patches/suggestions/release-plans are or will be, or even who to talk to.
I am asking OCT to set direction concerning installers. Where should the community focus on and how. I or somebody may invest time on darwinports for the community, but this is useless once the community decides to go for rpm's, GUI or something else. Similar, I know we have "workerbee" bugs but patches often don't get applied? Maybe because best practices are unclear.
I don't pretend to have a solution, nor do I say that someone needs to do a better job. I'm just stating that the current process inhibits consistent progress. Anarchie is fine but we need that "roadmap", certainly a "best practice example package" and a maybe a discussion whether the dotWRK approach of spreading efforts is worth following.
Probably move Ch 3.3 to Addendum B if Bison isn't required for postgreSQL tarballs.
I've just posted it in the "Will Dr. OpenACS survive?" forum. We've got a wonderful Windows installer based on the free Inno Setup. We've copied the basic infrastructure (CygWin and PostgreSQL on CygWin) directly from Vlassis. To try the installer please checkout my "Project/Open V3.0.beta4 Release" posting (http://openacs.org/forums/message-view?message%5fid=273854). Just press "Next" a few times and you are running OpenACS on a Windows 2000 machine within ~12 minutes. No XP nor 2003 yet, but coming soon.
Here is the copy of the text from the other posing:
The P/O installer is based on the free Inno Setup, as oposed to the installer from Vlassis Rizopoulos which is based on the proprietary InstallAnywhere. Both installers include CygWin, together with PostgreSQL 7.4.3 on CygWin. This way, you can distribute everything in a single binary. No need for an extra PostgreSQL 8.0 installation, except that the CygWin version is a bit slower and doesn't support searching (yet). But that are no issues for trying out the software.
Also, our P/O installer still contains an entire DotLrn installation, which came from Vlassis. I haven't tested the DotLrn installation recently, but it should still still ok. I guess it's only a few hours of work to include the latest DotLrn version.
We would be very, very happy to share the installer (and part of the testing work...) with the community. Inno Setup supports preprocessor directives, which could allow us to build installers for both DotLrn and Project/Open from the same source file.
The installer source is included in the ProjectOpen-3.0.beta3.Wininstaller.exe file and will install if you select the "Installer Source Code" option during install.
If you're interested, please contact me (at the other discussion, please) and I'll setup a chat or a Skype online conference for a hands-on session with the installer.
Same goes for .LRN. With each release of .LRN we need to get a new installer for .LRN, that installs .LRN out of the box. No other software should be included.
Then, with the documentation hopefully provided by you and the E-Lane folks, it should be possible to custom build certain versions. E.g. the E-Lane project released the version of .LRN they are distributing across the participating universtities. You could provide a distro based on OpenACS that includes P/O. Jeff could make dotKNOW ready to install.
So here are the three things needed:
- Documentation on an easy process for generating the Windows installer.
- Commitment by one person/organisation to generate the Windows Installer for OpenACS after each release.
- Commitment by one person/organisation to generate the Windows Installer for .LRN after each release.
I think we have the commitment for the next two years by the university of Reading to provide the Windows Installer for .LRN (if I'm not mistaken). For the rest it is a different matter.
I work for BitRock. As mentioned earlier in this thread, will be happy to provide you with free licenses for OpenACS. Our installer runs on Windows, Linux, Solaris Sparc and soon, OSX & FreeBSD.
What time investment (please, answer honestly) are we looking at in your estimation, for a newbie (who installed .LRN / OpenACS already) to learn your tool, so he could generate an installer e.g. for OSX?
How are you dealing with the fact that some of the tools we need might already be installed on the system?
Creating a simple installer (copy files, create shortcuts, etc.) is going to take you less than an hour. But in your case, it is going to take you a few days, not so much because the installer itself but because for your all-in-one installer you will be shipping a number of components that need to be built, made relocatable, etc.
Re: some of the tools been already on the system, my advice is that, for a first release, you bundle everything you need in the installer. This will simplify the code of the installer and will give you a controlled environment that will reduce the number of installation issues due to different versions, etc.
On later releases, you could add custom screens and actions to the installer (they can be defined easily in the project.xml file) that autodetect or ask for the location of the different components that may already be installed in the system.
A different approach, used by many of the last generation CMS is to use the installer to install a basic OpenACS system, start it, and then use a web-based procedure running on OpenACS itself to do all the setup (where is Postgres, what is the admin password, etc...)
> I think we have the commitment for the next two years
> by the university of Reading to provide the Windows
> Installer for .LRN (if I'm not mistaken). For the rest
> it is a different matter.
Hi, that would be great news. I think I mentioned it, our Project/Open installer is basicly a port of Vlassis' InstallAnywhere proprietary installer to the free Inno Setup. However, we have maintained exactly the same versions of both AOLServer and CygWin.
We're currently experiencing some nasty incompatibility errors between different versions of Windows without consistent explanation until now. Windows 2000 for example seems to work out in 90% of all cases, while XP gives an error in >50% aparently. Another time we had permission problems in a system that otherwise worked fined. Really strange.
And Windows 2003 server gives us a very new surprise: AOLServer (4.0.beta_10) consistently crashes with the error "Ns_Tls: invalid key 0, should be between 1 and 100). I believe this error has been fixed in a later version of AOLServer. However, the compilation of all of the AOLServer components (nscache, nsopenssl, nspostgres and tDOM) is extremely complex (we tried during about a week to get down to it, but had to give up finally), and it seem that nobody went through this exercise after Jamie Rasmussen in February 2003. I think we would need some serious help from Dossy here.
Vlassis, are you there? What do you think about the situation? Maybe it would be great to know who else is working on this issue.
We also checked Knoppix as a fall-back solution. However, it's a dead end, because it doesn't allow for development. It's really only for running a demo.
thanks for the feedback. Which version of the installer did you run, and on which version of XP exactly (I'd need the service packack and even the build number of XP...)?
Nima and I just had a conversation about the installer. As a conclusion, I have posted a "Windows Installer HowTo" in the forum: