miércoles, 29 de septiembre de 2021

Acceder a filesystems de WSL desde Windows



Cómo solucionar el error C0070057 que impide usar Microsoft Teams en Windows".



Puede ser interesante acceder a los filesystems de WSL (Windows Subsystem for Linux) desde el explorador de Windows. Esto ya es posible en WSL v2.

Para ello, primero deberemos listar los discos duros de nuestro equipo:

C:\Users\Usuario\Documents>wmic diskdrive list brief Caption DeviceID Model Partitions Size SAMSUNG MZ7LN256HC-07 \\.\PHYSICALDRIVE0 SAMSUNG MZ7LN256HCHP-00007 3 256

Las rutas de los discos están disponibles en las columnas 'DeviceID'.
Por lo general, los discos tienen el formato \\.\\\.\PHYSICALDRIVE*.


Montar


Para montar este disco usaríamos:

wsl --mount \\.\PHYSICALDRIVE0 --partition 1

El sistema quedará montado bajo /mnt/wsl/PHYSICALDRIVE0p1/

De forma predeterminada, wsl --mount intenta montar el disco como ext4.

Desde Windows, podemos dirigirnos a \wsl$ - o en este caso a \wsl\PHYSICALDRIVE0p1 - desde el explorador de Windows y veremos las carpetas y ficheros del sistema WSL.


Desmontar


Para desmontar el disco:

wsl --umount \\.\PHYSICALDRIVE0


Fuentes:

https://devblogs.microsoft.com/commandline/access-linux-filesystems-in-windows-and-wsl-2/
0

miércoles, 22 de septiembre de 2021

AWS: script python para crear snapshots y rotarlos



script en python para crear snapshots y rotarlos en AWS.



A continuación explicaré como crear snapshots en AWS usando un script en python, que a su vez rotará los snapshots, todo ello usando AWS cli en Linux.

Crear un cron que cree snapshots cada *:

[ec2-user@ip-10-5-0-143 ~]$ echo "* * * * * aws ec2 create-snapshot --volume-id vol-0b2efa7e024e758e5 2>&1 >> /tmp/cronlog" > cronjob [ec2-user@ip-10-5-0-143 ~]$ crontab cronjob

Miramos qué snapshots existen en este momento:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-snapshots --filters "Name=volume-id,Values=vol-0b2efa7e024e758e5" { "Snapshots": [ { "Description": "", "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "pending", "VolumeSize": 8, "StartTime": "2020-06-17T10:50:02.036Z", "Progress": "99%", "OwnerId": "077455710323", "SnapshotId": "snap-0c9062daba8a9f4f7" }, { "Description": "", "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "completed", "VolumeSize": 8, "StartTime": "2020-06-17T10:45:11.200Z", "Progress": "100%", "OwnerId": "077455710323", "SnapshotId": "snap-0f2af28035ea778e5" }, { "Description": "", "Encrypted": false, "VolumeId": "vol-0b2efa7e024e758e5", "State": "completed", "VolumeSize": 8, "StartTime": "2020-06-17T10:49:02.082Z", "Progress": "100%", "OwnerId": "077455710323", "SnapshotId": "snap-0870e6eba7a6cc337" } ] }

Paramos crontab:

[ec2-user@ip-10-5-0-143 ~]$ crontab -r

Script para eliminar snapshots excepto 2:

[ec2-user@ip-10-5-0-143 ~]$ more snapshotter.py #!/usr/bin/env python import boto3 MAX_SNAPSHOTS = 2 # Number of snapshots to keep # Create the EC2 resource ec2 = boto3.resource('ec2') # Get a list of all volumes volume_iterator = ec2.volumes.all() # Create a snapshot of each volume for v in volume_iterator: v.create_snapshot() # Too many snapshots? snapshots = list(v.snapshots.all()) if len(snapshots) > MAX_SNAPSHOTS: # Delete oldest snapshots, but keep MAX_SNAPSHOTS available snap_sorted = sorted([(s.id, s.start_time, s) for s in snapshots], key=lambd a k: k[1]) for s in snap_sorted[:-MAX_SNAPSHOTS]: print "Deleting snapshot", s[0] s[2].delete()

Miramos cuantos snapshots hay:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-snapshots --filters "Name=volume-id, Values=vol-0b2efa7e024e758e5" --query 'Snapshots[*].SnapshotId' [ "snap-0c9062daba8a9f4f7", "snap-0f2af28035ea778e5", "snap-0870e6eba7a6cc337" ]

Ejecutamos el script:

[ec2-user@ip-10-5-0-143 ~]$ python snapshotter.py Deleting snapshot snap-0f2af28035ea778e5 Deleting snapshot snap-0870e6eba7a6cc337

Miramos cuantos snapshos quedan:

[ec2-user@ip-10-5-0-143 ~]$ aws ec2 describe-snapshots --filters "Name=volume-id, Values=vol-0b2efa7e024e758e5" --query 'Snapshots[*].SnapshotId' [ "snap-0c9062daba8a9f4f7", "snap-0c87c81530f2f06c3" ]
0

miércoles, 15 de septiembre de 2021

Deshabilitar SELinux en CentOS



Cómo deshabilitar SELinux en CentOS.



Primero miramos el estado actual de SELinux en el sistema:

[centos@ip-10-252-3-87 ~]$ sudo sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31

Vemos que SELinux está enabled (activo) en modo targeted.

Podemos modificar este estado para la sesión actual de targeted a permissive con el siguiente comando:

[centos@ip-10-252-3-87 ~]$ sudo setenforce 0

Comprobamos el estado actual de la política:

[centos@ip-10-250-3-87 ~]$ sudo sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31

Si queremos deshabilitar permanentemente SELinux, debemos:

1. Editar el fichero /etc/selinux/config
2. Escribir SELINUX=disabled

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted

Reiniciar el sistema con:

[centos@ip-10-252-3-87 ~]$ sudo shutdown -r now

Una vez reiniciado el equipo, comprobar el estado de SELinux con:

[centos@ip-10-252-3-87 ~]$ getenforce Disabled

SELinux ha quedado deshabilitado permanentemente.
0

miércoles, 8 de septiembre de 2021

Guardando caché en un reverse proxy nginx



Cómo configurar cache en reverse proxy nginx.



Un caché de contenido se encuentra entre un cliente y un "servidor de origen" y guarda copias de todo el contenido que este presenta. Si un cliente solicita contenido que el caché ha almacenado, este devuelve el contenido directamente sin contactar al servidor de origen. Esto mejora el rendimiento de una web ya que la caché de contenido está más cerca del cliente y utiliza los servidores de aplicaciones de manera más eficiente porque no tienen que hacer el trabajo de generar páginas desde cero cada vez.

Hay potencialmente varios cachés entre el navegador web y el servidor de aplicaciones: el caché del navegador del cliente, los cachés intermediarios, las redes de entrega de contenido (CDN) y el equilibrador de carga o el proxy inverso que se encuentra frente a los servidores de aplicaciones. El almacenamiento en caché, incluso a nivel de equilibrador de carga/proxy inverso, puede mejorar considerablemente el rendimiento.

NGINX se implementa comúnmente como un proxy inverso o un balanceador de carga en una pila de aplicaciones y tiene un conjunto completo de funciones de almacenamiento en caché. Para ello, solo se necesitan dos directivas: proxy_cache_path y proxy_cache. La directiva proxy_cache_path establece la ruta y la configuración del caché, y la directiva proxy_cache lo activa.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; proxy_pass http://my_upstream; } }

Los parámetros de la directiva proxy_cache_path definen la siguiente configuración:

- El directorio del disco local para el caché se llama /ruta/a/caché/.

- levels establece una jerarquía de directorios de dos niveles en /ruta/a/caché/. Tener una gran cantidad de archivos en un solo directorio puede ralentizar el acceso a los archivos, por lo que recomendamos una jerarquía de directorios de dos niveles para la mayoría de las implementaciones. Si el parámetro de niveles no está incluido, NGINX coloca todos los archivos en el mismo directorio.

- keys_zone configura una zona de memoria compartida para almacenar las claves de caché y los metadatos, como los temporizadores de uso. Tener una copia de las claves en la memoria permite que NGINX determine rápidamente si una solicitud es HIT o MISS sin tener que ir al disco, lo que acelera enormemente la verificación. Una zona de 1 MB puede almacenar datos de unas 8000 claves, por lo que la zona de 10 MB configurada en el ejemplo puede almacenar datos de unas 80 000 claves.

- max_size establece el límite superior del tamaño de la memoria caché (a 10 gigabytes en este ejemplo). es opcional; no especificar un valor permite que la memoria caché crezca para usar todo el espacio disponible en el disco. Cuando el tamaño de la caché alcanza el límite, un proceso llamado administrador de caché elimina los archivos que se usaron menos recientemente para que el tamaño de la caché vuelva a estar por debajo del límite.

- inactive especifica cuánto tiempo puede permanecer un elemento en la memoria caché sin que se acceda a él. En este ejemplo, el proceso del administrador de caché elimina automáticamente un archivo que no se ha solicitado durante 60 minutos, independientemente de si ha caducado o no. El valor predeterminado es 10 minutos (10 m). El contenido inactivo difiere del contenido caducado. NGINX no elimina automáticamente el contenido que ha caducado según lo definido por un encabezado de control de caché (Cache-Control:max-age=120, por ejemplo). El contenido caducado (obsoleto) se elimina solo cuando no se ha accedido a él durante el tiempo especificado por inactivo. Cuando se accede al contenido caducado, NGINX lo actualiza desde el servidor de origen y restablece el temporizador inactivo.

- NGINX primero escribe los archivos que están destinados a la memoria caché en un área de almacenamiento temporal, y la directiva use_temp_path=off le indica a NGINX que los escriba en los mismos directorios donde se almacenarán en la memoria caché. Le recomendamos que desactive este parámetro para evitar la copia innecesaria de datos entre sistemas de archivos. use_temp_path se introdujo en NGINX versión 1.7.10 y NGINX Plus R6.

- proxy_cache activa el almacenamiento en caché de todo el contenido que coincide con la URL del bloque de ubicación principal (en el ejemplo, /). También puede incluir la directiva proxy_cache en un bloque de servidor; se aplica a todos los bloques de ubicación del servidor que no tienen su propia directiva proxy_cache.

Una característica poderosa del almacenamiento en caché de contenido de NGINX es que NGINX se puede configurar para entregar contenido obsoleto de su caché cuando no puede obtener contenido nuevo de los servidores de origen. Esto puede suceder si todos los servidores de origen de un recurso en caché están inactivos o temporalmente ocupados.

Si un contenido no está disponible, en lugar de transmitir el error al cliente, NGINX entrega la versión obsoleta del archivo desde su caché. Esto proporciona un nivel adicional de tolerancia a fallas para los servidores que NGINX está representando y garantiza el tiempo de actividad en caso de fallas del servidor o picos de tráfico. Para habilitar esta funcionalidad, incluir la directiva proxy_cache_use_stale:

location / { # ... proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; }

Si NGINX recibe un error, tiempo de espera o cualquiera de los errores 5xx especificados del servidor de origen y tiene una versión obsoleta del archivo solicitado en su caché, entrega el archivo obsoleto en lugar de transmitir el error al cliente.


Fuentes:

https://www.nginx.com/blog/nginx-caching-guide/
0

miércoles, 1 de septiembre de 2021

Ampliar volumen LVM



Cómo ampliar o extender un volumen LVM en Linux.



Un volumen LVM llega al 100% de ocupación en un servidor Linux y debemos ampliarlo para que la aplicación que corre sobre él siga funcionando con normalidad.

Observemos que /dev/mapper/centos_centreon--central-var_lib_mysql está al 100%:

[root@centreon-central ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 8.9M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/centos_centreon--central-root 20G 3.5G 16G 19% / /dev/sda1 969M 282M 621M 32% /boot /dev/mapper/centos_centreon--central-var_lib_centreon 6.8G 2.6G 3.9G 40% /var/lib/centreon /dev/mapper/centos_centreon--central-var_lib_centreon--broker 4.8G 236M 4.4G 6% /var/lib/centreon-broker /dev/mapper/centos_centreon--central-var_cache_centreon_backup 4.8G 61M 4.5G 2% /var/cache/centreon/backup /dev/mapper/centos_centreon--central-var_log 9.8G 590M 8.7G 7% /var/log /dev/mapper/centos_centreon--central-var_lib_mysql 16G 15G 0 100% /var/lib/mysql tmpfs 379M 0 379M 0% /run/user/0

Añadimos 14 GB al disco de la máquina (con VMWare) y mostramos info del volumegroup:

[root@centreon-central ~]# vgdisplay --- Volume group --- VG Name centos_centreon-central System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 94 VG Access read/write VG Status resizable MAX LV 0 Cur LV 7 Open LV 7 Max PV 0 Cur PV 2 Act PV 2 VG Size <81.02 GiB PE Size 4.00 MiB Total PE 20740 Alloc PE / Size 17152 / 67.00 GiB Free PE / Size 3588 / <14.02 GiB VG UUID gNfI3W-1FLX-zcfi-ZycH-uxmZ-jlhf-439sEF

Vemos que hay 14 GB libres.

Ampliamos/extendemos el volumen que se ha quedado sin espacio:

/dev/mapper/centos_centreon--central-var_lib_mysql

[root@centreon-central ~]# lvextend /dev/mapper/centos_centreon--central-var_lib_mysql -L +14G Size of logical volume centos_centreon-central/var_lib_mysql changed from 16.00 GiB (4096 extents) to 30.00 GiB (7680 extents). Logical volume centos_centreon-central/var_lib_mysql successfully resized.

Lanzamos un df para ver cómo ha quedado el volumen:

[root@centreon-central ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 8.9M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/centos_centreon--central-root 20G 3.5G 16G 19% / /dev/sda1 969M 282M 621M 32% /boot /dev/mapper/centos_centreon--central-var_lib_centreon 6.8G 2.6G 3.9G 40% /var/lib/centreon /dev/mapper/centos_centreon--central-var_lib_centreon--broker 4.8G 236M 4.4G 6% /var/lib/centreon-broker /dev/mapper/centos_centreon--central-var_cache_centreon_backup 4.8G 61M 4.5G 2% /var/cache/centreon/backup /dev/mapper/centos_centreon--central-var_log 9.8G 590M 8.7G 7% /var/log /dev/mapper/centos_centreon--central-var_lib_mysql 16G 15G 0 100% /var/lib/mysql tmpfs 379M 0 379M 0% /run/user/0

El nuevo tamaño aun no se refleja en el volumen. Usamos resize2fs para finalizar el proceso:

[root@centreon-central ~]# resize2fs /dev/mapper/centos_centreon--central-var_lib_mysql resize2fs 1.42.9 (28-Dec-2013) Filesystem at /dev/mapper/centos_centreon--central-var_lib_mysql is mounted on /var/lib/mysql; on-line resizing required old_desc_blocks = 2, new_desc_blocks = 4 The filesystem on /dev/mapper/centos_centreon--central-var_lib_mysql is now 7864320 blocks long.

Volvemos a mirar el espacio del volumen:

[root@centreon-central ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 8.9M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/centos_centreon--central-root 20G 3.5G 16G 19% / /dev/sda1 969M 282M 621M 32% /boot /dev/mapper/centos_centreon--central-var_lib_centreon 6.8G 2.6G 3.9G 40% /var/lib/centreon /dev/mapper/centos_centreon--central-var_lib_centreon--broker 4.8G 236M 4.4G 6% /var/lib/centreon-broker /dev/mapper/centos_centreon--central-var_cache_centreon_backup 4.8G 61M 4.5G 2% /var/cache/centreon/backup /dev/mapper/centos_centreon--central-var_log 9.8G 591M 8.7G 7% /var/log /dev/mapper/centos_centreon--central-var_lib_mysql 30G 15G 14G 53% /var/lib/mysql tmpfs 379M 0 379M 0% /run/user/0

La utilidad df ya muestra el nuevo tamaño correctamente.
0