One of my devs is having an issue pushing to our repo. Here's a snippet from his client-side:
He should be authorized. The relevant portion of our .htaccess looks like this:
And /home/user/htpasswd has the following:
Where he is user3. I (user1) can push without any issues. So we're at our wits' end. Thoughts?
Edit: In response to ryans's answer, I confirmed that our password is correct:
Still getting the same error with HTTP code 401.
Edit 2: On a whim, I changed the relevant line of our git app's .htaccess to point to /home/user/webapps/git/.htpasswd and copied /home/user/htpasswd to that location. In my testing, this now works. Our dev is unavailable, but I'm assuming it'll work for him as well. Previously /home/user/webapps/git/.htpasswd had had entries for user1 and user2, so I'm guessing we didn't see any problems because git was just looking there. user3 only had an entry in our central htpasswd file. So now I'm curious why git would care where I put my htpasswd file.
The error you are getting is an HTTP 401 (Unauthorized) error. It's likely related to the password for user3 in the htpasswd file being incorrect. This also explains why it is working for user1 but not user3.
For reference, the RPC Postbuffer error that setting http.postBuffer fixes would be a 411 error code.
answered Nov 07 '10 at 18:58
There is a workaround solution for the RPC error, which is to use SSH for pull/push. SSH push/pull is in general more reliable than HTTP, but it is not as convenient to set up.
Using Git over SSH:
In order for SSH push/pull to work, your PATH in ~/.bashrc must include the path to your git binaries.
Append the following to your ~/.bashrc file: export PATH=$PATH:$HOME/webapps/(git_application)/bin
Once that is done, you can clone using the following: git clone (your_user)@(your_user).webfactional.com:webapps/(git_application)/repos/(proj.git) (proj)
This would clone the repository into a new directory in this folder, named "proj". "push" and "pull" operations will work as normal.
If at any time you'd like to check the remote listing for your repository, simply issue:
git remote -v
You can switch between SSH and HTTP/HTTPS using the "git remote set-url" command.
Using Git over SSH with another user:
You can create an additional SSH user through the Control panel, then give that user full permissions to your git application. If you then create a symlink from ~ssh_user/webapps to ~your_user/webapps, then you should be able to perform the same function using the add-on SSH user for authentication. The path to Git will still need to be added in ~ssh_user/.bashrc, as normal.
Regarding the original issue:
If the passwords are correct, small commits work for both users, and large commits are working for user1 but not user3, then it seems like some client-side issue. We don't have a good way to debug that. If you can reproduce this situation on a fresh repository (or one whose contents you are willing to expose), and then provide the URL and passwords in a support ticket, we would be happy to look into this further as best we can.
answered Nov 08 '10 at 00:09
Ah, the issue is that git was unable to find your most current htpasswd file.
The reason that an Apache .htpasswd file is relevent to git is because Git push-pull over HTTP goes through Apache. It is built within a Static/CGI/PHP application, and Apache authentication is used to ensure that the repository contents remain private.
We have written some complex mod_rewrite rules in the /home/user/webapps/git/.htaccess file to manage this process. These rewrite rules serve to handle data service to git after authentication succeeds. If Apache is looking at the wrong .htpasswd file (as listed in the .htaccess file), then git will also be unable to authenticate because it cannot read its own repository data, and will return an HTTP 401 (Unauthorized) error.
Hope that clarifies!
answered Nov 08 '10 at 00:24