login en consola (sin display manager)

fundamentos GNU/Linux  fun-gnu


loginTodas la distros vienen por defecto con un gestor de pantalla (display manager) donde, como mínimo, hacer el login (usuario y contraseña) y en algunos casos elegir tipo de sesión a iniciar (qué entorno de escritorio arrancar).

Los gestores de pantalla más conocidos son:

GDM (Gnome Display Manager)
KDM (KDE Display Manager)
LXDM (Gestor de inicio de sesión de LXDE)

además de MDM, LightDM, SDDM, Slim, etc.

Esta forma de logarse (¡qué palabro!) en el sistema puede ser bonita y gráfica, pero a mí personalmente no me vale para nada, el ordenador tarda más en arrancar y el proceso consume memoria RAM.

Si quieres que el equipo arranque en modo consola y hacer el login en el shell directamente, y tu equipo funciona con systemd, haz lo siguiente:

1. si no está ya instalado, instala el paquete xinit de tu distribución (lo necesitaremos para arrancar). Puede que se llame xinit, xorg-xinit, o algo que contenga xinit, depende de la distro).

2. en tu home (home/pepito/) debes de crear, si no lo hay, un archivo que se llame .xinitrc (como ves por el punto es un archivo oculto).

3. la configuración básica del archivo .xinitrc es esta: exec sesión-a-arrancar

por ejemplo:

exec startxfce4 (arranca XFCE)
exec gnome-session (arranca Gnome)
exec startkde (arranca KDE)
exec cinnamon-session (arranca Cinnamon)
exec startlxde (arranca LXDE)
exec mate-session (arranca MATE)

.xinitrc lógicamente admite configuraciones más complejas, en las que aquí no podemos entrar. En una configuración básica para arrancar un único entorno de escritorio instalado, basta con que contenga una línea como esta (que es mi caso para arrancar mi XFCE de Manjaro):

exec startxfce4

Pues ya tenemos configurado nuestro xinit para arrancar en consola, sólo nos resta deshabilitar nuestro display manager con sistemd.
1. método ostodoxo:

en un terminal hacemos:

sudo systemctl disable display-manager.service

(si nuestro gestor de pantalla es por ejemplo GDM, también podríamos hacer:

sudo systemctl disable gdm.service
2. método heterodoxo:

Nota: este método no gustará a los puritanos linuxeros, pero a mí me gusta usarlo con el fin de tener registrado un control de cambios en las configuraciones de hago. Nunca me ha gustado hacer las cosas como se dice que hay que hacer las cosas. Soy así.

entramos como root en el directorio: /etc/systemd/system/

vemos que ahí está un enlace simbólico que se llama display-manager.service y que apunta a (en mi caso) /usr/lib/systemd/system/gdm.service que lo que hace, lógicamente, es cargar en el arranque GDM.

yo lo que hago es crear una capeta en /etc/systemd/system/ que se llama NO, así:
/etc/systemd/system/NO/

y dentro de ella meto el enlace simbólico display-manager.service, por lo que al arrancar no estará donde debe, y por lo tanto no apuntará a GDM y, por lo tanto, no arrancará GDM  🙂

y ya está, sólo tienes que reiniciar el sistema y verás que no arranca ningún login manager gráfico.
Te encontrarás la bonita, pura y prístina pantalla negra del shell, que te pide un nombre de usuario y la contraseña.
Una vez logueado (¡cielo santo, qué palabro!) sólo te resta teclear:

startx

(startx es el comando de xinit que arrancará el entorno de escritorio que hayamos definido en nuestro .xinitrc)

y eureka, arrancará tu entorno de escritorio sin estúpidos intermediarios gráficos.

Sólo para los que aman la pureza de la consola y su cursor parpadeante…

el PATH, la ruta de LINUX (variables de entorno)

fundamentos GNU/Linux fun-gnu


rura66[Actualizado: añadido al final cómo agregar una ruta al PATH.]

Cuando abres un terminal en linux, por defecto estás en tu home  /home/pepito/
podemos verlo así:

$ pwd
/home/pepito

(pwd= print work directory)

y si tecleo un comando, lo cual llama a un programa ejecutable (un binario), como por ejemplo “ls” que lista los directorios y archivos que hay en ese directorio, ¿cómo sabe el sistema operativo dónde está ese binario para ejecutarlo?. La respuesta es, gracias al PATH.

El PATH (el camino, la ruta) es una variable de entorno. Las variables de entorno contienen información a la que se accede a través del nombre de la variable (al igual que ocurre en los lenguajes de programación).

Por ejemplo, PWD es una variable de entorno. Algo que puedo comprobar así:

$ echo $PWD
/home/pepito

(lo que significa que el comando “pwd” es una llamada a “echo $PWD”

Para consultar todas mis variables de entorno puedo hacer:

$ env

me listará todas las variables definidas en el sistema.

Algunas variables importantes:

SHELL=/bin/bash      (el tipo de shell en uso)
TERM=xterm      (el programa de terminal por defecto)
USER=pepito      (el nombre de usuario)
PWD=/home/pepito      (la ruta por defecto del usuario)
LANG=es_ES.utf8      (el juego de caracteres de idioma)
DESKTOP_SESSION=xfce      (el entorno de escritorio)
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin      (el PATH)

puedo consultar el valor de cualquier variable definida mediante el comando echo y el nombre (normalmente en mayúscula) de la variable con el signo dólar “$” delante, así:

$ echo $USER
pepito

El PATH, es tal vez la variable de entorno más importante.

El PATH informa al shell (en la mayoría de los casos BASH) dónde se encuentran los programas binarios que puedo ejecutar en el sistema, sin tener que llamarlos por su ruta absoluta).

por ejemplo, el programa “ls” está en /usr/bin/ls
algo que puedo saber gracias la comando whereis:

$ whereis ls
ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz /usr/share/man/man1/ls.1p.gz

(me informa de dónde reside el binario “ls” así como sus páginas man)

esto significa que puedo llamar al comando “ls” de manera absoluta así:

$ /usr/bin/ls      (responderá de manera adecuada)

pero si llamo a “ls” directamente:

$ ls

responderá igual, gracias a que tengo definida su ruta en el PATH, como puedo ver así:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

vemos que separados por dos puntos, están las rutas donde buscar binarios (en ese orden). He aquí la respuesta a porqué el sistema operativo sabe donde está el binario de un comando. Eureka!

¿Dónde están los archivos de configuración del PATH?

los archivos globales del sistema están en:

etc/profile
etc/profile.d/
etc/bashrc  o  etc/bash.bashrc

(estos se aplican para todos los usuarios si no definen los propios en ~/)

y los archivos del espacio de usuario:

~/.bashrc
~/.bash_profile

¿Cómo añado una ruta al PATH?

Pues lo más cómodo, si tengo un binario que no está en el PATH y lo quiero añadir, es hacerlo en mi espacio de usuario, en mi home. Lo primero miramos cómo está el PATH ahora:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

imaginemos que nuestro binario que no está en el PATH está aquí:

/opt/tacata/

pues sólo hay que añadir esa ruta de directorio al PATH. Editamos

nano /home/pepito/.bashrc

y le añadimos estas dos líneas:

PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/tacata/"

export PATH

que como vemos es el PATH anterior más la nueva ruta (se separan con dos puntos) y al final la orden “export PATH” que vale para que se use ese PATH.

Y ya está, ya podremos llamar al ejecutable que hay dentro de /opt/tacata/

desde cualquier consola o terminal sin tener que llamar a la ruta absoluta.

Pues ya sabes; caminante no hay camino, se hace camino al andar.

touch, echo y operadores de redirección

fundamentos GNU/Linux fun-gnu


hoy en día creamos carpetas y archivos en nuestro gestor de archivos preferido (Nautilus, Nemo, Thunar, etc):

clic botón derecho -> crear carpeta nueva  o  clic botón derecho -> crear documento nuevo -> archivo vacío

los usuarios de Linux suelen conocer el comando de creación de directorios mkdir pero, ¿cómo se crea en consola un archivo vacío?

touch

touch, realmente, es un comando que sirve para modificar la marca temporal de un archivo, pero resulta muy útil para crear un archivo vacío, así:

touch nombre-archivo

y ya tendremos en el directorio en que estemos un bonito archivo vacío llamado nombre-archivo

touch archivo1 archivo2 “archivo de Pepito”  (creará esos tres archivos vacíos)

echo

es un hecho que el comando echo parece un poco tonto:

echo La vida es bella, dicen

La vida es bella, dicen   (muestra en la consola el texto que escribamos después de él)

[paciencia, ahora después veremos un uso más interesante de echo]

operadores de redirección  >  y  >>

el signo matemático “mayor que” > es un interesante operador para redirigir la salida estándar de consola a un archivo, así:

echo La vida es bella, dicen > “La vida”

producirá el bonito resultado de crear un archivo llamado La vida, en cuya primera línea se lea La vida es bella, dicen (observese que he puesto entre comillas el nombre del archivo “La vida”, pues contiene un espacio; sin espacios, no sería necesario).

[ahora echo ha servido para algo más que para hacer el bobo]

Ejemplillo útil: supongamos que en nuestro /etc no tenemos un archivo llamado “hostname” que contiene únicamente el nombre de mi máquina (host) en la primera línea. Pues:

sudo echo hal9000 > /etc/hostname

y ya tenemos como nombre de nuestra máquina hal9000 (lo cual suele verse en el prompt así  juan@hal9000 $ )

pero imaginemos que de pronto se nos cruzan los cables y odiamos 2001 Una Odisea del Espacio y decidimos amar a la maternal computadora de la nave Nostromo de Alien. Pues nada:

sudo echo madre > /etc/hostname

y como el operador de redirección “>” sombreescribe el archivo si existe, pues ya no estamos en Hal9000 sino en Madre, así:  juan@madre $

finalmente, si en vez de usar el operador de redirección “mayor que” simple, lo usamos doble “>>“:

(recordemos que ya teníamos un archivo llamado “La vida” que contenía una primera línea que decía: La vida es bella, dicen)

ahora podemos hacer esto:

echo menos cuando un Alien cabroncete se cuela en tu nave >> “La vida”

el resultado será que nuestro (ya amado) archivo llamado La vida, ahora contiene 2 líneas:

La vida es bella, dicen
menos cuando un Alien cabroncete se cuela en tu nave

¿y tú, eres más de Hal9000 o de Madre?

hal  nostromo