Puppet module test debug output

This one took hours to find out.

If you are using pdk to run your unit tests, all console output from your module gets squashed. Which is a bit rude, frankly. I could not find anyway of making it print stuff to the console so that I had half a hope of debugging my failing test.

Tha answer in the end was not to use

pdk test unit

But to run the tests with rspec directly. To do this (on Mint):


sudo apt-get install ruby-bundler
sudo bundle install

Then you can


bundle exec rake spec

from the directory which contains your spec folder. You will get different (more) output, and if you use Ruby’s puts you will be able to print to the console.

To keep track of when this gets fixed so that output is retained, follow this issue.

Advertisements

Multiple dropboxes stops working; only one at a time

There are lots of posts out there about how to use multiple (fake) home directories to force Dropbox to run multiple times on Linux. This approach is great, but it breaks when Dropbox upgrades. If you have had this approach working previously and suddenly it stops working, with only one Dropbox running at a time, it’s likely because the Dropbox client has updated itself in the background. The dropbox client has two components, the one you installed, and then the brains that it downloaded during installation. When an update becomes available, the brains get downloaded again. That’s fine if you only have one Dropbox, but when you have two it makes a mess, because you cannot have two different versions of Dropbox running at the same time.

The good news is that you can fix this relatively easily, without re-downloading your files and without re-building your index.

The background

I had multiple dropboxes working fine for months on two different computers. One morning I switched them on and only had one Dropbox, and I knew I hadn’t applied any OS updates, so I suspected a Dropbox update. The brains that self-updates is contained in a folder called .dropbox-dist. You should just have one instance of this folder. To see if all is well, try this:

sudo updatedb && locate -r .dropbox-dist$

If you don’t have updatedb, you need the package mlocate installed. Hopefully the result of this will be one directory, /var/lib/dropbox/.dropbox-dist. On my machine there were two:

/var/lib/dropbox/.dropbox-dist
/home/user/.dropbox_work/.dropbox-dist

Digging in further, I had:

/var/lib/dropbox/.dropbox-dist/dropbox-lnx.x86_64-3.12.6
/home/user/.dropbox_work/.dropbox-dist/dropbox-lnx.x86_64-3.14.5

Uh-oh. Two different versions. To see what was happening, I manually ran the two dropbox instances:

HOME=$HOME/.dropbox_personal; dropbox start
HOME=$HOME/.dropbox_work; dropbox start

Whichever I ran second killed the first. I also ran ps -ef while each was running, and here’s what I got:

dropbox_personal: /var/lib/dropbox/.dropbox-dist/dropbox-lnx.x86_64-3.12.6/dropbox
dropbox_work: /home/user/.dropbox_work/.dropbox-dist/dropbox-lnx.x86_64-3.14.5/dropbox /newerversion

So not, in fact, two instances of the same program running in different home directories, but two different programs. Also playing a part here is how you installed dropbox; if you installed in Ubuntu or any of its derivatives using the package manager (the package you have installed is nautilus-dropbox) then you will find .dropbox-dist in /var/lib/dropbox. If you installed it by downloading the deb ifrom the Dropbox website (the package you have installed is dropbox) then it will be under a home directory.

How to fix it

Debian and its derivatives

If you have Debian’s nautilus-dropbox installed, run these one at a time:

killall dropbox
sudo rm -rf /var/lib/dropbox/.dropbox-dist
rm -rf /home/user/.dropbox_one/.dropbox-dist
rm -rf /home/user/.dropbox_two/.dropbox-dist
HOME=/home/user/.dropbox_one; dropbox start -i
HOME=/home/user/.dropbox_two; dropbox start
ps -ef | grep dropbox

Others

If you have dropbox installed, run these one at a time:

killall dropbox
rm -rf /home/user/.dropbox_one/.dropbox-dist
rm -rf /home/user/.dropbox_two/.dropbox-dist
HOME=/home/user/.dropbox_one; dropbox start -i
HOME=/home/user/.dropbox_two; dropbox start -i
ps -ef | grep dropbox

Check it

Now you should have two instances of the same program, with the later version:

user 8139 1 2 11:42 ? 00:00:38 /var/lib/dropbox/.dropbox-dist/dropbox-lnx.x86_64-3.14.5/dropbox
user 8140 1 1 11:42 ? 00:00:28 /var/lib/dropbox/.dropbox-dist/dropbox-lnx.x86_64-3.14.5/dropbox

Huzzah! All is well, and you can revert to launching your Dropboxes however you were before.

Possible aol.com WHOIS poisoning

I was trying to report some spam abuse this morning, and happened to do a WHOIS on aol.com via swhois.net (my usual location because they have one form that works for IPs and names). What I got was this:

A couple of other WHOIS sites I tried (such as InterNIC) didn’t have this result. I don’t know enough about the structure of the WHOIS DB to know what’s going on, but it looks like something’s been hacked somewhere.