[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

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

Matt Johnson mwj@doc.ic.ac.uk
Fri, 5 May 2006 08:09:21 -0700 (PDT)

Hi Bryan,

On Wed, 3 May 2006, Bryan Stansell wrote:

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

That's exactly the point. ;-) Many thanks for the below -- indeed, just setting up a single conserver.cf for everything, and setting each console's "master" to be the local cyclades device works very nicely -- console and the conserver on the linux server redirect traffic to the correct cyclades correctly.

A nit would be that 'console -x' on the Linux server lists all the consoles (everywhere!) correctly but doesn't list the host on which the console exists, so you get output like:

 grebe                    on /dev/ttyS4                       at   9600n
 blackbird                on /dev/ttyS1                       at  38400n
 c20p1                    on /dev/ttyS1                       at   9600n

(where blackbird is on one cyclades, and c20p1 is on another)

I'll take a look at the source and see if I can produce a useful patch for this though. :)

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

Hugely clearer. The very terse definition of 'master' in the conserver.cf manpage didn't really help me here, but this makes the situation very much clearer!

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.

Yup, that's the one. I actually only intend to give folks access to the Linux server as a frontend -- all the cyclades detail below should be indistinguishable from magic :-)

Many thanks for the quick response!

best regards


Matt Johnson <mwj@doc.ic.ac.uk>               (020) 7594 8440 / x48440
Systems Programmer, Computing Support Group         Office: Huxley 225
Department of Computing, Imperial College London