Marca colectiva. Portosín, Porto do Son

Neste enlace (2,43 MB) deixo as transparencias da presentación “Marca colectiva” que din o día 30 de xuño de 2018 na Casa da Cultura de Portosín, en Porto do Son.

O contido é o seguinte:

  • Marca.
  • Tipos de marca.
  • Marca colectiva.
  • Implantación.
  • Exemplos de marcas colectivas.
  • Como podemos colaborar na implantación.
  • Traballos realizados.

Limit one session per user in Laravel 5

Laravel 5 does not limit the number of sessions a user may have open, so the web application may be open in several browsers of several computers.

In a project in which I am participating we need that the user can only have an active session, so if it is authenticated in a browser, the rest of sessions have to disappear, so the user can not use the web application in the other browsers, except in the last one. The example is developed with Laravel 5.4.

Continue reading “Limit one session per user in Laravel 5” →

Limitar a una sesión por usuario en Laravel 5

Laravel 5 no limita el número de sesiones que puede tener abiertas un usuario, por lo que puede tener abierta la aplicación web en varios navegadores de varios equipos.

En un proyecto en el que estoy participando necesitamos que el usuario solo pueda tener una sesión activa, con lo que si se autentifica en un navegador, el resto de sesiones tienen que desaparecer, con lo cual no podrá usar la aplicación web en el resto de navegadores, excepto en el último. El ejemplo está desarrollado con Laravel 5.4.

Continue reading “Limitar a una sesión por usuario en Laravel 5” →

Automating the management of HTTPS certificates in a Dockerized environment with Let’s Encrypt

Hi, my name is Pablo, and I am a friend of Jesús Amieiro and partner at TramitApp, an online Human Resources software that helps you better manage your employees (holidays, sickness leaves, expense reports, etc.)

We’ve been friends for a while, and every now and then we meetup to talk about “geeky stuff”.

In one of those meetings, he talked to me about Let’s Encrypt and how easy it was to set it up in a WordPress environment, so I followed his advice and set it up for free in the WordPress installations I currently manage.

Continue reading “Automating the management of HTTPS certificates in a Dockerized environment with Let’s Encrypt” →

Cómo sincronizar los archivos de dos servidores mediante rsync

En este post voy a explicar cómo sincronizar los archivos de dos servidores remotos (s1.example.com y s2.example.com) usando una conexión SSH.

Una buena alternativa para sincronizar dos servidores es Lsyncd (Live Syncing Daemon), pero como en este caso no necesito que la sincronización sea en tiempo real, lo voy a hacer mediante rsync (a través de SSH), ejecutando el comando cada hora mediante el cron del usuario.

En ambos servidores está instalado Debian 9, pero la operativa es muy similar o idéntica en el resto de distribuciones Linux.

Necesito tener instalado el siguiente software:

  • s1.example.com. Cliente SSH y rsync.
  • s2.example.com. Servidor SSH.

Lo primero que voy a hacer es configurar las claves para que un usuario de s1.example.com (u1) pueda acceder a s1.example.com (u2).

Convenciones

# – indica que el comando que viene a continuación tiene que ser ejecutado con permisos de root directamente con el usuario root o mediante el comando sudo.
$ – indica que el comando que viene a continuación puede ser ejecutado por un usuario normal sin privilegios de administración.

Generación de las claves

Ejecuto, con el usuario u1 en el servidor s1.example.com, el siguiente comando para crear las claves de acceso a s2.example.com.

u1@s1.example.com:~$ ssh-keygen -t rsa -b 4096 -C "Clave de acceso para u1 de s1.example.com a u2 en s2.example.com" -f ~/.ssh/u1s1u2s2  -q -N ""

Los parámetros del comando indican:

  • -t rsa. Tipo de clave a crear. En este caso es de tipo RSA.
  • -b 4096. Número de bits que tendrá la clave. El valor por defecto es 2048, pero cuanto más grande más robusta es la clave.
  • -C “Clave de acceso para u1 de s1.example.com a u2 en s2.example.com”. Es un campo de comentarios, donde indico el uso que le doy a la clave que estoy generando. Este comentario se añade al final de la clave pública.
  • -f ~/.ssh/u1s1u2s2. Archivo donde se almacena la clave privada. La clave pública se almacena en un archivo con el mismo nombre y con la extensión “pub”.
  • -q. Genera la clave en modo silencioso, sin mostrar nada por la consola.
  •  -N “”. Indica la contraseña (passphrase) de uso de la clave. En este caso la dejo vacía.

Copia de la clave pública al servidor remoto

Lo siguiente es copiar la clave pública al segundo servidor (s2.example.com), para poder acceder usando el usuario u2

u1@s1.example.com:~$ ssh-copy-id -i ~/.ssh/u1s1u2s2  u2@s2.example.com

The authenticity of host 's1.example.com (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:+Drsm91Tzl3wsuY1mCkBsDWd3WeJ1KloIGjUgPmgcf8.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/u1/.ssh/u1s1u2s2.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
u2@s2.example.com's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'u2@s2.example.com'"
and check to make sure that only the key(s) you wanted were added.

Los parámetros del comando indican:

  • -i ~/.ssh/u1s1u2s2. Ubicación de la clave privada. La clave pública tiene el mismo nombre y la extensión “pub”. La clave pública es la que se copia a s2.example.com
  • u2@s2.example.com. Usuario (u2) y equipo (s2.example.com) al que se copia la clave pública para poder usarla para acceder a ese equipo.

Si me conecto al servidor s2.example.com (usuario u2) por SSH en otra consola nueva y veo el contenido de su directorio “.ssh”

u2@s2.example.com:~$ ls .ssh/
authorized_keys

aparece un archivo de claves autorizadas “authorized_keys”, donde se almacenan las claves públicas que tienen acceso a este usuario de este servidor

u2@s2.example.com:~$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDWm0gRSxFyyZKDLjvc4z10iQ87rj3TlIVo9+U1D1oHbPNjiCMBpF6xOQCqKAi+f5U2tTcZ23wDh1CVnTkCFC/LWsrMiv5UVaDIXVv/1NLnRz/n1REzSL+PemdIjE0R8Ll6DUae40brCmTn1yrDZnF9qOrRm6VWKr3BQ3nvV59P3O+zWUYLrNH6vs2nIlY7Xj9ss0I9BDVwdPFv8q0+mijyeld6VYLnnJ8clDaTBZmVEwWAADfD6a0ODPf61FItON0PCcnljU408aym6U2605cYuAfu70g5gqvis1gZadc9BbUw+6E748APmSN0oVHOHU2WSyX4UQNcaZzuaZxslKh/g7isWMV1tCN0MLfp13Kgjsa84xZEhT6LG3/+iTG9gdb1qxQ4tBtx0O7TNYvQH/U4SU0lCz6PNKjVVgXBNfBz4jxvMiVqrsRzwy5QnQnfwCWEm3whqqCuOL7meyMGY77IWkguqcGrn4Mj9n/m/bQ0dY1XoLKPbCgVBPEeMaQ96hoKNy13eExhksn/K6VH2qXRiChMyuj198e5l9KFqYrf+AY+SF8MGfHNjGJSPkQYdncqppHiN7491GmeUkFl1E8y5sZPCxCKGivLBzpR/BNnKfShSN6+9f43Wx/MydgH1Zmhzi5z3H1oLAVsGG/FjxGEYm33/OMy8payOv29Azy3lw== Clave de acceso para u1 de s1.example.com a u2 en s2.example.com

Desde el servidor s1.example.com pruebo a acceder al s2.example.com mediante SSH usando la clave privada

u1@s1.example.com:~$ ssh -i ~/.ssh/u1s1u2s2 u2@s2.example.com
Linux s2.example.com 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64

Debian GNU/Linux 9 (stretch)

Linux s2.example.com 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

u2@s2.example.com:~$

Los parámetros del comando indican:

  • -i ~/.ssh/u1s1u2s2. Ubicación de la clave privada. La clave pública tiene el mismo nombre y la extensión “pub”.
  • u2@s2.example.com. Usuario (u2) y equipo (s2.example.com) al que trato de acceder usando la clave privada indicada en el parámetro anterior.

A continuación pruebo el comando de sincronización mediante rsync

u1@s1.example.com:~$ rsync -arz --no-o --no-g --progress --delete --rsh="ssh -i /home/u1/.ssh/u1s1u2s2" /home/u1/backup/ u2@s2.example.com:"/home/u2/backup"
sending incremental file list

Los parámetros del comando rsync indican:

  • -a. Procesado manteniendo los parámetros de los ficheros copiados en el equipo remoto.
  • -r. Procesado de los ficheros de forma recursiva.
  • -z. Compresión de los archivos durante la transferencia.
  •  –no-o. Ignoro el usuario (owner).
  • –no-g. Ignoro el grupo (group).
  • –progress. Muestra el progreso de la transferencia. Esta opción no la usaré en el cron, ya que no se ejecuta de forma interactiva en la consola, sino en background.
  • –delete. Borra en el destino los ficheros no existentes en el origen.
  • –rsh. Ejecuto el comando de acceso SSH con la clave privada que se pasa como parámetro (-i).
  • /home/u1/backup/. Directorio origen que quiero copiar a s2.example.com
  • u2@s2.example.com:”/home/u2/backup”. Usuario remoto (u2), servidor remoto (s2.example.com) y directorio (/home/u2/backup) donde se va a realizar la copia.

Para probarlo creo un directorio y un par de ficheros en s1.example.com

u1@s1.example.com:~$ cd ~/backup
u1@s1.example.com:~/backup$ touch archivo1.txt
u1@s1.example.com:~/backup$ mkdir directorio1
u1@s1.example.com:~/backup$ cd directorio1
u1@s1.example.com:~/backup/directorio1$ touch archivo2.txt

Vuelvo a ejecutar el comando y compruebo en s2.example.com que se ha sincronizado correctamente.

u1@s1.example.com:~$ rsync -arz --no-o --no-g --progress --delete --rsh="ssh -i /home/u1/.ssh/u1s1u2s2" /home/u1/backup/ u2@s2.example.com:"/home/u2/backup"
sending incremental file list
sending incremental file list
./
archivo1.txt
 0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=2/4)
directorio1/
directorio1/archivo2.txt
 0 100% 0.00kB/s 0:00:00 (xfr#2, to-chk=0/4)

Borro un fichero, añado otro

u1@s1.example.com:~/backup/directorio1$ rm archivo2.txt
u1@s1.example.com:~/backup/directorio1$ touch archivo3.txt

y vuelvo a ejecutar la sincronización para ver si en el equipo s2.example.com se han añadido y se han borrado los archivos de forma adecuada.

u1@s1.example.com:~$ rsync -arz --no-o --no-g --progress --delete --rsh="ssh -i /home/u1/.ssh/u1s1u2s2" /home/u1/backup/ u2@s2.example.com:"/home/u2/backup"
sending incremental file list
deleting directorio1/archivo2.txt
directorio1/
directorio1/archivo3.txt
 0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/4)

Lo siguiente es programar el rsync en el cron del usuario cada hora sin la opción “progress”, ya que no se ejecuta de forma interactiva en la consola, sino en background.

u1@s1.example.com:~$ crontab -e

Y añado la línea

00 * * * * rsync -arz --no-o --no-g --progress --delete --rsh="ssh -i /home/u1/.ssh/u1s1u2s2" /home/u1/backup/ u2@s2.example.com:"/home/u2/backup"

A partir de ahora, cada hora se sincronizará el contenido del directorio origen y del destino, borrando en el destino los archivos inexistentes en el origen.

Más información: