Moodle, Jailkit y php-fpm

 Revisar:

• php.ini: date.timezone = America/Lima
• /usr/share/zoneinfo/America/Lima debe estar dentro de chroot
• Usar "127.0.0.1" como db host en config.php en lugar de "localhost"
  (el socket no está disponible dentro de chroot)

Problemas con Grub2

Un simple reinicio luego de una actualización de kernel y el servidor no arrancaba.

Ejemplo de comandos a usar desde grub:

ls (hd2,2)/ es lo mismo que ls (hd2,msdos2)/ o ls (hd2,gpt2)/

Se debe buscar en cuál unidad está /boot con archivos vmlinuz-* e initramfs-*

set root=(hd0,1)
linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
initrd /boot/initrd.img-3.13.0-29-generic
boot

/dev/sda1 debe corresponder a la unidad que aloja a la raíz. En el caso de discos ssd puede ser algo como /dev/nvme0n1p2, lo mejor es revisar /etc/fstab, por ejemplo (estando en grub): cat (hd2,2)/etc/fstab

Al reiniciar el sistema podría quedarse en modo de mantenimiento. Se debe corregir el problema de grub2 y hacer permanentes los cambios. Lo primero es ver una lista de kernels disponibles:

cat /etc/grub2.cfg | grep ^menuentry

La lista de kernels se cuenta desde 0. El primero de la lista es el 0. Es importante porque se debe elegir cuál se usará:

grub2-set-default 0

Luego:

grub2-mkconfig -o /boot/grub2/grub.cfg

Y finalmente:

grub2-install /dev/sda

Ojo que no es /dev/sda1 porque no se refiere a una partición, sino a una unidad entera.
En el caso de una partición /dev/nvme0n1p2, el nombre de la unidad sería /dev/nvme0n1

reboot al final de todo.

Referencias:

• https://www.linux.com/training-tutorials/how-rescue-non-booting-grub-2-linux/
• https://www.thegeekdiary.com/centos-rhel-7-change-default-kernel-boot-with-old-kernel/

Cuando los programas que usan la librería ncurses, se ven mal

Tratando de usar ncdu (una excelente herramienta para averiguar de qué está lleno el disco), me encuentro con que su interface se ve mal, por caracteres gráficos incorrectamente mostrados.

Este problema ocurre en CentOS 7 con cualquier programa que use la librería ncurses y la solución consiste en crear un archivo /etc/profile.d/ncurses.sh que contenga:

export NCURSES_NO_UTF8_ACS=1

En el siguiente inicio de sesión, la aplicación ya será mostrada correctamente.

Actualizar de PHP 5.3 a PHP 5.4 usando CentOS y Virtualmin para poder usar Moodle 2.7 o posteriores.

Hace poco tuve que actualizar Moodle a 2.8+ y utilice el repo de Remi tal como dicen en otros posts que se encuentran al googlear.

El problema es que al final, los sites no cargaban, sólo páginas en blanco.

Encontré este link:
http://reviews.myhken.com/upgrading-php-from-5-3-x-to-5-4-x-or-5-5-x-on-centos-6-5-with-virtualmin/

Y aunque funciona bien parcialmente, el problema es que los sites corriendo como php_mod ya no funcionaban.

Lo resolví así:

Renombré /etc/httpd/conf.d/php.conf como php.conf.no tal como decían en el link.
Pero en su lugar copié php.conf de otro servidor que aún tenía php 5.3:

#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#

  LoadModule php5_module modules/libphp5.so

  LoadModule php5_module modules/libphp5-zts.so
#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddHandler php5-script .php
AddType text/html .php
#
# Add index.php to the list of files that will be served as directory
# indexes.
#
DirectoryIndex index.php
#
# Uncomment the following line to allow PHP to pretty-print .phps
# files as PHP source code:
#
#AddType application/x-httpd-php-source .phps

Y nada más, ya no modifiqué /etc/httpd/conf/httpd.conf para quitar las líneas que empezaran por php_ (ni reemplazándolas por #php_).

Aparentemente todo el problema es causado por las líneas SetHandler del nuevo archivo php.conf.

Con esta configuración, funciona PHP 5.4 con cualquiera de los tres modos: mod_php, cgi o fcgi.

De todos modos, la instalación de Moodle la tuve que hacer con el modo CGI:

https://moodle.org/mod/forum/discuss.php?d=221196

Tener un televisor full-hd y no poder elegir la resolución correcta desde Windows

¿Te ha pasado que tienes una pantalla full-hd pero al conectarla a tu laptop con un cable VGA sólo puedes elegir hasta 1366x768 o alguna otra resolución inferior? ¿O te pasa que la imagen se ve estirada, distorsionada o borrosa? ¿Notas que las letras no se ven con la misma nitidez que en la pantalla de la laptop?

Esto ocurre cuando Windows no puede manejar correctamente la pantalla, porque esta última le da información errada sobre sus características. Existe una pequeña herramienta gratuita llamada Custom Resolution Utility (CRU) que puede resolverlo.

Resulta muy fácil: ejecutamos el programa del link mencionado antes, descomprimimos el zip (no hace falta instalarlo) y ejecutamos cru.exe. La imagen que veremos será como esta:

En la parte superior hay un selector donde deberemos elegir la pantalla que queremos modificar. En la imagen mostrada ya he seleccionado mi pantalla LCD y ya he agregado una resolución que no estaba disponible: 1920x1980 (16:9) @ 60 Hz. Para ello todo lo que hay que hacer es usar el botón ADD de la lista "Standard resolutions":

Elegimos la resolución full-hd tal como se muestra, pulsamos OK para regresar a la ventana principal y estando allí volvemos a pulsar OK. Reiniciamos el equipo y listo, problema resuelto!

Si deseas saber por qué ocurre, aquí una breve explicación: las pantallas plug & play comparten información sobre sus capacidades mediante un formato de datos llamado EDID (Extended display identification data). Algunas pantallas brindan información incompleta o incorrecta, lo que causa que Windows no pueda manejar correctamente el dispositivo.

Es posible proporcionarle manualmente a Windows estos datos (lo mismo que haría un driver), pero implica manipular el registro. Aquí es donde CRU nos resulta muy útil, ya que nos permite fácilmente "agregar" una resolución específica que teóricamente nuestra pantalla no soporta. Por supuesto debemos tener cuidado porque algunas pantallas muy antiguas podrían incluso averiarse, pero cualquier televisor decente mostrará un aviso de "resolución no soportada".

Evitar que YUM actualice ciertos paquetes

Directo al grano:

Para evitar actualizar -por ejemplo- tomcat, en /etc/yum.conf agregar la línea

exclude=tomcat*

Ahora los rodeos que normalmente irían antes:

Algunas veces ocurre que tenemos una configuración especial en un servidor o equipo. Algo que es mejor no tocar porque es demasiado crítico. O también puede ser que pretendamos mantener una versión específica de ciertos programas, para pruebas de compatibilidad.

Me pasó con un cliente que utilizaba mailman para distribuir información bursatil muy importante. Un buen día la distribución no funcionó y no había tiempo para investigaciones. No tuve más remedio que "retroceder" el sistema a un estadio previo (menos mal que era una VM de la cual tenía backup).

La solución fue simple (CentOS 6.4), en /etc/yum.conf agregué

exclude=mailman*

Santo remedio, nunca más se actualizó (ni ofreció actualizar) mailman.

Y si se trata de mantener un sistema sin actualizar, se puede desactivar los repositorios básicos de yum. En /etc/yum.repos.d existen archivos por cada repositorio. Se puede crear excludes en cada uno de ellos (a diferencia del anterior que es global). O se puede desactivar completamente un determinado repositorio (enable=0) mientras que otros quedan activos.

Por ejemplo, en mi caso desactivé los repositorios base de CentOS pero (por ser una VM manejada con Cloudmin/Virtualmin) mantuve activo el repositorio virtualmin-universal porque actualiza el manejador de la máquina virtual pero no el sistema operativo.

Máquinas Virtuales

Una máquina virtual (VM por Virtual Machine) es un entorno de software que recrea las características de un equipo real de modo que podamos -para decirlo en términos simples- tener una computadora dentro de otra. Una máquina virtual tiene su propio Bios, hardware y sistema operativo con independencia de lo que utilice la máquina real que la aloja.

Las aplicaciones son variadas, desde emular entornos de hardware no disponibles por antiguedad, precio, etc. hasta consolidar múltiples equipos en uno sólo con fines de ahorro o simplificación de administración.

Hemos experimentado con máquinas virtuales desde hace varios años, pero siempre sólo para probar aplicaciones desarrolladas en VIS bajo diferentes entornos. También para probar algunas aplicaciones externas o software de dudosa procedencia sin comprometer las máquinas reales.

Recientemente, nos hemos aventurado a utilizarlo con un fin más interesante: nuestros servidores de hosting compartido. Las ventajas son enormes, especialmente por la forma en que VIS organiza sus servicios.

Concentrar todos los servicios en un único servidor es una pésima idea.

Separar todos los servicios en equipos independientes es muy costoso.

Una buena opción es agrupar los servicios en dos o tres equipos.

Una opción mucho mejor es separar todo en máquinas virtuales y distribuirlas en los mismos dos o tres equipos reales. ¿Por qué?

Las ventajas son muchas:

• La administración puede ser más refinada y precisa: se puede afinar al detalle los servicios o mantenerlos separados y controlados de manera que no interfieran entre ellos.
• Se puede ajustar los recursos asignados a cada servicio según la demanda lo requiera. Incluso se puede independizar un servicio en un equipo real independiente si el consumo así lo requiere.
• Se puede "clonar" equipos muy fácilmente, con toda la configuración ya lista.
• El costo no se eleva significativamente pero sí se requiere mayores conocimientos para poder administrar el conjunto.
• Migrar a equipos más potentes se reduce a mover la máquina virtual de un equipo a otro.

Existen muchas plataformas de virtualización en constante desarrollo, algunas comerciales, otras de código abierto: VMware, Hyper-V, KVM, VirtualBox, Xen, etc.

Como siempre, es cuestión de darse el tiempo -nunca suficiente- para experimentar con ellas y ver la forma de sacarles provecho.