En versiones antiguas de Kubernetes u OpenShift no es posible redimensionar los PVC por lo que la forma de hacerlo es básicamente borrando el PVC y volviendo-lo a crear.

En la siguiente entrada hago un resumen de los pasos que tuve que dar para hacer esto mismo sobre un entorno Openshift que se ejecutaba en Azure y usaba azdisk.

Redimensionar los azdisk

Para poder redimensioanr los azdisk es necesario que no esten atachados a ninguna VM, en mi caso como los discos se atachaban a PODs solo necesité parar los PODs para que OpenShift automaticamente desatachara el azdisk del nodo.

Detener el POD para desvincular el disco.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[antonio.guillen@folio13 ~]$ oc get dc -n logging
NAME                              REVISION   DESIRED   CURRENT   TRIGGERED BY
logging-curator                   5          1         1         config
logging-es-data-master-qj25vqhi   20         1         1         
logging-es-data-master-jp36wvh    10         1         1         
logging-es-data-master-pl47qa23   10         1         1         
logging-kibana                    8          1         1         config
[antonio.guillen@folio13 ~]$ oc scale --replicas=0 dc logging-es-data-master-qj25vqhi
deploymentconfig "logging-es-data-master-qj25vqhi" scaled
[antonio.guillen@folio13 ~]$ oc scale --replicas=0 dc logging-es-data-master-jp36wvh
deploymentconfig "logging-es-data-master-jp36wvh" scaled
[antonio.guillen@folio13 ~]$ oc scale --replicas=0 dc logging-es-data-master-pl47qa23 
deploymentconfig "logging-es-data-master-pl47qa23" scaled
[antonio.guillen@folio13 ~]$ oc get dc -n logging
NAME                              REVISION   DESIRED   CURRENT   TRIGGERED BY
logging-curator                   5          1         1         config
logging-es-data-master-qj25vqhi   20         0         0         
logging-es-data-master-jp36wvh    10         0         0         
logging-es-data-master-pl47qa23   10         0         0         
logging-kibana                    8          1         1         config

Redimensionar el disco

Este paso se puede ejecutar directamente desde el portal de Azure o via CLI.

En esta entrada se verá como configurar un servidor de reenvio de correo (relay server) en postfix. El relay server actua como una pasarela STMP de correo saliente entre postfix y el resto de servidores de correos. Es importante tener en cuenta que el servidor de reenvio solo interviene en la salida de correos, no en la entrada.

A continuación se detalla el proceso para configurar un relay server en postfix, por lo que este procedimiento es válido para cualquier servidor de correos que use postfix como servidor SMTP como por ejemplo iRedmail.

Configurar postfix

Editar el archivo /etc/postfix/main.cf, ejemplo:

1
2
3
4
5
6
7

## Relay server configuration
relayhost =  [smtp-relay.server.com]:587
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_security_options = noanonymous
## End relay server configuration

A veces es necesario exponer algún servicio desplegado en una VM en la red. En VirtualBox con una red de tipo NAT la configuración del Port Forwarding se ejecuta de forma muy sencilla a través de una sencilla interfaz. Sin embargo esta taréa tan simple no puede ser ejecutada mediante una GUI en HyperV ya que no existe tal opción. Al trabajar con HyperV y NAT, la configuración del port-forwarding debe ejecutarse a través del comando netsh de Windows.

En esta entrada se verá como crear y eliminar reenvios de puertos desde la máquina local a las VM via netsh.

Una autoridad certificadora (CA) es una entidad con capacidad para firmar certificados. Para crear una CA es necesario crear el par criptográfico llave privada (ca.key) y certificado publico (ca.cert). Esta CA puede ser usada para firmar certificados de autoridades certificadores intermedias (intermediate CAs) o certificados finales de usuarios o servidores.

En esta entrada se verá como crear una CA así como crear y firmar certificados con nuestra CA. Además los certificados creados y firmados por la CA incorporarán la extensión SAN (Subject Alternative Name).

Crear la entidad certificadora (CA)

Preparar el directorio

1
2
3
4
5
6
7

DIR_CA="/root/ca"
cd $DIR_CA
mkdir certs csr crl newcerts private
chmod 700 private
touch index.txt
touch index.txt.attr
echo 1000 > serial

Preparar los archivos de configuración

Aunque hace casi un año que no trabajo con productos Atlassian, revisando mis viejas notas me tope con un par de consultas SQL que me resultaron muy útiles para ejecutar la consolidación de varias instancias de Confluence.

Una de las consultas SQL permite obtener el listado de espacios de Confluence con las columnas ID, nombre del espacio, login del propietario, nombre del propietario y email del propietario. Esta consulta es útil cuando la migración se ejecuta faseada, de forma, que es posible informar a los responsables de los espacios cuando se migrará su espacio.

La otra consulta SQL permite obtener el listado de espacios de Confluence con las columnas ID, nombre del espacio y tamaño en MB del espacio. Esta consulta es útil para estimar los tiempos de migración así como permitir fasear la migración creando paquetes de migración de tamaños similares.

Esta es una receta un pelín vieja para resolver un problema que me encontré al trabajar con Vagrant, por lo que es posible que ya este corregido en versiones actuales; aunque en su momento, en la última disponible, vagrant-1.9.5, fue la única forma de hacer funcionar rsync entre Vagrant y la VM en HyperV en Windows 8.1.

El problema surgía al sincronizar, mediante node.vm.synced_folder, una carpeta local de Windows a una carpeta de la VM desplegada con Vagrant. Concretamente me dió problemas al adaptar unos antiguos scripts para aprovisonar los nodos de un clúster Spark. Los scripts tiraban de recursos en Internet, que ya no estaban accesibles por lo que no era posible levantar el mismo entorno de desarrollo que el que estaba en producción, por lo que el paso que dí fue copiar todos los recursos a una carpeta local y modificar el vagrantfile para que tirara desde recursos locales.

La solución que encontré fue editar el archivo \plugins\synced_folders\rsync\helper.rb, en mi caso localizado en C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.9.5\plugins\synced_folders\rsync\helper.rb, y aplicar el siguiente fix:

Una solicitud de certificado (CSR) contiene la parte fundamental de un certificado SSL (CRT), y esta preparado para ser firmado por una autoridad certificadora (CA). Mediante la firma del CSR por una CA se obtiene el CRT que puede ser instalado en un servidor para cifrar el tráfico (HTTPS).

El CSR contiene una firma digital, el identificador del algoritmo de cifrado e información del certificado. Los campos que incluyen la información del certificado son:

• Common Name, es el FQDN del certificado. Ejemplo: blog.guillen.io
• Organization, nombre de la organización.
• Department, departamento que gestiona el certificado.
• City/Locality, localidad.
• State/County/Region, ciudad.
• Country, país.
• Email address, una dirección de correo de contacto.

Para generar el par clave cifrada/solicitud de certificado (key/csr) solo es necesario ejecutar openssl req -new -newkey rsa:2048 -nodes -keyout wildcard.guillen.io.key -out, ejemplo:

A continuación un procedimiento para actualizar PROXMOX cuando no dispones de una suscripción activa. He usado este procedimiento desde PROXMOX 3.0, por lo que funciona desde versiones anteriores a los ejemplos de esta entrada.

Ojo, que PROXMOX 3.4, liberado en 2015/02/19, fue la última versión con soporte para OpenVZ por lo que si estás actualizando desde una versión anterior a PROXMOX 4.0 deberás de convertir los contenedores OpenVZ a contenedores LXC, el procedimiento se resume en un backup & restore en cualquier caso PROXMOX publico la guía Convert OpenVZ to LXC.

También es importante notar que en esta actualización se actualiza el SO a Debian Stretch (9.x) desde Debian Jessie (8.x) si actualizas desde PROXMOX 4.x o desde Debian Wheezy (7.x) si actualizas desde PROXMOX 3.x.

Firewalld permite gestionar de forma dinámica las reglas de firewall, es decir, es posible implementar cambios en ejecución sin necesidad de reiniciar el servicio. Esta separación entre el entorno de ejecución y configuración permanente permite evaluar y testear las reglas sin hacer cambios permanentes en la configuración.

Firewalld sigue un diseño de dos capas:

• Capa Núcleo, es responsable de gestionar la configuración y los backends tales como iptables, iptables6, ebtables, ipset, así como la carga de módulos del kernel.
• Capa D-BUS, es la interface principal para modificar la configuración del firewall.

Tras levantar un nuevo entorno de Isso, al intentar recuperar los comentarios o publicar uno nuevo se registraba el siguiente error en los logs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Oct 22 08:25:17 blog isso-dev: 192.168.100.100 - - [2017-10-22 08:25:17] "GET /js/embed.min.js HTTP/1.1" 200 56494 0.045020
Oct 22 08:25:18 blog isso-dev: Traceback (most recent call last):
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/gevent/pywsgi.py", line 935, in handle_one_response
Oct 22 08:25:18 blog isso-dev: self.run_application()
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/gevent/pywsgi.py", line 908, in run_application
Oct 22 08:25:18 blog isso-dev: self.result = self.application(self.environ, self.start_response)
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/werkzeug/contrib/fixers.py", line 152, in __call__
Oct 22 08:25:18 blog isso-dev: return self.app(environ, start_response)
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/isso/wsgi.py", line 119, in __call__
Oct 22 08:25:18 blog isso-dev: return self.app(environ, start_response)
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/isso/wsgi.py", line 147, in __call__
Oct 22 08:25:18 blog isso-dev: add_cors_headers("200 Ok", [("Content-Type", "text/plain")])
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/isso/wsgi.py", line 144, in add_cors_headers
Oct 22 08:25:18 blog isso-dev: return start_response(status, headers.to_list(), exc_info)
Oct 22 08:25:18 blog isso-dev: File "/opt/isso/dev/lib/python2.7/site-packages/gevent/pywsgi.py", line 830, in start_response
Oct 22 08:25:18 blog isso-dev: raise UnicodeError("The status string must be a native string")
Oct 22 08:25:18 blog isso-dev: UnicodeError: The status string must be a native string
Oct 22 08:25:18 blog isso-dev: Sun Oct 22 08:25:18 2017 {'REMOTE_PORT': '44922', 'HTTP_HOST': 'dev-comment.guillen.io', 'REMOTE_ADDR': '192.168.100.21', (hidden keys: 32)} failed with UnicodeError