joomlatools / joomlatools-vagrant

Vagrant box for Joomla development.
https://www.joomlatools.com/developer/tools/vagrant/
Mozilla Public License 2.0
141 stars 37 forks source link

Incorrect permissions over /home/vagrant/.config #148

Closed yiendos closed 4 years ago

yiendos commented 5 years ago

Seems we have incorrect permissions over a home folder: /home/vagrant/.config/

Consequently git related activities gives rise to an error:

$ git pull --rebase
warning: unable to access '/home/vagrant/.config/git/attributes': Permission denied
Already up to date.

Whilst the git actions do succeed we should look to chown -R the permissions to vagrant:vagrant to be in keeping with other permissions for this folder. Currently they are set to root:root

Screenshot 2019-06-05 at 09 54 48
stevenrombauts commented 5 years ago

@yiendos Is this on a new build? This directory can only be set to root if it was created by some process that ran as root which we should be able to solve by finding the responsible exec resource in the Puppet code.

yiendos commented 5 years ago

@stevenrombauts going by the contents of the folder in question:

$ tree -L 3 ~/.config/configstore
/home/vagrant/.config/configstore
└── update-notifier-npm.json

I'd say it's something npm related: https://www.npmjs.com/package/update-notifier

But not much of clue when this get installed to the box?

stevenrombauts commented 5 years ago

@yiendos I think it might have something to do with the installation of CloudCommander: https://github.com/joomlatools/joomlatools-vagrant/blob/master/puppet/environments/box/modules/profiles/manifests/cloudcommander.pp#L6-L11

This runs as root but explicitly sets the home directory to /home/vagrant. Running this as the vagrant user might solve it.

yiendos commented 5 years ago

@stevenrombauts Absolutely spot on with that one, indeed it was cloud commander that was creating these folders.

We can certainly set the group no problems, but changing the user from which the exec will run (and therefore ultimate owner):

==> default: Notice: /Stage[main]/Profiles::Cloudcommander/Exec[npm-install-cloudcommander]/returns: 
==> default: Notice: /Stage[main]/Profiles::Cloudcommander/Exec[npm-install-cloudcommander]/returns: npm ERR! A complete log of this run can be found in:
==> default: Notice: /Stage[main]/Profiles::Cloudcommander/Exec[npm-install-cloudcommander]/returns: npm ERR!     /home/vagrant/.npm/_logs/2019-06-06T14_51_46_970Z-debug.log
==> default: Error: 'npm install cloudcmd@11.8.5 -g' returned 243 instead of one of [0]
==> default: Error: /Stage[main]/Profiles::Cloudcommander/Exec[npm-install-cloudcommander]/returns: change from 'notrun' to ['0'] failed: 'npm install cloudcmd@11.8.5 -g' returned 243 instead of one of [0]

Output of this log:

/home/vagrant/.npm/_logs/2019-06-06T14_51_46_970Z-debug.log

1102 error If you believe this might be a permissions issue, please double-check the
1102 error permissions of the file and its containing directories, or try running
1102 error the command again as root/Administrator (though this is not recommended).
1103 verbose exit [ -13, true ]

So we can't install npm stuff without being root, which is pretty standard fare. However what we can do however is nip in there first and create the directory with the correct owner and group before npm is even called.

Seems that $HOME/.config is a pretty standard place for configs.

stevenrombauts commented 5 years ago

@yiendos Thanks for testing this. It makes sense because we're installing it globally (-g) flag, so npm needs administrative rights. We are also running the process itself as root but this is not creating the .config directory (because we don't change home directory in the systemd unit file)

I'm updating the global Node set up in #138 so let's finish that first and get back to this? Either we install it locally as the vagrant user and use the correct path in the systemd unit or stop installing with the HOME=/home/vagrant env var, which is the cause of our troubles here.

stevenrombauts commented 5 years ago

@yiendos Node has been upgraded in #138 and reinstalling cloudcmd didn't give me any trouble (have yet to try a new build from scratch)

stevenrombauts commented 4 years ago

Marking as closed.