2020-10-06 14:46:44 +02:00
|
|
|
This might not be the same cause or solution as [[git_test_receive_wrapper_fails]] so filing
|
|
|
|
|
it separately.
|
|
|
|
|
|
|
|
|
|
Anon git push is broken again
|
|
|
|
|
|
|
|
|
|
remote: error: cannot lock ref 'HEAD': Unable to create '/home/b-ikiwiki/source.git/./HEAD.lock': Permission denied
|
|
|
|
|
To git://git.ikiwiki.info/
|
|
|
|
|
! [remote rejected] master -> master (failed to update ref)
|
|
|
|
|
|
|
|
|
|
*—[[Jon]], 2020-10-06*
|
2020-12-29 15:44:24 +01:00
|
|
|
|
|
|
|
|
> It does not seem related to the other problem. I don't understand how it
|
|
|
|
|
> could have broken in a new way since I fixed it before. git has not been
|
|
|
|
|
> upgraded in the meantime. This is affecting more than one site, and the
|
|
|
|
|
> permissions do not seem obviously broken.
|
|
|
|
|
>
|
|
|
|
|
> Since this is now seeming so fragile -- after working for about a decade,
|
|
|
|
|
> it's broken twice in a matter of months -- I'm questioning whether it's
|
|
|
|
|
> worth trying to keep the feature working. --[[Joey]]
|
2021-01-13 16:47:22 +01:00
|
|
|
|
|
|
|
|
>> Of course, that's got to be your call. I haven't made a great deal of use
|
|
|
|
|
>> of it, but it *does* seem more convenient if one is working on an IkiWiki
|
|
|
|
|
>> patch, as I can write the website notes about it in the same tree (although
|
|
|
|
|
>> I then have to cherry-pick to push that to the live site, of course.). If
|
|
|
|
|
>> you decide to drop it from `ikiwiki.info`, would you leave the code as-is,
|
|
|
|
|
>> or drop it as broken? Any further clues what went wrong this time?
|
|
|
|
|
>> *—[[Jon]], 2021-01-13*
|
2021-03-29 20:02:19 +02:00
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
The HEAD.lock permissions error does not come from the post-receive hook or
|
|
|
|
|
from ikiwiki when it runs it. Instead, stracing git-daemon shows that it
|
|
|
|
|
happens after ikiwiki has checked the push and accepted it, and exited
|
|
|
|
|
successfully.
|
|
|
|
|
|
|
|
|
|
So the problem is that git-daemon is unable to write to the git repo.
|
|
|
|
|
|
|
|
|
|
drwxr-sr-x+ 8 b-git-annex b-git-annex 4096 Mar 29 17:07 /home/b-git-annex/source.git/
|
|
|
|
|
|
|
|
|
|
ikiwiki-hosting's ikisite is supposed to arrange for git-daemon
|
|
|
|
|
to be able to write there by using an ACL, so something about that
|
|
|
|
|
must be what is broken now. --[[Joey]]
|
|
|
|
|
|
|
|
|
|
Ok, found the problem. ikisite runs setfacl, and that does the right thing.
|
|
|
|
|
Then ikisite runs chmod on the source.git directory (to make it suid as seen
|
|
|
|
|
above). That seems to mess up the ACLs that were set earlier.
|
|
|
|
|
|
|
|
|
|
The diff from good to bad ACLs, as shown by getfacl is:
|
|
|
|
|
|
|
|
|
|
-group::rwx
|
|
|
|
|
-group:ikiwiki-anon:rwx
|
|
|
|
|
-group:b-ikiwiki:rwx
|
|
|
|
|
-group:b-git-annex:rwx
|
|
|
|
|
-mask::rwx
|
|
|
|
|
+group::rwx #effective:r-x
|
|
|
|
|
+group:ikiwiki-anon:rwx #effective:r-x
|
|
|
|
|
+group:b-ikiwiki:rwx #effective:r-x
|
|
|
|
|
+group:b-git-annex:rwx #effective:r-x
|
|
|
|
|
+mask::r-x
|
|
|
|
|
|
|
|
|
|
I don't understand ACLs or how a chmod could clear them but ok, ikisite needs
|
|
|
|
|
to chmod before setting the ACLS.
|
|
|
|
|
|
|
|
|
|
This is not an ikiwiki bug and I'll fix it in ikisite-hosting then. [[done]]
|
|
|
|
|
--[[Joey]]
|
