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. asked 07 Nov '10, 16:52 spiffyman |
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 07 Nov '10, 18:58 ryans ♦♦ I should've been more clear and said that we'd addressed the 411 error code initially with the http.postBuffer fix. I had not noticed that the code had changed, though, so thanks for pointing that out. I modified our htpasswd file and tested with no luck. I'm updating the question to reflect those steps.
(07 Nov '10, 23:48)
spiffyman
|
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 08 Nov '10, 00:09 ryans ♦♦ Commits never worked for user3 at all. However, see my Edit 2 regarding the original issue. It now looks like git simply didn't like our having changed the location of the htpasswd file. Appreciate all the help.
(08 Nov '10, 00:15)
spiffyman
|
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 08 Nov '10, 00:24 ryans ♦♦ This makes perfect sense, but it doesn't explain why /home/user/htpasswd apparently doesn't work as a valid path for Apache to find. Is it as simple as the fact that it's named htpasswd and not .htpasswd?
(08 Nov '10, 22:25)
spiffyman
Ah, this is because pulling uses the AuthUserFile from: $HOME/webapps/(git_application)/.htaccess And pushing uses the AuthUserFile from: $HOME/webapps/(git_application)/auth/.htaccess This is a feature that actually allows you to specify certain users who can pull but not push (by using two different htpasswd files). Normally, these two AuthUserFile lines are the same, so this problem is not encountered. It would probably be a good idea to add this to our official documentation. Sorry for the black magic there!
(08 Nov '10, 22:48)
ryans ♦♦
|
What version of git is user3 running on the client side?
user3 is running 1.7.3.1. So am I. On the server side it's 1.7.2.