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.
In any given week our company is typically developing five projects at once, with teams of one to three. We run one-week sprints with a half day planning session on Monday morning, and a review session on Friday afternoon.
A sprint is the basic unit of development in Agile. Sprints tend to last between one week and one month and are a “timeboxed” development effort of a constant length.
Our sprint planning session is broken down as follows:
Product owner – prioritise and explain highest priority items in the product backlog (we use Pivotal Tracker). The team can ask questions at this point.
Product owner – set a sprint goal (what are we achieving this sprint).
Team – select Pivotal Tracker stories you can commit to, to attain that goal.
Team – demonstrate a solution to each story in the sprint and ensure no outstanding questions.
Our Friday afternoon review session:
Product Owner and Team - demo all completed stories.
Team – Review estimates from the sprint and note down how you went and how you can improve (if target not met).
Team – Review points missed from the sprint and why, and how you can improve on that for next sprint.
If you’re running sprints in your organisation do you do things a little differently? Drop us a line in the comments.
Have you ever created an application where users are trusted to upload their own avatars? Wouldn’t it be great if there was an easy way to ensure the avatar contains a person’s face?
Has Face is a neat little gem that uses the face.com API to ensure that an image contains a persons face. It’s very simple to use and can be easily integrated into an existing rails application.
To get started add the has_face gem to your Gemfile and run a bundle install
Now we’ll need to make a face.com developer account. You can signup for a free account over at face.com. Once you have signed up, place your API key and API secret in the initializer config.
The last option in the initializer (skip_validation_on_error) will change the behavior of has_face when an error occurs. If set to true, when an error occurs a warning will be logged to the logfile with detailed information about the failure and face validation will be skipped. This can be useful if you want your application to function if the API service is not reachable. If the value is false then an exception will be raised when an API call fails, this will allow you to manually handle the exception yourself, please check the documentation for details on the errors raised.
Once the initializer settings are setup then we can add face validation to a model. In the example below I’m using carrierwave to attach the image to the model but other image attachment gems should also work fine (anything that correctly responds to `path` should be OK).
That’s it, that’s all we need to have a functioning face validator. There are a few other options that I haven’t covered here in this short guide, please consult the readme for more detailed information.
Just upgraded to the newest RSpec (2.6.0) and found that RCov has stopped working completely? That’s what happened to me after running a bundle update. RCov refused to run, no error messages, just blank output.
In short: the new RSpec has been broken up into modules a tad more, the one that we require for rspec to run correctly ‘autorun’ is not included by default, so to solve this simply add require ‘rspec/autorun’ to the top of your spec_helper.
Sending iOS push notifications from a Rails application is very easy to do these days, thankfully there are many great Ruby gems that can be used to handle most of the magic for you. Recently I ran into the apn_sender gem which handles sending push notifications in a really neat way.
Sending push notifications directly from a Rails application can be slow and we probably don’t want to have the user waiting until the notification is sent, instead apn_sender can be setup to run a worker which is constantly connected to the apple push notification service. When there are new notifications to send, the notifications are queued up and sent through the always open connection that is maintained by the worker.
apn_sender uses redis as a message queue to keep track of the notifications waiting to be sent, you’ll need to install it before using the gem.
To add apn_sender in your Rails 3 application, just add the gem to your Gemfile. We’re going to need the daemons gem too so we’ll include that as well.
Now we can create our daemon which we will be using for sending push notifications, this can be placed anywhere, I’ve put mine in script/apn_sender. Make sure to add execute permission to the file after creating so we can run it.
Before the daemon can start running we’ll need to put our iOS push certificate into the application. Instructions for generating the certificates are available at the Apple Developer site. The certificates need to be placed inside of /config/certs and should be named apn_development.pem or apn_production.pem for production.
Once the certificates are in their correct locations, we can start up the daemon. The daemon does not know about the Rails environment so we need to specify this when starting it up. The daemon supports start, stop and restart commands. There is a verbose flag available to output more information (which can be helpful when debugging).
Our application is now set up to send push notifications, this can now easily be performed by adding a new notification to the queue. The notify method on the APN class will take a push notification token and then our parameters, we can specify the alert message to show the user, whether or not we want sound as well as the number to display on the badge icon. Anything else we pass to notify will be sent as metadata in the push notification. Here’s an example of creating a notification.
The worker should pick up the notification within a few seconds and send it off. The apn_sender has many other features that I haven’t covered, you can view the full documentation over at https://github.com/kdonovan/apn_sender.