Lately we’ve been working on an app that we are now happy to announce as FlyRight.
FlyRight is a mobile app (with accompanying web site) designed to use the power of real-time services to help improve airline travel, allowing you to be heard by the airlines when you need to be: on the spot.
We want to help make travelling a smoother and more enjoyable experience by giving you power when you need it. If you want to be heard, FlyRight is for you.
We’ll have more updates soon so for now, register your interest at FlyRight to hear all about the launch. You can also keep up to date on FlyRight’s Twitter and Facebook page.
Our DEVOPS team manage a NetApp FAS2020 filer for a customer, and recently our network monitoring systems began reporting an issue connecting to the device’s BMC (Board Management Controller). This is the independent processor that provides the lowest level access to the system. In theory, if everything was to break and the machine was to blow up, we should be able to log into the BMC and find out what is going on. It’s an entirely separate computer tasked with providing a (secure!) back-door to the system in case of catastrophic failure.
Even though NetApp has a phenomenal reputation – at a technical seminar last year, a sales engineer said that no NetApp customer has ever lost data due to a hardware failure – I still don’t feel comfortable without access to the BMC.
Access to the BMC (on other NetApp devices the LOM controller is called a Remote Management Controller, or RMC) is via SSH, using naroot as the username. From here you can move “up the chain” to a system console, and use CTRL-G to move “down the chain” back to the BMC.
mlambie@prime:~$ ssh naroot@ilca-netapp-bmc
naroot@ilca-netapp-bmc's password:
=== OEMCLP v1.0.0 BMC v1.2 ===
bmc shell ->
bmc shell -> system console
Press ^G to enter BMC command shell
Data ONTAP (ilca-netapp.thefrontiergroup.net.au)
login: root
Password:
ilca-netapp> Mon Mar 12 11:40:27 WST [console_login_mgr:info]: root logged in from console
ilca-netapp> <ctrl g>
=== OEMCLP v1.0.0 BMC v1.2 ===
bmc shell ->
The filer also allows management via SSH directly, and not through the BMC. I used this shell to restart the BMC.
ilca-netapp> bmc help status
bmc status
- Display status for a Baseboard Managment Controller (BMC).
ilca-netapp> bmc help reboot
bmc reboot
- Reboot the Baseboard Managment Controller (BMC)
ilca-netapp> bmc reboot
ilca-netapp> The BMC rebooted successfully
It looks like the SSH daemon was simply hung (it had an uptime of 270+ days prior to the reboot) and restarting the BMC through the management console in this way corrected the issues the monitoring systems were reporting.
