Sep 24 2011

Fall , Winter and Spring Conference Season 2011 - 2012

Patrick posted his upcoming conference schedule for the next couple of months.
as you can see there are a comple of overlapping conferences :)

Conferences I'm speaking at or likely to attend are:

  • The first week of October I`ll be in the Valley , I`ll be late for Jenkinsconf but I hope to pick up some events while I`m there.. suggestions are welcome , I`m also heading back to Europe earlier than planned so I will miss BadCamp :( ...
  • Devopsdays Goteborg, Sweden : October 14,15 - The yearly Europe devops event is happening in Goteborg this time. It's going to be really exciting this time , as the theme is inclusive. Eploring the boundaries of devops, I`m once again in the organization of this conference.
  • T-Dose 2011, The Technical Dutch Open Source Event, on 5 and 6 november 2011 , I will be talking again about my experiences with complex Puppet setups
  • Citconf , London: November 11-12 - All you ever wanted to know about Continuous Integration. Period, registered, haven't booked flights yet.
  • Cloudcamp Belgium: November 21 - I'm looking forward to this year's event, as there will likely more practioners and less marketing folks.
  • Lisa 2011, Boston, US, I`m giving an Invited talk titled , Devops: The past and futre are here, It's just not evenly distributed (yet), and I`ll be on a panel titled What Will Be HOt Next Year, really looking forward to this one :)
  • Fosdem.org will take place on 4 and 5 February 2012 , and as every year since it inception I'll be there
  • The UKUUG rebranded to FlossUK , they are hosting their Annual Spring conference from 20th to 22nd March in Edinburgh , given their refound focus it will be even more interresting !
  • And as announced earlier this week Loadays.org will take place in Antwerp again this year on 31/3/2012 and 1/4/2012 , as the previous years I`m co organizing this conference

And yes, I do work from time to time. Just that these conferences are a great way to capture and share new ideas. All worth it!

Aug 24 2011

Using Veewee

With @dancarley and @patrickebois just discussing the origin of the name of Veewee I figured I still had that piece of documentation I wrote up for myselve flying around ...

So with no other reason than having my docs mirrored on the internet .

  1. gem install veewee

  1. veewee templates

shows you what templates we have around ..

  1. $veewee init natty ubuntu-11.04-server-amd64
  2. Init a new box natty, starting from template ubuntu-11.04-server-amd64
  3. The basebox 'natty' has been successfully created from the template ''ubuntu-11.04-server-amd64'
  4. You can now edit the definition files stored in definitions/natty
  5. or build the box with:
  6. vagrant basebox build 'natty'

As noted this will generate the definition for your natty box,
It will create a definition.rb file which describes your box.
A preseed (or kickstart or similar file) and a postinstall file

The next step is then to use vagrant to build this basebox

  1. $ vagrant basebox build natty
  2.  
  3. Verifying the isofile ubuntu-11.04-server-amd64.iso is ok.
  4. Creating vm natty : 384M - 1 CPU - Ubuntu_64
  5. Creating new harddrive of size 10140
  6. VBoxManage createhd --filename '/home/sdog/VirtualBox VMs/natty/natty.vdi' --size '10140' --format vdi > /dev/null
  7. Attaching disk: /home/sdog/VirtualBox VMs/natty/natty.vdi
  8. Mounting cdrom: /home/sdog/iso/ubuntu-11.04-server-amd64.iso
  9. Waiting for the machine to boot
  10.  
  11. Typing:[1]: <Esc><Esc><Enter>
  12. Typing:[2]: /install/vmlinuz noapic preseed/url=http://192.168.10.101:7122/preseed.cfg
  13. Typing:[3]: debian-installer=en_US auto locale=en_US kbd-chooser/method=us
  14. Typing:[4]: hostname=natty
  15. Typing:[5]: fb=false debconf/frontend=noninteractive
  16. Typing:[6]: keyboard-configuration/layout=USA keyboard-configuration/variant=USA console-setup/ask_detect=false
  17. Typing:[7]: initrd=/install/initrd.gz -- <Enter>
  18. Done typing.
  19.  
  20. Starting a webserver on port 7122
  21. Serving file /home/sdog/definitions/natty/preseed.cfg
  22.  
  23. Waiting for ssh login with user vagrant to sshd on port => 7222 to work
  24. .....................................................................................................................................................Transferring /tmp/vbox.version20110822-6766-1xcca1e-0 to .vbox_version
  25. ..
  26.  
  27.  
  28. Step [0] was successfully - saving state
  29.  
  30. Waiting for ssh login with user vagrant to sshd on port => 7222 to work
  31. .Transferring /home/sdog/definitions/natty/postinstall.sh to postinstall.sh

Plenty more output here !

Be very patient .. you will see VirtualBox launch a VM and start installing it ..

The next steps are clear .. vagrant tells you what you can do next

  1. Now you can:
  2. - verify your box by running : vagrant basebox validate natty
  3. - export your vm to a .box file by running : vagrant basebox export natty

So after validating it , you can now export the basebox and share it with other people.

The next step is to actually use that box in your own Vagrant setup, for that you need to import the box into your box collection

  1. $ vagrant box add 'natty' 'natty.box'
  2. [vagrant] Downloading with Vagrant::Downloaders::File...
  3. [vagrant] Copying box to temporary location...
  4. [vagrant] Extracting box...
  5. [vagrant] Verifying box...
  6. [vagrant] Cleaning up downloaded box...

To verify just run

  1. $ vagrant box list
  2. Centos6
  3. MyCentOS2
  4. debian
  5. natty

your freslhy imported box should be in the list .

You can now use

  1. config.vm.box = "natty"
to refer to the fresly imported box in your Vagrant file, a file that can be created by running vagrant init, or copying around another Vagrant template ..

After that .. regular vagrant fun starts, up, provision, provision, provision, destroy, and so forth ..

Aug 21 2011

Devops for Drupal, the survey,

Devops is gaining momentum, the idea that developers and operations should work much closer together , the idea that one should automate as much as possible in both their infrastructure and their release process brings along a lot of questions, ideas and tools that need to be integrated in your daily way of working.

Drupal has one of the biggest development communities in the open source world, being part of both communities We are trying to bridge the gap,

At Inuits we are building tools and writing best practices to close the gap, but we are not alone in this world and we would like to gather some feedback on how other people are deploying, and managing their Drupal environments

Working with Drupal, build with Drupal in mind .. how do you release your sites .. That's what we are trying to figure out ... for everybody else to learn from

Oh and you can win some items of our brand new fashion line !

The survey is here , please spend a bit of your time helping us to better understand the needs of the community

Aug 21 2011

Back from opendbcamp and Froscon

I`m back from my second opendbcamp this year, and my first Froscon :)

With Sankt Augustin being only a 2.5 hour drive , it was one of the only conferences in Europe so close to home that I hadn't visited yet. Overall it's a good conference, it's a good sized, not too crowded event which attracted a bunch of interesting speakers.

Sadly they managed to do way to much changes to the schedule last minute which were not updated in their Android app.. so I ended up arriving in the wrong room multiple times .. Also Sadly German conferences still tend to have way to much German language presentations, for foreign speakers from different parts of the world that limits the choice of talks they can visit.

I gave 2 talks today in Sankt Augustin, I opened the Devops Track today with a general introduction to Devops, the talk was fairly well attended given it was on a Sunday morning right after the social event and plenty of people had questions.

My second talk of the day was about my experience puppetizing SipX, it felt pretty weird having to give an introduction to Puppet in the slot after James , apart from the session chair telling me I had only 5 minutes left about 25 minutes into my talk and the microphone breaking twice on me it went fairly well, it was even attended by a dog.

Time permitting, Froscon is a conference I might visit again :)

Jul 17 2011

Drupal and Configuration Mgmt, we're getting there ...

For those who haven't noticed yet .. I`m into devops .. I`m also a little bit into Drupal, (blame my last name..) , so one of the frustrations I've been having with Drupal (an much other software) is the automation of deployment and upgrades of Drupal sites ...

So for the past couple of days I've been trying to catch up to the ongoing discussion regarding the results of the configuration mgmt sprint , I've been looking at it mainly from a systems point of view , being with the use of Puppet/ Chef or similar tools in mind .. I know I`m late to the discussion but hey , some people take holidays in this season :) So below you can read a bunch of my comments ... and thoughts on the topic ..

First of all , to me JSON looks like a valid option.
Initially there was the plan to wrap the JSON in a PHP header for "security" reasons, but that seems to be gone even while nobody mentioned the problems that would have been caused for external configuration management tools.
When thinking about external tools that should be capable of mangling the file plenty of them support JSON but won't be able to recognize a JSON file with a weird header ( thinking e.g about Augeas (augeas.net) , I`m not talking about IDE's , GUI's etc here, I`m talking about system level tools and libraries that are designed to mangle standard files. For Augeas we could create a separate lens to manage these files , but other tools might have bigger problems with the concept.

As catch suggest a clean .htaccess should be capable of preventing people to access the .json files There's other methods to figure out if files have been tampered with , not sure if this even fits within Drupal (I`m thinking about reusing existing CA setups rather than having yet another security setup to manage) ,

In general to me tools such as puppet should be capable of modifying config files , and then activating that config with no human interaction required , obviously drush is a good candidate here to trigger the system after the config files have been change, but unlike some people think having to browse to a web page to confirm the changes is not an acceptable solution. Just think about having to do this on multiple environments ... manual actions are error prone..

Apart from that I also think the storing of the certificates should not be part of the file. What about a meta file with the appropriate checksums ? (Also if I`m using Puppet or any other tool to manage my config files then the security , preventing to tamper these files, is already covered by the configuration management tools, I do understand that people want to build Drupal in the most secure way possible, but I don't think this belongs in any web application.

When I look at other similar discussions that wanted to provide a similar secure setup they ran into a lot of end user problems with these kind of setups, an alternative approach is to make this configurable and or plugable. The default approach should be to have it enable, but the more experienced users should have the opportunity to disable this, or replace it with another framework. Making it plugable upfront solves a lot of hassle later.

Someone in the discussion noted :
"One simple suggestion for enhancing security might be to make it possible to omit the secret key file and require the user to enter the key into the UI or drush in order to load configuration from disk."

Requiring the user to enter a key in the UI or drush would be counterproductive in the goal one wants to achieve, the last thing you want as a requirement is manual/human interaction when automating setups. therefore a feature like this should never be implemented

Luckily there seems to be new idea around that doesn't plan on using a raped json file
instead of storing the config files in a standard place, we store them in a directory that is named using a hash of your site's private key, like sites/default/config_723fd490de3fb7203c3a408abee8c0bf3c2d302392. The files in this directory would still be protected via .htaccess/web.config, but if that protection failed then the files would still be essentially impossible to find. This means we could store pure, native .json files everywhere instead, to still bring the benefits of JSON (human editable, syntax checkable, interoperability with external configuration management tools, native + speedy encoding/decoding functions), without the confusing and controversial PHP wrapper.

Figuring out the directory name for the configs from a configuration mgmt tool then could be done by something similar to

  1. cd sites/default/conf/$(ls sites/default/conf|head -1)

In general I think the proposed setup looks acceptable , it definitely goes in the right direction of providing systems people with a way to automate the deployment of Drupal sites and applications at scale.

I`ll be keeping a eye on both the direction they are heading into and the evolution of the code !

Jun 10 2011

The case for Augeas

Ever since I met David Lutterkort over steaks at OLS 2007 augeas was this tool in the back of my mind that I couldn't place... I never saw the need for it... or it seemed to be huge overkill for the problem that needed solving .

Till I ran into sipxecs rewriting XML files on the fly .. and putting values in their XML that I could not trace back to an original source. As of Augeas 0.8.x there's an XML lens out there.

Digging innot blah.xml with augtool you can do stuff like

  1. set /augeas/load/Xml/incl[3] /tmp/blah.xml
  2. set /augeas/load/Xml/lens Xml.lns
  3. load
  4. print /files/tmp/blah.xml/profile/settings/param[17]/
  5. /files/tmp/blah.xml/profile/settings/param[17] = "#empty"
  6. /files/tmp/blah.xml/profile/settings/param[17]/#attribute
  7. /files/tmp/blah.xml/profile/settings/param[17]/#attribute/name = "sip-ip"
  8. /files/tmp/blah.xml/profile/settings/param[17]/#attribute/value = "10.255.202.90"
  9. augtool> print /files/tmp/blah.xml/profile/settings/param[18]/
  10. /files/tmp/blah.xml/profile/settings/param[18] = "#empty"
  11. /files/tmp/blah.xml/profile/settings/param[18]/#attribute
  12. /files/tmp/blah.xml/profile/settings/param[18]/#attribute/name = "ext-rtp-ip"
  13. /files/tmp/blah.xml/profile/settings/param[18]/#attribute/value = "auto-nat"
  14. augtool> print /files/tmp/blah.xml/profile/settings/param[16]/
  15. /files/tmp/blah.xml/profile/settings/param[16] = "#empty"
  16. /files/tmp/blah.xml/profile/settings/param[16]/#attribute
  17. /files/tmp/blah.xml/profile/settings/param[16]/#attribute/name = "rtp-ip"
  18. /files/tmp/blah.xml/profile/settings/param[16]/#attribute/value = "10.255.202.90"

and get and set

  1. augtool> get /files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml/profile/settings/param[17]/#attribute/value
  2. /files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml/profile/settings/param[17]/#attribute/value = 10.255.202.90
  3. augtool> set /files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml/profile/settings/param[16]/#attribute/value 10.0.0.2

Putting that into puppet however isn't that tvivial .

When you try to do this

  1. augeas{"sipxprofile" :
  2. changes => [
  3. "set /augeas/load/Xml/incl[last()+1] /etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml",
  4. "set /files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml/profile/settings/param[16]/#attribute/value 10.0.0.2",
  5. "set /files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml/profile/settings/param[17]/#attribute/value 10.0.0.2",
  6. ],
  7. }

Puppet really doesn't output what you want to do ... it only outputs the snippet you modify ..
It's the load statement above that is the really important piece but puppet can't directly work with that so you need to go around that using
The way to solve this is

  1. augeas{"sipxprofile" :
  2. lens => "Xml.lns",
  3. incl => "/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml",
  4. context => "/files/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml",
  5. changes => [
  6. "set profile/settings/param[16]/#attribute/value $ipaddress",
  7. "set profile/settings/param[17]/#attribute/value $ipaddress",
  8. ],
  9. onlyif => "get profile/settings/param[16]/#attribute/value != $ipaddress",
  10. }

Jun 08 2011

Killing VirtualBox

Note to self :
when virtualbox acts up again .

  1. [sdog@stillmine ~]$ VBoxManage list runningvms
  2. "vagrant-etherpad_1307533136" {60697a54-35fc-44e7-96b6-008cde6995a6}
  3. [sdog@stillmine ~]$ VBoxManage controlvm vagrant-etherpad_1307533136 poweroff
  4. 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

May 25 2011

Beyond Configuration Mgmt

(This post has been sitting in the drafts folder for way to long, I decided to push the publish button anyhow .. some people might get ideas from it..)

We've all run in to the problem, you've puppetized, or euh .. cooked , about every part of your infrastructure and then there's this one service which has no config files, a broken api that doesn't allow you to configure antyhing, but a magnificent web gui to configure all aspects of the service. Magnificent for the eye , full of AJAX and other fancy stuff which wget isn't really keen on. Off course before it even starts working you need to set it's password , from that webgui.

Sometimes when you are lucky they store al their config in a database, which you can dump, parse and replace all the host specific parameters for other deployments, but is that an approach you like ? As for each new version you'll need to reanalyze the db layout. But no matter how you look at it ,dumping the DB and restoring it is an ugly hack you don't want.

Other alternatives like sniffing the traffic and replaying the POSTS etc were considered ... but fancy AJAX stuff and SSL make that less trivial than it seems

Wo while discussing with an upstream project they proposed to actually screenscrape their config webgui .

So screenscraping the config gui it is .. but how ... I started looking at tools that are typically used for testing rather than for automation, with the purpose of replaying the scenarios one needs to configure the services.

My first attempt was Selenium, it plugs into a browser , so it's easy to acraully record what it has to do, and it saves it's scenarios in a somewhat readable/ editable format.
Having found the export to perl function it alll looked promising. However the export to perl isn't really an export to perl as I epxected .. I assumed it would just generate the perl code to run the same scneario which would be awesome .. it however generates a perl script that instructs a selenium server to run the script.

One of the annoyancies I ran into with Selenium is that a browser
doesn't accept self signed certificates , and one can't preprovision a browser easyily with those freshly created certificates. (Yes Karl I already read about certutil ... )

I had heard good things about Cucumber so I was pretty eager to start testing it ... In short Cucumber lack documentation ,
I tried a couple of things but I couldn't get beyond testing if a certain string was on a page.. couldn't figure out how to fill in a form etc ...
Maybe if anyone could point me to some great documentation on how you should write recipe's here ... I didn't find the documentation all to easy to find ..
Bummer as it really really looks promisiung .. specially since it is so lightweight ..

IP played with JMeter and Sahi too .. but still

So apart from filing bugs to the upstream project/product and hoping they understand your problem and are willing to oopen up their API , what other options do you folks suggest ?

I gave a short talk about this at Puppetcamp in Amsterdam and the audience came up with a bunch of other potential projects to look at .

The main problem still is that all these are tools to automate testing , they don't provide you with a general purpose approach to solve the configuration mgmt problem, each time the upstream vendor modifies the layout of his page you hav e to do the work again and that .. really doesn't sound promising ..

May 02 2011

And then vagrant gave up ... for a while

Don't you just love Ruby errors ... like the one below ?

Don't they almost make Java stack traces look readable ?
57 lines of jibberish ... where all I wanted to read was "VirtualBox in error state, check gui"

People like Randall Hanssen deserve much more visibility .. they do understand how to write a good error message and there are lots of projects that need improvement there.

Anywhow... vagrant had suddenly stopped working on me with the error below

Turned out that I had deleted some unused Virtualbox images , not from the VirtualBox gui and therefore Virtualbox didn't want to play nice ..

Upon starting the VirtualBox gui and cleaning up the images there , everything started working again ..

But the error wasn't really helpfull ..

  1. vagrant up
  2. /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/com/implementer/ffi.rb:95:in `call_and_check': Error in API call to get_teleporter_enabled: 2147942405 (VirtualBox::Exceptions::FFIException)
  3. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/com/implementer/ffi.rb:69:in `call_vtbl_function'
  4. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/com/implementer/ffi.rb:36:in `read_property'
  5. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/com/abstract_interface.rb:122:in `read_property'
  6. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/com/abstract_interface.rb:64:in `teleporter_enabled'
  7. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:93:in `send'
  8. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:93:in `spec_to_proc'
  9. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:32:in `call'
  10. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:32:in `load_interface_attribute'
  11. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:13:in `load_interface_attributes'
  12. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:12:in `each'
  13. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/interface_attributes.rb:12:in `load_interface_attributes'
  14. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:251:in `initialize_attributes'
  15. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:246:in `initialize'
  16. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:229:in `new'
  17. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:229:in `populate_array_relationship'
  18. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:228:in `each'
  19. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:228:in `populate_array_relationship'
  20. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:218:in `populate_relationship'
  21. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/relatable.rb:242:in `populate_relationship'
  22. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model.rb:215:in `populate_relationship'
  23. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/dirty.rb:129:in `ignore_dirty'
  24. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model.rb:215:in `populate_relationship'
  25. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/global.rb:93:in `load_relationship'
  26. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/relatable.rb:192:in `read_relationship'
  27. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/abstract_model/relatable.rb:146:in `vms'
  28. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:185:in `all'
  29. from /usr/lib/ruby/gems/1.8/gems/virtualbox-0.8.3/lib/virtualbox/vm.rb:193:in `find'
  30. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/vm.rb:13:in `find'
  31. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/environment.rb:378:in `load_vms!'
  32. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/environment.rb:377:in `each'
  33. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/environment.rb:377:in `load_vms!'
  34. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/environment.rb:144:in `vms'
  35. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/environment.rb:180:in `multivm?'
  36. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/command/helpers.rb:19:in `target_vms'
  37. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/command/up.rb:8:in `execute'
  38. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/task.rb:22:in `send'
  39. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/task.rb:22:in `run'
  40. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task'
  41. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:124:in `invoke_all'
  42. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/config.rb:115:in `map'
  43. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/core_ext/ordered_hash.rb:73:in `each'
  44. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:124:in `map'
  45. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:124:in `invoke_all'
  46. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/group.rb:226:in `dispatch'
  47. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:109:in `send'
  48. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:109:in `invoke'
  49. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/lib/vagrant/cli.rb:45:in `up'
  50. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/task.rb:22:in `send'
  51. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/task.rb:22:in `run'
  52. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task'
  53. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor.rb:263:in `dispatch'
  54. from /usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib/thor/base.rb:389:in `start'
  55. from /usr/lib/ruby/gems/1.8/gems/vagrant-0.7.2/bin/vagrant:15
  56. from /usr/bin/vagrant:19:in `load'
  57. from /usr/bin/vagrant:19

Apr 20 2011

The 4158 second catalog run.

Two of my tweets , sorry dents, earlier today caused some people to ask me what on earth I was doing :)

You don't exist, go away!

Was the first one, indeed .. it was a long time since I had actually seen that one.. this actually happens when you delete the user you are logged in with on a host, when the host notices you don't exist anymore it will tell you.

Now that is exactly what happend .. We were busy reordening the uid's on some hosts , so I modified the puppet config for that host and changed the uid values, a couple of minutes later I was told that I don't exist ..

The last time I saw that , was about 10 years ago when I was trying to fool some collegues :)

Now the second tweet that tracked some people's attention was the one about a very lengthy catalog run

  1. Apr 20 05:12:42 sipx-a puppet-agent[22384]: Finished catalog run in 4158.09 seconds

Indeed, a puppet catalog run of about 69 minutes, yes thats 1 hour and 9 minutes ..

The reason for this lengthy catalog run was the above uid reordering , combined with

  1. "/var/sipxdata/":
  2. owner => "sipxchange", group => "sipxchange",
  3. recurse => true,
  4. ensure => directory;

And about 5K files in that directory .. apparently recurse doesn't translate to chown -R yet :)