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

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

Phillip Pacheco ppacheco@genesyslab.com
Tue, 9 May 2006 14:18:03 -0700 (PDT)

I have a question which is sort-of on this topic.  

Is there a way to configure redundancy into a multi-homed structure?

As I understand it, if the server which has the alias/name of 'console'
crashes then the whole console network is offline.  Is this correct?  If
so, is there a way to setup redundancy which will avoid this single
point of failure?

Phillip Pacheco

-----Original Message-----
From: users-bounces@conserver.com [mailto:users-bounces@conserver.com]
On Behalf Of Matt Johnson
Sent: Friday, May 05, 2006 8:09 AM
To: Bryan Stansell
Cc: users@conserver.com
Subject: Re: Conserver chaining -- cyclades-ts to consolidating linux

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
  blackbird                on /dev/ttyS1                       at
  c20p1                    on /dev/ttyS1                       at

(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
> 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
> a 'master' entry cooresponding to the appropriate cyclades term
> distribute that file to each cyclades server as well as the linux
> server.

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
> the linux host defined as it's "default initial master server" (in
> console -V output).  when a person then says 'console foo', the
> binary would first connect to the linux server, ask for the console,
> the linux server (since it knows about all the consoles on the
> 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
users mailing list