Change your default linux shell without root access

A friend recently mentioned his hatred of ksh and inability to change his default shell because he is not root and root will not make the change. I concur, ksh is turrible, that needs fixed. Here’s a little trick for anyone else who has this issue. Let’s say you want to use bash and the shell forced upon you is ksh. The Korn shell uses .profile to set up your environment when you log in, so append these two lines to your profile:

# run bash damnit
[ ! "`which bash | egrep "^no"`" ] && [ -z $BASH ] && exec bash --login

We look for the output of which bash and ensure it does not say no bash in …, and if that file is non-zero, we exec bash as a login shell. You can read man exec for details on specifically how it works in a given shell, but it essentially replaces the running shell with the new command. If the first two checks are positive, then bash is executed and replaced the ksh process. Once the files are added to your profile, log in again in a new session. Voila, you now have a bash login shell!

rnelson0@dumbserver ~ $ ps -ef | grep bash
  rnelson0  5927  5298   0 19:56:42 pts/1       0:00 grep bash
  rnelson0  5298  5292   0 19:47:48 pts/1       0:00 bash --login

If you’re forced to use a different shell, you may need to locate a different profile file. If you want to use a different shell, just sub out bash for the name of your preferred shell. Enjoy!

Tag-based Veeam Backups

As I teased in Using vCenter tags with PowerCLI, I want to explore how to use tags  in a practical application. To refresh our memory, we looked at creating an Ownership category with individual tags in it, and limited VMs to having just one of the tags. We created a little script that defines our schema, in case we need to re-create it. We are going to work on a new category today for our backups. Specifically, Veeam backups, based on SDDC6282-SPO, Using vSphere tags for advanced policy-driven data protection as presented at VMworld 2015.

Defining Policy and Tags

To create our backup jobs, we need to know a few things that will translate into our tag schema. Our backup policies are defined by a combination of ownership, recovery point objective (RPO), and the retention period. For example, our Development group is okay with a 24 hour RPO and backups that are retained for a week. Operations may require a 4 or 8 hour RPO and require 30 days of backups. Each of those combinations will require a separate backup job. We can combine these tuples of information into individual tags so that Veeam can make use of them. We also need one more tag for VMs that do not need any backup at all. We can put all of this in a tag category called VeeamPolicy. Here’s what that might look like, again in PowerShell:

New-TagCategory -Name VeeamPolicy -Description "Veeam Backup Policy" -Cardinality Single -EntityType VirtualMachine
New-Tag -Name "NoRPO" -Category VeeamPolicy -Description "This VM has no backups"
New-Tag -Name "Development24h7d" -Category VeeamPolicy -Description "Development VMs with 24 hour RPO, 7 days retention"
New-Tag -Name "Operations8h30d" -Category VeeamPolicy -Description "Operations VM with 8 hour RPO, 30 day retention"
New-Tag -Name "Sales48h30d" -Category VeeamPolicy -Description "Sales VM with 48 hour RPO, 30 day retention"

Continue reading

Using vCenter tags with PowerCLI

I was recently introduced to some practical usage of vCenter tags. I used tags to build a fairly easy and dynamic set of sources for Veeam backup jobs, but before I get into that, I want to explain tags a little bit for those who are not familiar with them.

Tags are something that are pretty easy to understand conceptually. You create a category which contains a few tags. An object can receive one or multiple tags from a given category. Tags are managed by vCenter, not by vSphere, so require a license that provides vCenter for management. That’s a pretty simple explanation and list of requirements.

A Tag Category has a collection of Tags available within it. If the Category is “single cardinality”, it means that an object can only be assigned one tag in the category. This might be good for a category associated with ownership or recovery point objective (RPO). A Category can also be “multiple cardinality”, where a single object can be assigned multiple tags in a category. This would be helpful to associate applications with a VM, or a list of support teams that need notified if there is a planned impact or outage.

I’m going to show you how to manage Tags and Tag Categories with PowerCLI (Specifically with the PowerShell ISE and a profile to load PowerCLI), but you can manually create and manage them through the vSphere Web Client, under the Tags item on the left hand menu. You can create and delete and rename tags and categories there all day long, and you can right click on an object almost anywhere else and select Edit Tags to edit the assigned tags on it. When you view most objects, you’ll see an area in the Summary tab labeled Tags that will display and let you manage assignments.

Continue reading

Print the rspec-puppet catalog, courtesy of @willaerk

Sometimes, when you are writing an rspec-puppet test, you’re not sure exactly how the test should be written. You know that you want to test a resource with some extra attribute, but you may be describing the resource wrong, or using a bad regex to test the contents. Rspec-puppet will helpfully tell you when the code and the test do not match, but it does not always tell you where the mismatch is. In those cases, you want to see the whole catalog to see more detail on the resource attributes.

Let’s look at a very simple profile and its corresponding tests and test output:

Continue reading

Rspec fixtures tip: symlink to other modules in your controlrepo

If you are writing rspec tests against your controlrepo, specifically your profile module, you need to set up your .fixtures.yml file to reference the other modules in your controlrepo. For example, here’s a list of the modules in the dist directory of a controlrepo:

dist
├── eyaml
├── profile
└── role

If any of the profile modules reference one of the other modules, it needs to be referenced as a fixture or an error is generated that the resource cannot be found:

$ be rspec spec/classes/eyaml_spec.rb

profile::eyaml
  should contain Class[profile::eyaml] (FAILED - 1)
  should contain Class[eyaml] (FAILED - 2)

Failures:

  1) profile::eyaml should contain Class[profile::eyaml]
     Failure/Error: it { should create_class('profile::eyaml') }

     Puppet::PreformattedError:
       Evaluation Error: Error while evaluating a Function Call, Could not find class ::eyaml for build at /home/rnelson0/puppet/controlrepo/
dist/profile/spec/fixtures/modules/profile/manifests/eyaml.pp:15:3 on node build

We can reference these local modules with the symlinks type of fixture, like this:

fixtures:
  symlinks:
    profile: "#{source_dir}"
    eyaml: "#{source_dir}/../eyaml"

The paths must be fully-qualified, so we use #{source_dir}, a magical value available through rspec, to start with the fully-qualified path to the current directory dist/profile. Follow the symlinks type with repositories and other types of fixtures as you normally would.

When you run rake spec or rake spec_prep, these symlinks will be created underneath dist/profile/spec/fixtures/modules automatically for you. Your rspec tests on profiles that include content from these other modules will no longer error with an inability to find the module in question.

$ be rake spec_prep
$ be rspec spec/classes/eyaml_spec.rb

profile::eyaml
  should contain Class[profile::eyaml]
  should contain Class[eyaml]

Finished in 3.39 seconds (files took 1.61 seconds to load)
2 examples, 0 failures

Enjoy!