Nuestro primer script «importar_usuario.py» tiene como misión importar los ficheros CSV que el administrador suba a la carpeta Clientes_CSV de nuestra intranet. Los pasos que sigue en script son:
Crea el usuario en NextCloud
Manda un email a dicho usuario notificándole su usuario y contraseña aleatoria que el usuario puede/debe cambiar en el primer acceso.
Crea la estructura de carpetas en la zona de usuario.
Formato del fichero
El fichero de clientes con extensión csv debe tener la siguiente estructura:
Abonado;Razón social Cliente;Email empresa 1000;Pepe;[email protected]
El primero (1000) es el código que recibirá el cliente en nuestra plataforma. Puede ser numérico o alfanumérico. En cualquier caso dicho código será la primera cadena del nombre del fichero de facturas a repartir.
En nuestro ejemplo, las facturas para el usuario 1000 deben empezar por 1000_loquesea.pdf.
Los demás campos se explican por sí mismos.
Cron
Nuestro script se debe programar con la frecuencia estimada por el administrador de la plataforma atendiendo a sus necesidades. Esto es, si la necesidad de crear clientes nuevos no fuera mucha no tiene sentido establecer la programación con demasiada frecuencia.
En el caso de Hostens, el panel de control nos ofrece un asistente para los trabajos de cron como se muestra a continuación:
Fichero de creación de usuarios programado cada 5 minutos
Nuestra Intranet parte de una instalación de Nextcloud con varios retoques.
Cualquier proveedor de internet tiene en su panel cpanel/plesk una forma de instalar Nextcloud muy sencilla. En nuestro caso el hosting de pruebas está en https://www.hostens.com que para las pruebas iniciales está bien.
En su amplio repertorio de aplicaciones está Nextcloud:
Parte del repertorio de aplicaciones de Hostens
La instalación no nos llevará mas que unos cuantos clics. De esta forma ya tenemos nuestro Nextcloud instalado:
Nextcloud instalado en el panel de Hostens
Una vez instalado necesitaremos acceder a él y crear el usuario y la contraseña que será el administrador de nuestra intranet. En este momento tenemos Nextcloud instalado pero todavía nos quedan unos ajustes para adaptarlo a nuestras necesidades de Intranet.
Ponerlo en castellano y habilitar nuestro dominio.
Tenemos que modificar/añadir un par de claves que se encuentran en el archivo config/config.ini del directorio de nuestra instalación.
Hostens nos provee en el panel de control de un administrador de ficheros con el que podemos hacer los cambios:
Acceso a config.php
Aquí retocaremos el apartado dominio y el lenguaje:
En el array ponemos los dominios desde los que llamaremos a nextcloudPara que todo aparezca en castellano
2. Estructura de carpetas para los usuarios
También hay que preparar el /core/skeleton para que al crear el usuario nos aseguremos que la estructura es correcta.
Cada usuario tendrá la carpeta Factura en su home.
3. Cron
Nextcloud recomienda en su instalación que se programe una tarea de cron en el sistema que lo albergue para su correcto funcionamiento. Aunque existen varias posibilidades, lo mejor, cron.
Seleccionamos cron en los ajustes del administrador.
Hostens nos provee también de una interfaz muy amigable para establecer la tarea de cron de Nextcloud cada 5 minutos.
Acceso a Cron en el panel de HostensTarea de cron creada con el asistente
4. Configuración de nuestro correo saliente.
Necesitaremos una cuenta de email que será el remitente de cuantos correos mandemos a los clientes. Se ha de configurar en los ajustes del administrador de NextCloud (Ajustes básicos):
Configuración de correo saliente
5. Configurar las aplicaciones instaladas.
Por defecto, Nextcloud incluye muchas aplicaciones instaladas que en nuestro caso no son necesarias.
En el panel de control del administrador debemos dejar exclusivamente las aplicaciones que se describen en la siguiente captura:
Aplicaciones instaladas en nuestra intranet
Todas las demás aplicaciones no aportan para nuestro caso. Las dejaremos deshabilitadas.
6. Estructura del usuario administrador.
El usuario administrador debe tener una configuración de carpetas como la que se describe en la siguiente imagen:
Estructura de las carpeta en la zona de administración
Clientes_CSV : Contendrá los ficheros csv con los clientes que nuestros scripts crearán en NextCloud en un formato que se verá mas adelante.
Plantillas_Email: Nuestros scripts pueden mandar correos con un formato preestablecido o bien leer los ficheros html de esta carpeta para mandar emails personalizados.
Reparto_Facturas: El administrador subirá a esta carpeta los ficheros de facturas con formato pdf que nuestros scripts repartirán a los clientes que les correspondan.
scripts: Contiene los scripts python del programa.
Hace un tiempo desarrollé unos scripts en Python para cubrir una necesidad que puede surgir en una empresa pequeña con pocos recursos como es la de dotar a sus propios clientes de un espacio donde éstos puedan consultar sus facturas y descargarlas.
Los scripts que funcionarán prácticamente en cualquier hosting o máquina dedicada efectuarán las siguientes acciones:
Creación de usuarios importando un script csv sencillo. Se mandará al usuario un email con los datos para el primer acceso incluyendo una clave aleatoria.
Reparto de las facturas en pdf que la empresa subirá a su zona de administración con el formato id_factura.pdf. El sistema notificará al usuario por email de nuevas facturas en su zona de usuario.
Las ventajas de este sistema son muchas:
Aprovechar la infraestructura que crea una software open source como es Nextcloud: seguridad de los datos y simplicidad de manejo.
Los documentos sensibles como son las facturas «no viajan» al correo electrónico del usuario, sino que es el cliente final el que accede a sus facturas.
Aislamiento. Aunque Nextcloud es una plataforma en la que se fomenta el intercambio de información entre usuarios también se puede adaptar para que los usuarios estén aislados de los otros.
A través de un fichero de configuración de texto, el administrador puede adaptar distintos parámetros de su hosting como son los distintos paths o la configuración de su correo saliente.
Los scripts en Python serán publicados en Github para que se puedan adaptar a otras necesidades si así se requiere.
A través de una serie de próximos artículos iré explicando desde la configuración inicial de Nextcloud hasta la configuración de los scripts y su programación en cron.
De muchos es sabido que Pihone se está convirtiendo en un elemento imprescindible en toda red que pretenda estar mas protegida de trackers, anuncios intensivos, etc.
En este post pretendo añadir la configuración básica para que Pihole en el Docker de Synology funcione adecuadamente. Los pasos principales son:
Descarga de la última versión de Pihole desde el menú «Registro» de Docker.
Por motivos que se me escapan al entendimiento en este momento, la nueva versión Debian Jessie para la Raspberry pi (versión de marzo 2017) viene con el servicio ssh deshabilitado.
Esto impide que se pueda controlar la raspberry desde consola a través de ssh y obliga a configurarla la primera vez con un monitor y teclado.
Salvando este inconveniente, la solución es sencilla. Simplemente tenemos que teclear lo siguiente:
En la entrada anterior expliqué como instalar kali en una Raspberry Pi3.
No sé porqué pero a la hora de que el usuario root hiciera autologin tuve alguna dificultad: no conseguí hacerlo. Por ello, hago esta entrada ahora donde explico cómo acceder por VNC a un sistema linux funcionando con systemd.
Configuramos ahora el servidor añadiendo una contraseña de acceso y opcionalmente otra contraseña para el modo de solo visualización.
/usr/bin/tightvncserver
2. Añadiendo TightVNCServer al sistema de inicio systemd
Para que Tightvnc arranque automáticamente necesitamos crear un fichero de arranque que estará almacenado en /etc/systemd/system/ y terminará con el sufijo «.service«. Yo lo llamaré tightvncserver.service. Debe ser creado con el usuario root.
A menudo tenemos la necesidad de conectar a un servidor ssh, a través de consola, de putty, etc.
La mayor parte de las veces tenemos que habilitar el NAT del servidor ssh y pelear con los routers para conseguirlo. Una vez salvada la configuración del NAT (router) tenemos que volver a pelear con el posible cortafuegos.
Para evitar estos problemas viene a nuestro rescate el ssh reverso. ¿Qué pasaría si el servidor destino nos mandara a nosotros (clientes de él) una conexión a nuestro equipo? De esta forma nosotros como clientes recibiríamos la conexión del servidor. Con esto evitamos tener que abrir puertos y configurar el cortafuegos porque es el servidor el que nos manda la conexión a nosotros (a nuestro equipo).
Con la replicación de MySQL podremos tener varios servidores en sincronía, si bien MySQL tiene opciones como MySQL cluster puede que en algunos casos sea demasiado para nuestras necesidades y con una replicación sea suficiente. MySQL no soporta replicación bidireccional, unicamente unidireccional, destinada a tener un maestro y muchos esclavos, pensado para hacer todas las escrituras en el maestro y todas las lecturas en los esclavos y en el maestro.
Esta idea surge a partir de que en aplicaciones de web dinamica normalmente se leen datos más veces de las que se modifica (pero no siempre tiene porque ser así). Aunque MySQL no soporte la replicación bidireccional podemos lograr el mismo efecto haciendo dos unidireccionales, el servidor A sera maestro de B y B esclavo de A, y también B sera maestro de A y A esclavo de B.
Para poder hacer esto modificaremos los autoincreementales para evitar problemas de concurrencia. Empecemos haciendo la replicación del servidor A al servidor B. El escenario:
Servidor 1: 192.168.1.11
Servidor 2: 192.168.1.12
Base de datos (presente en ambos servidores): web
Usuario MySQL (lo crearemos para la replicación): replicacion
Clave MySQL: BFp7yv1wjqTxg5TLKha0
Un punto importante a tener en cuenta es que la clave que le asignemos al usuario destinado a la replicación no sea mayor de 32 caracteres, en las claves de acceso podemos usar la longitud que deseemos pero la replicación con claves superiores a 32 caracteres pueden darnos fallos de conectividad en la actual versión de MySQL (5.5 cuando se escribió esto). Además, el usuario lo limitaremos a que solo pueda conectarse desde la IP del esclavo.
Muy probablemente el usuario root creado en la instalación del mysql habrá que darlo de alta en la sección usuarios del mysql con el parámetro % para que sea capaz de entrar a configurar el servidor de MySQL desde cualquier IP de red.
