> 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?
> - 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?
>> 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.
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. 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!)
I guess it would be possible to setup a gateway (vserver?) which you ssh
into and then from there into the real server. 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"
Grateful for any other ideas?
Received on Thu Jul 16 01:12:50 2009