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

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Hmmm, so I presume that means no X?  Or just the minimal client bits? -
> E.g. enough to run client(s) and display on some other X server (such
> as securely forwarded over ssh), but no X server.

Hi, Michael.  I need to be cooking rather than responding to mailing
lists posts, but I'll take a really brief swing at this.  No offence
intended by any breezy inattention to your points.

I definitely do not have X in any meaningful sense on my servers, at
least certainly not the server-software portion of X.  Cannot offhand
recall whether I end up having X11 _libs_ on any of my servers, though
that is possible and of some utility in some cases, but I'm pretty sure
not on _my_ servers because I strongly doubt there are any X client
executables, either -- because I would make a point of not having them.
I think.

As to the contemplated CompuLab system, I would expect that I would go
to some lengths to prevent any part of X from being part of the host OS
build.  What might end up being part of the VM is a different story.
Maybe there might end up being one or more X11 executable available in
the guest OS, with the idea that a user might want to run it remotely
using 'ssh -Y linuxmafia.com' to tunnel X calls remotely to the user's
workstation X11 display.

In case it's not obvious, and I _think_ it is, I always run Linux
servers in headless operation -- with the exception of when I connect
any-old-ratty-monitor to local console, where in consequence I can if I
wish run a local session, but that local session would be console-based
(text-only)  on account of the absence of an X11 server.

I'm a little confused about the rest of what you're saying, though
perhaps it's best to clarify when you get here.  It's more challenging
to configure KVM/qemu without local X11, you say?  Oh.  Hmm, well, if
it's most expedient to have X11 for VM-layer configuration, I -guess- we
could configure local X11 for purposes of that work.  But I'd definitely
blow away every bit of X11 when we're done, because even at normal
times, not to mention when I'm creating an emphatically minimalistic VM
host OS, my view is that *ix servers should not run X11 servers or even
have them installed.

This used to be a big problem with Oracle Corporation's default
installer for Oracle RDBMS, which wants to run some big, dumb, graphical
Java process to install and configure the database.  Oracle released
that to the world back in, I'm going to say, the late 1990s?, and the
world's *ix sysadmins, most of them, immediately went 'Uh..., sorry, I
really don't think so.'  So, Oracle hastily cobbled up _alternate_
installation instructions that don't require X11, and most sysadmins I
know used that rather than the official instructions because their
attitude remained 'Local X display daemon, display manager, X11 clients,
and X11 libraries on my Unix server?  No, I really don't think so.'

As to how to get into stuff in the absence of X11:  In the normal model,
one gets into a headless, networked Linux server by either ssh'ing in
from remote, or by being right at the server and logging in directly to
its (text-only) console.  How does one get into such a server when it's
running KVM/qemu?  Um... you tell me.

In that scenario, my understanding is that the host OS would end up not
being network-accessible in order to not waste a public IP address on it
(and to make it less attackable).  My understanding is that the host OS
would somehow bridge network traffic to the VMs.  Therefore, my
guesttimation is that user access to the VMs' shells would need to be
via... not sure?  Long term, via SSH.  During setup prior to activation
of sshd in a configured guest OS in the VM, I really don't know yet, and
was hoping you could tell me -- since this would be the first time I've
configured KVM/qemu.  I figured that is a standard problem for which
there is a standard method of entry.  Otherwise, it'd be difficult to
install and configure guest OSes, right?

I'm out of time, but I'm not clear on what PXE boot has to do with this.
At the present time, I'm not aware of needing or wanting a PXE boot
setup, and I'm pretty _certain_ I don't want one on the CompuLab.  The
intended scope of services doesn't include one.

It'd be nice to have a PXE server (w/tftp, etc., to be able to do
kickstart, or workalikes such as FAI) on my home network, if only
because that would be super-handy to help people duing CABAL -- but it
strikes me that my Internet-facing server is absolutely the wrong place
for that.

But, again, I don't _think_ I need PXELinux, or a DHCPd, or tftpd, or
FAI _today_ -- unless I'm missing something important.


> Also, for the existing linuxmafia.com host - presuming one will just
> copy the image over - with zero to minimal changes (at least initially),
> would be best to set serial console up on that first; Linux can even do
> multiple consoles - e.g. serial *and* graphics (or at least via whatever
> the graphics card - can still just be text) ... however only one
> is used for input - if multiple are specified for console, the last
> specified is used for input....

Again, we should talk about this.  Maybe you're implying that serial
console is the standard means of access from a KVM host OS into a newly
created VM in order to do configuration of a guest OS.  If that's not
what you mean, then I don't know why you're suggesting it.

For most of my history as a sysadmin, serial console was what you were
forced to do for initial setup of certain weird hosts that had no
capability to run a normal local video monitor and local keyboard.  In
the world of normal x86 hardware, by contrast, serial console has
typically been an exotic option that you feel glad you don't need
because you _can_ just connect a monitor and keyboard.

Just to be clear, the CompuLab _does_ have normal video and keyboard
connections, and runs just great with bog-standard local console like
any other normal x86 box.  So, thank Ghu, I believe there's no reason to
sod about with bootloader serial console configuration, etc.

> Here 'ya go :-) 
[...]

Appreciately -- and I'm sure you'll understand that I'm backlogged at
the moment and didn't even have time to try to read that, yet.  And, at
a really quick glance, that was Greek to me, sort of, at least in part,
because it's kind-of new to me.

See you this afternoon.