Mailing List Archive: conserver: users

Conserver chaining -- cyclades-ts to consolidating linux server

Index | Next | Previous | View Threaded

mwj at doc

May 3, 2006, 9:07 AM

Post #1 of 5 (1455 views)
Permalink

Conserver chaining -- cyclades-ts to consolidating linux server

Hi all,

I'm looking for some assistance with regard to chaining conservers. The
documentation which is provided with conserver on this particular issue
seems be rather unclear -- and although average-distributed.cf seems to
be an example of the chaining case, it is proving highly opaque to me,
and I'm not at all clear whether it works in the way I'm hoping!

Here's the situation:

* I have conserver cross-compiled and running on a whole bunch (>10) of
Cyclades TS-4000s (one of which is 10.1.2.20), which present their
serial ports as ttyS* to the local embedded Linux system. I'm happy
enough with this bit -- the local conservers need to configure
consoles as type "device" and have a devicesubst entry in an
appropriate default{} stanza and then be referred to as ports.

My current conserver config on these looks like this:

=========================================================

# CYCLADES TS-4000 config -- cyclades has ip 10.1.2.20

config * {
autocomplete yes;
defaultaccess rejected;
daemonmode yes;
passwdfile /etc/conserver.passwd;
primaryport 782;
secondaryport 2001;
}

default * {
type device;
device /dev/ttyS.;
devicesubst .=Pd;
host none;
portbase 0;
portinc 1;
parity none;
rw *;
master 10.1.2.20;
# master 10.1.1.1;
baud 38400;
}

access * {
allowed 127.0.0.1;
trusted 10.1.1.1;
}

console cyc20port1 {
port 1;
# host 10.1.2.20;
}

=========================================================

* 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
involves the use of the "master" keyword in the configs on the
Cyclades, but when I have tried on the individual Cyclades to say that
the master is the Linux server (master 10.1.1.1), the secondaryport
for the console cyc20port1 isn't actually opened when running
conserver on the Cyclades! (Config as above opens the secondaryport
when run on the cyclades -- switching the master in the default stanza
and uncommenting the host entry in console cyc20port1 makes it
vanish.) Assuming I need to use a 'type host' connection from the
Linux server to the individual Cyclades consoles (which is what all
the examples and documentation suggest) this is an obvious
showstopper.

I know there has been some wisdom here in using identical config files
across all conserver instances (both "master" and "slave" here) -- but I
can't tell whether this is the correct thing to do here. I have tried
various versions of using the same config file on both cyclades and
server, but there's also an (obvious) conflict between using 'type
device' as is necessary on the Cyclades devices to get conserver lashed
up to the raw serial devices, and the use of 'type host' with 'host
<cyclades ip>' and 'port 2001' et al in the conserver.cf on the Linux
server.

Essentially:

* will doing what I am trying to do work? :)
* do I need separate conserver.cf files for each conserver instance in
this case?
* what am I doing wrong in the above?

I'd be very happy to provide updates to the documentation and a worked
example for inclusion in future releases to make this clearer in future!

Thanks

Matt

--
----------------------------------------------------------------------
Matt Johnson <mwj[at]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
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

bryan at conserver

May 3, 2006, 3:33 PM

Post #2 of 5 (1369 views)
Permalink

Re: Conserver chaining -- cyclades-ts to consolidating linux server [In reply to]

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
_______________________________________________
users mailing list
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

mwj at doc

May 5, 2006, 8:09 AM

Post #3 of 5 (1368 views)
Permalink

Re: Conserver chaining -- cyclades-ts to consolidating linux server [In reply to]

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

--
----------------------------------------------------------------------
Matt Johnson <mwj[at]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
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

ppacheco at genesyslab

May 9, 2006, 2:17 PM

Post #4 of 5 (1348 views)
Permalink

RE: Conserver chaining -- cyclades-ts to consolidating linux server [In reply to]

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
WIS-UNIX
Genesys

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

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

--
----------------------------------------------------------------------
Matt Johnson <mwj[at]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
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

_______________________________________________
users mailing list
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

bryan at conserver

May 9, 2006, 5:38 PM

Post #5 of 5 (1353 views)
Permalink

Re: Conserver chaining -- cyclades-ts to consolidating linux server [In reply to]

On Tue, May 09, 2006 at 02:17:53PM -0700, Phillip Pacheco wrote:
> 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?

well, it's not totally offline...you just need to hit it via a different
server. if you point the console client at one of the other conserver
instances, it'll be fine and redirect to whatever is necessary. so, you
could put in an alias/name of 'console2' (or something) of another
instance and then use 'console -M console2 foobar' and the client will
talk to 'console2' instead of 'console' and all should be well.

it would be ideal to have the client process a list of masters, so it
would automatically fallback to other instances. but it doesn't do that
(yet, anyway).

Bryan
_______________________________________________
users mailing list
users[at]conserver.com
https://www.conserver.com/mailman/listinfo/users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com