• Skip to primary navigation
  • Skip to main content

jdgreen.io

The personal blog of James Green

  • Home
  • Technology
    • Announcements
    • Industry
    • Reviews/Guides
    • Tech Field Day
    • Interviews
  • Health
    • Food
    • Biohacking
    • Fitness
  • Faith
  • Book Notes
    • Business Books
    • Faith Books
    • Health Books
    • Technology Books
  • About
  • Show Search
Hide Search

Reviews/Guides

Fixing iDRAC Viewers on Mac with Hazel

James Green · May 31, 2016 ·

In my lab, I’ve got a couple of PowerEdge R610’s that include iDRAC interfaces for lights-out management. Unfortunately, the remote console is Java-based. They’re older servers (using the iDRAC 6 interface), and I hope that newer versions of the iDRAC console look more like 2016! The interface on my iDRAC 6 boxes is awful.

I’m a heavy OS X user, and as such I regularly run into problems with software that was designed with only the Windows user in mind. Using the remote console tool in my version of the iDRAC interface is a perfect example of this.

The Problem

When I try to launch a remote console, a .jnlp file is downloaded. This is a Java Web Start file that would allow me to save it and run the file any time to access the remote console. The connection information is appended to the filename when the file is downloaded. See the example below.

JNLP Download

I’ve never even seen this on a Windows machine, so it must be the case that the Java Web Start application on Windows knows how to handle this. But in the case of OS X, everything goes sideways. The extension isn’t recognized as .jnlp because of the additional periods in the IP address. OS X thinks this is a .12@atm-wi[…] file because it’s grabbing everything after the last period. As such, I can’t open the viewer without renaming the file.

For quite a while, I just dealt with this as another one of those things that I deal with for going against the grain when it comes to OS of choice. Each time I downloaded a new viewer, I would just go into my Downloads folder and rename the file, then launch it. But this morning I decided I didn’t want to deal with it anymore, so I came up with a fix.

Hazel, To the Rescue

If you’re an OS X user and you’ve never heard of Hazel, you’re missing out. Developed by the one-man team at Noodlesoft, Hazel is like a local IFTTT or Zapier. It’s mostly built for handling files, but you can have it kick off Applescript, Javascript, shell scripts, and more. Which means that really you can use files as triggers to automate just about anything with Hazel.

In this case, the fix is pretty simple. Chrome puts files that I download in my Downloads directory, so I just created a Hazel rule to watch the downloads folder for new remote console viewer files and rename them so that they work correctly. I tried to do this a while back with version 3 of Hazel, but I had a hard time because the filename is wonky and I couldn’t get the pattern matching right. Version 4 of Hazel was recently released, and it includes the ability to preview rule matching. Using the previews, I was able to make the correct rule in just a minute or two. But, I figured I’d share what I’m doing and save you the work. So behold! My Hazel rule for making iDRAC less of a pain to use on Mac.

Hazel Rule

This correctly identifies and renames these files to ‘iDRAC-Viewer-[increment counter to ensure uniqueness].jnlp’ Now after downloading, I can just go run the file like normal without screwing around with it 🙂

Backing up vPostgres Database

James Green · Aug 14, 2015 ·

Something I have learned over my career as a consultant is to back up everything before performing an upgrade, and then back it up again another way 🙂 There’s nothing worse than an upgrade going sideways and having no way to back out. Also, if you’re doing any sort of work in an enterprise setting, furnishing a back-out plan before you begin may well be a requirement. This is to ward off extended downtime and potential financial loss as a result. As deploying the vCenter Server Appliance (or whatever we’re calling it now…) becomes the de facto method of deploying vCenter, a Windows admin can sometimes no longer pop into SSMS and fire off a quick backup of the database. Especially as of version 6.0, the embedded vPostgres database is capable of handling quite a large environment, so more folks are opting to use it. As such, I’m going to go over how to grab a backup of it. It’s good practice to do this regularly if you aren’t getting a backup of it another way, and I also recommend doing this before any sort of upgrade (as I’m doing now). Here we go!

[Read more…] about Backing up vPostgres Database

Vagrant Series » Multi-Machine Environments (Part 6)

James Green · Aug 7, 2015 ·

Vagrant is neat if you need a whip up a machine to quickly test a script or check compatibility on an operating system that is different than what you normally run. And the value of that isn’t to be minimized. But some of the real power of Vagrant happens when you start to stand up full environments (think 3-tier applications or large scale web server farms) in a repeatable, effortless way. In Hashicorp Land, this is specifically referred to as a “multi-machine” environment. Any Vagrantfile that defines and controls multiple guest machines qualifies for this descriptor.

Defining Multi-Machine Environments

Building a Vagrantfile that will configure a multi-machine environment is as simple as defining multiple VMs with the parameter config.vm.define. In the below example nabbed from Hashicorp documentation, one case see that an Apache front end and MySQL back end are both defined.

Vagrant.configure("2") do |config|
  config.vm.provision "shell", inline: "echo Hello"

  config.vm.define "web" do |web|
    web.vm.box = "apache"
  end
  config.vm.define "db" do |db|
    db.vm.box = "mysql"
  end
end

Once the VMs are defined, configuration takes place by using the inner variable with the same name. In the example, web.anything and db.anything will apply configurations specifically to that machine. Global configurations can still be defined and will apply to all VMs. When configuring a multi-machine environment, it’s important to consider the load order of a Vagrantfile. I covered this in Part 3 of this series, but just to quickly recap, the load order is:

  1. Vagrantfile packaged with the box that is to be used for a given machine.
  2. Vagrantfile in your Vagrant home directory (defaults to ~/.vagrant.d). This lets you specify some defaults for your system user.
  3. Vagrantfile from the project directory. This is the Vagrantfile that you’ll be modifying most of the time.
  4. Multi-machine overrides if any.
  5. Provider-specific overrides, if any.

As the Vagrantfile grows and a large number of machines are defined, it can become a bit of a mess. Scott Lowe wrote about an idea he found over on this blog that breaks all the configuration data out into a separate YAML file. You could also use JSON or XML if you’re more comfortable with that, as in this example.

Accessing Multi-Machine Environments

When using a multi-machine environment, some vagrant commands need to become more specific. If you issue vagrant sshin a multi-machine environment, which machine should be connected to? The commands in a multi-machine environment that only make sense for one machine need to have the machine specified in the command. So in the case of SSH, the command would be vagrant ssh web. In the case of a command like reload, you could issue vagrant reload and reload the whole environment, or you could specify one VM, as in vagrant reload db. Since sometimes one needs to be specific but there’s also a large number of VM’s, the Vagrantfile will also parse regex when it identifies a regular expression for the name, such as /web[A-Za-z0-9]/.

AutoLab 2.6 on Ravello – Build the vCenter & Hosts (Part 3)

James Green · Jul 28, 2015 ·

Part 3 of this series has been a long time coming. I’d been running into some serious problems getting vCenter to build properly, and then I ran out of hours on my promotional hours allotment from the kind folks at Ravello. So I had to wait until I PSODgot some fresh hours. To the right, you can see the sorts of problems I was having. My hosts would frequently PSOD either while building, or while booting. I’m really not sure what’s going on, and I’ve been pressed for time, so I didn’t open a case with Ravello to have them check it out. My feeling is that it’s probably just kinks that need worked out from what amounts to what’s been lovingly referred to as hypervisor Inception. (via HVX)

My advice after having sorted through this, which is also in the AutoLab 2.6 Deployment Guide, is to just keep trying. Eventually, I did get it to work as intended, and I didn’t do anything different. It just worked one time. So, after a long wait, here’s a few notes on the steps required to get the hosts and vCenter built.

Build the Hosts

The hosts and vCenter can be built at the same time. The deployment guide says to start them at the same time. Because the hosts are required for the vCenter build to finish (assuming you’ll run the AddHosts script as a part of the build) I opted to get the hosts started before getting the vCenter build started. There’s a trick, and I can’t remember where I heard this – select all three hosts and start them at once as opposed to starting them one at a time. The reason for this is that starting them in one command will launch them on the same back-end hypervisor, causing performance of communication between the three hosts to be improved. Again, I can’t remember where I got that tip, and I can’t find it in the deployment guide, so correct me if I’m wrong 🙂

Ravello-hosts

Assuming the DC build completed successfully, it’s running a PXE server that the hosts will boot an install wizard from. From the menu, on each host, select ‘ESXi [version] automated builds’ and then the corresponding build (e.g. Host1 Automated Install). This will build the respective host with the correct settings like hostname, IP address, and so on.

PXE-menu1

PXE-menu2

Once you’ve selected a host to build and the process completes, you’ll be left with a fully configured ESXi host. All that’s left is to get them connected to an added vCenter server. Powering on the vCenter server will get the build started, and it generally takes around an hour to complete. An option was set during the DC build to add the hosts to vCenter during the build, so first the OS customization script will run and set up the box, install vCenter, and dependencies/utilities (utilities being things like 7-zip, PuTTy, etc). Once the OS is ready, vCenter is installed, and the script gets PowerCLI installed, it will kick off the script that customizes vCenter. This builds out everything like the datacenter, cluster, adds hosts, adds datastores, and more.

VC-build

AddHostsOnce the vCenter script is totally finished (it might be best not to watch it like I did – feels like an eternity!) the final action will be to install VMware Tools and reboot, just like the DC did. Once the reboot is complete and the OS is automatically logged in again, open the AutoLab Script Menu from the shortcut on the desktop and validate the build just as was done on the DC.

ScriptMenu

GoodBuild

 

And there you have it! Assuming the vCenter is built, you can log in to vCenter via the vSphere Client using credentials in the ‘as-built’ documentation. You will find a fully configured environment with as many hosts as you chose to build. In my build for this post, I just had it build 2.

AutoLabInventory

Vagrant Series » Project Setup, Vagrantfiles, and Boxes (Part 3)

James Green · Jul 27, 2015 ·

In the previous post in this series, I looked at how to provision an Ubuntu box with Vagrant in a matter of moments. Now that the process is understood and the power of Vagrant has been seen, it’s time to break it down a little bit and show how Vagrant is able to create a fully functioning VM with a simple vagrant up.

Vagrant Project Setup

When deploying a new development environment, the first thing to do is set up an area for all of the project files. In the previous post, vagrant init hashicorp/precise32actually created the project in whatever directory the terminal was open to. For a bit more organization moving forward, I prefer to create a folder for a given Vagrant environment. The configuration files will be stored here, as will any supporting files. For instance, a www share for an Apache server might exist in this folder. Creating a new project is easy.

mkdir VirtAdmin
cd VirtAdmin/
vagrant init

In the desired location, just create a new folder, and from within that folder run vagrant init.This will automatically generate a Vagrantfile! What’s a Vagrantfile, you might ask?

[Read more…] about Vagrant Series » Project Setup, Vagrantfiles, and Boxes (Part 3)

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

Copyright © 2023 · Monochrome Pro on Genesis Framework · WordPress · Log in

Posting....