
git branch -m master maingit fetch origingit branch -u origin/main maingit remote set-head origin -a
git branch -m master maingit fetch origingit branch -u origin/main maingit remote set-head origin -a
Publicada:
Modificada:
Mi primer contacto con la distribución GNU/Linux (Debian) Ubuntu fue con la versión 6.10 en el año 2007.
En el año 2014 fue que formalmente comencé a realizar cursos sobre Software Libre en la Academia del Ministerio de Ciencia y Tecnología del estado Carabobo y allí me confirmaron lo que yo había aprendido por mi cuenta navegando por internet: Se deben de utilizar siempre los repositorios oficiales en línea o un repositorio espejo reconocido para las actualizaciones mayores y menores. En cuanto a las actualizaciones de seguridad, esas sí que siempre hay que recogerlas directamente de la fuente, por aquello de la rapidez y veracidad del asunto. Más que todo por la rapidez …
El asunto es que hoy 3 de noviembre de 2026 la empresa Canonical, mantenedores de Ubuntu, en una ansiedad que llevamos días en ello, se decidieron a sacar un parche de seguridad ante la CVE-2026-98432, con una peligrosidad de 9,8/10 (vamos, 98 % de peligrosidad) NO por los repositorios oficiales sino por la nueva estrategia de ciclo Kernel SRU con 2 semanas de duración.
Yo siempre estoy dispuesto a estudiar día con día👨🏽🎓, por aquello que dicen de que «se es vieja o viejo cuando se deja de aprender». Viendo (y disfrutando) la transmisión en vivo de los amigos de Tecnocrática una cosa (y es el comienzo apenas) que llamó mi atención fue lo de la mención de Fail2ban y su degradación al manejar un alto volumen de direcciones IP, ahora incluso los abusos que vienen por IPv6.
Y esto que para nada culpa nuestra, los administradores de red, sino que simplemente somos víctimas no más: Si atacan nuestros servidores de lo que sea (principalmente los servidores web con Nginx y Apache2) que pues Fail2ban hará el trabajo que le encomendamos y sumará a su lista una gran cantidad de direcciones IP que harán lento a nuestro servidor. Es por ello que me puse a investigar el tema y hoy, humildemente, retribuyo mis hallazgos.
Pues como leen, se trata de ampliar en preciado espacio en la barra de direcciones para programación con PHP:
Con esto de la vulnerabilidad crítica PHP2SHELL me percaté que el repositorio personal del señor Ondrej pues que ya se dejó de utilizar en Ubuntu 26 así que hay que retirarlo y agregar el nuevo repositorio, dejo las instrucciones para mi recordatorio (y si le es de utilidad a alguien más):
Muchas veces necesitamos nuestro propio archivo o carpeta temporal ya sea para evitar embasurar nuestro directorio de usuario o simplemente para extraer unos ficheros comprimidos y examinarlos o, mejor aún, instalar nuestras propias aplicaciones (nuestros instaladores). Para ello el comando adecuado es mktemp.
Esto es sencillo: Conviene ofrecer siempre la mínima información necesaria e incluso hay quienes la cambian a propósito (si usan Nginx pues declaran que usan Apache).
El procedimiento es fácil, editar sudo nano /etc/apache2/conf-available/security.conf .
Dentro de dicho fichero buscar (o agregar):
ServerTokens Prod .ServerSignature Off .El archivo está profusamente «documentado» con líneas de comentarios, obvio que en idioma inglés siempre.
Por último reiniciar Apache2: sudo systemctl restart apache2 .
¡ De nuevo vamos con HTTP/2 !
Por dos razones principales:
Yo utilizo GNU/Linux® Ubuntu® (derivado Debian®) y ni es tanto el tiempo que le dedico a su configuración.
Sin embargo al actualizar a Chromium 143.0.7499.146 y apagar la máquina, al día siguiente me sucedió algo muy curioso: Se negaba a mostrar mi lista de perfiles, generalmente uno por cada aplicación y/o sitio web.
Pues nada, arremangarse la camisa, revisar los respaldos hechos a ver si faltaba algo… Y nada, un buen rato investigando, al menos abría un perfil temporal y así abrí uno o dos perfiles directamente, sin el asistente de bienvenida. Pero no es la idea tener que estar recurriendo a la línea de comandos cada día para lanzar el navegador web, ese recurso es para trabajos importantes.
Por fin leyendo un artículo en «Ask Ubuntu» alguien aconsejó borrar los «Singleton*» y revisé en ~/snap/chromium/common/chromium y allí estaban:
SingletonCookie
SingletonLock
SingletonSocket
Los moví a un directorio de respaldo, ejecuté Chromium y ¡Zas! todo de nuevo a la normalidad.
Me queda, como pendiente, saber qué hace el endemoniado Singleton ese…