git push still gets RPC error after changing postBuffer

Question

One of my devs is having an issue pushing to our repo. Here's a snippet from his client-side:

$ git config http.postBuffer 524288000
$ git push origin master
Username: 
Password: 
Counting objects: 10153, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7004/7004), done.
Writing objects: 100% (10141/10141), 12.15 MiB, done.
Total 10141 (delta 2350), reused 10132 (delta 2344)
error: RPC failed; result=22, HTTP code = 401
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
$

He should be authorized. The relevant portion of our .htaccess looks like this:

AuthName "Git Authentication"
AuthType Basic
Require valid-user
AuthUserFile /home/user/htpasswd

And /home/user/htpasswd has the following:

user1:hash1
user2:hash2
user3:hash3

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:

Server side (inside /home/user/):
$ htpasswd -b htpasswd user3 password3

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.

Answer 1

1

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.

permanent link

answered 07 Nov '10, 18:58

ryans ♦♦
5.0k●10●35●60
accept rate: 43%

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

Answer 2

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.

Answer 3

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.

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!

git push still gets RPC error after changing postBuffer

Follow this question

Related questions