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'],
  ],
}
OEP
  • 183
  • 9
  • **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

0 Answers0