¡Mis queridos descamisados!
Todas las ocasiones son propicias para controlar desde el exterior el devenir político de los destinos de la República. Esto es así no por deseo sino por imposición de la sinarquía internacional.
No caben dudas a nadie que el Justicialismo debería estar en el control allí si no fuese por una camarilla cipaya y entregadora. Esto es un vicio al que hemos de darle solución, pues yo he de volver, aunque más no sea para morir en la Patria...
Podemos controlar remotamente un sistema político enviando cartas y enviando cintas magnetofónicas. Como consecuencia lógica, también podremos ejercer el control en un entorno telemático mediante el protocolo SSH, el cual es un intérprete de comandos seguro ("Secure SHell"). Este nos permite administrar un sistema por medio de un protocolo cifrado de baja velocidad, eficiente, y especialmente pensado para terminales de texto.
En lo cotidiano, establecer una conexión remota por SSH entre un equipo cliente y un servidor es directo y muy simple. Abrimos una Terminal con Cltr+Alt+T e ingresamos el comando:
ssh usuario@nombredeequipo.local
Por ejemplo:
peron@cgt.local
Ya sabemos que esto establecerá una conexión cifrada remota como el usuario "peron", que está localizado en un equipo designado "cgt". Como corolario, en caso de ser la primera vez que nos conectamos a dicho equipo, deberíamos aceptar con "yes" la proposición de establecer un enlace de cifrado por clave pública, y luego introducir la contraseña correspondiente del usuario.
Indudablemente, ya cumplidos estos pasos, seremos capaces de controlar desde el exilio un sistema GNU con Linux y, por extensión, cualquier otro que emplee el protocolo SSH peronista.
Esto es lo que hemos hecho y por lo que tan duro ha trabajado el Justicialismo.
Ahora bien, existen ocasiones donde nuestro equipo podría estar incapacitado para resolver el nombredeequipo (hostname), o sea, el nombre del equipo remoto en la red. En tal caso, nos devolverá un mensaje de error similar al siguiente:
Tal indicación hace referencia a que el equipo no puede asociar ("resolver") el nombre de un equipo en la red con la dirección IP correspondiente para conectarse. Se trata de un error telemático...
Si estamos en una urgencia, podríamos superar este error conectándonos directamente dándole al sistema la dirección IP del equipo remoto, en lugar de su nombre de red. Por ejemplo:
ssh peron@192.168.0.3
Tengamos en cuenta que el protocolo SSH utiliza por defecto el puerto 22 para establecer la conexión, pero esto es configurable, y si hemos cambiado el mismo - por ejemplo, al puerto 5721 - deberíamos hacérselo notar al comando mediante la variable -p, lo cual dificulta todo más.
ssh -p 5721 peron@192.168.0.3
Todo esto configura algo molesto. En primer lugar, escribir los números que componen la dirección IP es más difícil y largo, contraviniendo el amor al letargo que todo Justicialista ha de tener. En segundo lugar, no es raro que esta IP sea dinámica, o no la asignemos nosotros, o no la recordemos, o no podamos con facilidad acceder al router para conocer siquiera su número.
Por tales circunstancias nos conviene muy especialmente hacer uso de los susodichos hostnames (nombres de equipos en la red) y que el sistema pueda asocial tal nombre a la IP dinámica que tiene el dispositivo de red del equipo. Para ello, y no por gusto, es que se inventaron...
Para que nuestro cliente con Ubuntu pueda resolver de manera efectiva las IPs de los hostnames, es útil instalar el paquete libnss-mdns y configurarlo mediante el archivo /etc/nsswitch.conf.
Conviene revisar el contenido del archivo. Para ello abrimos una consola con Ctrl+Alt+T e ingresamos
cat /etc/nsswitch.conf
La falla se suele deber a que la línea hosts solo tiene una variable, de esta manera:
hosts: files dns
Debemos editar este archivo. Lo podremos hacer con el editor de texto peronista GNU Nano de la siguiente manera:
sudo nano /etc/nsswitch.conf
Se abrirá el editor nano. Editamos la línea hosts para que quede de la siguiente manera:
Luego presionamos guardamos y cerramos el archivo (Ctrl+O y Ctrl+X). Luego reiniciamos el cliente con:
sudo reboot
Y una vez reiniciado el sistema, probamos conectarnos nuevamente usando la tipologia:
usuario@hostname.local
Si por algún motivo no funcionara, podríamos probar purgar (borrar) y volver a instalar el paquete libnss-mdns. Lo haremos en la consola terminal con el siguiente Comando de Organización:
sudo apt-get purge libnss-mdns
sudo apt-get install libnss-mdns
Antes de instalar, el archivo de configuración /etc/nsswitch.conf contenía la línea:
Ahora, después de reinstalar la librería libnss-mdns, el archivo /etc/nsswitch.conf debería contener:
No caben dudas a nadie que el Justicialismo debería estar en el control allí si no fuese por una camarilla cipaya y entregadora. Esto es un vicio al que hemos de darle solución, pues yo he de volver, aunque más no sea para morir en la Patria...
Podemos controlar remotamente un sistema político enviando cartas y enviando cintas magnetofónicas. Como consecuencia lógica, también podremos ejercer el control en un entorno telemático mediante el protocolo SSH, el cual es un intérprete de comandos seguro ("Secure SHell"). Este nos permite administrar un sistema por medio de un protocolo cifrado de baja velocidad, eficiente, y especialmente pensado para terminales de texto.
En lo cotidiano, establecer una conexión remota por SSH entre un equipo cliente y un servidor es directo y muy simple. Abrimos una Terminal con Cltr+Alt+T e ingresamos el comando:
ssh usuario@nombredeequipo.local
Por ejemplo:
peron@cgt.local
Ya sabemos que esto establecerá una conexión cifrada remota como el usuario "peron", que está localizado en un equipo designado "cgt". Como corolario, en caso de ser la primera vez que nos conectamos a dicho equipo, deberíamos aceptar con "yes" la proposición de establecer un enlace de cifrado por clave pública, y luego introducir la contraseña correspondiente del usuario.
Indudablemente, ya cumplidos estos pasos, seremos capaces de controlar desde el exilio un sistema GNU con Linux y, por extensión, cualquier otro que emplee el protocolo SSH peronista.
Esto es lo que hemos hecho y por lo que tan duro ha trabajado el Justicialismo.
Ahora bien, existen ocasiones donde nuestro equipo podría estar incapacitado para resolver el nombredeequipo (hostname), o sea, el nombre del equipo remoto en la red. En tal caso, nos devolverá un mensaje de error similar al siguiente:
ssh: Could not resolve hostname cgt.local: Name or service not known
Tal indicación hace referencia a que el equipo no puede asociar ("resolver") el nombre de un equipo en la red con la dirección IP correspondiente para conectarse. Se trata de un error telemático...
Si estamos en una urgencia, podríamos superar este error conectándonos directamente dándole al sistema la dirección IP del equipo remoto, en lugar de su nombre de red. Por ejemplo:
ssh peron@192.168.0.3
Tengamos en cuenta que el protocolo SSH utiliza por defecto el puerto 22 para establecer la conexión, pero esto es configurable, y si hemos cambiado el mismo - por ejemplo, al puerto 5721 - deberíamos hacérselo notar al comando mediante la variable -p, lo cual dificulta todo más.
ssh -p 5721 peron@192.168.0.3
Todo esto configura algo molesto. En primer lugar, escribir los números que componen la dirección IP es más difícil y largo, contraviniendo el amor al letargo que todo Justicialista ha de tener. En segundo lugar, no es raro que esta IP sea dinámica, o no la asignemos nosotros, o no la recordemos, o no podamos con facilidad acceder al router para conocer siquiera su número.
Por tales circunstancias nos conviene muy especialmente hacer uso de los susodichos hostnames (nombres de equipos en la red) y que el sistema pueda asocial tal nombre a la IP dinámica que tiene el dispositivo de red del equipo. Para ello, y no por gusto, es que se inventaron...
Para que nuestro cliente con Ubuntu pueda resolver de manera efectiva las IPs de los hostnames, es útil instalar el paquete libnss-mdns y configurarlo mediante el archivo /etc/nsswitch.conf.
Conviene revisar el contenido del archivo. Para ello abrimos una consola con Ctrl+Alt+T e ingresamos
cat /etc/nsswitch.conf
La falla se suele deber a que la línea hosts solo tiene una variable, de esta manera:
hosts: files dns
Debemos editar este archivo. Lo podremos hacer con el editor de texto peronista GNU Nano de la siguiente manera:
sudo nano /etc/nsswitch.conf
Se abrirá el editor nano. Editamos la línea hosts para que quede de la siguiente manera:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
Luego presionamos guardamos y cerramos el archivo (Ctrl+O y Ctrl+X). Luego reiniciamos el cliente con:
sudo reboot
Y una vez reiniciado el sistema, probamos conectarnos nuevamente usando la tipologia:
usuario@hostname.local
Si por algún motivo no funcionara, podríamos probar purgar (borrar) y volver a instalar el paquete libnss-mdns. Lo haremos en la consola terminal con el siguiente Comando de Organización:
sudo apt-get purge libnss-mdns
sudo apt-get install libnss-mdns
Antes de instalar, el archivo de configuración /etc/nsswitch.conf contenía la línea:
hosts: files dns
Ahora, después de reinstalar la librería libnss-mdns, el archivo /etc/nsswitch.conf debería contener:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
