Mailing List Archive

On Wed, Feb 18, 2004 at 02:37:04PM -0500, Rick Gaine wrote:
> simply telnet to the port. Can someone help me with a sample
> conserver.cf file to allow console connections to a hostname on port
> 23. I've tried fooling around with it, but I haven't had any luck.

> I'd like to eliminate password checking since the machine this is
> running on is secure and all users can be trusted.

here's a config file that i hope fits your situation:

access * { trusted 127.0.0.1; }
default * { master localhost; logfile /var/consoles/&;
rw *; type host; port 23; }
console machinea { host hosta; }
console machineb { host hostb; }

you can add more ips/hostnames/blocks to the trusted list in case you
aren't connecting via the loopback interface. and fix up the
machine[ab]/host[ab] stuff to match the right hostnames and/or ip
addresses for accessing things. and tweak logfile, if
necessary...basically double-check them all, but the general ideas here
should get you going.

so everyone knows, there are sample config files in conserver.cf/samples
that can help explain the config file and it's possibilities. the
situation above is a bit different because it uses various ip addresses
instead of various port numbers for accessing the serial ports, but i
wanted to mention it.

Bryan

if this is one of the ALOM-based systems (V210/V240/V440/etc.), try
something like:

======
default alom { type host; portbase 22; initcmd /usr/local/bin/alom-chat; }
console v440-sc { include alom; host v440-sc; port 1; }
access * {
trusted 0.0.0.0/0;
}
=====
with the following in /usr/local/bin/alom-chat:
=====
#! /usr/bin/sh
/usr/local/bin/chat -t 4 -I "gin: " "USER" \
"word:" "PASSWORD" \
"sc>" "console -f" \
"return to ALOM-y-return to ALOM" "\c"
=====
(with /usr/local/bin/chat built from conserver-8.8.1/contrib/chat).

On a vaguely related note I've got some hacks-in-progess to deal with
the b1600's system controller -- it wants you to connect, log in, and
utter "console -f sN" to get to the console of blade N.

The main part of it is to add an "initsubst" akin to execsubst,
allowing parameters to the initcmd.

A couple things have made this messy:
- b1600 blades are numbered 0..15, while conserver thinks
physical terminal server ports always start at 1
- a portinc of 0 is expressly disallowed

- Bill

On Wed, Feb 18, 2004 at 03:19:17PM -0500, Bill Sommerfeld wrote:
> On a vaguely related note I've got some hacks-in-progess to deal with
> the b1600's system controller -- it wants you to connect, log in, and
> utter "console -f sN" to get to the console of blade N.

since i haven't gotten to tinker with an alom-based system or a b1600, i
took a quick look and the docs for the b1600 and they say you can access
the consoles of the blades via ports 2300-2315. looks like you still
have to log in, so the chat script would be useful, but it might be
easier than the 'console -f sN' method and integrating that into an
initcmd script.

http://www.sun.com/products-n-solutions/hardware/docs/html/817-3589-11/blade_switch_console.html#12556

> The main part of it is to add an "initsubst" akin to execsubst,
> allowing parameters to the initcmd.

interesting idea...i now understand how clustered/embedded systems could use
something like that.

> A couple things have made this messy:
> - b1600 blades are numbered 0..15, while conserver thinks
> physical terminal server ports always start at 1
> - a portinc of 0 is expressly disallowed

something that may help...you can set portbase to -1 and portinc to 1,
which would allow you to use ports 1-16 in the conserver.cf file and it
would calculate 0-15 for substitutions (i was originally thinking of
device files /dev/ttyC0 through /dev/ttyC7, etc). not perfect, but a
possibility.

Bryan

On Wed, Feb 18, 2004 at 03:19:17PM -0500, Bill Sommerfeld wrote:
> On a vaguely related note I've got some hacks-in-progess to deal with
> the b1600's system controller -- it wants you to connect, log in, and
> utter "console -f sN" to get to the console of blade N.

since i haven't gotten to tinker with an alom-based system or a b1600, i
took a quick look and the docs for the b1600 and they say you can access
the consoles of the blades via ports 2300-2315. looks like you still
have to log in, so the chat script would be useful, but it might be
easier than the 'console -f sN' method and integrating that into an
initcmd script.

http://www.sun.com/products-n-solutions/hardware/docs/html/817-3589-11/blade_switch_console.html#12556

> The main part of it is to add an "initsubst" akin to execsubst,
> allowing parameters to the initcmd.

interesting idea...i now understand how clustered/embedded systems could use
something like that.

> A couple things have made this messy:
> - b1600 blades are numbered 0..15, while conserver thinks
> physical terminal server ports always start at 1
> - a portinc of 0 is expressly disallowed

something that may help...you can set portbase to -1 and portinc to 1,
which would allow you to use ports 1-16 in the conserver.cf file and it
would calculate 0-15 for substitutions (i was originally thinking of
device files /dev/ttyC0 through /dev/ttyC7, etc). not perfect, but a
possibility.

Bryan

> since i haven't gotten to tinker with an alom-based system or a b1600, i
> took a quick look and the docs for the b1600 and they say you can access
> the consoles of the blades via ports 2300-2315. looks like you still
> have to log in, so the chat script would be useful, but it might be
> easier than the 'console -f sN' method and integrating that into an
> initcmd script.

Somehow I missed that in my skim through the docs.. d'oh.

> > The main part of it is to add an "initsubst" akin to execsubst,
> > allowing parameters to the initcmd.
>
> interesting idea...i now understand how clustered/embedded systems could use
> something like that.

> something that may help...you can set portbase to -1 and portinc to 1,
> which would allow you to use ports 1-16 in the conserver.cf file and it
> would calculate 0-15 for substitutions (i was originally thinking of
> device files /dev/ttyC0 through /dev/ttyC7, etc). not perfect, but a
> possibility.

This is only really "safe" if the end users never see the alternate
1..16 numbering. (if folks have to operate simultaneously in 0-based
and 1-based numbering space, i can see unfortunate accidents because,
among other things, the system controller lets you power cycle
blades...)

What I'm doing for now is to map 16 to 0, and 17 and 18 to
the switch consoles..