Issue #62 resolved

hook.log permissions

Brett Haydon
created an issue

I'm using Python Fabric and Ubuntu 10.04. When the hook.log is getting rotated the new log gets created with root write permissions causing errors in later logins, as virtualenvwrapper can't write to it under the normal user's permissions.

Comments (17)

  1. Brandon Konkle

    I'm running into this problem also, using Fabric and Ubuntu 10.04. When hook.log is rotated, the new hook.log shows up in /.virtualenvs owned by root:root. This blows up the deploy, because the errors cause a paramiko.SSHException of 'EOF during negotiation'.

    Here's an abbreviated example of a deploy that blew up:

    [myuser@myserver] err: Traceback (most recent call last):
    [myuser@myserver] err:   File "<string>", line 1, in <module>
    [myuser@myserver] err:   File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper/", line 72, in main
    [myuser@myserver] err:     backupCount=1,
    [myuser@myserver] err:   File "/usr/lib/python2.6/logging/", line 107, in __init__
    [myuser@myserver] err:     BaseRotatingHandler.__init__(self, filename, mode, encoding, delay)
    [myuser@myserver] err:   File "/usr/lib/python2.6/logging/", line 59, in __init__
    [myuser@myserver] err:     logging.FileHandler.__init__(self, filename, mode, encoding, delay)
    [myuser@myserver] err:   File "/usr/lib/python2.6/logging/", line 819, in __init__
    [myuser@myserver] err:     StreamHandler.__init__(self, self._open())
    [myuser@myserver] err:   File "/usr/lib/python2.6/logging/", line 838, in _open
    [myuser@myserver] err:     stream = open(self.baseFilename, self.mode)
    [myuser@myserver] err: IOError: [Errno 13] Permission denied: '/home/myuser/.virtualenvs/hook.log'
    [myuser@myserver] err: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenv has been installed for VIRTUALENVWRAPPER_PYTHON=/usr/bin/python and that PATH is set properly.
    paramiko.SSHException: EOF during negotiation
  2. Brandon Konkle

    The hook log itself looks normal. Fabric creates a new non-interactive connection for every command, and each time is sourced it writes to the hook.log. In my ~/.bashrc on my servers, is sourced at the top above the "# If not running interactively, don't do anything" line.

    After connecting to my server manually, if I repeatedly run the . /usr/local/bin/ command I can see the hook.log rotate and it does so with the pegasus user, not the root user.

    The same thing happens when I use my local machine and repeatedly run ssh galahad ". /usr/local/bin/". The hook.log is rotated with user and not root.

    I'm looking through my deploy scripts to see if there's any time when I accidentally use sudo to run workon, but I haven't found anything yet. I'm wondering if it's possible that every time sudo(command) is used in Fabric, it somehow runs ~/.bashrc as root.

  3. Brandon Konkle

    Okay, I think Fabric's sudo(command) function is the culprit. When it runs a sudo command, it connects to the server and runs it like this (as long as env.use_shell is True):

    sudo -S -p '%s' /bin/bash -l -c "my_command"

    Since /bin/bash is being run with sudo, it's running ~/.bashrc with sudo, correct? Any ideas on how to work around this?

    Here's the source code for sudo() if needed:


  4. Doug Hellmann repo owner

    In your /.bashrc you could test USER to see if you're running as yourself, and skip sourcing entirely when you find another user (root, etc.). If sudo isn't setting USER, you might have to look at `id` or os.geteuid().

  5. Morgan Goose

    In fabric you can also specify shell=False, in the command or just set that env var to False throughout, and it'll not use that /bin/bash/ -l part of the command.

  6. Brett Haydon reporter

    After trying a few different methods my workaround for this was to set fabric = '/bin/bash --noprofile -l -c'. As far as I can see everything in the .bashrc and .profile files are to make life easier for human users, so have no real benefit to fabric. Ditto for virtualenvwrapper. I had no issues with any scripts by inserting --noprofile, so I'm happy with this result.

    Another alternate possibility would be for fabric to insert an alternate .bash_profile script which would be sourced instead of .profile.

    Tried using shell=False but some of my scripts depend on shell=True so couldn't use that method.

    Other potential solutions - perhaps an environment variable to switch off the virtualenvwrapper logging might be of use, or log to sysloghandler?

  7. Whit Morriss

    I have a similar issue when I have a machine where multiple users are sharing a set of environments defined in $WORKON_HOME . I think if hook.log was written with the group write permission set, I could simply put all the users in the same group and be ok.

  8. Anonymous

    I just ran into the same error (IOError: [Errno 13] Permission denied: '/hook.log') on a plain vanilla Ubuntu 10.10, while sshing in manually.

    Having this in my .bashrc solved it:

    export WORKON_HOME=$HOME/.virtualenvs
    source /usr/local/bin/
  9. David Marble

    Finally decided to do something about this. The python logging module defaults to 0644. You CANNOT change this default merely by changing umask for system users (through /etc/.profile or similar).

    If you want to create a log file with that module with different file permissions, you can use `os.umask` before logging has a chance to create the file.

    I changed the umask to 0664 for hook.log creation purposes in my fork today. I'll send a pull request. I don't think there are any negatives to this, as it's merely a log file. I share virtualenvs using virtualenvwrapper among several developers on a project on our development/staging servers.

    Changeset: Wiki macro error: Changeset d987986dcb04 not found.

  10. Log in to comment