lunes, 30 de noviembre de 2015

¿Qúe archivos podríamos modificar?

Como regla general, para añadir directorios a tu PATH, o definir variables de entorno adicionales, coloca dichos cambios en .bash_profile (o equivalente, según tu distribución. Por ejemplo, Ubuntu usa .profile.) Para todo lo demás, coloca los cambios en .bashrc. A menos que seas el administrador del sistema y necesites cambiar los predefinidos para todos los usuarios del sistema, reduce tus modificaciones a los archivos de tu directorio home. En realidad es posible cambiar los archivos en /etc, como el archivo profile, y en muchos casos sería sensato hacerlo, pero por ahora, juguemos con seguridad.

viernes, 27 de noviembre de 2015

Modificando el entorno

Como ya sabemos dónde están los archivos de arranque y qué contienen, podemos modificarlos para personalizar nuestro entorno.

miércoles, 25 de noviembre de 2015

¿Qué hay en un archivo de arranque?

Si miramos dentro de un archivo .bash_profile típico (tomado de un sistema CentOS 4), vemos algo así:

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin
export PATH

Las líneas que empiezan con un “#” son comentarios y no son leídas por el shell. Son para que sean legibles por personas. La primera cosa interesante ocurre en la cuarta línea, con el siguiente código:

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

Esto se llama un comando if compuesto, que veremos más en profundidad cuando lleguemos al scripting de shell en la Parte 4, pero por ahora lo traduciremos:

Si el archivo "~/.bashrc" existe, entonces
    lee el archivo "~/.bashrc".

Podemos ver que este fragmento de código es la forma en que un shell con login toma los contenidos de .bashrc. Lo siguiente en nuestro archivo de arranque tiene que ver con la variable PATH.

¿Te has preguntado alguna vez, cómo sabe el shell dónde encontrar los comandos cuando los introducimos en la línea de comandos? Por ejemplo, cuando introducimos ls, el shell no busca en todo el ordenador para encontrar /bin/ls (la ruta completa del comando ls), en su lugar, busca en una lista de directorios que están contenidos en la variable PATH.

La variable PATH a menudo (pero no siempre, depende de la distribución) es establecida por el archivo de arranque /etc/profile con este código:

PATH=$PATH:$HOME/bin

PATH se modifica para añadir el directorio $HOME/bin al final de la lista. Esto es un ejemplo de expansión con parámetros, como vimos en el Capítulo 7. Para demostrar como funciona, prueba lo siguiente:

[me@linuxbox ~]$ foo="This is some "
[me@linuxbox ~]$ echo $foo
This is some
[me@linuxbox ~]$ foo=$foo"text."
[me@linuxbox ~]$ echo $foo
This is some text.

Usando esta técnica, podemos añadir texto al final de los contenidos de una variable.

Añadiendo la cadena $HOME/bin al final del contenido de la variable PATH, el directorio $HOME/bin se añade a la lista de directorios a buscar cuando se introduce un comando. Esto significa que cuando queremos crear un directorio dentro de nuestro directorio home para almacenar nuestros programas privados, el shell está preparado para contenerlos. Todo lo que tenemos que hacer es llamarlo bin, y estamos listos para empezar.

Nota: Muchas distribuciones proveen esta configuración de PATH por defecto. Algunas distribuciones basadas en Debian, como Ubuntu, buscan la existencia del directorio ~/bin en el login, y dinámicamente lo añaden a la variable PATH si encuentran el directorio.

Finalmente, tenemos:

export PATH

El comando export le dice al shell que haga que los contenidos de PATH estén disponibles para los procesos hijos de este shell.

lunes, 23 de noviembre de 2015

¿Cómo se establece el entorno?

Cuando nos identificamos en el sistema, el programa bash arranca, y lee una serie de scripts de configuración llamados archivos de arranque (startup files), que definen el entorno por defecto compartido para todos los usuarios. A continuación se leen más archivos de arranque en tu directorio home que definen tu entorno personal. La secuencia exacta depende del tipo de sesión de shell que se inicie. Hay dos tipos: sesión de shell con login y sesión de shell sin login.

Una sesión de shell con login es aquella en la que nos preguntan nuestro nombre de usuario y contraseña; por ejemplo, cuando arrancamos una sesión de consola virtual. Un sesión de shell sin login es la que típicamente se da cuando arrancamos una sesión de terminal en la GUI.

Los shell con login leen uno o más archivos de arranque como se muestra en la Tabla 11-2:

Tabla 11-2: Archivos de arranque para sesiones de shell con login
Archivo Contenidos
/etc/profile Un script de configuración global que se aplica a todos los usuarios.
~/.bash_profile Un archivo de arranque personal del usuario. Puede utilizarse para extender o anular configuraciones del script de configuración global.
~/.bash_login Si ~/.bash_profile no se encuentra, bash intenta leer este script.
~/.profile Si no se encuentran ni ~/.bash_profile ni ~/.bash_login, bash intenta leer este archivo. Este es el que viene por defecto en las distribuciones basadas en Debian, como Ubuntu.

Las sesiones de shell sin login leen los siguientes archivos de arranque:

Tabla 11-3: Archivos de arranque para sesiones de shell sin login
Archivo Contenidos
/etc/bash.bashrc Un script de configuración global que se aplica a todos los usuarios.
~/.bashrc Un archivo de arranque personal del usuario. Puede usarse para extender o anular las configuraciones del script de configuración global.

Además de leer los anteriores archivos de arranque, los shells sin login también heredan el entorno de sus procesos padre, normalmente un shell con login.

Echa un vistazo a tu sistema y mira cuales de estos archivos de arranque tienes. Recuerda, como la mayoría de los archivos listados anteriormente empiezan con un punto (que significa que están ocultos), necesitarás usar la opción “-a” cuando uses ls.

El archivo ~/.bashrc es probablemente el archivo de arranque más importante desde el punto de vista de un usuario normal, ya que casi siempre se lee. Los shell sin login lo leen por defecto y la mayoría de archivos de arranque para los shell con login se escriben de forma que también lean el archivo ~/.bashrc.

viernes, 20 de noviembre de 2015

Algunas variables interesantes

El entorno contiene bastantes variables, sin embargo tu entorno puede diferir del presentado aquí, verás más o menos las siguientes variables en tu entorno:

Tabla 11-1: Variables de entorno
Variable Contenidos
DISPLAY El nombre de tu pantalla si estás corriendo un entorno gráfico. Normalmente es “:0”, que significa la primera pantalla generada por el servidor X.
EDITOR El nombre del programa que se usa para editar texto.
SHELL El nombre de tu programa de shell
HOME La ruta de tu directorio home.
LANG Define la configuración de caracteres y la secuencia de ordenado de tu idioma.
OLD_PWD El anterior directorio de trabajo.
PAGER El nombre del programa que se usa para paginar la salida. A menudo está establecido en /usr/bin/less.
PATH Una lista de directorios, separados entre sí por dos puntos ":", en la que se busca cuando introduces el nombre de un programa ejecutable.
PS1 Prompt String 1. Define el contenido de tu prompt de shell. Como veremos más tarde, puede ser ampliamente personalizado.
PWD El directorio de trabajo actual.
TERM El nombre de tu tipo de terminal. Los sistemas tipo Unix soportan muchos protocolos de terminal; esta variable establece el protocolo que se va a usar con tu emulador de terminal.
TZ Especifica tu zona horaria. La mayoría de los sistemas tipo Unix mantienen un reloj interno en el ordenador en Coordinated Universal Time (UTC) y luego muestran la hora local aplicando un desfase especificado por esta variable.
USER Tu nombre de usuario.

No te preocupes si algunas de estas variables faltan. Varían según la distribución.

miércoles, 18 de noviembre de 2015

Examinando el entorno

Para ver qué hay almacenado en el entorno, podemos usar el comando integrado en bash set o el programa printenv. El comando set nos mostrará tanto las variables del shell como las del entorno, mientras que printenv sólo mostrará estas últimas. Como nuestra lista de contenidos del entorno será muy larga, es mejor canalizar la salida de cualquiera de los comandos a less:

[me@linuxbox ~]$ printenv | less

Hacíendolo, deberíamos obtener algo parecido a esto:

KDE_MULTIHEAD=false
SSH_AGENT_PID=6666
HOSTNAME=linuxbox
GPG_AGENT_INFO=/tmp/gpg-PdOt7g/S.gpg-agent:6689:1
SHELL=/bin/bash
TERM=xtermXDG_MENU_PREFIX=kde-
HISTSIZE=1000
XDG_SESSION_COOKIE=6d7b05c65846c3eaf3101b0046bd2b00-
1208521990.996705-1177056199
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/me/.gtkrc-
2.0:/home/me/.kde/share/config/gtkrc-2.0
GTK_RC_FILES=/etc/gtk/gtkrc:/home/me/.gtkrc:/home/me/.kde/share/config/gtkrc
GS_LIB=/home/me/.fonts
WINDOWID=29360136
QTDIR=/usr/lib/qt-3.3
QTINC=/usr/lib/qt-3.3/include
KDE_FULL_SESSION=true
USER=me
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe:

Lo que vemos es una lista de las variables de entorno y sus valores. Por ejemplo, vemos una variable llamada USER, que contiene el valor “me”. El comando printenv puede listar también el valor de una variable específica:

[me@linuxbox ~]$ printenv USER
me

El comando set, cuando lo usamos sin opciones o argumentos, mostrará tanto las variables del shell como las del entorno, así como cualquier función definida del shell. Al contrario de printenv, su salida está cortésmente ordenada alfabéticamente:

[me@linuxbox ~]$ set | less

También es posible ver el contenido de una variable usando el comando echo, así:

[me@linuxbox ~]$ echo $HOME
/home/me

Un elemento del entorno que ni set ni printenv muestran son los alias. Para verlos, introduce el comando alias sin argumentos:

[me@linuxbox ~]$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

lunes, 16 de noviembre de 2015

¿Qué se almacena en el entorno?

El shell almacena dos tipos básicos de datos en el entorno, sin embargo, con bash, los dos tipos son casi indistinguibles. Hay variables de entorno y variables de shell. Las variables de shell son bits de datos puestos allí por bash, y las variables de entorno son básicamente todo lo demás. Además de las variables, el shell también almacena algunos datos programáticos, llamados alias y funciones de shell. Vimos los alias en el Capítulo 5, y las funciones de shell (que están relacionadas con los scripts de shell) las veremos en la Parte 4.

viernes, 13 de noviembre de 2015

El entorno

Como vimos antes, el shell mantiene una cantidad de información durante nuestra sesión de shell llamada el entorno. Los datos almacenados en el entorno los usan los programas para determinar cosas acerca de nuestra configuración. Si bien la mayoría de programas usan archivos de configuración para almacenar las configuraciones del programa, algunos programas también buscan valores almacenados en el entorno para ajustar su comportamiento. Sabiendo esto, podemos usar el entorno para personalizar nuestra experiencia con el shell.

En este capítulo, trabajaremos con los siguientes comandos:
  • printenv – Imprime parte o todo el entorno
  • set – Establece opciones del shell
  • export – Exporta el entorno a los programas que se ejecuten a continuación
  • alias – Crea un alias para un comando

miércoles, 11 de noviembre de 2015

Resumiendo

Los sistemas más modernos proporcionan un mecanismo para gestionar múltiples procesos. Linux provee un rico catálogo de herramientas para este propósito. Dado que Linux es el sistema operativo de servidores más expandido en el mundo, esto tiene mucho sentido. Sin embargo, al contrario que otros sistemas, Linux se basa principalmente en herramientas de línea de comandos para la gestión de procesos. Aunque hay herramientas gráficas para procesos en Linux, las herramientas de línea comandos son ampliamente preferidas por su velocidad y ligereza. Aunque las herramientas de la GUI son más bonitas, a menudo crean una gran carga en el sistema, con lo que estropean su propósito.

lunes, 9 de noviembre de 2015

Más comandos relacionados con procesos

Cómo monitorizar procesos es una tarea importante para la administración de sistemas, hay muchos comandos para ello. Aquí tenemos algunos para jugar con ellos:

Tabla 10-6: Otros comandos relacionados con procesos
Comando Descripción
pstree Muestra una lista de procesos dispuestos en una estructura de árbol mostrando las relaciones padre/hijo entre los procesos.
vmstat Muestra una instantánea de los recursos de sistema usados, incluyendo memoria, intercambio (swap) y la E/S del disco. Para una visualización continua, añade al comando un periodo de tiempo (en segundos) para las actualizaciones. Por ejemplo: vmstat 5. Finaliza la salida con Ctrl-c.
xload Un programa gráfico que traza un gráfico mostrando la carga del sistema a lo largo del tiempo.
tload Igual que el programa xload, pero dibuja el gráfico en el terminal. Finaliza la salida con Ctrl-c.

viernes, 6 de noviembre de 2015

Enviando señales a múltiples procesos con killall

También es posible enviar señales a múltiples procesos eligiendo un programa específico o un nombre de usuario usando el comando killall. Aquí tenemos la sintaxis:

killall [-u user] [-signal] name...

Para demostrarlo, iniciaremos un par de instancias del programa xlogo y las finalizaremos:

[me@linuxbox ~]$ xlogo &
[1] 18801
[me@linuxbox ~]$ xlogo &
[2] 18802
[me@linuxbox ~]$ killall xlogo
[1]-  Terminated              xlogo
[2]+  Terminated              xlogo

Recuerda, como con kill, debes tener privilegios de superusuario para enviar señales a procesos que no te pertenecen.

miércoles, 4 de noviembre de 2015

Enviando señales a un proceso con kill

El comando kill se usa para enviar señales a programas. Su sintaxis más común es así:

kill [-signal] PID...

Si no se especifican señales en la línea de comandos, la señal TERM (Terminar) se envía por defecto. El comando kill se usa la mayoría de las veces para enviar las siguientes señales:

Tabla 10-4: Señales comunes
Número Nombre Significado
1 HUP Colgar. Es un vestigio de los buenos y viejos tiempos cuando los terminales estaban conectados a ordenadores remotos mediante líneas telefónicas y modems. La señal se usa para indicar a los programas que el terminal de control ha “colgado”. El efecto de esta señal puede demostrarse cerrando una sesión de terminal. El programa en primer plano, que está corriendo en el terminal, recibirá una señal y terminará.

Esta señal también se usa con muchos programas demonio para provocar una reinicialización. Esto significa que cuando se le envía esta señal a un demonio, se reiniciará y releerá su archivo de configuración. El servidor web Apache es un ejemplo de demonio que usa la señal HUP de esta forma.
2 INT Interrupción. Realiza la misma función que las teclas Ctrl-c enviadas desde el terminal. Normalmente termina un programa.
9 KILL Mata. Esta señal es especial. Mientras que los programas pueden elegir manejar las señales que les son enviadas de diferentes formas, incluso ignorarlas todas, la señal KILL realmente nunca se envía al programa objetivo. En su lugar, el kernel inmediatamente termina el proceso. Cuando un proceso es finalizado de esta forma, no se le da la oportunidad de “limpiar” o guardar su trabajo. Por esta razón, la señal KILL sólo debería ser utilizada como último recurso cuando otras señales de finalización fallan.
15 TERM Terminar. Esta es la señal por defecto enviada por el comando kill. Si un programa aún está lo suficientemente “vivo” como para recibir señales, se terminará.
18 CONT Continuar. Esta restaurará un proceso después de una señal STOP.
19 STOP Parar. Esta señal causa la pausa de un proceso sin terminarlo. Al igual que la señal KILL, no se envía al proceso objetivo, y por lo tanto no puede ser ignorada.

Probemos el comando kill:

[me@linuxbox ~]$ xlogo &
[1] 13546
[me@linuxbox ~]$ kill -1 13546
[1]+  Hangup                  xlogo

En este ejemplo, arrancamos el programa xlogo en segundo plano y luego le enviamos una señal HUP con kill. El programa xlogo termina y el shell indica que el proceso en segundo plano ha recibido una señal de cuelgue. Necesitarás pulsar la tecla intro un par de veces antes de ver el mensaje. Fíjate que las señales pueden ser especificadas con número o con nombre, incluyendo el nombre precedido de las letras “SIG”:

[me@linuxbox ~]$ xlogo &
[1] 13601
[me@linuxbox ~]$ kill -INT 13601
[1]+  Interrupt               xlogo
[me@linuxbox ~]$ xlogo &
[1] 13608
[me@linuxbox ~]$ kill -SIGINT 13608
[1]+  Interrupt               xlogo

Repite el ejemplo anterior y prueba las otras señales. Recuerda, también puedes usar jobspecs en lugar de PIDs.

Los procesos, como los archivos, tienen propietarios, y debes ser el propietario de un proceso (o el superusuario) para enviarle señales con kill.

Además de la lista de señales anterior, usadas generalmente con kill, hay otras señales usadas frecuentemente por el sistema. Aquí tenemos una lista de otras señales comunes:

Tabla 10-5: Otras señales comunes
Número Nombre Significado
3 QUIT Abandonar.
11 SEGV Violación de segmentación (Segmentation Violation). Esta señal se envía si un programa hace un uso ilegal de la memoria, es decir, trata de escribir en un sitio en el que no está autorizado.
20 TSTP Stop de terminal (Terminal Stop). Esta es la señal enviada por el terminal cuando se pulsa Ctrl-z. Al contrario que la señal STOP, el programa recibe la señal TSTP, pero puede optar por ignorarla.
28 WINCH Cambio de ventana (Window Change). Es una señal enviada por el sistema cuando una ventana cambia de tamaño. Algunos programas, como top y less responden a esta señal redibujándose a sí mismos para ajustarse a las nuevas dimensiones de la ventana.

Para los curiosos, se puede ver una lista completa de las señales con el siguiente comando:

[me@linuxbox ~]$ kill -l

lunes, 2 de noviembre de 2015

Señales

El comando kill se usa para matar procesos. Esto nos permite terminar programas que necesitan ser matados. Aquí tenemos un ejemplo:

[me@linuxbox ~]$ xlogo &
[1] 28401
[me@linuxbox ~]$ kill 28401
[1]+  Terminated                  xlogo

Primero arrancamos xlogo en segundo plano. El shell muestra el jobspec y el PID del proceso en segundo plano. A continuación, usamos el comando kill y especificamos el PID del proceso que queremos terminar. También podríamos haber especificado el proceso usando un jobspec (por ejemplo, “%1”) en lugar de un PID.

Aunque esto es todo muy sencillo, hay mucho más al respecto. El comando kill no "mata" exactamente los procesos, en su lugar les manda señales. Las señales son una de las diversas formas con que el sistema operativo se comunica con los programas. Ya hemos visto señales en acción con el uso de Ctrl-c y Ctrl-z. Cuando un terminal recibe una de estas pulsaciones de teclado, manda una señal al programa en primer plano. En el caso de Ctrl-c, se manda una señal llamada INT (Interrupción); con Ctrl-z, una señal llamada TSTP (Terminal Stop). Los programas, a su vez, “escuchan” las señales y las utilizan según las van recibiendo. El hecho de que un programa pueda escuchar y actuar mediante señales permite que el programa haga cosas como guardar el trabajo en proceso cuando se le envía una señal de terminación.