Setup osgeo8 as LXD Host

[robe]

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.

[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.

[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.

[robe]

This was already done. We have grass on this and also download.osgeo.org proxy