Frank wrote: > * We prioritized establishing a large "Projects" VM and > the services for GRASS, Mapbender, and metadata.osgeo.org > will be located their until there is a fairly compelling > need for project specific VMs.
watching xblade14 for the last couple of weeks it seems that a number of buildbots are responsible for a good portion of the load. The run niced, but still.. So I've been thinking it might be good to have a build.osgeo.org VM set up as a build server; it could run at 100% without slowing down the static html front ends of the other sites hosted on osgeo4. comments? > Some questions outstanding around the idea of doing all > logins over https to avoid making OSGeo passwords easily > sniffed. a big +1 for adding https to the mediawiki login page(s), and whatever ldap magic is needed to reuse the osgeo ids there. ..if we can avoid having a bad day.. regards, Hamish ps- continue this over at grass-dev, but re CMS for Grass I saw www.lyx.org the other day and thought it looked good for our 'portal' front page needs. Aesthics are not too austere flat text like trac wiki, not too blog or wiki like either. Actually it uses PmWiki but the visitors don't know that, the login button is very subtle. and they kept notes! http://www.lyx.org/SiteDocumentation http://www.pmwiki.org convert html -> pmwiki libhtml-wikiconverter-pmwiki-perl No idea how it's stored on disk (eg if you can ues unix command line power tools to bulk maintain pages) but it seems to me that the home-portal doesn't really need to run more than about a dozen pages of content- it's just a front end reception service. No idea about RSS support, but we can't be the first folks to think about it. Again, https logins and reuse of osgeo ids+ access groups would be a bonus. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
