How to Add a Favicon in Ruby on Rails Apps

Favicons are this nifty little icons on the tab of your browser to help give a little personalized identity rather than the blank page one which is the default

This is one of the super fast things to fix yet I forget every time I build out a Rails app. Favicons can be created with a plethora of different sites. I’m old school and keep using DynamicDrive (http://tools.dynamicdrive.com/favicon/) as it has limited advertising and junk on the site.

The code block is super easy to remember…except when I need to remember it, so here it is:

<%= favicon_link_tag asset_path('image-name.ico') %>

Here are the steps to set up your favicon in your Rails app:

  1. Generate your icon
  2. Copy the icon to the app/assets/images folder
  3. Create the pointer in the HEADsection of your app/views/layouts/application.html.erb file as shown here:

Reload the server your server and you’re off to the races!  Once you restart your app you should see your new icon appear. There may be some delay because some browsers (Chrome being the main culprit) believe in caching everything to save you time on loading. This creates problems because sometimes the cache invalidation takes a while when you legitimately want to see an update.

This will be the end result:

Hopefully this is helpful and saves you a little hunting for the solution.




Installing PowerCLI 6.5.x on Windows Server 2012 R2 after Find-Module Error

Now that PowerCLI is part of the PowerShell Gallery, you can install it using the native module installer…but there’s a catch. Windows Server 2012 R2 requires a couple of minor updates to get this process underway. You’ll know really quickly if you open up your PowerShell terminal or PowerShell ISE (as Administrator) and try the following command:

Find-Module -name VMware.PowerCLI

The issue is easily solved be deploying a more recent installer for the PackageManagement PowerShell Modules. Download the installer using this link and run the install:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Select the Download within the page once you’re there:

Choose the x64 version (assuming you’re running a 64-bit OS):

Run through the installation and accept the defaults. Nothing significant to worry about with this file as it’s a necessary update for what we need to do.

If you run the Find-Module command again, you’ll see a much better result. You’ll be prompted to update your NuGet components which are used to pull resources from the PowerShell Gallery. Accept the update and then we can keep going:

Time to get back to the issues. Just relaunch your PowerShell terminal or ISE as an Administrator. We are running as Administrator so that we install the module for all users of the server. If you only want to run for your user then run your PowerShell session as your regular user and add -scope CurrentUser to the Install-Module command. Run the following to install for all users:

Install-Module -name VMware.PowerCLI

Now we have to import the module into our session using the Import-Module -name VMware.PowerCLI command:

Just like that, you’re up to date and running the latest and greatest PowerCLI goodness. Happy scripting!




Getting Terraform Provisioning Parameters from the Packet.net API

Provisioning on Packet.net is super easy using Terraform. One of the tricks you will need to know up front is that for Terraform and for many other provisioning tools, you need to provide a minimum set of parameters to launch.

As a minimum, you need to provide these following parameters as shown in the Terraform docs for the Packet provisioner:

  • hostname – gotta name ’em all
  • project_id – you need to know, or create the project to launch into
  • facility – which location are you deploying into? (EWR1, SJC1, etc.)
  • plan – which node type?
  • billing_cycle – hourly or monthly
  • operating_system – which OS will the node run?

Some are simple to use because they are your criteria. We choose the hostname, and we choose the billing cycle as either a static choice of hourly or monthly. How can we get the other details about our deployment? You can gather some data using a browser such as browsing to your project and then pulling the project ID from the URL. That still leaves us in search of the plan type, operating_system, and facility.

For completeness, let’s learn how to simply gather all four items (operating system list, project ID, plan types, facility) from the Packet.net API.

You’ll need a terminal session, your API key to query the Packet.net API, and the JQ tool for parsing out JSON results into something a little more friendly.

Querying the API is as easy as sending your token to the API using the cURL command and selecting which entities you want to query. This is the basic framework:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/OBJECT'

Now we can dig into the four easy examples we have.

Finding the Packet.net Facility Name

The simple one-liner will pull a JSON result that gives you the locations and subsequent Facility name that you can use and then parses out just the location codes to use. If you remove the '.facilities[].code' portion of the command it will show you the full pretty-printed JSON results including the full facility descriptions.

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/facilities' | jq '.facilities[].code'

Finding the Packet.net Project ID

You’ll want the full JSON result so you can choose from your active projects if you have more than one. Just drill into the JSON results and you can locate the id field:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/projects' | jq

Finding the Packet.net Plan Names

Plans don’t shift around too much, just like facilities. Here is the simple query to get all the plan names and match them to what node type you want to use:

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/plans' | jq '.plans[].slug'

Finding the Packet.net Operating System Types

By now, you can guess where we are going wth the next one. Query the API, parse out the results, and provide the slugs for the Operating System names which we will use for Terraform and other provisioning tools which consume the Packet API.

curl -s -X GET -H 'X-Auth-Token: YOURAPITOKEN' 'https://api.packet.net/operating-systems' | jq '.operating_systems[].slug'

The result will give you all of the slug names that are usable as the operating_system parameter. In the case of vSphere 6.5, it happens to be vmware_esxi_6_5 which may not have been obvious if you were to try guessing it out.

Now you can take those easy JSON results and feed them into a Terraform file or you may also use these raw queries as part of other configuration management and provisioning solutions. Hope you find this helpful!

Also, you can sign up for Packet.net to kick the tires on this goodness and you can use VDM25 as a referral code to get a 25$ credit to use. Make sure you tell them DiscoPosse and the Virtual Design Master crew sent you!




Setting up a Slack WebHook to Post Notifications to a Team Channel

If ChatOps is something you’ve been hearing a lot about, there is is a reason. Slack is fast becoming the de facto standard in what we are calling ChatOps. Before we go full out into making chatbots and such, the first cool use-case I explored is enabling notifications for different systems.

In order to do any notifications to Slack, you need to enable a WebHook. This is super easy but it made sense for me to give you the quick example so that you can see the flow yourself.

Setting up the Slack Webhook

First, we login to your Slack team in the web interface. From there we can open up the management view of the team to be able to get to the apps and integrations. Choose Additional Options under the settings icon:

You can also get there by using the droplets in left-hand pane and selecting Apps and Integrations from the menu:

Next, click the Manage button in the upper right portion of the screen near the team name:

Select Custom Integrations and then from there click the Incoming WebHooks option:

Choose the channel you want to post to and then click the Add Incoming WebHooks Integration button:

It’s really just that easy! You will see a results page with a bunch of documentation such as showing your WebHook URL:

Other parts of the documentation also show you how to configure some customizations and even an example cURL command to show how to do a post using the new WebHook integration:

If you go out to a command line where you have the cURL command available, you can run the example command and you should see the results right in your Slack UI:

There are many other customization options such as which avatar to use, and the specifics of the command text and such. You can get at the WebHook any time under the Incoming WebHooks area within the Slack admin UI:

Now all you have to do is configure whatever script or function you have that you want to send notifications to Slack with and you are off to the races.