Servicios

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

root — Mon, 27 Feb 2017 21:03:16 +0000

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

Lunes, Febrero 27, 2017 - 22:03

Linux

Debian

Servicios

SSL

HTTPS

Let’s Encrypt es una autoridad certificadora (CA) abierta, gratuita, y libre. Llevan funcionando menos de un año, desde 2016, y se puede decir que es un servicio público, dirigido a promover y facilitar la obtención y configuración de certificados de seguridad para la web. Lo que ofrecen son certificados X.509 por dominio que podemos usar para TLS.

https://letsencrypt.org/

Hay varias organizaciones involucradas en el proyecto, siendo la principal la Internet Security Research Group (ISRG), junto a otras como Linux Foundation o Mozilla Foundation, pero también gigantes como Akamai o Cisco Systems. Es decir, que hay gente grande detrás, y el proyecto es bastante interesante, esperemos que dure.

Hasta ahora conseguir un certificado de seguridad para configurar HTTPS como es debido era bastante engorroso, además de que solía ser bastante caro. Últimamente los precios habían comenzado a bajar, pero ahora podemos conseguir un certificado propio por la cara, y con una instalación muy sencilla.

La principal ventaja del servicio se basa en la automatización de todo el proceso. El objetivo es configurar un servidor HTTPS y obtener un certificado de confianza para los navegadores sin intervención humana. Y dejarme deciros que me ha funcionado de verdad, y a la primera.

Esta automatización es la clave de todo el asunto, primero porque los certificados que nos ofrecen solamente son válidos por 90 días, lo que nos va a obligar a configurar la renovación de forma automática si no queremos estar cada tres meses renovando el certificado de forma manual.

Para esto han ideado un protocolo llamado ACME (Automated Certificate Management Environment), y el truco consiste en instalar un agente que se encargue de realizar automáticamente la petición y renovación del certificado, validando el solito nuestros dominios. Tenemos unos cuantos disponibles, pero el que recomiendan desde letsencrypt.org es Certbot:

https://certbot.eff.org

Certbot esta empaquetado en los repos de Debian, pero deberemos usar el repositorio de backports. Para ello basta con incluir una línea en nuestro fichero /etc/apt/sources.list. Si estáis usando Jessie (Debian 8) será:

deb http://ftp.debian.org/debian jessie-backports main

Después actualizamos:

apt-get update

Ahora ya podemos instalar el cliente de Certbot:

$ sudo apt-get install python-certbot-apache -t jessie-backports

Una vez instalado, ya podemos ejecutarlo, si estamos usando Apache, así:

$ certbot --apache

Y ya está. Lo juro. El instalador nos hará una serie de preguntas sobre los certificados que queremos instalar y listo. En mi caso tenia un Apache2 con varios VirtualHosts con diferentes nombres de dominio y alias, todos por el puerto 80. El instalador hizo solito todo esto:

Realizo una copia de cada fichero de configuración de VirtualHost, añadiendo -le-ssl.conf al nombre, y configuró en ellos el certificado.
En cada VirtualHost original, añadió una redirección automática a su versión de HTTPS
Configuró un servicio en Cron /etc/cron.d/certbot para realizar automáticamente la renovación de los certificados.
Reinicio el servidor Apache para cargar la nueva configuración.

Si no os hace mucha gracia que os toque la configuración, o tenéis algo realmente chungo montado, también podemos hacer que solamente consiga el certificado, y configurarlo nosotros a mano, así:

$ certbot --apache certonly

En mi caso, añadió las siguientes líneas a mis archivos de VirtualHost originales en el 80:

RewriteEngine on
RewriteCond %{SERVER_NAME} =xxxxx.com [OR]
RewriteCond %{SERVER_NAME} =www.xxxxx.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Los nuevos ficheros para SSL que creó Certbot son copias de los que yo tenía, en los que se añade la configuración del certificado:

SSLCertificateFile /etc/letsencrypt/live/xxxxxxx/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxxxxxx/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

Y este es el archivo que añade al Cron en /etc/cron.d/certbot para automatizar la renovación de los certificados:

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Podemos hacer una simulación del proceso de renovación de los certificados con este comando:

certbot renew --dry-run

Esto nos dará una idea de si funcionará o no cuando lo tenga que hacer el solo.

De momento, está funcionando perfectamente. Ya veremos cuando llegue la primera renovación...

Referencias

Proceso de como funciona completo: https://letsencrypt.org/how-it-works/
Porque 90 días: https://letsencrypt.org/2015/11/09/why-90-days.html
Lista de clientes soportados: https://community.letsencrypt.org/t/list-of-client-implementations/2103
Let's Encrypt en Wikipedia
Debian backports
How to install Certbot

Añadir nuevo comentario

Servidor de correo con Mailgun

root — Sat, 25 Feb 2017 17:11:38 +0000

Servidor de correo con Mailgun

Sábado, Febrero 25, 2017 - 18:11

Mailgun

Servicios

Yo creo que el servidor de correo ha sido el coñazo mas grande que yo he tenido que configurar nunca. Para ser justos, hace ya mas de 10 años desde que desmonte el dominio donde lo tenia con Postfix y desde entonces vengo usando Gmail, y por aquel entonces no tenia tanta experiencia con servidores y Linux, pero lo recuerdo como una locura constante: emails no entregados, spam por un tubo, relays chungos, blacklists, whitelists, suputamadrelists... vamos un horror.

Por aquí y aquí hay un par de artículos (en ingles) bastante interesantes al respecto.

Pues ahora quería volver a configurar un servicio de correo electrónico para varios dominios, pero no tenia ninguna gana de instalar un MTA propio, así que busque algunas alternativas. Las premisas eran sencillas:

Que pueda configurar en mi dominio y enviar y recibir correo como pepito@midominio.com.
Que pueda gestionar varias cuentas de correo.
Que me permita recibir y enviar correos desde mi cuenta de Gmail, que es la que uso habitualmente.
Que sea gratuito o de muy bajo coste.
No voy a hacer un uso extensivo de el, pero quiero poder tener direcciones de email propias.

Con esta idea en mente encontré Mailgun. Ellos se definen como un servicio de correo electrónico para desarrolladores, y solo eso ya suena bastante bien, ¿no?

Es un servicio bastante completo que provee de una API Rest para poder realizar operaciones en la recepción y envío, y básicamente nos va a gestionar hasta 10.000 mensajes al mes por la cara.

Tienen cosas bastante interesantes, como un SDK para PHP en Github donde tenéis algunos ejemplos sobre como usar su API para gestionar el correo:

https://github.com/mailgun/mailgun-php

Que nos ofrece

Con Mailgun vamos a poder:

Enviar correo desde nuestro dominio con un servidor SMTP externo.
Redireccionar el correo entrante hacia otras cuentas de correo, por ejemplo, Gmail: admin@midominio.com -> cuentadecorreodetodalavida@gmail.com
Logs e informes
Gestionar hasta 10.000 correos al mes de forma gratuita

Solo hay un pero: con la cuenta gratuita solo podemos enviar/recibir correo de/a otras cuentas que han de ser validadas previamente. Tenemos que pasarnos a una cuenta de pago y dar nuestros datos bancarios, pero hasta 10.000 correos al mes, el servicio es gratuito, no nos cobrarán ni un duro. Recomiendo registrarse con una cuenta básica, configurarlo y probarlo con algunas direcciones controladas, y si os convence, actualizar a una cuenta de pago. Vamos, lo que hice yo.

La primera en la frente

Una vez registrados en Mailgun, tendremos que configurar nuestro dominio. Desde su panel de control, vamos a Domains > Add new domain para hacerlo. Nos pedirá el nombre de nuestro dominio, y la primera recomendación es que utilicemos un subdominio para el correo del tipo mail.midominio.com y que mas tarde lo podremos configurar al gusto. Bueno, pues eso no es del todo cierto, y es una putada, porque me pasé un buen rato intentando configurarlo y no hubo forma. Si utilizamos mail.midominio.com, nuestras direcciones de correo van a ser siempre algo como pepito@mail.midominio.com, en lugar de pepito@midominio.com, que es lo que la mayoría de personas (las normales, al menos) tiende a querer configurar.

Así que nada de mail.loquesea, y al turrón. Yo lo he configurado en el dominio raíz y hasta ahora no he tenido ningún conflicto con ninguna otra cosa, claro esta, no tengo ningún otro servidor de correo en ese dominio.

Si alguien lee esto y ha conseguido configurarlo correctamente con mail.midominio.com, que deje un comentario o algo, y le pago una cerveza.

Configuración de DNS

Para configurar el dominio, tendremos que hacer algunos cambios en nuestros DNS para poder enviar correos, configurando una serie de registros que servirán básicamente para validar que el dominio es efectivamente nuestro. Para hacer esto dependeremos de nuestro proveedor de DNS y será diferente en cada caso, así que no voy a meterme ahí. Mailgun tiene un servicio que permite comprobar al momento si nuestros cambios de DNS son correctos o no.

Una configuración típica de DNS podría ser algo así, usando midominio.com como ejemplo:

midominio.com	A	xxx.xxx.xxx.xxx	Registro A básico del dominio
midominio.com	MX 10	mxa.mailgun.org	Registro de correo MX principal
midominio.com	MX 10	mxb.mailgun.org	Registro de correo MX secundario
pic._domainkey.midominio.com	TXT	k=rsa; p=XXXX	Registro TXT con info de Mailgun
midominio.com	TXT	v=spf1 include:mailgun.org ~all	Registro TXT con info de Mailgun
email.midominio.com	CNAME	mailgun.org	Registro para rastreo de los correos

Hay que tener en cuenta que los cambios de DNS tardan en propagarse, y dependiendo de los cambios que hagamos Mailgun puede tardar hasta 24 horas en comprobar el dominio.

Enviar correo: SMTP

En cuanto tengamos los DNS configurados y validados por Mailgun, ya podremos comenzar a enviar correos, pero ojo, tan solo a direcciones previamente autorizadas si tenemos la cuenta básica. Accediendo a la información de nuestro dominio en Domains, debajo de Domain information podremos ver la configuración del servidor SMTP, que siempre será el mismo: smtp.mailgun.org. Hay un enlace en Manage STMP credentials. desde donde podremos dar de alta buzones nuevos y gestionar las contraseñas. Por defecto, tendremos configurado un buzón postmaster@midominio.com, y una contraseña por defecto.

Ahora lo que podemos hacer para comenzar a enviar correo es añadir la cuenta en cualquier otro servicio de correo (ejem, Gmail):

Usuario	postmaster@midominio.com
Contraseña	La que hayamos configurado
Servidor SMTP	smtp.mailgun.org
Puerto	587
Otros	Activar opción de TLS

Recibir correos: Mailgun Routes

Para recibir correos solamente tendremos que definir una serie de rutas, ya que Mailgun va a recoger absolutamente todo el correo que llegue a nuestro dominio, y procesarlo según las rutas que configuremos. La opción mas básica es crear una ruta para recoger los mensajes de una cuenta y reenviarlos automáticamente a otra (ejem, Gmail otra vez?). Lo bueno es que podemos crear tantas rutas como necesitemos, por lo que podemos crear tantas cuentas de correo como queramos, y redirigir cada una de ellas.

Para ello vamos a la opción de Routes > Create route, usaremos los siguientes datos:

Expresion type	Match recipient	El tipo de regla
Recipient	nuevacuenta@midominio.com	Cuenta de correo que queremos configurar
Actions	cuentadestino@servidor.com	Activar la opción Forward
Description	Nuestra descripción	Algo para identificar la regla

De este modo podemos ir creando las reglas que necesitemos para todos los buzones que queramos configurar. Como veis no es necesario configurar nada en nuestro cliente de correo, ya que no se usa un servidor POP3 o IMAP, sino que simplemente Mailgun se encargará de reenviar los correos a los recipientes adecuados.

Conclusiones

Cumple perfectamente lo que esperaba de el servicio, y a coste 0 patatero. Me ahorro el tedio de configurar mi propio MTA, y además tengo un plataforma que me va a permitir jugar con el correo si lo necesito. La configuración es muy sencilla y lleva poco tiempo, y el único problema que tuve fue el tema de poner el mail.* delante del dominio.

Hay par de cosas a comentar:

A veces los correos tardan un ratito en llegar, mas de lo usual con un servicio de correo 'normal', pero llegan.
Si configuráis esto con Gmail, el muy cabrón no os va a mostrar el mensaje recibido, al enviar el correo desde la misma cuenta que lo va a recibir. Tenéis que usar una cuenta diferente para enviar y recibir.

Aparte de este par de detalles, el servicio funciona bastante bien, y tiene mucha potencia si de verdad necesitamos realizar operaciones con estos correos, ya que podemos configurar una URL para recibirlos por medio de servicio web, por ejemplo. En mi caso, para lo que yo lo quería, me va perfecto.

Ya me contaréis si lo utilizáis o no.

Referencias

Comments

Error al realizar envio

No sirvio de nada esta informacion no me dijo como debo enviarlo, no me dice cual es la diferencia entre el usuario, la contraseña, el correo, etc muchas cosas, si uso el correo con el que me registre me dice que los subdominios algo, si uso el postmaster me da el mismo error, tengo una gran cantidad de log de mensajes rechazados

Gran artículo!

Hola,
he leído este artículo y me he sentido identificado puesto que he tenido los mismos problemas / ideas que tú. Lástima no haberlo encontrado antes y haberme ahorrado algo de tiempo (sobre todo con lo del subdominio).
Muy bueno!

Añadir nuevo comentario

Servidor de Git privado con Gogs

root — Sun, 19 Feb 2017 00:45:21 +0000

Servidor de Git privado con Gogs

Domingo, Febrero 19, 2017 - 01:45

Linux

Git

Servicios

El único problema que tengo con GitHub es que en su versión gratuita todos los repos tienen que ser públicos. Si queremos tener repositorios privados tenemos que pasar por caja, y creo que son unos 7$ al mes, que me parece cojonudo, pero en mi caso necesito minimizar al máximo el coste de mis sistemas, principalmente porque no me da dinero.

Así que estuve investigando que alternativas tenia para instalar un servidor de Git privado. Lo primero que me vino a la cabeza fue GitLab, porque lo he utilizado durante una buena temporada en el trabajo con equipos relativamente grandes y nos ha dado muy buen resultado. En mi actual empresa estamos usando Bitbucket de Atlasian, y prácticamente es lo mismo que teníamos con GitLab, pero al ser de pago no es una opción para mi.

Una vez decidido a instalar GitLab, el problema está cuando te pones a mirar los requisitos:

4GB de RAM es lo recomendado.
2GB de RAM + 2GB de swap, ya te dicen que va a ir como el culo
Se necesitan varios GB de espacio en disco solo para la instalación de GitLab

Demasiada caña para mi pobre servidor, y mas si pienso servir desde la misma máquina un par de sitios o algún otro servicio, necesitaba algo mas ligero pero que al menos molase (ya que estamos...).

Así que después de dar algunas vueltas e investigar un poco, acabé encontrando Gogs:

https://gogs.io/

Según ellos mismos, Gogs es:

Gogs is a painless self-hosted Git service.

Que viene a ser un servicio de Git que te alojas tu mismo e indoloro.

Y la verdad es que no ha sido nada doloroso, llevo ya varios meses usándolo y ha sido una gran opción, y es que fue muy sencillo de instalar, viene con un montón de funcionalidades de serie, y tiene una interfaz muy pulida y que es calcada a GitHub.

Entre las funcionalidades interesantes:

Open Source
Ligero, muy ligero. Esta ocupando menos de 500Mb en disco (con las sus fuentes y las de Go) y aun no lo he visto sobrecargar la máquina.
Gravatar (venga va...)
Pull request, funcionan igual que Github
Webhooks !! (esto ya es lo mas, pero no los he probado aún)
Notificaciones por correo
Soporta SSH, tanto para servir la aplicación como para los repos
Tickets para incidencias, sencillo pero útil.
Wiki para cada proyecto
Creación de cuentas de usuario: Con registro o manual
Permite desactivar el registro de usuarios
Permite configurar repositorios privados
Webhooks, espera esto ya lo había dicho, ¿no?

Instalación

La ayuda oficial para la instalación la podéis encontrar aquí (todo en inglés):

Instalación desde fuentes: https://gogs.io/docs/installation/install_from_source
Ejecución: https://gogs.io/docs/installation/configuration_and_run
Instalación avanzada: https://gogs.io/docs/advanced/configuration_for_source_builds
Instalación desde binarios: https://gogs.io/docs/installation/install_from_binary

La instalación oficial la están haciendo con Ngnix y postgresql. Yo lo monté tirando de un viejo Apache2 y MySQL que ya tenia corriendo. Voy a hacer una traducción de la instalación que son los pasos que yo he seguido, y luego pongo mis archivos de configuración. Y ojo, que estos pasos son para instalarlo desde el fuente, que es lo que hice yo.

Lo que queremos hacer es:

Servir ‘Gogs’ desde un dominio midominio.com, por ejemplo como git.midominio.com
Apache2 como servidor web
MySQL como servidor de base de datos

Primero creamos un usuario para que corra la aplicación:

$ sudo adduser --disabled-login --gecos 'Gogs' git

Descarga e instalación de Go

Vamos a instalar Go dentro del home del usuario que acabamos de crear para no interferir con ninguna otra versión de la distribución que usemos. Usaremos

/home/git/local/go

Creamos un directorio:

$ sudo su - git
$ cd ~
$ mkdir local

Bajamos la versión disponible:

$ wget https://storage.googleapis.com/golang/go1.7.3.linux-amd64.tar.gz
$ tar -C /home/git/local -xzf go1.7.3.linux-amd64.tar.gz

Añadimos unas cuantas rutas al fichero bashrc de nuestro usuario git:

$ sudo su - git
$ cd ~
$ echo 'export GOROOT=$HOME/local/go' >> $HOME/.bashrc
$ echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc
$ echo 'export PATH=$PATH:$GOROOT/bin:$GOPATH/bin' >> $HOME/.bashrc
$ source $HOME/.bashrc

Instalar Gogs

La forma rápida de instalar Gogs parece ser esta:

$ go get -u github.com/gogits/gogs 
$ cd $GOPATH/src/github.com/gogits/gogs 
$ go build

Y una vez compilado, podemos probarlo con:

$ cd $GOPATH/src/github.com/gogits/gogs
$ ./gogs web

Configuración

La configuración por defecto está en conf/app.ini pero no vamos a editar ese fichero. En lugar de eso Gogs nos permite crear una copia que será donde pondremos nuestras modificaciones. Primero vamos a crear unos directorios:

mkdir -p $GOPATH/src/github.com/gogits/gogs/custom/conf
mkdir -p ~/gogs-repositories
sudo mkdir -p /var/log/gogs
sudo chown git:git /var/log/gogs

Hacemos una copia del fichero de configuración original, en donde haremos nuestros cambios:

cd $GOPATH/src/github.com/gogits/gogs
cp conf/app.ini custom/conf/

En teoría en nuestro fichero de configuración 'custom' solamente deberíamos tener la configuración especifica que necesitemos. Es decir, que podemos borrar todo lo que se quede por defecto. La principal razón de esto es que cuando actualicemos la versión de Gogs, nuestra configuración no se modificará, ya que tienen un .gitignore para este fichero local. Este es el fichero que yo tengo:

; Change it if you run locally
RUN_USER = git
; Either "dev", "prod" or "test", default is "dev"
RUN_MODE = prod

[repository]
ROOT                      = /home/git/gogs-repositories

[server]
PROTOCOL               = http
DOMAIN                 = git.midominio.com
ROOT_URL               = http://git.midominio.com/
HTTP_ADDR              = 0.0.0.0
HTTP_PORT              = 3000

[database]
; Either "mysql", "postgres" or "sqlite3", it's your choice
DB_TYPE  = mysql
HOST     = 127.0.0.1:3306
NAME     = gogs
USER     = gogs
PASSWD   = **CONTRASEÑA**

[admin]

[security]
INSTALL_LOCK                      = true
; !!CHANGE THIS TO KEEP YOUR USER DATA SAFE!!

#@FDEWREWR&*(
SECRET_KEY                        = *KEY*

; Auto-login remember days
LOGIN_REMEMBER_DAYS               = 7
COOKIE_USERNAME                   = gogs_awesome
COOKIE_REMEMBER_NAME              = gogs_incredible
; Reverse proxy authentication header name of user name
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER

[service]
ACTIVE_CODE_LIVE_MINUTES               = 180
RESET_PASSWD_CODE_LIVE_MINUTES         = 180
; User need to confirm e-mail for registration
REGISTER_EMAIL_CONFIRM                 = false
; Does not allow register and admin create account only
DISABLE_REGISTRATION                   = true
; User must sign in to view anything.
REQUIRE_SIGNIN_VIEW                    = false
; Mail notification
ENABLE_NOTIFY_MAIL                     = false

[log]
ROOT_PATH  = /home/git/go/src/github.com/gogits/gogs/log
; Either "console", "file", "conn", "smtp" or "database", default is "console"
; Use comma to separate multiple modes, e.g. "console, file"
MODE = file
; Buffer length of channel, keep it as it is if you don't know what it is.
BUFFER_LEN = 10000
; Either "Trace", "Debug", "Info", "Warn", "Error", "Critical", default is "Trace"
LEVEL = Info

Configurar Apache2 con Gogs

Si quereis usar Nginx en lugar de Apache, la ayuda oficial tiene la info necesaria. En Debian podemos instalar Apache2 si no lo tenemos ya:

sudo apt-get install apache2

La instalación de Gogs que acabamos de hacer corre en el puerto 3000 por defecto. Lo que queremos hacer es utilizar un servidor web como proxy para poder servir Gogs desde el puerto 80, como un subdominio de nuestro dominio, por ejemplo en este caso:

http://git.midominio.com

La mejor forma de hacer esto es crear un fichero de configuración para hacer un VirtualHost y usar mod_proxy para poder servir Gogs en el puerto 80 con Apache.

vi /etc/apache2/sites-available/080-gogs.conf

El contenido del fichero puede ser tan simple como esto:

<VirtualHost *:80>
  ServerName git.midominio.com

  ProxyPreserveHost On
  ProxyPass        / http://localhost:3000/
  ProxyPassReverse / http://localhost:3000/

  ErrorLog ${APACHE_LOG_DIR}/gogs-error.log
  CustomLog ${APACHE_LOG_DIR}/gogs-access.log combined

</VirtualHost>

El nombre del dominio que usemos aqui será el mismo que pondremos en la configuración de Gogs. Aún tenemos que activar este VirtualHost:

ln -s /etc/apache2/sites-available/080-gogs.conf /etc/apache2/sites-enabled/

Ahora activaremos el módulo mod_proxy de Apache. Podemos probar con a2enmod:

$ sudo a2enmod proxy

Esto debería crear los dos ficheros necesarios dentro de /etc/apache2/mods-enabled/ : proxy.conf y proxy.load

Reiniciar Apache y a correr. Con suerte no tendreis ningún error.

$ sudo service apache2 restart

Configurar MySQL

No voy a entrar en detalles sobre la configuración inicial de MySQL, porque eso daría para un libro entero. En principio bastará con crear una base de datos nueva y asignar todos los permisos a un usuario para Gogs:

CREATE DATABASE gogs CHARACTER SET utf8 COLLATE utf8_general_ci;
GRANT ALL PRIVILEGES ON gogs.* To 'gogs'@'localhost' IDENTIFIED BY 'password';

Lo suyo sería ahora verificar la conexión a la nueva base de datos para estar seguros de que funciona correctamente, por ejemplo, desde la linea de comandos:

mysql --user=gogs --password=password --host=localhost gogs

Ejecutar el instalador

Llegado este punto deberíamos tener todo lo necesario para arrancar el dichoso Gogs. Lo arrancamos manualmente con:

$ cd $GOPATH/src/github.com/gogits/gogs
$ ./gogs web

Si ahora usamos un navegador para acceder a la dirección que hayamos configurado en nuestro Apache, deberiamos acceder a la primera pantalla del instalador, que nos guiará por la configuración básica. En nuestro ejemplo seria:

http://git.midominio.com

Añadir Gogs a init.d

Llegados a este punto todo deberia estar funcionando, sin embargo necesitamos arrancar Gogs a mano. Lo que necesitamos es poder levantar y parar Gogs como un servicio mas de nuestra máquina, y además, que este arranque automaticamente al levantar o reiniciar el servidor.

Para esto los chavales de Gogs nos han preparado una plantilla que nos facilitará mucho las cosas (para Debian / Ubuntu). Esta aqui:

$GOPATH/src/github.com/gogits/gogs/scripts/init/debian/gogs

La copiamos al directorio de init.d:

$ sudo cp $GOPATH/src/github.com/gogits/gogs/scripts/init/debian/gogs /etc/init.d/gogs

Y ahora modificamos un par de cosas. Editaremos las dos primeras lineas:

# Required-Start:    $syslog $network
# Required-Stop:     $syslog

De esta manera

# Required-Start:    $syslog $network $local_fs apache2 mysql
# Required-Stop:     $syslog $local_fs

Y nos aseguramos de que la variable WORKINGDIR apunte al directorio correcto:

WORKINGDIR=/home/git/go/src/github.com/gogits/gogs

El script necesita permisos de ejecución, y lo añadimos a la configuración de inicio:

$ sudo chmod ug+x /etc/init.d/gogs
$ sudo update-rc.d gogs defaults 30 70

Ahora podemos probar nuestra configuración y levantar el servicio gogs:

$ sudo service gogs start

Y conectar con un navegador a la URL que hemos configurado

http://git.midominio.com

Listo, espero que disfrutéis tanto como yo montando este pollo. Ahora ya nadie podrá ver los WTF que tenéis en vuestro código.