I ran the command,"sudo /usr/local/libexec/git-core/git-daemon git-daemon --export-all /pub/git &" at public repository machine.
At my private machine, I ran, git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD"
I got: "fatal: The remote end hung up unexpectedly"
At the public repository server, I got "'/pub/git/u-boot.git': repository not exported." Any idea of this error?
ps -A | grep inetd
8874 ? 00:00:00 xinetd
It means it uses xinetd.
I copied git-daemon back to /etc/xinetd.d and added git-daemon to the server_args. See below:
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = git-daemon --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I kill the daemon "/usr/local/libexec/git-core/git-daemon git-daemon --export-all /pub/git &".
Back to my private box, and did git pull. I got Connection refused again. what I did wrong?
git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
svdcgit01.amcc.com[0: 10.66.4.168]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
--- On Thu, 11/20/08, Deskin Miller <deskinm@xxxxxxxxx> wrote:
> From: Deskin Miller <deskinm@xxxxxxxxx>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "Gary Yang" <garyyang6@xxxxxxxxx>
> Cc: git@xxxxxxxxxxxxxxx
> Date: Thursday, November 20, 2008, 3:08 PM
> On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang wrote:
> > Many thanks for your explanation. I hope I understand
> what you said. I deleted /etc/xinetd.d/git-daemon. Then, I
> tried to git pull. But, I got connection refused. git uses
> port 9418. Should I request IT Admin to open the port 9418
> for me?
>
> You'll need port 9418 open, yes; but since it's an
> unprivileged port (1024 or
> higher), you can use it as a regular user and don't
> need IT intervention unless you have some firewall set up
> which they need to override for you.
>
> > git pull git://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > git.mycompany.com[0: 10.66.4.168]: errno=Connection
> refused
> > fatal: unable to connect a socket (Connection refused)
>
> It's possible, and likely simpler, to use git-daemon
> directly, instead of
> having it be managed by inetd; especially for initial
> debugging, I'd recommend
> getting that working before trying to determine if
> you're having issues with
> inetd configuration: to do so, just run git-daemon with all
> the same arguments
> except for --inetd.
>
> You said you deleted the xinetd config, but that's only
> relevant if your
> machine actually uses inetd as its super-server. You
> should do 'ps -A | grep
> inetd' (which will match either inetd or xinetd), and
> see which one is running.
> If it's inetd, you should be all set, and the issue
> doesn't look like inetd
> (assuming you sent it a signal to reload its config file).
> If on the other
> hand xinetd is running, you need to use the xinetd config
> file, and fix the
> server_args to look like the arguments which exist in the
> inetd file. Again,
> you need to signal xinetd at this point to reload its
> configuration.
>
> Based on the linux kernel version you're reporting,
> I'm guessing you have some
> sort of Red Hat based system, which uses xinetd to the best
> of my knowledge.
>
> > Another question, I got no output of "netstat |
> grep 9418". It means no program runs at port 9418 at
> the public repository machine. Is it correct?
> >
> > netstat | grep 9418
>
> netstat translates IP addresses to dns names, and ports to
> service names by
> default; so, given the line listed in /etc/services, this
> will show
> '0.0.0.0:git' or something. Also, it lists
> established connections, not
> listening sockets, by default. I'd recommend spending
> some time with the man
> page if you're going to use it to debug your setup.
>
> Deskin Miller
--
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
