Chown GEOS downloads to pramsey

[pramsey]

I need write access to /osgeo/downloads/geos so I can write new archives in, and so I can set up the regular generation of the doxygen builds and changelogs from GEOS. Also, whether it is preferred to run those processes on upload or download would be good knowledge.

[jef]

/osgeo/download/geos is group writable for users and upload/download are now the same machine (198.202.74.218).

[pramsey]

The machine seems lacking in "stuff"... no 'svn', no 'doxygen'. Is anyone else building out snapshots here?

[warmerdam]

Paul,

We are not generating the GDAL (or I think the mapserver) snapshots on the download system any more. At least for GDAL I do it on the projects vm and keep the latest snapshot on the web site instead of the download site.

Among other things this reduces the churn on the mirrored download site. It also keeps non-downloading work off the download server.

It looks like the chown for /osgeo/download/geos is taken care of, perhaps by jef?

[pramsey]

Chown is handled, so I can drop download bundles now, but the problem I actually set out to solve was the missing doxygen and svn snaps, which it sounds like I am discouraged from running on upload/download. Any suggestions on alternate locales for doing that?

[warmerdam]

As I mentioned, I've been doing it on the ProjectsVM.

In the past I maintained the upload/download machines as distinct things so the upload machine could be used to do stuff like snapshots, etc. Now we don't have a spare available blade for that.

The downside to doing stuff on the ProjectsVM is that it is not so easy to push things to the download server and cleanup up old versions.

[pramsey]

I have access to the ProjectsVM? Could it mount /osgeo/downloads to make life easier on the pushing side?

[warmerdam]

Paul,

Yes you have access to the projects vm (some info is at ​http://wiki.osgeo.org/wiki/ProjectsVM).

We can't practically cross mount the download's disk here since it is a different data center. I'm not keen on cross-country nfs mounts though possibly I'm just to conservative.

[pramsey]

OK, getting closer... accessing that box. Now, if I could have geos.osgeo.org pointed there, /osgeo/geos created and chowned to me. and an apache vhost entry added that exposes /osgeo/geos as geos.osgeo.org, I'll be ready to go :)

[warmerdam]

I'll take this action item.

[warmerdam]

Paul,

I have given you sudo, created /osgeo/geos/geos-web, owned by you, and setup the vhost.

I haven't repointed geos.osgeo.org to it yet but you can modify your local /etc/hosts to point to it while testing. I can update the dns when you are ready to deploy.

Does this mean that trac.osgeo.org/geos won't be the main page any more? Perhaps the web site with the doxygen docs and the nightly snapshots could be www.geos.osgeo.org and the main entry point could still be geos.osgeo.org - the trac site?

[pramsey]

I figured I would just redirect geos.osgeo.org back to trac.osgeo.org/geos and put geos.osgeo.org/doxygen and geos.osgeo.org/snapshots in place under the domain. Currently geos.osgeo.org just redirects so the behavior would remain identical.

[hamish]

Replying to warmerdam:

We can't practically cross mount the download's disk here since it is a different data center.

for the occasional single-user one-off, sshfs is a great alternative to NFS.

  #mount:
  sshfs -o idmap=user "$SERVER:/$DIRNAME" ~/mnt/"$DIRNAME"

  # do stuff...

  #unmount:
  fusermount -u ~/mnt/"$DIRNAME"

I'm not keen on cross-country nfs mounts though possibly I'm just to conservative.

IMHO that's not too conservative at all, NFS is not secure by design. Also fwiw&iiuc NFS would mean that if a user had sudo on ProjectsVM they'd essentially have sudo on the xblade as well (for that dir structure). Not that I wouldn't trust any of the Projects people, just fyi.

Hamish

[pramsey]

OK, I am ready to have geos.osgeo.org point to the projectsvm.

[warmerdam]

Change applied, presumably it will take several hours to spread.