Firefox no muestra algunos videos web en Fedora 39

En una instalación desde cero de Fedora 39, una de las cosas que no me han funcionado ha sido la visualización de algunos videos de la web, en concreto los de un curso de EdX en el que me he apuntado. He probado a instalar codecs, etc. conforme se especifica en la página web de Fedora Docs, pero no he conseguido arreglarlo.

La solución finalmente ha sido desinstalar la versión de Firefox que viene por defecto en Fedora e instalar la que se obtiene desde Flathub. Si buscamos «Firefox» en la aplicación Software de Fedora veremos que se ofrece desde dos orígenes: el paquete rpm de la distribución y el flatpak que se obtiene de Flathub. Este último ya viene empaquetado con todos los codecs necesarios par la visualización de videos, etc.

Y con esta versión instalada, ya puedo ver los vídeos del curso sin problemas.

Por cierto, según las estadísticas del curso, solo un 5% de los que estamos apuntados al mismo usamos Linux para hacer los ejercicios, algo que me ha sorprendido, ya que el curso trata de programación y tecnologías web, aspectos en los que yo personalmente me encuentro mucho más a gusto en Linux que en Windows.

Montar el acceso a HiDrive en Linux

El sistema de almacenamiento HiDrive disponible en Ionos tiene apps clientes para Windows, Mac y Android, pero no para Linux. Sin embargo, montar el acceso en Linux como si fuera una unidad de disco más es fácil utilizando el protocolo WebDav. La forma de hacerlo es la siguiente:

Instalamos davfs. Por ejemplo en Debian sería:

apt-get update 
apt-get upgrade (si hace falta)
apt-get install -y davfs2

Creamos el directorio donde montaremos la unidad remota, lo mejor es hacerlo en /home/<usuario> para evitar problemas de permisos, pero se podría hacer en cualquier otro directorio. Problemas de permisos también pueden darse cuando el directorio se crea en un sistema de archivos distinto al raiz :

mkdir /home/<mi_usuario>/HiDrive 

Tenemos que incluir nuestro usuario en el grupo davfs2 con el comando:

sudo usermod -aG davfs2 <mi_usuario>

Ahora podemos montar dicha unidad directamente desde un terminal lanzando el comando:

mount -t davfs -o noexec  https://webdav.hidrive.ionos.com/ /home/<mi_usuario>/HiDrive/

Si queremos que esta unidad se monte automáticamente cada vez que iniciamos el equipo, podemos editar el /etc/fstab y añadir la nueva unidad, para lo cual tenemos que incluir al final de dicho fichero una línea:

https://webdav.hidrive.ionos.com/ /home/<mi_usuario>/HiDrive davfs rw,user,uid=<mi_usuario>,auto 0 0

Para no tener que introducir usuario y contraseña cada vez que accedamos, podemos guardar nuestras credenciales en el fichero /etc/davfs2/secrets añadiendo al final de dicho fichero la línea:

/home/<mi_usuario>/HiDrive <Username> <Password>

Reiniciamos y ya se puede acceder a la unidad, que se sincronizará con el contenido remoto. Si queremos, podemos añadir la ruta a «Lugares» en el explorador de archivos para acceder más rápidamente.

Más información sobre el uso de HiDrive:

https://www.ionos.es/ayuda/hidrive/configuracion/ionos-hidrive-primeros-pasos/

https://server-help.org/index.php/2021/01/18/mount-hidrive-using-webdav-protocol/

https://geekland.eu/montar-servidor-webdav-en-un-sistema-de-archivos-con-davfs2/

Error instalando HumHub: Zend OPcache API is restricted by “restrict_api”

Al intentar instalar Humhub en un hosting compartido, me ha saltado este error durante la instalación, el cual es debido a que el servidor tiene restringidas las llamadas a OPcache en la configuración de PHP. En concreto, tiene activa la restricción opcache.restrict_api, la cual permite llamar a funciones de la API de OPcache solamente desde scripts de PHP cuya ruta comience con la cadena especificada.

Atención: este error está corregido ya en la versión 1.13.0 de Humhub, donde se aplica la modificación descrita en el punto 2.

Hay dos formas de solucionar este error, dependiendo de si tenemos acceso o no a la configuración del servidor web.

1) Si tenemos acceso al php.ini

En este caso tenemos que editar el php.ini. Accedemos a él, por ejemplo en un servidor Debian 11 lo haremos con :

sudo nano /etc/php/7.4/apache2/php.ini

Encontraremos la línea a modificar haciendo ctrl+W y buscando «opcache.restrict_api». Veremos que la opción tendrá asignada una cadena de texto, la cual tendremos que borrar dejando la línea:

opcache.restrict_api = ""

Que es la opción por defecto. Guardamos el fichero, reiniciamos el servidor con:

sudo systemctl restart apache2

Y ya no debería de saltar el error cuando hagamos la instalación de HumHub

2) Si no tenemos acceso al php.ini

Esta es la situación habitual cuando intentamos instalar Humhub en un hosting compartido. En este caso tenemos que editar el código de HumHub, prefijando las llamadas a la función opcache_invalidate con el símbolo «@», que es la forma que tiene PHP de evitar que salten los errores de una función cuando es ejecutada, silenciándolos. Si buscamos la cadena «opcache_invalidate» en los ficheros del directorio donde hemos extraído el código fuente de HumHub veremos que aparece en varios de ellos, y que en casi todos ya aparece prefijado con la @, salvo en dos (estoy usando la versión 1.21.1, puede que en versiones anteriores o posteriores la situación sea distinta) que son:

/protected/humhub/libs/DynamicConfig.php

/protected/vendor/yiisoft/yii2/rbac/PhpManager.php

Tenemos que modificar el código de forma que la llamada a la función quede:

@opcache_invalidate($configFile)

en el primer fichero y

@opcache_invalidate($file, true)

en el segundo.

No me gusta solucionar un error simplemente ignorándolo, que es lo que hacemos cuando en PHP prefijamos con @ la llamada a una función, pero dado que los creadores de HumHub lo han hecho así en todas las llamadas a la función salvo en dos, creo que ha sido más por olvido que por intención. Esta solución tiene además el problema de que cada vez que actualicemos la versión de HumHub tendremos que volver a editar dichos ficheros para rehacer los cambios, salvo que la actualización no nos los cambie o nuevas versiones corrijan este problema.

Leer archivos Access desde Linux con mdbtools

El formato .mdb de Microsoft Access es propietario y su uso se restringe a los entornos de trabajo Windows, lo cual implica no solo tener el sistema operativo de Microsoft sino además haber comprado una licencia de Office. Al no poder trabajar de forma directa con ellos en Linux, ya existen aplicaciones que nos permiten leerlas, como son por ejemplo DBeaver o Kexi. Sin embargo, puede que no necesitemos un programa tan completo, sino que solo nos interese extraer la información contenida en el Access para luego procesarla por otros medios. Para este cometido lo más sencillo es utilizar la herramienta mdbtools. Aunque podemos bajarnos el código y compilarlo, es más fácil utilizar los gestores de paquetes de cada distribución Linux, por ejemplo en Fedora o cualquier distribución basada en Red Hat la forma de hacerlo sería:

sudo dnf install mdbtools

Una vez instalada, tenemos a nuestra disposición varios comandos, uno de los cuales es mdb-export, que nos permite exportar una de las tablas contenidas dentro del archivo Access a un fichero de texto plano con formato csv de esta forma:

mdb-export nombre_Access nombre_tabla > nombre_fichero.csv 

Donde nombre_Access es el nombre del ficho Access; nombre_tabla es el nombre de la tabla dentro del Access de la que queremos obtener los datos; y nombre_fichero.csv es el nombre del fichero de texto en el que queremos guardar la información. Existen más opciones para la exportación de datos que pueden consultarse simplemente tecleando «mdbtools» en la consola:

En caso de que no conozcamos a priori los nombres de las tablas incluidas en el Access, podemos obtenerlos con el comando:

mdb-tables nombre_Access

Existen más comandos que podemos usar, y podemos obtener una lista de ellos si tecleamos «mdb-» en la consola y pulsamos el tabulador. El que puede sernos bastante útil es mdb-schema, que nos devuelve no solo las tablas que tenemos en el Access sino también los campos que tiene cada una y su formato.

Otra de las buenas características de mdbtools es que puede usarse también desde un script de R, si previamente instalamos el paquete Hmisc en R con:

install.packages("Hmisc")

Con él instalado podemos usar el comando:

mdb.get(RutaAlFicheroAccess, "nombre_tabla") 

Esta opción de carga de datos desde R me parece más interesante que la utilización de los paquetes basados en Rodbc, porque dichos paquetes necesitan que la arquitectura del sistema (32 o 64 bits) sea la misma que la del Access, lo cual puede ser un problema.

Fedora 33: buenas impresiones

Aunque hace ya tiempo que se liberó la versión 33 de Fedora, no me había decidido a probarla hasta hace unos días. Me relación con Fedora comenzó hace bastantes años, creo que la primera versión que probé fue Fedora 5, y por una u otra razón (no reconocer el hardware, principalmente) no terminaba de convencerme para su utilización diaria en mi equipo de trabajo, en el que casi siempre tenía Debian o una distribución basada en Debian.

Esa sensación ha cambiado totalmente con la versión 33, la cual he instalado en lo que es mi actual equipo de trabajo: un Dell Latitude E6320 con procesador i5-2520, 4Gb de RAM y disco HDD de 250 Gb, un portátil robusto pero que tiene ya más de seis años. Ha reconocido perfectamente el hardware a la primera y el equipo se nota ágil y efectivo. Tengo que resaltar que este equipo resultaba extremadamente lento y prácticamente inutilizable con Windows 7, el sistema operativo que traía de fábrica, y cuyo anterior propietario lo tenía destinado al punto limpio, si no hubiera pasado antes por mis manos y por la magia del ecosistema GNU/Linux.

En estos momentos me permite conectarme perfectamente en remoto a mi equipo con Windows 10 del trabajo mediante una VPN y el escritorio remoto Remmina; maneja una pantalla externa auxiliar sin problemas de resolución y ha reconocido perfectamente el adaptador wifi y el teclado inalámbrico por bluetooth. La conexión con Skype empresarial se puede hacer mediante el equipo remoto, direccionando en Remmina los dispositivos de audio al equipo local, y además se puede configurar la calidad de la conexión remota, y así en caso de que no tengamos mucho ancho de banda disponible podemos bajarla para que la respuesta sea mejor. De esta forma, el teletrabajo es perfectamente posible independientemente del sistema operativo que necesitemos usar, con un equipo muy modesto gracias a su nueva vida con Fedora 33.

Cómo leer una base de datos Microsoft Access desde Linux con DBeaver

La base de datos Microsoft Access no está disponible para Linux, por lo que para acceder a ella o bien se usa un equipo con sistema operativo Windows, o bien extraemos su contenido con mdbtools, o bien usamos una aplicación que nos permita acceder a su contenido desde Linux. Un programa para hacer esto último, que a mí me ha parecido fácil de usar y bastante completo, es DBeaver.

Aunque es un programa de pago, tiene una versión Community gratuita que permite hacer muchas cosas, entre ellas acceder a una gran variedad de bases de datos, entre las que se encuentra Access. Tiene versión para Linux en formato deb, rpm, snap… En mi caso, Debian 10, la instalación sería como sigue:

Como es un programa escrito en Java, se necesita previamente instalar dicho entorno de ejecución ejecutando en un terminal:

sudo apt install default-jre default-jdk

Y comprobando que se ha instalado correctamente con:

java -version

javac -version

A continuación descargamos el fichero .deb y situándonos en la carpeta en la que se encuentra el fichero descargado, ejecutamos:

sudo dpkg -i dbeaver dbeaver-ce_7.0.1_amd64.deb

Una vez hecho esto, antes de lanzar el programa es conveniente ampliar la memoria RAM que va a utilizar porque la que viene por defecto puede ser escasa si la base de datos contiene muchas tablas. Para ello editamos el fichero /usr/share/dbeaver/dbeaver.ini (se puede consultar una explicación de cómo está organizado este fichero) modificando las líneas:

-Xms64m

-Xmx1024m

De forma que especifiquemos en ellas la cantidad inicial de memoria que usará el programa (-Xms ) y la máxima (-Xmx) que permitiremos que utilice. Hay que establecer unos valores que sean admisibles por el ordenador en que se esté trabajando. Para saber de cuánta memoria libre disponemos podemos ejecutar el comando free, y ajustar los valores en consecuencia. En mi caso he indicado -Xms1024m y -Xmx4096m.

A continuación iniciamos DBeaver y pulsando en el icono «Nueva conexión» (el enchufe):

Nos aparecen todas las bases de datos disponibles, bajamos hasta encontrar Access, la seleccionamos y pulsamos Siguiente:

A continuación especificamos dónde se encuentra el fichero .mdb que queremos abrir y lo seleccionamos. Es posible que se nos pida instalar un complemento java si no lo tenemos ya instalado, basta con pulsar en «Download» y tras finalizar, ya tendremos la base de datos Access disponible para su consulta en el navegador de bases de datos de la aplicación.

Como DBeaver tiene un asistente de exportación, podremos también extraer la información de la tabla que deseemos a un archivo .csv o .sql para su posterior carga en otra base de datos que no sea exclusiva de Windows.

Pantalla en negro tras el inicio de sesión en CrunchBang Linux

Si utilizando CrunchBang Linux ocurre que, tras la pantalla de login, el escritorio se queda totalmente en negro, mientras que el resto de consolas (ctrl+alt F1 a ctrl+alt F6) siguen funcionando correctamente, puede ser debido a que se ha desconfigurado el gestor de sesiones, haciendo que nuestra sesión por defecto sea lxsession en vez del openbox.

Para arreglarlo basta con abrir una de los consolas que funcionan (p.ej. ctrl+alt F1) y en ella teclear:

sudo update-alternatives –config  x-session-manager

Aparecerán varias opciones, cada una de ellas asociada a un número, por lo que deberemos introducir el correspondiente a openbox-session.

x-session-optionsDespués de esto, reiniciamos el equipo y ya arrancará de nuevo con el escritorio de OpenBox.

Solución encontrada en unix.stackexchange.com

 

 

 

Error «.htaccess: Options not allowed here» en Apache2

Este error me ha aparecido en el log de Apache cuando he intentado acceder a una réplica en mi directorio de usuario de una página hecha en Drupal. Para solucionarlo he tenido que editar el archivo «/etc/apache2/sites-available/000-default.conf» añadiendo las lineas

<Directory /home/mi_usuario/public_html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

Y reiniciar el servicio con «sudo service apache2 restart»