[OPEN-ILS-DEV] ***SPAM*** Re: Evergreen installtion problems--minor issue with instructions

[John Craig]

Dan Scott wrote (in response to Charles's frustrations with installing Evergreen on Ubuntu): <snip> > > what was the trick that made it work on a standard Ubuntu server installation? > Yes. No tricks were required. I would add one caveat here: getting Evergreen to work on CentOS or RedHat is, in my admittedly limited experience w/ these OS's as Evergreen hosts, significantly more difficult than with Debian or Ubuntu. Interestingly, we run all our servers with CentOS or RedHat (Debian and Ubuntu won't work with their disk controllers w/o more fussing than was practical). But CentOS/RedHat serve as the host OS--but (important point), we *always* run Evergreen in Virtual Machines with Ubuntu as the guest OS. At the moment, everything that's up and running uses the Ubuntu 8.04 LTS version. Then, more from Charles:  We do not believe the instructions from the evergreen site are complete.  We think we are missing something simple, but consistantly.   We have tried several  "solutions" found in various Dan's reply: I go through the instructions, step by step, every couple of months. I would argue that the instructions are complete (disclaimer: I'm one of the people who helps to write and maintain those instructions); some users might want more contextual detail (for example, a description of what PostgreSQL or ejabberd are and configuration tips and where it keeps its logs, etc, but that's far better served by the sites for those projects themselves, in my opinion). There is one small mistake in the current instructions for Debian/Ubuntu (which would only affect people working with Ubuntu "Hardy" and is pretty simple to deal with). The instructions at the point of adjusting the Apache2 run user (my apologies if the format below is completely messed up) say that Ubuntu Hardy users should change the the User entry in /etc/apache2/apache2.conf--but, in fact, at least the 8.04 LTS version of Ubunutu Hardy has no such entry in apache2.conf. Ubuntu Hardy actually falls into the 2nd category: you have to edit /etc/apache2/envars to set the user value. I haven't tried Debian Etch is so long, I have no recollection of how it works in this regard and I do not know if the Ubuntu Hardy versions that are not the LTS server version might be subtly different from other Hardy versions. My guess is that this is a characteristic of the version of Apache HTTPD and not the OS, per se and so Etch may, at this point, also fall into the latter category also. But, in my experience this is the only "trick" to getting through the directions--and I've gone through them a lot of times over the last 3 years. 8.    This step is still necessary to keep the logs functioning, but may break other Apache applications on your server. We hope to make this unnecessary soon. Change the user for the Apache server:     I.    Ubuntu Hardy/Debian Etch: As the root user, edit /etc/apache2/apache2.conf:         a. Change User www-data to User opensrf     II.    Ubuntu Karmic/Ubuntu Lucid/Debian Lenny: As the root user, edit /etc/apache2/envvars:         a.    Change export APACHE_RUN_USER=www-data to export APACHE_RUN_USER=opensrf I can second Dan's statement that the main way to get messed up is to assume you can skip a step. Favorite ones to assume you can skip are editing opensrf_core.xml during the Evergreen install--after all, you just DID that during the OpenSRF install, right? Yes, but, the content of that file is now substantially different and you can't use the plain OpenSRF version of opensrf_core.xml to run the Evergreen application (or you won't get the Perl services that Evergreen needs started). Other favorites to assume you can skip include the Apache HTTPD setup steps. Or, for those of us who nearly always install with Postgres on a separate server from the Evergreen app, and almost always have a database already created, is skipping the running of eg_db_config.pl in step 4. (What you do when you have an extant DB you want to connect to is just leave off the --create-schema switch.) Other common mistakes, for me, are doing something via the wrong login. I find I do best if I keep two terminal sessions open and run the commands in the appropriate terminal session mostly by cutting and pasting. (And, by the way, step 13 in the OpenSRF install instructions assumes you are not doing it that way--the exit after the echo "export PATH=..." >> ~/.bashrc is the only place where the assumption that you're using su opensrf from a root session is reflected in the directions--and that can be a bit confusing if you're not using that approach. Given that this is the only place where this pattern occurs, I'd be inclined to omit the exit command there; again, minor.) The script that John Schmidt did some while back (no link to it from the basic instruction page any more) was pretty slick, but no one's kept it up to date, as far as I know. One final suggestion on the install stuff, while we're on the topic, it seems like it'd be worth including an install of the current Bundle::CPAN package at the beginning of the prerequisites script--but that's a really minor thing. John