Mailing List Archive: conserver extras

conserver extras

Nov 17, 2008, 4:47 AM

Post #1 of 6 (5145 views)

Dear Conserver users/devs,

I manage a largish (about 9k nodes, constantly growing) remote console
installation here at CERN. Clients are, for the smaller part, disk
arrays and such (with serial console) but mostly Linux PCs (serial
and/or IPMI SOL consoles). We have one "headnode" (a Linux PC with
optional multiport serial cards) every 40..200 clients where server code
gathers console logs and allows user access to consoles.

Our current software has its limitations and I'm looking for an
alternative. I came accross conserver which seems to be a nice fit for
us, with a small set of addons and packaging. This is where I'd like
your input and comments.

Please find a patch at http://cern.ch/ahorvath/rpms/conserver/ which
does the following:
- run conserver as user 'uucp', not as root (modified RedHat init
script -- we run Scientific Linux aka recompiled RHEL)
- also, 'service conserver restart' will work even if conserver wasn't
running
- a wrapper script around ipmitool, with its own config file, so that
IPMI passwords are not exposed to users and special options (e.g. "-o
intelplus" can be passed on where needed. The same script can, and
will, be eventually used to use ssh as a transport (e.g. for SUN
machines without IPMI SOL)
- cleanup :) of the default config files
- a logrotate plug-in
- provide a 'console.cf' that connects to localhost by default
There's also a SPEC file there which is a modified version of what the
DAG RPM repository carried. (In fact the patch is against the DAG
version, if it's any different from the original. The source RPM is also
there for your convenience.)

I plan on configuring this all via a component of the Quattor system
(http://quattor.org) that we use for all node configuration.

I'd be happy to have your criticism on the changes :-) and also to
contribute these back to upstream if the developers accept them.
The Quattor component is also available.

Please note that this is not widely-tested code yet, I'm merely
preparing for more tests by packaging everything.

Cheers,

Andras HORVATH

--
Andras HORVATH
Systems engineer, CERN IT FIO
Tel: +41 22 767 4290
Fax: +41 22 766 9154
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Re: conserver extras [ In reply to ]

wernli at in2p3

Nov 17, 2008, 6:14 AM

Post #2 of 6 (4962 views)

Permalink

Hi,

On Mon, Nov 17, 2008 at 01:47:33PM +0100, Andras.Horvath@cern.ch wrote:
> optional multiport serial cards) every 40..200 clients where server code
> gathers console logs and allows user access to consoles.

How do you sync conserver.cf among conservers?

> - run conserver as user 'uucp', not as root (modified RedHat init
> script -- we run Scientific Linux aka recompiled RHEL)

er... why on earth uucp?

> - a wrapper script around ipmitool, with its own config file, so that
> IPMI passwords are not exposed to users and special options (e.g. "-o
> intelplus" can be passed on where needed. The same script can, and
> will, be eventually used to use ssh as a transport (e.g. for SUN
> machines without IPMI SOL)

I have working wrapper scripts around IPMI, SUN ALOM, ILOM, and
V[24]0z SP, IBM e32[56] and ls20 bladecenter. Some are already in
conserver.com/contrib. Feel free to contact me if you're interested.

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Re: conserver extras [ In reply to ]

Andras.Horvath at cern

Nov 17, 2008, 6:40 AM

Post #3 of 6 (4955 views)

Permalink

On Mon, Nov 17, 2008 at 03:14:16PM +0100, Fabien Wernli wrote:

> How do you sync conserver.cf among conservers?

I don't. Each headnode only knows only its own clients. From the same
central database that is used to configure the headnodes, a DNS alias is
registered as "myclienthost.headnode.cern.ch" to point to the actual
headnode, and this is what end users use to actually connect to the
respective consoles.

I could, I suppose, generate one large conserver.cf everywhere, but that
would mean having to update ~200 headnodes whenever anything changes.

> > - run conserver as user 'uucp', not as root (modified RedHat init
> > script -- we run Scientific Linux aka recompiled RHEL)
>
> er... why on earth uucp?

Because it's there and unused :), and because ttyS devices are
660 root:uucp by default in RHEL5. Why not?

> I have working wrapper scripts around IPMI, SUN ALOM, ILOM, and
> V[24]0z SP, IBM e32[56] and ls20 bladecenter. Some are already in
> conserver.com/contrib. Feel free to contact me if you're interested.

Gah, I haven't noticed that link :)

I had a look of what's up there, and I mostly don't need that (the most
common use case is standard serial or standard IPMI 2.0 SOL). The ILOM
one certainly looks interesting, but how do you pass
username/password/key to ssh?

BTW, my Quattor component generates proper exec lines directly into
conserver.conf for Xen VMs (no wrapper needed). The Xen dom0 is the
headnode for its domU virtual machines.

Andras
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Re: Re: conserver extras [ In reply to ]

wernli at in2p3

Nov 17, 2008, 6:59 AM

Post #4 of 6 (4959 views)

Permalink

Hi,

On Mon, Nov 17, 2008 at 03:40:10PM +0100, Andras.Horvath@cern.ch wrote:
> I don't. Each headnode only knows only its own clients. From the same
> central database that is used to configure the headnodes, a DNS alias is
> registered as "myclienthost.headnode.cern.ch" to point to the actual
> headnode, and this is what end users use to actually connect to the
> respective consoles.

Our conservers share the same conserver.cf using crond and cvs.
The nice part is being able to 'console myserver' on any of the conservers
without knowing which console is being served by which conserver.

> Because it's there and unused :), and because ttyS devices are
> 660 root:uucp by default in RHEL5. Why not?

Fair enough, but conserver isn't intended solely for linux/rhel so I guess
Bryan wouldn't want that in the common source tree.

> I had a look of what's up there, and I mostly don't need that (the most
> common use case is standard serial or standard IPMI 2.0 SOL). The ILOM
> one certainly looks interesting, but how do you pass
> username/password/key to ssh?

It's an expect tcl script.
I tried these sunoem sshkey ipmi commands on some X4500 without success.
Also Sun promised some development to be made for IPMI SOL to work, but I
wouldn't expect too much from their side.

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Re: Re: conserver extras [ In reply to ]

Andras.Horvath at cern

Nov 17, 2008, 7:23 AM

Post #5 of 6 (4947 views)

Permalink

> Our conservers share the same conserver.cf using crond and cvs.
> The nice part is being able to 'console myserver' on any of the conservers
> without knowing which console is being served by which conserver.

At the moment we log in to the headnode interactively (there's a client
wrapper script around 'ssh -t ${client}.headnode.cern.ch -- console
${client}' or somesuch).

This works just as well and it minimizes the times stuff needs to be
regenerated and restarted. (Again, we have 9000+ clients and 200+
headnodes, and yes, the configuration changes often as machines are
reallocated, renamed, moved, installed or retired etc.)

> > Because it's there and unused :), and because ttyS devices are
> > 660 root:uucp by default in RHEL5. Why not?
>
> Fair enough, but conserver isn't intended solely for linux/rhel so I guess
> Bryan wouldn't want that in the common source tree.

No, this stuff is in contrib/, a redhat-specific init script as well as
a (redhat- or RPM-specific :) spec file. (My "patch" does not touch
actual source code.) These are just each set up so that running as
non-root works out of the box, logrotate rotates in the right directory
etc.

However, I feel that all these OS-specific packaging details and
good defaults are what make conserver actually usable if you have a
larger farm (the Debian wrap-up is also neat, btw.) If there's no
one to look after the package in each distribution we may want to
include these extras WITH the source code, so that people can create
their binary packages more easily.

> > I had a look of what's up there, and I mostly don't need that (the most
> > common use case is standard serial or standard IPMI 2.0 SOL). The ILOM
> > one certainly looks interesting, but how do you pass
> > username/password/key to ssh?
>
> It's an expect tcl script.

Er.. meaning? Do user/pass need to be hardcoded in the script?

Andras
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Re: Re: Re: conserver extras [ In reply to ]

wernli at in2p3

Nov 17, 2008, 7:48 AM

Post #6 of 6 (4942 views)

Permalink

On Mon, Nov 17, 2008 at 04:23:36PM +0100, Andras.Horvath@cern.ch wrote:
> This works just as well and it minimizes the times stuff needs to be
> regenerated and restarted. (Again, we have 9000+ clients and 200+
> headnodes, and yes, the configuration changes often as machines are
> reallocated, renamed, moved, installed or retired etc.)

Well, conserver just gets a signal and (re)starts consoles which need to be

> No, this stuff is in contrib/, a redhat-specific init script as well as
> a (redhat- or RPM-specific :) spec file. (My "patch" does not touch

I'm relieved :)

> one to look after the package in each distribution we may want to
> include these extras WITH the source code, so that people can create
> their binary packages more easily.

I agree

> Er.. meaning? Do user/pass need to be hardcoded in the script?

they need to be _somewhere_
anyuser can't read them and they don't appear in the process list

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users