El apareamiento de los dispositivos bluetooth

Llego a casa después de trabajar y me dispongo a tener mi momento de relax, con música variada de fondo con mi flamante y de la que estoy orgullosísima JBL Charge 4. Al reinstalar la debian de mi portátil éste fin de semana me ha tocado configurar el bluetooth, una tarea no demasiado compleja y que no requiere muchas habilidades, por no ser que sólo la hacemos una vez cada mil y nunca nos acordamos como era, así que nos perdemos en el concepto y entre haber pulsado todos los botones habidos y por haber, desistimos.

El funcionamiento de bluetooth es

1. encender ambos dispositivos
2. emparejar
3. conectar
4. reproducir/mandar señal de audio

¡Siempre pecamos por saltarnos el paso 2! así que antes para conectar dos dispositivos que no se habían emparejado antes, deben emparejarse. Si, al igual que los humanos (si lo comparamos con una óptica tradicional y reptiliana).
Según dice la tradición, para que dos personas se puedan conectar y transmitir flujo de datos (ya me entendéis…), antes deben emparejarse/aparearse. ¡Encima aquí los dispositivos pueden irse con otros!

La cuestión es que a medida que va evolucionando la tecnología bluetooth, además de la calidad de la señal, compresión, etc. vienen mejoras tan buenas como el emparejamiento con dispositivos similares para por ejemplo, ya que estamos hablando de altavoces bluetooth, conectar decenas de ellos para cubrir un área entera o el multi-emparejamiento, que permite tener conectado varios dispositivos (el comportamiento es que el último que manda señal de …

do ut des

Éste es el estandarte de una de las Asociaciones las cuales capitaneo junto a Josep Jover, Aspertic.
El término nace del mal uso del “quid pro quo” que significa un intercambio directo y comúnmente material, cadena de favores, etc., el “quid pro quo” lo veo como la base del capitalismo agresivo, cuando el “do ut des” es mas el dar para después (y ya veremos, si hay un trato justo) recibir.

Anoto de la wikipedia el siguiente fragmento

En ocasiones nos encontramos con un mal uso en castellano de quid pro quo en lugar de do ut des, como en tantas ocasiones, por influencia del inglés. Esto sucede porque en inglés la expresión quid pro quo comenzó a aplicarse por error para referirse a la reciprocidad en un trato explícito o implícito, en un intercambio de favores, o en cualquier tipo de relación social o interpersonal, especialmente en las negociaciones en las que debe haber beneficios o cesiones equivalentes por cada parte; del modo en que se usan las expresiones castellanas «toma y dame» o «toma y daca» y las expresiones inglesas what for whatgive and take y this for that, en lugar de utilizar la locución latina apropiada para este caso, do ut des («doy para que des»).

Y refiriéndose al término “do ut des”

Esta es una expresión latina que significa literalmente «doy para que des».2​ Se usaba para referirse a la reciprocidad de cualquier trato o pacto. Del mismo modo, era

Debian 10: Problema al hacer dpkg -i paquete.deb

Acabo de instalar mi primera debian con entorno gráfico con cinnamon y veo que le faltan bastantes cosillas

# apt -y install mate-terminal pluma glances mtr net-tools dnsutils

Y también que al hacer dpkg -i de algun paquete me suelta éste error:

# dpkg -i google-chrome-stable_current_amd64.deb 
dpkg: avís: no s'ha trobat «ldconfig» en el PATH o no és executable
dpkg: avís: no s'ha trobat «start-stop-daemon» en el PATH o no és executable
dpkg: s'ha produït un error: no s'han trobat 2 programes esperats al PATH, o no són executables
Nota: el PATH del root normalment ha de contenir /usr/local/sbin, /usr/sbin i /sbin

El motivo es que necesitamos definir los directorios donde se encuentran los binarios del sistema:

# echo 'export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin' /home/aspertic/.bashrc
# echo 'export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin' /root/.bashrc

Salimos de la sesión de terminal del usuario y la volvemos a iniciar y ta-dá!

Recuerdo que si un paquete no deja instalar las dependencias, tenemos que forzar la instalación manual con apt -f install

root@aspertic01:/home/aspertic/Baixades# dpkg -i teamviewer_14.5.1691_amd64.deb 
S'està seleccionant el paquet teamviewer prèviament no seleccionat.
(S'està llegint la base de dades… hi ha 173445 fitxers i directoris instal·lats actualment.)
S'està preparant per a desempaquetar teamviewer_14.5.1691_amd64.deb…
S'està desempaquetant teamviewer (14.5.1691)…
dpkg: problemes de dependències impedeixen la configuració de teamviewer:
 teamviewer depèn de libqt5gui5 (= 5.5) | qt56-teamviewer; tot i així:
  El paquet libqt5gui5 no està instal·lat.
  El paquet qt56-teamviewer no està instal·lat.

 [...]

dpkg: s'ha produït un error en processar el paquet teamviewer (--install):
 problemes de dependències - es deixa sense 

Ejemplo script de backup

Aquí os dejo uno de los scripts de backup que uso para hacer la copia de seguridad de los servidores con proxmox. Espero que os sea de ayuda :)

#!/bin/bash

## lmdb-backup (proxmox)
#### Loc: ******
#### OS: Debian 9 (container lxc)
#### Up: 2019/08/28 11:45 (Blackhold)

BACKUP_DIR="/mnt/hd_extern/backups_lmdb"
ID[0]="server1:x.x.x.x1"
ID[1]="server2:x.x.x.x2"

for INFO in "${ID[@]}"
do
    HOST=`echo ${INFO} |awk -F ':' '{print $1}'`
    IP=`echo ${INFO} |awk -F ':' '{print $2}'`
    BACKUP_DIR_SERVER="${BACKUP_DIR}/${HOST}"

    if [[ ! -e ${BACKUP_DIR_SERVER} ]]; then
        mkdir ${BACKUP_DIR_SERVER}
        mkdir ${BACKUP_DIR_SERVER}/daily
        mkdir ${BACKUP_DIR_SERVER}/monday
        mkdir ${BACKUP_DIR_SERVER}/15
        mkdir ${BACKUP_DIR_SERVER}/28
        mkdir ${BACKUP_DIR_SERVER}/lastmonth
    fi

    rsync -av --delete root@${IP}:/var/lib/vz2/dump/ ${BACKUP_DIR}/${HOST}/daily/dump/
    rsync -av --delete root@${IP}:/var/lib/vz2/template/ ${BACKUP_DIR}/${HOST}/daily/template/

    if [[ $(date +%e) -eq 28 ]]; then
        echo Backup final de mes
        rsync -av --delete ${BACKUP_DIR}/${HOST}/28/dump/ ${BACKUP_DIR}/${HOST}/lastmonth/dump/
        rsync -av --delete ${BACKUP_DIR}/${HOST}/28/template/ ${BACKUP_DIR}/${HOST}/lasthmonth/template/

        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/28/dump/
        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/28/template/
    fi

    if [[ $(date +%e) -eq 15 ]]; then
        echo Backup dia 15
        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/15/dump/
        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/15/template/
    fi

    if [[ $(date +%u) -eq 1 ]]; then
        echo Backup dilluns
        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/monday/dump/
        rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/monday/template/
    fi
done

Y lo añado en cron

root@lmdb-backup:~# vi /etc/cron.d/lmdb
# backup planets - activated on 2019-08-18 - blackhold
30 1    * * *   root    /root/scripts/backup_nodes_planet_lmdb.sh

Por supuesto, para hacer funcionar el script es necesario instalar rsync y también poner la clave pública del servidor de backups en el autorized_keys (ssh) de los servidores que queramos hacer copia de seguridad. Recomiendo fervientemente que ninguno de los servidores ni contenedores, tenga acceso directo …

GlusterFS

GlusterFS es un gestor de ficheros en red. Básicamente lo que permite es replicar unos mismos ficheros en varios servidores, para luego con los clientes de glusterfs conectar a alguno de ellos y definir otro de backup en el caso de que se caiga el primero. Con éste sistema tenemos redundancia de los datos.

La recomendación es usar 3 nodos servidores de gluster, en mi caso, ahora mismo no dispongo del tercero, y lo añadiré mas tarde.

Vamos a trabajar con 3 nodos, Node1A, Node1B y Node2A, los dos primeros serán los servidores que tendrán el disco duro que queremos compartir en red, y el último sólo va a actuar como cliente.…

proxmox 6 + ceph

Por fin otro logro mas que me había dado guerra durante muchas horas, el motivo un ceph roto al que de momento he preferido migrar los datos a otro sitio y ya con mas calma intentaremos recuperarlo (ya vendrá otro post otro día sobre éste tema).

En motivo del ceph roto he aprovechado para reinstalar la infraestructura de proxmox entera sobre proxmox6 (debian10).

Partimos de 5 nodos unidos en el cluster (pvecm add ipmaster), sólo vamos a instalar ceph en 3 de ellos.

- node1A - 172.31.0.1 (ceph)
- node1B - 172.31.0.2
- node1C - 172.31.0.3 (ceph)
- node1D - 172.31.0.4 (ceph)
- node2D - 172.31.0.8

El nodo maestro del cluster es “node1D”, y para ver que ésto no implica nada a la hora de configurar ceph y también porque romper el 1D era una cosa que no me podía permitir… vamos a empezar por “node1A”.

Para ello vamos a la interfaz web de proxmox e instalamos ceph:…

Nextcloud sobre nginx y postgreSQL + fulltextsearch + paquetes ofimáticos collabora o onlyoffice-ds sobre docker

Hoy les traigo un manual de éstos tochos o al menos para llegar hasta aquí ya que hay mucha documentación pero ninguna que lo englobe todo, así que os voy a mostrar mi experiencia y los pasos seguidos.

Primero de todo, la política ha sido de instalar cada servicio en un contenedor o máquina virtual. La instalación de nextcloud va a estar instalada sobre un contenedor lxc y los paquetes ofimáticos, que los vamos a instalar usando docker, sobre las máquinas virtuales kvm. El motivo es que docker no funciona muy bien sobre contenedores lxc.

La otra cosa que tenemos que tener en cuenta, es que para hacer funcionar los paquetes ofimáticos, vamos a usar proxys de nginx, las máquinas van a requerir que se vean correctamente entre ellas y el usuario a las maquinas. Ésto lo comento porque la idea inicial era montar todo el sistema sobre un mismo servidor compartiendo la misma IP y repartir en el host que alberga las maquinas virtuales con iptables a los puertos correspondientes. Ésto me ha dado problemas, así que la mejor opción es servicios preparados.
En éste post me hubiese gustado documentar elasticsearch para poder buscar entre los ficheros, pero aún lo tengo a medio instalar y no he conseguido aún la comunicación. Espero que en unos días pueda publicar otro post en éste mismo blog de como hacer la integración nextcloud-fulltextsearch-elasticsearch.

Así que vamos a empezar! :)

Nextcloud
Partimos de un contenedor lxc, ésto quiere decir que el procedimiento se …

Servidor ldap

ldap es un sistema de autenticación que nos puede valer para centralizar la autenticación de los usuarios. Una vez creada ésta base de datos podemos llamar a los programas que requieran autenticación contactar con ésta base de datos centralizada.

Partimos como casi siempre con una Debian recién instalada y ahí instalamos slapd que es el servicio de ldap y ldap-utils que nos va a permitir gestionar la base de datos ldap.

# apt -y install slapd ldap-utils 

Durante la instalación nos va a pedir el password para el usuario admin (cn=admin,dc=capa8,dc=net).

En algunos manuales hacen referencia a tocar los ficheros de configuración. Dicha acción no es recomendable, para ello, lo recomendable es usar browsers de ldap como jxplorer con el que entraremos mas adelante o con las herramientas que trae ldap-utils.

De momento, para verificar que el servidor está funcionando, en el mismo servidor donde hemos instalado ldap, vamos a ejecutar el comando slapcat, que nos muestra el contenido de la base de datos ldap

# slapcat

Con el siguiente comando vamos a poder ver las entradas disponibles

# ldapsearch -x -h localhost

A continuación para configurar nuestro dominio vamos a reconfigurar slapd

# dpkg-reconfigure -plow slapd 
Omit ldap configuration: NO
DNS domain name: capa8.net
Organization name: Capa8
Administrator Password: password
Database backend to use: MDB
Do you want database to be removed when slapd is purged? NO
Move old database?: YES

Creación y configuración de Usuario, Grupos y U. Organizativas en LDAP.
Ahora vamos a crear todos los objetos …

Enviar correos electrónicos por SMTP+TLS con python

Pues otra espinita que llevaba unos días clavada sacada! :)

Con uno de los programas que estoy haciendo necesitaba mandar un correo electrónico para hacer la verificación de correo electrónico y activación posterior del usuario. Me puse con ello pero los ejemplos que encontraba requería poner la configuración del correo electrónico en el código en lugar de cogerlo de la base de datos, además estaba dando problemas de autenticación con el servidor, cosa que entre que mi código estaba mal y la configuración con el servidor era errónea no se mandaban los mensajes, en el servidor salía el error feúcho:

Error: dict-client: server returned failure:

Así que para implementar ésto sólo vamos a tocar los ficheros de mi proyecto almacenado en ~/dev/ (mi entorno de desarrollo, en producción lo suelo dejar bajo /var/www/ o /var/www/html/).

en ~/dev/capa8/ es donde almaceno los settings.py y las url.py
en ~/dev/web/ es donde almaceno el código de mi programa
~/dev/ es pues donde está mi manage.py de django

Vamos a ver pues el código de urls.py almacenado en capa8, vamos a ver la página de registro de usuario y de validación del correo electrónico:

# vi capa8/urls.py
############
# /account/
# account patterns
urlpatterns += [
    ...
    path('create', views_account.create, name='create'),
    path('verify/<str:token>', views_account.verify_mail, name='verify'),
    ...
]

Ambas funciones las vamos a buscar en el fichero que está en web/views_account.py, pero primero editaremos el web/views.py que es donde voy a crear la función a la que le pasaremos la dirección donde queremos enviar el correo, el …

Servidor de ficheros NFS

Hace muchos años escribí un post con éste mismo propósito, pero es lioso y pide hacer muchas cosas, así que aquí uno mas sencillo, claro y entendedor :)

Servidor

# apt install nfs-kernel-server

Ahora en el fichero /etc/exports definimos los directorios del servidor que queremos compartir por NFS.

# vi /etc/exports
/mnt/hd_extern	192.168.1.0/24(rw,no_subtree_check,async)
/mnt/hd_extern  192.168.1.100(rw,no_subtree_check,async)

La primera línea sería para permitir el acceso a los hosts de la red 192.168.1.0/24 y la segunda sólo al host 192.168.1.100. Con ésta configuración debería valer, pero addicionalmente si la conexión es mediante una red MAN como guifi, tendremos que afinar lo de la pérdida de los paquetes. Una configuración alternativa podría ser:

# vi /etc/exports
/mnt/hd_extern	192.168.1.0/24(rw,sync,fsid=0,crossmnt,no_subtree_check,no_root_squash)
/mnt/hd_extern  192.168.1.100(rw,sync,fsid=0,crossmnt,no_subtree_check,no_root_squash)

Para recargar la configuración usaremos el comando exportfs

# exportfs -arv

La opción -a exporta todos los directorios, la opción -r eliminará las entradas antiguas, mientras que la opción -v nos mostrará el resultado de la ejecución.

Cliente
Primero instalamos el cliente nfs en el equipo

# apt install nfs-common

Creamos un punto de montaje y montamos el directorio del servidor NFS

# mkdir /mnt/hd_remot
# mount 192.168.1.3:/mnt/hd_extern /mnt/hd_remot/

Para montarlo automáticamente, añadir en /etc/fstab

# vi /etc/fstab
192.168.1.3:/mnt/hd_extern /mnt/hd_remot nfs defaults 0 0

Y listos! :)…