seems we are experiencing the issue described here: http://serverfault.com/questions/275183/virtualmin-git-integration
how do we address this so that the files have proper ownership such as the other files ?
--
the vmin user's email describing their issue is below as well: "Hope you are doing well. Wanted to touch base quickly on an issue we are having with deploying our site changes to the server. As you know we use Git as our source control. Our usual deployment process is to push to our server, which hits a script file and syncs the server with the latest changes. The last time we pushed our files we had to manually change the owner of the files from apache to drivingjobs. We made a small change today and tried to push, but it failed.
Basically all files in this folder /home/drivingjobs/public_html/git/drivingjobs_live.git should be owned by drivingjobs so we can push to it.
We've tried chown -R drivingjobs:drivingjobs /home/drivingjobs/public_html/git/drivingjobs_live.git but it's not working.
We were able to ftp our change today, but it's not an ideal workflow moving forward if we make larger changes/updates and there are multiple files."
Comments
Submitted by andreychek on Tue, 01/14/2014 - 13:29 Comment #1
Howdy -- when you look in Server Configuration -> Website Options, what is the PHP Execution Mode set to?
Submitted by dolesec on Tue, 01/14/2014 - 15:26 Comment #2
set to FCGId (run as virtual server owner)
Submitted by dolesec on Tue, 01/14/2014 - 15:28 Comment #3
wait but on the dev subdomain it was set to :
PHP script execution mode Apache mod_php (run as Apache's user)
i assume i need to change that to match the other at the top level of their domain ?
Submitted by dolesec on Tue, 01/14/2014 - 15:28 Comment #4
do i need to restart anything for that to take affect ?
Submitted by andreychek on Tue, 01/14/2014 - 16:07 Comment #5
Yeah, you'd probably want your Sub-Server to use either FCGID or CGI. You don't need to restart anything for that to take affect, if you've configured that by going into Server Configuration -> Website Options.
Note that you may need to reset the permissions though, if they aren't currently correct.
To do that, you can go into Limits and Validation -> Validate Virtual Servers -> Fix Permissions, and there you can reset the permissions for any of the domains on your server.
Submitted by dolesec on Tue, 01/14/2014 - 16:50 Comment #6
having them test it now
Submitted by dolesec on Wed, 01/15/2014 - 12:51 Comment #7
ok they are still having issues and this it what they wrote me back …
"Chris,
Here is an overview
We have a git repository on the server. We push our source code from local machines to this git remote repository. The repository does a checkout of the source code. The git repository is configured in such a way that the checkout puts the files in the public_html folder through a post receive hook.
The command that we run locally to push the latest source code to the server is: git push --progress live master:master
The above command must be run from within a git repository with the following remote setup in the repo: ssh://drivingjobs@23.92.29.227:9022/home/drivingjobs/public_html/git/dri...
The full error we receive is:
$- 1:14:57.819: git push --progress live master:master
Counting objects: 61, done. Delta compression using up to 4 threads. Compressing objects: 100% (48/48), done. error: unable to create temporary sha1 filename ./objects/56: No such file or directory fatal: failed to write object fatal: sha1 file '' write error: Broken pipe error: failed to push some refs to 'ssh://drivingjobs@23.92.29.227:9022/home/drivingjobs/public_html/git/dri...'
I think (not sure without more researching) the repository is trying to create a temporary file in /home/drivingjobs/public_html/git/drivingjobs_live.git/objects, but does not have permission to do so."
what else can we try to resolve this issue ?
Submitted by andreychek on Thu, 01/16/2014 - 14:06 Comment #8
What is the output of this command:
ls -l /home/drivingjobs/public_html/git/drivingjobs_live.git
Also, did you change the Virtual Server to use FCGID or CGI, as well as run the "Fix Permissions" described in comment #5 above?
Submitted by dolesec on Thu, 01/16/2014 - 16:55 Comment #9
output of command: - [root@vmin ~]# ls -l /home/drivingjobs/public_html/git/drivingjobs_live.git total 220 drwxrws--- 2 drivingjobs drivingjobs 4096 Dec 5 11:14 branches -rw-rw-r-- 1 drivingjobs drivingjobs 201 Dec 5 15:26 config -rwxrwx--- 1 drivingjobs drivingjobs 38 Dec 5 11:14 description -rw-rw-r-- 1 drivingjobs drivingjobs 23 Jan 3 17:03 HEAD drwxrws--- 2 drivingjobs drivingjobs 4096 Jan 15 12:25 hooks -rw-rw-r-- 1 drivingjobs drivingjobs 182768 Jan 3 17:03 index drwxrws--- 2 drivingjobs drivingjobs 4096 Dec 5 11:14 info drwxrwsr-x 3 drivingjobs drivingjobs 4096 Jan 3 17:02 logs drwxrws--- 4 drivingjobs drivingjobs 4096 Dec 18 12:46 objects drwxrws--- 4 drivingjobs drivingjobs 4096 Dec 5 11:14 refs
both their domain and subdomain are set to: FCGId (run as virtual server owner)
i ran the fix permissions and validated , the output is below: Beginning validation of selected virtual servers. Any problems found will be shown in red ..
dev.drivingjobs.landair.com All features OK drivingjobs.landair.com All features OK
Submitted by andreychek on Fri, 01/17/2014 - 12:25 Comment #10
Yeah, all those files appear to have the correct permissions.
I goofed though, and didn't have you run a command that shows the permissions of the actual directory there, just the files in it.
What is the output of this command:
ls -ld /home/drivingjobs/public_html/git/drivingjobs_live.git
Also, the domain that you're using to access git -- could you create a file in that domain's public_html folder, and in that file, add the following contents:
<?php phpinfo; ?>
I'm curious if it shows that it's using FCGI/CGI, or if something is causing it to revert to mod_php. Actually, is there any chance that we could see the output of that script?
Submitted by dolesec on Fri, 01/17/2014 - 13:48 Comment #11
[root@vmin ~]# ls -ld /home/drivingjobs/public_html/git/drivingjobs_live.git drwxrws--- 8 drivingjobs drivingjobs 4096 Jan 3 17:03 /home/drivingjobs/public_html/git/drivingjobs_live.git
by output of the script do you mean what the phpinfo returns or something else ?
the phpinfo file i created returned - "Debug setting does not allow access to this url."
Submitted by andreychek on Fri, 01/17/2014 - 13:56 Comment #12
Here's the problem -- that git directory, and the files in it, have the correct permissions to be edited by a user within your Virtual Server.
So something else is going awry, though at the moment I'm not sure what.
It's possible that PHP isn't working properly -- we've seen issues with non-standard PHP versions causing domain's to run using mod_php, instead of the configured CGI or FCGID.
What is the output of this command:
php -v
However, it sounds like there's some sort of PHP setting or htaccess file that's been enabled that's preventing access to that test.php script.
Try renaming test.php to another name, perhaps just "foo.php", and see if you're able to retrieve the phpinfo() output at that point.
Submitted by dolesec on Fri, 01/17/2014 - 14:22 Comment #13
phpinfo attached
Submitted by dolesec on Fri, 01/17/2014 - 14:26 Comment #14
here is what they had to do in order to get the phpinfo to return any data:
"Chris,
Give it another shot and you should see the phpinfo() output.
I moved it to the app/webroot folder so it would show. I also added the opening and closing parentheses after the phpinfo call.
Thanks, Brian"
also php -v output: [root@vmin public_html]# php -v PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies [root@vmin public_html]# su drivingjobs [drivingjobs@vmin public_html]$ php -v PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies [drivingjobs@vmin public_html]$
Submitted by andreychek on Fri, 01/17/2014 - 14:32 Comment #15
Yup, that looks correct too. Hmm, I'm a bit puzzled as to what might be going wrong.
Perhaps we should take a look at each directory in the path that needs to be accessed to reach the dir that's not working.
What is the output of the following commands:
ls -ld /home/drivingjobs/public_html/git/drivingjobs_live.git
ls -ld /home/drivingjobs/public_html/git
ls -ld /home/drivingjobs/public_html
ls -ld /home/drivingjobs
Also, just to verify -- which user are you using to access git, is that the "drivingjobs" user?
If so, can you log into SSH as the "drivingjobs" user, and run these two commands:
id
groups
Submitted by dolesec on Fri, 01/17/2014 - 14:46 Comment #16
[root@vmin ~]# ls -ld /home/drivingjobs/public_html/git/drivingjobs_live.git drwxrws--- 8 drivingjobs drivingjobs 4096 Jan 3 17:03 /home/drivingjobs/public_html/git/drivingjobs_live.git [root@vmin ~]# ls -ld /home/drivingjobs/public_html/git drwxr-sr-x 3 drivingjobs drivingjobs 4096 Dec 5 11:14 /home/drivingjobs/public_html/git [root@vmin ~]# ls -ld /home/drivingjobs/public_html drwxr-x--- 9 drivingjobs drivingjobs 4096 Jan 3 17:03 /home/drivingjobs/public_html [root@vmin ~]# ls -ld /home/drivingjobs drwxr-x--- 14 drivingjobs drivingjobs 4096 Jan 17 15:03 /home/drivingjobs
[drivingjobs@vmin root]$ id uid=504(drivingjobs) gid=504(drivingjobs) groups=504(drivingjobs) [drivingjobs@vmin root]$ groups drivingjobs