Please forgive the ignorance of a sales guy lurking an engineers' discussion list...
Why would you want this type of solution instead of/in addition to FilerView? Granted, FilerView is network-bound (correct?), but if you need to dial in under a complete network outage wouldn't any RAS/terminal server solution do? (I'd be concerned about security issues with my filer console ports connected indirectly to a modem, though.) For those familiar with other remote management solutions, how does NetApp's remote manageability compare with, say, Compaq's Remote Insight Board Lights Out Edition? TIA. Joe
Joe Luchtenberg Dataline, Inc. 757.858.0600 757.285.1223 (cell) 757.858.0606 (fax) joe.luchtenberg@data-line.com www.data-line.com
-----Original Message----- From: Ronan Mullally [mailto:ronan@online.ie] Sent: Monday, April 02, 2001 12:29 PM To: Martin Hughes Cc: 'toasters@mathworks.com' Subject: Re: Filer Serial Connectivity
On Mon, 2 Apr 2001, Martin Hughes wrote:
We have 4 clustered F840Cs in our environment. As a backup connection method, we're looking at some type of terminal server that we can connect the filers to that will present the filers serial ports as IP addresses
that
we can connect to , in order to view the bootup messages etc, with a modem hookup in case of complete network failure. Does anyone else out there
have
any recommendations on make/model of equipment?
We're using a Linux box with a Cyclades multiport serial card and a utility called 'conserver'. The Cyclades card will connect to up to 64 devices. Conserver allows multiple users access the console ports of the various devices over the network and logs every character that traverses the console connection to local disk.
The hardest part of the whole thing was figuring out the pin-outs for each device...
-Ronan
Why would you want this type of solution instead of/in addition to FilerView?
Some of us old die-hard command-line guys have never used FilerView. I personally think the whole GUI/WWW thing is a fad. :-)
... Granted, FilerView is network-bound (correct?), but if you need to dial in under a complete network outage wouldn't any RAS/terminal server solution do? (I'd be concerned about security issues with my filer console ports connected indirectly to a modem, though.)
For me it's the convenience of having one box for talking to my SPARCs, Filers, routers/switches, UPSes, etc. It's all about being able to get to the PROM. :-) Plus it's a multi-function solution: Having a couple of modems - one for dialout to send text messages to pagers or cell phones, and one for dialin (with dail-back) to give access when the external connectivity is down is nice. _Logging_ your console output is a big plus. Being able to run monitoring apps or catch SNMP traps on the console/paging server is a benefit. A standalone terminal server isn't really designed to do that. And the 'conserver' package lets multiple people view (many readers/one writer) a single console, which is neat.
More importantly, if the network is hosed on a machine the serial console is still a way to unwedge things. Upgrading IPFilter or SSH or renumbering a machine without a reboot is kinda cool - you can "ifconfig down" to your heart's content without sawing off the branch you're sitting on. :-)
That's just my reasoning, anyway. To each his own, eh?
-- Chris
-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
On Mon, Apr 02, 2001 at 12:01:43PM -0700, Chris Lamb wrote:
Some of us old die-hard command-line guys have never used FilerView. I personally think the whole GUI/WWW thing is a fad. :-)
Hoo Rah.
Gotta feel sorry for those Windows admins who actually have to show up in a machine room at 2am to fix something. :)
Zach Metzinger UNIX System Administrator White Rock Networks
"skeezics" == Chris Lamb skeezics@measurecast.com writes:
Why would you want this type of solution instead of/in addition to FilerView?
skeezics> Some of us old die-hard command-line guys have never used skeezics> FilerView. I personally think the whole GUI/WWW thing is a skeezics> fad. :-)
Nevermind that FilerView isn't going to help much if 1) you're connecting through a dumb terminal over 9600baud modem or 2) need to get to the serial prompt or 3) don't have access to a windoze box.
Despite the abundance of Microsoft product, not everyone uses them.
skeezics> More importantly, if the network is hosed on a machine the skeezics> serial console is still a way to unwedge things. Upgrading skeezics> IPFilter or SSH or renumbering a machine without a reboot is skeezics> kinda cool - you can "ifconfig down" to your heart's content skeezics> without sawing off the branch you're sitting on. :-)
That, too... taking down the interface you're connecting through can make for a long evening. ;-)
K.
On Mon, 2 Apr 2001, Joe Luchtenberg wrote:
Please forgive the ignorance of a sales guy lurking an engineers' discussion list...
Why would you want this type of solution instead of/in addition to FilerView? Granted, FilerView is network-bound (correct?), but if you need to dial in under a complete network outage wouldn't any RAS/terminal server solution do? (I'd be concerned about security issues with my filer console ports connected indirectly to a modem, though.) For those familiar with other remote management solutions, how does NetApp's remote manageability compare with, say, Compaq's Remote Insight Board Lights Out Edition? TIA. Joe
I think most of the reasons for this have already been covered. Mine are:
- GUIs suck (I'm a command line weenie).
- You can invariably do a lot more from the console that you can via a GUI.
- A console server gets you out of band access to your devices. Throw in a (properly secured) modem and you don't even need a functioning network, or a functioning IP stack on either end to be able to access your boxes.
- If your hardware has the necessary functionality you can do anything that doesn't require physical access remotely (including powering up and down devices).
- The conserver package we use allows every single command and every character of output to be logged to disk, so when things go wrong you can trace back *exactly* what has happened.
-Ronan
Ronan Mullally wrote:
On Mon, 2 Apr 2001, Joe Luchtenberg wrote:
Please forgive the ignorance of a sales guy lurking an engineers' discussion list...
Why would you want this type of solution instead of/in addition to FilerView? Granted, FilerView is network-bound (correct?), but if you need to dial in under a complete network outage wouldn't any RAS/terminal server solution do? (I'd be concerned about security issues with my filer console ports connected indirectly to a modem, though.) For those familiar with other remote management solutions, how does NetApp's remote manageability compare with, say, Compaq's Remote Insight Board Lights Out Edition? TIA. Joe
I think most of the reasons for this have already been covered. Mine are:
- GUIs suck (I'm a command line weenie).
Not to mention that for those of us who can type, old programmer etc., command line if much faster. With a couple of "for" loops, sed, and awk, I can make the same changes to all 35 of my filers within seconds and modify the necessary files at the same time. This is a time saver. Even if I have to telnet into each filer, such as changing the root password, I just use a for loop to telnet into each filer.
One reason that I do like the GUIs is because I have a lot of new guys coming into the group and I can, as I have done in the past, modified the web interface to disallow the new guys from making system modifications through the web interface.
You can invariably do a lot more from the console that you can via a GUI.
A console server gets you out of band access to your devices. Throw in a (properly secured) modem and you don't even need a functioning network, or a functioning IP stack on either end to be able to access your boxes.
If your hardware has the necessary functionality you can do anything that doesn't require physical access remotely (including powering up and down devices).
The conserver package we use allows every single command and every character of output to be logged to disk, so when things go wrong you can trace back *exactly* what has happened.
-Ronan
Just to add my two cents in here.
I often use FilerView as a toll for familiarizing cutomers with the filer. You can click on things and see what's going on. It steps up the learning curve. But there's nothing like a good Unix guy (girls included) working from the command line to make any system really do things. The difference is that when you use a GUI you sort of request things. When you use the command line you tell the system what to do. Why do you think they call it a "command" line?
As for the dial-in thing, That is the old way of doing things. Today you want to leverage your network to do things. I think that filers should have an option to hook a modem directly up to the console port, but the usefulness of such a feature is pretty limited. The product design is network centric. In the old days the network used to be unreliable. Today's switched netwoorks are probably the mostreliable part of the computing infrastructure. Except of course for your filers ;-)
Paulb Netapp Guy
-----Original Message----- From: owner-dl-toasters@netapp.com [mailto:owner-dl-toasters@netapp.com]On Behalf Of G D Geen Sent: Tuesday, April 03, 2001 8:32 AM To: 'toasters@mathworks.com' Subject: Re: Filer Serial Connectivity
Ronan Mullally wrote:
On Mon, 2 Apr 2001, Joe Luchtenberg wrote:
Please forgive the ignorance of a sales guy lurking an engineers' discussion list...
Why would you want this type of solution instead of/in addition to FilerView? Granted, FilerView is network-bound (correct?), but if you need to dial in under a complete network outage wouldn't any RAS/terminal server solution do? (I'd be concerned about security issues with my filer console ports connected indirectly to a modem, though.) For those familiar with other remote management solutions, how does NetApp's remote manageability compare with, say, Compaq's Remote Insight Board Lights Out Edition? TIA. Joe
I think most of the reasons for this have already been covered. Mine are:
- GUIs suck (I'm a command line weenie).
Not to mention that for those of us who can type, old programmer etc., command line if much faster. With a couple of "for" loops, sed, and awk, I can make the same changes to all 35 of my filers within seconds and modify the necessary files at the same time. This is a time saver. Even if I have to telnet into each filer, such as changing the root password, I just use a for loop to telnet into each filer.
One reason that I do like the GUIs is because I have a lot of new guys coming into the group and I can, as I have done in the past, modified the web interface to disallow the new guys from making system modifications through the web interface.
You can invariably do a lot more from the console that you can via a GUI.
A console server gets you out of band access to your devices. Throw in a (properly secured) modem and you don't even need a functioning network, or a functioning IP stack on either end to be able to access your boxes.
If your hardware has the necessary functionality you can do anything that doesn't require physical access remotely (including powering up and down devices).
The conserver package we use allows every single command and every character of output to be logged to disk, so when things go wrong you can trace back *exactly* what has happened.
-Ronan
On Tue, 3 Apr 2001, Paul Brosseau wrote:
As for the dial-in thing, That is the old way of doing things. Today you want to leverage your network to do things. I think that filers should have an option to hook a modem directly up to the console port, but the usefulness of such a feature is pretty limited. The product design is network centric. In the old days the network used to be unreliable. Today's switched netwoorks are probably the mostreliable part of the computing infrastructure. Except of course for your filers ;-)
I'd consider out of band modem access to be there not for when the network screws up, but for when I screw up the network... :)
Our console server has saved my bacon at least two or three times over the past 18 months. It also allows me to completely reconfigure our network (upgrade switch / router / load balancer firmware, or play with internal routing for example) without having to be onsite.
My one gripe about filers in this regard is that it's not possible to manipulate the power supply remotely. All of our other servers (HP 9000s and Netservers) allow me to literally power them down and bring them back up again. Very handy in the unlikely event of the machine completely locking up.
-Ronan
Ronan Mullally wrote:
My one gripe about filers in this regard is that it's not possible to manipulate the power supply remotely. All of our other servers (HP 9000s and Netservers) allow me to literally power them down and bring them back up again. Very handy in the unlikely event of the machine completely locking up.
-Ronan
Take a look at http://www.baytechdcd.com. They have a powerstrip with an ethernet connection. You can telnet into it and control each receptacle is individually.
barry
On Tue, 3 Apr 2001, Ronan Mullally wrote:
My one gripe about filers in this regard is that it's not possible to manipulate the power supply remotely. All of our other servers (HP 9000s and Netservers) allow me to literally power them down and bring them back up again. Very handy in the unlikely event of the machine completely locking up.
Aside from the managed power strip suggestions from others (which may not always be feasible or desireable in every situation), I would like to see lights-out management (LOM) ability on the filers. Many PC hardware vendors do it now, and our Netra t1's have that capability too. As long as the server is able to draw power, the serial port (and the management interface) is available, even if the rest of the server itself is not powered up.
-
Barry Lustig -
Brian Tao -
Chris Lamb -
fubar＠pir.net -
G D Geen -
Joe Luchtenberg -
Metzinger Zach -
Paul Brosseau -
Ronan Mullally