Re: proposal for remote console specs using the console name, not device name

[ On Wednesday, April 24, 2002 at 23:46:06 (-0700), Dave Stuit wrote: ]
> Subject: Re: proposal for remote console specs using the console name, not device name
>
> On 24 Apr 02 18:41 PDT, Greg A. Woods wrote:
> >
> > I'd like to propose that remote console specifications (the "@conserver"
> > form) should be preceded by the remote conserver's name for the console,
> > not it's device name.  [and until the next major release both could be
> > permitted, with a warning logged for deprecated usage....]
> 
> I can see how that would make things easier for multiple conserver hosts
> with separately maintained cf files (although i'm not sure when it would
> be desirable for different conservers to refer to a console by different
> names ... seems like that would be confusing).

My assumption, based on my reading of the documentation and from the
various sample configurations, was that the device name was the key used
to select the "console" on the remote conserver host.  I probably do
want to have the same console name, and I don't think I really meant to
suggest that different conserver hosts would refer to the same "console"
by different names.  I just didn't want to have to distribute the device
names -- I want the freedom to change them without having to change the
console.cf on the master conserver host.

I've since come to understand the code a bit better and I've done some
more experiments and I've found that indeed the device name is ignored
and can be omitted (as can the baud rate):

	callerid:@very::&:

This has much the same effect as I was trying to achieve through my
proposal in the first place -- I apologise to all for not trying it
before!  :-)

(my next post will be about why it's now a _lot_ easier for me to try
such things on a whim!  :-)

> However, i know of at least a few sites where a single cf file is
> maintained centrally and distributed to all conserver hosts (and we like
> it that way :) ).  Also, if one of the hosts dies, it's especially easy
> to have another one take over if all of the device and port information
> is present in everyone's cf file (assuming the devices are terminal
> servers that are accessible from the other conserver hosts).

In almost all situations I currently envision using conserver its
primary reason is for logging -- where possible I always use terminal
servers for the actual serial ports, so universal access from any
workstation via the 'console' client program is only required because of
my use of conserver.  I'm only using multiple hosts on my home network
and that's only because I don't have the necessary power supply to be
able to put a small 8-port termserver in my office!  ;-)

In the scenarios I manage if the conserver host dies then I just telnet
directly to the terminal server, just as I did before using conserver. :-)
Unless the conserver host outage is extended I wouldn't want to take
over console logging on some other host as dis-joint and distributed
console logs are probably not any more useful than no logs at all,
especially given that I only really need logging for capturing the cause
of hopefully far more rare system crashes.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>