HOW TO
Licencia
#4sysadmins por nebul4ck
se distribuye bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.
Docker para todos. Guía docker: docker, docker-compose y docker-swarm
Buenas a todos, voy a ser claro, escribo esta entrada para darle un empujón a mi nuevo libro e-book, «Docker para todos. Guía docker: docker, docker-compose y docker-swarm«.
El libro está disponible en Amazon, tiene un precio muy asequible y con un contenido bastante completo para adentrarse en el mundo de los contenedores, algo que cualquier Administrador de Sistema debería de controlar si quiere continuar en el top del mundo de las IT.
Hoy en día, la administración de sistemas está dando un cambio de 180º. Acostumbrados (los adminsys) a administrar servidores, estamos empezando a tener que lidiar con la administración de servicios en la nube y plataformas o arquitecturas de aplicaciones desarrollada en microservicios. La tendencia actual es crear instancias, hardenizarlas con algún administrador de configuraciones (puppet, ansible…), aplicar algunas configuraciones a nivel de sistemas y agregarlas a un clúster de nodos preparados para instanciar tantos contenedores como sea posible. Por lo tanto, ahora la tarea principal será la de mantener este Swarm o cluster de nodos con servicios como Docker Swarm o Kubernetes, o incluso si estás en el cloud, lo harás a través de AKS, EKS o GKE.
En mi libro «Docker para todos», enseño como desplegar desde simples contenedores, arquitecturas completas de servicios dockerizados en tu máquina local para propósitos de desarrollo o testing, hasta desplegar enjambres (Swarm) de nodos Docker host para formar clúster ya sea con Docker Swarm Service o Docker Swam Stack. A parte de esto, el libro ofrece recomendaciones sobre buenas prácticas a tener en cuenta, herramientas a utilizar o consejos para comenzar con Docker.
Espero que os guste!.
Servidor de contraseñas
Objetivo: tener un servidor web donde almacenar de forma segura todas nuestras cuentas online de forma que centralicemos la gestión de las cuentas y podamos consultar los usuarios/password e incluso crear/modificar/eliminar cuentas desde el propio servidor, cliente de escritorio o Android/iOS app.
Requisitos:
- KeepassX o Keepass2
- Apache2
- WebDav
- Keeweb
Dispositivos/Servidores:
- PC/Desktop (cliente1)
- Smartphone (cliente2)
- Servidor Ubuntu (password server)
kdbx: base de datos de contraseñas
Instalación Keepass en un cliente de escritorio:
$ sudo apt update && apt install keepassx
$ keepassx
Base de datos > Nueva base de datos > contraseña > repite_contraseña > Aceptar
En este punto podemos o crear una contraseña fuerte o un archivo de claves. En mi caso he optado por una contraseña fuerte. Prefiero recordar una buena contraseña que andar con un archivo de llave que tendré que tener en el móvil, en el PC, en la nube y al final o lo pierdes o te lo roban, a saber…
Ahora tendremos que crear nuestras cuentas dándole la estructura jerárquica que queramos a nuestras carpetas dentro de la base de datos
Por último guardamos la base de datos como archivo .kdbx (ej: mis_cuentas_online.kdbx)
Servidor
Ya tenemos nuestra base de datos local, ahora vamos a crear un servidor web desde el que poder gestionar este archivo de forma centralizada.
Lo vamos hacer medianamente bien y medianamente seguro, es decir nuestro servidor tendrá conexiones cifradas y usuario/password para poder abrir el archivo de base de datos (además de la clave con la que va encriptada (la creada en el primer paso)).
Certificados
Para crear una PKI visita mi siguiente link donde explico brevemente como crear una PKI: CA + firma de certificados.
Importante:
- Solo necesitáis crear la CA y los certificados de servidor, los de clientes NO harán falta.
- Durante la configuración de OpenSSL se utilizan una serie de FQDN (ej vpn-00a1cc34.nebul4ck.org). Elegir aquel con el que queráis luego acceder a vuestro keeweb (ej my-keeweb.red-casa.com).
- Si no tenéis un servidor de nombres (DNS) en casa, acordaros de configurar el FQDN en el archivo /etc/hosts para traducir el nombre por la IP del servidor Apache
Apache2 + Keeweb + Webdav
Una vez contamos con los certificados necesarios, supongamos que son keeweb.local-network.com.crt, keeweb.local-network.key y que en mi Desktop (Ubuntu 18.04) tengo la siguiente entrada en el archivo /etc/hosts:
192.168.1.223 keeweb.local-network.com keeweb
vamos entonces a instalar, configurar y alojar keeweb en Apache2
Keeweb
Lo primero instalar keeweb en el servidor web:
# cd /var/www/
# mkdir -p keeweb/kdbx
# cd keeweb
# wget https://github.com/keeweb/keeweb/archive/gh-pages.zip
# unzip gh-pages.zip
# mv keeweb-gh-pages/* .
# rmdir keeweb-gh-pages
¿Os acordáis del archivo .kdbx, es decir de la base de datos que creamos con KeepassX? pues será necesario que lo copiéis (por ejemplo con el comando «scp» desde vuestro Desktop/Cliente a este servidor) en el siguiente directorio:
/var/www/keeweb/kdbx
Instalar y Configurar Apache2
# apt install apache2
# cd /etc/apache2
# mkdir cert
# cd cert <-- Copiar en este directorio los certificados generados anteriormente (tanto el .crt como el .key), certificados de servidor
## Creación de los sites HTTP/HTTPS
# cd ../sites-available
# vi 001-keeweb-http.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName keeweb.local-network.com
ServerAlias www.keeweb.local-network.com
DocumentRoot /var/www/keeweb
Redirect "/" "https://keeweb.local-network.com/"
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vi 002-keeweb-https.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName keeweb.local-network.com
ServerAlias www.keeweb.local-network.com
DocumentRoot /var/www/keeweb/
SSLEngine on
SSLCertificateFile "/etc/apache2/cert/keeweb.local-network.com.crt"
SSLCertificateKeyFile "/etc/apache2/cert/keeweb.local-network.com.key"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
<Directory /var/www/keeweb>
Options -Indexes
DirectoryIndex index.html
AllowOverride None
</Directory>
ErrorLog ${APACHE_LOG_DIR}/keeweb-https-error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
</IfModule>
## Configuración Webdav para compartir el archivo kdbx
# cd ../conf-available/
# vi webdav-kdbx.conf
RewriteEngine on
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ blank.html [R=200,L,E=HTTP_ORIGIN:%{HTTP:ORIGIN}]
<Directory "/var/www/keeweb/kdbx">
AuthType "Basic"
AuthName "Password Manager"
AuthBasicProvider file
AuthUserFile "/etc/apache2/.htpasswd-webdav-kdbx"
Require valid-user
DAV On
Options Indexes
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "origin, content-type, cache-control, accept, authorization, if-match, destination, overwrite"
Header always set Access-Control-Expose-Headers "ETag"
Header always set Access-Control-Allow-Methods "GET, HEAD, POST, PUT, OPTIONS, MOVE, DELETE, COPY, LOCK, UNLOCK"
Header always set Access-Control-Allow-Credentials "true"
</Directory>
## Crear usuario de acceso al directorio kdbx
# chmod -R www-data:www-data /var/www/
# cd /etc/apache2
# htpasswd -c .htpasswd-webdav-kdbx kdbxadmin
Enter a New password: ************
## Activar los sites
# a2dissite 000-default.conf
# a2ensite 001-keeweb-http
# a2ensite 002-keeweb-https
# a2enconf webdav-kdbx
## Activar los módulos necesarios
# a2enmod ssl
# a2enmod dav
# a2enmod dav_fs
# a2enmod rewrite
# a2enmod headers
## Reiniciar Apache
# systemctl restart apache2
Abrir la Base de datos
Ahora ya podemos acceder vía web a nuestro keeweb y configurar el acceso Webdav, recordar el fqdn que registramos en nuestro certificado y con el que accederemos al servicio (keeweb.local-network.com) y el usuario y contraseña que hemos creado con el comando htpasswd.
Una vez que accedáis os pedirá la clave maestra de la base de datos, la escribimos y accederemos a las cuentas.
PKI: certificados autofirmados, self-signed certificates
Crear Autoridad Certificadora (Public Key Infrastructure)
Nota: en mi caso mi PKI se encuentra en un servidor local sin acceso a Internet. Una vez generados los certificados, los muevo donde sean necesarios.
$ ssh user@ubuntu-server
$ sudo su -
# cd ~; mkdir pki; cd pki
# openssl genrsa -out CA.key 4096
# chmod 400 CA.key
# openssl req -x509 -new -nodes -key CA.key -sha256 -days 7300 -out CA.crt
ES
Seville
Seville
Nebul4ck Org.
Nebul4ck Security Dept
Nebul4ck CA
nebul4ck@no-existe.org
# chmod 444 CA.crt
# openssl x509 -noout -text -in CA.crt
Recordar que este certificado «CA.crt» es el que deberéis de importar en vuestro navegador Web para que autorice de forma correcta las conexiones con los servidores a los que vayáis a añadir un certificado firmado por esta CA.
Certificados de Servidor
Editar y añadir al siguiente archivo aquello que sea necesario para que las secciones/argumentos queden como veremos a continuación. Además vamos a suponer que accederemos a nuestro servidor apache con alguno de los siguientes fqdn:
# cd /etc/ssl/
# cp openssl.cnf openssl-ok.cnf
# vi openssl-ok.cnf
...
[req]
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = vpn-00a1cc34.nebul4ck.org
DNS.2 = vpn-00b1cc35.nebul4ck.org
DNS.3 = vpn-gwtransit-1110aa.backup
DNS.4 = vpnClient
[ CA_default ]
copy_extensions = copy
Los alt_names (por si no os habéis dado cuenta) son los FQDN o nombres completo los cuales nuestro certificado reconocerá cuando accedamos al servidor por www (en Apache2 = ServerName).
# openssl genrsa -out vpn.key 2048
# openssl req -new -key vpn.key -out vpn.csr
ES
Seville
Seville
Nebul4ck Org.
Nebul4ck Security Dept
vpn-00a1cc34.nebul4ck.org
nebul4ck@no-existe.org
[]
[]
El CNAME debe de coincidir con el nombre del servidor (con el que accedemos vía web)
# openssl x509 -req -in vpn.csr -CA CA.crt -CAkey CA.key \
-CAcreateserial -out vpn.crt -days 7300 -sha256 -extensions \
v3_req -extfile /etc/ssl/openssl-ok.cnf
Certificado de usuario para autenticación Web
# openssl req -newkey rsa:2048 -keyout vpnClient.key -out vpnClient.csr -nodes -days 7300 -subj "/CN=vpnClient"
# openssl x509 -req -in vpnClient.csr -CA CA.crt -CAkey CA.key \
-out vpnClient.crt -set_serial 01 -days 7300 -extensions \
v3_req -extfile /etc/ssl/openssl-ok.cnf
# openssl pkcs12 -export -clcerts -in vpnClient.crt -inkey vpnClient.key -out vpnClient.p12
Enter Export Password: ************
Verifying - Enter Export Password: ************
Ahora ya puedes importar este p12 en tu navegador y autenticarte contra tu servidor web de forma segura.
Advance Format Disk: sector 4k
Advance Format Disk
Sector 512 bytes
Hasta el año 2009 las compañías fabricantes de discos duros aplicaban sobre los discos un diseño de sector físico de 512 bytes. Esto significa que a nivel lógico el disco era particionado en pequeños fragmentos llamados bloques lógicos (sector físico) de 512 bytes en los que se almacenaba la información una vez debidamente fragmentada a nivel lógico. Antes, cuando los archivos o información con la que trabajaba el computador eran de menor tamaño, quizás este sistema funcionase eficientemente, el problema llegó cuando los bloques de información que se leían o escribían al disco eran muy superiores a 512 bytes.
Diseño sector 512 bytes
Un sector se divide de la siguiente forma:
- Gap: espacio que separa un sector de otro
- Sync: indica el inicio de sector y la alineación del sector
- Marca de dirección: contiene el estado del sector y sus datos identificativos (número y ubicación)
- Datos: donde residen los datos
- ECC: contiene los códigos de corrección de errores utilizados para reparar y recuperar los datos dañados durante el proceso de lectura y escritura.
Desventajas del sector de 512 bytes
A medida que las densidades de los discos han ido aumentado, la proporción de sectores como porcentaje del almacenamiento total se ha vuelto ínfimo e ineficiente.
Algunas de las principales desventajas del sector de 512 bytes:
- Ineficientes en sistemas que trabajan continuamente con bloques mayores de 512 bytes
- Mayor número de sectores implica mas espacio de disco invertido en ECC
- Mayor probabilidad de error y ejecución de tareas de recuperación de datos
- Disminución de la capacidad de almacenamiento en discos de mayor densidad
Sector 4K o de formato avanzado (Advance Format Disk)
En Diciembre del año 2009 se nombró y aprobó el nombre de «sector de formato avanzado» para los sectores de 4KB.
A partir del año 2011 los fabricantes de discos comenzaron en su mayoría a aplicar este nuevo estándar, aumentando la eficiencia, las capacidades de almacenamiento mediante la reducción del espacio utilizado para ECC, y mejorando la corrección de errores.
El sector 4K combina ocho sectores antiguos de 512 bytes.
El estándar de formato avanzado utiliza el mismo número de bytes por sección Gap, Sync y Marca de dirección, pero aumenta el campo ECC al 100 bytes, algo que mejora considerablemente la eficiencia de tareas de corrección de errores, además de minimizar el riesgo de reproducción.
Impacto en el OS
En muchos de los aspectos a nivel de firmware y software relacionados con el sistema operativo, se sigue asumiendo que los sectores son de 512 bytes. Con el tiempo, tendrá lugar la implementación total de sectores 4k nativos. Mientras tanto, y durante esta transición, los fabricantes de unidades de disco duro implementan los sectores de 4k mediante una técnica denominada emulación de sectores de 512 bytes. Este término alude al proceso de conversión de los sectores físicos de 4 Kb utilizados en el formato avanzado, a los sectores antiguos de 512 bytes que esperan los sistemas informáticos. Esto puede conllevar a consecuencias negativas en el rendimiento, concretamente cuando la escritura de datos no se corresponde sencillamente con los ochos sectores antiguos convertidos, es decir, cuando no existe una perfecta alineación entre el sector 4k y los ocho bloques lógicos de 512 bytes.
Esto se debe a que la unidad de disco duro debe realizar pasos mecánicos adicionales, que se traducen en:
- La lectura de un sector de 4 Kb
- La modificación de contenidos
- Reescritura de los datos
Este proceso se denomina ciclo de lectura-modificación-escritura, y resulta no deseado por su impacto negativo en el rendimiento de la unidad de disco duro.
Prevención contra los ciclos de lectura-modificación-escritura:
- Solicitudes de escritura que están desalineadas debido a la desalineación de la partición lógica con respecto a la física.
- Solicitudes de escritura con un tamaño inferior a 4 Kb.
Logical Block Addressing
El modo en que los sistemas operativos y las unidades de disco duro se comunican la ubicación de los sectores, tiene que ver principalmente con LBA (Logical Block Addressing).
A cada sector de 512 bytes se le asigna un LBA único, desde cero hasta el número necesario según el tamaño del disco. Cuando el OS solicita la escritura de datos, se devuelve una dirección LBA al final de la escritura que con la que se indica la ubicación de los mismos. Al pedir un bloque de 4k, existen ocho posibilidades distintas correspondientes a los ocho bloques de 512 bytes.
Cuando se alinea el LBA con el primer bloque de 512 bytes virtual en el sector físico de 4 Kb, la situación de alineación lógico-física para la emulación de 512 bytes se denomina alineación 0. Las situaciones de alineación 0 funcionan muy bien con los nuevos sectores de 4 Kb en el estándar de formato avanzado. Esto se debe a que una unidad de disco duro puede asignar fácilmente ocho sectores de 512 bytes contiguos en un único sector de 4 Kb.
Cuando se crean particiones en la unidad de disco duro que producen una situación sin alinear, como se muestra en la siguiente figura, el resultado es que se crean ciclos de lectura-modificación-escritura que pueden mermar el rendimiento de la unidad de disco duro.
En el caso de la imagen anterior, se trata de un tipo de alineación 1.
Conclusiones
- Para el firmware, sistema operativo y todas las utilidades, el disco parece tener sectores de 512 bytes, aunque el tamaño de sector físico subyacente es 4.096 bytes
- El uso de sectores físicos más grandes tiene implicaciones directas en el diseño del disco y el rendimiento del sistema
- Cuanto mayor es el tamaño del sector, mas eficientes y potentes algoritmos de corrección de errores puede ser utilizados.
- En teoría redimensionar o contar con sectores de mayor tamaño ofrece mayor fiabilidad y capacidad de almacenamiento
- La mayoría de los sistemas de archivos modernos utilizan estructuras de datos de 4.096 bytes o superior
- En conjunto, las ventajas de una eficiencia de formato mejorada y una corrección de errores más sólida hacen que la transición a los sectores de 4 Kb merezca la pena
En la práctica…
Si cuentas con un disco indebidamente alineado, algo que se puede comprobar con el comando fdisk o parted, quizás te interese el siguiente link
Referencias:
ubuntu 18 dns not working
¿Problemas con los DNS en Ubuntu 18.04 Bionic?
EDITADO: mejor opción es utilizar NETPLAN el nuevo configurador de networking de Debian y derivados. Es fácil usar y configurar. +info
Con la nueva resolución de nombres añadida en la versión 18 de Ubuntu se han dado varios problemas con aplicaciones de terceros como por ejemplo al montar tu propio DNS server (BIND9 o dnsmasc) o con otras herramientas como por ejemplo VPN o Cloud-init para servidores aprovisionados en el cloud..
La cuestión es que ahora el archivo /etc/resolv.conf es administrado de forma nativa por systemd-resolved y no por resolvconf . Se ha intentado dar compatibilidad con «antiguas herramientas Linux» (lo que dicen ellos…) y básicamente la han cagado (por supuesto hasta futuros parches y/o versiones). No voy a entrar en largas explicaciones porque para el que las quiera, puede empezar a leer sobre los modos de funcionamiento de este nuevo demonio (resolved man pages), luego seguir con NetworkManager el cual tiene mucho que decir aquí también, y si aún te quedan ganas puedes ver algunos de los intentos por resolver parte de este problema en:
- https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu/907249#907249
- https://wiki.archlinux.org/index.php/Systemd-resolved#Automatically
- https://stackoverflow.com/questions/51784208/stop-network-manager-from-updating-resolv-conf
- https://unix.stackexchange.com/questions/323459/how-to-make-networkmanager-add-a-dns-server-at-the-top-of-etc-resolv-conf
- https://www.linode.com/community/questions/17081/dns-stops-resolving-on-ubuntu-1804
y un largo etcétera…
Al final lo mejor es meterse en como cada demonio realiza su trabajo y volver a una configuración compatible con el «antes y el ahora».
Básicamente el archivo /etc/resolv.conf es administrado de forma manual (propio de antaño y de sysadmins) o por un demonio externo (systemd-resolved, resolvconf o openresolv) que a la vez este puede tener «dependencias de» por ejemplo NetworkManager. Bien pues para poner fin a nuestros males y que:
- El dhcp de la red modifique el archivo /etc/resolv.conf con los DNS de nuestro ISP/router
- Programas como VPN también puedan gestionar este archivo (recordar, openvpn trabaja con resolvconf y si tenemos configurado el sistema con systemd-resolved, tendremos o DNS de ISP, de VPN o en algunos casos ninguno de los dos :D)
- cloud-init para servidores desplegados en el Cloud
Solución
- Deshabilitar y parar el maldito systemd-resolved (hasta que den solución…):
systemctl disable systemd-resolved
systemctl stop systemd-resolved- Eliminar el archivo /etc/resolv.conf:
rm /etc/resolv.conf- Configurar correctamente NetworkManager:
vi /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
#default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections.
dns=default
#resolvconf: NetworkManager will run resolvconf to update the DNS configuration.
rc-manager=resolvconf
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no- Instalar resolvconf:
apt update && apt install resolvconf- Habilitar e iniciar el demonio:
systemctl enable resolvconf && systemctl start resolvconf- Crear enlace directo a /etc/resolv.conf:
ln -s /run/resolvconf/resolv.conf /etc/resolv.confUna vez reiniciado, al hacer un cat del archivo resolv.conf deberá de aparecer los DNS de vuestro ISP o LAN (antes 127.0.0.53). Cuando instaléis un servicio que necesite nuevos DNS como un cliente VPN este, será capaz de añadir nuevos servidores.
Listo!!
Servidor DNS dnsmasq con CNAMES
Configurar un servidor DNS con dnsmasq es relativamente sencillo pero con frecuencia si no se siguen ciertas pautas, fácilmente va a funcionar de forma errónea y difícilmente te vas a dar cuenta antes de que vengan a darte un toque/aviso de que algo no marcha bien.
Uso de memoria RAM
En BigData y aplicaciones «On Streaming» se está dando mucha importancia al uso de memoria RAM, ya que podemos encontrar servidores con hasta 244GB de memoria para tan solo mantener un servicio activo. En esta entrada veremos como el sistema hace uso de la RAM de manera que puedas calcular de forma mas exacta los recursos necesarios.
Integrar Nagios/Centreon con chat Slack
Si bien existen diferentes formas de recibir las alertas del monitorizador Nagios o Centreon; correo electrónico, mensaje de texto, IRC, etc… en esta entrada veremos como hacer que Slack (uno de los chats libres mas utilizados a nivel empresarial) nos notifique de aquello que ocurre en nuestra infraestructura.
Migrar MySQL a PostgreSQL
Si tienes ciertas BBDD en MySQL/MariaDB y necesitas migrar los datos (bbdd/tablas) a un servidor postgreSQL aquí te explicamos una sencilla y rápida forma de hacerlo.
#4sysadmins 