I suspect it has been hard to miss that I’ve enjoyed playing with the Opengear advanced console management (ACM) servers lately and seeing what they are capable of doing. In a recent post I described creating outbound SSH ‘Call Home’ sessions to a linux server over 3G so that I could manage the devices even if my usual (LAN-based) connectivity had failed. I commented in that post that Opengear has a secure central management solution (CMS) which is where Call Home really comes into it own – and I mentioned that I didn’t have one so I wouldn’t be testing it.
Opengear apparently read this, and came to the rescue – they created an account on one of their Virtual Central Management Solution (VCMS) demo servers on the Internet so that I could configure my console servers to call home and be managed through that system. And so I did, and here’s what I think.
Opengear VCMS is now Opengear Lighthouse!
The first important thing to note is that the CMS / VCMS products have been rebranded and are now know as Opengear Lighthouse. VCMS (the version of CMS designed to run in your own virtual machine) is now Lighthouse VM, and their appliance (previously the CMS6100) has now diverged into two lines – Lighthouse Standard and Lighthouse Enterprise, both of which seem to be based on 1U Dell rackmount servers. I reproduce here Opengear’s table describing the differences between the three product lines:
Pricing for Lighthouse is, refreshingly, available right on the website. If you take a look at the pricing, you’ll see that Lighthouse VM is priced based on how many endpoints you want to manage, starting at $1500 for 10 devices and going up to $8,500 for 5000 devices, each for 1 year. There’s a 3 year option available ($2,400 to $13,600), and once the initial license expires, there’s a recurring annual licensing cost which runs from $750 (10 devices) to $4,250 (5000 devices). Still with me?
Lighthouse Standard and Lighthouse Enterprise – the appliances – are priced based on a mix of hardware and licensing cost. They are Dell servers, and where the Standard appliance sports a 1.9GHz Xeon and 2GB of RAM and is limited to 100 devices, the Enterprise appliance raises the bar to a Pentium G620 2.60GHz, 16GB or RAM, hardware RAID, dual power supplies, and up to 5000 devices. Nice – but costly. The base Enterprise model is $10,000 with a 1 year, 10-device license. With 5000 devices, that rises to $17,000. If you think about it, Lighthouse VM costs $1,500 for a 10-device license, so if you take that cost away from the base Enterprise model, the hardware component makes up $8500 of the cost – and that figure holds as you go up the licensed device table. In other words, if you can build/license/support an appropriate equivalent VMWare capable server for less than $8,500, it’s in your interests to look at Lighthouse VM so that you’re in control of the hardware costs – there’s neither a penalty nor a benefit in terms of licensing for choosing the VM option, which actually I think is a good thing.
I will refer to the product as VCMS for the rest of this post, as that’s what it was called when I wrote my notes, but you’ll know to look for Opengear Lighthouse if you want to find out more. And since the software is the same whether you run an appliance or a VM, any comments about VCMS apply equally to CMS (or now, any of the Lighthouse products).
VCMS
Opengear’s VCMS has Nagios at its core to perform monitoring and alerting on Opengear devices. This will be fairly obvious to anybody who has used Nagios before, as much of the data you view is pulled in from Nagios with a recognizable appearance. My VCMS instance had basic network configuration on it, but the rest would be down to me.
The appearance of VCMS is very familiar if you’ve worked on the console servers – the underlying menu system is the same, even though the options differ:
For my use, the first step was to configure a Call Home password on VCMS. In Configure > System Administration, you can set a password that remote systems use to login and offer themselves as candidates for remote management by VCMS:
Next up, configure my Console Servers to Call Home. This is less effort than when I connected to my own server – you just need an IP address and the Call Home password you set in the previous step:
Hit Apply and if everything is correct, the Console Server will log into VCMS and it will show up as a candidate device in Configure > Managed Console Servers:
At this point, the new remote device is not being managed – it’s simply a candidate for management. In the image above, there are two devices shown: Opengear1 is already being managed by VCMS, and the second (as yet unnamed) device shows under Remote Console Servers with its IP address, ready to be added. To manage the new device, I selected the appropriate device in the dropdown list of new servers, and click Add just below it. I now needed to configure more information about the server before it could be managed – most importantly, a Name, a Description and the remote root password. Once completed, I clicked Apply, and VCMS reached out to the Console Server through the open SSH connection and it polled the device for a range of information. After about 30 seconds, the screen refreshed and the device had been added as a Managed Console Server. Once I had added both devices, I started looking at what this management platform was actually offering me.
Tactical Monitoring Overview
The Tactical Monitoring Overview (Monitor > Tactical Overview) provides a general dashboard for the managed devices and the VCMS server itself. It isn’t visually exciting – a side effect of the standard Nagios presentation – but it does as least provide some of the key information about what is being monitored and the current service status. A slightly compressed view is shown below.
If you look closely under Services, there is apparently “1 Warning”. I really want this to show in yellow to draw attention to it, as I overlooked it a few times before spotting it. Once I saw it, clicking on the words “1 Warning” takes you to a page listing the current warnings. In this case, the warning is because the device Opengear2 has failed over to its Cellular 3G connection, and the output confirms that this happened 19m 22s ago:
Maps
Another Nagios function, the Monitor > Maps function shows a map of the managed devices in a variety of potential hierarchical views (e.g. Circular, Collapsed Tree, Balanced Tree, etc.). Nagios itself shows as the root, then hanging off that are the remote devices, and hanging off them in turn are any services being monitored through them – e.g. environmental sensors in this case. I suspect this display can be seriously customized, but out of the box it doesn’t do much for me:
In this case, I have enabled the environmental sensor on Opengear 2 (and it is being monitored), but I have not done so on Opengear1, hence it does not show. Does this help me understand better what’s going on? Perhaps in more complex environments where I can monitor, say, IP-PDU status through an Opengear console server – it might help by documenting where that connection and monitoring occurs. In my test setup, I feel that I gain very little from drawing a picture of the connections.
Hosts Summary
The next menu option is Monitor > Hosts. Looking at my list of hosts, the presence of a large X indicates that something is not being monitored on the device:
Hovering over the X, pop-up text confirms that “Checks of this host have been disabled“. Clicking on the X takes me to the Host monitoring configuration page where a current Host State and list of “Host Commands” is shown:
The Host Commands are all clickable actions to change the monitoring behavior. In this case I highlighted the option to enable active checks for the remote device. Somewhat confusingly, although the “Enable active checks of this host” option has a check mark on the left, that doesn’t mean it’s enabled. Instead, it signifies that this is an ‘enabling’ option. In the same way, ‘disabling’ commands have an X showing. I confess that I really dislike this approach to toggling options – and it’s Nagios rather than Opengear who is at fault here – but unfortunately by adopting Nagios as the underlying platform, this kind of idiocy comes by default out of the box. There are a few host commands that aren’t status toggles, and they are rightly listed in the Host Commands table. All in all, I could make it work, but I found myself getting very frustrated having to check status on the left, then find the appropriate option on the right to toggle it.
Services
The Monitor > Services tab digs another layer deeper and summarizes the status of the managed devices and the services within them:
You’ll notice that my 3G device is in network failover mode again, and that VCMS can also monitor the trigger actions on the console servers. I should add that although the environmental sensors reported a high temperature, I have since applied an offset to more correctly report the temperature where they are located.
Alerting
VCMS offers the usual Nagios alerting/escalation options, so that, for example, you could raise an alert if a device goes down. I won’t dwell on this other than to note that you can schedule downtime for devices so that reboots or firmware upgrades that generate unavailability (for example) won’t trigger alerts during the configured time.
Accessing Remote Devices
So much for monitoring, I suppose – it’s useful to know when there are connectivity issues on the remotely managed devices, but as I see it, the best reason to have VCMS running is to simplify remote access to the console servers – especially if they are behind a firewall and/or NAT deviceor if you don’t have a fixed IP on which to contact the console server. The outbound Call Home of the remote console server means that you don’t have to keep track of LAN and 3G IPs, and change how you connect depending on whether or not a device has failed over – instead, you can just select the device within VCMS and connect through to it.
Manage > Access Console Servers allows you connect to the remote console server via three options: Browse, Web Terminal or SSH.
Web Terminal creates an ssh connection to the console server via an embedded app in your web browser.Browse connects to the remote web UI, proxied via VCMS. A nice touch here is that you get a handy reminder in the header that you’re accessing the system remotely, and a link back to VCMS:
The final option, SSH, is an SSH:// URI – so as long as you have an appropriate handler configured in your browser you can use your preferred SSH client to connect to the VCMS on a particular TCP port that will proxy your connection through to the remote console server. If you don’t get on with the Web Terminal, that’s a very elegant way to connect.
You can also remotely access the serial ports themselves. By default, none of the serial ports are made available through VCMS, but when you configure the Managed Device, you can say how many ports should be made available. This is a curious option because rather than specifying which ports are available, you specify that the first n ports will be available. Clicking Web Terminal by the port name connects you to the remote serial port using the embedded web app again:
Remote Device Management
The Manage > Command Console Servers page allows more high level control of the remote console servers – rebooting, firmware upgrades and so on:
Since you can select multiple devices for an action, this could be a real time-saver in a large environment. You can also lock/unlock a user account on any selected devices. This in particular is a great feature to have – especially if you use local accounts and have a personnel change.
Configure > User Authorization
VCMS’ user management is interesting. When you manage a remote device, the user information – though I don’t think the passwords – from that device are synced to VCMS. It’s easy – optionally – to select a username, set a password, and give them permissions to login to VCMS. Note that this is not centralized user management. Changes made to users only apply to VCMS; access permissions and passwords on each remote device are unchanged. However, when you use the features to connect to remote ports, your username is used to determine which ports (for example) you can access based on the permissions that same username has on the remote device. Clearly this means that duplicating a username across devices is only a good idea if the same person uses the same account on every device (which you’d hope would be the case, but may rule out role-based access to local devices).
On VCMS you can put users into one of two roles: Users and Admin. The User role can see the Monitor, Reports, System and Manage menus, though some menu items will not be accesible even though they’re still listed. Meanwhile the Admin role gains the ability to access the device via VCMS.
I’d actually love to have centralized user management and automatic sync in VCMS, but I can see how it could get complicated very quickly given that you’d want to set up per-port permissions on every device. As it stands, it’s a handy way to pull in usernames without introducing typos. You can of course use TACACS, RADIUS and similar to authenticate users to VCMS, rather than local accounts.
Conclusions
If you stuck with me this far, thank you – I know it’s a bit dry, but I wanted to dig a little bit into the specifics of what you can achieve with VCMS, as I think it can be a little difficult to be clear on the benefits it offers. The demo that Opengear set me up with was very helpful in allowing me to get a better feel for what it could do.
Product Look and Feel
I liked that the look and feel of the menus matched that of the Opengear ACM console servers. However, I felt that while the parts of the UI that Opengear created were quite nicely done, I was underwhelmed by the management of the devices through the rather transparent rebranding of Nagios. Nagios is very customizable – and perhaps in a later release (maybe even in Lighthouse), Opengear has hopefully continued to refine the interface to make it simpler and clearer. As it is in this version (VCMS v3.6.0p0) I found the Nagios elements hard to navigate, illogically organized, and I was struggling constantly to find the right place in which to find information or configure a component. This is something that may become easier as my familiarity increases, but out of the box as a new user, it was bewildering.
Usefulness
As a platform with which to manage remote console devices, I think VCMS has a great use anywhere that you are using more than a handful of Opengear ACM servers. The ability to use Call Home to have an ‘always on’ connection to the device, maintain inventory, and to remotely access the devices and their ports from a central location is something I see as a big selling point. Do I need the uptime management? In theory, no – but the Call Home feature does make it very simple to ensure that devices are manageable by providing a secure tunnel from the remote device to VCMS – and indeed perhaps provides it in a way that would be difficult or time-consuming to set up without the automation it provides. That said, if you only have LAN-based devices (no 3G backup) and can directly access them from your management station, any existing management platform would be able to manage the device itself. What you would not get is the direct visibility of downstream managed devices like IP-PDUs, so if you’re running that kind of environment, there’s an obvious gain there.
Final Thoughts
I actually think VCMS does more than meets the eye in terms of making the ACM – and its downstream devices – manageable. The Nagios interface felt clumsy though, and while that’s not Opengear’s fault directly, it does suggest that there’s a lot of room for improvement in making it as easy to use as the ACM console servers themselves. I look forward to seeing what changes have been made in Lighthouse, but I suspect it will be a few revisions yet before the product truly comes into its own.
Disclosures
Opengear was a paid presenter at Networking Field Day 4, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were provided. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative. Opengear provided me with an entry-level console management device (ACM5004-G), and more recently an ACM5004-G-E and an ACM5504-5-G-W-I, all three of which I am using as test hardware to create the content for these posts. I mentioned a while back on Twitter that I wouldn’t be testing the cellular option on the ACM, as I didn’t have a suitable data SIM available. Shortly after that, the nice folks at Opengear got in touch with me and have lent me a SIM with which to do a little testing; again this has been done with no obligation, and my opinions remain my own. Similarly, Opengear made a demo server for VCMS available for me to try out, and I used that access as the basis for this post.
Please see my Disclosures page for more information.
Leave a Reply