Gitolite removes sshkey on cygwin?
Steven
I successfully set up gitolite on Debian machines multiple times (both
on
etch and Squeeze), but I'm running into trouble on cygwin.
The setup process goes quite smooth and I can clone the gitolite-admin
repo. The problem though is that when I push changes from the
gitolite-admin repo, it gives me a warning that my user does not have a
public key, although it is in the keydir, with the correct name. This
causes git to ask for a password again instead of using the public key.
Issuing the 'gl-setup ~/user.pub' command (same pub key as in the keydir
of the admin repo) fixes this temporarily, until the next change is
pushed. This command is the same I used to setup gitolite in the first
place.
Any ideas? Links that could be faulty? errors in a script?
Kind regards,
Steven
Sitaram Chamarty
> Hi,
>
> I successfully set up gitolite on Debian machines multiple times (both
> on
> etch and Squeeze), but I'm running into trouble on cygwin.
>
> The setup process goes quite smooth and I can clone the gitolite-admin
> repo. The problem though is that when I push changes from the
> gitolite-admin repo, it gives me a warning that my user does not have a
> public key, although it is in the keydir, with the correct name. This
> causes git to ask for a password again instead of using the public key.
I dont know much about windows stuff, except a very specific config
that I support for some users at work (msysgit, client only -- no
server, and NO putty anywhere in sight!)
The first hit on http://www.google.co.in/search?hl=en&q=gitolite on
cygwin&meta= sounds useful. The site is down right now, but the
google-cache of that page looks decent enough. Give it a shot.
> Issuing the 'gl-setup ~/user.pub' command (same pub key as in the keydir
> of the admin repo) fixes this temporarily, until the next change is
> pushed. This command is the same I used to setup gitolite in the first
> place.
>
> Any ideas? Links that could be faulty? errors in a script?
>
> Kind regards,
> Steven
>
>
--
Sitaram
Steven
> On Sat, Nov 13, 2010 at 7:43 PM, Steven <redalert....@gmail.com> wrote:
> > The setup process goes quite smooth and I can clone the gitolite-admin
> > repo. The problem though is that when I push changes from the
> > gitolite-admin repo, it gives me a warning that my user does not have a
> > public key, although it is in the keydir, with the correct name. This
> > causes git to ask for a password again instead of using the public key.
>
> I dont know much about windows stuff, except a very specific config
> that I support for some users at work (msysgit, client only -- no
> server, and NO putty anywhere in sight!)
>
> The first hit on http://www.google.co.in/search?hl=en&q=gitolite on
> cygwin&meta= sounds useful. The site is down right now, but the
> google-cache of that page looks decent enough. Give it a shot.
>
This seems like the page I used to set it up, but since something was
not going well I ended up using the local non-root install method,
mentioned in the INSTALL file on your github page.
Apart from that issue when pushing the admin repo all seems well,
pushing/pulling from regular repos, creating new repos, etc... even
gitweb.
I suspect it's something with a hook script or symlink.
I was hoping you could point me in the right direction on a probable
cause of this weird behavior.
Also I'm afraid I'll run into trouble when I add more users, the
gl-setup script only restore one key.
I'll have another look at it next week at work, but I'll try to get a
Linux server set up when this goes into production.
I'll let you know if I manage to get this thing working.
Kind regards,
Steven
Sitaram Chamarty
> Thanks for your swift response.
> This seems like the page I used to set it up, but since something was
> not going well I ended up using the local non-root install method,
> mentioned in the INSTALL file on your github page.
I must tell you that I have never tested any of them on Windows.
Windows as a server is something I am deeply against, so I don't
expect that will ever change.
Pointing to resources that may help, if I know of any, is as far as I
will go (as I have just done in my previous email).
Linux is free. So are all the *BSDs. Pick one, use it. Even running
*inside* a virtual machine within Windows is likely to be a more
satisfying experience, and probably faster, than using Windows itself.
My sincere apologies for turning this into a non-helpful rant.
> Apart from that issue when pushing the admin repo all seems well,
> pushing/pulling from regular repos, creating new repos, etc... even
> gitweb.
> I suspect it's something with a hook script or symlink.
> I was hoping you could point me in the right direction on a probable
> cause of this weird behavior.
> Also I'm afraid I'll run into trouble when I add more users, the
> gl-setup script only restore one key.
>
> I'll have another look at it next week at work, but I'll try to get a
> Linux server set up when this goes into production.
perfect! And then if you have problems I will certainly help (but
you've already done successfully that on two different Debians).
Sitaram
Steven
> Windows as a server is something I am deeply against, so I don't
> expect that will ever change.
> Linux is free. So are all the *BSDs. Pick one, use it. Even running
> *inside* a virtual machine within Windows is likely to be a more
> satisfying experience, and probably faster, than using Windows itself.
always possible at work, since I don't make the decisions there.
> perfect! And then if you have problems I will certainly help (but
> you've already done successfully that on two different Debians).
>
no longer supported, had to fix the repo's to an archive mirror, upgrade
git (version 1.5 from backports was used earlier), which needed to be
compiled, and gitolite wasn't in the etch repo's since those are pretty
old, but it works with all the bells and whistles now.
Thank you for your time, I'll leave it at that if I can't fix it next
week.
Steven
Steven
On Sat, November 13, 2010 17:16, Sitaram Chamarty wrote:
[...]
>
> I must tell you that I have never tested any of them on Windows.
> Windows as a server is something I am deeply against, so I don't
> expect that will ever change.
>
>
> My sincere apologies for turning this into a non-helpful rant.
>
>> Apart from that issue when pushing the admin repo all seems well,
>> pushing/pulling from regular repos, creating new repos, etc... even
>> gitweb.
>> I suspect it's something with a hook script or symlink.
>> I was hoping you could point me in the right direction on a probable
>> cause of this weird behavior.
>> Also I'm afraid I'll run into trouble when I add more users, the
>> gl-setup script only restore one key.
>>
>
I found the answer.
I'll post the solution here in case anyone stumbles upon the same issue.
The vanishing public keys was due to failing 'find' commands, which in
turn were caused by the used 'find' binary which wasn't the one installed
by cygwin, but the windows version, which is totally different. The
following url led me to the answer:
http://www.mail-archive.com/cyg...@cygwin.com/msg54166.html
So I reinstalled the ssh service like this, which sets a more apropriate
path(No idea what's with the Wbem folder):
cygrunsrv -R sshd
cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd --env
"PATH=/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/system32/Wbem"
And now the correct find is being used, and gitolite seems to be working
just fine now.
Kind regards,
Steven
--
Sitaram Chamarty
> The vanishing public keys was due to failing 'find' commands, which in
> turn were caused by the used 'find' binary which wasn't the one installed
> by cygwin, but the windows version, which is totally different. The
The purpose of cygwin is to create a unix environment in
windows. It seems to do a good job, because lots of things
work as is, even things which were not designed with windows
in mind (such as gitolite).
However, there seems to be some scope for some improvement
here.
When a "bash" script runs, it is expecting a unix
environment. Which means cygwin's default -- at least when
bash runs -- should be to place their binaries first.
Please bug cygwin to fix this.
regards
sitaram
PS: let me also come right out and say this: friends dont
let friends run *server* stuff on windows. While I will
never do anything just to *prevent* gitolite running on
windows, I certainly will not do anything that is *specific*
to windows. You'll just have to ensure your server
environment matches a typical posix env as much as possible,
and -- as people have found -- this is pretty much there
already.
Gitolite's modest needs (posix shell, git, perl core -- no
extra modules) are dictated not by Windows support, but to
allow it to be installed even on Solaris 9 vintage servers,
and that too without root access (assuming someone already
installed git).