Up and running with Vagrant on Fedora 27

Vagrant, Ansible, Fedora and You

Having shied away from using Vagrant in the past I recently was forced to use it. I really enjoyed the workflow that it enabled; much better than manually restoring snapshots. One of the things that turned me off initially to using Vagrant was the requirement to use VirtualBox in earlier editions. This requirement has been removed in recent versions and you can now pick from many different providers.

The Install

The install is simple dnf install vagrant and after a minute or two you will have a fully working vagrant install using the libvirt provider.

Your First Vagrant Box

Make a new directory and setup your first Vagrantfile. To setup your first Vagrantfile lets run vagrant init centos/7. This will setup and new CentOS 7 box. Once that is done you will have a new Vagrantfile in the directory. You can choose from many different Vagrant boxes, each with a different OS or installed software. Run vagrant up and watch the output. After everything is up and working you can test it by logging into the machine with vagrant ssh.

Next Steps

Vagrant can be configured to automatically provision a host once it has come online. This feature is what changed my mind about Vagrant. So much faster and easier to test Ansible playbooks using this workflow. To enable the machine to be provisioned after boot edit your Vagrantfile and add: 

config.vm.provision "ansible_local" do |ansible|
  ansible.playbook = "playbook.yml"

in the config section of your file. This tells vagrant to run the playbook.yml using Ansible after the machine boots. You can also re-provision the machine by running vagrant up --provision. This will apply any changes you may have made to the playbook.yml after the machine is already running.

Downloading Container Images from Proxmox

Download Container Images Programmatically

I wanted all of the Proxmox container templates to be available for my users to choose from and the pveam tool doesn't provide an easy way to do this. So I came up with a simple bash script to do this for me.

pveam available -section system | while read c1 c2; do pveam download templates $c2; done

This one-liner just downloads all the container system images to the storage location named templates. If you wanted all images just omit the '-section system' part. Stupid simple but a bit of a time saver compared to doing it by hand.

Migrating Proxmox VMs with Python

Using the Proxmox API with Python to Migrate Virtual Machines

I hate doing repetitive tasks, and am always on the lookout for a way to save myself time.

I noticed the other day how much time it was taking me to move virtual machines around using the Proxmox web interface. When doing updates I like to move all the virtual machines off of the machine being updated in the cluster. This is easy to do with the "migrate all" option inside of the web interface. However moving those machines back to the original host was a pain and required a lot of clicking. So I spent an hour and whipped up a quick and dirty python script to do the migrations for me. It only works with KVM based virtual machines right now but it would be simple to adapt to move container based virtual machines. It also only authenticates against PAM right now, again it would be a fairly trivial change to fix that.

Usage

To use the script edit the PROXMOX_HOST global variable and put in the host, FQDN or IP address of your proxmox cluster and adjust the Proxmox port if necessary. Then just call:

./proxmoxMigrate.py -n <node where vms currently reside> -t <node where you want them to end up> <space seperated list of VM ids>

For example:

./proxmoxMigrate.py -n proxmox1 -t proxmox2 100 101 103 104

The Script

Monitoring the Network

Network Monitoring with collectd

Scattered around campus is a few thousand network ports. Most of the ports I don't care what they are doing so no alerting needed but, occasionally when there is an issue and it is nice to have an idea of what the network looked like historically. Enter the SNMP plugin for collectd. I chose collectd because of the vast number of plugins available for it, the fact that its config is file based and that it can be scaled horizontally. Having a file based configuration allows me to check my changes into version control allowing easier auditing and disaster recovery.

Installing collectd and related tools is as simple as enabling the EPEL repository and doing a:

yum install collectd-rrdtool collectd-snmp httpd php git

That  installs everything you need to start graphing your network ports. We will use Collectd Graph Panel to view the pretty graphs that collectd makes.

Simple collectd Configuration

FQDNLookup true

LoadPlugin rrdtool
<plugin rrdtool>
       DataDir "/var/lib/collectd/rrd"
       CacheTimeout 120
       CacheFlush   900
</plugin>

LoadPlugin snmp
<plugin snmp>
   <data std_traffic>
       Type "if_octets"
       Table true
       Instance "IF-MIB::ifDescr"
       Values "IF-MIB::ifInOctets" "IF-MIB::ifOutOctets"
   </data>

   <host "my.host.name">
       Address "192.168.1.40"
       Version 2
       Community "public"
       Collect "std_traffic"
   </host>
</plugin>

Collectd Graph Panel Installation

To install the Collectd Graph Panel just clone the git repository into your web root and it works pretty much out of the box.

git clone https://github.com/pommi/CGP.git

Conclusion

That's it! Really that is all that is needed to start graphing your network ports. This provides a basic system that can easily be expanded and tweaked based on your needs.

Stupid Yo! tricks with Spark Core

Intro

Yo made a huge splash when it first came out. It was all over the tech news sites and of course I had to download the app and see what the hype was. Like all the tech news sites said it was dead simple to use push a button and send a Yo. After a while I found some services via the Yo store. A Yo would be sent when a new post was made or something happened that you cared about (a package delivered, your favorite instagramer uploads a new photo, etc.).

My local ski mountain Yo's whenever 6" of new snow falls, this was pretty much the only reason I kept Yo. It was my killer app for Yo but I wanted more, enter Spark. I have a Spark Core and it is perfect for internet of things (IoT) projects. I wanted a light to turn on whenever 6" of snow fell on the moutain, so I would know even if I didn't have my phone close to me.

Yo provides a simple callback to a webpage whenever a Yo is received which is pretty awesome. The callback includes the username and location if it was included as a GET variable. The setup is fairly simple and straight forward, Yo calls back to a webpage that does some basic checks and then uses the Spark cloud to activate the light on the Spark Core.

Code

Android Studio on Fedora 20 x86_64

Android Studio is an IDE made by Google for developing Android applications. It is an alternative to Eclipse with the Andriod plugin installed. It works quite well under Fedora 20 as long as you install the required dependencies. Android studio requires some i386 libs to be installed that aren't on x86_64 systems by default. To install them:

yum install glibc.i686 zlib.i686 libstdc++-devel.i686

Once that is completed finish installing Android Studio using Google's directions.

Using GitHub with Saltstack

Salt Master with GitHub

I have started using a better work flow with my salt. Mainly integrating GitHub as my file backend. This isn't a new feature as the git backend in salt has been available for a while now but I finally started using it. It simplifies making changes when I am not at my desk as I can just clone the project make the changes and push it back out. Not to mention having a record of what was changed when is great for when things break.

The Setup

Setting up the salt master is easy only a few lines are needed to enable it. In your salt master config file (typically /etc/salt/master) add the following lines.

fileserver_backend:
  - git
gitfs_remotes:
  - git+ssh://git@github.com/kaptk2/gitfs.git

Replace the git+ssh:// line with your repository information.

Make sure you add a deploy key to your repository and test the key. Information on setting up deploy keys can be found on GitHub's site. After the key is tested restart the salt master and check your logs to make sure no errors pop up.

Conclustion

Salt is now powered by a GitHub repository, giving you all the nice stuff that git provides and the ability to work with others easily through GitHub.

References:

• https://docs.saltstack.com/topics/tutorials/gitfs.html
• https://help.github.com/articles/managing-deploy-keys