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

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