On Thu, Jul 16, 2009 at 01:10:48AM +0100, Ed W wrote:
> Hi
> >well, you have a bunch of options, depending on the
> >specific usecase ... e.g.
> Assuming headless server somewhere in a rack.
>
> > - use a real console (serial or vga)
> > - use a virtual console
> Excuse dim question, but presumably the latter (and former)
> of these is out if we aren't on the physical terminal?
well, the vc doesn't really care about a physical
terminal, and the serial console could be one for
each guest, if you like ...
> > - use a pipe or unix socket
> > - use a network socket
> Again, probably dim question, but by this do you mean some
> variation of ssh, telnet or home grown equivalent using
> netcat/shells, etc?
whatever gives you a logon via pipe or socket, yes
> >>SSH is a given, but isn't always a straightforward option
> >>if IP addresses are constrained
> >AFAIK, there is no constraint on private IP addresses
> >(yet, although the IPV6 folks would like to see that
> >on IPV4 :), so the public IP address constrains are
> >not a real reason for not using ssh or telnet
> Well, kind of. However, it's certainly more convenient
> to run all services on port 22 on real IPs.
IMHO, it is much more convenient to have them running
on private IPs, and to S/DNAT them to 'real' (i.e.
public) IPs whenever needed
(this is a lot more flexible than using the public IP
directly)
> At least for my data center machines I obviously need
> to talk to real IPs at some point and obviously one IP
> is enough if use an array of ports, but remembering how
> they all map is a pain.
not necessarily for sshd. as you are depicting a scenario
where you have lots of guests but only a single (or a few)
public IPs available, I presume they are usually not
running sshd, and thus, they are unreachable from the
outside, except via the host ... so in this scenario, it
would be logical to access the guests via ssh _from_ the
host, which doesn't need any sshd bound to a public IP
> Someone will say to configure some file in ~/.ssh which
> lets you setup these mappings, but I hop around between
> a bunch of linux, windows and mac terminals and keeping
> such a file up to date is not ideal. (DNS solves the problem
> neatly in the case of lots of IPs!)
of course that is an _additional_ option you have, which
would allow you to reach the guests directly over the
network (which is a bonus feature in your setup :)
> I guess it would be possible to setup a gateway (vserver?)
> which you ssh into and then from there into the real server.
the host could be that gateway ...
> Add some scripts and I can see that working
> However, quite often when I'm doing maintenance and leaping
> into machines to check config (and some machines are
> just templates, so they get fired up with incorrect ip
> addresses), it's definitely extremely convenient to be
> able to use "enter"
having a private IP for each guest makes it unnecessary
to change the IP in the guest config, so a name service
association (on the host) can be easily done via /etc/hosts
but let me state that once again: there is nothing wrong
with using enter to _enter_ a guest (I do that all the
time) just don't expect it to be the same as a regular
logon (the very same way as you do not expect ftp to behave
like telnet)
> Grateful for any other ideas?
as I listed them methodically, I doubt that there will
be many of them which do not fit into one of the
categories above, although I could add more obscure
things like shared memory or file system interfaces :)
best,
Herbert
> Thanks
> Ed W
Received on Thu Jul 16 01:32:12 2009