Entries for administración

Gitosis es básicamente una herramienta que nos permite gestionar los accesos a repositorios Git. Esto lo realiza a través de SSH, gestionando el fichero authorized_keys del usuario gitosis.

Instalación

Para su instalación, bastará con ejecutar lo siguiente:

$ sudo apt-get install git-core gitosis

dependiendo de la versión de Ubuntu/Debian disponible, el paquete que contiene Git se puede llamar git o git-core.

Una vez instalado, vamos a dar acceso al administrador. Para ello, supongamos un usuario con permisos de administración llamado user.

$ sudo -H -u gitosis gitosis-init < /home/user/.ssh/id_user.pub
Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

Ahora, desde el cliente, vamos a probar la conexión SSH:

$ ssh gitosis@miservidor.com

Si todo ha ido bien, tenemos el acceso al servidor, así que ya podemos cerrar la conexión SSH.

Añadir repositorios y usuarios

Lo primer es clonar el repositorio de administración. A través de él podremos controlar los repositorios y los usuarios de forma simple y sencilla.

$ git clone gitosis@miservidor.com:gitosis-admin.git
Cloning into gitosis-admin...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

Aquí tenemos disponibles dos elementos claves:

• gitosis.conf: Fichero de configuración
• keydir: directorio con las claves públicas de los usuarios que tienen acceso

Vamos a crear otro repositorio nuevo llamado miproyecto, para ello editamos gitosis.conf:

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = user

[group miproyecto]
writable = miproyecto
members = user member1 member2

Y añadimos las claves de los usuarios member1 y member2:

$ cd gitosis-admin
$ cp ~/member1.pub keydir/
$ cp ~/member2.pub keydir/

Ahora vamos a subir los cambios al servidor:

$ git add keydir gitosis.conf
$ git commit -m 'miproyecto con member1 y member2'
$ git push

Creando nuevos repositorios

Hasta ahora, hemos indicado a gitosis que habrá un nuevo repositorio y los usuarios que tienen acceso a él. Ahora vamos realmente a crear el repositorio. Todo esto se hace desde el lado del cliente:

$ git init miproyecto.git
Initialized empty Git repository in /home/member1/miproyecto.git/.git/
$ cd miproyecto.git/
$ git remote add origin gitosis@miservidor.com:miproyecto.git

Si tratamos de subir los cambios al servidor, nos indicará que el repositorio está vacío.

$ git push origin master
Initialized empty Git repository in /srv/gitosis/repositories/miproyecto.git/
error: src refspec master does not match any.
error: failed to push some refs to 'gitosis@miservidor.com:miproyecto.git'

Así que vamos a crear algo de contenido:

$ echo "" > README
$ git add README
$ git commit
[master (root-commit) 0dcec56] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git push origin master
Initialized empty Git repository in /srv/gitosis/repositories/miproyecto.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitosis@miservidor.com:miproyecto.git
 * [new branch]      master -> master

Y con esto todo listo :)

Acabo de terminar un script realizado en Python que comprueba actualizaciones de seguridad para Ubuntu Server y en caso de que tener instalado algún paquete, se enviará un mail a la dirección de correo indicada. Este script está pensado principalmente para administradores de sistemas, que como yo, no están dedicados a esta tarea y no disponen de mucho tiempo.

El equipo de Ubuntu utiliza un RSS para publicar las actualizaciones de seguridad, http://www.ubuntu.com/usn/rss.xml. Así que el script se conecta, parsea las entradas del RSS, selecciona los paquetes que son específicos para la versión de Ubuntu instalada, se comprueba si el paquete está instalado y se envía un mail con el listado de paquetes.

La idea es bastante sencilla. Disponemos de un sitio web en el que vamos a añadir MediaWiki en /wiki/. Así, por ejemplo, si nuestro dominio es http://www.plagaos.com/, en el cuál hay un proyecto Django en despliegue, vamos a tener http://www.plagaos.com/wiki/ sin que afecte al sitio. Además, MediaWiki hará uso de PostgreSQL.

Hoy he estado revisando los logs de mi servidor, y me he dado cuenta que llevan 5 días de ataques por fuerza bruta para intentar tener un acceso SSH. Seguro que a alguien le resulta útil este script:

import re
exp = re.compile(r'.*[\s]*sshd\[.*?\]:[\s]*Invalid user.*')
f = open('/var/log/auth.log')
for line in f.readlines():
    if exp.match(line):
        print line[:-1]

Este script nos mostrará todos los accesos fallidos que hay en el servidor. Ahora vamos a ver la forma más sencilla de impedir este tipo de ataques: fail2ban.

Este es un tema que tenía un poco descuidado (muy mal por mi parte) y que ahora acabo de solucionarlo. logrotate permite configurar de una forma sencilla cómo, cuándo y dónde queremos hacer la rotación de los logs. Esta utilidad se suele ser usada por bastante software, como: apache2, apt, aptitude, dpkg, mysql-server, postgresql-common ó rsyslog.

En este caso, voy a explicar brevemente como podemos utilizar logrotate para los logs de nuestros sitios web. Aunque bien es cierto que existe una configuración para los logs generales de Apache, yo utilizo logs independientes para cada sitio que tengo desplegado, por lo que habrá que rotar de forma independiente cada uno de ellos.

Estos días he estado configurando Postfix (si tengo tiempo ya explicaré una breve introducción de cómo echarlo a andar). Una vez montado he estado probando la configuración y autenticación vía Telnet, pero resulta un poco incómodo cuando lo tienes que hacer 4 veces. Así que aquí dejo un pequeño código para enviar un correo a través de Python.

Cuando trabajamos con un editor de textos en la terminal, en ocasiones echamos de menos un Ctrl+H para reemplazar un texto por otro. Esto es especialmente útil cuando estamos configurando un servidor remoto a través de SSH.

Para ello disponemos del comando sed (Stream EDitor), que nos permite filtrar y hacer transformaciones sobre texto.

Aprovechando la migración voy a tratar de escribir una serie de artículos acerca de algunos aspectos con los que he tenido que lidiar. Lo primero es preparar el acceso al servidor.

Cuando contratas un "Linode" (LInuxNODE, así es como llaman en Linode a los servidores que alquilan) debemos especificar una contraseña de root. Además, por defecto, el servidor SSH viene preparado para que podamos acceder.

Brevemente voy a hablar de dos aspectos importantes: el tratamiento de usuarios del sistema y la configuración del servidor SSH.

Hoy me he decidido a migrar de servidor. Voy a cambiar a Linode. ¿La razón? No me va nada mal con SliceHost, pero Linode ofrece 512MB de RAM (frente a los 256MB de SliceHost), 6GB más de disco duro y 50GB más de transferencia mensual. Además todo por el mismo precio, 20$/mes.

Actualmente este sitio está alojado en un servidor virtual que ofrece SliceHost. Por temas económicos, tengo contratado lo mínimo: 256 slice, que sólo me ofrece 256 MB de Ram. Y aquí es donde entra en juego Apache.

En algunas ocasiones es necesario, o incluso conveniente, no utilizar contraseña para conectarnos a nuestro servidor SSH. Aunque SSH es un protocolo seguro (Secure SHell), es susceptible a ataques. Veamos como podemos reforzar la seguridad a la misma vez que automatizamos procesos que requieran SSH.

Tener un servidor en producción lleva un tiempo de mantenimiento. Es necesario mantener las actualizaciones de seguirdad, revisar logs, monitorizar los recursos, ... El problema viene cuando no disponemos de demasiado tiempo. En sistemas Debian disponemos de actualizaciones desatendidas, yo concretamente utilizo Ubuntu Server.