Am I doing something wrong?
kragen@thrifty:~/devel$ git clone http://watchdog.notabug.com/code/ watchdog-git
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
kragen@thrifty:~/devel$ git clone git://watchdog.notabug.com/code/ watchdog-git
fatal: unable to connect a socket (Connection refused)
fetch-pack from 'git://watchdog.notabug.com/code/' failed.
kragen@thrifty:~/devel$ git clone watchdog.notabug.com:/home/watchdog/code/.git watchdog-git
fatal: no matching remote head
fetch-pack from 'watchdog.notabug.com:/home/watchdog/code/.git' failed.
kragen@thrifty:~/devel$ git clone watchdog.notabug.com:/home/watchdog/code watchdog-git
fatal: no matching remote head
fetch-pack from 'watchdog.notabug.com:/home/watchdog/code' failed.
In case you're doing something wrong, perhaps this flowchart might be
helpful. I don't know enough about Git to guess how far along you are
in the process.
http://weblog.masukomi.org/2008/03/11/sharing-a-public-git-repo-over-http-flow-chart
$ git clone watchdog.notabug.com:/home/watchdog/code/.git watchdog-git
works.
Great! But it looks like the umask in /etc/profile is from the dark ages
before per-user groups (it's 022 instead of 002) and consequently only you can
write to the repository, and I don't have sudo to fix it. Also sendmail is
broken because nbsmtp is installed in place of an actual MTA; probably we
should fix this if we want the site to be sending out email.
kragen@thrifty:~/devel/watchdog-git$ git push
updating 'refs/heads/master'
from 277226c98c06ad7f7e6c41bb81bf0950c751051e
to 9ce41c153754dd04543785409836a3e1b1963d01
Generating pack...
Done counting 8 objects.
Result has 7 objects.
Deltifying 7 objects.
100% (7/7) done
Writing 7 objects.
100% (7/7) done
Total 7, written 7 (delta 0), reused 0 (delta 0)
error: unable to create temporary sha1 filename ./objects/tmp_obj_A3Siq0: Permission denied
fatal: failed to write object
unpack unpacker exited with error code
ng refs/heads/master n/a (unpacker error)
...
kragen@watchdog:~$ sudo chmod -R g+w /home/watchdog/code/
[sudo] password for kragen:
kragen is not in the sudoers file. This incident will be reported.
kragen@watchdog:~$ /usr/sbin/sendmail: invalid option -- t
Usage: /usr/sbin/sendmail -f fr...@address.com -h relayhost [OPTIONS] (use -H for help)
Great! I was able to push, so you should be able to pull my changes
now, but the umask in /etc/profile is still 022 instead of 002 as it
should be, so now you can't necessarily push, because now there are
directories in there that are only writable by me. I just fixed that
now by hand (I hope) but it will happen again until the umask is
fixed. Also, the directories aren't sgid, so new files and directories
therein will get the wrong group ownership, which will cause the same
problem.
Still some trouble. Maybe we're doing something wrong, because I can't
find anybody writing on the web having trouble with git and umask,
although it looks like the umask situation in Debian has been kind of a
PITA for a while.
The Current State of the umask Problem
--------------------------------------
So I made the mistake of believing /etc/skel/.profile when it
said:
# the default umask is set in /etc/profile
It turns out /etc/profile doesn't do squat when you do this:
$ ssh watchdog.notabug.com umask
because there's no login shell involved. And that's how git executes
remote git, by default. It does read .bashrc, but having every subshell
reset your umask would be annoying and maybe dangerous.
/etc/login.defs explains:
# UMASK usage [in /etc/login.defs] is discouraged because it
# catches only some classes of user entries to system, in fact
# only those made through login(1), while setting umask in shell
# rc file will catch also logins through su, cron, ssh etc.
#
# At the same time, using shell rc to set umask won't catch
# entries which use non-shell executables in place of login shell,
# like /usr/sbin/pppd for "ppp" user and alike.
#
# Therefore the use of pam_umask is recommended (Debian package
# libpam-umask) as the solution which catches all these cases on
# PAM-enabled systems.
#
# This avoids the confusion created by having the umask set in two
# different places -- in login.defs and shell rc files (i.e.
# /etc/profile).
#
# For discussion, see #314539 and #248150 as well as the thread
# starting at
# http://lists.debian.org/debian-devel/2005/06/msg01598.html
But for whatever reason, libpam-umask is not installed and used by
default.
Consequently there are now a bunch of directories in
/home/watchdog/code/.git that are writable only by "aaronsw", so I
probably won't be able to push any more changes until we fix that.
Why This Problem Arose
----------------------
Probably everybody knows, but just for the record.
Debian by default uses "UPG" or "User Per Group". This lets you leave
your umask at 002 (or 007, or 000) all the time, and just use group
ownership to distinguish private from shared files; private files
belong to the group that contains only you.
But not all people, or all software, have adapted to this new world,
so sometimes people like to have other umasks. This causes the
problem we're seeing here: accidentally creating directories other
people can't write to in shared spaces.
Why We Should Care
------------------
If we can get the infrastructure into a smoothly working state, we
don't have to struggle with it later on. The opportunity cost of time
at the start of a project is high, so it's hard to justify spending
time on stuff like this up front, but the psychological phenomenon of
hyperbolic discounting exaggerates that opportunity cost. I think
putting in an hour or so on this stuff now will save us two or three
hours over the course of the next few weeks.
> http://en.wikipedia.org/wiki/Hyperbolic_discounting
Probably all of us have been burned a few times by not keeping our
infrastructure in adequate order, so I expect this should be an easy
sell.
What We Should Do
-----------------
First, aaronsw or root should fix the nonwritable directories:
$ chmod g+w $(find /home/watchdog/code/.git -perm -200 ! -perm -020 -print)
Then we should fix the umask. Two choices:
1. use libpam-umask. I've tested this on my server and it works:
kragen@courageous:~$ sudo apt-get install libpam-umask
Put this line at the end of /etc/pam.d/common-session:
session optional pam_umask.so umask=002
Remove the "umask 002" line from /etc/profile.
2. Put 'if [ "$SHLVL" = 1 ] ; then umask 002; fi' into
/etc/bash.bashrc. Putting this in .bashrc does seem to work (I'm
testing it on another server where other people didn't like the
libpam-umask approach), so putting it in /etc/bash.bashrc should
work too, as long as everyone uses bash.
Done.
> 1. use libpam-umask. I've tested this on my server and it works:
>
> kragen@courageous:~$ sudo apt-get install libpam-umask
This turns out not to work, since base-files on gutsy contains a
package that provides libpam-umask.
> Put this line at the end of /etc/pam.d/common-session:
> session optional pam_umask.so umask=002
>
> Remove the "umask 002" line from /etc/profile.
Done.
$ ssh watchdog umask
0002
So this seems to work.
$ git clone watchdog:/home/watchdog/git/dev.git watchdog
Sorry about that.
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html is helpful.