Si hay algo que cualquier administrador de sistemas tiene claro es que es imposible saberlo todo, lo que hay que saber es buscar. Los sistemas *nix cuentan con sistemas de ayuda integrados que nos explican al detalle las funcionalidades de los comandos y servicios, sus ficheros de configuración, directivas, el modo de usarlos, etc.

Páginas man

Las páginas man (manual) nos ofrecen toda esta información detallada, su modo de uso es el siguiente:

$ man COMANDO

Si por ejemplo quisieramos ver la ayuda del comando grep ejecutaríamos lo siguiente:

$ man grep

Una vez dentro, siempre tendremos unas secciones claramente diferenciadas como por ejemplo NAME, SYNOPSIS, DESCRIPTION, etc. Si tenéis conocimientos básicos de vim podréis navegar a través de ellas del mismo modo que en el editor. Para movernos usaremos las teclas de desplazamiento, para buscar ESC + / + cadena a buscar, tecla ‘n’ para movernos entre los resultados, etc.

A la hora de acceder a las páginas man tenemos la posibilidad de acceder directamente a la sección X, si quisieramos acceder a la sección 3 de la página man de grep:

$ man 3 grep

Las secciones para BSD, Unix y Linux son las siguientes:

1. Comandos disponibles
2. Llamadas Unix y C del sistema
3. Rutinas en C para programas en C
4. Nombres de fichero especiales
5. Formatos de fichero y convenciones para ficheros usados por Unix
6. Juegos y salvapantallas
7. Paquetes de procesamiento de palabras
8. Procedimientos y comandos para administradores de sistemas

También podemos buscar en las páginas man a través de palabras clave mediante el parámetro -k seguido de las palabras:

$ man -k regexp
regexp_table (5)     - format of Postfix regular expression tables

Y para ficheros de configuración el parámetro -f:

$ man -f resolv.conf

El comando apropos

Ya hablé hace tiempo de él, entrad aquí para más información: apropos: buscador de comandos en la shell

Comando seguido de –help ó -?

Si a cualquier comando le añadís el parámetro

ó -? recibiréis ayuda por pantalla sobre el mismo. Un ejemplo de la ayuda del comando ps:

$ ps --help
********* simple selection *********  ********* selection by list *********
-A all processes                      -C by command name
-N negate selection                   -G by real group ID (supports names)
-a all w/ tty except session leaders  -U by real user ID (supports names)
-d all except session leaders         -g by session OR by effective group name
-e all processes                      -p by process ID
T  all processes on this terminal     -s processes in the sessions given
a  all w/ tty, including other users  -t by tty
g  OBSOLETE -- DO NOT USE             -u by effective user ID (supports names)
r  only running processes             U  processes for specified users
x  processes w/o controlling ttys     t  by tty
*********** output format **********  *********** long options ***********
-o,o user-defined  -f full            --Group --User --pid --cols --ppid
-j,j job control   s  signal          --group --user --sid --rows --info
-O,O preloaded -o  v  virtual memory  --cumulative --format --deselect
-l,l long          u  user-oriented   --sort --tty --forest --version
-F   extra full    X  registers       --heading --no-heading --context
                    ********* misc options *********
-V,V  show version      L  list format codes  f  ASCII art forest
-m,m,-L,-T,H  threads   S  children in sum    -y change -l format
-M,Z  security data     c  true command name  -c scheduling class
-w,w  wide output       n  numeric WCHAN,UID  -H process hierarchy

El comando whatis

También hablé de él en su día, pinchad aquí: whatis: Descubre para qué sirve un comando

El comando whereis

Comando también tratado en el blog: Whereis, encuentra binarios, sources o páginas de ayuda en Linux / Unix

¡Y si esto no es suficiente para encontrar la información que necesitáis siempre podéis recurrir a Google!

Cuando el nombre de una partición o volúmen es demasiado largo, al mostrarla con el comando df se crea un salto de línea para mantener la estructura de las columnas y tabulaciones:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      447G  6.3G  417G   2% /
/dev/sdb1             996M   39M  906M   5% /tmp
/dev/sda1              99M   24M   70M  26% /boot

Esto puede ser un problema en algunas ocasiones en las que queramos recoger los datos de la salida del comando. Para evitarlo, únicamente tenemos que utilizar el parámetro

y se respetará el nombre y el resto de información en la misma línea:

# df -hP
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  447G  6.3G  417G   2% /
/dev/sdb1             996M   39M  906M   5% /tmp
/dev/sda1              99M   24M   70M  26% /boot

Un truco simple que puede parecer una tontería pero es muy útil en ciertas ocasiones.

Hoy vamos a tratar de comprender las diferencias que existen en Unix / Linux entre los enlaces simbólicos (soft o symbolic links) y los enlaces duros (hard links).

Enlaces simbólicos (soft / symbolic links)

La manera más sencilla de comprender que es un enlace simbólico en Linux es compararlo con el “enlace directo” o “shortcut” en Windows. El fichero o directorio se encuentra en un único punto del disco y los enlaces son un puntero contra él. Cada enlace simbólico tiene su propio número de inodo lo que permite hacer enlaces simbólicos entre distintos sistemas de ficheros.

Para crear enlaces (tanto simbólicos como duros) usamos el comando ln. En este caso vamos a crear un enlace simbólico (parámetro

) del fichero test:

$ ln -s test enlace-a-test

Si listamos ambos veremos que el enlace tiene el carácter

que lo identifica como enlace simbólico:

$ ls -l
lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
-rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Para confirmar que el enlace simbólico tiene un inodo distinto usamos el comando stat:

$ stat test
  File: «test»
  Size: 0         	Blocks: 0          IO Block: 4096   archivo regular vacío
Device: 804h/2052d	Inode: 73793       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:58:53.124142406 +0200
Modify: 2011-04-27 18:58:53.124142406 +0200
Change: 2011-04-27 18:58:53.124142406 +0200

$ stat enlace-a-test
  File: «enlace-a-test» -> «test»
  Size: 4         	Blocks: 0          IO Block: 4096   vínculo simbólico
Device: 804h/2052d	Inode: 77212       Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:59:07.812139890 +0200
Modify: 2011-04-27 18:59:06.460112888 +0200
Change: 2011-04-27 18:59:06.460112888 +0200

También lo podemos verificar sacando el inodo en el ls (

):

$ ls -li
77212 lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
73793 -rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Hay que tener en cuenta, que en Linux / Unix (al igual que con los accesos directos de Windows), si borramos el fichero o directorio origen, el enlace simbólico permanece pero los datos desaparecen para siempre.
 

Enlaces duros (hard links)

Los enlaces duros lo que hacen es asociar dos o más ficheros compartiendo el mismo inodo. Esto hace que cada enlace duro es una copia exacta del resto de ficheros asociados, tanto de datos como de permisos, propietario, etc. Esto implica también que cuando se realicen cambios en uno de los enlaces o en el fichero este también se realizará en el resto de enlaces.

Los enlaces duros no pueden hacerse contra directorios y tampoco fuera del propio sistema de ficheros.

Vamos a crear un hard link contra el fichero “test” de antes y veremos que efectivamente comparten inodo y que los datos se sincronizan entre ambos:

$ ln test enlace-duro-test
$ ls -li
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 test

En la primera columna verificamos que tienen el mismo número de inodo y en la tercera se especifica cuando enlaces duros tiene el fichero. Si hacéis cambios en uno de ellos veréis que también se hacen en el resto. Si por ejemplo cambiamos los permisos al fichero test:

$ chmod 0755 test
$ ls -li
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 test

Y finalmente el stat de cada uno verifica todo lo que comentamos:

$ stat test
  File: «test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

$ stat enlace-duro-test
  File: «enlace-duro-test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

Diferencias entre soft y hard links

• Los enlaces simbólicos se pueden hacer con ficheros y directorios mientras que los duros solo entre ficheros.
• Los enlaces simbólicos se pueden hacer entre distintos sistemas de ficheros, los duros no.
• Los enlaces duros comparten el número de inodo, los simbólicos no.
• En los enlaces simbólicos si se borra el fichero o directorio original, la información se pierde, en los duros no.
• Los enlaces duros son copias exactas del fichero mientras que los simbólicos son meros punteros o “accesos directos”.

Si se os ocurre alguna diferencia o apunte más no dudéis en comentarlo.

En Unix existen tres bits de permisos especiales que pueden ser asignados a directorios y/o ficheros ejecutables, setuid (set user information), setgid (set group information) y sticky.

setuid

EL bit setuid es asignable a ficheros ejecutables, y permite que cuando un usuario ejecute dicho fichero, el proceso adquiera los permisos del propietario del fichero ejecutado. El ejemplo más claro de fichero ejecutable y con el bit setuid el

.

sirve para ejecutar una shell con identificadores de grupo y de usuario distintos al nuestro, por ello ha de tener este bit y así permitir adquirir al usuario temporalmente permisos administrativos para poder hacer el cambio de usuario.

Podemos ver que el bit está asignado (s) haciendo un ls:

$ ls -l /bin/su
-rwsr-xr-x 1 root root 31012 2009-04-04 07:49 /bin/su

Para asignar este bit a un fichero:

# chmod u+s /bin/su

Y para quitarlo:

# chmod u-s /bin/su

Lógicamente, conviene utilizar este bit con extremo cuidado ya que puede provocar una escalada de privilegios en situaciones inseguras. Para que veáis un ejemplo de lo que se podría hacer.

El usuario “alex” no tiene permisos para ejecutar correctamente un fdisk -l:

alex@linux:~$ fdisk -l

La salida es 0, pero si asignamos el bit setuid al binario de fdisk…

# ls -l /sbin/fdisk
-rwsr-xr-x 1 root root 93048 2009-02-18 20:43 /sbin/fdisk

Probamos de nuevo a ejecutar fdisk con el usuario “alex” y conseguimos privilegios de root:

alex@linux:~$ fdisk -l

Disco /dev/sda: 160.0 GB, 160041885696 bytes
255 cabezas, 63 sectores/pista, 19457 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x000c3c51

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *           1        3232    25959424    7  HPFS/NTFS
/dev/sda2            3233        9683    51817657+  83  Linux
/dev/sda3            9684        9855     1381590   82  Linux swap / Solaris
/dev/sda4            9856       19457    77128065   83  Linux

Luego nos acordamos de volver a quitarlo:

# chmod u-s /sbin/fdisk

setgid

Si el bit setuid permitía que el proceso adquiriera los permisos del propietario del fichero ejecutado, setgid hace lo mismo pero adquiriendo los privilegios del grupo asignado al fichero, también es asignable a directorios. Este bit entonces será muy útil cuando varios usuarios de un mismo grupo necesiten trabajar con recursos dentro de un mismo directorio.

En el siguiente ejemplo asignamos el bit setgid la carpeta /compartido, le asignamos permisos totales para el propietario y el grupo (770) y el bit segid (2):

$ mkdir compartido && chmod 2770 /compartido

Si hacemos un ls veremos el bit asignado:

$ ls -l
drwxrws--- 2 alex alex      4096 2011-04-24 21:27 compartido

Ahora vamos a hacer la prueba de crear un fichero dentro del directorio. Lo vamos a crear estando autenticados como root, pero al tener el bit setgid le asignará el grupo “alex” en lugar de root.

$ su
# touch test
root@sistemas:/home/alex/compartido# ls -l
total 0
-rw-r--r-- 1 root alex 0 2011-04-24 21:28 test
# whoami
root

En lugar de modo octal podéis asignar también los permisos setgid del siguiente modo:

$ chmog g+s /compartido

Y quitarlo:

$ chmog g-s /compartido

sticky

Este bit suele asignarse en directorios a los que todos los usuarios tienen acceso, y permite evitar que un usuario pueda borrar ficheros/directorios de otro usuario dentro de ese directorio, ya que todos tienen permiso de escritura. Seguro que lo estáis pensando, este bit se asigna siempre en /tmp y /var/tmp.

tmp tiene permisos 777, el bit sticky se asignaría del siguiente modo:

# chmod 1777 /tmp

También así:

chmod o+t /tmp

Y para quitarlo:

chmod o-t /tmp

Si hacemos un ls veremos la “t” asignada:

drwxrwxrwt  13 root root  4096 2011-04-24 20:55 tmp

Esta es una visión general de estos tres bits especiales asignables a ficheros ejecutables y directorios en Unix/Linux.

Hoy vamos a ver el modo de gestionar trabajos, procesos o aplicaciones que corren dentro de un sistema Linux/Unix. El objetivo es aprender a poner un proceso que se está ejecutando en segundo plano, suspenderlo, volver a ponerlo en primer plano, reactivarlo, etc.

Ejecutar un trabajo/proceso en segundo plano

Para ejecutar algo en segundo plano, debemos utilizar el carácter & y colocarlo tras el comando o proceso a ejecutar:

$ top &

Os recomiendo también revisar esta entrada sobre el comando nohup.

Visualizar los procesos que se encuentran en segundo plano

Para obtener un listado de los procesos que están ejecutándose en segundo plano utilizaremos el comando

(background). La salida del mismo nos indicará cada uno de los procesos con su número de trabajo asignado entre corchetes.

$ bg
[1]+ top &

Traer a primer plano los procesos que se encuentran en segundo plano

Para ello utilizaremos el comando

(foreground) junto con el ID del trabajo anteponiéndole %:

$ fg %1

Suspender un proceso que tenemos corriendo en primer plano

Si estamos ejecutando un trabajo en pantalla/terminal y queremos suspenderlo colocarlo en segundo plano utilizaremos la combinación de teclas Ctrl + Z. Automáticamente nos asignará el ID de trabajo para poder gestionarlo posteriormente:

top - 21:20:57 up 33 min,  2 users,  load average: 0.99, 0.98, 0.81
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.0%us,  4.7%sy,  0.0%ni, 70.5%id,  1.6%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   2052640k total,   948528k used,  1104112k free,    55876k buffers
Swap:  1951888k total,        0k used,  1951888k free,   461444k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                  

  776 root      15  -5     0    0    0 S    0  0.0   0:00.02 kjournald2                                                                                                               

[1]+  Stopped                 top

Para volver a arrancarlo en primer plano después:

$ fg %1

Y para ponerlo en segundo plano:

$ bg %1

Esto es realmente útil en casos como por ejemplo, estamos ejecutando un script que se demora más de lo esperado y necesitamos ejecutarlo sin necesidad de una terminal, lo dejamos en segundo plano y seguirá corriendo sin necesidad de ningún entorno visual. También si solo disponemos de una única terminal y necesitamos realizar varias tareas simultaneamente.

Visualizar los trabajos en primer plano, suspendidos, en segundo plano

El comando

nos permite visualizar un listado de los trabajos en el sistema junto con su estado e identificador:

$ jobs
[1]   Stopped                 top
[2]-  Stopped                 top
[3]+  Stopped                 vim

Un resumen práctico sería el siguiente. Arrancamos un programa (por ejemplo thunderbird) desde línea de comandos:

$ thunderbird

Ocurre que necesitamos pararlo temporalmente. En la terminal desde la que lo hemos lanzado presionamos Ctrl + Z.

Ahora el programa está parado a la espera de ser reactivado cuando queramos:

$ thunderbird
^Z
[1]+  Stopped                 thunderbird
$ jobs
[1]+  Stopped                 thunderbird

Podemos arrancarlo de nuevo pero en segundo plano:

$ bg %1
[1]+ thunderbird &

O en primer plano:

$ fg %1

Recordad que es interesante revisar la ayuda (páginas man y –help) de los comandos para obtener información sobre su utilización y las posibilidades que nos ofrece.

Personalmente pocas veces he trabajado con el comando diff en Linux, pero la verdad es que las veces contadas que lo he hecho no me ha gustado demasiado su salida para encontrar diferencias entre ficheros. Hoy, de casualidad me he topado con vimdiff, un “añadido” del maravilloso vim que nos permite ver las diferencias de ficheros de forma gráfica y muchísimo más clara que diff.

Si ya tenéis instalado vim en vuestro sistema ya dispondréis de esta utilidad. En caso contrario instalad el paquete

. Su ejecución es sencilla, simplemente pasamos como parámetro los ficheros a comparar:

# vimdiff fichero1.txt fichero2.txt

 
El resultado es tan intuitivo que no es necesario explicar demasiado. En este ejemplo vemos que vimdiff nos marca con resaltados de colores las diferencias. Por ejemplo cuando hay líneas con carácteres que están en un fichero pero no en el otro nos muestra dichos carácteres con resaltado rojo. Cuando un fichero tiene líneas completas distintas, muestra toda la línea con un resaltado azul en un fichero y con un resaltado celeste con guiones la en el otro.

En definitiva, lo más básico a conocer de vimdiff es que muestra en rojo líneas que están parcialmente cambiadas, en azul las líneas completas que no coinciden y sin resaltado lo que coincide. Como imaginaréis vimdiff al igual que vim es todo un mundo, conviene revisar la documentación si queréis profundizar en su manejo.

En todas las variantes de Unix tenemos tres flujos estándar que, a modo de canales, conectan la entrada y salida (I/O) de un comando/aplicación con la terminal/consola cuando se ejecuta, son los siguientes:

• standard input (stdin)
• standard output (stdout)
• standard error (stderr)

Vamos a explicar los usos que podemos dar estos tres canales para enviar y recoger los datos que surgen de la ejecución de un script, comando o aplicación.

standard input (stdin)

Stdin, o standard input son los datos que son enviados al programa, quizás cara al usuario de terminal sea el menos utilizado ya que lo normal suele ser interpretar los datos que el programa o comando envía, y no al revés. Normalmente stdin es texto enviado por el usuario, vamos a ver un ejemplo.

En un script en perl, podemos solicitar la interacción del usuario mediante STDIN, por ejemplo en este caso recogemos mediante STDIN el valor de dos variables que el usuario escribe:

#!/usr/bin/perl
print "Introduce tu nombre:\n";
my $nombre = <STDIN>;
print "Introduce tu apellido:\n";
my $apellido = <STDIN>;

Otro ejemplo que se me ocurre es el que puse en la entrada de automatizar comandos FTP, en este caso a la conexión FTP le pasamos de antemano los comandos a ejecutar:

ftp -inv direccion_ip<<FINFTP
comando1
comando2
comando3
FINFTP

standard output (stdout)

A través de la salida estándar, “stdout” se reciben los datos que vuelca el comando o programa durante su ejecución, ejemplos sencillos de stdout serían por ejemplo el resultado de un “ls”,”cat” o cualquier otro comando de terminal. En cambio, hay otros comandos o programas que no muestran salida (a no ser que se especifique), como por ejemplo mover o copiar ficheros. Como ya sabemos cualquiera de estos flujos de datos se puede manipular, vamos a ver un ejemplo  para comprender sus posibilidades.

Si hicieramos un “ls” a una carpeta, la salida de datos (stdout) se muestra en nuestra terminal:

$ ls
backups  cpq    games  local  log   opt  spool  www
cache    crash  lib    lock   mail  run  tmp

Para manipular la salida estándar, utilizaremos el símbolo “>”. Si por ejemplo quisieramos que stdout fuera redirigido a un fichero de texto, haríamos así:

$ ls > fichero.txt

Como podréis comprobar, por pantalla no aparece el resultado del comando, sino que se ha almacenado en el fichero indicado:

$ cat fichero.txt
backups  cpq    games  local  log   opt  spool  www
cache    crash  lib    lock   mail  run  tmp

standard error (stderr)

A través del canal stderr los programas o comandos suelen enviar el informe de error de la ejecución de un comando en caso de fallar. En nuestros scripts o comandos podemos combinar el uso de stdout y stderr para separar la salida estándar de los errores, almacenarlos en registros independientes o manipularlos por separado.

En el siguiente ejemplo vamos a ejecutar un “ls” con parámetros incorrectos, por defecto la salida de errores se volcará en pantalla (terminal):

$ ls -7
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.

Si quisieramos almacenar los errores de la ejecución del comando en caso de suceder, podemos volcarlos usando en lugar del símbolo “>” el número 2 seguido de “>”, “2>”:

$ ls -7 2> errores.log

Como podéis ver los errores ya no aparecen por pantalla, pero si abrimos el fichero de log tenemos el registro del fallo:

$ cat errores.log
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.

Si quisieramos redirigir tanto el stdout como stderr al mismo sitio, en lugar de especificar dos veces el destino podemos hacerlo del siguiente modo “2>&1″. Vamos a ver un ejemplo

Stdout y stderr a un fichero de log:

$ ls -3 > fichero.log 2>&1

Vamos a ver un ejemplo práctico de mysql. El comando mysqldump vuelca a stdout el dump de una base de datos, seguro que nos es más útil en un fichero que por pantalla, así mismo, si surge algún error nos conviene revisarlo así que lo volcamos a otro fichero distinto de log:

$ mysqldump test > test.sql 2> error.log

Otra opción es querer que tanto stdout como stderr vayan directamente a la basura (/dev/null):

$ ls -l > /dev/null 2>&1

Este es el uso más básico que podemos dar a estos tres importantes flujos estandar Unix, si tenéis cualquier duda podéis consultarla a través de los comentarios.

Era un poco complicado poner título a esta entrada, no obstante seguro que a todos nos ha pasado que comenzamos a editar un fichero desde vim o vi y a la hora de grabar nos damos cuenta que no tenemos privilegios para guardarlo (ya sea porque es propietario root u otro usuario), recibimos un error similar a:

W10: Advertencia: cambiando un fichero de sólo lectura 58,1 Final

E212: No puedo abrir el fichero para escribir en él.

Si tenemos la posibilidad de hacer uso de sudo con nuestro usuario, la solución para poder grabar el fichero sin necesidad de salir de vim es del siguiente modo. Tenemos que entrar en modo comandos (ESC) y ejecutar lo siguiente:

:w !sudo tee %
[sudo] password for alex:

Nos pedirá la clave de sudo y podremos guardar el fichero ;)