[Geodata] [Fwd: Re: [SAC] Accessing and using projects.osgeo.osuosl.org]

Seven (aka Arnulf) seven at arnulf.us
Thu Jul 1 12:42:55 EDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fyi

- -------- Original Message --------
Subject: Re: [SAC] Accessing and using projects.osgeo.osuosl.org
Date: Thu, 1 Jul 2010 16:54:42 +0200
From: <christopher.schmidt at nokia.com>
Reply-To: System Administration Committee Discussion/OSGeo
<sac at lists.osgeo.org>
To: <sac at lists.osgeo.org>
CC: geodata at lists.osgeo.org, mapbender_dev at lists.osgeo.org,
geonetwork-devel at lists.sourceforge.net
References: <4C2C45F5.7040801 at arnulf.us>

(I"m not on several of the lists CCed here; please feel free to forward
this response as you see fit.)

On Thu, Jul 01, 2010 at 09:38:29AM +0200, Seven (aka Arnulf) wrote:
> Hi,
> maybe this has all been resolved yet, please jsut send a link where to
> read up on.

Sorry, I need to write up a plan for projects; I've been shipping the
kids off to camp the last two weekends, so I got distracted. I'll make
sure to get a writeup this weekend. (though I'm not really sure this
is on the right list, since this seems

> This might evolve into a ticket but maybe we need to have a broader
> dialog before actually starting to decide and then do things.
> 
> We (GN, MB, Geodata Committee) have collected some requirements for what
> we need to run metadatata.osgeo.org. I guess that other projects need
> similar things and I am absolutely unclear on how this can be organized
> so that we don't step on each other's toes.
> 
> Here goes things that I believe sudo rights are required + they can
> conflict with other's requirements:
> 
> Apache
> * add aliases
> * add modules (rewrite, etc.)
> * ssh / certificats (this could probably managed by SAC and does not
> need changes often)

I don't understand this. Are you *developing* a service, or *running*
a service? If you're developing software, then the projects server
is not the right place to put it.

> PostgreSQL
> * create database
> * create users
> * change ownerships
> * add triggers, functions, etc.

This is all easy; none of this requires access to bring down a service.
However, the latter comes down to the same question as above: are you
writing software, or running software?

> Installations:
> * PostGIS (maybe in different versions for different projects?)
> * PHP
> * gettext
> * all the nitty gritty personally preferred admin tools

These are easy (and already done, except for gettext; which is
installed, but I'm assuming you want something other than the C
library.)

> We will need to edit PHP.INI regularly, try different settings. This
> requires to restart Apache / force reload.

To be frank: No. This is a perfectly reasonable thing to do in testing
of some new software, but I don't understand why you think this would
be required in restarting apache regularly in a production service;
if you're asking for a machine to develop on, projects isn't it.

> We will have to deal with https, connect to LDAP, maybe create users or
> groups for LDAP (this could or should probably also be done by SAC)?

Creating LDAP users can be done by having the users create accounts.
Creating groups requires the LDAP Manager password, and should be managed
by SAC. Adding users to groups can be done by other users once the group
is created.

> There will probably be more details as we go along, this is just to get
> us started.
> 
> The Geodata Committee wants to grow a service for all types of metadata
> for services, dataset, applications, portals and so on. The Mapbender
> and GeoNetwork teams are interested in supporting this project from the
> technical side. If sucessful it will be a well received OSGeo service.
> If not highly available and stable it has no chance of becoming
> sucessful which puts us into this old deadlock.


... You want something highly available and stable, but apparently plan
to develop the software on the production machine? This is definitely
a problem, but the problem is not on SAC's side; it's in the social
aspect.

> These are just initial ideas, maybe you already have it all worked out
> and can point to a policy page that describes how to deal with this.

Very little of this is not solvable technically. Instead, the problem
here is social: You seem to be proposing developing a service that
you wish to maintain for the public on the 'live'/production service.

If you don't care about uptime, that's fine, but you've said that you
do, so I'm trapped between a rock and a hard place here.

So let me propose something slightly different here:

 1. Seperate development and deployment of updates to development.
    This means that your constant PHP tweaks, configuration changes,
    etc. take place on another machine.
 2. Deployment takes place on the projects server; one or two members
    of the projects have sudo access on the projects server to change
    the bits on the server that need changing when a deployment is
    taking place. Since these types of deployments should be tested,
    a new one shouldn't be particularly difficult to arrange.
    (Considering our current uptime for some projects is approaching
     the 'nine fives' SLA level, a couple minutes of downtime during
    a transition is unlikely to be a significant impact.)
 3. Development takes place on some other server; this is where all
    the constant tweaking takes place. (In any real development setup,
    I'd expect each developer to need their own local development
    setup; certainly that's the way I've developed my software over
    the years, but maybe that's Just Crazy.)

The key difference between #2 and #3 is that #3 can be a 'nothing'
machine; since it has no users other than developers, perforamcne
and uptime are not issues. (The exact location of this development
machine is not something I've settled on; I'll need to check with
some other people to figure out the status of our incoming
resources.)

Even if I/SAC were to hand over a full, high powered VM, the idea
of running a production service on the development machine is just
off; we need to separate the two to avoid the very problems you've
stated you wish to avoid. So I'd recommend avoiding them by using
a separated environment.

If I've missed something significant here, I apologize, and look
forward to a clarification.

Best Regards,
- --
Christopher Schmidt

_______________________________________________
Sac mailing list
Sac at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac

- --
Arnulf Christl

Exploring Space, Time and Mind
http://arnulf.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwsxY8ACgkQXmFKW+BJ1b3dkQCfRfxD1cHJWatTGK6chL+Zwszg
OfIAnj2blEyELzNG2A/Xw2HU3UkUEOP/
=smn5
-----END PGP SIGNATURE-----


More information about the Geodata mailing list