Esta página puede ser redistribuida libremente bajo los términos de la licencia GPL. Vease ( GPL texto original ) o si lo prefiere (Traducción española no oficial de la GPL) Al margen de las obligaciones legales que se derivan del uso de esta licencia rogamos sea respetada la referencia a su lugar de publicación original www.ciberdroide.com. y a su autor original Antonio Castro Snurmacher (Madrid 01/01/2000).

Ausencia de Garantía

Esta ausencia de garantía se hace extensa a cualquier tipo de uso de este material y muy especialmente a las prácticas, ejercicios, y de ejemplos que encuentre en estas páginas. Deberá trabajar siempre salvo indicación contraria con un SO Linux y con un usario distinto de 'root' sin privilegios especiales. Como directorio de trabajo se procurará usar el directorio '/tmp' o algún otro que no contenga información valiosa. Tampoco se considera buena idea practicar en una máquina que contenga información valiosa.

Todo esto son recomendaciones de prudencia. En cualquier caso si algo sale mal toda la responsabilidad será únicamente suya. En ningún caso podrá reclamar a nadie por daños y perjuicios derivados del uso de este material. Para más información lea el contenido de la licencia GPL y abstengase de hacer prácticas si no está dispuesto a asumir toda la responsabilidad.

SISTEMA DE FICHEROS Tercera parte

Tipos de enlaces (links) y su manejo
La palabra link es inglesa y para el concepto que vamos a tratar podríamos traducirla por enlace. Hay dos tipos de enlaces llamados 'hard link' y 'symbolic link'. Podriamos traducirlo por enlace rígido y por enlace simbólico. El término enlace simbólico se usa con frecuencia en español y parece muy adecuado pero realmente no existe una traducción para hard link tan aceptada. Nosotros emplearemos el término rígido para hard que literalmente significa duro.

Ya hemos mencionado algunas cosas sobre ellos pero sin profundizar demasiado.

El manejo de ambos tipos de enlaces se hace con el comando 'ln'. Como es habitual un repaso a la página man de este comando es muy recomendable. La creación de un enlace rígido y uno simbólico es muy similar. La diferencia es que para el enlace simbólico tendremos que usar la opción -s.

Como es habitual asumimos que las prácticas se realizarán desde un usuario distinto de root. 

$ cd /tmp
$ mkdir /tmp2
$ cd tmp2
$ echo xxxx > ej0
$ ## Ahora creamos un par de enlaces rígidos con ej0
$ ln ej0 ej1
$ ln ej0 ej2
$ ## Creamos también un enlace simbólico ejs1 a ej0
$ ln -s ej0 ejs1
$ mkdir dir1
$ ## También creamos un enlace simbólico dir2 a dir1
$ ln -s dir1 dir2
$ ls -l

drwxr-xr-x   2 pepe user 1024 may 18 17:28 dir1
lrwxrwxrwx   1 pepe user    4 may 18 17:28 dir2 -> dir1
-rw-r--r--   3 pepe user    1 may 18 17:26 ej0
-rw-r--r--   3 pepe user    1 may 18 17:26 ej1
-rw-r--r--   3 pepe user    1 may 18 17:26 ej2
lrwxrwxrwx   1 pepe user    3 may 18 17:28 ejs1 -> ej0

Con esto acabamos de crear dentro de tmp un directorio tmp2 y dentro de el hemos creado ya algunos ficheros, algunos directorios y unos cuantos enlaces rígidos y simbólicos. Los enlaces rígidos no muestran nada particular listados con 'ls -l' pero los enlaces simbólicos vienen acompañados de una flecha que apunta a otro nombre de fichero.

El fichero 'ej0' lo hemos creado con un contenido 'xxxx' para ver que pasa con ese contenido más adelante. El nombre de usuario 'pepe' y el nombre de grupo 'users' son ficticios y en su sistema obtendrá otra cosa. Hay una columna de números a continuación de los permisos. Se trata de una columna que indica el número de enlaces rígidos que están asociados a un mismo fichero. En el caso de 'ej0', 'ej1', 'ej2' aparece un 3 y está claro porque son enlaces creados por nosotros pero el directorio 'dir1' tiene un 2. Esto significa que existe otro enlace rígido para ese directorio que nostros no hemos creado. Se ha creado automáticamente al crear 'dir1'. Acuerdese que todos los directorios se crean con un par de entradas que son '.' y '..' El 2 por lo tanto en este caso se debe a la entrada '.' dentro del propio 'dir1' y si dentro de 'dir1' existieran directorios habría que contabilizar cada uno del los '..' de los directorios hijos como enlaces rígidos de 'dir1'. Un fichero se corresponde con un único inodo. Es decir tiene una única entrada en la tabla plana del sistema de ficheros, pero quizas aparezca varias veces en distintas partes del sistema de ficheros, o con distinto nombre. Si esto último no le ha quedado claro vuelva a leerlo después de finalizar este capítulo porque vamos a seguir exiplicando que es un enlace rígido. Ahora retomamos la práctica en el punto donde la dejamos y continuamos. 

$ cat ej0

xxxx

$ echo kkkkkkkkk > ej1
$ cat ej0

kkkkkkkkk

$ cat ejs1

kkkkkkkkk

Vemos que el contenido de los distintos enlaces con 'ej0' es idéntico, y si modificamos el contenido de cualquiera de ellos se afectará instantaneamente el contenido de los restantes. En realidad la información es accesible desde distintos nombres de ficheros pero no son copias sino que se trata de la misma unidad de información. Continuamos con el ejercicio. 


$ rm ej0
$ cat ejs1

cat: ejs1: No existe el fichero o el directorio

$ cat ej1

kkkkkkkkk

Aquí ya vemos una diferencia. Pese a que 'ej1' se creó como un enlace de 'ej0', 'ej1' mantiene accesible la información incluso aunque desaparezca 'ej0'. Eso es porque en el caso de los enlaces rígidos da igual cual es el enlace o fichero original. Son totalmente equivalentes y la información solo desaparecerá del sistema cuando el último enlace rígido sea eliminado. La diferencia con el enlace simbólico es que actua simplemente accediendo al nombre del fichero que tiene almacenado en su interior. Por eso en el caso que acabamos de ver 'ejs1' queda apuntando a 'ej0' que es un fichero que ya no existe. Continuamos con el ejercicio y ahora usaremos una opción para 'ls' que no habíamos visto antes. Se trata de la opción -i que sirve para visualizar el número de inodo. Un inodo es una clave numérica para el acceso al sistema plano de ficheros donde cada almacén de información tiene una única clave y por eso los distintos enlaces rígidos contienen el mismo valor de inodo. 

$ ls -li

  73449 drwxr-xr-x   2 pepe user 1024 may 18 17:28 dir1
  59173 lrwxrwxrwx   1 pepe user    4 may 18 17:28 dir2 -> dir1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej2
  59172 lrwxrwxrwx   1 pepe user    3 may 18 17:28 ejs1 -> ej0

Como se puede ver 'ej1' y 'ej2' tienen el mismo valor de 59171 que en su sistema será otro valor cualquiera. En este momento después de borrar 'ej0' figuran con el valor 2 para el número de enlaces rígidos asociados. Vamos a mover el enlace simbólico 'ejs1' a 'dir1' pero vamos a usar 'mv ejs1 dir2' en lugar 'mv ejs1 dir1' pero debería dar lo mismo ya que 'dir2' es un enlace simbólico a 'dir1'. 

$ mv ejs1 dir2
$ #
$ ## Comprobamos el resultado
$ ls -li

  73449 drwxr-xr-x   2 pepe user 1024 may 18 17:32 dir1
  59173 lrwxrwxrwx   1 pepe user    4 may 18 17:28 dir2 -> dir1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej2

$ ls dir2

ejs1

$ ls -li dir1

  59172 lrwxrwxrwx   1 pepe user    3 may 18 17:28 ejs1 -> ej0

Hemos comprobado que un enlace simbólico se ha comportado igual que si fuera el propio directorio apuntado. En realidad podemos actuar a todos los efectos como si se tratara del verdadero fichero en lugar de un enlace simbólico salvo en el momento de su creación y en el momento de su destrucción. La operación 'rm' sobre un fichero simbólico no actua sobre el fichero apuntado sino sobre el propio enlace simbólico destruyendolo.

Ahora tenemos 'dir2/ejs1 -> ej0' pero 'ej0' ni siquiera existe. Vamos a cambiar el nombre de 'ej2' que era un enlace rígido de 'ej0' por 'ej0'. 

$ mv ej2 ej0
$ cat dir2/ejs1

cat: dir2/ejs1: No existe el fichero o el directorio

Bueno este error es lógico porque el enlace 'dir2/ejs1' apunta a 'ej0' y no importa que estemos en el mismo directorio que 'ej0' sino que 'dir2/ejs1' y 'ej0' estén en el mismo directorio. Los enlaces son siempre relativos al sitio donde se encuentra el propio enlace. En caso contrario podría resultar graciosísimo pero poco práctico porque dependiendo de donde estuvieramos nosotros ( más exactamente dependiendo del directorio actual del proceso que lo use) apuntaría a un directorio distinto cada vez.

De todas formas comprobemoslo trasladando 'ej0' a 'dir2', y observando como ha quedado todo. 

$ mv ej0 dir2
$ cat dir2/ejs1

kkkkkkkkk

$ ls -li

  73449 drwxr-xr-x   2 pepe user 1024 may 18 17:34 dir1
  59173 lrwxrwxrwx   1 pepe user    4 may 18 17:28 dir2 -> dir1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej1

$ ls -li dir2

  59173 lrwxrwxrwx   1 pepe user    4 may 18 17:28 dir2 -> dir1

$ rmdir dir2

rmdir: dir2: No es un directorio

$ rm dir2
$ ls -li

  73449 drwxr-xr-x   2 pepe user 1024 may 18 17:34 dir1
  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej1

$ ls -li dir1

  59171 -rw-r--r--   2 pepe user   10 may 18 17:30 ej0
  59172 lrwxrwxrwx   1 pepe user    3 may 18 17:28 ejs1 -> ej0

Montage de dispositivos
Pueden existir varios sistemas de ficheros cada uno en un dispositivo o partición distinta, pero para hacerlo accesible ha de ser montado dentro del sistema principal de ficheros. Para ello se utilizan los comandos 'mount' y 'umount'.

Explicaremos esto un poco más. Supongamos que dispone de un disquete en el que desea guardar información accesible como parte del sistema actual. En MSDOS se accedería a la unidad que representa este dispositivo mediande el comando a: o b: por ejemplo. En Unix esto no ocurre porque ese patético invento llamado unidad lógica no existe.

Perdón por lo de patético pero es que en MSDOS, y en Windows cambias las cosas de sitio y terminas reinstalando todo.

Supongamos que tenemos en un dispositivo cdrom, cinta, disquete, o lo que sea la siguiente estructura de directorios. 

.
|-- Guia-del-enROOTador-2.8
|-- curso
|-- glup_0.6-1.1-html-1.1
|-- lipp-1.1-html-1.1
|-- man_instal_debian_21
|-- novato-a-novato
`-- rhl-ig-6.0es
    |-- cpps
    `-- icons

Para poder acceder a esta información tendríamos que realizar una operación de montado sobre algún punto de nuestro sistema de ficheros actual. Por ejemplo si disponemos de un directorio '/misc/novato' podriamos montar en ese punto nuestro dispositivo y en ese caso la operación sería como enganchar un arbol en la rama de otro arbol. De esta forma para el sistema sería como si el arbol creciera. 

.
`-- misc
    `-- novato
        |-- Guia-del-enROOTador-2.8
        |-- curso
        |-- glup_0.6-1.1-html-1.1
        |-- lipp-1.1-html-1.1
        |-- man_instal_debian_21
        |-- novato-a-novato
        `-- rhl-ig-6.0es
            |-- cpps
            `-- icons

Si el administrador considera que montar y un dispositivo no entraña riesgos para el sistema concedera permisos para que esto pueda ser realizado por los usuarios. Por ejemplo un administrador puede considerar que los usuarios solo puedan montar la unidad de cdrom.

En un entorno multiusuario y multiproceso no interesa hacer efectiva las actualizaciones sobre un dispositivo de forma instantanea sino que se intenta optimizar los accesos al dispositivo. Por eso si escribimos en un dispositivo de lectura escritura como por ejemplo un disquete y sacamos dicho disquete antes de desmontarlo lo más probable es que algunas operaciones de escrituras queden sin realizar porque estaban simplemente guardadas en memoria a la espera de ser realizadas. Cuando se desmonta un sistema de ficheros se escriben las operaciones pendientes sobre ese dispositivo y entonces puede ser extraido del sistema sin peligro.

Directorio /proc
Este directorio es un directorio muy especial. Es un directorio en el cual está montado un sistema de ficheros virtual. En realidad muestra información que no reside en ningún dispositivo sino que es elaborada por el propio kernel. Por ello se trata de falsos archivos. Su ocupación en disco es 0. Sirve para comprobar la configuración y el funcionamiento del kernel. No entraremos ahora a comentarlo en detalle porque este tema es de interés para administradores del sistema. Lo que nos interesa comentar es que aquí la presentación en forma de sistema de ficheros es una simulación y se hace así para que pueda ser manejada exactamente de la misma forma que si realmente estuviera contenida en directorioss y ficheros.

Algunos de estos ficheros son de solo lectura otros son de lectura y escritura y permiten cambiar la configuración del kernel sin detenerlo. Evidentemente todo ello está configurado con los permisos adecuados para mantener la seguridad del sistema.

Si miramos dentro del directorio '/proc' veremos que hay un montón de directorios cuyo nombre es un número. Estos directorios representan cada uno a un proceso por su pid. Ya hemos estudiado el proceso init en capítulos anteriores así que vamos a poner un ejemplo.

Pruebe a hacer lo siguiente: 

$ cat /proc/1/status

Obtendrá la información de estado más importante del proceso init. Además de contribuir a la cultura general sobre nuestro sistema lo que hemos mencionado sobre '/proc' nos sirve para introducir el siguiente tema.

Sistema de ficheros virtual
En Linux un sistema de ficheros puede corresponderse físicamente y lógicamente con cosas muy distintas. Acabamos de ver que el directorio '/proc' aparentemente está organizado como si fuera un sistema de ficheros idéntico a los que residen en disco duro y sin embargo se trata de algo totalmente distinto. Un sistema de ficheros puede residir, en memoria, en una partición de disco duro, en un dispositivo raid formado por varios discos duros funcionando en paralelo y con un sistema de redundancia, en disquetes, en cdroms, en un dispositivo remoto conectado a red, etc.. También se puede implementar un sistema de ficheros dentro de un fichero. Por ejemplo umsdos es un sistema de ficheros linux implementado dentro de un fichero msdos. Realmente es una solución muy poco eficiente pero pone de relieve la flexibilidad del sistema virtual de ficheros. Un sistema de ficheros puede tener un formato interno que no siempre es el mismo. Linux puede manejar sistemas de ficheros de otros sistemas operativos. En resumen lo que Linux ofrece con su sistema ficheros virtual (VFS) es un sistema unificado de acceso a toda una variedad de recursos muy distintos. Esto es posible porque se definen una serie de funciones para manejar un sistema de ficheros genérico. En Unix cada sistema de ficheros tiene asociado un sistema plano de ficheros. Las estructuras pueden ser diferentes para cada tipo de sistema de ficheros, pero las funciones que lo manejan quedan unificadas por el (VFS)

Estructura estandar del sistema de ficheros de Linux
Existe un documento 'fsstnd' donde se describe una recomendación para estandarizar la estructura del sistema de ficheros de Linux para las distintas distribuciones. Nosotros vamos a resumir brevemenente la informacióm más importante. Un detalle mayor sería necesario si este curso fuera un curso de administración del sistema.

Este último capítulo no explica conceptos nuevos pero servirá para que comprenda lo que tiene en su sistema. Puede investigar todo lo que quiera por su cuenta siempre que use un usuario normalito sin privilegios. Si alguna vez se siente perdido solo tiene que introducir el comando 'cd' para volver a casita.

Puede haber diferencias importantes en la estructura general del sistema de ficheros entre unas distribuciones y otras pero en lineas generales el aspecto de la disposición de los directorios más importantes sería más o menos el siguiente; 

.
|-- bin
|-- sbin
|-- tmp
|-- boot
|-- dev
|-- etc
|-- home 
|-- lib
|   |-- modules
|   `-- security
|-- home
|   |-- ftp
|   |-- httpd
|   |-- luis
|   |-- msql
|   |-- pili
|   `-- skeleton
|-- root
|-- usr
|   |-- bin
|   |-- sbin
|   |-- X11R6
|   |   |-- bin
|   |   |-- include
|   |   |-- lib
|   |   `-- man
|   |-- local
|   |   |-- bin
|   |   |-- doc
|   |   |-- man
|   |   |-- lib
|   |   |-- src
|   |   `-- tmp
|   |-- doc
|   |-- include
|   |-- info
|   `-- src
|       `-- linux 
|-- proc
`-- var
    |-- cache
    |-- catman
    |-- lib
    |-- local
    |-- lock
    |-- log
    |-- run
    |-- spool
    |   |-- cron
    |   |-- lpd
    |   |-- mail
    |   `-- mqueue
    `-- tmp

Si observa diferencias con la estructura de ficheros de su distribución no debe preocuparse esto es solo un ejemplo. Comentaremos el cometido de los directorios más significativos.

El directorio raiz
Para arrancar el sistema, debe estar presente lo suficiente como para montar '/usr' y otras partes no-esenciales del sistema de archivos. Esto incluye herramientas, información de configuración y del cargador de arranque (boot loader) y alguna otra información esencial al arrancar.

Para habilitar la recuperación y/o la reparación del sistema, estará presente en el sistema de archivos raíz aquellas herramientas que un administrador experimentado necesitaría para diagnosticar y reconstruir un sistema dañado.

Los errores del disco, que corrompen la información en el sistema de archivos '/' son un problema mayor que los errores en cualquier otra partición. Un sistema de archivos '/' (raiz) pequeño es menos propenso a corromperse como resultado de un fallo del sistema.

La principal preocupación que se usa para balancear las anteriores consideraciones, que favorecen el colocar muchas cosas en el sistema de archivos raíz, es la de mantener '/' (raiz) tan pequeno como sea razonablemente posible. 


/ --- El Directorio Raíz


bin             Binarios de comandos esenciales
boot            Archivos estáticos de cargador de arranque(boot-loader)
dev             Archivos de dispositivos
etc             Configuración del sistema local-máquina
home            Directorios home de los usuarios
lib             Librerías compartidas
mnt             Punto de montaje de particiones temporales
root            Directorio hogar del usuario root
sbin            Binarios del sistema esenciales
tmp             Archivos temporales 
usr             Segunda jerarquía mayor
var             Información variable
La jerarquía /usr.
'/usr' es la segunda mayor sección del sistema de archivos. '/usr' es información compartible, de solo lectura, esto significa que '/usr', debe ser compartible entre varias maquinas que corren LINUX y no se debe escribir. Cualquier información que es local a una máquina o varía con el tiempo, se almacena en otro lugar.

Ningún paquete grande (como TeX o GNUEmacs) debe utilizar un subdirectorio directo bajo '/usr', en vez, debe haber un subdirectorio dentro de '/usr/lib' (o '/usr/local/lib' si fué instalado completamente local) para ese propósito, con el sistema X Window se hace una excepción debido a un considerable precedente y a la práctica ampliamente aceptada. 

/usr --- Segundo mayor punto de montaje (permanente)

X11R6           Sistema X Window Version 11 release 6
X386            Sistema X Windows Version 11 release 5 en plataformas  X 86
bin             La mayoría de los comandos de usuario
dict            Listas de palabras
doc             Documentación miscelánea
etc             Configuración del Sistema (todo el site)
games           Juegos y binarios educacionales
include Archivos header incluidos por programas C
info            Directorio primario del sistema GNU Info
lib             Librerías
local           Jerarquía local (vacía justo después de la instalación principal)
man             Manuales en línea
sbin            Binarios de Administración del Sistema No-Vitales
share           Información independiente de la arquitectura
src             Código fuente

/usr/local: Jerarquía local
La jerarquía '/usr/local' está para ser utilizada por el administrador del sistema cuando se instale el software localmente. Necesita estar a salvo de ser sobreescrito cuando el software del sistema se actualiza. Puede ser usado por programas y por información que son compartibles entre un grupo de máquinas , pero no se encuentran en '/usr'. 

/usr/local      Jerarquía local.

bin             Binarios solo-locales
doc             Documentación local
etc             Binarios de configuración solo-local
games           Juegos instalados localmente
lib             Librerías para /usr/local
info            Páginas de info local
man             Jerarquías de páginas de manual para /usr/local
sbin            Administración del sistema solo-local
scr             Código fuente local.

Este directorio debe estar vacío al terminar de instalar LINUX por primera vez. No debe haber excepciones a la regla , excepto quizá los subdirectorios vacíos listados. La Jerarquía /var
El sistema necesita con frecuencia una zona de trabajo temporal. Si solo se requiere usar un espacio por un corto periodo de tiempo se puede usar '/tmp', pero muchas veces la información conviene manejarla y almacenarla en un lugar más permanente. El sistema puede sufrir una caida repentina y el contenido de '/tmp' puede ser borrado durante el arranque o depurado regularmente mediante algúna tarea periódica. Por el contrario '/var' contiene todo tipo de información alguna de ella puede ser importante. Por ejemplo información vital para el mantenimiento de la gestión de paquetes de la distribución o mensajes pendientes de ser enviados por correo, archivos y directorios en fila de ejecución, información de bitácora administrativa y archivos temporales y transitorios aunque se asume que su permanencia será mayor que '/tmp' 

 /var	Información variable

	catman  	Páginas del manual formateadas localmente
	lib		Información del estado de aplicaciones
	local		Información variable del software de /usr/local
	lock		Archivos de bloqueo
	log		Archivos de bitácora
	named		Archivos DNS, solo red
	nis		Archivos base de datos NIS
	preserve	Archivos almacenados después de una falla de ex o vi 
	run		Archivos relevantes a procesos ejecutándose
	spool		Directorios de trabajos en fila para realizarse después
	tmp		Archivos temporales, utilizado para mantener /tmp pequeño

Test
Puede comprobar sus conocimientos respondiendo el siguiente test.
Para ello seleccione las opciones que se ajusten a la verdad y luego pulse el boton para ver el resultado de su test.

1 Cuando se crea un directorio se crea tambien un
par de enlaces simbólicos que apuntan a '.' y a '..' .
2 Suponiendo que 'fich1', 'fich2', y 'fich3' tienen
el mismo valor de inodo su contenido será idéntico.
3 Suponiendo que 'fich1', 'fich2', y 'fich3' tienen
el mismo valor de inodo y que cada uno tiene un
tamaño de 10Mbytes al borralos recuperaremos 30Mbytes
4 En el caso de los enlaces simbólicos da igual cual es
el enlace o fichero original.
5 No se puede establecer enlaces rígidos entre distintos
sistemas de ficheros.
6 Para acceder a un sistema de ficheros hay que montarlo en algún punto del sistema de ficheros raiz.
7 Un sistema de ficheros siempre reside en disco.

Resultado del test

Si quiere hacernos llegar alguna duda, aclaración,
crítica, o contribución personal, utilice nuestro
formulario de contacto y nosotros le contestaremos		 contacto