Re: Conserver chaining -- cyclades-ts to consolidating linux server

On Wed, May 03, 2006 at 05:07:05PM +0100, Matt Johnson wrote:
> * What I want to do is to *also* run conserver on a Linux server
>    (10.1.1.1), which would allow me to use the `console` utility on that
>    machine to reach consoles on the conservers on all of the Cyclades
>    devices (essentially acting as a consolidator). I believe that this

you don't necessarily need to run conserver on the linux server to use
the console client...the client just needs to talk to any of the
conserver instances and then (with the same .cf file on all instances)
redirected to the appropriate place.  but, you can certainly run
conserver on the linux server without the linux server managing any
consoles, and then it's sole duty would be to direct clients to the
appropriate cyclades device.  a nifty setup, in my book (that way you
don't have to decide which of the many cyclades devices you want to be
the point of first contact for clients - the linux server is).

> * will doing what I am trying to do work? :)

yes, it will.

> * do I need separate conserver.cf files for each conserver instance in
>    this case?

you can, but it's easier with a single cf file that you give to all
intances.

> * what am I doing wrong in the above?

just making it more complex than necessary, actually.  ;-)

but, that's 'cause the documentation is really lacking in this area (i
thought i had written something up, but apparently haven't - that must
have gotten lost in the shuffle somewhere).

maybe i can paint a picture that will help.  first, there is no
master/slave philosophy.  the config item 'master' specifies which
conserver instance will manage which console.  all conserver instances
are equivalent.  so, with >10 conserver.cf files like the one you
shared, you should be able to just combine them together (fixing up the
access lists, but just a literal concatenation should be enough - the
access lists would just be repeated) into one large conserver.cf file.
then you'll have a situation where each set of consoles in the file have
a 'master' entry cooresponding to the appropriate cyclades term server.
distribute that file to each cyclades server as well as the linux
server.  when you crank up conserver on each device, you'll have the
following:

   - the cyclades hosts will open each device that specifies itself as
     the 'master'.  for all other console specifications, it will
     remember the master entry (but not try and create/open that
     console - since it's not the master for those).

   - the linux server will realize that none of the console
     specifications specify itself as the 'master'.  they're all remote
     console specifications.  it's job will only be to redirect clients
     to the appropriate cyclades host (since it knows where they all
     are).

so, what would happen, ideally, is that the 'console' command would have
the linux host defined as it's "default initial master server" (in
console -V output).  when a person then says 'console foo', the console
binary would first connect to the linux server, ask for the console, and
the linux server (since it knows about all the consoles on the cyclades
hosts) would then tell the client to talk to cyclades #X.  the client
then makes a connection to conserver there, asks for the console,
connects, and life is good.

now, without the linux server as a traffic cop, you just point the
console client to any of the cyclades servers (or if the linux box dies,
you do this so that you don't have to wait to bring it back up).  the
same behavior happens.  the client talks to one of the cyclades
conserver instances, asks for a console, and if it's local (that
cyclades is the 'master') it's connected, otherwise it's told where to
find it and the client chats with the appropriate device.

hopefully this all makes sense - i wrote it up kinda quick.

Bryan