gitolite broken: created repositories keep references to /usr/bin for hooks

OpenSubmitted by ng0.
Details
5 participants
  • ng0
  • Danny Milosavljevic
  • Efraim Flashner
  • Maxime Devos
  • zimoun
Owner
unassigned
Severity
normal
N
(address . bug-guix@gnu.org)
20170303215819.bttmrfsbhlxyipmy@abyayala
Our gitolite package currently creates all
(including gitolite-admin.git) git repositories with references to
"/usr/bin/perl" as shebang, which makes it completely useless on
serverside.
Given that the server side in the case of a gitolite from Guix runs an
environment where you will not run perl from /usr/bin/, you will have to
change all hooks manually currently.

When you install perl into the profile of the user which hosts the
repositories and change the shebangs, gitolite can be used.
N
Re: bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
(address . 25957@debbugs.gnu.org)
20170303222743.wf777eedaauuof3f@abyayala
What makes this worse, with every update (push) of gitolite-admin
repository the shebang of "hooks/update" is reset.
Other repositories seem to keep changes in the hooks shebangs so
far.
N
(address . 25957@debbugs.gnu.org)
20170304133242.towlmzdcm6x43hvi@abyayala
On 17-03-03 22:27:43, ng0 wrote:
Toggle quote (8 lines)
> What makes this worse, with every update (push) of gitolite-admin
> repository the shebang of "hooks/update" is reset.
> Other repositories seem to keep changes in the hooks shebangs so
> far.
>
>
>

When I build gitolite from guix, this looks trivial to fix.

[user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
lib/Gitolite/Cache.pm:127: open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
ed: $!";


The parts I want to fix as my immediately affect every user, are in
the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
I think there should be a reference to /gnu/store/ reddis and not
"/usr/sbin/redis-server". Different problem, related bug.. This can be
solved in a commit after this bug.
D
D
Danny Milosavljevic wrote on 4 Mar 2017 16:43
(name . ng0)(address . contact.ng0@cryptolab.net)(address . 25957@debbugs.gnu.org)
20170304164309.08e43b4c@scratchpost.org
Hi ng0,

Toggle quote (4 lines)
> I think there should be a reference to /gnu/store/ reddis and not
> "/usr/sbin/redis-server". Different problem, related bug.. This can be
> solved in a commit after this bug.

Yeah.

I would question why a normal application needs to start a redis *server* in the first place. Sounds strange to me. But I agree that if it wants to do that it should use a store reference.

https://redis.io/topics/admin says "Redis is designed to be a very long running process in your server" so that definitely reads to me that a normal program shouldn't just start redis-server when it feels like it (and I hope it stops it again later? After reading the source code it doesn't appear that way...).

http://gitolite.com/gitolite/cache.html says "WARNING: this has not been tested in a while. YMMV". Uhhhh. Not confidence-inspiring.
N
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 25957@debbugs.gnu.org)
20170304173339.ubumkmfdfrkbascj@abyayala
On 17-03-04 16:43:09, Danny Milosavljevic wrote:
Toggle quote (14 lines)
> Hi ng0,
>
> > I think there should be a reference to /gnu/store/ reddis and not
> > "/usr/sbin/redis-server". Different problem, related bug.. This can be
> > solved in a commit after this bug.
>
> Yeah.
>
> I would question why a normal application needs to start a redis *server* in the first place. Sounds strange to me. But I agree that if it wants to do that it should use a store reference.
>
> <https://redis.io/topics/admin> says "Redis is designed to be a very long running process in your server" so that definitely reads to me that a normal program shouldn't just start redis-server when it feels like it (and I hope it stops it again later? After reading the source code it doesn't appear that way...).
>
> <http://gitolite.com/gitolite/cache.html> says "WARNING: this has not been tested in a while. YMMV". Uhhhh. Not confidence-inspiring.

It was the first time I read about reddis in gitolite context, and in
all the time I used gitolite I never really needed it when building or
running.
I disregard this as not very important and not really important at all
to fix. It should be fixed in the long run, but my main concern was
usability of gitolite, which has been addressed in one of the two
patches I've sent.
Z
Z
zimoun wrote on 5 Jan 01:07 +0100
Re: bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
(address . 25957@debbugs.gnu.org)
86k0ff9has.fsf_-_@gmail.com
Hi,

This old bug [1] is still relevant.


On Sat, 04 Mar 2017 at 13:32, ng0 <contact.ng0@cryptolab.net> wrote:
Toggle quote (2 lines)
> On 17-03-03 22:27:43, ng0 wrote:

This previous…

Toggle quote (8 lines)
> [user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
> commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
> lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
> lib/Gitolite/Cache.pm:127: open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
> ed: $!";

…is now…

Toggle snippet (5 lines)
share/gitolite/lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
share/gitolite/lib/Gitolite/Cache.pm:127: open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server failed: $!";
share/gitolite/commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";

…but…

Toggle quote (6 lines)
> The parts I want to fix as my immediately affect every user, are in
> the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
> I think there should be a reference to /gnu/store/ reddis and not
> "/usr/sbin/redis-server". Different problem, related bug.. This can be
> solved in a commit after this bug.

…the package redis is not a dependency of gitolite. Therefore, the
question is: is our Gitolite package working with Redis? Even using the
/usr/bin one? Idem for SVN.

Otherwise, I am favor to remove the 2 “problematic” references. WDYT?


Cheers,
simon
E
E
Efraim Flashner wrote on 12 Jan 19:07 +0100
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 25957@debbugs.gnu.org)
Yd8Y6ScvOqyczm2A@3900XT
On Wed, Jan 05, 2022 at 01:07:07AM +0100, zimoun wrote:
Toggle quote (41 lines)
> Hi,
>
> This old bug [1] is still relevant.
>
> 1: <http://issues.guix.gnu.org/issue/25957>
>
> On Sat, 04 Mar 2017 at 13:32, ng0 <contact.ng0@cryptolab.net> wrote:
> > On 17-03-03 22:27:43, ng0 wrote:
>
> This previous…
>
> > [user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
> > commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> > lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> > lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
> > lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
> > lib/Gitolite/Cache.pm:127: open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
> > ed: $!";
>
> …is now…
>
> --8<---------------cut here---------------start------------->8---
> share/gitolite/lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> share/gitolite/lib/Gitolite/Cache.pm:127: open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server failed: $!";
> share/gitolite/commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> --8<---------------cut here---------------end--------------->8---
>
> …but…
>
> > The parts I want to fix as my immediately affect every user, are in
> > the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
> > I think there should be a reference to /gnu/store/ reddis and not
> > "/usr/sbin/redis-server". Different problem, related bug.. This can be
> > solved in a commit after this bug.
>
> …the package redis is not a dependency of gitolite. Therefore, the
> question is: is our Gitolite package working with Redis? Even using the
> /usr/bin one? Idem for SVN.
>
> Otherwise, I am favor to remove the 2 “problematic” references. WDYT?

Or change it to search the $PATH for the binary, so it would just be
'redis-server' or 'svnserve'

--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmHfGOgACgkQQarn3Mo9
g1H5RQ//UJ90vtM+nXuz+3mhuFap57Df4c1llA3rHCpg9OI/o4ZgBdqF1pO8Shcp
iy8S/MVOsfpOzTC3Xu88wA5Z03sEmEGRNTPnZKi1dEng5SYIczy9BIsQcxhL/xuy
XEJg7FuFWLX2N1beREWlAAcWyB12mu2I0AeRS+5yqY4AClUeHdJ+iR8kN1BrOTy/
1hTeGJDPNbxMqDAfdLtWcdX4G4PRhpfykAOyGZmj6DrFNczgs+RB/vCMWTAoEKcx
uuvinG/WFohduA4hbtgczQPbJ3P1cgQQl5o/1qUdgzWOK6bD9EUXhUhiQFpRyDXg
lu0pnGTRXJ+Ac6yp7/N5oRPiSqJY8bR43FSbjr6dSuXTt71HXzL0bDtjroOLdHi7
S/72adidesoXFtYiGUnMu2vGYrr3mDEUHRqMiccbNifaPthJwSpI1vbTe5pHUWw5
sT0s48DXCy7MDqHZ4gEpVpk8NFBBxMCVAPHERxSQihg45ca6DnIptwGSilntm0Xz
zI474GcJi2XdD1pQgJ3QsS40G1/RlgfEjgGgd/Y+gILDFS2BQKI4LjmTvNwVVn4B
ONjL1tvwAabnKnmeDgEQSvQz1IedgJVdSqPCIts/0qMAkFASygzS14TL171lzfCR
GoLH1rjcBujj0iF683SGET38r30kGqsnCo34vjhSAxeFoal2zO0=
=caCW
-----END PGP SIGNATURE-----


Z
Z
zimoun wrote on 3 Feb 03:49 +0100
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 25957@debbugs.gnu.org)
8635l01x7a.fsf@gmail.com
Hi Efraim,

On Wed, 12 Jan 2022 at 20:07, Efraim Flashner <efraim@flashner.co.il> wrote:

Toggle quote (9 lines)
>> …the package redis is not a dependency of gitolite. Therefore, the
>> question is: is our Gitolite package working with Redis? Even using the
>> /usr/bin one? Idem for SVN.
>>
>> Otherwise, I am favor to remove the 2 “problematic” references. WDYT?
>
> Or change it to search the $PATH for the binary, so it would just be
> 'redis-server' or 'svnserve'

Is our Gitolite package working with Redis? If not, why try to fix. ;-)


Cheers,
simon
Z
Z
zimoun wrote on 23 Mar 11:45 +0100
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 25957@debbugs.gnu.org)
86lex10wwr.fsf@gmail.com
Hi,

On Thu, 03 Feb 2022 at 03:49, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (13 lines)
> On Wed, 12 Jan 2022 at 20:07, Efraim Flashner <efraim@flashner.co.il> wrote:
>
>>> …the package redis is not a dependency of gitolite. Therefore, the
>>> question is: is our Gitolite package working with Redis? Even using the
>>> /usr/bin one? Idem for SVN.
>>>
>>> Otherwise, I am favor to remove the 2 “problematic” references. WDYT?
>>
>> Or change it to search the $PATH for the binary, so it would just be
>> 'redis-server' or 'svnserve'
>
> Is our Gitolite package working with Redis? If not, why try to fix. ;-)

What is the status of this old bug [1]? Is it actionable? If yes, what
is the action? If no, let close it. :-) WDYT?




Cheers,
simon
M
M
Maxime Devos wrote on 23 Mar 13:44 +0100
(address . 25957@debbugs.gnu.org)
6a325301e7cc55ee08652c67e49c3eb8a0802baa.camel@telenet.be
zimoun schreef op wo 23-03-2022 om 11:45 [+0100]:
Toggle quote (23 lines)
> > On Wed, 12 Jan 2022 at 20:07, Efraim Flashner
> > <efraim@flashner.co.il> wrote:
> >
> > > > …the package redis is not a dependency of gitolite.  Therefore,
> > > > the
> > > > question is: is our Gitolite package working with Redis?  Even
> > > > using the
> > > > /usr/bin one?  Idem for SVN.
> > > >
> > > > Otherwise, I am favor to remove the 2 “problematic”
> > > > references.   WDYT?
> > >
> > > Or change it to search the $PATH for the binary, so it would just
> > > be
> > > 'redis-server' or 'svnserve'
> >
> > Is our Gitolite package working with Redis?  If not, why try to
> > fix. ;-)
>
> What is the status of this old bug [1]?  Is it actionable?  If yes,
> what
> is the action?  If no, let close it. :-)  WDYT?

Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve'
into a '/gnu/store/...' (untested), so seems actionable to me.
Alternatively, as Efraim wrote, let it search the $PATH (that might be
useful if adding svnserve would increase the closure too much and it is
an optional dependency in practice?).

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYjsWLRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7i9eAQC7udOOdgxpn6huFy0Pq6TulGQr
rM8xLyTjPS/y6olwAgEAvrKQqgpEJv4qd5J0k59AI3N34xLGk68jzBMn2eQrMQg=
=JfJY
-----END PGP SIGNATURE-----


E
E
Efraim Flashner wrote on 28 Mar 08:49 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)
YkFaedjhpznFqbNM@3900XT
On Wed, Mar 23, 2022 at 01:44:29PM +0100, Maxime Devos wrote:
Toggle quote (30 lines)
> zimoun schreef op wo 23-03-2022 om 11:45 [+0100]:
> > > On Wed, 12 Jan 2022 at 20:07, Efraim Flashner
> > > <efraim@flashner.co.il> wrote:
> > >
> > > > > …the package redis is not a dependency of gitolite.  Therefore,
> > > > > the
> > > > > question is: is our Gitolite package working with Redis?  Even
> > > > > using the
> > > > > /usr/bin one?  Idem for SVN.
> > > > >
> > > > > Otherwise, I am favor to remove the 2 “problematic”
> > > > > references.   WDYT?
> > > >
> > > > Or change it to search the $PATH for the binary, so it would just
> > > > be
> > > > 'redis-server' or 'svnserve'
> > >
> > > Is our Gitolite package working with Redis?  If not, why try to
> > > fix. ;-)
> >
> > What is the status of this old bug [1]?  Is it actionable?  If yes,
> > what
> > is the action?  If no, let close it. :-)  WDYT?
>
> Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve'
> into a '/gnu/store/...' (untested), so seems actionable to me.
> Alternatively, as Efraim wrote, let it search the $PATH (that might be
> useful if adding svnserve would increase the closure too much and it is
> an optional dependency in practice?).

I spent some time looking at gitolite and the service. As I understand
it, with the exception of svnserve, it searches $PATH for a number of
different binaries, including git-annex. I believe that this would only
work if git-annex (and potentially other packages) are installed
globally.

In addition, git (not git-minimal) and openssh are propagated inputs AND
wrapped. I haven't tested to see if wrapping only is enough.

I think the best choice is to:
A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH,
like it does with the other helpers.
B: Adjust the service so that it automatically creates a variant (or
just a wrapped version) of the package which is wrapped with a list of
additional packages so that they can be in gitolite's path. If I were
deploying this to an arm device I wouldn't want it wrapped with
git-annex since it doesn't build, but would definitely want it for an
x86_64 machine.

I suppose we should try to find someone who is using the gitolite
service and see if they can be our test subject for wrapping the package
with optional addons.

--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmJBWnIACgkQQarn3Mo9
g1F36A//TNGr5K6tptHG5aR4e6/StBJM5qrUJb/ldVQZ8yr0LpHQZF+PgHsdOX3S
/thtlEwQuqVTnaBptF+9w8R35IowpDc1fwwQgy5zgKpFdH1r90ufFaNFm2YJ6Pep
dLxpRyr3hxc3bOk6/B7cEfyBbD2A56qh4pLcGUrSbmfOH1VYZDKWNonBz1zZd4PC
oyViPxFLWdXxblaSLo2CCxfKcsM0jmBV7VHgfOYaTrSvr+UStiKLf1Doib4Hfz2V
ZnPq2oTv+tTr4gI7dSF5eOu4UtK45KcFLwuPWDNBw3s9dDeGcZ8ly6snbPFRhevU
mAHo7rqkn1rpQLxAUYSZv35eZnpj2953TtekdCacHtrw+I9AhhBNwLhWJg3FF5By
KkG9jbLp1d64UdTDCrxCte5XacS3mailiW0Oh2wzr/R5W42CntrVGPK1PSduyCe1
EzbkdnGd3lLpmk6IDhTrjh6vGq07QdsyH+i9vfEsTboM2sbAUeT4IQagYAYL4Q0H
WFatKL4I00BUYI/cGfaxIO6Cc1566CI4YNkTCGf0Y6nOKMMjllZdOGXsQ3D/cm3T
nyBDsIZc2PPSkC63CN9KNz3XWFiRqw4i9pmLe0KLTOsL8i+goYkSYxkWlI8rdqad
HP75zsuJ8+uK/06SpwPRbodCr1CzGzMtCnXZjFhFAdL8K3zIF90=
=KBfr
-----END PGP SIGNATURE-----


?