Error Django en Seafile

martes, 25 de enero de 2022 Sin comentarios

Si nos encontramos un error similar al siguiente en los log’s de Seafile (sobretodo al intentar crear un fichero «.md»):

django.db.utils.OperationalError: no such column: base_filecomment.uuid_id

Se debe a que en la migración a la versión 7.0 la base de datos no sufrió los cambios necesarios y nos toca hacerlos a mano.

En el caso de utilizar MySQL nos bastará con hacer lo siguiente después de haber eliminado la tabla «base_filecomment»:

CREATE TABLE `base_filecomment` (

`id` int(11) NOT NULL AUTO_INCREMENT,
`author` varchar(255) NOT NULL,

`comment` longtext NOT NULL,
`created_at` datetime NOT NULL,

`updated_at` datetime NOT NULL,
`uuid_id` char(32) NOT NULL,

`detail` longtext NOT NULL,
`resolved` tinyint(1) NOT NULL,

PRIMARY KEY (`id`),
KEY `base_filecomment_uuid_id_4f9a2ca2_fk_tags_fileuuidmap_uuid` (`uuid_id`),

KEY `base_filecomment_author_8a4d7e91` (`author`),

KEY `base_filecomment_resolved_e0717eca` (`resolved`),

CONSTRAINT `base_filecomment_uuid_id_4f9a2ca2_fk_tags_fileuuidmap_uuid` FOREIGN KEY (`uuid_id`) REFERENCES `tags_fileuuidmap` (`uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Si se trata de SQLite tendremos que eliminar la tabla «base_filecomment» y recrearla con lo siguiente:

CREATE TABLE «base_filecomment» (
«id» integer NOT NULL PRIMARY KEY AUTOINCREMENT,
«author» varchar(255) NOT NULL,
«comment» text NOT NULL,
«created_at» datetime NOT NULL,
«updated_at» datetime NOT NULL,
«uuid_id» char(32) NOT NULL REFERENCES «tags_fileuuidmap» («uuid»),
«detail» text NOT NULL,
«resolved» bool NOT NULL);

Actualizando desde Opensuse Leap a Tumbleweed

sábado, 22 de enero de 2022 Sin comentarios

OpenSuse Tumbleweed es un distribución Linux de filosofía rolling-release mientras que le versión Leap es del tipo clásico. Si queremos pasar de una a otra deberemos realizar un cambio de repositorios y después actualizar desde ellos.

Primeramente realizamos una copia de seguridad de los repositorios que estamos utilizando actualmente:

mkdir /etc/zypp/repos.d/old
mv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/old

Añadimos los nuevos:

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/oss repo-oss

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/non-oss repo-non-oss

zypper ar -f -c http://download.opensuse.org/update/tumbleweed/ repo-update

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/debug repo-debug

zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-oss repo-src-oss

zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-non-oss repo-src-non-oss

Comprobaremos que todo está correcto con el comando «zypper lr -u» y luego actualizaremos con el comando «zypper dup».

Si todo ha ido bien, sólo tendremos que reiniciar el equipo para aplicar los cambios.

Categories: OpenSuse Tags:

Mostrar tráfico de red en un terminal

lunes, 3 de enero de 2022 Sin comentarios

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:

Screenshot 1

Actualizar contenedores LXC

domingo, 8 de agosto de 2021 Sin comentarios

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.

Categories: GNU/Linux, LXC Tags:

Eliminado el administrador por error en Windows

miércoles, 21 de julio de 2021 Sin comentarios

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:

  • Accedemos a la ruta «windows\system32».
  • Renombramos el fichero «utilman.exe» por «utilman.exe.bak».
  • Hacemos una copia del fichero «cmd.exe» con el nombre «utilman.exe».
  • Reiniciamos el equipo para que arranque en Windows.

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 *

Comprobar memoria RAM en caliente

sábado, 13 de marzo de 2021 2 comentarios

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.

Sin sonido por HDMI con tarjeta gráfica Nvidia en OpenSuse

miércoles, 23 de diciembre de 2020 1 comentario

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.

Qemu con su error -22 (Invalid argument)

martes, 1 de septiembre de 2020 Sin comentarios

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(0x563169753c80, 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.

Contraseña en la BIOS del portátil

miércoles, 27 de mayo de 2020 Sin comentarios

La mayoría de fabricantes de portátiles permiten asignar una contraseña de acceso a su BIOS para evitar que se efectúen cambios en su configuración. Si nos encontramos con este inconveniente vamos a descubrir que dichos fabricantes no se esforzaron mucho en tal tarea.

Cuando al acceder a la BIOS el portátil nos pregunte la contraseña introduciremos una a una las siguientes contraseñas:

  1. 3hqgo3
  2. jqw534
  3. 0qww294e

Esto hará que el portátil nos devuelva un mensaje de error en hash. Dependiendo de la marca del portátil tendrá un formato u otro:

 Fabricante  Tipo de hash  Ejemplo de hash
 Asus Fecha 01-01-2011
 Compaq 5 dígitos decimales 12345
 Dell Número de serie 1234567-595B
 Fujitsu-Siemens 5 dígitos decimales 12345
 Fujitsu-Siemens 8 dígitos hexadecimales DEADBEEF
 Fujitsu-Siemens 5×4 dígitos hexadecimales AAAA-BBBB-CCCC-DEAD-BEEF
 Fujitsu-Siemens 5×4 dígitos decimales 1234-4321-1234-4321-1234
 Fujitsu-Siemens 6×4 dígitos decimales 8F16-1234-4321-1234-4321-1234
 Hewlett-Packard 5 dígitos decimales 12345
 Hewlett-Packard/Compaq Netbooks 10 caracteres CNU1234ABC
 Insyde H20 (generic) 8 dígitos decimales 03133610
Phoenix (generic) 5 dígitos decimales 12345
Sony 4×4 dígitos hexadecimales 1234-1234-1234-1234
Sony 7 dígitos numéricos 1234567
Samsung 12 dígitos hexadecimales 07088120410C0000

Con ese hash y un script en python (en la mayoría de los casos) podremos obtener una contraseña para cuando arranque de nuevo el portátil. Y de dónde sale el script, pues normalmente de Internet como todo lo que la gente comparte.

Categories: Portátiles Tags: , ,

Cambiando prioridades de CPU e IO en KVM

jueves, 7 de mayo de 2020 Sin comentarios

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.