SSL Reverse proxy con Apache

Un ejemplo que sirve para Meteor:


SSLProxyEngine On
# snake oil certs in proxyied service -> skip checks
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests Off
ProxyPreserveHost On

ProxyPass /websocket ws://localhost:3000/websocket
ProxyPassMatch ^/sockjs/(.*)/websocket ws://localhost:3000/sockjs/$1/websocket

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
ProxyPassReverseCookiePath / /
ProxyPassReverseCookieDomain 127.0.0.1 52.211.154.50
RequestHeader set X-Forwarded-Proto "https"

Parece que en nginx la configuración análoga es trivial. Quizá sea un buen argumento para convertirse…

Secure cookies over reverse proxy with https

Discos virtuales en Xen Server

Con el comando vhd-util podemos obtener un listado de los VDI/VHD de un Storage Repository (SR) de Xen Server:

vhd-util scan -f -a -c -m “VHD-*” -l nombre_VG

(el nombre del vg de Xen lo podemos averiguar con vgs. Normalmente empieza con VG_XenStorage)

vhd-util scan muestra una jerarquía de VHD, con su tamaño virtual y real. Esto es útil para hacer un seguimiento de los snapshots. Cada VHD es un volumen lógico en el VG, con lo cual a partir del identificador de VHD podemos obtener información adicional (por ejemplo, cuando se creó) buscándolo en la salida del comando lvdisplay

Para averiguar a qué VM corresponde un VDI…

xe vbd-list vdi-uuid=UUID

(el UUID es el que aparece en vhd-util scan, pero sin VHD-)

Otro comando para obtener información sobre los VDI es

xe vdi-list

Para empezar es cómodo, pero sólo muestra el tamaño virtual del disco.

Lista de instantáneas:

xe snapshot-list

Desde el interfaz de Xen Server es fácil eliminar un snapshot. Generalmente, en el interfaz desaparece al instante, pero en función de las dependencias en la cadena de snapshots puede tardar un rato en eliminarse del almacenamiento (cada vez que se elimina un snapshot, por detrás se lleva a cabo un “online coalescencing”). Se puede hacer un seguimiento más detallado del proceso en el log de Xen Server /var/log/SMlog

Repartir espacio disco NVME entre Windows y Linux

Arrancar Linux desde pendrive (por ejemplo, Ubuntu live)

Gparted. Reducir tamaño partición Windows. Mover comienzo partición Linux (para aprovechar el espacio liberado). Al cambiar el sector de inicio de la partición de sistema de Linux, puede ser que Grub no sea capaz de arrancar Linux. Con lo cual lo más simple es volver a reinstalar grub.

En Gparted podemos ver los nombres de dispositivo del disco nvme. Normalmente, el disco se denomina nvme0n1, y las particiones nvme0n1p1, p2…

Reinstalar Grub:

Montar sistema de ficheros raíz de Linux en /mnt/os
bind-mount sistemas de ficheros dev, proc, sys en /mnt/os
chroot /mnt/os
mount /boot/efi
grub-install /dev/nvme0n1

OpenGL en remoto (ssh) y Nvidia

Para el rendering OpenGL en un ordenador remoto se recurre (por defecto) a “indirect rendering” (los comandos Open GL pasan por el protocolo GLX). El “direct rendering” permite acceder directamente a la GPU del ordenador donde se ejecuta la aplicación. Este es el modo que usa por defecto el controlador nativo de Nvidia, que de hecho por defecto rechaza el uso del “indirect rendering” (se puede rehabilitar con la opción “AllowIndirectGLX” de la sección “ServerFlags” de xorg.con).

Así pues, ejecutando la instalación por defecto del driver nativo de Nvidia, se sustituye la biblioteca del sistema libGL. Con lo cual, se pierde el “indirect rendering” y las aplicaciones OpenGL dejan de funcionar en remoto (X11 sobre SSH)

Por otro lado, la biblioteca libGL que Nvidia instala puede ser necesaria para otras aplicaciones (por ejemplo, CUDA)

Una posibilidad es rescatar la biblioteca libGL original (del paquete libgl1-mesa-glx, o equivalente) y recurrir a ella para uso remoto, anteponiendo LD_PRELOAD=/ruta/a/libGLoriginal.so al programa a utilizar.

Si MESA recurre a swrast_dri.so para hacer el rendering (render por software), es probable que haya conflictos con bibliotecas como libstdc++.so.6 o libgcc_s.so (como suele suceder con UCSF Chimera, que tiene sus propias copias de esas bibliotecas en su directorio lib). En este caso se puede usar el mismo “truco” de LD_PRELOAD, pero con esas bibliotecas:

LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so:/usr/lib/x86_64-linux-gnu/libstdc++.so.6 chimera