Temporarily disable all push access easily
Sebastian Hahn
is there an easy way to disable push access
temporarily, without rewriting the configuration
file? I'd like to run some repository maintenance
occasionally, and that shouldn't be interrupted
by commits. Ideally, I'd like to give the users
an error message "pushing is currently disabled,
please try in a few minuts" or so. Does anything
come to mind?
Thanks
Sebastian
Christian MICHON
to allow temporary repository maintenance, inside the account and on
the physical machine hosting gitolite:
"mv ~/.gitolite ~/.gitolite_" should allow this quickly...
But you'll not get any message back else than this for example:
ssh gitolite info
bash: /home/gitolite/.gitolite/src/gl-auth-command: No such file or directory
Once you're done, "mv ~/.gitolite_ ~/.gitolite"
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Sitaram Chamarty
With the code as it is, nothing comes to mind other than temp'ly
renaming the
"gl-auth-command" program that is specified in ~/.ssh/authorized_keys.
This is the simplest solution but will also prevent fetches/clones too;
if the
window is small enough that should not matter. You can replace it by a
shell
script that basically prints some message to STDERR instead.
If you need a longer window (and thus not prevent fetches) you can do
the same
to the update hook but this is a little more tricky. Reasonably recent
gitolite's do this via symlink, so changing one ought to do it for all
of them;
again -- just replace with code that prints and message to STDERR and *dies*
(exits with non-0 code).
Longer term, I guess a bit of code in the update hook wouldn't hurt;
sort of a
counterpart to the current:
exit 0 if exists $ENV{GL_BYPASS_UPDATE_HOOK};
to say
if (-f $ENV{HOME}/.gitolite.down) {
system("cat ~/.gitolite.down >&2");
exit 1;
}
so all you'd do to initiate maint mode is to type some message into that
file.
And when done with maint mode just remove the file.
I'll wait a bit for other ideas and probably make that change in a few days.
Question: do people anticipate both reads AND writes need to be
blocked? Maybe
the gl-auth-command should look for (and act upon) a file called
".gitolite.down" and update hook looks for ".gitolite.readonly". The
first one
overrides of course (it'll never get to the second one if the first one is
present). Ideas for filenames?
Does this help?
Sitaram
PS: I know someone is going to now ask for "disable only some
repositories" ;-)
Sorry; won't do
Christian MICHON
>
> PS: I know someone is going to now ask for "disable only some
> repositories" ;-)
> Sorry; won't do
>
>
for this one, you could suggest the person to temporarily move the
directories away from ~/repositories.
you'll get R and W denied at no cost: it's not that difficult, no
extra coding required :-)
Eli Barzilay
> On Mon, May 31, 2010 at 1:15 PM, Sitaram Chamarty <sit...@atc.tcs.com> wrote:
> >
> > PS: I know someone is going to now ask for "disable only some
> > repositories" ;-)
> > Sorry; won't do
> >
> >
>
> for this one, you could suggest the person to temporarily move the
> directories away from ~/repositories.
>
> you'll get R and W denied at no cost: it's not that difficult, no
> extra coding required :-)
Gitolite will create new ones.
But instead of (or in addition to) checking a global .gitolite.down
file, it could check for one in the repository directory, then people
can add an administrative command that touches the file, does some
stuff, then removes it.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Sitaram Chamarty
> On May 31, Christian MICHON wrote:
>> On Mon, May 31, 2010 at 1:15 PM, Sitaram Chamarty <sit...@atc.tcs.com> wrote:
>> >
>> > PS: I know someone is going to now ask for "disable only some
>> > repositories" ;-)
>> > Sorry; won't do
>> >
>> >
>>
>> for this one, you could suggest the person to temporarily move the
>> directories away from ~/repositories.
>>
>> you'll get R and W denied at no cost: it's not that difficult, no
>> extra coding required :-)
>
> Gitolite will create new ones.
Bingo!
> But instead of (or in addition to) checking a global .gitolite.down
> file, it could check for one in the repository directory, then people
> can add an administrative command that touches the file, does some
> stuff, then removes it.
Bingo again!
Tested reasonably well. Enjoy!!
Eli Barzilay
>
> Bingo!
> [...]
> Bingo again!
:)
(The only comment I have on this is that the nice property of a single
verb script with subverbs is not as important as the clarity of using
"enable" and "disable". But feel free to ignore me, since that's a
feature I don't need...)
Sitaram Chamarty
Sitaram Chamarty
> (The only comment I have on this is that the nice property of a single
> verb script with subverbs is not as important as the clarity of using
> "enable" and "disable". But feel free to ignore me, since that's a
> feature I don't need...)
more importantly, the stuff in contrib is just a suggestion; you can
do change it however you like.
Christian MICHON
> On Mon, May 31, 2010 at 5:53 PM, Eli Barzilay <e...@barzilay.org> wrote:
>> On May 31, Christian MICHON wrote:
>>> On Mon, May 31, 2010 at 1:15 PM, Sitaram Chamarty <sit...@atc.tcs.com> wrote:
>>> >
>>> > PS: I know someone is going to now ask for "disable only some
>>> > repositories" ;-)
>>> > Sorry; won't do
>>> >
>>> >
>>>
>>> for this one, you could suggest the person to temporarily move the
>>> directories away from ~/repositories.
>>>
>>> you'll get R and W denied at no cost: it's not that difficult, no
>>> extra coding required :-)
>>
>> Gitolite will create new ones.
>
> Bingo!
>
interestingly enough, it did not happen in my case, since I've an
extra hierarchical level between repositories directory and the real
repositories. I moved that folder containing repos, and it did not
create new ones.
I take the point, it's very valid if the folder structure is flat :-)
>> But instead of (or in addition to) checking a global .gitolite.down
>> file, it could check for one in the repository directory, then people
>> can add an administrative command that touches the file, does some
>> stuff, then removes it.
>
> Bingo again!
>
> http://github.com/sitaramc/gitolite/blob/50940d33023dfad9ed150553b4c178d46a763af5/doc/admin-defined-commands.mkd#A7
>
> Tested reasonably well. Enjoy!!
>
--