Cómo usar un directorio .bashrc.d para no «ensuciar» nuestro .bashrc

En los sistemas operativos GNU/Linux, el fichero ~/.basrhrc es un script de bash que se ejecuta cada vez que hacemos login en un terminal, y en él podemos encontrar las configuraciones que se aplican cada vez que iniciamos una sesión.

Es habitual escribir en él todo aquello que queremos añadir ya sea por gusto personal o para incluir una configuración que necesitemos o necesite un programa para ejecutarse, por lo que, si no somos muy cuidadosos, al final podemos llegar a tener un script .bashrc bastante «sucio» y desorganizado.

Otra cosa a tener en cuenta es que si hacemos una reinstalación de nuestro sistema, perderemos todas esas modificaciones, salvo que previamente las hayamos extraído y respaldado en un fichero aparte, algo que puede resultar engorroso si dichas modificaciones las tenemos esparcidas por todo el script.

Para evitar esto podemos hacer uso de un directorio .bashrc.d. Si miramos en el .bashrc que se crea por defecto en Fedora 39, veremos que tiene las siguientes líneas:

# User specific aliases and functions
if [ -d ~/.bashrc.d ]; then
for rc in ~/.bashrc.d/*.bashrc; do
if [ -f "$rc" ]; then
. "$rc"
fi
done
fi

Este código hace que se ejecuten todos los script que tengamos en el directorio .bashrc.d con extensión «bashrc», por lo que podemos incluir ahí todas nuestras modificaciones del perfil en scripts separados, de forma que podamos localizarlas rápidamente, así como respaldarlas, pues solo tendremos que copiar a un medio externo nuestro directorio .basrdc.d

Pongamos un ejemplo: yo suelo usar el alias «la» para ejecutar el comando «ls -la» pero no suele venir por defecto en Fedora. Para incluirlo en mi configuración primero creo el directorio «.bashrc.d»

mkdir ~/.bashrc.d

A continuación creo en él un fichero «01_alias.bashrc» con la línea

alias la="ls -la"

Si ejecuto en este momento la lista de alias que tengo en mi sistema con «alias -p» no aparecerá listado.

Si cierro el terminal y lo vuelvo a abrir, puedo comprobar que ahora ya sí que me aparece.

De la misma manera podemos crearnos por ejemplo un script ~/bashrc.d/10_python.bashrc con la línea

export PIP_REQUIRE_VIRTUALENV=TRUE

Y de la misma forma para cualquier otra configuración que necesitemos.

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.

Iwlwifi falla en Linux con el error -110

Después de una instalación limpia de Fedora 39 en un Dell Latitude 5590, y comprobando que todo funcionaba bien, tras un par de reinicios, dejó de funcionar el wifi. No es que diera error, simplemente no aparecía ni la opción de activarlo, como si hubiera dejado de reconocerse el hardware. Haciendo un:

dmesg | grep iwlwifi

Se mostraba el error:

iwlwifi failed with error -110

Después de varias tentativas y búsquedas por internet, parece ser que el problema surge a causa del «fast boot» habilitado en la BIOS. Para corregirlo, hay que entrar en la configuración pulsando «F2» al iniciar.

Vamos a la sección Secure Boot y ponemos:

  • Secure Boot Enable, sin el check.
  • Secure Boot Mode, en modo Audit.

Después vamos a la sección POST Behaviour y ponemos:

  • Fastboot en modo Thorough

De esta manera, al reiniciar, ya aparece la wifi funcionando. Al parecer, el inicio rápido es tan rápido que no permite que se carguen correctamente los drivers en Linux al arrancar. Las prisas nunca han sido buenas.

Cómo ver VirtualBox a pantalla completa

Cuando instalamos VirtualBox y creamos una máquina virtual GNU/Linux en él, inicialmente la resolución que nos presenta suele ser menor que la que disponemos en la pantalla del anfitrión. Para ver la máquina virtual a pantalla completa hay que pulsar las teclas Ctrl derecha + F (en caso de que la tecla anfitrión sea esa, lo podemos comprobar en la esquina inferior derecha de la ventana de VirtualBox) o seleccionar la opción Ver / Modo a pantalla completa en las opciones de la ventana en la que se ejecuta la máquina virtual. Lo habitual también suele ser que al hacerlo tampoco veamos la máquina virtual a pantalla completa, sino la misma resolución con un borde blanco o negro que rellena alrededor. Eso se debe a que antes hay que hacer un par de cosas:

En la máquina virtual, instalar los headers del kernel. Por ejemplo en las distribuciones Red Hat/Fedora/CentOS sería:

sudo dnf install kernel-devel
sudo dnf install kernel-headers

A continuación montamos el CD de las «guest additions» (traducido horriblemente como «complementos del invitado») seleccionando la opción Dispositivos / Insertar imagen de los complementos del invitado en la ventana de VirtualBox en la que se está ejecutando la máquina virtual

A continuación abrimos el navegador de archivos y nos situamos en la unidad del CD de los complementos

Hacemos click derecho en la ventana y seleccionamos «Abrir un terminal», ejecutando en él:

sudo ./VBoxLinuxAdditions

Si la ejecución no nos da ningún error, ya podremos ver la ventana de la máquina virtual a pantalla completa al pulsar Ctrl derecha + F , aunque es posible que solo lo haga después de un reinicio.

Conectar NetBeans a un repositorio de GitHub

Es fácil trabajar en NetBeans utilizando Git como controlador de versiones, pero para hacer la conexión correctamente con GitHub hace falta seguir una serie de pasos que son los siguientes:

  • Crear el repositorio en GitHub, no hace falta incluir contenido.
  • Creamos el proyecto en NetBeans, o entramos en un proyecto que ya tengamos y queramos versionar en GitHub.
  • Hacer click derecho en el proyecto en el árbol de directorios de la izquierda en NetBeans, y seleccionamos «Versioning / Initialize Git repository»
  • Hacer otra vez click derecho sobre el proyecto y seleccionar «Git / Add»
  • Hacer otra vez click derecho sobre el proyecto y seleccionar «Git / Commit, seleccionando todos los elementos y especificando un texto explicativo del commit.
  • Hacer otra vez click derecho sobre el proyecto y seleccionar «Git / Push»

De esta manera ya tenemos creado y versionado el proyecto en local. Ahora lo conectamos con el repositorio de GitHub haciendo lo siguiente:

  • Hacer click derecho sobre el proyecto y seleccionar «Git / Remote / Push»
  • Especificamos el repositorio remoto, por ejemplo si hacemos la conexión con claves ssh la dirección será del tipo git@github.com:<miUsuario>/<miProyecto>.git
  • Al hacer el push nos preguntará en qué rama y seleccionaremos la rama «master», aceptando la pregunta «Set up remote tracking?»

Puede ser que al hacer este Push solo nos aparezca una rama o que aparezcan dos: una «main» que es la que creó GitHub al inicializar el repositorio y que no tiene apenas contenido, y otra «master» que es la que acabamos de crear. En ese caso, vamos a GitHub, seleccionamos la rama «master» como la rama por defecto y posteriormente borramos la rama «main». De esta forma ya se queda el repositorio preparado para versionar el proyecto.

Yii: error de permisos en /var/lib/php/sessions

Al probar una instalación limpia de Yii2 basic en Debian 12, salta el error:

Estoy ejecutando Yii2 en un directorio web de usuario colgando de /home/<usario>/public_html. Parece que el usuario con el que se ejecuta Yii no tiene permisos para crear una sesión en la carpeta del sistema, que por defecto pertenece a root.

Una solución rápida pero poco aconsejable es cambiar los permisos de la carpeta /var/lib/php/sessions para que cualquier usuario pudiera grabar información en ella, pero no es aconsejable cambiar los permisos de los directorios por defecto de la instalación. Una mejor solución es cambiar en PHP el directorio en el que se guardan las sesiones, creando previamente uno cerca del lugar donde está situado el raíz de nuestra aplicación web. Para ello insertamos las siguientes líneas en el archivo index.php antes de iniciar la sesión:

ini_set('session.save_path',realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../../session'));

ini_set('session.gc_probability', 1);

session_start();

Hemos creado previamente un directorio «session» dos niveles más arriba en el árbol de directorios de donde tenemos situado el index.php de la aplicación.

La primera línea de código indica a PHP que guarde los archivos de sesión en esa carpeta. La segunda es específica para un sistema Debian, donde el borrado de sesiones obsoletas se hace de forma periódica eliminándolas de las carpetas por defecto. Como hemos cambiado la carpeta donde se guardan, tenemos que decirle que limpie sesiones para que no se nos acumulen.

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/

Instalar KDE en Debian 11

Después de mucho tiempo trabajando en Debian con Gnome, me entraron las ganas de volver a usar KDE, escritorio que hace tiempo que no uso. Hacer el cambio es muy sencillo. Ejecutamos en un terminal:

sudo apt update && sudo apt upgrade
sudo apt install tasksel -y

A continuación ejecutamos tasksel

sudo tasksel

Y seleccionamos el escritorio que queremos instalar, en este caso KDE.

Esta es la forma en la que se explica la forma de instalar KDE en Debian en las páginas que he consultado, sin embargo, en ninguna de ellas se cita, y creo que es importante, que hay que tener en cuenta que el gestor de inicio de sesión por defecto en KDE es sddm, por lo que si procedemos de Gnome, que usa el gdm3, algunas cosas no funcionan, como por ejemplo activar el inicio de sesión automático de un usuario. Por evitar esto, tenemos que instalar también:

sudo apt install sddm kde-config-sddm sddm-theme-debian-maui

Y a continuación seleccionamos sddm como gestor de inicio con:

sudo dpkg-reconfigure sddm

Y ya está, ya tenemos KDE en Debian funcionando con su inicio de sesión correcto.

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.

Entorno de desarrollo con R, RStudio y GitHub en Ubuntu Linux

Para instalar un entorno de desarrollo usando el lenguaje de script R, el IDE RStudio y usar el control de versiones de GitHub en un ordenador con Ubuntu Linux 21.10 (aunque sería muy similar en otra versión o distribución de Linux) tenemos que realizar los siguientes pasos:

1. Instalar GIT y SSH (es posible que alguno ya esté instalado).

sudo apt install git openssh-client ssh-askpass

2. Configurar Git para que use nuestro usuario y email por defecto.

git config --global user.name "miusuario"
git config --global user.email "micorreo@miserver.com"

3. Instalar R. Para ello podemos por ejemplo seguir la guía de DigitalOcean.com.

También es conveniente instalar un par de librerías que serán necesarias si queremos trabajar con el paquete «tidyverse» de R.

sudo apt install libxml2-dev libcurl4-openssl-dev

4. Instalar RStudio, descargando la versión correspondiente de la web de RStudio. La última versión para Ubuntu es en estos momentos la rstudio-2021.09.1-372-amd64.deb que podemos instalar una vez descargada simplemente dando click con el botón derecho y seleccionando «Abrir con instalar software».

5. Crear una cuenta en GitHub, si no la tenemos ya.

6. Crear un par de claves SSH desde RStudio, para ello abrimos el IDE y vamos a Tools / Global options / Git/SVN. Pulsamos sobre el botón «Create RSA Key» y una vez que la crea pulsamos en el enlace «View public key» seleccionando y copiando nuestra clave pública. Aunque es opcional, es muy recomendable poner una password a la clave en su creación. Es posible que nada más crearla no veamos la nueva clave en la ventana, pero es un error de visualización, pues el fichero sí que está creado (podemos confirmarlo listando el directorio .ssh de nuestro usuario). Si cerramos RStudio y lo volvemos a abrir, veremos que ya aparece la clave tal y como se muestra en la imagen siguiente.

7. Añadimos nuestra clave pública a GitHub. Entramos en nuestra cuenta y desplegamos la lista junto a nuestro nombre arriba a la derecha, vamos a Settings y en las opciones de la derecha seleccionamos «SSH and GPG keys». Pulsamos el botón «New SSH key», le damos un nombre a nuestra clave y pegamos la clave pública copiada en el paso anterior en el espacio reservado para ello.

8. Probamos la conexión SSH con GitHub. Abrimos un terminal y tecleamos:

ssh -T git@github.com

Ya tenemos todo lo necesario para trabajar con R, RStudio y GitHub. Para probarlo podemos por ejemplo crear un repositorio en nuestra cuenta de GitHub, y seleccionamos el código para clonar correspondiente a la opción «SSH».

Desde RStudio seleccionamos File / New Project / Version Control / Git y ahí pegamos la dirección copiada en GitHub. Dando a Create Project se clonará el repositorio en la carpeta que hayamos seleccionado.

En caso de que nos de el error: «host key verification failed» entonces debemos de agregar GitHub a los hosts confiables, para ello ejecutamos en un terminal:

ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts

Trabajar con Git en RStudio es muy sencillo, hay una guía muy bien explicada en la web de soporte de RStudio para trabajar con el control de versiones.