Protege tu .git

Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.

El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una “feliz transición”. El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.

¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?

Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:

        <Directory /directorio.de.la.web/.git>
		Options FollowSymLinks
		AllowOverride All
		Require all denied
	</Directory>

Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.

Y con esto y un bizcocho… Podemos empezar nuestra semana.

Año nuevo, consola vieja

Bueno, en realidad no es una “consola” son muuuchas consolas en una. Ya os conté anteriormente como había construido mi mini máquina aracade.Esta vez, viendo que se habían vuelto a poner de moda las versiones “mini” de las consolas retro (que, por cierto, estoy intentando coleccionar) decidí construirme la mía… No sería mucho más barato, pero si que tendría el control de todo lo que metería en la misma. Este es el resultado:

Estuve tentado de imprimir también la carcasa en 3D con mi impresora.. Pero sabía que el resultado iba a ser peor y quería algo que fuese, como mínimo, familiar. La consola es capaz de ejecutar juegos de NES, SNES, Megadrive, Master system, PSX, Neo Geo, Game Boy, GBA, Game Gear y Arcades… Además, he incluido que se puedan ejecutar programas del CPC 464 y de C64 y VIC-20… Vamos, todo lo que puede dar de si una Raspberry Pi 3.

Así que aquí os dejo la lista de “ingredientes” para que los vayáis preparando:

También se puede hacer con una SD de 8Gb, pero entonces podrás meter menos juegos. El resto de lo necesario supongo que ya lo tenéis (cable HDMI,cargador y cable de móvil microusb)

Cuando las tengáis continuamos… No quiero que nos precipitemos… Así tenemos proyecto para el año nuevo.

Por cierto… ¡Feliz 2018!

Usando google drive desde Ubuntu

Una de las cosas a los que los linuxeros estamos acostumbrados es a que las grandes empresas nos “ninguneen” constantemente y oferten servicios multiplataforma solo para windows y mac, aunque el esfuerzo de haberlos hecho para linux pueda ser mínimo. Uno de estos productos, y que uso mucho ya que tengo cuenta de empresa desde hace más de 10 años es google drive.

 

Si accedemos a la página web para descargarnos el software de google, este nos indica que no hay cliente para nuestro sistema “todavía”, y lleva diciendo esto desde hace más de cinco años, sin embargo el acceso mediante la API es realmente sencillo (yo lo uso en NoMorePass por ejemplo desde una app para móvil), por eso me extrañaba mucho esta carencia.

Pero, como siempre, la comunidad de software libre viene al rescate y ya hay algunos que han desarrollado el cliente que necesitamos. Esta es la receta para instalarlo:

sudo add-apt-repository ppa:alessandro-strada/ppa
sudo apt-get update
sudo apt-get install google-drive-ocamlfuse

Una vez instalado, hay que crear el directorio donde queremos que se sincronice (por ej. ~/google-drive) y ejecutar (como usuario):

google-drive-ocamlfuse

Esto nos abrirá una ventana en el navegador para autorizar a la aplicación y darle acceso a tu cuenta, si todo va bien terminará apareciendo esta pantalla:

Y el proceso terminará con un “Access token retrieved correctly”. A partir de este momento ya puedes montar la unidad con el comando:

google-drive-ocamlfuse ~/google-drive

Para desmontar el directorio basta con escribir:

fusermount -u ~/google-drive

Y eso es todo, yo lo he hecho y aparentemente funciona, ahora queda ver si es operativo o no…

¿Porqué el ciberataque no me importa?

Como diría Pablo Iglesias en el congreso refiriéndose a Rajoy, el “ciberataque” de estos días no me importa lo más mínimo, me trae sin cuidado o, al final, me la bufa.

¿Porqué me la bufa?

Primero, porque ese “ataque” no me afecta en lo más mínimo. Se basa en un factor de infección exclusivo de windows, utilizando una vulnerabilidad conocida hace pocos meses (excepto para la CIA) y que, por tanto, no afecta a los ordenadores Linux con los que trabajo. Así, ante la alarma causada por todos los medios de comunicación y el principio del apocalipsis cibernético augurado, yo me senté tranquilamente a ver el espectáculo.

Segundo, porque hago backups regularmente de TODO ya que no te puedes fiar de nada en esta vida y de un disco duro menos. Aunque algún muñón de colaborador le diese por venir infectado de casa con un windows y se conectase a mi red los daños que podría causar serían mínimos.

Tercero, porque no es nada nuevo, ni nada que no hayamos vivido antes. Todavía recuerdo los famosos ataques por messenger, donde toda la oficina en la que trabajaba empezó a ver como sus ordenadores empezaban a mandar infecciones a sus contactos mientras les impedía seguir trabajando. O aquella vez que cada vez que instalaba windows a mi hermana y lo conectaba a internet no pasaban ni dos minutos hasta que el virus se instalaba de nuevo y me reiniciaba el ordenador (el famoso sasser).

Y, por último, porque ahora que guardo casi todo en la nube y mis passwords están seguras en mi móvil con nomorepass, nada de esto me ha quitado ni un solo minuto de mi tiempo. ¿No hay posibilidades de infecciones en Linux? Si, claro que si, pero si un sistema operativo se ha hecho para gente sin conocimiento (como windows), lo más normal es que gente sin conocimiento lo use (y caiga más fácilmente en trampas) y eso arrastre a muchos otros que tienen que cargar con las deficiencias de un sistema que solo puede parchear un equipo determinado en un país determinado. Los usuarios de Linux suelen estar más informados y las soluciones pueden llegar de cualquier parte del mundo en cualquier momento.

Instalar un servidor de correo con docker

Hace tiempo que vengo mirando la tecnología de contenedores con interés, la verdad es que desde hace mucho tiempo el trabajo más ingrato, después de haber terminado un desarrollo, era configurar el servidor donde se iba a ejecutar finalmente. No basta con saber el sistema operativo, necesitas instalar una miriada de dependecias y de versiones de software que no siempre se encuentra en la versión que usaste para el desarrollo. Docker promete poder replicar entornos completos mediante una virtualización parcial y eso me parece muy, muy interesante.

Aunque no entraré al análisis profundo de cómo funciona docker, por el momento, si que veremos un ejemplo práctico de una tarea muy habitual como administrador de sistemas, configurar un servidor de correo con todos los servicios habituales. Para ello vamos a utilizar una máquina virtual (no sirve cualquiera, hay sistemas de virtualización que no se llevan bien con docker, en mi caso usé un VPS de OVH después de desechar otros dos de strato y webserver4you). Nuestra máquina virtual tiene un ubuntu 14.04… Al lío.

Lo primero que hay que hacer es instalar docker. Por suerte esto es bastante sencillo:

sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates
sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual
sudo apt-get install docker-engine

Con esto ya tendremos docker en la máquina. Podemos probarlo:

sudo service docker start
sudo docker run hello-world

Si no queremos andar usando sudo para cada comando, añadiremos nuestro usuario al grupo de docker:

sudo groupadd docker
sudo usermod -aG docker $USER

Ahora usaremos Poste.io como contenedor de nuestro servidor de correo. Es una solución simplemente completa y muy sencilla de instalar y configurar. En nuestro caso lo único que hay que hacer para ponerlo a funcionar es crear un directorio (en mi caso /home/mail/data) y ejecutar lo siguiente:

docker run \
-p 25:25 \
-p 81:80 \
-p 110:110 \
-p 143:143 \
-p 8443:443 \
-p 465:465 \
-p 587:587 \
-p 993:993 \
-p 995:995 \
-v /etc/localtime:/etc/localtime:ro \
-v /home/mail/data:/data \
-e "HTTPS=OFF" \
--name "mailserver" \
--restart=always \
-t analogic/poste.io

Lo más relevante en este caso es que NO queremos las redirecciones https porque vamos a configurar el servidor apache que ya tenemos para que actúe de proxy y será él quien tenga el https y los certificados y que el puerto que exponemos para la administración es el puerto 81 (redirigido al puerto 80 del contenedor).

Para que sea accesible desde el exterior por https lo que hicimos fue configurar un virtualhost en apache de esta manera:

<VirtualHost *:80>
        ServerName mail.midominio.es
        AssignUserId mailuser mailuser

        ServerAdmin info@midominio.es
        DocumentRoot /home/mailuser/www

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

        <Directory /home/mailuser/www>
                Options Indexes FollowSymLinks
                AllowOverride All
                Require all granted
        </Directory>

ProxyPass / http://localhost:81/

RewriteEngine on
RewriteCond %{SERVER_NAME} =mail.midominio.es
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>

La configuración del https es similar, aunque yo dejé que el certbot de let’s encrypt me lo configurase automáticamente al generar los certificados, quedó una cosa como esta:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName mail.midominio.es
        AssignUserId mailuser mailuser

        ServerAdmin info@midominio.es
        DocumentRoot /home/mailuser/www

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

        <Directory /home/mailuser/www>
                Options Indexes FollowSymLinks
                AllowOverride All
                Require all granted
        </Directory>

ProxyPass / http://localhost:81/

SSLCertificateFile /etc/letsencrypt/live/mail.midominio.es/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.midominio.es/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mail.midominio.es/chain.pem
</VirtualHost>
</IfModule>

Si todo ha ido bien (seguro que algún detalle se nos pasa), tendremos el contenedor funcionando y podremos acceder al administrador de esta manera:

https://mail.midominio.es/admin/

Y, después de verificar la identidad y hacer los primeros ajustes de dominio, cuentas y demás podremos disfrutar de nuestro servidor de correo…