¿Cómo configurar dos VirtualHost en Apache2 con diferentes versiones de PHP?

Hace poco vimos como instalar y usar dos versiones distintas de php, ahora vamos a afinar más y vamos ha hacer que cada virtualHost de Apache2 use una versión distinta de PHP (por ejemplo, PHP 7.4 y PHP 8.3) en Debian 12, la forma más robusta y recomendada es usar PHP-FPM junto con el módulo proxy_fcgi de Apache. Así, cada sitio web puede ejecutar su propia versión de PHP de manera simultánea e independiente.

Pasos para la configuración:

1. Instala y habilita los módulos necesarios de Apache:
   

   sudo a2enmod proxy_fcgi setenvif
   sudo systemctl restart apache2

2. Asegúrate de tener instalados y activos los servicios PHP-FPM para cada versión
   Por ejemplo:
   

   sudo systemctl enable php7.4-fpm
   sudo systemctl start php7.4-fpm
   
   sudo systemctl enable php8.3-fpm
   sudo systemctl start php8.3-fpm

   Verifica que los sockets existan en /run/php/ (por ejemplo, php7.4-fpm.sock y php8.3-fpm.sock).
   
   
3. Configura los archivos de VirtualHost
   Ejemplo para PHP 7.4
   Archivo: /etc/apache2/sites-available/site1.tu_dominio.conf
   

   <VirtualHost *:80>
       ServerAdmin admin@site1.tu_dominio
       ServerName site1.tu_dominio
       DocumentRoot /var/www/site1.tu_dominio
   
       <Directory /var/www/site1.tu_dominio>
           Options Indexes FollowSymLinks
           AllowOverride All
           Require all granted
       </Directory>
   
       <FilesMatch \.php$>
           SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"
       </FilesMatch>
   
       ErrorLog ${APACHE_LOG_DIR}/site1_error.log
       CustomLog ${APACHE_LOG_DIR}/site1_access.log combined
   </VirtualHost>

   Ejemplo para PHP 8.3
   Archivo: /etc/apache2/sites-available/site2.tu_dominio.conf
   

   <VirtualHost *:80>
       ServerAdmin admin@site2.tu_dominio
       ServerName site2.tu_dominio
       DocumentRoot /var/www/site2.tu_dominio
   
       <Directory /var/www/site2.tu_dominio>
           Options Indexes FollowSymLinks
           AllowOverride All
           Require all granted
       </Directory>
   
       <FilesMatch \.php$>
           SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
       </FilesMatch>
   
       ErrorLog ${APACHE_LOG_DIR}/site2_error.log
       CustomLog ${APACHE_LOG_DIR}/site2_access.log combined
   </VirtualHost>

   
   
4. Habilita los sitios y recarga de Apache:
   

   sudo a2ensite site1.tu_dominio.conf
   sudo a2ensite site2.tu_dominio.conf
   sudo systemctl reload apache2

   
   

En conclusión:

• Cada VirtualHost especifica su versión de PHP mediante la directiva SetHandler apuntando al socket de PHP-FPM correspondiente.
• Puedes tener tantos sitios como necesites, cada uno con su propia versión de PHP, sin conflictos.
• Esta configuración es válida tanto para entornos de desarrollo como de producción y es la más flexible y mantenible

.

M2000: emulador Phillips P2000

M2000 es un emulador libre de ordenadores Philips P2000, uno de los primeros ordenadores domésticos de 1981 que, heredero de las consolas Videopac, funcionaba con cartuchos y minicassettes. NO ES UN MSX.

El mismo autor incluye en otro repositorio software de ejemplo para el M2000.

Uno de sus cartuchos incluía un Microsoft Basic muy limitado pero con el que se podían hacer algunas cosas y que probarlo es un buen ejercicio para conocer los inicios de la informática de consumo. También traía cartuchos de Pascal y procesador de textos, estando disponibles otros incluso con CP/M.

Para quien simplemente quiera instalarlo y echarle un vistazo sin complicaciones, ya se puede instalar desde el script RetroMultiInstaller y no necesita leer el siguiente apartado del artículo.

Compilar M2000

Para quien prefiera compilarlo por si mismo debe ejecutar los siguientes comandos:

sudo apt install git build-essential liballegro5-dev
git clone https://github.com/p2000t/M2000
cd M2000
make allegro

Dentro de esta carpeta tendremos un archivo ejecutable llamado M2000 que debemos ejecutar con el comando;

./M2000

Para mayor comodidad recomiendo crear un acceso directo en el escritorio o en los menús, por ejemplo.

Por cierto, funciona perfectamente en PC con distros de 64 y 32 bits, pero también en todos los modelos de raspberry pi y similares.

Enlaces de interés

Para quien quiera saber más sobre este ordenador y su funcionamiento hay varios artículos sobre la serie Phillips P2000:

• Artículo en la Wikipedia (inglés).
  
• Artículo en el wiki de madrisx.org.
• P2000 Architecture.
• Primeros pasos en la revista Ordenador Personal.
  

RetroMultiInstaller: los menús solo muestran apps compatibles con el ordenador que lo ejecuta (e instalación desatendida)

RetroMultiInstaller, el script facilitador de instalaciones tenía el defecto de ofrecerte todos los scripts de instalación en sus menús, aunque no fueran compatibles con tu hardware, así por ejemplo, si lo ejecutabas en una Raspberry Pi podrías terminar instalando un programa que no fuera compatible con ARM y que por tanto no iba a funcionar.

También se ha corregido la instalación por lotes desatendida y ya aparecen solo los programas ordenados para la arquitectura actual.

 

Recuerda que, si ya tienes instalado RMI, lo puedes actualizar seleccionando las opciones:

Update ► update own

 

¿Como lo he hecho y como puedes añadir más instaladores?

Para solucionar esto he incluido un nuevo mecanismo que mira las arquitecturas declaradas en los archivos menu/*.txt de tal manera que la definición de cada línea de script quedaría ahora con esta estructura:

arquitecturas etiqueta definición

• Las arquitecturas se ponen una detrás de otra separadas por el carácter tubería "|" por ejemplo, NUNCA ESPACIOS NORMALES.
• La etiqueta sigue siendo el identificador del script.
• La definición tampoco permite ESPACIOS NORMALES pero sí espacios duros.

Algunos ejemplos, que podemos encontrar casi todos en el archivo menus/multisystem.txt:

• Si ponemos como arquitectura 'all' no filtrará, es decir, mostrará el script del menú independientemente del hardware desde el que ejecutemos RMI:
  

  all ZEsarUX ZEsarUX multi emulator

• Podemos poner una sola arquitectura, en la siguiente línea tenemos un script que solo se mostraría en Raspberry pi OS de 32 bits:
  

  armv7l Retropie Multi Emulationstation Enviroment

• Un ejemplo de un script que se ejecutaría en varias arquitecturas, en este caso solo para Intel de 32 o 64 bits o Raspberry pi OS de 64 bits.
  

  x86|x86_64|aarch64 RetroVM Retro Virtual Machine

• Las opciones para abrir otro menú o salir del actual deben tener la etiqueta menu para no aparecer en las opciones de la instalación desatendida:
  

  menu Exit Return to Main Menu

• Si en un momento un script dejara de funcionar ya no teníamos que borrarlo podemos dejarlo para arreglarlo más adelante y en el menú poner como arquitectura algo así como 'none' o 'disabled':
  

  none oldgame Old Game

 

He encontrado un programa que NO funciona, ¿qué hago?

Ahora queda la ardua tarea de ir comprobando que las arquitecturas definidas en cada script se corresponden con los programas que se pueden ejecutar en cada arquitectura, como seguro se me van a pasar muchos necesitaré vuestra ayuda en los comentarios para que me indiquéis los que no funcionan.

 

Aunque si abrís una incidencia en el propio gitlab me resultará más fácil tener el seguimiento de lo que está pendiente de arreglar. ;-)

Instalación desatendida por lotes (batch)

Instalar dos versiones distintas de php en Debian

Para instalar varias versiones de PHP, por ejemplo, 7.4 y 8.3 en Debian 12 , podemos usar el repositorio de Ondřej Surý, que es la fuente recomendada y más actualizada para múltiples versiones de PHP en Debian. Aquí tienes la guía paso a paso:

1. Actualizamos el sistema:
   

   sudo apt update
   sudo apt upgrade -y

2. Instalamos las dependencias que vamos a necesitar:
   

   sudo apt install -y lsb-release ca-certificates apt-transport-https software-properties-common curl wget

3. Agremos el repositorio de Ondřej Surý:
   

   sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
   echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
   sudo apt update

4. Instalamos php 7.4 y sus módulos necesarios:
   

   sudo apt install -y php7.4 php7.4-cli php7.4-fpm php7.4-mysql php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip

5. Instalamos php 8.3 y sus módulos necesarios:
   

   sudo apt install -y php8.3 php8.3-cli php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip

6. Comprobamos las instalaciones:
   

   php7.4 -v
   php8.3 -v

7. Podemos cambiar la versión activa de php manualmente desde la línea de comandos:
   

   sudo update-alternatives --set php /usr/bin/php7.4

   O para PHP 8.3:
   

   sudo update-alternatives --set php /usr/bin/php8.3

8. O Habilitar y arrancar PHP-FPM para cada versión:
   

   sudo systemctl enable php7.4-fpm
   sudo systemctl start php7.4-fpm

   O para PHP 8.3:
   

   sudo systemctl enable php8.3-fpm
   sudo systemctl start php8.3-fpm

Esta metodología es segura y ampliamente usada en entornos de producción y desarrollo.

Configuración extra para Moodle

Para usar con Moodle hay que instalar también los siguientes paquetes:

sudo apt install php7.4-intl php7.4-xmlrpc php7.4-soap

Y

sudo apt install php8.3-intl php8.3-xmlrpc php8.3-soap 

En los archivos  /etc/php/X.Y/fpm/php.ini hay que añadir o cambiar en la sección correspondiente:

max_input_vars = 5000 

Y reiniciamos los servicios php-fpm

sudo systemctl restart php7.4-fpm

sudo systemctl restart php8.3-fpm

¿Qué diferencia, ventajas e inconvenientes, hay entre usar update-alternatives o php-fpm?

update-alternatives y PHP-FPM cumplen funciones distintas en la gestión de PHP en sistemas Debian:

• update-alternatives: Herramienta del sistema para seleccionar la versión de un ejecutable por defecto en la línea de comandos (CLI), como php, phar, etc.
• PHP-FPM: Gestor de procesos FastCGI para PHP, diseñado para servir aplicaciones web de alto rendimiento, gestionando pools de procesos PHP que atienden peticiones web a través de sockets o puertos TCP.

Cuadro comparativo:

Característica	update-alternatives	PHP-FPM
Propósito	Selección de versión de ejecutable CLI	Procesamiento eficiente de peticiones web PHP
Ámbito	Línea de comandos y scripts del sistema	Servidores web (Apache, Nginx, etc.)
Cambio de versión	Afecta solo a la CLI (no al servidor web)	Cada pool puede usar una versión diferente
Concurrencia	No aplica	Maneja múltiples peticiones concurrentes
Personalización	Limitada a la selección de ejecutable	Pools configurables por usuario, dominio, etc.

 

Consideraciones:

• Cambiar la versión de PHP con update-alternatives solo afecta a la CLI, no a los sitios web servidos por PHP-FPM.
• Para que un servidor web use una versión específica de PHP-FPM, debes apuntar el socket o puerto correspondiente en la configuración del servidor web.
• No puedes tener un único socket genérico para alternar versiones de PHP-FPM sin perder la posibilidad de ejecutar varias versiones simultáneamente.
• PHP-FPM es imprescindible para entornos web modernos y de alto tráfico, mientras que update-alternatives es útil para scripts y tareas del sistema.

Copiar archivos clave de un Batocera a otro

Imagina que un amigo te ha pasado una imagen para raspberry pi, ya preparada con una colección estupenda de roms y bios de libre difusión para raspberry pi 3+ pero tu tienes una raspberry pi 2, una 4 o una 5, por supuesto no te funciona, ¿qué haces?

Pues lo más sencillo es bajarse la versión para tu modelo concreto de la página oficial de Batocera y copiarte los directorios roms y bios de la imagen de tu amigo a tu tarjeta, pero ¿cómo?

Hay varias maneras de conseguir esta "proeza", hoy voy a explicar la más evidente, copiar el contenido de la carpeta /share de una imagen de batocera a otra, al menos los subdirectorios roms y bios completos.

Para complicarnos lo mínimo vamos a "tostar" la imagen que nos ha pasado nuestro amigo a un pendrive que tenga como mínimo el tamaño de la imagen,  con el tamaño suficiente y conectarlo a un puerto USB.

La imagen microSD que hemos tostado de la página oficial de batocera la conectaríamos al PC, si usamos GNU/Linux bastaría con ejecutar mc como administrador (root) y copiar el contenido de cada carpeta del pendrive a la microSD.

Pero... ¿y si usamos Windows?

Hay soluciones para leer particiones de GNU/Linux, como ext4, desde el ventanucos pero son bastante inestables y nos pueden dar algún disgusto, así que la solución correcta es hacerlo de manera nativa.

Simplemente, nos creamos un pendrive de autoarranque con alguna distribución live sencillota, por ejemplo Linux Mint Mate que ya incluye mc (aunque si usamos otra la podíamos instalar en el live temporalmente) y seguir los mismos pasos que si tuvieramos un GNU/Linux nativo. Así ni siquiera tocamos el sistema que trae el ordenador y no lo comprometemos con software experimental y puede que hasta de dudosa procedencia.

Lo mínimo para hacer un video con presentación una sola persona con un móvil y edición básica con GNU/Linux

Este experimento lo hice para crear el vídeo sobre como resetear un Android TV.

En esta ocasión usé dos programas, ffmpeg y vlc, que si no los tienes instalados ya estás tardando. 

sudo apt install ffmpeg vlc

Vamos al lío:

• introduccion.mp4: En la primera parte de vídeo aparezco en mi cuarto de ordenadores con algunos equipos de fondo, este trozo lo grabé yo mismo con el móvil haciendo un "video selfie", pero como en todos los selfies la imagen sale como si te miraras en un espejo, por tanto este trozo requería un efecto de espejo horizontal, para ello usé el siguiente comando de ffmpeg:

fmpeg -i introduccion.mp4 -vf "hflip" introduccion_corregida.mp4

 

• video_principal.mp4: Después grabé en otro archivo todo lo que fue la operación de wipe con la cámara normal del móvil, aquí el problema era hacerlo todo con una sola mano, pero por lo demás fue un vídeo que no requirió modificaciones.
  
  
• video_final.mp4: Así que ya solo me quedaba unir los dos trozos, en esta ocasión usé VLC en modo CLI, es decir, un comando de consola:

vlc introduccion_corregida.mp4  video_principal.mp4 --sout "#gather:std{access=file,dst=video_final.mp4}" --sout-keep

Resumiendo: 

introduccion_corregida.mp4 +  video_principal.mp4 = video_final.mp4

Y ya está, terminado y listo para subir :-D

Script bash para comprimir cada directorio de la ruta actual en un archivo zip independiente

Supongamos que tenemos, en una ruta determinada de nuestro disco, varias carpetas cada una con los archivos correspondientes a un determinado programa y queremos que el contenido de cada una se guarde en un archivo zip independiente, lo podíamos hacer con un script como éste:

#!/bin/bash
for dir in */; do
    dirname=$(basename "${dir}")
    cd ${dir}
    zip -r "../${dirname}.zip" .
    cd ..
done

El script hace lo siguiente:

1. Recorre la lista de nombres de directorios
2. Nos cambia a la ruta
3. Comprime el contenido en un archivo zip con el mismo nombre que el directorio y guardándolo en un nivel inferior de la ruta, es decir, donde ejecutamos el script.
4. Vuelve a la ruta original, bajando un nivel.

Este script lo copiaría con el nombre dir2zip en la ruta /usr/local/bin para que esté disponible desde cualquier lugar de nuestro disco, ya que debe ejecutarse desde el mismo directorio.

Se puede mejorar fácilmente para que haga otras cosas:

• Pasar la ruta opcionalmente como parámetro.
• Comprimir solo un nivel e ir ejecutándose recursivamente, si esa es nuestra necesidad.
• Borrar la carpeta después de una compresión exitosa.
  

Si se te ocurre maneras de mejorar en el script exponlas en los comentarios y así seguimos aprendiendo entre todos.

Quien sabe lo mismo me animo y explico más adelante como hacer el script contrario: zip2dir.