Mailing List Archive

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).

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).

Since conserver running on any given host only cares about the device
info in the cf file entries that it's controlling, i wouldn't think
it would be hard to modify the parser to permit the device name to be
omitted from the remote entries (assuming it's considered an error now).
And i suppose it could be taken a step further to allow a different remote
console name to be specified (perhaps if the "device" starts with none of
[/!|]). But that could require some code (and protocol) changes where
the client is referred to a remote conserver. Also remember that the
console client will talk to multiple servers to get the information it
needs for options like "-w", so it'll be really hard to hide the remote
console names.

It's all fine with me, just as long as it doesn't break the existing
functionality, with remote names defaulting to the local names. :)

--dave

[. 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>