Wednesday, July 30, 2014

Python Virtualenv Setup: Updated

I used the script I created to start a new project and realized very quickly that something wasn't right.  I had noticed that the autoenv wasn't working, while it had previously.  I checked other projects I used it with and it worked fine, so I started digging through the code.

Then I saw it.  With all the other projects, there was either a github or bitbucket repository created.  For this project I opted for neither.  Unfortunately, I completed forgot that even if I don't start a project, I need to still initialize the project as a virtualenv.

So, I decided to functionalize the github and bitbucket portions and moved the final step outside of the code that creates the repo's.  I tested it and voila!!!  Worked like a champ.

So, if you downloaded previously, please update your checked out version so you have the latest copy.


Wednesday, July 09, 2014

Getting started with Ansible

There are a ton of buzzwords thrown around every single day.  So many that its sometimes hard to determine what is legit and what isn't.  One of the words that I have paid attention to and come to really love is ansible.

To quickly sum up what ansible is, it's an automation tool that allows you to run a command or a set of commands across multiple machines.  This is extremely handy, for instance, if you have a bunch of machines acting as web servers and you need to shut down the web server portion for maintenance.

Previously you would have had to log in to each machine and issue the necessary commands.  But with ansible, you can simply put the commands in one file (called a playbook) and then run that playbook again the machines in question.

I would cover how to install ansible, but considering people work on different systems, I will just say that ansible has a pretty good set of docs on this already.  After you have installed the software, you will need a directory structure that looks something like the following:

ansible
    |
    |___ playbooks/
    |             |_____  .yml
    |
    |___ .ansible_hosts
    |
    |___ ansible.cfg

   You don't have to call the top directory ansible, but it helps so that you remember what is in there.  The playbooks directory is needed and under that is where you store the playbooks, which are in yaml format (thus the .yml extension).

The ansible.cfg file has a lot of options and you are going to want to read up on how to configure that.  As for the .ansible_hosts file, this is where you list the hosts that are under your conrtol and that you want to act upon.  In there you can list a single host or a group of hosts.  You can ready about how to specify your hosts in the ansible sites Inventory documentation.

The way that I have one of mine configured is so that it prompts me for the sudo password so that it can run all the commands that it needs to, with sudo.  As an example, I have a playbook called df.yml that will do a df on the set of specified hosts.  The df.yml file looks like this:

---
- hosts: "{{ group }}"
  gather_facts: false
  tasks:
    - name: df
      sudo: yes
      command: 'df -h'

Please keep in mind that this is a yaml file and the format above is specific to yaml.  If you look at the hosts line, there are no hosts specified.  Instead, it simply says {{ group }}.  This is a variable that will be expected from the command line when I run the playbook.   In my .ansible_hosts file, I have a section that looks like this:

[ hostgroupname ]
host1
host2
host3

To run the df.yml play on that group, I run it as follows:
ansible-playbook playbooks/df.yml -v -i ./.ansible.hosts -k --extra-vars "group=hostgroupname"
That is being run from the ansible directory and referencing everything with that being the root.  Notice the '--extra-vars' option and the 'group=hostgroupname' at the end.  That is where the  {{ group }} is pulled from.  Ansible will take that and run the commands in the file on each host in that group.

There is a lot more configuration that can (and will) be done for ansible.  Particularly, I will be setting up my ssh key on all the servers, that way the script just runs, other than prompting for the sudo password.  (Yes, my script currently prompts me for my password to connect via ssh, but that is my current configuration and destined to change when I find the two minutes to do it).

So, that is a slight intro to ansible.  Remember to bookmark the ansible documentation.   Hopefully you are able to get it working quickly and enjoy its use as I am.

Tuesday, July 08, 2014

Homebrew and the Untracked Working Tree Files

On the Mac, you have package managers that are designed to allow you to install software via the command line.  Two of the majors are MacPorts and Homebrew.  This is specific to Homebrew as that is the one that I chose to use for my system.

If you are like me, you install the software you need and then don't touch Homebrew for a while.  During the lapse in use, the system tends to get stale and you will find that before you search for software or are able to install anything, that you must  first update it.

The update is usually simple and run as follows:
sudo brew update
Unfortunately, its not a perfect system, and will let you know this by pretty much bitching and complaining and exiting, refusing to update.  The output of such a hissy fit looks similar to this:

> sudo brew update --force
error: The following untracked working tree files would be overwritten by checkout:
Library/Aliases/fishfish
Library/Aliases/fluidsynth
Library/Aliases/gearmand
Library/Aliases/git-tig
Library/Aliases/gnu-scientific-library
Library/Aliases/google-go
Library/Aliases/gperftools
Library/Aliases/gpg
Library/Aliases/gpg2
Library/Contributions/brew_bash_completion.sh
Library/Contributions/brew_fish_completion.fish
Library/Contributions/brew_zsh_completion.zsh
Library/Contributions/cmd/brew-aspell-dictionaries.rb
Library/Contributions/cmd/brew-beer.rb
Library/Contributions/cmd/brew-bundle.rb
Library/Contributions/cmd/brew-cleanup-installed
Library/Contributions/cmd/brew-dirty.rb
Library/Contributions/cmd/brew-gist-logs.rb
Library/Contributions/cmd/brew-graph
Library/Contributions/cmd/brew-grep
Library/Contributions/cmd/brew-leaves.rb
Library/Contributions/cmd/brew-ls-taps.rb
Library/Contributions/cmd/brew-man
Library/Contributions/cmd/brew-mirror-check.rb
Library/Contributions/cmd/brew-profile.rb
Library/Contributions/cmd/brew-pull.rb
Library/Contributions/cmd/brew-readall.rb
Library/Contributions/cmd/brew-server
Library/Contributions/cmd/brew-services.rb
Library/Contributions/cmd/brew-switch.rb
Library/Contributions/cmd/brew-tap-readme.rb
Library/Contributions/cmd/brew-test-bot.rb
Library/Contributions/cmd/brew-tests.rb
Library/Contributions/cmd/brew-unpack.rb
Library/Contributions/cmd/brew-which.rb
Library/Contributions/cmd/git
Library/Contributions/cmd/public/bootstrap.min.css
Library/Contributions/cmd/public/glyphicons-halflings-white.png
Library/Contributions/cmd/public/glyphicons-halflings.png
Library/Contributions/cmd/svn
Library/Contributions/example-formula.rb
Library/Cont

No matter what you do with the brew command (at least from what I have found), you won't be able to update.  What is nice though, is that brew uses git to do its checkouts and updates.  And, for your knowledge going forward, brew uses /usr/local as its base directory.  So, the easiest way that I found to correct this issue and update brew is to completely bypass the command and go straight to git.  

The following set of commands should work to get your brew back up and working(note, I am sudo running these commands):
# cd /usr/local
# git fetch origin
# git reset --hard origin/master
After doing the above, you should find that running brew update has the following results:

# brew update
Already up-to-date. 
Why?  Because you just circumvented the brew command and updated it manually.  You can now run 'brew search ' or whatever other brew command you were going to run.  Have fun!
 
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.