static-httpd

Sitio web estático (HTML + CSS) que sostiene el blog del autor
Log | Files | Refs

index.html (6277B)


      1 <!DOCTYPE html>
      2 <html>
      3 <head>
      4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      5 <meta name="viewport" content="width=device-width, initial-scale=1" />
      6 <title>Construcción de mi propio servidor Git</title>
      7 <link rel="icon" type="image/png" href="/favicon.png" />
      8 <link rel="stylesheet" type="text/css" href="../article.css" />
      9 </head>
     10 <body>
     11 <header>
     12 <p class="title">Construcción de mi propio servidor Git</p>
     13 <p class="date">22 de noviembre de 2020 • fjbalon</p>
     14 </header>
     15 <p>Aquí todos conocemos el software o protocolo desarrollado en inicio por Linus Torvalds: Git. Un sistema de control de versiones, que se constituye como una herramienta indispensable, a día de hoy, para cualquier programador; especialmente en el software libre. Git funciona como cliente o como servidor, y cada cliente aloja en local una copia del software que sincronizará con el servidor en función de lo que el cliente convenga. Los despliegues de Git más conocidos son Github o Gitlab, donde éstos te ofrecen una interfaz gráfica pulida y almacenamiento de servidor para todos los proyectos que se deseen incluir. Por ello, la duda razonable que debe asaltar al lector sería: ¿por qué querría crear mi propio servidor de Git?</p>
     16 <p>Veamos, una buena razón para alojar tus propios repositorios Git es tener y mantener el control sobre tu propia infraestructura informática, tanto a nivel de sistema como a nivel de código, guardando incluso el secreto de aquellos códigos que quieras mantener sin publicar (y que de otra forma lo estarías cediendo al ordenador de otro, confiando ciegamente en que verdaderamente se encuentre oculto). Considero que los servidores de Git comúnmente utilizados como Github, Gitlab, Bitbucket… No son de fiar, en cuanto son propietarios desconocidos y sostenedores de tu código. No es secreto que estos servicios analizan el código, aplican telemetría e inteligencia sobre ellos, analizan las conexiones de sus usuarios y aplican restricciones y limitaciones. Al fin y al cabo son empresas con fines comerciales, y a menudo con fines ocultos. En el caso de Microsoft, como propietario de Github es mucho más lamentable y peligrosa la situación.</p>
     17 <p>En cuanto a economía doméstica, estos servicios también tienen diferentes planes de precios y varias restricciones (arbitrarias en muchos casos). Sin embargo cuando usted mismo lo aloja, las restricciones son los límites de recursos del sistema y su conexión, por lo tanto, es una solución mucho más flexible, adaptada y convergente con el usuario.</p>
     18 <h2>¿Cómo creo mi propio servidor de Git?</h2>
     19 <p>Bien, entremos en el barro técnico.</p>
     20 <p>Lo primero que debemos hacer es tener Git instalado. Debido a la gran cantidad de distribuciones y formas variopintas de realizar la instalación, voy a obviarla. No es dificil instalar Git y se encuentra disponible, que yo sepa, en todos los repositorios oficiales de todas las distros.</p>
     21 <p>También voy a obviar el uso general de Git. No es objetivo de esta entrada explicar cómo realizar cambios en el software, realizar commits, status, push y pull, revisar el histórico de cambios, etcétera. Si me animo podría escribir un post a parte a modo de curso, del uso de Git a nivel de cliente. Pero en este caso me centro en el servidor.</p>
     22 <p>Para ello, el primer paso sería crear el usuario git (a nivel de sistema operativo), encargado de gestionar todos los procesos referentes a los repositorios y al servidor. Además, con el objetivo de dotar acceso mediante SSH añadimos authorized_keys y añadimos al fichero las claves públicas de los clientes.</p>
     23 <pre><code>adduser git
     24 su git
     25 cd
     26 mkdir .ssh && chmod 700 .ssh
     27 touch .ssh/authorized_keys 
     28 chmod 600 .ssh/authorized_keys</code></pre>
     29 <p>Los repositorios pueden estar en el directorio que se quiera. En este caso, se encontrarán en el directorio git en la raíz del sistema. Para lo que tendremos que crearlo. Por cada repositorio, se crea un directorio (aconsejable es que terminen con .git). Para iniciar un repositorio como server usamos el parámetro <emb>init --bare.</emb></p>
     30 <pre><code>mkdir /git
     31 cd /git
     32 mkdir code.git
     33 chown git:git code.git
     34 cd code.git
     35 git init --bare
     36 Initialized empty Git repository in /git/code.git/</code></pre>
     37 <h2>Publicación de repositorios</h2>
     38 <p>Quien haya sido un poco sagaz, se habrá dado cuenta que de esta forma el único que puede acceder a dichos repositorios es aquel que conozca la contraseña del usuario git, o bien que su clave pública esté alojada en el servidor para que sea reconocido. Es decir, sólo podría acceder al repositorio el que conozca personalmente al propietario del servidor.</p>
     39 <p>Por ello tenemos la opción de publicar el repositorio, de forma que pueda ser clonado por todos (al igual que en Github y similares).</p>
     40 <p>Para ello empleamos <emb>git-daemon</emb>, indicándole el directorio donde se encuentran los repositorios.</p>
     41 <pre><code>git daemon --reuseaddr --base-path=/git/ /git/</code></pre>
     42 <p>Esto no basta para publicar el repositorio, ya que el demonio de git iterará en el directorio anteriormente pasado en busca de repositorios exportables, éstos son aquellos que tengan el fichero <emb>git-daemon-export-ok</emb> en su raíz.</p>
     43 <pre><code>touch /git/code.git/git-daemon-export-ok</code></pre>
     44 <p>De esta forma, cualquier cliente podría clonar el repositorio usando la siguiente dirección:</p>
     45 <pre><code>git clone git://templier.es/code.git</code></pre>
     46 <h2>En el lado del cliente</h2>
     47 <p>De esta simple forma, cualquier equipo que tenga acceso al servidor podría, a través de Git y SSH, clonar repositorios. En el lado del cliente, configuraríamos nuestros parámetros (globales, si no sabes lo que haces):</p>
     48 <pre><code>git config --global user.name "fjbalon"
     49 git config --global user.email fjbalon@templier.es       
     50 git config --global core.editor vim</code></pre>
     51 <p>O directamente modificando el fichero <emb>~/.gitconfig</emb>:</p>
     52 <pre><code>[user]
     53 email = fjbalon@templier.es
     54 name = fjbalon
     55 [core]
     56 editor = vim</code></pre>
     57 <p>La descarga mediante SSH y mediante repositorio público se hará de tal forma:</p>
     58 <pre><code>git clone git@templier.es:/git/code.git
     59 git clone git://templier.es/code.git</code></pre>
     60 </body>
     61 </html>