Sí nos topamos con este error.

Sep 23 10:40:30 localhost mariadbd[471]: 2022-09-23 10:40:30 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
Sep 23 10:40:30 localhost mariadbd[471]: 2022-09-23 10:40:30 0 [Note] InnoDB: Starting shutdown...
Sep 23 10:40:31 localhost mariadbd[471]: 2022-09-23 10:40:31 0 [ERROR] Plugin 'InnoDB' init function returned error.
Sep 23 10:40:31 localhost mariadbd[471]: 2022-09-23 10:40:31 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Sep 23 10:40:31 localhost mariadbd[471]: 2022-09-23 10:40:31 0 [Note] Plugin 'FEEDBACK' is disabled.
Sep 23 10:40:31 localhost mariadbd[471]: 2022-09-23 10:40:31 0 [ERROR] Unknown/unsupported storage engine: InnoDB
Sep 23 10:40:31 localhost mariadbd[471]: 2022-09-23 10:40:31 0 [ERROR] Aborting
Sep 23 10:40:33 localhost systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Sep 23 10:40:33 localhost systemd[1]: mariadb.service: Failed with result 'exit-code'.
Sep 23 10:40:33 localhost systemd[1]: mariadb.service: Consumed 3.454s CPU time.

Lo vamos a solucionar de la forma más sencilla.

rm /var/lib/mysql/ib_logfile0

Reiniciamos el servicio y listo.

Pues si nos disponemos actualizar nuestro repo y derepente nos encontramos con este mensajito:

$ N: Repository 'http://ftp.fr.debian.org/debian bullseye InRelease' changed its 'Version' value from '11.3' to '11.4'
$ N: Repository 'http://ftp.es.debian.org/debian bullseye InRelease' changed its 'Version' value from '11.3' to '11.4'
$ N: Repository 'http://ftp.de.debian.org/debian bullseye InRelease' changed its 'Version' value from '11.3' to '11.4'

Lo que debemos hacer para solunarlo es lo siguiente.

Tengo un post hablando de Wireguard (el cual no he publicado porqué no he tenido tiempo de terminar) pero tengo en beta la puesta en marcha del WireGuard, ya que me parece la mejor opción para migrar de OpenVPN sin irme a Firewall fisico ya sea forti o cualquiera del estilo.

Pues bien el problema es que tanto uno de mis compañeros como yo tenemos la sana salud mental de no usar Windows en nuestras máquinas y llevamos usando una buena temporada WireGuard sin problema, otro de mis compañero también y de unos días para acá me dice que le falla, que no le enruta la IP con el consiguiente problema... Después de estar dando muchas vuelta y por fin poder sentarme en su máquina a revisar la razón es que en las últimas versiones de Windows 10 Pro han realizado algún cambio y evita que añada las rutas correspondientes, así que se lo arreglamos de la sigueinte manera.

 Para hoy traemos una receta despúes de algunos meses parados, de nada novedoso pero útil para correr Zabbix 6 en Docker para facilitarnos un poco algunas cosas, de gestión y administración de dispositivos...

En la propia web de zabbix tenemos como hacerlo y el enalce es, este. Además dejaré mis ejemplos. Para mi es un viejo conocido al igual que Nagios, pero está vez me volví a decantar por Zabbix no por nada especial si no que ta tenía los agents configurado de una instalación anterior, que deje de usar porqué la máquina murio no por otra cosa y desde entonces tenía pendiente volver añadir algo que me ayudará a gestionar y controlar los equipos.

Desde la Oficina de Seguridad del Internauta advierten de que han aumentado las llamadas fraudulentas en las que un supuesto técnico de Microsoft informa a los usuarios de que uno de sus dispositivos se ha visto infectado. 

Hace unas semanas ya os informábamos del fraude conocido como vishing, que consiste en la llamada de un ciberdelincuente haciéndose pasar por técnico de Microsoft y advirtiendo de un virus en uno de los dispositivos de la víctima con la intención de hacerse con el control del aparato y estafar al usuario.

Este tipo de llamadas se han multiplicado en las últimas semanas y,  generalmente, se indica al usuario que uno de sus dispositivos ha sido infectado y que para solucionarlo deberá seguir los pasos que le indica, así como instalarse una aplicación externa para proceder a la desinfección.

Debemos editar el /usr/src/linux/.config y comentar los siguiente

# CONFIG_TRUSTED_KEY
# CONFIG_SYSTEM_TRUSTED_KEYRING
# CONFIG_SYSTEM_TRUSTED_KEYS=""

Y ya podemos volver a procesar el make; make modules; make modules_install

Un saludo

Para usuarios con servidores CentOS or CloudLinux 7 o superior, podremos comprobar.