1

I have a vagrant VM being provisioned via Puppet. I'm testing this on two different Ubuntus, 12.04 and 13.10, both using the "standard" precise32 box. The application I'm testing is a Django application being installed using Python's setuptools (by doing pip install /vagrant). Using 13.10 as the host, the VM seems to provision just fine.

On 12.04 however, some later Puppet rules start failing that depend on my manage.py script:

vagrant@precise32:~$ sudo -u buffet ~buffet/project/manage.py collectstatic
Traceback (most recent call last):
  File "/home/buffet/project/manage.py", line 11, in <module>
    import settings
  File "/home/buffet/project/settings.py", line 3, in <module>
    import pkg_resources
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2727, in <module>
    add_activation_listener(lambda dist: dist.activate())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 700, in subscribe
    callback(dist)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2727, in <lambda>
    add_activation_listener(lambda dist: dist.activate())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2227, in activate
    self.insert_on(path)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2334, in insert_on
    self.check_version_conflict()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2373, in check_version_conflict
    for modname in self._get_metadata('top_level.txt'):
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2221, in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1209, in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1201, in get_metadata
    return self._get(self._fn(self.egg_info,name))
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1316, in _get
    stream = open(path, 'rb')
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/Pygments-1.6.egg-info/top_level.txt'

So it looks like in all my stuff I can remove the pkg_resources import and code around this, but I hate to leave the system in a state where all it takes is an import to crash an app. What it looks like is that everything setuptools installs, except for the *.pyc files, does not have read permissions so that unprivileged users can use them.

I tried to rule out a few things:

  • On both distro's I'm using Ubuntu's blessed version of vagrant (1.0.1). Sometimes things can be so old on 12.04 that they just don't work right so I tried upgrading the host system to Vagrant 1.2.2 (which is what 13.10 uses). This didn't seem to affect anything.
  • I tried upgrading the VM to the latest pip via PyPI. No effect.
  • Interestingly if I shell to the VM and pip install something the permissions are set as I would expect, so it seems like it has something to do with either Puppet or Vagrant.
  • I read through the bugfixes between the vagrant versions but couldn't find anything applicable.
  • The only major site differences I can think of between these two systems is that the 12.04 system has a more locked-down umask so that group and other don't have read/write. I have no idea how this would carry into the VM though.
  • Interestingly this is only the dependencies which have this problem. The primary app seems to be fine... (edit: well, the sources are OK, but the top_level.txt and related files aren't)

Any thoughts on this? It won't be relevant soon as we'll be moving to 14.04 in a few months, but it'd be nice if it worked in the meantime.

Here's the rule which installs the app (and dependencies):

exec{'buffet::install library':
  path    => "/usr/bin",
  command => "pip install /vagrant",
  notify  => [
    Exec['buffet::collect static'],
    Exec['buffet::generate hookenv'],
    Service['uwsgi'],
  ],
}
  • Did you find any solution? I'm having the same exact problem. And the nice thing is that it doesn't occur on the first provisioning (when creating the box), but just happens always if I try to re-provision. – Kamafeather Feb 20 '15 at 11:33
  • @Pictor I gave up on the version of pip that ships with 12.04. I have had a host of problems with it unrelated to this too, and have found 14.04's version to be more reliable. exec resources have a "umask" so maybe that could help though it still doesn't make sense to me. – OEP Feb 20 '15 at 17:26
  • Just for letting you know, I solved the problem downgrading the installed PIP version, with sudo easy_install pip==1.2.1. My problem (that maybe is slightly different from yours) was with the OpenSSL version shipped with my laptop, a MacBook (but seems also Windows is affected by this), that has a bug preventing the correct functioning of pip. The downgrade to the most recent version that don't support OpenSSL solved my issue. – Kamafeather Feb 21 '15 at 12:46
  • Thanks; I think they are different problems. Ubuntu 12.04's pip version is just 1.0. I suspect this contributed to the problem I was having. – OEP Feb 21 '15 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.