On Sat, 20 Aug 2005, Alan Chandler wrote:
>
> If I switch over to git, I assume I run git-daemon from inetd.
Yes. Use the "--inetd" flag, and open port 9418 instead.
> a) Is this what the git://my.domain.com/path/to/repository url refers to
> (neither get-pull-script nor git-fetch-script man pages actually say what
> this form means) ?
Yes.
> b) I can't find any mention in the documentation of what the default port
> should be. What is it?
The default one is 9418, although you can use "--port=xxx" to set it to
something else. Obviously, if you put it at some other port, you either
need to re-compile the client side with the new port number (it's
DEFAULT_GIT_PORT in cache.h) or need to use
git://my.domain.com:<port>/path/to/repository
> c) Is git-daemon multithreaded (ie do I use nowait in inetd.conf)?
Yup, it's entirely safe to run tons of them concurrently.
You can also run the git deamon without inetd, and it will do it's own
serving. That normally limits it to 25 connections at a time.
> d) Is it possible to ensure that external accesses can't access anywhere in
> my
> filesystem?
Yes. The first thing the git-deamon will do is to chdir to the argument
(and add ".git" to the end if it can't find the exact path), and then look
up a file called "git-daemon-export-ok". If that file does not exist, it
will exit.
This means, btw, that it will _not_ export any random git directory by
default, much less anything else. You literally have to mark your git
directories for export explicitly by doing a "touch git-daemon-export-ok"
in the .git directory.
See "daemon.c: upload()" for some of the details.
> e) If I put my public key in ~git/.ssh/authorized_keys on the server, I can
> act as user git on the server via ssh. Does git push support this?
Yes. That's the normal way to do it. The anonymous "git://" protocol can
only do reads (adn it is entirely anonymous). For pushes, you _have_ to
use ssh, either through
git push my.domain.com:/path/to/repository
or
git push ssh://my.domain.com/path/to/repository
(and you can obviously shorthand the format by putting it into your
.git/remotes/ files, so that you can do things like "git push public".)
> f) If I can do e), then perhaps [need to read the docs a bit harder] I can
> set
> up my user git on the machine to use git-receive-pack as its login shell.
> Will this work? - the tutorial talks about needing .bashrc to set up the
> $PATH environment, but are there any other hidden gotchas?
There shouldn't be any other gotchas. But no, you can't _quite_ use
git-receive-pack as the login shell. Why? Because if you have it as your
login shell, it will get the wrong arguments: it will get:
0: git-receive-pack
1: -c
2: git-receive-pack '/path/to/repository'
and you'd need to have some ultra-simple shell that took this, verified
the proper arguments, and turned it into an
execvp(git-receive-pack, /path/to/repository, NULL);
But yes, you _should_ be able to do it with that ultra-simplistic login
shell. Probably just a 5-liner main() function or something.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
