Si queremos visualizar de forma remota por SSH el tráfico que está gestionando uno de nuestros servidores podemos hacer uso de «bmon«. Suele estar disponible en la mayoría de repositorios oficiales y tiene el siguiente aspecto:
Si estamos trabajando con Libvirt y deseamos realizar una actualización de sistemas de forma prácticamente desatendida, este es un script que puede resultar cómodo:
#!/bin/bash
## Recoge el nombre de los contenedores y elimina la primera línea y la última
lxc_names=»$(virsh -d 0 -c lxc:/// list –name | tail -n +2 | head -n -1)»update_lxc_machines(){
local lxc=»$1″
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq update
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y upgrade
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y clean
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y autoclean
}for lxc_name in $lxc_names
do
update_lxc_machines «$lxc_name»
done
He tomado como referencia este otro script y lo he modificado a mis necesidades.
Si manipulando los grupos de usuarios en Windows da la casualidad de que elimináis del grupo de Administradores al único usuario al que teníais acceso prácticamente os deja fuera de su configuración. Su solución es curiosa porque nos abre un amplio abanico de posibilidades.
Arrancamos con una distro de linux que nos permita acceder al sistema de ficheros de Windows y realizamos las siguientes acciones:
Cuando estemos en la pantalla de login podremos pulsar sobre el equino de las herramientas de accesibilidad que ahora nos abrirá un terminal con permisos de administrador. En él tendremos que escribir la siguiente orden:
net localgroup Administradores /add nombreUsuario
Con lo anterior pondremos al usuario «nombreUsuario» dentro del grupo de Administradores. Pero si hemos perdido por completo nuestro usuario, lo suyo es habilitar el usuario «Administrador» y asignarle una contraseña:
net user administrador /active:yes
net user administrador *
En aquellos casos en los que sospechamos de zonas de memoria RAM que no funcionan correctamente y que se producen en equipos con funciones de servidor en los que un reinicio para utilizar Memtest86+ nos supone un problema podemos optar por «memtester».
Con el comando «free» podemos averiguar cuánta memoria tiene nuestro equipo utilizada y cuánta libre. Sabiendo esto lanzamos nuestra nueva herramienta indicándole cuánta memoria tiene que reservar para testearla y cuántas pasadas debe realizar:
memtester 20131 2
En el caso anterior le estaríamos diciendo que comprobase algo más de 19GB y que hiciese dos pasadas. En caso de que encontrase errores veríamos mensajes como el siguiente:
FAILURE: 0x7f40f12dd82264da != 0x7f40f52dd82264da at offset 0x22fa2d27.
Quizás aplique a distintas distribuciones de Linux pero en mi caso concreto me ha ocurrido con OpenSuse. El problema consiste en que no aparece por ningún lado el dispositivo de sonido asociado a la tarjeta gráfica, sólo aparece la integrada de la placa base o la integrada en el procesado si es del estilo APU.
Por tanto, si hacemos un «lspci» nunca nos va a parece la segunda línea:
07:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1)
07:00.1 Audio device: NVIDIA Corporation Device 1aef (rev a1)
Esto es debido a que, por algún motivo que desconozco, se aplican unas reglas de configuración al detectar la tarjeta gráfica que eliminan el dispositivo y no nos permite utilizarlo. Para cambiar este comportamiento sólo tenemos que editar el fichero «/usr/lib/udev/rules.d/90-nvidia-udev-pm-G05.rules» y comentar la línea que ponga lo siguiente:
ACTION==»add», SUBSYSTEM==»pci», ATTR{vendor}==»0x10de», ATTR{class}==»0x040300″, ATTR{remove}=»1″
Tras esto y un reinicio de la máquina tendremos de nuevo la capacidad de sacar sonido a través del HDMI de nuestra gráfica Nvidia. También recordar que el uso de «pavucontrol» nos permitirá pasarle a un posible AVR el sonido en DTS.
Hace unos meses moví todas las máquinas virtuales de Proxmox a Ubuntu 18.04 LTS y todo iba bien hasta que decidir actualizar a Ubuntu 20.04 LTS. Resulta que esta última versión incluye el kernel 5.4 que trae consigo una serie de modificaciones más restrictivas con respecto al acceso de zonas de memoria reservadas y que afectas a las agrupaciones IOMMU mal hechas por parte de algunas BIOS. El error que saltaba era similar al siguiente:
failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_
map(0x563169753 c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument)
Hice diversas modificaciones sobre el kernel para intentar evitar la restricción del mapeo de memoria sin ningún éxito. Probé a actualizar al kernel 5.8 de la rama de desarrollo de Ubuntu para acabar teniendo el mismo problema. La única solución era volver a Ubuntu 18.04 o directamente probar una distribución que trabajase con el kernel 5.3 que era el último que se sabía que funcionaba de forma permisiva en ese aspecto. Por tanto terminé con OpenSuse 15.2.
Todo ello me llevo a cuestionarme si el hardware (HP Gen8) que estaba intentando hacer funcionar merecía la pena tanto tiempo invertido o simplemente comprar otro equipo mejor preparado. Tras visitar numerosas webs me encontré con que la información relativa a las agrupaciones IOMMU no se ofrecen por parte de los fabricantes de placa base y que, futuras actualizaciones de la BIOS podían afectarlas. Lo que parece ser más orientativo es que las placas base más caras suelen ser mejores en ese aspecto y que para plataformas AMD hay que llevar cuidado con las actualizaciones de AGESA. Con lo que al final supone una lotería y voy a estirar el kernel 5.3 todo lo que pueda, a ver si en un futuro se publica algún método para seguir usando este hardware.
En Proxmox creo recordar que se podía limitar el % de uso de la CPU de forma individual en cada máquina virtual. Como sustituto o equivalencia me topé con un script de Stuart Hopkins que a partir de un fichero de configuración permitía ajustar con el comando «nice» la prioridad del proceso de cada una de las instancias de nuestro KVM. Jim Klimov por su parte mejoró el script para permitir definir además qué prioridad de acceso al disco tendría cada una de esas instancias, completando de esa forma la funcionalidad del script.
El fichero de configuración tendría el siguiente aspecto:
### Note: comments or config lines from here on, e.g. no empty lines!
#
# KVM VM Priorities (NAME|NICEPRIO|IOCLASS|IOPRIO)
# IOCLASS – 1=realtime, 2=best-effort, 3=idle
# IOPRIO – 0=highest, 7=lowest
#
# e.g. MYVM|15|3|7
#
521-MaquinaVirtual|10|3|7
Por un lado tendría el nombre de la máquina virtual a la que le deseo aplicar los cambios «202-MaquinaVirtual», el «nice» a aplicar sería de 10 (-20 es la prioridad más alta, 19 la menor y 0 la por defecto), la clase de acceso al disco la mantendríamos en «idle» para que dejase paso al resto de procesos y una prioridad de 7 que es la más baja. Con todo ello pretendo que la máquina virtual suponga el menor impacto sobre los discos y que tenga un consumo de CPU moderado cuando tenga que compartirla.
Dicho lo anterior, en mi caso el script no me funcionaba porque no era capaz de leer el PID de mi máquina virtual, ya que el comando «ps» lo mostraba de la siguiente forma:
qemu-system-x86_64 -enable-kvm -name guest=521-MaquinaVirtual,debug-threads=on -S -object secret,………..
Así que cambié la línea que extrae el nombre de la máquina virtual que en un origen era así:
vm_name=$(ps -o cmd -p $vm_pid 2>/dev/null | tail -n 1 | sed -e ‘s/^[^0-9a-zA-Z]*//g’ | sed -e ‘s/^.*-name\ \([a-zA-Z0-9]*\).*/\1/’ 2>/dev/null)
Por esta otra:
vm_name=$(ps -o cmd -p $vm_pid 2>/dev/null | tail -n 1 | sed -e ‘s/^[^0-9a-zA-Z]*//g’ | awk ‘{print $4}’ 2>/dev/null| awk -F’=’ ‘{print $2}’ 2>/dev/null|awk -F’,’ ‘{print $1}’ 2>/dev/null)
No sé si será igual para todo el mundo o afecta sólo a mi configuración, pero el script es sencillo de entender y editar para ajustarlo a las necesidades de cada uno.
Y, por supuesto, con tenerlo en cron para que ajuste la configuración por si hemos reiniciado alguna máquina no cuesta mucho.
Si disponemos de un dispositivo Android al cual queremos acceder por SSH para, por ejemplo, trasferir ficheros porque MTP es intratable desde Linux (al menos con KDE), podemos hacerlo a través de una aplicación llamada Termux. Esta aplicación nos habilita un terminal desde el cual podemos instalar paquetes y configurarlos de forma muy similar a como lo haríamos en cualquier distribución de Linux.
Instalaremos el servicio, averiguaremos con qué usuarios estamos accediendo al terminal, le cambiaremos la contraseña y mostraremos nuestra IP local:
pkg install openssh
whoami
passwd
ifconfig
sshd
Y con un simple comando desde nuestro ordenador conectaremos:
ssh usuario@192.168.1.123 -p8022
Si queremos tener acceso a la tarjeta microSD, tendremos que darle permisos de almacenamiento a la aplicación Termux desde los ajustes de Android. Una vez hecho eso podremos acceder en modo lectura. Para poder realizar escrituras deberemos ejecutar lo siguiente en Termux:
termux-setup-storage
Esto nos habilitará ciertas zonas de escritura dentro del móvil:
cd $HOME/storage
ls -l
Lo anterior nos devolverá algo similar a lo siguiente:
dcim -> /storage/emulated/0/DCIM
downloads -> /storage/emulated/0/Download
external-1 -> /storage/3868-4120/Android/data/com.termux/files
movies -> /storage/emulated/0/Movies
music -> /storage/emulated/0/Music
pictures -> /storage/emulated/0/Pictures
shared -> /storage/emulated/0
La carpeta «external-1» nos llegaría a la tarjeta microSD donde podríamos copiar ficheros y después moverlos con alguna aplicación de Android.
Y para dejar de utilizar nuestro servicio SSH solo tendremos que ejecutar lo siguiente:
pkill sshd
Si queremos automatizar el arranque del servicio SSH cuando abramos la aplicación, sólo tenemos que crear el fichero «~/.bashrc» con «vi» y añadir lo siguiente:
alias exit=»pkill sshd && exit»
sshd
echo «Your IP is: »
ifconfig | grep -Eo ‘inet (addr:)?([0-9]*\.){3}[0-9]*’ | grep -Eo ‘([0-9]*\.){3}[0-9]*’ | grep -v ‘127.0.0.1’
Con lo anterior tendremos el servicio en marcha y nos mostrará en pantalla la IP local que tenemos actualmente. Además incorporamos un alias al comando «exit» que terminará el servicio SSH, lo que nos da un poco de comodidad a la hora de cerrar sesiones.
En su día ya me topé con algún Windows 8.1 que se quedaba en bucle infinito sin llegar a actualizar nada, simplemente buscando. Acabé encontrando un remedio para sistemas que se han quedado bastante rezagados en cuanto actualizaciones.
El primer paso es desactivar las actualizaciones automáticas desde el Panel de Control y reiniciar el sistema, o en su lugar detener el servicios que se encarga de Windows Update.
Ejecutar el siguiente script como administrador que limpiará la cache de actualizaciones:
@ECHO OFF
echo Simple Script to Reset / Clear Windows Update
echo.
PAUSE
echo.
attrib -h -r -s %windir%\system32\catroot2
attrib -h -r -s %windir%\system32\catroot2\*.*
net stop wuauserv
net stop CryptSvc
net stop BITS
ren %windir%\system32\catroot2 catroot2.old
ren %windir%\SoftwareDistribution sold.old
ren «%ALLUSERSPROFILE%\application data\Microsoft\Network\downloader» downloader.old
net Start BITS
net start CryptSvc
net start wuauserv
echo.
echo Task completed successfully…
echo.
PAUSE
Tendremos que descargar dos actualizaciones concretas: la KB3173424 (para x86 o x64) y la KB3172614 (para x86 o x64). Puede ser que necesitemos instalar previamente la actualización de abril de 2014 Update Rollup (KB2919355) y la de abril de 2015 Servicing Stack Update (KB3021910). Después de instalar lo anterior reiniciaremos el sistema, habilitaremos de nuevo las actualizaciones automáticas y ahora nuestro sistema no debería quedar atrapado en un bucle.
En una de las máquinas virtuales tenía funcionando dos aplicaciones que hacían uso intensivo de lectura/escritura de información que tengo almacenada en una unidad NFS. Toda esa actividad acababa generando un consumo considerable de CPU y, de alguna forma, mayor actividad en los discos duros de lo que sería normal.
Opté por añadir un sistema de ficheros compartido entre el sistema anfitrión e invitado para intentar no poner por medio el servicio NFS. El sistema de ficheros sería de tipo «mapped» lo que nos llevaría a una serie de inconvenientes en cuanto a permisos en los ficheros creados pero que nos dejaría escribir sin mayores problemas:
<filesystem type=»mount» accessmode=»mapped»>
<source dir=»/mnt/unidadCompartida»/>
<target dir=»unidadCompartida»/>
<alias name=»fs0″/>
<address type=»pci» domain=»0x0000″ bus=»0x00″ slot=»0x08″ function=»0x0″/>
</filesystem>
Para montar la unidad en el sistema invitado sólo hay que añadir la siguiente línea en el fichero «/etc/fstab»:
unidadCompartida /mnt/unidadCompartida 9p trans=virtio,version=9p2000.L,cache=mmap,rw 0 0
Hay que tratar de recordar añadir las opciones de «version=9p2000.L,cache=mmap» para evitar problemas con aplicaciones como «rtorrent» cuyo log nos devolvería lo siguiente:
Could not create: memory:524288 block:1 errno:22 errmsg:Invalid argument.
Para arreglar el tema de permisos en la carpeta compartida, como desde un primer momento no tuve la previsión de hacerlo de este modo, lo arreglé con una pequeña tarea en el Cron del sistema anfitrión:
*/15 * * * * /bin/chmod 777 -R /mnt/unidadCompartida/
De este modo, cada 15 minutos, se le otorga permisos a todo el mundo sobre el contenido de dicha carpeta para que otras máquinas puedan acceder a él sin problemas. Obviamente, se tiene que saber lo qué se hace y almacena en dicha carpeta, porque un 777 abarca mucho.
Últimos Comentarios