Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 20 additions & 21 deletions book/04-git-server/sections/git-daemon.asc
Original file line number Diff line number Diff line change
@@ -1,34 +1,34 @@
=== Git Daemon

(((serving repositories, git protocol)))
Next we'll set up a daemon serving repositories over the ``Git'' protocol.
This is common choice for fast, unauthenticated access to your Git data.
Remember that since it's not an authenticated service, anything you serve over this protocol is public within its network.
Em seguida, configuraremos um daemon que disponibiliza repositórios sobre o protocolo ``Git''.
Esta é uma escolha comumpara acesso rápido e sem autenticação para seus dados Git.
Lembre-se de que, como não é um serviço autenticado, tudo que você disponibiliza através desse protocolo é público dentro da sua rede.

If you're running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world.
If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each.
Se você estiver executando isso em um servidor fora do seu firewall, deve somente ser usado para projetos que sejam publicamente visíveis.
Se o servidor que você está executando isso estiver dentro do seu firewall, você pode usá-lo para projetos que um grande número de pessoas ou computadores (integração contínua ou servidores de compilação) tem acesso de apenas leitura, quando você não quer adicionar uma chave SSh para cada um.

In any case, the Git protocol is relatively easy to set up.
Basically, you need to run this command in a daemonized manner:(((git commands, daemon)))
Em todo caso, o protocolo Git é relativamente fácil de configurar.
Basicamente você precisa executar esse comando em modo daemon:(((git commands, daemon)))

[source,console]
----
$ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
----

`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export.
If you're running a firewall, you'll also need to punch a hole in it at port 9418 on the box you're setting this up on.
`--reuseaddr` permite o servidor reiniciar sem esperar que conexões antigas expirem, a opção `--base-path` permite pessoas clonar o projeto sem especificar o caminho completo e o caminho no final indica ao daemon Git onde procurar por repositórios para exportar.
Se você estiver executando um firewall, você tamém precisará abrir uma conexão na porta 9418 no servidor onde está configurado o serviço.

You can daemonize this process a number of ways, depending on the operating system you're running.
On an Ubuntu machine, you can use an Upstart script.
So, in the following file
Você pode executar esse processo como daemon de várias maneiras, dependendo do sistema operacional que você está executando.
Em uma máquina Ubuntu, você pode usar um script Upstart.
Portanto, no seguinte arquivo:

[source,console]
----
/etc/init/local-git-daemon.conf
----

you put this script:
Você insere esse script:

[source,console]
----
Expand All @@ -42,26 +42,25 @@ exec /usr/bin/git daemon \
respawn
----

For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories – you can easily do this by creating a new user 'git-ro' and running the daemon as them.
For the sake of simplicity we'll simply run it as the same 'git' user that `git-shell` is running as.
Por motivos de segurança, é fortemente recomendado ter esse serviço executando como um usuário com permissões de somente leitura para os repositórios - você pode fazer isso facilmente criando um novo usuário 'git-ro' e executar o serviço como ele.
Para simplificar, nós vamos simplesmente executar com o mesmo usuário 'git' que está executando o `git-shell`.

When you restart your machine, your Git daemon will start automatically and respawn if it goes down.
To get it running without having to reboot, you can run this:
Quando você reiniciar sua máquina, seu serviço vai iniciar automaticamente e reiniciar caso seja interrompido. Para executá-lo sem precisar reiniciar, você pode executar o seguinte comando:

[source,console]
----
$ initctl start local-git-daemon
----

On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else – as long as you get that command daemonized and watched somehow.
Em outros sistemas, você pode querer usar o `xinetd`, um script no seu sistema `sysvinit` ou algo similar - contanto que você tenha esse comando em segundo plano e possa monitorá-lo de alguma forma.

Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to.
You can do this in each repository by creating a file named `git-daemon-export-ok`.
Em seguida, você precisa dizer ao Git quais repositórios permitir acesso não autenticado a serviços do servidor Git.
Você pode fazer isso em cada repositório criando um arquivo chamado `git-daemon-export-ok`.

[source,console]
----
$ cd /path/to/project.git
$ touch git-daemon-export-ok
----

The presence of that file tells Git that it's OK to serve this project without authentication.
A presença desse arquivo diz ao Git que está tudo bem servir esse projeto sem autenticação.
87 changes: 44 additions & 43 deletions book/04-git-server/sections/git-on-a-server.asc
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
[[r_git_on_the_server]]
=== Getting Git on a Server
=== Instalando Git em um servidor

Now we'll cover setting up a Git service running these protocols on your own server.
Agora vamos abordar a configuração de um serviço git rodando esses protocolos em seu servidor.

[NOTE]
====
Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux based server, though it's also possible to run these services on Mac or Windows servers.
Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved.
Aqui estaremos demonstrando comandos e passos necessários para fazer instalações básicas e simplificadas em um servidor baseado em linux, embora seja possível rodar esses serviçoes em servidores Mac ou Windows.
Na prática, configurar um servidor de produção dentro da sua infraestrutura certamente irá envolver diferenças nas medidas de segurança ou nas ferramentas do sistema operacional, mas esperamos que isso lhe dê uma ideia geral do que está envolvido.
====

In order to initially set up any Git server, you have to export an existing repository into a new bare repository – a repository that doesn't contain a working directory.
This is generally straightforward to do.
In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option.(((git commands, clone, bare)))
By convention, bare repository directories end in `.git`, like so:
Para configurar inicialmente qualquer servidor git, você tem que exportar um repositório existente em um novo repositório vazio (bare repository) - um repositório que não contém um diretório de trabalho.
Isso geralmente é fácil de fazer.
Para clonar seu repositório e criar um novo repositório vazio, você roda o comando com a opção `--bare`.(((git commands, clone, bare)))
Por convenção, diretórios vazios terminam com `.git`, como neste exemplo:

[source,console]
----
Expand All @@ -21,40 +21,41 @@ Cloning into bare repository 'my_project.git'...
done.
----

You should now have a copy of the Git directory data in your `my_project.git` directory.
Agora você deve ter uma cópia do diretório de dados Git em seu diretório `my_project.git`.

This is roughly equivalent to something like
Isso é aproximadamente equivalente a algo como:

[source,console]
----
$ cp -Rf my_project/.git my_project.git
----

There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing.
It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.
Existem algumas pequenas diferenças no arquivo de configuração; mas para o seu propósito é praticamente a mesma coisa.
Ele pega o repositório Git isoladamente, sem um diretório de trabalho e cria um diretório específico apenas pare ele.

[[r_bare_repo]]
==== Putting the Bare Repository on a Server
==== Colocando o repositório vazio em um servidor

Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols.
Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/srv/git` directory.
Assuming that `/srv/git` exists on that server, you can set up your new repository by copying your bare repository over:
Agora que você tem uma cópia vazia do seu repositório, tudo que você precisa fazer é colocá-lo em um servidor e configurar seus protocolos.
Vamos supor que você configurou um servidor chamado `git.example.com` que você possui acesso via SSH e você quer armazenar todos os seus repositórios Git no diretório /srv/git.
Supondo que `/srv/git` exista no servidor, você pode configurar seu novo repositório copiando seu repositório vazio para ele:

[source,console]
----
$ scp -r my_project.git user@git.example.com:/srv/git
----

At this point, other users who have SSH access to the same server which has read-access to the `/srv/git` directory can clone your repository by running
Neste ponto, outros usuários que tenham acesso SSH para o mesmo servidor e que possuem permissão de leitura para o diretório `/srv/git` pode clonar seu repositório executando o seguinte comando:

[source,console]
----
$ git clone user@git.example.com:/srv/git/my_project.git
----

If a user SSHs into a server and has write access to the `/srv/git/my_project.git` directory, they will also automatically have push access.
Se um usuário acessar um servidor via SSH e tiver acesso ao diretório `/srv/git/my_project.git`, ele também vai automaticamente ter permissão para enviar alterações (push).

Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare)))
Git vai automaticamente adicionar permissões de escrita de grupo a um repositório corretamente se você rodar o comando `git init`
com a opção `--shared`.(((git commands, init, bare)))

[source,console]
----
Expand All @@ -63,38 +64,38 @@ $ cd /srv/git/my_project.git
$ git init --bare --shared
----

You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access.
Now you're ready to collaborate on the same project.
Veja o quão fácil é pegar um repositório Git, criar uma versão vazia e colocá-la em um servidor do qual você e seus colaboradores tem acesso SSH.
Agora vocês estão prontos para colaborar no mesmo projeto.

It's important to note that this is literally all you need to do to run a useful Git server to which several people have access – just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to.
You're ready to go – nothing else needed.
É importante notar que isso é literalmente tudo o que você precisa fazer para executar um servidor Git funcional ao qual várias pessoas tenham acesso - basta adicionar contas com acesso SSH em um servidor e colocar um servidor vazio em algum lugar que todos esses usuários tenham acesso de leitura e escrita. Você está pronto - nada mais é necessário.

In the next few sections, you'll see how to expand to more sophisticated setups.
This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs and more.
However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
Nas próximas seções, você verá como expandir para configurações mais sofisticadas.
Essa discussão irá incluir não ter que criar contas de usuários para cada usuário, adicionar acesso público de leitura para repositórios, configurar interfaces web e muito mais.
No entanto, mantenha em mente que para colaborar com algumas pessoas em um projeto privado, tudo que você _precisa_ é um servidor SSH e um repositório vazio.

==== Small Setups
==== Configurações pequenas

If you're a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you.
One of the most complicated aspects of setting up a Git server is user management.
If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit more difficult to arrange.
Se você faz parte de uma pequena empresa ou está experimentanto Git em sua organização e tem poucos desenvolvedores, as coias podem ser simples para você.
Um dos aspectos mais complicados de configurar um servidor Git é o gerenciamento de usuários.
Se você quer que alguns repositórios tenham acesso de somente leitura para certos usuários e leitura/escrita para outros, acesso e permissões podem ser um pouco mais difíceis de configurar.

===== SSH Access
===== Acesso SSH

(((serving repositories, SSH)))
If you have a server to which all your developers already have SSH access, it's generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section).
If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs.

If you want to place your repositories on a server that doesn't have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them.
We assume that if you have a server with which to do this, you already have an SSH server installed, and that's how you're accessing the server.
Se você tem um servidor do qual todos os seus desenvolvedores já tem acesso SSH, geralmente é mais fácil configurar seu primeiro repositório nele, porque você tem que fazer quase nenhum trabalho (como abordamos na seção anterior).
Se você quer um controle de acesso mais complexo em seus repositórios, você pode gerenciá-las com as permissões normais do sistema de arquivo do sistema operacional que seu servidor executa.

There are a few ways you can give access to everyone on your team.
The first is to set up accounts for everybody, which is straightforward but can be cumbersome.
You may not want to run `adduser` and set temporary passwords for every user.
Se você quer colocar seus servidores em um servidor que não possui contas para todos no seu time que você quer que tenha acesso de escrita, você terá qeu configurar acesso SSH para eles.
Nós assumimos que se você tem um servidor que deseja fazer isso, você já possuam um servidor SSH instalado e que é dessa maneira que você está acessando o servidor.

A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user.
At that point, everyone will be able to access that machine via the 'git' user.
This doesn't affect the commit data in any way – the SSH user you connect as doesn't affect the commits you've recorded.
Há algumas maneiras de dar acesso a todos no seu time.
A primeira é configurar contas para todos, que é bem simples, mas pode ser trabalhoso.
Você pode não querer executar `adduser` e definir senhas temporárias para cada usuário.

Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up.
As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work.
Um segundo método é criar um único usuário 'git' na máquina, pedir para cada usuário que deve ter acesso de escrita enviar para você uma chave pública SSH e adicionar essa chave no arquivo `~/.ssh/authorized_keys` do seu novo usuário 'git'.
A partir daí, todos vão ser capazes de acessar a máquina através do usuário 'git'.
Isso não afeta os dados de commit de forma alguma - o usuário SSH que você conecta não afeta os commits que você registrou.

Outra maneira de fazer isso é configurar seu servidor SSH para autenticar a partir de um servidor LDAP ou alguma outra fonte de autenticação que você já tenha configurado.
Contanto que cada usuário possa ter acesso ao shell da máquina, qualquer mecanismo de autenticação SSH que você possa imaginar deve funcionar.
Loading