Mostrando entradas con la etiqueta servidor. Mostrar todas las entradas
Mostrando entradas con la etiqueta servidor. Mostrar todas las entradas

jueves, 14 de diciembre de 2023

¿Cómo instalo OwnCloud en Ubuntu?

Durante el discurso del 19 de enero de 1948 concerniente a la inauguración del Tren de las Nubes, Juan Perón enseñó cómo instalar OwnCloud en Ubuntu Server.

¡Estimados Señores!

Este augusto día inauguramos el ferrocarril Trasandino del Norte, que une las ciudades de Salta con la chilena de Antofagasta, como Obra de Unión de los Pueblos. En nuestras tierras pasa por Cerrillos, Rosario de Lerma, San Antonio de los Cobres, Salar de Pocitos, Toco-Toco, Caipe y Socompa, en un recorrido de 571 km del lado argentino, y cruzado al territorio hermano de Chile, las queridas localidades de Victoria, Palestina y Antofagasta, en los 331 kilómetros que tiene allí la traza. 

Forman parte de su ánima 33 puentes de acero y 21 túneles con una longitud total de 3.234 metros. La altura máxima del ramal alcanza los 4.475 metros en el imponente macizo del Abra de Chorrillos, lo que le ha valido el cariñoso apelativo de "Tren de las Nubes",

Siempre me han dicho que el Peronismo está en las nubes, e indudablemente que este nos inspira la concreción de una vía de los datos que hermane Pueblos: un troncal capaz de unir centros de datos propios controlados y conducidos por el Justicialismo. Es esto a lo que aspiramos.

Sin embargo, cuando muchos se refieren a "la nube" no lo hacen para homenajear a este querido tren, sino que lo hacen para ocultar el hecho de hablar de un almacenamiento informático proporcionado en una computadora ajena, que sólo ofrece acceso limitado desde la red de datos Internet. 

La premisa de que a estas máquinas es posible cargarle nuestro contenido digital  a veces sin costo monetario, y que éste podría estar disponible para su descarga en múltiples dispositivos, podría parecer - a primera vista - sumamente beneficiosa. Contaríamos así con la dicha y comodidad de contar con la información digitalizada al alcance telemático sin necesidad de portar medios de almacenamiento de masa para suplir la demanda. Estos señores dicen que podríamos acceder a ellos a través de los enlaces de datos...

Pues bien señores, es mi opinión que en estos menesteres, el costo es lo de menos: el hecho que la máquina sea ajena (y para peor, normalmente de una omnímoda corporación oligárquica) nos cuadra el más grave riesgo al que alguien pueda someterse sin llevar puesto un casco y un fusil. No podía ser de otra manera: ¡estas empresas lucran con los metadatos de tales archivos, a la par de reservarse su uso con fines inconfesables!

Googl€, Amazon y Micro$oft son sólo algunas de las empresas que - de mano de una opresión interesada - que ofrecen este tipo de soluciones bajo los nombres de Googledriv€, AW$, y One$pace respectivamente. Sin embargo, estas soluciones son prohibitivas ya que el contenido es sometido a inspección y no va cifrado de manera alguna.

La lucha de los hombres por la Liberación de su software es una que acarrea riesgos y es dificultosa, pero entrenándonos para suplir las verdaderas necesidades de la lid explica la manera de salir victoriosos. 

En el caso de los servicios de almacenamiento en la nube, lo procedente no es usar un servicio - por mas gratuito que sea - y mucho menos pagarlo si es una empresa extranjera. Lo ideal es montar nuestra propia nube con software libre, de la misma forma en la que nacionalizamos los ferrocarriles.

Para ello contamos con la plataforma de alojamiento de archivos OwnCloud, liberada bajo AGPLv3. Junto con el servicio de alojamiento propio - que podemos dar a los usuarios que queremos en medios de almacenamiento propios en nuestro servidor - también contaremos con las funcionalidades de ofimática que nos ofrece OnlyOffice. Este nos permitirá resguardo, cifrado opcional, visualización y edición - incluso colaborativa - de documentos de todo tipo.

Desde el punto de vista de software, OwnCloud requiere una instalación base de Ubuntu 22.04 Server con SSH activado, y una partición /var con el espacio de disco deseado (en mi caso, haré uso de unos 20 Terabytes). El directorio de OwnCloud se encotnrará en /var/www/owncloud. La versión de PHP debe ser al menos la 5, (por defecto en Ubuntu Server 20.04 se puede instalar PHP 7.4). Asimismo debemos contar con el Módulo de Multiprocesador (MPM) correcto (debemos leer las notas Versión de OpenSSL, importantes cuando se planea usar encriptación).

En este caso haremos las preparaciones de de instalación en la máquina de servicio munida con Ubuntu Server con los servicios web Apache, de base de datos MariaDB y de programación PHP 7.

Naturalmente, si contamos con un usuario común escalable en el servidor, debemos utilizar el comando sudo su e ingresar la contraseña de administrador correspondiente. 

Primero introduciremos los comandos que configuren el servicio del nombre de dominio que va a tener la instalación de de OwnCloud, especialmente el nombre de dominio que queremos para la máquina:

Configurar el nombre de dominio

mi_dominio="nube.peronismo.org"
echo $mi_dominio

hostnamectl set-hostname $mi_dominio
hostname -f

Generar contraseñas fuertes

A continuación generamos las contraseñas seguras para el usuario administrador de OwnCloud y para el usuario de la base de datos SQL. Estas se resguardarán  en /etc/.sec_admin_pwd.txt y /etc/.sec_db_pwd.txt:

sec_admin_pwd=$(openssl rand -base64 18) ;
echo $sec_admin_pwd > /etc/.sec_admin_pwd.txt ;
sec_db_pwd=$(openssl rand -base64 18) ;
echo $sec_db_pwd > /etc/.sec_db_pwd.txt

Acto seguido conviene aseguramos que todos los paquetes del servidor estén instalados y totalmente actualizados, a la vez que comprobamos que tenemos PHP a mano en el repositorio APT. Para hacer esto, seguimos las instrucciones siguientes:

apt update && apt upgrade -y

Debemos crear ahora un guion de ayuda que nos simplifique la tarea de ejecución de los comandos occ de OwnCloud. Esto lo haremos ingresando:

FILE="/usr/local/bin/occ"
cat <<EOM >$FILE
#! /bin/bash
cd /var/www/owncloud
sudo -E -u www-data /usr/bin/php /var/www/owncloud/occ "\$@"
EOM

A este guion de OwnCloud llamado /usr/local/bin/occ le otorgamos permisos de ejecución:

chmod +x $FILE

Con las preparaciones listas, instalamos las dependencias necesarias para todo:

apt install -y apache2 libapache2-mod-php mariadb-server openssl redis-server wget php-imagick php-common php-curl php-gd php-gmp php-bcmath php-imap php-intl php-json php-mbstring php-mysql php-ssh2 php-xml php-zip php-apcu php-redis php-ldap php-phpseclib

Si bien es opcional, es sabido recomendar conectar nuestro servidor a unidades de almacenamiento externas de Window$ a través del protocolo Samba. Para ello habríamos de instalar el módulo smbclient php. Aunque normalmente en el caso de las máquinas de escritorio con GNU con Linux no suele ser el caso, no es raro que otras unidades de almacenamiento y discos puedan accederse a través de la red, y en tal caso el cliente Samba por terminal nos vendría de perillas para que el servidor integre las mismas también a nuestra OwnCloud. Para ello primero instalamos sus dependencias:

apt-get install -y libsmbclient-dev php-dev php-pear

...y luego instalaríamos el módulo smblclient php por medio de pecl:

pecl channel-update pecl.php.net ;
mkdir -p /tmp/pear/cache ;
pecl install smbclient-stable ;
echo "extension=smbclient.so" > /etc/php/7.4/mods-available/smbclient.ini ;
phpenmod smbclient ;
systemctl restart apache2

Revisamos entonces si fue activado de manera exitosa:

php -m | grep smbclient

El servidor nos debería devolver lo siguiente:

libsmbclient
smbclient

...denunciando la activación de ambos módulos - ahora en más automática - toda vez que inicie el servicio.

No viene mal instalar el herramental útil adicional, que sería necesario en caso de tener que revisar y depurar errores en el servidor. Lo haremos con:

apt install -y unzip bzip2 rsync curl jq inetutils-ping  ldap-utils smbclient  

Configurar servidor web Apache

Ya deberíamos contar con el servidor web Apache instalado en nuestro Ubuntu Server. Este nos daría el servicio a la web por intermedio de un entorno virtual de uso. Para que funcione aceitadamente junto a OwnCloud debemos configurarlo con ciertas especificaciones. 

Para ello creamos un fichero de configuración /etc/apache2/sites-available/owncloud.conf para el host virtual de OwnCloud:

FILE="/etc/apache2/sites-available/owncloud.conf"
cat <<EOM >$FILE
<VirtualHost *:80>
# descomentar la línea siguiente si la variable fue configurada
#ServerName $mi_dominio
DirectoryIndex index.php index.html
DocumentRoot /var/www/owncloud
<Directory /var/www/owncloud>
  Options +FollowSymlinks -Indexes
  AllowOverride All
  Require all granted

 <IfModule mod_dav.c>
  Dav off
 </IfModule>

 SetEnv HOME /var/www/owncloud
 SetEnv HTTP_HOME /var/www/owncloud
</Directory>
</VirtualHost>
EOM

Finalmente, activamos esta configuración de Host Virtual, mediante:

a2dissite 000-default
a2ensite owncloud.conf

Configurar la Base de Datos


Como en todo uso telemático, se recomienda ejecutar el comando mysql_secure_installation para asegurar la instalación de la base de datos SQL MariaDB y ponerle una contraseña fuerte al usuario de la base de datos ("sec_db_pwd").

Nos aseguramos que el nivel de aislamiento de transacciones esté configurado, y el performance_schema esté activado.

sed -i "/\[mysqld\]/atransaction-isolation = READ-COMMITTED\nperformance_schema = on" /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl start mariadb
mysql -u root -e \
  "CREATE DATABASE IF NOT EXISTS owncloud; \
  CREATE USER IF NOT EXISTS 'owncloud'@'localhost' IDENTIFIED BY '${sec_db_pwd}'; \
  GRANT ALL PRIVILEGES ON *.* TO 'owncloud'@'localhost' WITH GRANT OPTION; \
  FLUSH PRIVILEGES;"

Se recomienda ejecutar el guion mysqltuner para analizar la configuración de la base de datos luego de usarlo con carga de trabajo durante varios días.

Finalmente, activamos los módulos recomendados del servidor Apache:

Instalación de OwnCloud

Con el servidor Web Apache y la base de datos SQL funcionando, podremos descargar e instalar OwnCloud.

Descargar ownCloud

cd /var/www/ ;
wget https://download.owncloud.com/server/stable/owncloud-complete-latest.tar.bz2 ;
tar -xjf owncloud-complete-latest-tar.bz2 ;
chown -R www-data. owncloud

Instalar ownCloud


Recuerda configurar una contraseña fuerte para el usuario de administración de ownCloud, y proveer la contraseña del usuario de la base de datos previamente obtenida, bajo el argumento --database-pass.
occ maintenance:install \
    --database "mysql" \
    --database-name "owncloud" \
    --database-user "owncloud" \
    --database-pass ${sec_db_pwd} \
    --data-dir "/var/www/owncloud/data" \
    --admin-user "admin" \
    --admin-pass ${sec_admin_pwd}

Configurar los Dominios Confiables de ownCloud

mi_ip=$(hostname -I|cut -f1 -d ' ')
occ config:system:set trusted_domains 1 --value="$mi_ip"
occ config:system:set trusted_domains 2 --value="$mi_dominio"

Configurar las automatizaciones de cron

Cron nos resultará últil para automatizar distintas tareas automáticas de mantenimiento. Configuramos el trabajo de segundo plano en cron:

occ background:cron

Configuramos la ejecución de un trabajo cronometrado cada 15 minutos y la limpieza de restos todas las noches a las 3 am:

echo "*/15  *  *  *  * /var/www/owncloud/occ system:cron" \
  | sudo -u www-data -g crontab tee -a \
  /var/spool/cron/crontabs/www-data
echo "0  3  *  *  * /var/www/owncloud/occ dav:cleanup-chunks" \
  | sudo -u www-data -g crontab tee -a \
  /var/spool/cron/crontabs/www-data

Si necesitamos sincronizar los usuarios de un LDAP o un servidor Active Directory, podemos agregar este cron adicional. De esta forma cada 4 horas cronometradas se producirá la sincronización de los usuarios LDAP en ownCloud y se desactivarán aquellos que no están disponibles en ownCloud. Además se obtendrá una bitácora en  /var/log/ldap-sync/user-sync.log para su eventual depurado.

echo "1 */6 * * * /var/www/owncloud/occ user:sync \
  'OCA\User_LDAP\User_Proxy' -m disable -vvv >> \
  /var/log/ldap-sync/user-sync.log 2>&1" \
  | sudo -u www-data -g crontab tee -a \
  /var/spool/cron/crontabs/www-data
mkdir -p /var/log/ldap-sync
touch /var/log/ldap-sync/user-sync.log
chown www-data. /var/log/ldap-sync/user-sync.log

Configuramos Caché y Acerrojado de Ficheros

occ config:system:set \
   memcache.local \
   --value '\OC\Memcache\APCu'
occ config:system:set \
   memcache.locking \
   --value '\OC\Memcache\Redis'
occ config:system:set \
   redis \
   --value '{"host": "127.0.0.1", "port": "6379"}' \
   --type json

Configuramos la rotación de bitácoras

FILE="/etc/logrotate.d/owncloud"
sudo cat <<EOM >$FILE
/var/www/owncloud/data/owncloud.log {
  size 10M
  rotate 12
  copytruncate
  missingok
  compress
  compresscmd /bin/gzip
}
EOM

Finalizar la Instalación

Nos aseguramos que los permisos sean los correctos:

cd /var/www/
chown -R www-data. owncloud

Y con esto debería haber quedado instalado ownCloud. Ahora podremos confirmar que está listo para activar el protocolo seguro de conexión HTTPS (por ejemplo usando certificados Let’s Encrypt) dirigiendo nuestro navegador web browser a la URL o IP de nuestra propia instalación de ownCloud (en este caso, nube.peronismo.org). 

Para evaluar la correcta instalación en el servidor y para ver si funcionan los comandos occ, podremos ejecutar lo siguiente:

occ -V
echo "Su contaseña de Admin es: "$sec_admin_pwd
echo "Está documentada en /etc/.sec_admin_pwd.txt"
echo "Su contraseña de Base de Datos es: "$sec_db_pwd
echo "Está documentada en /etc/.sec_db_pwd.txt y en su config.php"
echo "Su ownCloud está accesible desde: "$mi_dominio
echo "La instalación ha sido completada."
No viene mal almacenar esta información de forma segura en un medio aparte, y resguardarlo en caja fuerte.
Podremos encontrar la documentación del servidor de OwnCloud aquí.

miércoles, 9 de agosto de 2023

¿Cómo instalo Nginx en Ubuntu 22.04LTS?

 Apenas iniciada su primer Presidencia, Juan Perón impuso un plan en contra de la suba descontrolada de precios, que puso a tono los mismos y afianzó el poder de consumo del Pueblo Trabajador. Mientras presentaba el plan conocido como "de los sesenta días", explicó cómo instalar el servidor web Nginx en Ubuntu.

¡Señores!
 
Es tal la trascendencia que asigno a la necesidad de terminar con la carestía de la vida - especialmente en beneficio de la clase humilde de la Nación - que he llegado hasta aquí con el deseo de dar la iniciación de esta campaña que llamamos de los sesenta días.

En primer término se ha fijado ya hace tiempo cual es el concepto del equilibrio social entre sueldos y salarios. Existe una línea de la vida fijada por los salarios mínimos. Ese salario mínimo establece la línea de la vida. Los que por deficiencia de salario no alcanzan a ese salario vital, son sumergidos. Y los que lo pasan, son los emergidos.

Buscamos que en el país - en relación a los precios existentes - no existan salarios que establezcan la condición de sumergido para ningún ciudadano argentino. Si los precios suben justificadamente, no hay otro remedio que aumentar los salarios. Pero si suben los precios injustificadamente, el remedio está en bajar los precios.

En este momento, esos dos factores, el aumento justificado y el aumento injustificado, son las causas de la carestía de la vida.

En realidad, el aumento que puede considerarse justificado obedece a razones reales, impulsados por la escasez de producción, por el exceso de exportación o por la mala distribución de los artículos de primera necesidad. Y la causas ficticias obedecen a la especulación, a la mala distribución por acopio o por sustracción a la venta.

Lo primero ha de encararse para resolverlo en forma absolutamente racional, y por lo tanto con medidas racionales. Lo segundo, es decir la especulación, el acopio o la sustracción a la venta deberá combatirse con medidas drásticas de la mayor energía.

En este trabajo que hoy inicia el gobierno, para abaratar los artículos de primera necesidad necesitamos proceder racionalmente para llevar al mínimo los costos de producción, equilibrar la producción misma en su aspecto cualitativo, evitar el exceso de exportación en perjuicio del consumo interno, y racionalizar la producción. Y en segundo término contra las medidas ficticias, es decir la especulación, el acaparamiento o la sustracción a la venta, castigarlo con toda la fuerza de la Ley, ya que ambas cosas deben de considerarse en épocas como las actuales - en que la Nación debe servir al exterior en una proporción desconocida hasta hoy para abastecer a los pueblos hambrientos de otros continentes sin que la población argentina sufra las consecuencias de esa escasez - con una científica graduación de lo que podemos enviar al extranjero y lo que debemos mantener para el alimento de nuestra población.

Para ello, en primer término la colaboración de todos es absolutamente indispensable. Estamos encarando la solución de un problema de todos los argentinos, y en consecuencia todos los argentinos deben colaborar en su solución. Los productores, los industriales y los comerciantes deberán facilitar la solución del problema acelerando la producción, disminuyendo a lo indispensable la exportación, y asegurando la distribución adecuada. Eso en cuanto a las fuerzas patronales.

Los trabajadores tienen aquí también su cooperación, y ella ha de ser aumentando el rendimiento de su trabajo para producir más. Esa es la misión de todo trabajador en este momento. Y su cooperación en el taller, en la fábrica, y en el campo ha de ser asegurar para el país el mayor grado de producción posible, rindiendo con su trabajo en todas las horas el máximo posible.

Los consumidores - vale decir el Pueblo - también tiene su cooperación que asegurar en este problema. Cooperarán no pagando en ningún caso precios mayores que los fijados y denunciando a todo mal comerciante que quiera imponer precios sobre los oficiales fijados. Cada ciudadano debe ser un soldado de esta cruzada y cooperar con el Estado para el bien de todos.

Los funcionarios encargados de la vigilancia e inspección deben ser inflexibles y rígidos en el cumplimiento de su función. Los poderes y autoridades del Estado en todas sus jerarquías y funciones deben prestar apoyo y cooperación para la mejor realización de este plan.

Nadie dentro del país puede ser espectador indiferente sin que se lo considere un traidor a la causa de todos. Esta campaña de sesenta días, debe de poner a la Nación entera en marcha para vencer en ese plazo todas las dificultades, con la cooperación de los productores, industriales y comerciantes, con la cooperación de los trabajadores, haciendo rendir al máximo su trabajo, con la cooperación de los ciudadanos consumidores, no haciendo el juego a la especulación y no pagando en ningún caso un precio sobre los fijados.

Y señores, por sobre todas las cosas para no inutilizar todos estos esfuerzo de conjunto, necesitamos honradez. Honradez en el comerciante, para mantener la calidad de los artículos y no inutilizar los esfuerzos realizados. Honradez en el público, que no se preste a maniobras de ninguna naturaleza. Honradez en los funcionarios para hacer cumplir a todos con su deber de acuerdo a la ley.

Señores, vencidos los sesentas días, los precios de los artículos de primera necesidad serán los establecidos en 1945 por el Consejo Nacional de Posguerra, es decir, lo que necesita una familia obrera, en comida, menaje y vestido, para vivir dignamente con el salario vital mínimo establecido. 
En los servicios telemáticos también hemos de obrar de la misma manera. Hemos de disponer de software servidor capaz de cooperar y de gastar lo mínimo requerido. Nginix es la solución que hemos propuesto.

Se trata de uno de los servidores web más populares del mundo y aloja algunos de los sitios más grandes y con mayor tráfico en Internet. Es más fácil de utilizar que Apache en la mayoría de los casos y puede emplearse como servidor web o proxy inverso.

En esta guía os explicaré la manera de instalar Nginx en su servidor de Ubuntu 22.04LTS.

Requisitos previos

Antes de comenzar a usar esta guía, debería contar con lo siguiente:
  • Un servidor de Ubuntu 18.04 y un usuario regular que no sea Conductor (root) capaz de ejercer privilegios sudo. Además, debería ya tener habilitado un firewall básico capaz de bloquear los puertos que no sean esenciales. Para aprender a configurar una cuenta normal de usuario e instalar un firewall, siga nuestra guía de configuración inicial para Ubuntu 18.04.
Cuando disponga de una cuenta, inicie sesión como usuario no root para comenzar.

Paso 1: Instalar Nginx

Debido aq ue Nginx está disponible en los repositorios predeterminados de Ubuntu, puede instalarlo utilizando el sistema de paquetes apt.
Actualice su índice local de paquetes:

sudo apt update
sudo apt install nginx

Paso 2: Ajustar el firewall

Si siguió el tutorial de configuración del servidor de los requisitos previos, tendrá habilitado el firewall UFW. Compruebe los perfiles de aplicaciones ufw disponibles con el siguiente comando:

sudo ufw app list

...nuestro sistema nos devolverá:

Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Habilitaremos el perfil más restrictivo, el cual de todas formas permitirá el tráfico que hemos configurado y con ello el tráfico en el puerto 80. Para ello ingresamos:

sudo ufw allow 'Nginx HTTP' 

Verificamos el cambio realizado con:

sudo ufw status 

...nuestro sistema nos devolverá:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Nginx HTTP                 ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Paso 3: Comprobar nuestro servidor web

Realziaremos una verificación con el sistema init systemd para saber si se encuentra en ejecución el servicio, ingresando la siguiente órden:

systemctl status nginx

...a lo cual deberíamos recibir en la terminal algo como:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago Docs: man:nginx(8) Main PID: 2369 (nginx) Tasks: 2 (limit: 1153) CGroup: /system.slice/nginx.service ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2380 nginx: worker process

A través su dirección IP, accederemos a la página de destino predeterminada de Nginx para confirmar que el software opera de la manera deseada por el Pueblo:

http://IP_del_servidor

Deberíamos ver la insulsa página web de destino predeterminada de Nginx:

Paso 4: Configurar bloques de servidor (recomendable)

Al emplear el servidor web Nginx, podremos emplear _bloques de servidor _(similares a los hosts virtuales de Apache) a fin de encapsular detalles de configuración y alojar más de un dominio desde un único servidor.

Configuraremos un dominio llamado peronismo.com, pero debería cambiarlo por su propio nombre de dominio.

Creemos el directorio para peronismo.com, utilizando el indicador -p para crear cualquier directorio principal necesario:

sudo mkdir -p /var/www/peronismo.com/html

Asignamos la propiedad del directorio:

sudo chown -R $USER:$USER /var/www/peronismo.com/html

Los permisos de su las raíces de nuestras webs han de ser las correctas si no modificó su valor umask, pero podremos comprobarlo ingresando:

sudo chmod -R 755 /var/www/peronismo.com

Asimismo, crearemos allí una página de ejemplo index.html utilizando el editor GNU Nano:

nano /var/www/peronismo.com/html/index.html

Se abrirá el editor GNU Nano con el archivo vacío index.html. Le pegaremos el siguiente contenido:

 

Guardamos los cambios en el archivo con Ctrl+o y cerramos el editor con Ctrl+x.

Acto seguido, creamos un nuevo bloque de servidor en /etc/nginx/sites-available/peronismo.com. Lo haremos con:

sudo nano /etc/nginx/sites-available/peronismo.com

Le pegamos en dicho archivo el siguiente bloque de configuración, a fin de actualizar nuestro nuevo directorio y nombre de dominio:

server {
        listen 80;
        listen [::]:80;

        root /var/www/peronismo.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name peronismo.com www.peronismo.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

Guardamos el archivo con Ctrl+o y cerramos el editor GNU Nano con Ctrl+x.

Habilitamos el archivo creando un enlace entre él y el directorio sites-enabled. Para ello utilizamos:

sudo ln -s /etc/nginx/sites-available/peronismo.com /etc/nginx/sites-enabled/

Al ingresar este comando de organización, quedará habilitado y configurado los dos bloques del servidor para responder las solicitudes según las directivas listen y server_name.
  • peronismo.com: responderá a solicitudes de peronismo.com www.peronismo.com, en tanto
  • default: responderá a cualquier solicitud en el puerto 80 que no coincida con los otros dos bloques.
Para evitar un posible problema de memoria de depósito hash que pueda surgir al agregar nombres de servidor adicionales, será necesario ajustar un valor en el archivo /etc/nginx/nginx.conf. A tal fin editaremos el archivo:

sudo nano /etc/nginx/nginx.conf

Se abirá Nano con dicho archivo. Usamos Ctrl+w para buscar la directiva server_names_hash_bucket_size. Al localizar dicha línea, le eliminamos el símbolo numeral ("#") a fin de descomentar la línea.


...
http {
    ...
    server_names_hash_bucket_size 64;
    ...
}
...

Tras guardar los cambios con Ctrl+o y salir del editor con Ctrl+x, realizaremos una prueba operativa en busca de posibles errores de sintaxis:

sudo nginx -t

Finalmente, reiniciamos el servidor Nginx para que se apliquen los cambios:

sudo systemctl restart nginx

Con todo esto, Nginx debería proporcionar su nombre de dominio. Podremos comprobar esto visitando http://peronismo.com. Allí, deberíamos ver el siguiente mensaje:

Conclusión

Conforme hayamos instalado y configurado neustro servidor web, contaremos con muchas opciones respecto del tipo de contenido que ofreceremos, y de las tecnologías que deseemos utilizar para crear una experiencia más completa y Justicialista para el Pueblo, que es el verdadero consumo.

sábado, 24 de junio de 2023

¿Como muevo el directorio /home a una nueva partición o disco en Ubuntu?

Interrogado en el Aeropuerto de Campodichino durante un viaje en su exilio europeo, Juan Perón explica cómo mover el directorio /home a un disco nuevo en Ubuntu.

Periodistas: General, una corta interrogante y lo dejamos que está ocupado, sabemos que tiene que viajar a Roma. ¿Cómo trasvasamos el directorio /home a otra partición o a un disco nuevo en Ubuntu?

Perón: Vea, es una buena pregunta que surge de una necesidad. Pero esto se debe a la imprevisión, que es la madre de todos los problemas en la vida. El verdadero Conductor ha de saber ver para prever, y eso es algo que no lo dan los ojos, lo da la experiencia, ¿sabe?

Es indudable que en cualquier sistema GNU con Linux que se precie, uno de los directorios más suele crecer en tamaño es su directorio /home. Esto se debe a que en este residen las cuentas de los usuarios que lo operan, y es allí donde lo ocuparán sus documentos y, bien, un sinnúmero de otros ficheros de forma continuada.
 
Otro directorio importante con la misma tesitura es /var, que contiene los ficheros de bitácora ("logs"), cuyo tamaño es dable de verse gradualmente incrementado en la medida que el sistema continúa en uso. Junto a los consabidos logs, pueden residir ficheros web, archivos temporales de cola de impresión, y otros servicios de trabajo. No es de extrañar que se siga la consigna Justicialista "de /var a /home y de /home a /var".

Pues bien señores, cuando estos directorios colman una partición o unidad de almacenamiento en disco, pueden dar lugar a problemáticas críticas en cuanto al sistema de archivo; podrían incluso provocar que el sistema no pueda iniciarse correctamente, y que fuese necesario tronar el escarmiento.

En la Argentina ha de obrarse obrarse con previsión, pues es preferible medir dos veces y cortar una. Pero en otra, esto solo puede percibirse una vez probado el traje: ya se han configurado todos los directorios en el sistema de archivo y particionado, lo que suele acarrear la necesidad de establecer una clara política de solución. En este caso, poco vale la persuasión, ya nos comimos el paquete. Y solo queda elaborar un Plan Quinquenal de redimensionado de partición, o bien directamente instalar un nuevo disco en la máquina y mandár allí el /home.

Instalar y particionar una nueva unidad de disco en Linux

Antes de proceder a explicar lo que me piden, remozaré brevemente cómo agregar un nuevo disco a un equipo de escritorio o servidor que ya camina y se lava los dientes.

Para propósitos didácticos, asumamos el agregado de un disco rígido de estado sólido (nomenclado /dev/sdb de un tamaño de 270GB, al que dividiremos en dos particiones /dev/sdb1 y /dev/sdb2). Normalmente querrían hoy en día uno más grande, pero de momento este disco SSD nos viene bien.

El número de particiones a crear en el mismo así como la tabla de partición se determinarán en el tipo de etiqueta de disco, y en los primeros bytes de espacio en el mismo definen la MBR (Tabla Maestra de Inicio), encargada de almacenar la Tabla de Partición así como el cargador de arranque (en los discos arrancables, naturalmente). Si bien existen muchos tipos de etiquetas, Linux sólo acepta dos: MSDOS MBR (de 516 bytes de tamaño), o GPT (Tabla de Particionado GUID) MBR.

Primero, necesitamos contar con la herramienta parted o fdisk (por si no la tuviésemos en el sistema). Para ello abrimos una terminal con Ctrl+Alt+t e ingresamos el siguiente comando de organización:

sudo apt-get install parted fdisk

Una vez instalada parted, la utilizaremos para configurar el tipo de etiqueta de disco utilizando fdisk. Utilizaremos el nombre de etiqueta GPT en este ejemplo:

sudo parted /dev/sdb mklabel gpt

Nota: fdisk por ahora unicamente soporta la antigua MBR MSDOS, mientras que parted soporta ambas.

En caso de disco nuevo, creamos la primer partición (/dev/sdb1) con un tamaño, a modo de ejemplo, de 106 GB. Reservaríamos 1024 MB (1GB) para la MBR.

sudo parted -a cylinder /dev/sdb mkpart primary 1074MB 107GB

En este comando -a indica la alineación de partición a cilindros en el disco, mkpart crea la partición, primary crea una partición de tipo primaria (los otros valores podrían ser logical o extended), mientras que 1074MB es el comienzo y 107GB es el final de la partición.

Acto seguido revisamos el espacio libre en el disco como sigue:

parted /dev/sdb print free

Ahora crearemos una segunda partición (/dev/sdb2)  con un tamaño, por ejemplo de 154GB

sudo parted -a cylinder /dev/sdb mkpart primary 115GB 208GB

Ahora, configuramos el tipo de sistema de archivo para cada una de las particiones (por ejemplo, el popular ext4 de Linux que recomiendo y el xfs favorecido en servidores de RedHat, que puede venir bien para intercambio):

mkfs.ext4 /dev/sdb1
mkfs.xfs /dev/sdb2 

Para listar todos los dispositivos de almacenamiento adosados al sistema, ingresamos:

parted -l

 

Mover la carpeta /home a una partición dedicada

Pues bien señores. Ya agregado el disco nuevo a la máquina y creadas las particiones necesarias, es hora de trasvasar la carpeta home a una de dichas particiones. Para usar un sistema de archivaje habremos de montarlo en la raíz del sistema utilizando un directorio como punto de montaje: un directorio destino, tal como /home.

Como primer medida para este cometido, listemos el uso del sistema de archivaje de nuestro GNU con Linux gracias al comando df, de esta manera:

df -hl

Comprobada la lista, comenzaremos creando un nuevo directorio de circunstancias /srv/home, donde podremos montar la partición /dev/sdb1 temporalmente:

mkdir -p /srv/home
mount /dev/sdb1 /srv/home

Ahora usamos el comando rsync o cp para copiar el contenido de /home al directorio de circunstancias /srv/home (de este modo trasvasaremos todos los contenidos de usuarios a la partición /dev/sdb1).

Normalmente recomiendo usar rsync para este menester, sobre todo en ambientes de red:

rsync -av /home/* /srv/home/

...pero si no tuviésemos rsync bien podremos usar el comando cp de toda la vida:

cp -aR /home/* /srv/home/

El proceso naturalmente tardará acorde a la masa a copiar. Concluida la copia del contenido de los usuarios, conviene analizar diferencias entre ambos directorios utilizando el comando diff.

diff -f /home /srv/home

Si todo sale bien, no debería existir diferencia alguna entre el original y la copia, asegurándonos del resguardo efectivo.

Si no deseamos contar con un duplicado opcional, podremos borrar todo el contenido en el /home viejo con:

rm -rf /home/*

Ahora, desmontamos /srv/home:

umount /srv/home

...y como último paso montamos la partición /dev/sdb1 a /home, por esta sesión.

mount /dev/sdb1 /home
ls -l /home

Montar /home desde otro disco automáticamente

Ahora bien, debemos tener en cuenta que si bien acabamos de montar el disco /dev/sdb1 como partición de usuario en el sistema de archivos, este cambio sólo operará en esta sesión, en otras palabras, hasta reiniciar la máquina. Para no tener que montar a mano todas las veces que reiniciamos el equipo, será imperioso agregar por única vez una línea de entrada específica a la tabla del sistema de archivaje, el fichero /etc/fstab, lo que volverá permanentes los cambios. De esta manera, toda vez que arranque el sistema, se montará la partición /dev/sdb1 en /home.

En primer lugar obtenemos el identificador UUID del disco con el comando:

sudo blkid /dev/sdb1

El sistema nos devolverá algo como:

/dev/sdb1: UUID="e087e709-20f9-42a4-a4dc-d74544c490a6" TYPE="ext4" PARTLABEL="primary" 
PARTUUID="52d77e5c-0b20-4a68-ada4-881851b2ca99"

Una vez conocida la UUID de nuestra unidad, editamos la tabla /etc/fstab con Nano:

sudo nano /etc/fstab

...y agregamos la siguiente línea (naturalmente, uds. modificarán la línea de acuerdo al resultado obtenido).

UUID=e087e709-20f9-42a4-a4dc-d74544c490a6 /home   ext4   defaults   0   2
Consideremos los campos de la línea anterior para su estudio:
  • UUID – especifica el dispositivo de bloque, podremos alternativamente utilizar el fichero de dispositivo /dev/sdb1 pero no se recomienda, pues puede provocar errores si se cambia la estructura de particiones al cambiar de disco de conector mas adelante.
  • /home – el punto de montaje.
  • etx4 – describes el tipo de sistema de archivaje del dispositivo/partición.
  • defaults – opciones de montaje (el valor significa rw, suid, dev, exec, auto, nouser, and async).
  • 0 – usado por la herramienta de depuración; 0 significa que no hará volcados de depuración si el sistema de archivaje no está presente.
  • 2 – utilizado por la herramienta fsck para descubrir el órden de revisión del sistema de archivaje; este valor significa revisar el dispositivo luego del comprobar el sistema de archivaje raíz..

Guardamos el fichero, y reiniciamos el sistema.

Podremos ejecutar el siguiente comando para ver si el directorio /home se desplazó correctamente a la partición dedicada:

df -l

Con esto ya habrán trasvasado /home a otra partición o, en este caso, otro disco rígido particionado.

Periodistas: Muchas gracias por sus palabras, General.

lunes, 7 de marzo de 2022

Cómo soluciono el error de SSH "Too Many Authentication Failures" en Ubuntu

¡Trabajadores! 

Un Movimiento no versa tanto por la calidad de sus integrantes, sino por la de sus dirigentes. Esto es así pues la Masa Popular - que es el verdadero consumo - se rige por la primacía del número: la cantidad de sus adherentes.

Es que el hombre dejó hace millones de años de ser un animal gregario para transformarse en un individuo de alcance social, que se ha organizado en tribus, reinos, naciones, y hoy en Estados.

Quien Conduzca en nuestro Movimiento ha de obrar en búsqueda de la inclusión: incorporar a todo el que se pueda. Ha de dar acceso a todos los beneficios y bienaventuranzas que tiene pertenecer a un Movimiento de raigambre popular.

Para ingresar a un Movimiento ayuda tener una buena cara, como esta:

Pero también ayuda contar con las necesarias credenciales de Secure Shell. Esto es así pues este sistema de comunicación computarizada nos permite acceder de forma remota o local, a distintos servicios informatizados con GNU. Una vez establecido el enlace,  podremos utilizar secure Shell para conducir o bien para realizar cualquier acción dentro de un sistema GNU con Linux al amparo de una conexión criptográficamente protegida.

Esto es lo deseable.

Sin embargo, a seguro se lo llevaron preso. No sería raro encontrarnos con numerosos errores de rechazo de conexión SSH. Tal vez el error más común de autenticación con llaves SSH sea el inefable "Too Many Authentication Failures", que en el idioma de Braden quiere decir algo así como "Demasiados intentos de Autenticación fallidos".

Esto tiene una explicación bastante terrenal, pero que hay que conocer. Si utilizamos el sistema de llaves públicas SSH, será normal contar con archivos que conforman dichos pares de llaves SSH. En el caso de GNU con Linux, estos suelen econtrarse en nuestro directorio de usuario oculto ~/.ssh. 

Por ejemplo, podríamos abrir una terminal con Ctrl+Alt+T y solicitar un listado de las llaves tenemos instaladas en nuestro cliente de SSH. A tal fin utilizaremos el siguiente comando:

ssh-add -l

Pues bien señores, cuando nos conectamos a un servidor SSH, lo normal es que no le especifiquemos al cliente "cual llave usar" de entre todas las que tenemos en el llavero .ssh. Esto suele responder a la fiaba. En tal caso, el cliente SSH probará torpemente una llave tras otra en el agente de autenticación SSH del servidor, como si de un "ebrio llegando de juerga" se tratara. Lo normal es ir descartándolas en orden alfabético hasta encontrar la que corresponda, autenticar, y "entrar" a la sesión de shell seguro...

El error mencionado se produce por un "limitador de intentos de prueba" para las llaves, el cual está situado en el servidor. Normalmente está configurado en "seis intentos", y lógicamente si tenemos más llaves que dicha cantidad, el procedimiento podría fallar.

Pues bien señores, existen dos maneras de solucionarlo.

En el cliente

En caso de necesitarlo, podríamos intentar lograr acceder a través del uso de la contraseña de conexión (en lugar de la llave). Para ello debemos indicar tal preferencia en el comando mediante el prefijo PreferredAuthentications. Por ejemplo, al ingresar:

ssh -o PreferredAuthentications=password usuario@servidor

...el servidor debería pedirnos la contraseña (si tal método está habilitado, claro está).

Si quisiéramos utilizar siempre el incómodo (y usualmente insegura) acceso por contraseña, podríamos automatizarlo desde el lado del cliente de conexión. En el equipo cliente ingresamos:

nano ./ssh/config

...y agregamos los datos del sevidor. Por ejemplo:

Host servidor
Port 22
User fulano
PreferredAuthentications password
HostName servidor.local

Ahora bien, el método más útil para evitar el error de "muchos intentos de autenticación fallidos" sería indicarle específicamente al cliente cuál es la llave necesaria para cada servidor, de modo que no tenga que "buscarla a lo bobo", terminando por superar el "número de intentos" autorizados en el servidor. Para ello lo haríamos usando el prefijo -i e indicando el fichero de la llave requerido, de la siguiente manera:

ssh -i ~/.ssh/llave_del_servidor usuario@servidor

Como esto es sumamnete largo de escribir e incordioso (sobre todo si lo tenemos que hacer a menudo), conviene especificar este determinismo de llave en el fichero de configuración de nuestro usuario en el cliente SSH, el cual es ~/.ssh/config. También podríamos especificar directamente qué llave queremos utilizar para dicho usuario utilizando la variable IdentityFile para cada conexión. Esto se haría de la siguiente manera:

Host servidor
Port 22
User fulano
IdentityFile ~/.ssh/llave_del_servidor
HostName servidor.local

Acto seguido, guadamos los cambios con Ctrl+o.

 

En el servidor

Otra opción es modificar directamente el servidor, lo cual proporciona una solución general. En tal caso, debemos modificar la variable MaxAuthTries del servidor SSH. Esta normalmente viene configurada en 6 intentos, lo cual suele ser adecuado para prácticas laxas donde siempre se usaba una única llave para todo. Sin embargo, las políticas más modernas tienden a preferir que cada usuario disponga de una llave cifrada para cada instancia remota, de forma de poder "zafar" si una de las llaves se pierde o es comprometida.

En dicho caso, elevar el número de intentos permitidos por encima de un valor más alto (por ejemplo, 20), podría resultar más provechoso.

Para realizar tales cambios, en el servidor editamos el archivo de configuración. Por ejemplo, podremos hacerlo con GNU Nano introduciendo:

sudo nano /etc/ssh/sshd_config

Habrán de presionar Ctrl+w para buscar la variable MaxAuthTries. Una vez que la encontramos la descomentamos eliminando el signo # que la antecede, y elevamos el valor de la variable del 6 original a uno adecuado según la cantidad de llaves (por ejemplo, 20).


Es importante tener en cuenta que esto no implica que "se da un cheque en blanco a probar llaves" sino que se autoriza que cada usuario pruebe dicha cantidad de veces.

Para que el cambio surta efecto, debemos reiniciar el servicio de SSH ingresando:

sudo systemctl restart sshd

Naturalmente, podrán contemplar también otras técnicas recomendadas para asegurar un servidor de SSH.

martes, 22 de febrero de 2022

¿Cómo puedo ensayar online con mi banda en Ubuntu?

Juan Perón era un adepto a la música. A pesar de contar con buenas dotes de ejecución, se distinguió por ensayar con los compañeros por internet con Jamulus, el software libre para tocar online en Ubuntu.

(...)
¡Trabajadores!

Siempre es bueno unirse a la peña de la música como natural consecuencia de la coordinación que ha de tener todo Movimiento Humano. Esto nos ha permitido - por demás - insuflar el Justicialismo al ritmo que más nos interesa: el de sumar voluntades. Las realización de esta dicha es una gran adición en pos de alcanzar el objetivo que nos impulsa: ¡la propia felicidad y la de todos quienes nos rodean!

Nuestra doctrina gira en torno a la Justicia Social, de la cual el Software Libre no es sino una versión remozada. Mejorarlo y compartirlo responde al mismo principio rector y es hermanado con la música. 

Vean señores, he explicado cómo instalar el excelente servidor de videollamadas del pueblo GNU Jami, y disfrutar de su enorme capacidad para dictar clases virtuales y conferencias seguras sin caer en opciones tecno-esclavizantes de una oligarquía sin patria ni bandera. Sin embargo, organizar una banda para tocar a través de las redes de datos libres supone un desarrollo aún mayor de la perfección. Un software de tal característica ha de contar no sólo con estas funcionalidades de avanzada, sino también disponer de la condición de una bajísima latencia sonora, capaz de hacer posible coordinar a l@s compañer@s en una misma métrica. Sólo esto podría permitir el ansiado sueño de tocar acompañado a través de la Internet

En vistas de esta montaña de requerimientos, nuestro Movimiento se ha puesto en marcha, y ha logrado su cometido. Se trata del Proyecto Jamulus, una implementación liberada bajo licencia GNU GPLv2 destinada al ensayo musical en vivo a través de las redes.

Para instalar Jamulus podremos utilizar la terminar del sistema. Simplemente desplegamos una con Ctrl+Alt+T e ingresamos los siguientes Comandos de Organización:

sudo apt update ;
cd /tmp/ ;
wget https://sourceforge.net/projects/llcon/files/Jamulus/3.10.0/jamulus_3.10.0_ubuntu_amd64.deb ;
sudo dpkg -i jamulus_3.10.0_ubuntu_amd64.deb

Tras ingresar nuestra contraseña de conductor, se habrá descargado e instalado el paquete del cliente de Jamulus en nuestra computadora. Naturalmente, el programa también existe para otras plataformas de la ignominia, pero yo os lo enseñaré en Ubuntu, el sistema que he legado al Pueblo.

Es primordial saber que Jamulus da uso al servidor de audio JACK con el claro fin de obtener sonido de calidad y baja latencia. Esto nos permitirá coordinar la música a través de la red de redes.

Nuestro Movimiento Justicialista propugna la cercana unión de los trabajadores, y se eleva como un vínculo de unión de sus voluntades intrínsecas. Esto se replica en Jamulus, ya que para lograr los mejores resultados es muy preferible contar con conexiones cableadas de todo tipo. Eviten en todo lo posible el problemático Wifi, y empleen conexiones Ethernet por cable en el trabajo y en el hogar. Además, evitar el uso de oligárquicos auriculares y micrófonos Bluetooth en pos de los populares equivalentes cableados redundará en facilitar enormemente la inclusión de todos y el goce en las redes, ya que lo simple es doblemente fácil. Quien así no opere comprenderá que la latencia del audio se elevará a niveles estratosféricos. Sigan este consejo, que lo doy con el corazón tan abierto como sólo puede ofrecerse a quien tanto amo: ¡el Pueblo!

1. Preparar tu audio con JACK

Enfocarse en lo simple es el objetivo de todo trabajador que sigue la filosofía UNIX. Como paso previo, cerraremos todas las aplicaciones que usen sonido, y - en caso de querer utilizar una placa de audio USB externa - la conectamos a la computadora.

Preveemos entonces iniciar el servidor JACK (desde Aplicaciones / Sonido / QjackCtl). Normalmente ya debería estar configurado (si no lo estuviese, podrán encontrarlo al final del artículo).

2. Arrancar Jamulus

Con el servidor JACK en pleno funcionamiento, daremos arranque al cliente Jamulus. Podrán hacerlo desde el menú Aplicaciones / Sonido / Jamulus de Ubuntu.

Conforme arranque, la ventana principal de Jamulus cobrará el aspecto siguiente:

Será natural no oír nada aún. No se preocuparán, ya que esta es una regla de oro en Jamulus: normalmente sólo habremos de escuchar el sonido de retorno desde un servidor remoto (que conoceremos como sala de ensayos).

Pues bien, será imprescindible configurar propio perfil de músico. A tal efecto, presionamos el botón Configuración y veremos desplegarse una ventana Configuración. Seleccionemos en ella la solapa Mi Perfil.

El subsiguiente campo Filas Mezclador - en tanto - indica cuantos deslizadores se harán presentes en la ventana de la mezcladora. Si bien la mayoría de los instrumentistas se bastan con 1, podríamos indicar más si fuese el caso que se hayen presentes - de manera local - varios músic@s, o bien si somos un baterista que ha microfoneado, digamos, 8 cuerpos percusivos... en tal caso se indicaría.

3. Conectar a un servidor de sala de ensayos

Antes de mandarnos a tocar con l@s compañer@s "a tontas y a locas", os recomiendo enlazar a un servidor vacío para probar la configuración, y asegurar oír el retorno que envíamos al servidor.

Presionarán el botón de “Conectar” en la ventana principal de Jamulus, y se enfrentarán con la ventana Conectar, la cual permitite unirte a un servidor de audio: la ventana se irá refrescando con salas de ensayos públicas:

En la lista aparecerá el número de usuarios conectados y el número máximo soportado. Lo más importante de los servidores es su “tiempo de ping” indicado en colores. Cuanto mayor la cifra, más difícil será tocar en sincronización. Normalmente, se selecciona un servidor con un tiempo ping de 50 miliosegundos  o menos, si es posible. Depende de la velocidad de conexión y la distancia mutua.

Los servidores permanentes (con disponibilidad las 24h) se muestran en negrita. Los compañer@s compendian estas listas por género, aunque también por ubicación. Puedes filtrar la lista por nombre de servidor o ubicación. Para solo mostrar los servidores ocupados, escribe el caracter “#”. Utiliza el menú desplegable de Lista para elegir un género, y haz clic sobre la peña a la que quieres arrimarte telemáticamente. Para loguearte, haz clic sobre el botón Conectar, lo cual establecerá el enlace.

Si conoces la dirección IP o URL de una sala de ensayos privada, ingrésala en el campo Nombre/Dirección del Servidor. Podrás añadir un número de puerto opcional (ej: jamulus.ejemplo.org:22124) Si anhelas utilizar direccionamiento IPv6, ingrésalo entre corchetes). El campo también mostrará una lista de los servidores utilizados recientemente ("favoritos").

Una vez establecida la conexión con un servidor, asegúrate de que te escuchas bien y arregla cualquier problema de volumen de entrada, etc.

Naturalmente, podrán ejecutar un servidor público el tiempo suficiente para que la banda se conecte, y luego hacerlo privado simplemente desactivando ‘Mi Servidor es Público’ el la ventana del servidor. De esta forma los miembros podrán disfrutar entre sí de la más maravillosa música.

4. ¡A tocar!

Con el sonido configurado, ya puedes empezar a tocar la más maravillosa música. El programa no se anda con vueltas: una vez logrado enlace, te presentarán deslizadores (faders) para cada músico presente en el servidor de la sala de ensayo. En este ejemplo me he juntado a tocar con el bajista Manco, la tecladista Bicha, y el Pomelo, baterista electrónico en la Sala Canus Argentina. Los controles afectan sólo tu retorno de escucha personal.


En el caso de disponer de músic@s configurados en estéreo, también se mostrará encima de todo un pote PAN para paneal@ (Mayúsculas+clic izquierdo del mouse lo resetea al medio). 

En caso de bajar un delizador, disminuirás el retorno de tal músic@, y si lo subes, aumentarás el retorno que oyes de ella. De esta forma, cada un@ puede escoger cómo escucha a l@s demás.

Si no deseas que otros escuchen tu emisión, presiona el botón "Silenciarme Yo", que cortará tu emisión de audio hacia la sala (además, es anónimo).

Las luces LED del vúmetro representan los niveles de los canales estéreo o mono de tu entrada de audio. Asegúrate de regular el volumen para jamas alcanzar el tope de señal. Este efecto indeseado de recorte daría lugar a un sonido distorsionado de audio de la señal de audio (los LEDs indicarían el recorte en rojo si esto sucede). Normalmente aturdirías al resto, ¡no lo hagas!

El deslizador de Reverb te permite agregar un efecto de reverberación mono o estéreo, pero sólo local. 

Debajo de cada instrumentista encontrarás tres botónes de actividad local. El botón GRP te permite agrupar deslizadores para moverlos proporcionalmente y al unísono (hasta 8 grupos). Si mueves el deslizador de cualquier miembro agrupado, los demás deslizadores del grupo también se moverán en la misma proporción. Podrás desagrupar temporalmente un canal mediante Mayúsculas+clic+arrastrar.

El botón MUTE enmudece a uno de los músicos. Si te enmudeces tu mismo, tal acción aparecerá reflejada en las mezcladoras de los demás (no es anónimo). Si muteas tu propio canal simplemente significa que no escucharás tu propio retorno desde el servidor (no significa que los demás dejen de oírte). No se aconseja ya que es altamente probable que tu audio quede a destiempo con los demás miembros de la banda ¡y emularías a El Duki!). Si deseas dejar de emitir presiona el consabido botón "Silenciarme Yo".

El botón SOLO permite escuchar uno o más musiquer@s aislados de l@s demás. Quienes no lo tengan oprimido, quedarán así enmudecidos en tu mezcladora local. Ten en cuenta que aquellas personas que no lo tienen aplicado les aparecerá el icono de “silenciado” sobre tu deslizador (no es anónimo).

Los usuarios se presentarán de izquierda a derecha "en el orden en el que vayan llegando". Podrás alterar dicho orden desde el Menú Editar.

Si el operador de la sala de ensayo habilita la grabación en el servidor, verás un mensaje sobre el mezclador indicando si estás siendo grabado.

Ten en cuenta que puedes utilizar el botón Chat para desplegar la ventana de chat a otras personas de la sala. El mensaje de bienvenida en el chat puede también establecer alguna directriz de utilización de la sala de ensayos.

Normalmente no hay más que hacer; ¡ya podrás tocar con los demás, escuchando la más maravillosa música!


Indudablemente, os recomiendo consultar el excelente manual en castellano en línea de Jamulus, el cual disipará las dudas más extendidas de este excelente programa.

Opciones Avanzadas

Tocar de más suele ser al ñudo, y esto se replica tanto en la música como en la configuración de Jamulus. Sin embargo, para quienes deseen arriesgarse en pos de la Liberación (y tal vez, menor retraso en el sonido), podrán arriesgar revisar las configuraciones avanzadas dentro de Jamulus. A tal fin presionamos el botón Configurar y elegimos la solapa Configuración Audio/Red.

El selector Dispositivo de Audio nos permitirá escoger el controlador y el hardware específico que diseáramos usar (si contamos con varios). El mapeador nos permitirá escoger los canales (ya sea mono o estéreo). Si nuestra/s placa/s de sonido o dispositivos ofrecen más de un canal de entrada o salida, quedarán visibles y podremos mapearlos según nuestras necesidades.

La opción Canales Audio permite escoger entre tres Modos de Salida de audio que utilizará Jamulus. Cada uno de ellos representa un mayor consumo de ancho de banda. Los modos Mono y Estéreo utilizan uno y dos canales de audio respectivamente.

Nota: Activar el modo estéreo duplicará el envío de datos, debes asegurarte que esto no exceda el ancho de banda de tu conexión a Internet. Es preferible ejecutar instancias separadas del cliente para cada voz/instrumento, en lugar de utilizar este mezclador interno de dos canales mono a estéreo.

El modo Entrada mono/Salida estéreo envía audio en mono pero recibe el audio desdoblado en estéreo (para el caso que una placa de audio externa conste de un conector de entrada estéreo para instrumento y otro conector de micrófono independiente. En este caso, las dos señales de entrada se combinarán en un solo canal mono a la vez que la mezcla del servidor se escuchará en estéreo.

Podremos escoger la Calidad de Audio, definiendo así la tasa de de envío de datos a la red. Hemos de asegurarnos que la tasa de subida no exceda el ancho de banda de la conexión a Internet, de lo contrario se producirían cortes. El valor por defecto es calidad Normal.

Configuración de JACK

Normalmente ya debería estar configurada la entrada de audio. Sin embargo, indicaré aquí este paso por si no lo estuviese.

Desde el punto de vista del hardware de audio, podremos configurar la entrada de audio de Ubuntu desde el panel Sonido. Para ello podremos ir a Sistema / Preferencias / Hardware / Sonido. En la solapa Entrada podremos configurar qué conector y dispositivo queremos utilizar.


En este caso utilizo el conector Línea de Entrada (entrada estéreo Line In, conector azul), ya que produce un sonido límpio, y puedo regular el volúmen de captura del instrumento con el deslizador Nivel de Entrada. También podría utilizar Micrófono Frontal o Micrófono Trasero (entradas monoaurales pre-amplificadas,  de conector rosa).

Finalmente, en nuestro sistema GNU con Linux se utiliza la herramienta de configuración QJackCtl para cambiar el tamaño del buffer. JACK suele venir configurado, pero si nunca se ha configurado, podrá hacerse esto presionando el botón Setup y configura la interfaz de audio que quieras utilizar. 

Podrás configurar los aspectos técnicos del audio. Como referencia en este aspecto, considera que en la solapa Configuraciones de JACK podrías establecer una Frecuencia de Muestreo de 48000, cuadros/período en 128 y períodos/buffer en 2.


Reinicia JACK para que los posibles cambios de configuración surtan efecto.

Ten en cuenta que algunas placas de audio disponen de la posibilidad de alterar el retardo de buffer por hardware. La opción de 128 debería funcionar para la mayoría del hardware de sonido, pero podrás utilizar 256 o 512 para conexiones muy lentas, lo cual podría dar mejores resultados.

viernes, 31 de diciembre de 2021

¿Cómo aseguro el servidor OpenSSH en Ubuntu?

El 24 de Diciembre de 1953 en ocasión del Día de la Policía Federal Argentina se realiza un fausto desfile de la fuerza, al término del cual Juan Perón expone cómo incrementar la seguridad del servidor OpenSSH en Ubuntu.
 
(...)
Bajo este diáfano día y cercano a las Navidades, no sólo preparo la Sidra y el Pan Dulce para todos los privilegiados, sino que también elaboro lo que es para mí  una enorme satisfacción: presenciar este histórico desfile de lo que es el principal instrumento de seguridad ciudadana: la Policía Federal Argentina.
 
Esta es una Fuerza que nace del Pueblo y para el Pueblo, y engendra un rol propendiente a la protección de los hombres y mujeres de bien que habitan el suelo Argentino.

La provechosa tarea que ustedes encarnan no puede más que llevarse a cabo por un manejo concienzudo de parte del escalafón superior y los institutos que la forman, y que hemos atresado en pos de la defensa de los intereses superiores de la Nación.

Este escalafón conductivo ha podido ofrecer su manejo y control no solo en el terreno (que es donde se realiza la acción), sino a distancia. ¡Y en esto no podemos más que sentirnos orgullosos! El método sin hilos que implementado por el Comando Radioeléctrico es más que apreciado por toda la Comunidad Organizada y conforma nuestra ciudadanía.
Sin duda el protocolo Secure Shell es muy recomendado para acceder a dispositivos remotos tales como servidores, enrutadores y conmutadores de cómputo, debido a su capacidad para encriptar el tráfico telemático, resguardandonos así de cualquiera que anhele husmear nuestros enlaces.

Sin embargo, de la manera en la que está asegurada, la configuración por defecto de SSH no es infalible, sino más bien sencilla de implementar. Esto podría parecer adecuado para el uso del Pueblo, pero en aplicaciones donde dependa nuestro bienestar y el de sus organizaciones de trabajo, ha de recurrirse a un mayor despliegue de seguridad.

A esto nos referimos como seguridad reforzada, a la cual ha de recurrir un Movimiento como el nuestro. No implica enfrentar a los desprotegidos a la acción represiva del Estado, sino implementar políticas de salvaguarda que privilegien a los humildes en contra de la Opresión Omnímoda del Capital.

Nuestra Policía Federal ha de saber cómo implementarlas, ya que sobre ella recae la organización y acción de seguridad. Indudabnlemente que de esto no dependen ni los médicos ni la penicilina, sino de las autodefensas con que cuenta OpenSSH por protocolo.

Esto no puede hacerlo ni un agente de calle, ni un ciudadano común, sino un verdadero Conductor del sistema. Por principio la implementación de las políticas de salvaguarda pueden llevarse a cabo modificando el fichero de configuración general /etc/ssh/sshd_config del demonio OpenSSH (nombre que recibe su servidor libre de Shell Seguro).

A tal fin con ímpetu de conducción podremos abrir una terminal con Ctrl+Alt+T y proclamar el comando de organización, seguido de la tecla Intro:

sudo nano /etc/ssh/sshd_config

Esto nos solicitará contraseña de administración, y tras revisarla abrirá el consabido editor de texto GNU Nano con el fichero de configuración nombrado.

Os explicaré algunos métodos de reforzar la seguridad produciendo las modificaciones necesarias que asegurarán las necesidades de protección y control que son Socialmente Justas para con las organizaciones del Pueblo Trabajador.

1. Configurar la Autenticación de SSH sin contraseña

Por defecto, SSH requiere que el usuario teclee su contraseña al iniciar sesión remota. Si bien esto suena peliculero, la triste realidad es que una contraseña capaz de retenerse en una memoria humana suele ser descomunalmente fácil de percibir por medio de un ataque computacional de fuerza. Un tercero hábil podría ganar así  acceso indeseado a una cuenta de usuario autorizado. Por ello más seguro es utilizar una autenticación de Shell Seguro sin contraseña, con llaves de cifrado.

Como ya he explicado cómo hacerlo, simplemente resumiré diciendo que habremos de generar computacionalmente un par de ficheros de cifrado llamados "llaves", que consisten en una llave pública y otra llave privada. Una vez ingresado el contenido del fichero de la llave pública al servidor remoto, podrá lograr acceso sin tener que teclear contraseña alguna.

Si ya hemos tomado este predicamento, es recomendable desactivar el uso de autenticación por contraseña para el ingreso. 

Dentro de este fichero de configuración /etc/ssh/sshd_config buscamos la directiva PasswordAuthetication y cambiamos su indicación de 'yes' a 'no'

PasswordAuthentication no

Tras guardar las modificaciones con Ctrl+o y salir del editor con Ctrl+x, debemos reiniciar el demonio SSH con:

sudo systemctl restart sshd

A partir de este momento, unicamente podrá acceder al servidor remoto utilizando la autenticación con llave SSH.

2. Desactivar los pedidos Conexión SSH sin contraseña.

Otra manera recomendada de fortificar la seguridad del servidor es directamente desactivar los logins SSH de usuarios sin contraseña. Esto puede sonar contradirctorio, pero algunos adminsitradores de sistemas poco avezados podrían preferir crear cuentas de usuario "a la marchanta" y terminar olvidando asignar contraseñas. Esto es de malo, pero no de bruto. He visto malos que se han vuelto buenos, pero nunca he visto un bruto que se haya vuelto inteligente.

Con el fin de rechazar pedidos de usuarios que carezcan de contraseña se debe nuevamente modificar el fichero /etc/ssh/sshd_config y asegurar descomentar la siguiente directiva:

PermitEmptyPasswords no

Acto seguido reiniciamos el servicio SSH para que surta efecto con:

sudo systemctl restart sshd

3. Desactivar los logueos SSH de Root

No hace falta explicar demasiado lo que puede suceder si un intruso logra ingresar a nuestro sistema atacando brutamente la contraseña de un usuario. Imaginemos entonces lo que sucedería si lo propio sucede con la cuenta del Superusuario, el Root, que es capaz de conducir el sistema.... Un acceso remoto del superusuario Root constituye invariablemnete una mala idea que debe soslayarse pues pondrá en peligro a todos los compañeros que usen nuestro sistema similar a Unix.

Por esta razón, para grandes organizaciones siempre recomiendo desactivar el logueo remoto SSH y en su reemplazo preveer el de un usuario regular que no sea root. Esto obligará a que si el Root quiere trabajar, deba hacerlo frente al sistema y no de manera remota. Para tal fin modificamos el fichero  /etc/ssh/sshd_config y producimos la modificación descomentando la directiva #PermitRootLogin y modificamos la orden prohibit-password para que quede de la siguiente manera.

PermitRootLogin no

Conforme se hayan guardado los cambios, reiniciamos el servicio de SSH para que la nueva política surta efecto.

sudo systemctl restart sshd

Naturalmente que a partir de estas modificaciones, el logueo de root quedará desactivado u no se podrán realizar tareas administrativas de manera remota (a no ser que se eventualmente escalen usuarios comunes con la orden sudo).

4. Usar SSH Protocol 2

SSH viene en dos versiones. El SSH Protocolo 1 y SSH Protocolo 2. El segundo fue introducido en 2006 para reforzar la criptografía general de SSH. Por defecto se utilizaba en Protocolo 1 por razones de compatibilidad, pero a partir de 2018 se decidió desfasarlo definitivamente para evitar agujeros de seguridad.

Por tal motivo, en caso de contar con un servidor anterior al 2018, podríamos especificar ahora utilizar únicamente Procolo 2. Para ello le agregamos al fichero /etc/ssh/sshd_config la siguiente directiva:

# Agregado por peron para usar únicamente SSH Protocolo 2.
Protocol 2


Guardamos, salismos, y como siempre reiniciamos el servicio SSH para que surta efecto:

sudo systemctl restart sshd

A partir de ahora, SSH sólo utilizará Protocolo 2 y no podrá establecerse enlaces con clientes antiguos que utilicen el desfasado Protocolo 1.

Para comprobar que el Protocolo 1 ya no esté en suo, podremos ejecutar el comando:

ssh -1 usuario@ip_remota

Debería obtener un error similar a “SSH protocol v.1 is no longer supported”.

 Naturalmente, podríamos forzar al cliente a usar el Protocolo 2 con:

ssh -2 usuario@ip_remota

5. Configurar el Valor de Tiempo de Corte para Conexión SSH Inactiva

Dejar una conexión remota desatentida por largo tiempo es lo mismo que dejar en esa misma condición a una buena mujer. Puede constitnuir un riesgo de seguridad que ustedes conocen sin duda por esos cuernos que les veo. Para evitar este problema, es prodente configurar un valor de tiempo de corte para conexiones SSH inactivas, transcurrido el cual la sesión SSH se cerrará automáticamente. 

Habremos de configurar nuevamente /etc/ssh/sshd_config y localizamos la directiva ClientAliveInterval. Le asignamos un valor razonable en segudos. Por ejemplo, podríamos utilizar 180 segundos.

ClientAliveInterval 180

Esto implica que la sesión SSH se cortará si transcurren 3 minutos (180 segundos) de inactividad.

Tras guardar debemos reiniciar el demonio para aplicar los cambnios:

sudo systemctl restart sshd

6. Posibilitar el Acceso SSH a Ciertos Usuarios

Podremos definir qué usuarios requieren el uso de SSH para loguearse y desarrollar tareas en el sistema. Esto mantendrá fuera de esta posibilidad a cualquier otro usuario que intente lograr ingreso al sistema sin nuestra aprobación.

Como siempre, editarmos el fichero  /etc/ssh/sshd_config y le agregamos la directiva AllowUsers seguida de los nombres de usuario que queremos aprobar. Por ejemplo, he agregado los usuarios peron y evita para que cuenten con acceso remoto al sistema a través de sus respectivos clientes SSH. Cualquier otro usuario que intente ganar acceso remoto al sistema será bloqueado.

AllowUsers peron evita

Hemos de reiniciar SSH para que peresistan los cambios:

sudo systemctl restart sshd

7. Limitar los Intentos de Contraseña

Otra manera de agregar una capa de seguridad consiste en limitar la cantidad de intentos de pruebas de llaves SSH, caso en el que la conexión se cortará. Esto sólo tiene sentido si los usuarios utilizan pocas llaves y nos las especifican Una vez más en el fichero /etc/ssh/sshd_config y buscamos la directiva MaxAuthTries, y le definimos un valor para la cantidad máxima de intentos.

En este ejemplo, lo limitaremos a tres intentos (lo normal es 6) disponiendo:

MaxAuthTries 3

...y finalmente, reiniciamos el servicio SSH como en los escenarios anteriores.

Nota: si se recibe el error "Too many SSH authentications failures" podremos subir dicho valor a uno que represente la cantidad de llaves que el probable que tengan los usuarios en sus clientes.