[SAC] [OSGeo] #2690: Setup osgeo8 as LXD Host

#2690: Setup osgeo8 as LXD Host
---------------------------+-----------------------
Reporter: robe | Owner: sac@…
     Type: task | Status: new
Priority: normal | Milestone: Unplanned
Component: Systems Admin | Keywords:
---------------------------+-----------------------
osgeo8 as mentioned in #2591 I think we should go ahead and setup osgeo8
as an LXD host and use the disks as is.

It will be a host that will have both containers and VMs. I still need to
get around the lxd limitation that that while it can be used to create and
manage a true VM via QEMU, the default config has hardware emulation
turned off. This makes it only useful for non-linux VMS such as Windows,
Mac, the BSDs that don't need complete hardware emulation. Until we
figure out a way around it, we can't use it for hardware emulation - such
as emulating the os390s or the ARMs (which bare QEMU I think can do).

For the most part the container support (which is Linux Containers) is
sufficient to support any kind of Linux that is x86_64 (possible even
32-bit, haven't checked that).

That means even with the current osgeo8 disk, it should be pretty good for
CI/CD, demo sites, tutorial sites. Anything where we are often rebuilding
the thing from scratch and thus don't care as much that the disks may not
be robust.

--
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2690&gt;
OSGeo <https://osgeo.org/&gt;
OSGeo committee and general foundation issue tracker.

#2690: Setup osgeo8 as LXD Host
---------------------------+------------------------
Reporter: robe | Owner: sac@…
     Type: task | Status: new
Priority: normal | Milestone: Unplanned
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+------------------------

Comment (by darkblueb):

this machine is related to the Openstreetmap Project, which is crucial to
the Open Data movement worldwide. Without evidence, I believe that there
are now at least two tiers of Openstreetmap replicating nodes: one has
full change logs with authorship, and the second and more common kind has
only changesets with some identifying information removed.

Osgeo8 is located on US territory and therefore subject to US laws,
however it is not reasonable to think that there is some kind of tier of
Openstreetmap core replicating node, that is never located on US
territory, therefore this Osgeo8 would not be the first (hopefully not the
last, either).

I suggest that with the longstanding relationship between OSGeo dot org
and the various forms of Openstreetmap network engineering groups, that
Osgeo8 is a great candidate for a secure, trusted, core Openstreetmap
replicating node.

As far as hack target dangers and attracting advanced infiltration, there
are higher value targets that attract that kind of thing on the net, and,
this would not be the only Openstreetmap inner-core replicating node in
the US -- by definition they are the same. Also given OSUOSL, it is likely
that there is already at least on node like that, either in Oregon, in
Wisconsin, or in New York State, per the recent expansion of the OSUOSL
inner network.

Bandwidth use of such a service is non-trivial, so good agreement with
OSUOSL would need to be in place, and their own planning would likely want
to know about that. Generally it seems like good policy to document the
basic server functions on OSGeo equipment anyway, e.g. on the public wiki.

--
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2690#comment:1&gt;
OSGeo <https://osgeo.org/&gt;
OSGeo committee and general foundation issue tracker.

#2690: Setup osgeo8 as LXD Host
---------------------------+------------------------
Reporter: robe | Owner: sac@…
     Type: task | Status: new
Priority: normal | Milestone: Unplanned
Component: Systems Admin | Resolution:
Keywords: |
---------------------------+------------------------

Comment (by robe):

@darkblueb the issues I see with the above is

1) I know nothing about managing osm replicating nodes, and given that osm
gave us this server, I presume they must have ruled that out as something
they wanted to use this for or manage.

2) The extra bandwidth and overhead of managing someone else's project is
beyond SAC responsibility goals. It would require someone to take up the
challenge and continue supporting it.

--
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2690#comment:2&gt;
OSGeo <https://osgeo.org/&gt;
OSGeo committee and general foundation issue tracker.

#2690: Setup osgeo8 as LXD Host
---------------------------+---------------------------------------
Reporter: robe | Owner: sac@…
     Type: task | Status: closed
Priority: normal | Milestone: Sysadmin Contract 2022-I
Component: Systems Admin | Resolution: fixed
Keywords: |
---------------------------+---------------------------------------
Changes (by robe):

* status: new => closed
* resolution: => fixed
* milestone: Unplanned => Sysadmin Contract 2022-I

Comment:

This was already done. We have grass on this and also download.osgeo.org
proxy
--
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2690#comment:3&gt;
OSGeo <https://osgeo.org/&gt;
OSGeo committee and general foundation issue tracker.