I'd like to open the question of roles/purposes for our servers again. I'll risk sounding out of touch, just so we can have the conversation. This is on my mind because of the task of moving the wiki into OSGeo-managed infrastructure. John's already got the shell of a wiki instance up for us to use on a Telascience machine, but I'm wondering if we should use one of the PEER1 hosted OSGeo servers instead.
osgeo2 is not being used very much, however it is still critical as a test instance of Drupal and other applications we test before loading onto osgeo1. I suggest we consider hosting some other services on there, in particular the wiki. I would personally feel more comfortable if such a critical service were run from one of our own hosted systems instead. I won't argue about any of the other services on Telascience as everyone seems to be content with the current set up.
I don't have any breathtaking arguments to make my point, but from my own perspective I just feel like our services are spread out maybe a bit too wide and we could be making better use of osgeo2. I'd also rather not segment some of the more critical day-to-day services (such as the wiki) from the rest of the infrastructure.
Managing parts of them has been really easy for me personally, it has helped to have these identical systems so the learning curve isn't steep when moving between them. In the end we have several platforms with some people helping administer various parts on one, but not others.
I don't have any stats on uptime of either PEER1 or Telascience, but am wondering if anyone else does or has a gut feel of stability on Telascience. Should we view it as a stable platform for critical communication tools, like the wiki? I know I'd sure prefer to take out frustrations on Mr. X Hosting Provider rather than see John in a tough spot trying to help us while also doing his 'normal' job
I'm sure there are other factors to consider, and that some of my reluctance may be unwarranted or uneducated, but I just want to get the discussion going. Feel free to remind me of past discussions if I've forgotten any earlier decisions about this.
Any other factors to consider (aside from software versions, etc.) for moving our wiki onto osgeo2?
I would like to see us make better and more organized use of osgeo2.
I wouldn't mind having the wiki there but I'm also fine with having it
on the .220 telascience blade as long as the database is dumped nightly
and backed up somewhere (ie. osgeo2).
Since the mediawiki install on the .220 blade seems to be ready to load,
and since we have limited resources for the media wiki transition, I'm
inclined to just move it there. But hopefully that won't prevent us from
figuring out a better services strategy in the future.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
On Mon, Oct 15, 2007 at 02:28:41PM -0700, Tyler Mitchell (OSGeo) wrote:
I'd like to open the question of roles/purposes for our servers
again.
I know very little about the history of involvement with Telascience
and almost nothing about the discussions that lead to the current setup
at the commercial hoster. So I prefer to refrain from taking a position
on this topic.
Cheerio,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
The original intention of having the two servers was to set them up with
cross-backups and production services on both, so that if one had to be
brought down the other could be turned up with all services running
quickly.
This didn't materialize, and as it stands the second server is just a
test machine. I think that this is a bit of a waste of high-powered
server, and would be happy to see the second server take on some of the
production services. I really appreciate the support that we get at
Telascience, but I would prefer to see services that have a strong
impact on our public image or projects' ability to get things done (SVN,
etc) on servers where we have an SLA. Even if SLAs don't really mean
anything.
If the second machine is not used for production services, I think that
we should consider decommissioning it after our current (two year?)
commitment.
I am not entirely convinced that the wiki falls under this category,
but...
Jason
-----Original Message-----
From: Tyler Mitchell (OSGeo)
Subject: [SAC] PEER1 and Telascience server roles
I'd like to open the question of roles/purposes for our servers again.
I'll risk sounding out of touch, just so we can have the conversation.
This is on my mind because of the task of moving the wiki into
OSGeo-managed infrastructure. John's already got the shell of a wiki
instance up for us to use on a Telascience machine, but I'm wondering if
we should use one of the PEER1 hosted OSGeo servers instead.
On Tue, Oct 16, 2007 at 08:15:56AM -0700, Jason Birch wrote:
If the second machine is not used for production services, I think that
we should consider decommissioning it after our current (two year?)
commitment.
I am not entirely convinced that the wiki falls under this category,
but...
I understand that Tyler considers the Wiki to be one of the relevant
'tools' for advertizing and promoting OSGeo, so I conclude that it
deserves to run on a highly reliable platform.
I also understand that nobody will object this conclusion - the
current discussion is just about: Are we going to move the Wiki to
'osgeo2' _right_now_ (TM) or later in a second step ?
Finally the essence of this question is: Are we going to waste the work
that John already put in setting up a MediaWiki instance on the blade ?
In order to figure if we can risk wasting John's effort we simply have
to determine if there's a sufficiently recent setup of MySQL, Apache
and mod_php on 'osgeo2'. If this is the case, then putting a MediaWiki
onto that machine is not a big deal.
Cheerio,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, Oct 16, 2007 at 06:17:44PM +0200, Martin Spott wrote:
In order to figure if we can risk wasting John's effort we simply have
to determine if there's a sufficiently recent setup of MySQL, Apache
and mod_php on 'osgeo2'.
Doesn't look that bad. Is anyone (feeling) responsible for tracking and
installing security updates on the two machines (osgeo1/2) ? Does
RedHat have a nice, easy to maintain installer/update tool like Debian
has ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
The core of the system is updated via peer1 admin's and a cron script
using peer1's up2date rpm repository. Anything beyond that is a manual
update by us read, anything that wasn't installed via up2date.
Software that was installed via up2date
* apache (httpd-2.0.52-28.ent.i386)
* postfix (postfix-2.2.10-1.RHEL4.2.i386)
* php (php-4.3.9-3.22PIDH.i386)
* python (python-2.3.4-14.3.i386)
* mailman (mailman-2.1.5.1-34.rhel4.5.i386)
Software installed that wasn't available via up2date (either didn't
exist in there repo or wrong version for our needs).
The initial idea was to use as much as possible from peer1 up2date repos
to minimize the effort for updating and patching. But, we are talking
about a redhat enterprise 4 system which doesn't 'always' have the
needed versions available.
shawn
On Tue, 2007-16-10 at 18:40 +0200, Martin Spott wrote:
On Tue, Oct 16, 2007 at 06:17:44PM +0200, Martin Spott wrote:
> In order to figure if we can risk wasting John's effort we simply have
> to determine if there's a sufficiently recent setup of MySQL, Apache
> and mod_php on 'osgeo2'.
Doesn't look that bad. Is anyone (feeling) responsible for tracking and
installing security updates on the two machines (osgeo1/2) ? Does
RedHat have a nice, easy to maintain installer/update tool like Debian
has ?
The core of the system is updated via peer1 admin's and a cron script
using peer1's up2date rpm repository. Anything beyond that is a manual
update by us read, anything that wasn't installed via up2date.
Software that was installed via up2date
* apache (httpd-2.0.52-28.ent.i386)
* postfix (postfix-2.2.10-1.RHEL4.2.i386)
* php (php-4.3.9-3.22PIDH.i386)
* python (python-2.3.4-14.3.i386)
* mailman (mailman-2.1.5.1-34.rhel4.5.i386)
Software installed that wasn't available via up2date (either didn't
exist in there repo or wrong version for our needs).
The initial idea was to use as much as possible from peer1 up2date repos
to minimize the effort for updating and patching. But, we are talking
about a redhat enterprise 4 system which doesn't 'always' have the
needed versions available.
shawn
On Tue, 2007-16-10 at 18:40 +0200, Martin Spott wrote:
On Tue, Oct 16, 2007 at 06:17:44PM +0200, Martin Spott wrote:
> In order to figure if we can risk wasting John's effort we simply have
> to determine if there's a sufficiently recent setup of MySQL, Apache
> and mod_php on 'osgeo2'.
Doesn't look that bad. Is anyone (feeling) responsible for tracking and
installing security updates on the two machines (osgeo1/2) ? Does
RedHat have a nice, easy to maintain installer/update tool like Debian
has ?
It was not a lot of effort to set up MediaWiki
I can always use it for something else
Martin Spott wrote:
Hi,
On Tue, Oct 16, 2007 at 08:15:56AM -0700, Jason Birch wrote:
If the second machine is not used for production services, I think that
we should consider decommissioning it after our current (two year?)
commitment.
I am not entirely convinced that the wiki falls under this category,
but...
I understand that Tyler considers the Wiki to be one of the relevant
'tools' for advertizing and promoting OSGeo, so I conclude that it
deserves to run on a highly reliable platform.
I also understand that nobody will object this conclusion - the
current discussion is just about: Are we going to move the Wiki to
'osgeo2' _right_now_ (TM) or later in a second step ?
Finally the essence of this question is: Are we going to waste the work
that John already put in setting up a MediaWiki instance on the blade ?
In order to figure if we can risk wasting John's effort we simply have
to determine if there's a sufficiently recent setup of MySQL, Apache
and mod_php on 'osgeo2'. If this is the case, then putting a MediaWiki
onto that machine is not a big deal.
It was not a lot of effort to set up MediaWiki
I can always use it for something else
Why not use this machine then? I sort of like the idea that we do not lose everything because one ISP goes down. From what I understand teascience and osgeo2 are fairly independent, even spatially. So if one meteor hits the osgeo2 ISP then we will still have the Wiki on telascience to blog about it and vice versa if telascience breaks we still have the web site.
As most everybody already has one account for the Wiki and one for the rest there is no need to hurry connecting with LDAP (although even that seems like not too large a problem technically anymore).
Best regards, Arnulf.
Martin Spott wrote:
Hi,
On Tue, Oct 16, 2007 at 08:15:56AM -0700, Jason Birch wrote:
If the second machine is not used for production services, I think that
we should consider decommissioning it after our current (two year?)
commitment.
I am not entirely convinced that the wiki falls under this category,
but...
I understand that Tyler considers the Wiki to be one of the relevant
'tools' for advertizing and promoting OSGeo, so I conclude that it
deserves to run on a highly reliable platform.
I also understand that nobody will object this conclusion - the
current discussion is just about: Are we going to move the Wiki to
'osgeo2' _right_now_ (TM) or later in a second step ?
Finally the essence of this question is: Are we going to waste the work
that John already put in setting up a MediaWiki instance on the blade ?
In order to figure if we can risk wasting John's effort we simply have
to determine if there's a sufficiently recent setup of MySQL, Apache
and mod_php on 'osgeo2'. If this is the case, then putting a MediaWiki
onto that machine is not a big deal.
On Wed, Oct 17, 2007 at 02:55:31PM +0200, Arnulf Christl wrote:
John Graham wrote:
>Martin
>
>It was not a lot of effort to set up MediaWiki
>I can always use it for something else
Why not use this machine then? I sort of like the idea that we do not lose
everything because one ISP goes down. From what I understand teascience and
osgeo2 are fairly independent, even spatially. So if one meteor hits the
osgeo2 ISP then we will still have the Wiki on telascience to blog about it
and vice versa if telascience breaks we still have the web site.
This motivation as well as other opinions on this topic are understood.
Yet someone should make the decision - and this certainly won't be me.
Cheerio,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, Oct 16, 2007 at 01:27:27PM -0400, shawn barnes wrote:
Software that was installed via up2date
* apache (httpd-2.0.52-28.ent.i386)
* postfix (postfix-2.2.10-1.RHEL4.2.i386)
* php (php-4.3.9-3.22PIDH.i386)
Any chance to get a PHP5 for osgeo2 ?
Cheerio,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Fri, Oct 19, 2007 at 10:23:32PM +0200, Martin Spott wrote:
On Tue, Oct 16, 2007 at 01:27:27PM -0400, shawn barnes wrote:
> Software that was installed via up2date
> * apache (httpd-2.0.52-28.ent.i386)
> * postfix (postfix-2.2.10-1.RHEL4.2.i386)
> * php (php-4.3.9-3.22PIDH.i386)
Any chance to get a PHP5 for osgeo2 ?
Well, I could always roll my own, if required, but as apparently most
of the stuff had been installed as a package it would be 'sane' to add
PHP5 - preferrably some 5.2.x version - using a package as well,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Fri, Oct 19, 2007 at 10:23:32PM +0200, Martin Spott wrote:
On Tue, Oct 16, 2007 at 01:27:27PM -0400, shawn barnes wrote:
Software that was installed via up2date
* apache (httpd-2.0.52-28.ent.i386)
* postfix (postfix-2.2.10-1.RHEL4.2.i386)
* php (php-4.3.9-3.22PIDH.i386)
Any chance to get a PHP5 for osgeo2 ?
Yes, there is the up2date application to help do it, but I can find where to point it to the package repository that exists on our ISP's infrastructure - as per http://wiki.osgeo.org/index.php/Migration_Documentation - I just don't know how Shawn specifically did it. I'd swear I knew at one point but couldn't find the answer.
Of course, I find the answer right after I send...
It looks like up2date is already configured to find packages off the hosting provider, but php5 isn't in their list of available packages. I'm no pro with this tool, though, that's for sure.
sudo up2date --showall | grep php
Tyler
On 19-Oct-07, at 2:18 PM, Tyler Mitchell (OSGeo) wrote:
On 19-Oct-07, at 1:36 PM, Martin Spott wrote:
On Fri, Oct 19, 2007 at 10:23:32PM +0200, Martin Spott wrote:
On Tue, Oct 16, 2007 at 01:27:27PM -0400, shawn barnes wrote:
Software that was installed via up2date
* apache (httpd-2.0.52-28.ent.i386)
* postfix (postfix-2.2.10-1.RHEL4.2.i386)
* php (php-4.3.9-3.22PIDH.i386)
Any chance to get a PHP5 for osgeo2 ?
Yes, there is the up2date application to help do it, but I can find where to point it to the package repository that exists on our ISP's infrastructure - as per http://wiki.osgeo.org/index.php/Migration_Documentation - I just don't know how Shawn specifically did it. I'd swear I knew at one point but couldn't find the answer.
On Fri, Oct 19, 2007 at 02:24:07PM -0700, Tyler Mitchell (OSGeo) wrote:
It looks like up2date is already configured to find packages off the
hosting provider, but php5 isn't in their list of available
packages. I'm no pro with this tool, though, that's for sure.
I'm not either - and, to be honest, I'm not inclined to become one
It would be pretty helpful if someone who's familiar with this
distribution could at least look if it makes sense to reach out for a
pre-packaged PHP5 on 'osgeo2'. If this proves to surface too many
difficulties then I'd like to add a self-grown PHP5.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
After reading some RedHat discussion it seems this is one of the common places to get them from. But I'll defer to anyone else from SAC who knows better. There are a few dependencies for the package from there though:
$ rpm -i --test http://mirror.stanford.edu/yum/pub/centos/5/updates/i386/RPMS/php-5.1.6-15.el5.i386.rpm
warning: /var/tmp/rpm-xfer.fC9A6t: V3 DSA signature: NOKEY, key ID e8562897
error: Failed dependencies:
httpd-mmn = 20051115 is needed by php-5.1.6-15.el5.i386
libc.so.6(GLIBC_2.4) is needed by php-5.1.6-15.el5.i386
libcrypto.so.6 is needed by php-5.1.6-15.el5.i386
libssl.so.6 is needed by php-5.1.6-15.el5.i386
php-cli = 5.1.6-15.el5 is needed by php-5.1.6-15.el5.i386
php-common = 5.1.6-15.el5 is needed by php-5.1.6-15.el5.i386
rtld(GNU_HASH) is needed by php-5.1.6-15.el5.i386
On 19-Oct-07, at 3:35 PM, Martin Spott wrote:
On Fri, Oct 19, 2007 at 02:24:07PM -0700, Tyler Mitchell (OSGeo) wrote:
It looks like up2date is already configured to find packages off the
hosting provider, but php5 isn't in their list of available
packages. I'm no pro with this tool, though, that's for sure.
I'm not either - and, to be honest, I'm not inclined to become one
It would be pretty helpful if someone who's familiar with this
distribution could at least look if it makes sense to reach out for a
pre-packaged PHP5 on 'osgeo2'. If this proves to surface too many
difficulties then I'd like to add a self-grown PHP5.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/sac
Tyler Mitchell
Executive Director
Open Source Geospatial Foundation
tmitchell@osgeo.org
P: +1-250-277-1621
M: +1-250-303-1831
On Sat, October 20, 2007 00:35, Martin Spott wrote:
On Fri, Oct 19, 2007 at 02:24:07PM -0700, Tyler Mitchell (OSGeo) wrote:
It looks like up2date is already configured to find packages off the
hosting provider, but php5 isn't in their list of available packages.
I'm no pro with this tool, though, that's for sure.
I'm not either - and, to be honest, I'm not inclined to become one
It would be pretty helpful if someone who's familiar with this
distribution could at least look if it makes sense to reach out for a
pre-packaged PHP5 on 'osgeo2'. If this proves to surface too many
difficulties then I'd like to add a self-grown PHP5.
Cheers,
Martin.
Hi,
I think you and _wolf_ are the first in the wider SAC team who do not
immediately groan about having to deal with something PHP.
OSGeo administration has not been keen to maintain PHP a lot or think
about how to upgrade to newer versions. Updating was sort of "deferred
until required" and dependencies have not been looked into. I suggest that
you two propose what to do exactly, send it to WebCom and VisCom and if
nobody objects just go ahead. The same applies to how you do it. If you do
not like using up2date and there is nobody else who really does - then do
it the way you like it.
If it's not in Peer1's Up2date repository then it has to be a roll your
own or finding an rpm for redhat enterprise 4. Unforunately i don't
think there is an 'official' rpm for rh4el and as you've noted the
dependencies are pretty extensive. I'm not a redhat guy (gentoo is my
preference)...and find it to be painful to run the latest version of
anything on it...but, it's purpose is stability not leading edge.
The versions of software on the systems are not set in stone...they are
there b/c of the ease of installing from the peer1 up2date repo and the
short migration timeline we had when initially setting up the system.
So rolling up a php5 is fine as long as the rest of SAC is ok with it.
I usually have a preference of rolling my own because you can tweak for
speed or your own needs instead of installing the distro's one size fits
all....but, there definitely has be a standardized way of doing things
and documentation of the process so other admins can easily understand
how the 'custom' parts of the system fit in.
shawn
On Fri, 2007-19-10 at 16:56 -0700, Tyler Mitchell (OSGeo) wrote:
After reading some RedHat discussion it seems this is one of the
common places to get them from. But I'll defer to anyone else from
SAC who knows better. There are a few dependencies for the package
from there though:
$ rpm -i --test http://mirror.stanford.edu/yum/pub/centos/5/updates/
i386/RPMS/php-5.1.6-15.el5.i386.rpm
warning: /var/tmp/rpm-xfer.fC9A6t: V3 DSA signature: NOKEY, key ID
e8562897
error: Failed dependencies:
httpd-mmn = 20051115 is needed by php-5.1.6-15.el5.i386
libc.so.6(GLIBC_2.4) is needed by php-5.1.6-15.el5.i386
libcrypto.so.6 is needed by php-5.1.6-15.el5.i386
libssl.so.6 is needed by php-5.1.6-15.el5.i386
php-cli = 5.1.6-15.el5 is needed by php-5.1.6-15.el5.i386
php-common = 5.1.6-15.el5 is needed by php-5.1.6-15.el5.i386
rtld(GNU_HASH) is needed by php-5.1.6-15.el5.i386
On 19-Oct-07, at 3:35 PM, Martin Spott wrote:
> On Fri, Oct 19, 2007 at 02:24:07PM -0700, Tyler Mitchell (OSGeo)
> wrote:
>
>> It looks like up2date is already configured to find packages off the
>> hosting provider, but php5 isn't in their list of available
>> packages. I'm no pro with this tool, though, that's for sure.
>
> I'm not either - and, to be honest, I'm not inclined to become
> one
>
> It would be pretty helpful if someone who's familiar with this
> distribution could at least look if it makes sense to reach out for a
> pre-packaged PHP5 on 'osgeo2'. If this proves to surface too many
> difficulties then I'd like to add a self-grown PHP5.
>
> Cheers,
> Martin.
> --
> Unix _IS_ user friendly - it's just selective about who its
> friends are !
> ----------------------------------------------------------------------
> ----
> _______________________________________________
> Sac mailing list
> Sac@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/sac
Tyler Mitchell
Executive Director
Open Source Geospatial Foundation
tmitchell@osgeo.org
P: +1-250-277-1621
M: +1-250-303-1831
OSGeo administration has not been keen to maintain PHP a lot or think
about how to upgrade to newer versions. Updating was sort of "deferred
until required" and dependencies have not been looked into.
Martin,
Speaking of deferred till required, is PHP5 required for MediaWiki? Or
just preferred?
> I suggest that
you two propose what to do exactly, send it to WebCom and VisCom and if
nobody objects just go ahead. The same applies to how you do it. If you do
not like using up2date and there is nobody else who really does - then do
it the way you like it.
Since you can't get it from up2date, my suggestion would be to build
it from source in /usr/local and document what you have done.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
