git push still gets RPC error after changing postBuffer

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:

1
2
3

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:

1 2	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.

git permissions

asked Nov 07 '10 at 16:52

spiffyman
1●1●3

edited Nov 08 '10 at 00:00

What version of git is user3 running on the client side?

(Nov 07 '10 at 16:58) seanf ♦♦

user3 is running 1.7.3.1. So am I. On the server side it's 1.7.2.

(Nov 07 '10 at 17:01) spiffyman

3 Answers:

oldest newest most voted

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

ryans ♦♦
2816●1●4●20

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.

(Nov 07 '10 at 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 Nov 08 '10 at 00:09

ryans ♦♦
2816●1●4●20

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.

(Nov 08 '10 at 00:15) spiffyman

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!

answered Nov 08 '10 at 00:24

ryans ♦♦
2816●1●4●20

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?

(Nov 08 '10 at 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!

(Nov 08 '10 at 22:48) ryans ♦♦

Your answer

If you have an answer to the above question, then use the form below. Otherwise, use the appropriate 'add new comment' button above to post your feedback.

toggle preview

community wiki

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Tags:

git ×80
permissions ×36

Asked: Nov 07 '10 at 16:52

Seen: 2,932 times

Last updated: Apr 07 '11 at 08:05

git push still gets RPC error after changing postBuffer

Follow this question

Got questions? We have answers!

Related questions