It's an odd choice of distribution I admit (Scientific Linux) but it wasn't my
choice in this particular situation, so I just ran with it. As far as I
understand it, it's basically RHEL recompiled so hopefully this will be useful
for others.
I mostly want to document what I've found somewhere public for people to google
for - it might save people some time if they try and follow along, as it took
me a while to figure all this out. Some of it might be obvious to people more
familiar with Zope, Postgresql, python, etc but it wasn't to me at the time! I
don't mean to be an ass about it but I definitely think there's room for
improvement in the install process - especially with troubleshooting/error
reporting :(.
If you aren't having trouble installing groupserver then you can skip to the
end, I have a question with one of the remaining problems I have that I would
appreciate some help on :).
Anyway! here's what I've found, looking back over my notes of what I've
encountered:
1. A very minor note but redis wasn't in the yum package manager for me, that's
quite possibly a scientific linux specific thing if they have their own package
sources (I come from a debian background so I don't really know!). I just
downloaded, built and ran it from http://redis.io/download so don't be afraid
to get your own redis install.
2. the postgresql config lives in /var/lib/pgsql/data/. I couldn't run
createuser as root (possibly because auth was IDENT by default - see below), I
had to sudo to postgres like so:
sudo -u postgres createuser -D -S -R -l gsadmin
and similarly for the database creates. Otherwise it worked OK. Side note: if
you ever need to restart the installation from scratch (you probably will when
it breaks) then make sure to drop these databases to get back to a clean slate.
I would - up front before doing anything else - make sure that you can log in
with psql on the command line to the database users you create. I found that
IDENT auth didn't work well later in the process, so try switching to password
auth. You can do this by modifying /var/lib/pgsql/data/pg_hba.conf and changing
the 'ident' in the METHOD column at the bottom to 'md5'.
3. I got the error "Error: Couldn't find a distribution for
'buildout.dumppickedversions'." when running buildout initially. From running
tcpdump I found that buildout seemed to be requesting
http://eggs.iopen.net/groupserver/cache/buildout.dumppickedversions/ which
doesn't exist (only the .tar.gz files up one directory). I found that
commenting the index= line in buildout.cfg fixed this, and the other lines
find-links= and allow-hosts= meant that it still only used packages from
iopen.net. If you allow packages from elsewhere it seems to get itself into
dependency hell, so make sure you don't comment the find-links and allow-hosts
lines.
4. A thing missing from the install docs 4.4.1 on RHEL instructions -
gs/recipe/createtables/setupdb.py assumes you are running gs_install_ubuntu.sh.
It relies on a PGPASSFILE environment variable being configured as in the
script (you can see how it's set up by opening the .sh) to auth to psql. If
that is missing you will just get weird errors that look like your database
settings are wrong, when in fact it's just not providing a password.
5. Note also that the createlang line from the gs_install_ubuntu.sh script is
required although it's not mentioned in the RHEL steps, so you should run that
manually before running buildout.
6. This one is the most annoying as you can't work around it easily. It seems
like there is some problem with the smtp authentication setup. Everything in
config.cfg and instance.cfg seem to use the variable "smtp_user". If you change
this then some of the python scripts seem to break so its name is important.
The reason I mention changing it is because there is a script that writes out
parts/instance/etc/gsconfig.ini and it writes out 'user' under the [smtp-on].
I'm not sure if this is separate or related to the naming of the config.cfg
variable. This breaks, however, as 'user' isn't valid for the script that
expects to read this ini file (or something like that, I couldn't quite tell)
and in fact it needs to be username.
Because groupserver breaks if it's unable to send an email during installation
(which to me seems kind of bad) the only way around this I found was to pause
the buildout process after the ini file is written, modify it, then continue.
7. As an aside, would it be possible to please expose the xverp= parameter in
this ini file to the config files somewhere. If your email server doesn't
support verp then the email fails and see above about what this does to the
groupserver installation.
8. A couple more scientific linux/RHEL notes: if apache refuses to proxy to
your zope install with 'permission denied' errors, try setsebool -P
httpd_can_network_connect 1 as selinux might be disallowing the proxying. Also
if you can't connect to the box from the outside try opening 80 and 8080 in
iptables as they might be blocked by default.
choice in this particular situation, so I just ran with it. As far as I
understand it, it's basically RHEL recompiled so hopefully this will be useful
for others.
I mostly want to document what I've found somewhere public for people to google
for - it might save people some time if they try and follow along, as it took
me a while to figure all this out. Some of it might be obvious to people more
familiar with Zope, Postgresql, python, etc but it wasn't to me at the time! I
don't mean to be an ass about it but I definitely think there's room for
improvement in the install process - especially with troubleshooting/error
reporting :(.
If you aren't having trouble installing groupserver then you can skip to the
end, I have a question with one of the remaining problems I have that I would
appreciate some help on :).
Anyway! here's what I've found, looking back over my notes of what I've
encountered:
1. A very minor note but redis wasn't in the yum package manager for me, that's
quite possibly a scientific linux specific thing if they have their own package
sources (I come from a debian background so I don't really know!). I just
downloaded, built and ran it from http://redis.io/download so don't be afraid
to get your own redis install.
2. the postgresql config lives in /var/lib/pgsql/data/. I couldn't run
createuser as root (possibly because auth was IDENT by default - see below), I
had to sudo to postgres like so:
sudo -u postgres createuser -D -S -R -l gsadmin
and similarly for the database creates. Otherwise it worked OK. Side note: if
you ever need to restart the installation from scratch (you probably will when
it breaks) then make sure to drop these databases to get back to a clean slate.
I would - up front before doing anything else - make sure that you can log in
with psql on the command line to the database users you create. I found that
IDENT auth didn't work well later in the process, so try switching to password
auth. You can do this by modifying /var/lib/pgsql/data/pg_hba.conf and changing
the 'ident' in the METHOD column at the bottom to 'md5'.
3. I got the error "Error: Couldn't find a distribution for
'buildout.dumppickedversions'." when running buildout initially. From running
tcpdump I found that buildout seemed to be requesting
http://eggs.iopen.net/groupserver/cache/buildout.dumppickedversions/ which
doesn't exist (only the .tar.gz files up one directory). I found that
commenting the index= line in buildout.cfg fixed this, and the other lines
find-links= and allow-hosts= meant that it still only used packages from
iopen.net. If you allow packages from elsewhere it seems to get itself into
dependency hell, so make sure you don't comment the find-links and allow-hosts
lines.
4. A thing missing from the install docs 4.4.1 on RHEL instructions -
gs/recipe/createtables/setupdb.py assumes you are running gs_install_ubuntu.sh.
It relies on a PGPASSFILE environment variable being configured as in the
script (you can see how it's set up by opening the .sh) to auth to psql. If
that is missing you will just get weird errors that look like your database
settings are wrong, when in fact it's just not providing a password.
5. Note also that the createlang line from the gs_install_ubuntu.sh script is
required although it's not mentioned in the RHEL steps, so you should run that
manually before running buildout.
6. This one is the most annoying as you can't work around it easily. It seems
like there is some problem with the smtp authentication setup. Everything in
config.cfg and instance.cfg seem to use the variable "smtp_user". If you change
this then some of the python scripts seem to break so its name is important.
The reason I mention changing it is because there is a script that writes out
parts/instance/etc/gsconfig.ini and it writes out 'user' under the [smtp-on].
I'm not sure if this is separate or related to the naming of the config.cfg
variable. This breaks, however, as 'user' isn't valid for the script that
expects to read this ini file (or something like that, I couldn't quite tell)
and in fact it needs to be username.
Because groupserver breaks if it's unable to send an email during installation
(which to me seems kind of bad) the only way around this I found was to pause
the buildout process after the ini file is written, modify it, then continue.
7. As an aside, would it be possible to please expose the xverp= parameter in
this ini file to the config files somewhere. If your email server doesn't
support verp then the email fails and see above about what this does to the
groupserver installation.
8. A couple more scientific linux/RHEL notes: if apache refuses to proxy to
your zope install with 'permission denied' errors, try setsebool -P
httpd_can_network_connect 1 as selinux might be disallowing the proxying. Also
if you can't connect to the box from the outside try opening 80 and 8080 in
iptables as they might be blocked by default.