-----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: <[email protected]> Reply-To: System Administration Committee Discussion/OSGeo <[email protected]> To: <[email protected]> CC: [email protected], [email protected], [email protected] References: <[email protected]> (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 [email protected] 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 iEYEARECAAYFAkwsxXsACgkQXmFKW+BJ1b2Q7QCeNr76RdzKUAAmzcDSEji1VaHq lIYAn2avuSp8HvsJrhc1mB7KQWXYquXF =kb6m -----END PGP SIGNATURE----- _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
