Actualizar PHP y su referencia en Apache2

Tras actualizar PHP y tener la nueva versión 8.3 varias cosas dejaron de funcionar y como siempre olvido los pasos a seguir para corregir, mejor lo dejo de referencia para el futuro :P

Si hay una nueva versión de PHP instalada y se estaba usando mysql como motor de base de datos, se debe validar que está instalado el módulo correspondiente a la nueva versión o instalar si hace falta:

sudo apt install php8.3-mysql

Ajustar las versiones de PHP en uso validando que corresponde a la última:

sudo update-alternatives --config php

sudo update-alternatives --config phar

sudo update-alternatives --config phar.phar

NOTA: en caso de tener otros módulos, se debe ejecutar comando sobre ellos igual, ej: phpize, php-config.

Si se quiere hacer el ajuste manualmente se pueden utilizar los comandos a2dismod y a2enmod:

sudo a2dismod php8.2

sudo a2enmod php8.3

En caso de estar usando carpetas de usuario para contenido web, se debe eliminar la restricción en apache:

sudo vi /etc/apache2/mods-enabled/php8.3.conf

Comentando la parte del mod_userdir con #

#<IfModule mod_userdir.c>
#    <Directory /home/*/public_html>
#        php_admin_flag engine Off
#    </Directory>
#</IfModule>

Revisar la configuración de php para la versión actual en caso de ajustes realizados en la versión previa:

sudo vi /etc/php/8.3/apache2/php.ini

Para finalizar se debe reiniciar apache:

sudo service apache2 restart

Y listo, ya todo debiera funcionar nuevamente sin problemas :)

Referencia:

https://httpd.apache.org/docs/2.4/howto/public_html.html

https://slaford.com/laravel/how-to-switch-php-versions-on-command-line-ubuntu/ 

Sesiones en PHP

Luego de crear una sesión con session_start(), lo recomendado es administrar dichas sesiones usando la variable global $_SESSION, agregando ahí un parámetro de tiempo referencial y luego validar si ese tiempo se cumplió o no, por ejemplo:

$_SESSION['fin'] = time() + 30 * 60 // tiempo en segundos plazo 30 minutos * 60 segundos

A pesar de haber configurado el valor y que el tiempo aún no expire, en algunos casos el usuario puede que reciba un término anticipado de la sesión teniendo que volver a ingresar, pero ¿por qué pasa eso? :/

Aparte de las variables de manejo de las sesiones, hay que recordar validar el tiempo del recolector de basura de PHP que va eliminando archivos temporales en el servidor, eso incluye los archivos asociados a sesiones. El tiempo por defecto es de 1440 segundos (24 minutos). Si se manejan sesiones de mayor tiempo se debe ajustar también ese parámetro de lo contrario si no hay actualizaciones el archivo de sesión será eliminado. Para ajustar se debe ir al archivo de configuración de apache "php.ini" y cambiar el valor del parámetro "session.gc_maxlifetime".

Dependiendo de la versioń de PHP es el archivo a configurar, por ejemplo para versión 7.3:

/etc/php/7.3/apache2/php.ini

Luego de ajustar el valor, se debe reiniciar el servicio:

service apache2 restart

o

systemctl restart apache2

No olvidar dejar un tiempo mayor al que se utiliza en el código y ahora sí todo está listo para administrar correctamente esas sesiones :D

Referencias:

https://www.php.net/manual/en/session.configuration.php

https://www.codeleaks.io/increase-session-timeout-in-php/

SSH y redireccionamiento: Abrir programas gráficos desde SSH estando bajo Screen

Una excelente herramienta para tener múltiples consolas de SSH bajo una misma conexión es "screen". Con ese programa nos ahorramos el tener que iniciar varias sesiones, pudiendo hacer todo desde una única. Esta maravilla de programa la expliqué en otra entrada, les recomiendo darle una vuelta... de verdad es un ahorro de tiempo y recursos 😀

Al conectarnos por SSH agregando la opción de redireccionamiento podemos abrir programas gráficos, es decir, tendremos en nuestro cliente un programa que en realidad se está ejecutando en el servidor, ahorrándonos tener que abrir todo el ambiente gráfico para enfocarnos específicamente en la aplicación ¿genial o no?

Si estamos usando screen, hay que tener en cuenta algunos detalles en la configuración o no veremos nada de la magia 😛

Revisar configuración de redireccionamiento

Estando conectados por SSH es posible hacer redireccionamiento de la parte gráfica, pero esa opción debe estar habilitada en el servidor. 

Revisar la configuración del servidor en "/etc/ssh/ssd_config". Ahí la opción "X11Forwarding" debe estar activa y con "yes". 

X11Forwarding yes

Si estaba desactivada y la activan, no olvidar reiniciar el servicio para que quede funcionando con la nueva configuración.

$ systemctl restart sshd

Conectarse por SSH con redireccionamiento activo

Para ver que todo está bien, conectarse al servidor usando opción -Y y ejecutar algún proceso, dicho programa debiera iniciar su versión gráfica en el cliente que está conectado.

$ ssh -Y -l usuario servidor.com

$ xcalc &

Con lo anterior se nos debería abrir la calculadora en el cliente que está conectado ^^.

Abrir programa gráfico bajo screen

Al iniciar screen generalmente uso las opciones -dR para recuperar la última sesión activa y partir tal cual la última vez.

Si repetimos el proceso de ejecutar algún programa gráfico puede que no nos muestre nada, pero ¿y la magia? ¿qué pasó? 

En algunos casos la variable de ambiente "gráfico" de la sesión de screen puede diferir de la configurada en SSH y como eso no coincide, veremos el programa que ejecutamos como activo en la lista de procesos, pero la parte gráfica estará perdida en el limbo. Para evitar que esto suceda debemos ajustar la variable DISPLAY para que coincida entre la ventana de screen que estemos usando y la sesión de SSH abierta, de esta forma haremos que el redireccionamiento gráfico funcione.

Cerrar screen para estar en la consola de SSH de forma directa, desde ahí ver la configuración de DISPLAY:

$ echo $DISPLAY

localhost:10.0 

En este caso el display apunta a 10, por lo que debemos configurar lo mismo en la ventana de screen que estemos usando. 

$ screen -dR

$ echo $DISPLAY

:0.0

Eso indica que la ventana actual está apuntando a 0 en vez de 10, toca ajustar:

$ export DISPLAY=:10.0

$ echo $DISPLAY

:10.0

$ xcalc &

Y magia... xcalc ahora sí aparece en el cliente, tal como se esperaba 😀

Esto se debe realizar en cada ventana bajo screen que abran, ya que por defecto se abren apuntando a :0.0 👌

Grub2 UEFI error

Más de una vez me ha tocado reparar grub en computador que tiene varios años, lo que implica haber pasado por varias migraciones. Eso sumado a que se vienen cambios en grub debido a una alerta de seguridad con "secure boot" en EFI (ver enlace más abajo), puede que más de alguno tenga problemas.  Teniendo eso en mente, acá un resumen de los pasos que generalmente ocupo para corregir y así de paso me sirve de ayuda memoria :P.

Luego de actualizaciones o instalaciones, puede que el archivo de configuración quede corrupto o simplemente "invisible" por lo que puede aparecer una ventana básica de grub.

Incluso sin reparar grub, podemos acceder a la partición con Linux de forma directa desde esa consola básica con estos comandos:

set root=(hd0,gpt8)
linux /boot/vmlinuz-4.19.0-10-amd64 root=/dev/sda8
initrd /boot/initrd.img-4.19.0-10-amd64
boot

Tiendiendo sda8 como la partición root, en caso de ser otra la partición se debe cambiar el número por la que corresponda. Lo mismo con las versiones de vmlinuz y initrd (presionando tab aparecerán los archivos disponibles).

Peeeero dado que es poco práctico escribir eso todas las veces, vamos con los pasos de la reparación.

Lo primero es tener un live cd o live usb -que es lo más habitual- e iniciar desde ahí. Idealmente es mejor tener en el live system la misma distro que está instalada, para descartar algún inconveniente.

Suponiendo que la partición EFI es sda6 y la partición root es sda8 los comandos serían:

sudo su -

mount /dev/sda8 /mnt
mount /dev/sda6 /mnt/boot/efi

for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

chroot /mnt /bin/bash

Abrir otra consola y ejecutar:

sudo apt install grub-efi

sudo grub-install --target=x86_64-efi /dev/sda --efi-directory=/mnt/boot/efi --boot-directory=/mnt/boot

Reiniciar el sistema y listo, ya debería partir grub con todas las opciones tal como antes :)

NOTA:

Para tener una idea y resumen de todo lo relacionado con el boot, se puede usar: sudo bootinfoscript.

Referencias:

https://wiki.debian.org/GrubEFIReinstall

https://forums.solydxk.com/viewtopic.php?f=5&t=7649#p71156

https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/

Nintex workflow: Cómo redondear un número / how to round a number

Desde hace un tiempo estoy trabajando con Nintex workflow para automatizar tareas en Sharepoint.
Hoy me topé con una tarea que inicialmente parecía fácil: calcular un valor y redondear el resultado. Contrario a lo que pensé, no había una opción directa para redondear :O
En varias partes leí algunas formas de hacerlo, sin embargo, mencionaban que se hacía de una forma para valores menores a 1000 y otra para mayores a 1000, por qué? Porque el número quedaba formateado como "1,000" lo que da error en uno de los pasos. Eso es válido hasta cierto punto, en realidad el error depende del idioma en el que esté el sitio donde esté alojado el worfklow. En este caso, el subsitio del Sharepoint en el que estaba trabajando está en español (es-CL) lo que da que el separador de miles es "." (punto) y para los decimales es "," (coma). Bajo ese formato, el problema de la conversión aplica para valores con decimales, peeero en realidad es fácil de resolver y no es necesario utilizar la opción de expresión regular que vi por ahí. Ahora voy a ello :)
Como mencioné antes, no existe una acción del tipo "redondear" para configurar en el nintex workflow, así que se debe usar una de las funciones inline, que en este caso es fn-Round(numero).
Al usar la función es donde se debe tener cuidado, para evitar error de conversión se debe agregar un tag de inicio y fin para indicar dónde está nuestra variable númerica: {TextStart}variable{TextEnd}

Los pasos:
- Supongamos que tenemos las variables: numeroDecimal (tipo número) y resultadoTxt (tipo texto).
- Crear una cadena de texto con la fórmula y el número a redondear, almacenar en la variable de tipo texto.
fn-Round({TextStart}{Workflow variable:numeroDecimal}{TextEnd})
- Convertir el string a número.

Y listo, con eso se tiene el valor redondeado.
En el caso de omitir los tag de inicio y fin en la fórmula, el workflow dará un error como éste:

Error parsing value. Value 'fn-Round(95,24)' is not compatible with the selected output variable type Number (double).

Esto sucede porque el procesador de la fórmula asume que la coma corresponde al paso de una segunda variable, es decir, en vez de tomar "95,24" como un único número, asume que son dos: "95" y "24", lo que excede la cantidad de parámetros de la fórmula en sí.

Creo que no es necesario realmente crear la variable de texto y almacenar la fórmula ahí, quizás es posible poner la fórmula directo en la opción de convertir valor, pero no alcancé a probar eso. De ser posible podría quedar todo en una única acción... ideal o no?


NOTA:
La función fn-Round como función inline a diferencia de su uso en los formularios (nintex form), no  permite indicar la cantidad de decimales, sino que simplemente aproxima al entero que corresponda.

Referencia:
Funciones inline: https://help.nintex.com/en-US/nintex2016/current/sp2016/Workflow/Reference/WFInlineFunctions.htm
Redondear número: https://www.codesigned.com/blog/round-a-number-with-nintex-workflow

Bot para Telegram con certificado digital autofirmado (self-signed certificate)

Esta entrada es para aquellos que están empezando a trabajar con bots para telegram y que estén teniendo problemas para que su bot reciba los mensajes después de configurar los parámetros de webhook.

La información se encuentra disponible en la documentación de Telegram, sin embargo, entre tanto paso uno se pierde, porque vi más de una pregunta sobre lo mismo: configurar webhook con certificado local, probar procesar mensajes y que no pase nada. El resumen del problema es que el certificado está mal publicado y no nos enteramos :P

Acá un resumen de lo que se debe hacer y cómo dejar el bot funcionando :)

1) Eliminar la asociación anterior del webhook para configurar de nuevo

curl -F "url="  https://api.telegram.org/bot[TOKEN_ID]/setWebhook

Donde "[TOKEN_ID]" obviamente corresponde al token asociado a al bot que se está configurando.


2) Crear el certificado digital con formato PEM para el servidor que se está utilizando y utilizar ese archivo para la navegación https.
En mi caso lo dejé a 3 años ya que es seguro que un año pasa volando, pero eso depende del gusto de cada uno.

openssl req -newkey rsa:2048 -sha256 -nodes -keyout server.key -x509 -days 1095 -out server.pem -subj "/CN=tu.dominio.cl/C=CL/ST=Santiago/L=Santiago"

Acá lo importante es el campo CN dado que debe coincidir con el nombre del servidor para el cual se está creando el certificado. Si ese parámetro está incorrecto, no se validará la navegación entre servidores y el bot no recibirá nada (punto a validar).

3) Asociar el certificado al bot.

curl -F "url=https://tu.dominio.cl/ruta/bot.php" -F "certificate=@/ruta_local/del/archivo/server.pem" https://api.telegram.org/bot[TOKEN_ID]/setWebhook

url = la ruta pública al código del bot.
certificate = ruta del archivo server.pem en el servidor (ruta local).


Si la ruta local del archivo .pem está incorrecta, y a pesar de que el registro del webhook diga que fue exitoso, no se validará la navegación entre servidores y el bot por lo que tampoco se recibirán los mensajes.



4) Revisar el estado del bot en Telegram para confirmar que el certificado está correctamente publicado y funcionando.

https://api.telegram.org/bot[TOKEN_ID]/getwebhookinfo

Si todo va bien, ahí aparecerá que se está utilizando un certificado de forma correcta.

has_custom_certificate: true

En caso de ir algo mal con el certificado, aparecerá un mensaje en ese parámetro. De ser así revisar los puntos marcados con rojo en los pasos anteriores y que coincidan con los valores reales de nombre, token y servidor.

Ahí lo tienen, luego de corregir el detalle del certificado y la ruta, quedará funcionando sin problemas :)
Algo a comentar es que si estuvieron haciendo pruebas enviando mensajes durante un rato y luego de que la configuración queda correcta, empezarán a recibir respuesta por todos esos mensajes de prueba que enviaron ya que quedan en cola en el servidor de Telegram por 24hrs :P.


NOTA:
Asociado al punto 3, aparte de asociar el certificado al bot, debe utilizarse ese certificado en la navegación https del servidor. Para activar la navegación https, si se está usando apache lo práctico es usar la ruta oficial, en ese caso sería dejar los archivos server.key y server.pem en /etc/apache2/ssl, además de cargar esa ruta en el archivo de configuración /etc/apache2/sites-available/default-ssl.conf con los siguientes parámetros:SSLCertificateFile      /etc/apache2/ssl/server.pem
SSLCertificateKeyFile /etc/apache2/ssl/server.key


Referencias:
https://core.telegram.org/bots/webhooks#a-self-signed-certificate
http://snakelab.cc/2016/10/28/telegram_gem_and_self_signed_cert.html

Acceder a cuenta de usuario en Windows sin tener la contraseña

Tal como dice el título de esta entrada, es posible acceder a una cuenta de usuario en Windows sin tener la contraseña, pero no mágicamente :P, para esto el usuario debe haber abierto sesión en el computador. Da lo mismo si el usuario bloqueó el computador, de todas formas es posible acceder a su sesión tal como la dejó, con aplicaciones abiertas y todo. Este acceso es posible haciendo uso de la elevación de privilegios de sistema desde una cuenta administrativa.
Según Microsoft (MS) esto no es una "falla de seguridad" ya que es necesario tener permisos de administrador para poder acceder a la cuenta del usuario, sin embargo, esto sí es un "riesgo de seguridad" si lo vemos desde el enfoque de separación de perfiles. Por ejemplo: un usuario X puede tener acceso a un sistema de remuneraciones al cual un administrador de sistemas no necesariamente debe tener acceso, pero podría acceder en algún momento en que el usuario X deje su computador libre o lo bloquee para ir a hacer alguna otra tarea.
Dicho lo anterior, la forma de acceder es usando el programa psexec (parte del kit "pstools" de MS) para ejecutar el administrador de tareas con permisos de sistema y desde ahí simplemente dar clic derecho sobre el usuario X en la pestaña "usuarios" y presionar "Conectar"... Tan sencillo como suena :/
Acá el detalle:

- Ingresar a Windows con la cuenta administrativa sin cerrar ninguna otra cuenta abierta, sólo presionar "Iniciar sesión con otro usuario" o "cambiar de usuario".
- Abrir el administrador de tareas para ver el ID del usuario propio (el ID de la cuenta administrativa).
   --> En el caso de Windows 10 el ID no aparece por defecto, hay que dar clic derecho en los títulos y activar la columna "ID" para que se muestre. En Windows 7 el ID aparece por defecto.
- Abrir consola como administrador y ejecutar el comando: psexec \\localhost -s -i 2 taskmgr
   --> Donde el número "2" corresponde al ID del usuario administrativo y no al del usuario al que se le secuestrará la cuenta. Ahí se debe poner el ID que corresponda, en este ejemplo es 2 (ver imagen de más abajo).
- Con el comando anterior se abrirá el administrador de tareas, pero con permisos de sistema, por lo que ahora se puede abrir la sesión del usuario X dando clic derecho sobre su nombre en la pestaña "Usuarios" y listo!

Tal como muestra la imagen esto es más largo de explicar que de hacer xD.

Al dar "Conectar" no aparecerá ninguna ventana pidiendo credenciales del usuario, simplemente se abrirá su escritorio tal como si hubieran desbloqueado el equipo.


Teniendo esto en mente, a revisar el log de windows (sección "Seguridad") con mayor frecuencia para ver si hay accesos "autorizados" en horarios incorrectos ;)

Referencias:
PSTools - https://docs.microsoft.com/en-us/sysinternals/downloads/pstools
Hack Windows User Account - https://thehackernews.com/2017/03/hack-windows-user-account.html