All,
So, here I am . . .
I’ve got some questions about the OSGEO hardware infrastructure.
Mostly right now, what is it’s current state of operation?
Looking to see where I might be able to offer up some help, with infrastructure stuff, newer hardware, network connection, etc. I’m not Admin, but . . . could possibly have some leads on things if I had a good idea about the current (future) shortcomings.
Is this all out of scope for the current difficulties? Would asking later on be better?
bobb
Bob Basques wrote:
All,
So, here I am . . .
I've got some questions about the OSGEO hardware infrastructure.
Mostly right now, what is it's current state of operation?
Bob,
There is some information on the current systems and services
available at:
http://wiki.osgeo.org/wiki/SAC_Service_Status
It does not fully reflect damage from the recent blade outage.
In particular at this time I believe xblades 10, 11, 13 and 14
are compromised. John is trying to re-install 13 which we use
as the download server normally. Most services on 14 should
likely be migrated to the Projects VM or elsewhere.
It is my intention that xblade11 would be re-setup as a buildbot
server (build and smoke test). I'm not sure to what extent we
will want to save the buildbot configurations from xblade11 and
xblade14. Mateusz has normally been the lead on buildbot stuff
but I get the impression he has limited time available.
There will be some admin needs for the download server once it
is working again. In particular setting up anonymous ftp
(for ftp.remotesensing.org), rsync service (for backup/mirroring),
webdav services (so the java maven updates work), and perhaps
putting the special throttling settings in place. There has also
been a long standing suggestion this server should be doing nightly
antivirus scans that would be nice to pursue.
The above steps are the ones I have hesitated to put in place
on the current download "backup server".
Other outstanding tasks as part of the Peer1 to OSU OSL migration that
I don't see having been addressed yet are migration of LDAP, and
email service + mailman.
Some discussion of this migration are available at:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010
Looking to see where I might be able to offer up some help, with infrastructure stuff, newer hardware, network connection, etc. I'm not Admin, but . . . could possibly have some leads on things if I had a good idea about the current (future) shortcomings.
>
Is this all out of scope for the current difficulties? Would asking later on be better?
One item that has come up as desirable but surprisingly hard to address
is a decent windows server that can be remotely administered and used
for windows build tests, shared build environment, etc. If you had a
dependable reasonable well resourced machine with good network
connectivity you were willing to provide in this role (and perhaps
provide some admin support for), that would be helpful.
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 | Geospatial Programmer for Rent
We’re Linux through and through, sorry on the windows thing, I feel for you.
Debian is our (currently) preferred poison.
In between the lines, I’m wondering about providing dedicated device(s) for OSGEO use, could be used, could be new, could be mixed. Does it make some sense to think about it possibly as redundant node(s), that could possibly take over if needed.
I was wondering about Blades vs separate CPU’s as well. You prefer Blades, or anything goes, etc. I would need to figure out how to balance one time setup vs long term support. Preferably, we would setup and forget. Don’t have the manpower resources currently to go much beyond this offer right now. Can’t really address the admin/VM stuff at all, nor do we want to at this time, but the co-locating is a real possibilty (offsite datacenter and independent vendor, NOT City).
What would be desirable based on the descriptions here?
Maybe this is not the right time to think about this.
bobb
Frank Warmerdam warmerdam@pobox.com wrote:
Bob Basques wrote:
All,
So, here I am . . .
I’ve got some questions about the OSGEO hardware infrastructure.
Mostly right now, what is it’s current state of operation?
Bob,
There is some information on the current systems and services
available at:
http://wiki.osgeo.org/wiki/SAC_Service_Status
It does not fully reflect damage from the recent blade outage.
In particular at this time I believe xblades 10, 11, 13 and 14
are compromised. John is trying to re-install 13 which we use
as the download server normally. Most services on 14 should
likely be migrated to the Projects VM or elsewhere.
It is my intention that xblade11 would be re-setup as a buildbot
server (build and smoke test). I’m not sure to what extent we
will want to save the buildbot configurations from xblade11 and
xblade14. Mateusz has normally been the lead on buildbot stuff
but I get the impression he has limited time available.
There will be some admin needs for the download server once it
is working again. In particular setting up anonymous ftp
(for ftp.remotesensing.org), rsync service (for backup/mirroring),
webdav services (so the java maven updates work), and perhaps
putting the special throttling settings in place. There has also
been a long standing suggestion this server should be doing nightly
antivirus scans that would be nice to pursue.
The above steps are the ones I have hesitated to put in place
on the current download “backup server”.
Other outstanding tasks as part of the Peer1 to OSU OSL migration that
I don’t see having been addressed yet are migration of LDAP, and
email service + mailman.
Some discussion of this migration are available at:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010
Looking to see where I might be able to offer up some help, with
infrastructure stuff, newer hardware, network connection, etc. I’m not
Admin, but . . . could possibly have some leads on things if I had a
good idea about the current (future) shortcomings.Is this all out of scope for the current difficulties? Would asking
later on be better?
One item that has come up as desirable but surprisingly hard to address
is a decent windows server that can be remotely administered and used
for windows build tests, shared build environment, etc. If you had a
dependable reasonable well resourced machine with good network
connectivity you were willing to provide in this role (and perhaps
provide some admin support for), that would be helpful.
---------------------------------------±-------------------------------------
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 | Geospatial Programmer for Rent
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
Bob Basques wrote:
We're Linux through and through, sorry on the windows thing, I feel for you.
Debian is our (currently) preferred poison.
Bob,
No need to appologise from where I'm standing!
In between the lines, I'm wondering about providing dedicated device(s) for OSGEO use, could be used, could be new, could be mixed. Does it make some sense to think about it possibly as redundant node(s), that could possibly take over if needed.
This might have some value, but we aren't really in a pressing need
for *more* servers at this time.
I was wondering about Blades vs separate CPU's as well. You prefer Blades, or anything goes, etc.
We are really moving to a "big multi-cpu server" with lots of
VMs on it architecture at OSU OSL. We have two physical
servers there now, with about 8 or so VMs running on them.
I would need to figure out how to balance one time setup vs long term support. Preferably, we would setup and forget. Don't have the manpower resources currently to go much beyond this offer right now. Can't really address the admin/VM stuff at all, nor do we want to at this time, but the co-locating is a real possibilty (offsite datacenter and independent vendor, NOT City).
Understood. But I'll say it is the manpower that is our main
limiting factor now.
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 | Geospatial Programmer for Rent