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