On Sat, Mar 14, 2009 at 7:58 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> However, being paranoid is a good thing when we talk about instructions we
> give to the end users. The site owner who uses this facility needs to be
> aware that the script is run as the same user that runs git-daemon, and
> that more than one instances of the script can be run at the same time.
> The script writer needs to be careful about using the same scratchpad
> location for the temporary files the script uses and not letting multiple
> instances of scripts stomping on each other's toes. These things need to
> be documented.
Will expand the docs further.
> Do you run git-daemon from inetd, or standalone, by the way?
Standalone.
> I am wondering how well it would scale if you spawn an external "filter path"
> script every time you get a request.
A quick test of 250 consecutive requests with ls-remote to localhost
(all without the --verbose flag), slowest run:
- Baseline (no --filter-path agument): 3.39s
$ cat filter.c
#import "stdio.h"
int main (int argc, char const *argv[]) {
printf("%s", "/existing.git\0");
return 0;
}
- 3.84s
$ cat filter.rb
#!/usr/bin/ruby
print "/existing.git\0"
- 4.76s
So, obviously highly dependent on how long it takes the script to
launch and how much work it does. And yes, neither of the above really
does anything :) nor takes any increased cpu load into account
Another approach is to keep the external script running and feed it on
stdin, but that would involve a bit more micro-management of the
external process. I will revisit that idea if I find out that's
needed.
> (by the way, "filter path" sounds as if it checks and conditionally
> denies access to, or something like that, which is not what you are using
> it for. It is more about rewriting paths, a la mod_rewrite, and I think
> the option is misnamed)
Maybe --rewrite-script or --rewrite-command instead?
Cheers,
JS
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
