[conspire] Church of Get It Done Now ... linuxmafia.com --> virtual? :-)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] Church of Get It Done Now ... linuxmafia.com  
> --> virtual? :-)
> Date: Fri, 24 May 2019 01:16:51 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> So ... how's it comin' along with setting up Linux on the spiffy newer
>> host hardware (SSD(s), fanless, much more modern, ... if I recall
>> correctly)?  And, somewhere along with that, converting linuxmafia.com
>> physical host to virtual upon the much newer hardware?  :-)
>>
>> Ah yes, much easier to dispense good advice than (always and/or
>> consistently) follow it ... yeah, me too.  8-O
>
> Guilty as charged.  I'll mostly leave it at that.
>
> _Maybe_ part of it is that, a long time ago, furiously working on the
> design for the next-generation server was _fun_ in a weird sort of way,
> but then a lot of very-not-fun work experiences happened, and suddenly
> it's easier to put it off, and put it off some more.  And... wait,
> sunofabitch, more privet volunteer shoots attempting to become trees,
> and I hate privets.  And, whoa, isn't that a native oak, trying to get

<snip *long* (and presumed quite partial(?!) list 'o (other) stuff>

Yep, bit different, but likewise, my, uh, "todo" list ... quite long -
and it's mostly *one* item per line 8-O ...

$ wc todo
   5927  21108 177427 todo
$

> I need to redo the CompuLab for proper KVM/qemu operation, but don't
> actually know how.  Need to find the time to study that.  Need a huge
> bunch of time to construct the hardened host-OS environment including a
> custom no-modules kernel.  And where on the revised network is Unbound
> going to go?  I haven't figured that out, yet.  NSD will be port 53 on
> the Internet-facing main host, which means Unbound cannot.  But that's
> just as well, because recursive servers need to be carefully protected,
> (Cache poisoning.)  So, somehow on one of the private RFC1918 networks?
> But if it's on one of those, it won't be visble to the other.  Do I need
> two dedicated hosts just for recursive nameservice?  Seems extravolent.
> But, if not that, what?  I don't know -- and it's like everything else
> around here:  If I don't do it, it simply doesn't get done.

Well, I certainly may be able to help with that - or certainly at least
parts of it, and especially so if it's Debian, and maybe up to nearly
as much if it's some Debian derivative (after all, more Linux distros
are Debian or derivatives thereof, than any other distro).
Some bits ...:

qemu-kvm - done lots 'o that on Debian - and for years.  Highly
recommended for VM infrastruture.  One *might* want to *also*
install virtualbox ... but that would bring in some non-free
bits (notably including at least one non-free kernel module).
I quite rarely use virtualbox, but it's rather/quite handy
for a (very?) few things, most notably (that I recall):
o taking certain VM formats, and well examining their definition (
   most notably hardware and virutal CPU details, etc.)
o *maybe* somewhere along converting some VM formats?
But for the most part, I just use qeum-kvm (and associated  
(required/recommended/suggests)? packages - and use it for *most*
VM type format conversions too - if/when I might actually need to
do that.
You'll definitely want libvirt & friends, e.g. lvirt-clients
(once upon a time I did Xen, then converted to qemu-kvm ... yet
another whole different syntax? ... kind'a - but only once
more - libvirt & friends - after that just use libvirt & friends -
will well handle Xen too - even some beyond qemu-kvm and Xen if
one wants/needs)
Once you've set that up, I can make some general recommendations
(e.g. [virtual] network bits, VM format, etc.) - even have a very
handy TEMPLATE file I use for quick and convenient creation of
virtual machines - copy it, tweak some common settings, execute
it, and VM is created up and running.
DNS nameservers ... RFC-1918 - don't need two dedicated hosts, can
put both on same interface or [v]LAN - no need for separate host;
e.g.:
$ ip -4 a s | sed -ne 's/^[0-9]\{1,\}: \([^ :]*:\).*$/\1/p;/^    inet /p'
lo:
     inet 127.0.0.1/8 scope host lo
br0:
     inet 198.144.194.235/29 brd 198.144.194.239 scope global br0
     inet 192.168.55.1/24 brd 192.168.55.255 scope global br0
virbr0:
     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.d067e5579d9d       no              eth0
                                                         vnet0
$
So ... Internet-facing - NSD
Unbound on RFC-1918 IP
neither listening on wildcard addresses - bind to specific IP(s)
I don't know about NSD, but if it's capable of doing so, and
you want/need to have it also do recursive from selected
Internet addressable IPs/blocks, if it can do it, it may be
possible to have it selectively forward stuff it can't itself
answer and only do so for queries from specified source IPs ...
but I don't know NSD's capabilities enough to know if it can
do that - if one wants it to.

So ... kernel, custom (hardened) ... are you going to do that:
o from kernel.org [+patches?] & customize?  I think that way madness
   lies - probably wouldn't be my recommendation ... but ... might be
   feasible if one wants (one generally gets kernel from distro; kernel.org
   no longer has stable "vs." unstable branches - that's mostly left up
   to distros to pick/configure appropriately for whatever they desire)
o Most distros have a this is a way you build the kernel from source for
   this distro - I'd probably recommend going that route, and then customize
   from there (that way one gets all the benefits of the work the distro
   puts into customizing the kernel ... and one can still atop that, get
   (most?) all the benefits one may want on customizing one's own
   kernel)
Other kernel bits:
Did you know (I'm sure I've mentioned it a time or two ... perhaps else-list)
one can "lock" modules in - so once kernel is up, running, and
"locked", after that, no modules can be added or removed.  That was a
BSD capability, that Linux adopted.  And either from that, or added,
when doing so, there's also the capability to optionally provide a
password - if so provided, one can change (add/remove) modules - but
only by providing that password - and if none was provided, can't be
done at all.  Not quite the same as all built-in and no modules, but
can (also) be useful ... probably most notably there might be some
stuff that will *only* compile as a module, but may be something one
wants/needs.

Anyway, maybe all that helps some wee bit?  And I can certainly provide
more information on at least some parts of it - e.g. qemu-kvm & libvirt &
setup thereof, its networking & networking on physical host itself and
the VMs thereupon, etc.  Heck, I've even got virtualbox in there too,
but most of the time I don't even fire that up (and thus its network
bits aren't even shown in the above).

> At a certain point in all this, I need an anagesic.  And some sleep.
> After all, I'm still jetlagged, which helps not at all.
>
> So, yeah, CompuLab.  Finish it.  Would be nice.  Inshallah.