Re: Pushing a git repository to a new server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
<kostix+git@xxxxxxxxx> wrote:
> What's wrong with
> $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
> $ git push --all git@remotehost:MyOtherRepo.git
> ?

Nothing, I just wanted to make myself a command to do that for me.

>> The reason I had to use my user is the git user's shell is git-prompt
>
> There's no such thing as git-prompt.  The restricted login shell for
> SSH-only access typically used for such a "virtual" Git user is
> git-shell.

Sorry, git-prompt is something I made for myself. I meant git-shell.

> It's not really clear what do you want to achieve.
> The reason the git-shell shell is *restricted* (read its manual page)
> is to shrink the surface of possible attacks in the case the shell
> account used for accessing Git repos over SSH is compromized (the key or
> password stolen, for instance).  This is achieved by only allowing
> commands like git-upload-pack etc in the shell (no general file
> manipulation commands etc).  So what creating "git command that can
> talk to the server using git-prompt ..." would really buy you?

I want to create a git-command that 1) creates a bare version of the
current repo, 2) and uploads it to the specified path on my server
(using tar, but that's not the point).

My problem is that I have no idea how things like git-push works via a
user with git-shell. Can you only run certain git commands, like
git-upload-pack? Because I tried running 'ssh git@server git status'
and that failed.

> I think the way to go is to start using gitolite [1] or implement by
> hand a subset of what it does (a custom login shell which is allowed to
> do certain things in a special area of the filesystem designated to keep
> Git repositories) or just set up a special account on the server
> ("git-admin", for instance) which would have a regular login shell set
> for it and would be in the same group as the user "git" (or even have
> the same UID) so that they could share the files they create (subject to
> active umasks of processes run as both users though).

I thought about the secondary user idea. I decided that trying to make
my own command would be more fun.


-- 
Ethan Reesor (Gmail)
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]