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

RE: Ki Networks CLIM experiences

Matt Cheek cheek@mars-systems.com
Wed, 22 May 2002 12:03:09 -0700 (PDT)


Title: RE: Ki Networks CLIM experiences

I could not agree with you more, Ernie. I am a CLI guy through and through. CLIM provides both CLI console access -and- CLI configuration utilities in addition to the pretty GUIs. In fact, I use the CLIM CLI tool (clif) 95% of the time. (clif(1) is equivalent to Conserver's console(1) command.) CLIM provides both GUI and CLI access. The GUI is pretty much icing on the cake for me.

Also, while I don't use it, CLIM comes with (and installs) TightVNC. I imagine this is a very useful feature to those who like VNC.

And, just as an aside, there IS a product that will provide a serial console for Intel systems. It is the PC Weasel (http://www.realweasel.com/). Take a look.

Matt

-----Original Message-----
From: Ernie Oporto
To: users@conserver.com
Sent: 5/22/2002 2:26 PM
Subject: RE: Ki Networks CLIM experiences

My main concern in a console system is being able to control my target
servers in an extreme emergency where I most likely won't have access to
any GUI, but only to manage a server through the rawest of interfaces:
some commandline SSH backdoor?  That is where clicking on icons and
setting up interfaces through GUIs hits a brick wall, and conserver
comes through to save the day.  For the longest time, we were using an
older piece of software called "console" and when I changed companies, I
could not find that software anywhere until conserver popped back into
the scene.
 
Products like the digital KVM Kaveman from www.digitalv6.com
<http://www.digitalv6.com>  that use an open protocol like VNC are where
it's at because of how simple they make the product; I've found VNC
works nicely through SSH pipes to control Win2k servers in an emergency,
so we plan on adding that product to our network to manage our servers.
Like VNC it can also be managed through a web browser.  I'm not
interested in proprietary interfaces like those used by Avocent, because
if I am on the road and am nowhere near one of my systems, I know I can
pick up any machine and have access to my network tools from almost any
machine with Internet access.  If only Linux PCs had some sort of way to
interface a serial port like a Sun sparc system to be able to use
conserver.  I know they have console echoing on a serial port, but it's
not the same as doing a break sequence to drop to the EEPROM.  Digital
KVMs come close, though.
 
Ernie
 
 

-----Original Message-----
From: users-admin@conserver.com [mailto:users-admin@conserver.com]On
Behalf Of Matt Cheek
Sent: Wednesday, May 22, 2002 12:57 PM
To: 'users@conserver.com'
Subject: Ki Networks CLIM experiences




All,

This is simply an overview of my experiences with the CLIM console
management product from Ki Networks ( http://www.kinetworks.com
<http://www.kinetworks.com> ). These are only my observations and
opinions. Your mileage may vary.

Matt
--
Matthew Cheek          | Medical Archival Systems, Inc. (a.k.a. MARS)
Systems Analyst IV     | 1370 Beulah Road | Pittsburgh, PA 15235-5084
cheek@mars-systems.com | v:  412-473-6565 | f:  412-473-6538



Background:
I joined Medical Archival Systems, Inc. (part of University of
Pittsburgh Medical Center) in early 2000. At that time, MARS had
approximately 75 consoles (mostly UNIX systems and network gear such as
Cisco routers and switches) with about 60 of these consoles connected to
a couple of Xylogics Annex3 terminal servers. There was no console
management solution in place at the time and staff would simply telnet
directly to the terminal server port in order to connect to particular
consoles. Obviously this was an unworkable solution and I set out to
find and deploy a true console management solution. (I had used DEC's
Polycenter Console Manager (PCM) at two previous employers.) At the same
time, I continued to add console connections to existing and new
terminal servers.

Before beginning my search, I identified and ranked the desired
attributes:

1) Console Management - The console manager "manages" which terminal
server port is which console - no remembering which port is which

2) Console Control - Easily manage the console (e.g. review the last N
lines, send a "break" character, etc.)
3) Console Logging - Useful for diagnosing system crashes or for
auditing console access
4) Read-Only Console Connection - Provides the ability to watch over
another user's shoulder
5) Security Mechanism - Only permit authorized users to connect to a
console
6) Event Notification - Provide notification (e.g. email, pager) of
specific console text

My initial research focused on commercial console management solutions
including CLIM (Command Line Interface Manager) from Ki Networks and
ControlTower from Aurora Technologies. Unfortunately, while these
commercial products provided rich and robust console management
features, they were also prohibitively expensive for my environment
which had grown to 178 managed consoles. In Aug 2000, I discovered
Conserver via a mention on the Sun Managers mailing list.

Conserver, being an open source product, certainly met my unstated
requirement of low- or no-cost. In addition, Conserver appeared to meet
the first five requirements (i.e. Console Management, Control, Logging
plus Read-Only Connections and a rudimentary Security Mechanism). After
downloading, building, and installing the product, I was pleased to
discovered that Conserver did in fact meet my immediate needs.

Additionally, since the Conserver product does not currently provide any
sort of event notification, I deployed SWATCH (the Simple WATCHer,
http://www.oit.ucsb.edu/~eta/swatch/
<http://www.oit.ucsb.edu/~eta/swatch/> ) to address the Event
Notification requirement. SWATCH is an open source utility that watches
log files in real time for specific text matches and notifies you in a
pre-determined manner when a match is found.

I continued to use the combination of Conserver and SWATCH as my Console
Management Solution until the middle of May 2002.

In early May 2002, Ki Networks made an extraordinary offer to any active
Conserver user. They offered a complimentary, permanent license to
deploy their CLIM and NodeMonitor products in exchange for feedback on
how to improve CLIM. In addition, Ki Networks agreed to provide ongoing
support for these products.

Since CLIM was one of the commercial products I had evaluated in 2000, I
jumped at the offer and worked with Ki Networks to download and install
CLIM on an evaluation basis. Since I consider Console Management a
critical production facility, one of my minor concerns was understanding
the terms of use of this permanent license and the support options.
Happily, Ki Networks provided formal license and support documents that
were quickly approved by my management. Once the red tape was worked
out, I began planning the deployment of CLIM across my enterprise.

CLIM Deployment:
My current environment is four terminal servers with 178 managed
consoles.

The CLIM installation was nearly trouble free and within 15 minutes I
was able to start the Ki Works GUI to start adding consoles. It quickly
became apparent that CLIM is more that just a simple console manager.
CLIM is a comprehensive system management product that provides log file
management, event management and notification, and terminal server
management. Along with this comprehensiveness comes complexity. While
Conserver is driven by a fairly simple configuration file, CLIM is best
configured via the Ki Works GUI. (There is a CLI configuration utility,
but I've not explored its capabilities yet.)

Since my primary goal is console management, I started by creating
several console connections. The main interface to CLIM is a graphical
application (i.e. X. I believe there is also a Windows version if that
is your wont.) called "Ki Works". This is a very intuitive GUI for all
aspects of configuration and console management. The first step is to
define the terminal server(s). This is a simple task that is made easy
by predefined configurations for most popular terminal servers (e.g.
Xylogics, Cyclades, Lantronix, Cisco, etc). Once a terminal server is
defined, adding a console is just as simple. Simply name the console,
select the terminal server it is connected to, specify the port number
on the terminal server, and select the console's hardware and operating
system type. (The last two options instruct CLIM how to interact with
the console. For instance, how to send a break, what the boot prompt is,
etc.) After creating a console, double clicking on the resulting console
icon pops up a console window and off you go. There are actually several
methods of connecting to a console:

a)  Simple Text Connection in a window (i.e. xterm, dtterm)
b)  GUI connection in a small graphical app with drop-down menus for
issuing common commands such as sending a break, powering off a system,
etc.

c)  Read-Only Connection in a window
d)  Command Line from a shell prompt

and, most intriguing:

e)  Gang Connect which lets you connect to multiple consoles at once and
type the same commands into all connections. Very handy!

After running several weeks with just a handful of non-production
consoles to explore the product, I have scheduled the production cutover
for early June. At that time, I will shutdown Conserver and add all my
remaining consoles into the CLIM environment. Before that time, I will
explore the CLIM command line configuration program (climcp) which will
be necessary to quickly and accurately batch add 150+ consoles to the
CLIM configuration.

I continue to discover features and benefits of CLIM as I use the
product. For instance, the CLIM Event Management module (EVM) includes a
large set of preprogrammed console event types. For instance there are
over a hundred UNIX-specific events. Some examples include system panic,
file system full, etc. At the very least, these preprogrammed event
types provide an example of how to create custom,
application/environment specific event types.