Linux, ubuntu, gnome, debian, xubuntu, GNULa Zona Linux, la zona linux, Todo lo relacionado al mundo de GNU / Linux, ubuntu, debian, etcPosteado por:
![]() REGISTRATE! es GRATIS!! Acá se explica cual es la estructura del sistema de archivos de Linux, la ubicación y principal función de cada uno de los directorios del sistema y de los distintos archivos de configuración. Es un texto bastante corto y consiso y sirve para que se saquen muchas dudas quienes están interesados en aprender acerca de este sistema operativo. (Está dividido en dos partes, porque no entraba todo en un sólo post) Leer primero la Parte 1 6. La jerarquía /usr usr es la segunda mayor seccion del sistema de archivos. /usr es /informacion compartible, de sólo-lectura, esto significa que /usr, debe ser /compartible entre varias máquinas que corren Linux y no se debe /escribir. Cualquier informacion que es local a una máquina o varía con el /tiempo, se almacena en otro lugar. Ningun paquete grande (como TeX o GNU Emacs) 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 sbir Binarios de Administración del Sistema No-Vitales share Información independiente de la arquitectura src Código fuente Los siguientes enlaces simbólicos a directorios pueden estar presentes. Esta posibilidad se basa en la necesidad de preservar la compatibilidad con sistemas anteriores hasta que en todas las implementaciones se pueda asumir el uso de la jerarquía /var. /usr/adm ------------------> /var/adm /usr/preserve -------------> /var/preserve /usr/spool ----------------> /var/spool /usr/tmp ------------------> /var/tmp /var/spool/locks ----------> /var/lock Una vez que el sistema ya no requiera más alguno de los anteriores enlaces simbólicos, el enlace se puede remover, si se desea. Notablemente, sólo se necesita poco esfuerzo para remover completamente /usr/preserve, dado que sólo ex y vi lo utilizan. 6.1 /usr/X11R6: El sistema X Window, Version 11 release 6 Esta jerarquía está reservada para el sistema X Window, Version 11 release 6 y archivos relacionados. /usr/X11R6 --- X Window System (Version 11, release 6) bin doc include lib man Para simplificar los problemas y hacer XFree86 más compatible con el sistema X Window en otros sistemas, los siguientes enlaces simbolicos deben estar presentes. /usr/bin/X11 ------------> /usr/X11R6/bin /usr/lib/X11 ------------> /usr/X11R6/lib/X11 /usr/include/X11 --------> /usr/X11R6/include/X11 En general, el software no se debe instalar o manejar vía los anteriores enlaces simbólicos. Sólo están para la utilización por usuarios. La dificultad está relacionada con la versión y el release del sistema X Window; en períodos transicionales es imposible saber que release de X11 está utilizandose . Por la misma razón no debe existir un enlace desde /usr/X11 apuntando a la jerarquía del sistema X Window actual. 6.2 /usr/X386: El sistema X Window, Version 11 release 5 en plataformas X 86 Esta jerarquía es generalmente idéntica a /usr/X11R6, excepto que los enlaces simbólicos de /usr deben estar ausentes si está instalado /usr/X11R6 /usr/bin: La mayoría de los comandos del usuario. Éste es el directorio principal de comandos ejecutables en el sistema. mh comandos para el sistema de manejo de correo M H X11 Enlace simbólico hacia /usr/X11R6/bin Debido a que los interpretadores de scripts de los shell (invocados con #! <ruta> en la primera linea del script de shell) no pueden depender de una ruta, es ventajoso el estandarizar la localización de ellos. La shell Bourne y C estan fijos en /bin, pero Perl, Python, Tlc se encuentran en muchos lugares diferentes /usr/bin/perl, /usr/bin/python y /usr/bin/tcl deben referenciar a los intérpretes de shell perl, python y tcl respectivamente. Éstos pueden ser enlaces simbólicos a la localización física de los intérpretes de shell. 6.3 /usr/dict: Listas de palabras Archivos recomendados en /usr/dict words Tradicionalmente este directorio contiene sólo el archivo words de palabras inglesas, el cual es utilizado por look(1) y varios programas de ortografía, words puede utilizar ortografía americana o británica. Los sites que requieran ambos, pueden enlazar words a /usr/dict/american-english ó /usr/dict/british-english. Las listas de palabras para otros lenguajes se pueden añadir usando el nombre en inglés para ese lenguaje, por ejemplo, /usr/dict/french, /usr/dict/danish, etc. Éstos deben, si es posible, utilizar un juegos de caracteres ISO 8859 que sea apropiado para el lenguaje en cuestión, si es posible el juego de caracteres ISO 8859-1 (Latin1) debe ser utilizado (esto es a veces imposible) Cualquier otra lista de palabras, tal como el directorio web2, debe ser incluido aquí, si está presente. Las razones tras tener sólo las listas de palabras aquí es que ellas son los únicos archivos comunes a todos los verificadores de ortogafía. 6.4 /usr/etc: Configuración del sistema (todo el site) Almacenar la configuración en /usr/etc del software que se encuentra en /usr/bin y /usr/sbin es un problema. Hace que el montar /usr sólo-lectura de un CDROM o a través de NFS sea difícil en el mejor de los casos. Una posible solución que se consideró fue eliminar completamente /usr/etc y especificar que todas las configuraciones se almacenen en /etc. Un problema con esta aproximación es que no anticipa propiamente la posibilidad de que muchos sites pueden querer tener algunos archivos de configuracion que no sean locales de máquina. Eventualmente se decidió que /etc deberá ser el único directorio que sea referenciado por los programas (esto es, todos deben buscar configuraciones en /etc y no en /usr/etc). Cualquier archivo de configuración que necesite ser para todo el site y que no es necesario antes de montar /usr (o en una situación de emergencia debe entonces estar localizado en /usr/etc. Entonces archivos específicos (en /etc), en máquinas específicas pueden ser o no ser enlaces simbólicos a los archivos de configuración localizados en /usr/etc. Ésto también significa que /usr/etc es técnicamente un directorio opcional en el sentido estricto, pero aún así recomendamos que todos los sistemas Linux lo incorporen. No se recomienda que /usr/etc contenga enlaces simbólicos que apunten a archivos en /etc. Ésto es innecesario e interfiere con el control local en máquinas que comparten un directorio /usr. 6.5 /usr/include: Directorio para archivos include estándar. Aquí es donde todos los archivos include de uso general del sistema para programación en lenguajes C y C++ deben ser localizados. /usr/include Archivos include X11 Enlace simbólico hacia /usr/X11R6/include/X11 arpa Definiciones del protocolo definido por ARPNET. asm Enlace simbólico hacia /usr/scr/linux/include/asm-<arch>. bsd Archivos include de compatibilidad con BSD. g++ Archivos include de GNU C++. gnu Archivos include GNU. linux Enlace simbolico a /usr/src/linux/include/linux. net Definiciones genéricas relacionadas con redes. netax25 Definiciones específicas a +AX25 ( ARRL AX25). netinet Definiciones específicas a TCP/IP. netipx Definiciones específicas a +IPX (Novel IPX/SPX). protocols Definiciones de protocolos ( Mayormente basadas en INET) readline La librería readline GNU. rpc Definiciones RPC de Sun Microsystems. rpcsvc Definiciones de servicios RPC de Sun Microsystems. sys Archivos include de generación de sistemas. El subdirectorio arpa contiene definiciones de cabecera de protocolos para los protocolos ARPANET, TCP/IP, definiciones para ftp, prototipos telnet y material similar. El subdirectorio net contiene definiciones genéricas relacionadas con redes, define la interface sistema-kernel, detalles de la familia de protocolo, etc. El subdirectorio netinet contiene definiciones especificas de INET (DARPA Internet, que tambien es conocida como TCP/IP ) ARRL AX.25 es mejor conocido como packet radio. Los protocolos novell IPX/SPX son parte de los servicios de archivos Novell Netware. 6.6 /usr/lib: Librerías para programas y paquetes. usr/lib incluye librerías objeto, binarios del programa compilador e /información estática de varias clases, ambos, códigos ejecutable ( por /ejemplo los binarios internos de gcc estan localizados bajo //usr/lib/gcc-lib ) y otros tipos de informacion. /usr/lib/ - librerias para programción y paquetes: X11 Enlace simbólico a /usr/X11R6/lib/X11 emacs Archivos de soporte estáticos para el editor GNUEmacs. games Archivos de datos estáticos para /usr/games. groff Librerías / Directorios para GNU groff gcc-lib Archivos/ Directorios específicos del sistema para gcc. kbd Tablas de traducción de teclado e información relacionada. Mh Librerías para el sistema de manejo de correo MH: news Cnews/INN. smail Smail. terminfo Directorios para la base de datos terminfo. texmf TeX/MF ( y LaTeX ) librerías de información. uucp Comandos de UUCP. zoneinfo Configuración e información de la zona horaria. Históricamente, /usr/lib ha incluido además algunos comandos ejecutables tales como sendmail y makewhatis. Dado que makewhatis no es referenciado por otros programas, no hay problemas al moverlo a un directorio binario. Dado que los usuarios tienen buena razón para usar makewhatis, /usr/lib es donde pertenece. El binario catman que remplaza al script makewhatis en muchos sistemas Linux, debe también estar en usr/bin El binario sendmail es referenciado por muchos programas con su nombre histórico /usr/lib/sendmail. Éste debe ser un enlace simbólico a la localización estándar para los agentes de transferencia de correo con una interfaz de línea de comando compatible con sendmail, /usr/bin/sendmail. En sistemas que utilizan smail deben localizar smail en /usr/sbin/smail y /usr/bin/sendmail debe ser un enlace simbolico a smail. Este arreglo también se conforma a la nueva locación estándar sendmail definida en Sendmail 8.6.x y BSD 4.4 Note que esta localización demanda que /usr/sbin y /usr/sbin/sendmail deben ser ejecutables para usuarios normales. Cualquier paquete o programa que contenga o requiera información que no necesite ser modificada debe almacenar tal información en /usr/lib ( ó /usr/local/lib, si está instalado localmente ). Se recomienda la utilizacion de un subdirectorio en /usr/lib para este propósito. La información de juegos almacenada en /usr/lib/games debe ser solamente información estática. Cualquier archivo modificable . tal como archivos de marcadores, registros de juego y similares, deben ser localizados en var/lib. Si es necesario para compatibilidad de juegos con el viejo estilo BSD, se puede usar un enlace simbólico desde /usr/games/lib hacia /usr/lib/games. Nota: ninguna información específica de host para el sistema X window debe almacenarse en /usr/lib/X11 ( que es realmente /usr/X11R6/lib/X11) . Los archivos de configuración específicos de host tales como Xconfig ó XF86Config deben almacenarse en /etc/X11. Éste debe incluir información de configuración como system.twmrc aún si es sólo un enlace simbólico a un archivo de configuración más global ( tal vez en /usr/etc/X11 ó /usr/X11R6/lib/X11). 6.7 /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 sólo-locales doc Documentación local etc Binarios de configuración sólo-local games Juegos instalados localmente lib Librerís 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 sólo-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. El software instalado localmente debe estar localizado dentro de /usr/local, en vez de /usr a menos que este siendo instalado para reemplazar o actualizar el software en /usr. Note que el software localizado en / o en /usr puede ser sobreescrito por actualizaciones del sistema (aunque recomendamos que las distribuciones no sobreescriban informacion en /etc bajo estas circunstancias). Por esta razón, el software local no se debe localizar fuera de /usr/local sin una buena causa. 6.8 /usr/man : Páginas del manual. Esta sección detalla la organización de las páginas del manual a través del sistema. Incluyendo /usr/man. Las páginas del manual están almacenadas <mandir>/<locale>/man [1-9]. Más delante se dá una explicación de <mandir> y <locale>. <mandir>/<locale> --- Una jerarquía de páginas de manuales. man1 Programas para usuarios. man2 Llamadas al sistema. man3 Subrutinas y funciones de librería man4 Dispositivos. man5 Formato de archivos man6 Juegos. man7 Misceláneas. man8 Administración del Sistema. man9 Funciones y variables internas del kernel. El <mandir> primario del sistema es /usr/man contiene información del manual para comandos e información bajo los sistemas de archivos / y /usr. Obviamente no hay páginas de manual en / por que no se necesitan para arrancar ni en emergencias. Se debe hacer provisión en la estructura de /usr/man para el soporte de páginas del manual que estén escritas en diferentes (o multiples idiomas ). Estas provisiones deben tomar en cuenta el almencenamiento y referencia de estas páginas del manual. Los factores relevantes incluyen el idioma ( incluyendo diferencias basadas en la geografia ) y el código del conjunto de caracteres. Esta nomenclatura de los subdirectorios de idiomas de /usr/man está basada en el apendice E del estándar POSIX 1003.1 que describe la cadena de identificación locale ---El metodo más aceptado para describir un ambiente cultural. La cadena <locale>es: <idioma>[<_territorio>][.<conjunto_de_caracteres>][,<version>] El campo <idioma> se tomará del ISO639 (un código para la representacion de los nombres de los idiomas). Sera de dos caracteres de ancho y especificado con minúsculas solamente. El campo <_territorio> sera el código de dos letras de ISO3116 (una especificación de la representación de los nombres de los países), si es posible. (mucha gente está familiarizada con el código de 2 letras empleado en el código de país en las direcciones de e-mail. El campo <conjunto_de_caracteres> debe representar el estándar que describe el código de caracteres. Si el campo <conjunto_de_caracteres> es sólo una especificación numérica, el número representa el número del estándar internacional que describe a ese conjunto de caracteres. Se recomienda que este sea una representacion numérica siempre que sea posible (especialmente, estándares ISO), que no incluya símbolos de puntuación y que todas las letras sean minúsculas. Un párametro que especifique <version> del perfil puede ser colocada despues del campo <conjunto_de_caracteres >, delimitado con una coma. Ésto puede utilizarse para discriminar entre diferentes necesidades culturales, por ejemplo un orden de diccionario en vez de un orden de acomodo más orientado hacia el sistema. Este estándar recomienda no usar el campo <version> a menos que sea necesario. En sistemas que usen sólo un idioma y un código de conjunto de caracteres para todas las páginas del manual, pueden omitir la subcadena <locale> y almacenar todas las páginas del manual en <mandir>. Por ejemplo en sistemas que sólo tienen páginas del manual en inglés codificados en ASCII, pueden almacenar las páginas del manual (los directorios man[1-9]) directamente en /usr/man (éstas son las circunstancias y el arreglo tradicional, de hecho). En países para los cuales existe un código de conjunto de caracteres estándar, puede omitir el campo <conjunto_de_caracteres>, pero recomendamos fuertemente que se incluya, especialmente para países con varios estándares en competencia. Varios ejemplos: Idioma Territorio Conjunto de caracteres Directorio Inglés -------- ASCII /usr/man/en Inglés Reino Unido ASCII /usr/man/en_GB Inglés Estados Unidos ASCII /usr/man/en_US Francés Canadá ISO8859-1 /usr/man/fr_CA Francés Francia ISO8859-1 /usr/man/fr_FR Alemán Alemania ISO646-DE /usr/man/de_DE646de Alemán Alemania ISO6937 /usr/man/de_DE6937 Alemán Alemania ISO8859-1 /usr/man/de_DE.88591 Alemán Suiza ISO646-CH /usr/man/de_CH.646ch Japonés Japón JIS /usr/man/ja_JP.jis Japonés Japón SJCS /usr/man/ja_JP.sjis Japonés Japón UJ (o EUC-J) /usr/man/ja_JP.ujis Las páginas del manual para los comandos e información que se encuentra bajo /usr/local están almacenadas en /usr/local/man. las páginas del manual para el sistema X Window están almacenadas en /usr/X11R6/man. Luego todas las jerarquías de páginas del manual en el sistema deben tener la misma estructura que /usr/man. Los directorios vacíos pueden ser omitidos de la jerarquía de páginas del manual. Por ejemplo si, /usr/local/man no tiene páginas del manual en la sección 4 (dispositivos) entonces se puede omitir /usr/local/man/man4. Las secciones de páginas cat (cat[1-9]) que contiene páginas del manual formateadas, también se encuentran dentro de los subdirectorios /<mandir>/<locale>, pero no son requeridas ni deben ser distribuidas en el lugar de las fuentes nroff de las páginas del manual. Las páginas del Manual del sistema de manejo de correo mh deben tener el prefijo mh en todos los nombres de archivos de las páginas. Las páginas del sistema X Window deben tener el prefijo x en todos los nombres de los archivos de las páginas. La práctica de colocar las páginas del manual de diferentes idiomas, en los subdirectorios apropiados de /usr/man también se aplica a las otras jerarquías de páginas del manual, tales como /usr/local/man, y /usr/X11R6/man. (Esta porción de este estándar tambien se aplica más delante en la estructura opcional de /var/catman). A continuación una descripción de cada sección. man1: Programas de usuario. Las páginas del manual que describen los comandos accesibles públicamente se encuentran en esta sección. La mayoría de la documentación de los programas que un usuario necesitará se encuentra aquí. man2: Llamadas al sistema. Esta sección describe todas las llamadas al sistema (requisiciones hacia el kernel de Linux para realizar ciertas operaciones). man3: Subrutinas y funciones de librería. La sección 3 describe programas rutinas de librería que no son llamdas directas al servicios del kernel. Esta sección y la 2 son de interés casi solamente para programadores. man4: Archivos especiales. Esta sección describe los archivos especiales, funciones relacionadas con los manejadores y el soporte para la red que estén disponibles en el sistema. Típicamente, esto incluye los archivos de dispositivo que se encuentran en /dev y la interfaz del kernel para el soporte de protocolos de red. man5: Formatos de archivos. Aquí se encuentran los formatos para muchos de los archivos cuyo formato no sea intuitivo. Ésto incluye varios archivos include, archivos de salida de programas, y archivos de sistema. man6: Juegos.(Binarios Educativos) Esta sección documenta los juegos,demos y programas triviales. Muchas personas tienen una opinión muy diferente de que tan escencial es esta sección. man7: Misceláneos Las páginas del manual que son difíciles de clasificar se designan como pertenecientes a la sección 7. Las de troff y otros macro paquetes de procesamiento de texto se encuentran aquí. man8: Administración del Sistema Aquí se documentan los programas utilizados por los administradores de sistemas para la operación y mantenimiento. Algunos de estos programas son ocasionalmente útiles para usuarios normales. man9: Funciones y variables internas del kernel Éste es utilizado para documentar el código fuente del kernel en los Sistemas Linux. 6.9 /usr/sbin: Binarios de sistema estándar no-esenciales. Este directorio contiene cualesquier binario no-esencial utilizando exclusivamente por el administrador del sistema. Los programas de administración del sistema que sean requeridos para la reparación del sistema, recuperación del sistema, montaje de /usr u otras funciones esenciales deben localizarse en /sbin en vez de aquí. Típicamente /usr/sbin contiene los deamons de red, cualquier herramienta de administración no-escencial y binarios para programas servidores no-críticos. Ésto incluye los deamons de internet que son llamados por inted (llamados in.*) tales como in.telnetd y in.fingerd y los deamons basados en rpc manejados por portmap (llamados rcp.*) tales como rcp.infsd y rcp.mountd. Estos programas servidores son utilizados cuando se entra en un estado que el System V conoce como "run level 2" (estado multi-usuario) y el "run level 3" (estado en-red) o el estado que el BSD conoce como "modo multi-usuario". En este punto se hacen disponibles los servicios para los usuarios (p. ej. soporte de impresión) y hacia otras máquinas (p. ej. exportar NFS). Los programas administrativos instalados localmente deben estar localizados en : /usr/local/sbin. 6.10 /usr/share : Información Independiente de Arquitectura. Cualquier especificación para /usr/share se incluirá en un documento suplementario al FSSTND. Note que es la opinión en consenso del FSSTND que /usr/share no es necesario en la mayoría de los sistemas Linux. En este momento, si nos confinamos a proporcionar una definición extensiva de este directorio, sería una mala idea. Por favor refiérase a la sección 6 para una discusión más de /usr/share. 6.11 /usr/src : Código fuente. /usr/src --- Código fuente linux Código fuente para el kernel de Linux. Cualquier código fuente no-local debe localizarse en este directorio. El único código fuente que siempre debe localizarse en un lugar específico es el código del kernel (cuando exista o esté enlazado como parte de una estructura en /usr/include). Se pueden usar subdirectorios si se desea. El código fuente para el kernel debe siempre estar en su lugar o al menos los archivos include del código del kernel. Esos archivos están localizados en estos directorios. /usr/src/linux/include/asm-<arch> /usr/src/linux/include/linux usr/include debe contener enlaces a estos directorios, llamados asm y /Linux, dados que son necesitados por el compilador de C, al menos /estos archivos include deben siempre ser distribuidos en las instalaciones /que incluye un compilador C. Deben ser distribuidos en el directorio //usr/src/linux de forma que no existan problemas cuando los administradores /del sistema actualicen su versión del kernel por primera vez. /usr/src/linux puede también ser un enlace simbólico a un árbol de código /fuente del kernel. 7. La Jerarquía /var /var Información variable adm Info administrativa del sistema (obsoleto). Enlace simbólico hacia /var/log 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, sólo red nis Archivos base de datos NIS preserve Archivos almacenados después de una falla de ex ó 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 var contiene archivos con información variable. Ésto incluye archivos y /directorios en fila de ejecución, información de bitácora administrativa y /archivos temporales y transitorios. Algunas porciones de /var son no-compartibles entre diferentes sistemas. Por ejemplo, /var/log, /var/lock y /var/run. Otras porciones son compartibles, notablemente /var/spool/mail y /var/spool/news. var se especifica aquí para hacer posible el montar /usr sólo-lectura. /Todo aquello que alguna vez fué en /usr que es escrito durante la operación /normal del sistema (pero no durante la instalación y el mantenimiento del /software) debe ir en /var. Si /var no puede ser una participación separada, es preferible mover /var fuera de la participación raíz pero dentro de la partición /usr (esto se hace algunas veces para reducir el tamaño de la partición raíz o cuando hay poco espacio en la partición raíz). Como sea, /var no debe ser enlazada a /usr, porque hace que la separación entre /usr y /var sea más difícil y seguramente creará un conflicto de nombres, En vez enlace /var a / usr/var. 7.1 /var/adm : Bitácora del sistema y archivos contables (obsoleto) Este directorio ha sido remplazado por /var/log y otros directorios. Debe ser un enlace simbólico a /var/log hasta que todos los programas ya no se refieran más a algún archivo en /var/adm. utmp se ha movido a /var/run. Todos los archivos bitácoras se han movido a /var/log incluyen en el archivo wtmp. El soporte de empaquetado de distribuciones se debe almacenar en /var/lib/<nombre> . Nota: El enlace simbólico /var/adm no debe ser necesario en la mayoría de los sistemas Linux-i386ELF dado que el cambio fué introducido antes que ELF fuera liberado al público. 7.2 /var/catman : Páginas del Manual Formateadas localmente (opcional) Este directorio proporcionara una localización estándar para los sites que proporcionan una partición /usr sólo-lectura, pero que desean permitir el almacenamiento temporal de páginas del manual formateados localmente. Los sites que montan /usr como escribible (p. pj. instalaciones mono-usuarios) pueden escoger no usar /var/catman y escribir las páginas del manual formateadas dentro de los directorios cat[1-9] dentro de /usr directamente. Recomendamos que la mayoría de los sites utilicen una de las siguientes opciones en su lugar. Preformateé todas las páginas del manual dentro de /usr con el programa (catman). : No se permita el almacenamiento temporal de las páginas formateadas del manual y requiera que se ejecute nroff cada vez que se necesite una página. Se permita el almacenamiento temporal local de las páginas del manual en /var/catman. La estructura de /var/catman necesita reflejar ambos, el hecho de la existencia de múltiples jerarquías de página del manual y la posibilidad del uso de múltiples idiomas. Dada una página del manual sin formatear que normalmente aparece en /usr/<ruta1>/man/man[1-9], la versión formateada almacenada temporal debe ir en /var/catman/<ruta2>/cat[1-9], donde <ruta2> es <ruta1>. Los componentes <ruta2> y <ruta1> están ausentes en el caso de /usr/man y /var/catman. Por ejemplo, /usr/man/man1/ls.1 se formatea en /var/catman/cat1/ls.1 y /usr/X11R6/man/<locale>/man3/XtClass.3x lo hace en /var/catman/X11R6/<locale>/cat3/XtClass.3x . Las páginas del manual escritas en /var/catman/cat[1-9] pueden eventualmente, transferirse a /usr/<ruta>/cat[1-9] ó expirarse. De igual forma las páginas del manual formateadas dentro de /usr/<ruta>/cat[1-9] pueden expirarse si no son accesadas en un periodo de tiempo. Si vienen páginas del manual preformateadas con un sistema Linux en un medio sólo-lectura. (p. ej. un COROM), deben estar instaladas en /usr/<ruta>/cat[1-9]. /var/catman está reservado como un lugar de almacenamiento temporal para páginas de manual formateados. 7.3 /var/lib : Información de Estado de Aplicaciones. /var/lib.- Información de Estado de Aplicaciones emacs Directorio del estado de Emacs games Información variable de juegos(archivos de marcadores) news Archivos variables de Cnews/INN texmf Información variable asociada con TeX xdm Archivos de autenticación y bitácoras de error del manejador de despliegues X var/lib/<nombre> es el lugar apropiado para el soporte de /empaquetamiento de todas las distribuciones. Diferentes distribuciones de /Linux pueden utilizar diferentes nombres por supuesto. /var/lib/emacs El directorio del estado GNU Emacs, el lugar donde los archivos de información independiente de la arquitectura, que Emacs modifica cuando se ejecuta, debe ser /var/lib. En el presente, Emacs sólo localiza su directorio de archivos de bloqueo bajo el directorio de estado (en <direstado>/emacs/lock), pero puede hacer uso más extenso del mismo en el futuro. Notablemente, sólo se requiere la adición de una opción sencilla en el programa configure de Emacs para hacer este cambio (antes de compilar). /var/lib/games Así como los subdirectorios antes citados, cualquier información variable relacionada con los juegos que se encuentran en /usr/games, deben estar aquí. /var/lib/games debe incluir la información variable que previamente se encontraba en /usr/lib/games; La información estática, tal como textos de ayuda, descripciones del nivel y demás, debe permanecer en /usr/lib/games. /var/lib/news var/lib/news se debe usar parea almacenar toda la información variable /asociada con los servidores de news tales como Cnews y INN, inclusive el /archivo histórico, el archivo activo y demás. /var/lib/texmf var/lib/texmf se debe usar para almacenar la información variable /asociada con TeX. Particularmente, en /var/lib/texmf/fonts se /almacenarán todas las fuentes tipográficas que son generadas /automáticamente por MakeTeXPK. Debe haber un enlace desde /usr/lib/texmf/fonts/tmp hacia /usr/lib/texmf/fonts. Este enlace permite a los usuarios hacer uso de una sola ruta /usr/lib/texmf/fonts/tfm cuando le hacen cambios a su variable de entorno TEXFONTS (ésta es la ruta por defecto en las herramientas TeX de Karl Berry distribuidas desde ftp.cs.umb.edu:pub/tex [La razón de mencionarlos aquí es que son el estándar de facto en las instalaciones UNIX, estas herramientas son ampliamente usadas entre la comunidad Linux]. Si se utiliza otra distribución de TeX, se debe hacer un enlace desde el directorio de fuentes apropiado hacia /usr/lib/texmf/fonts). El MakeTeXPK que se distribuye con dvipsk colocará los archivos .pk en fonts/pk/<dispositivo>/<nombre_de_la_fuente>, (p.ej. fonts/pk/Canon_CX/cmr10.300pk). Los archivos .pk se pueden purgar periódicamente del árbol /var/lib/texmf o se puede mover dentro del árbol /usr/lib/texmf. Si se usan generadores automáticos de .mf ó .tfm, éstos deben poner su información en los subdirectorios mf ó tfm de /var/lib/texmf/fonts. /var/lib/xdm /var/lib/xdm contiene la información variable de xdm que consiste en los /archivos xdm-errors y cualquier archivo de autoridad xdm. Los binarios de /xdm tales como chooser deben aún estar localizados en la localidad /histórica en /usr/X11R6/lib/X11/xdm. El archivo xdm-pid debe estar en //var/lib/xdm a pesar de existir /var/run. Los archivos restantes deben /estar en /etc/X11/xdm. 7.4 /var/local : Información variable del software que está en /usr/local Este directorio contiene toda la información variable que esté relacionada con el software que se encuentra en /usr/local. Naturalmente la implementación de este subdirectorio se deja a el administrador del sistema . Como sea la información que se puede categotizar en otro lugar del directorio /var, no se debe colocar en /var/local. Por ejemplo, todos los archivos de bloqueo aún irán en /var/lock. 7.5 /var/lock : Archivos de Bloqueo Los archivos de bloqueo deben almacenarse dentro de una estructura del directorio de /var/lock. Para preservar la habilidad de montar /usr sólo-lectura, no se deberá colocar los archivos de bloqueo en la partición /usr. Los archivos de bloqueo de dispositivo, tales como los archivos de bloqueo de dispositivos serie que antes se encontraban en /usr/spool/lock ó en /usr/spool/uucp deben ahora almacenarse en /var/lock. la convención para la nomenclatura que debe utilizarse es LCK... seguido del nombre base del dispositivo. Por ejemplo, para bloquear /dev/cua0 se deberá crear el archivo LCK... cua0. El formato usado para los archivos de bloqueo de dispositivo en Linux deberá ser el formato de archivos de bloqueo HDB UUCP. El formato HDB es almacenar el PID (Identificador del proceso) como un número decimal en ASCII de 10 bytes, con un caracter de línea nueva. Por ejemplo, si el proceso 1230 retiene un archivo de bloqueo, contendrá los siguientes once (11) caracteres: espacio, espacio, espacio, espacio, espacio, espacio, uno, dos, tres, cero y nueva línea. Entonces cualquier cosa que desee usar /dev/cua0, puede leer el archivo de bloqueo y actuar de acuerdo (Todos los archivos de bloqueo en /var/lock deben ser leíbles por todos). 7.6 /var/log : Archivos bitácora y directorios Este directorio contiene archivos bitácora misceláneos. la mayoría de los archivos bitácora se deben escribir en este directorio o subdirectorios apropiados. lastlog Registro del último acceso de cada usuario messages Mensajes del sistema desde syslogd wtmp Registro de todos los accesos y salidas Se puede requerir de un enlace simbólico desde /var/log/utmp hacia /var/run/utmp hasta que ningún programa se refiera a /var/adm/utmp (/var/adm es en sí mismo un enlace simbólico transicional hacia /var/log). 7.7 /var/named : Archivos DNS Este directorio contiene todos los archivos de trabajo del servidor de nombres Internet, named. : Recomendamos que /etc/named.boot sea un enlace simbólico hacia /var/named/named.boot, dado que /etc/named.boot es el archivo de arranque por defecto, si no se dan argumentos a named. 7.8 /var/nis : Archivos de bases de datos del servicio de información dered (NIS) El sistema de información de red (NIS) era anteriormente conocido como las Páginas Amarillas Sun (YP). La funcionalidad y localización de directorios de ambos es el mismo pero el nombre (Yellow Pages) es una marca registrada en el Reino Unido, pertenece a Bristish Telecommunications PLC. y no puede ser usada sin permiso. 7.9 /var/preserve:Archivos guardados después de una colisión o unaterminación inesperada de ex ó vi Este directorio contiene los archivos que son almacenados ante cualquier terminación no-esperada de ex, vi, ó de alguno de sus clones. 7.10 /var/run : Archivos variables de tiempo de ejecución Este directorio contiene archivos con información del sistema que lo describen desde que arrancó. Generalmente los archivos en este directorio se deben limpiar (remover o truncar, según corresponda) al comenzar el proceso de arranque. Los archivos identificados de proceso (PID), que estaban originalmente /etc, se deben colocar en /var/run. La convención de nomenclatura de archivos PID es <nombre-programa>.pid, por ejemplo el archivo PID de crond se llama /var/run/crond.pid. El formato interno de los archivos PID permanecen sin cambio. El archivo debe de consistir del indicador del proceso en decimales codificado como ASCII, seguido por un caracter nueva línea Por ejemplo, si crond fue el proceso número 25, /var/run/cond.pid contendrá 3 caracteres, dos cinco y nueva línea. Los programas que léan archivos PID deben ser flexibles en lo que aceptan, p. ej. deben ignorar los espacios extras, ceros a la izquierda, ausencia del caracter nueva línea o líneas adicionales en el archivo PID. Los programas que crean archivos PID deben utilizar la sencilla especificación dada en el anterior párrafo. El archivo utmp, que almacena información acerca de quién está actualmente utilizando el sistema, se localiza en este subdirectorio. Los programas que mantengan sockets transitorios de dominio UNIX, deben colocarlos en este directorio. 7.11 /var/spool : Directorios de fila de trabajos para procesamiento posterior var/spool es tradicionalmente utilizado para la información local de /máquina que es enviada para procesarse después, hacia o desde subsistemas /UNIX. Por ejemplo, trabajos de impresión que son almacenados aquí para /entrega posterior al daemon de la impresora, el correo que sale es /almacenado aquí para entrega a sistemas remotos y los archivos UUCP son /almacenados aquí para transmisión a los sistemas UUCP vecinos. El correo /que entra y las noticias son almacenados aquí para entregarse a los /usuarios y los trabajos de at y cron son almacenados aquí para ejecución /retardada por el daemon cron. /var/spool at Trabajos de at cron Trabajos de cron lpd Directorio de impresora * mail Archivos caja-postal(buzón) de los usuarios mqueue Fila del correo saliente news Directorio de noticias * rwhod Archivos rwhod smail Directorio de smail * uucp Directorio de UUCP Nota: * Significa fila de trabajos para proceso posterior. Los archivos de bloqueo UUCP deben localizarse en /var/lock. Véa la sección acerca de /var/lock. /var/spool/lpd /var/spool/lpd --- Directorio de fila de trabajos para proceso posterior o impresión <impresora> Directorio que tiene la fila específica de esta impresora El archivo de bloqueo para lpd, lpd.lock debe estar localizado en /var/spool/lpd. El archivo de bloqueo de cada impresora debe localizarse en el directorio <impresora> de la impresora especifica y se debe llamar lock. 7.12 /var/tmp : Archivos temporales, utilizando para mantener /tmp pequeño. Los archivos que están en /var/tmp están almacenados por una duración no especifica. (Recuerde que los directorios temporales del sistema no garantizan mantener la información por ningún periodo particular). La información almacenada en /var/tmp típicamente se limpia en una "forma definida localmente" pero usualmente menos frecuentemente que /tmp. Se puede encontrar información sobre directorios temporales en la selección dedicada a /tmp (arriba). Debe existir un enlace simbólico desde /usr/tmp hacia var/tmp por razones de compatibilidad. 8. Razonamientos adicionales y asuntos sin resolver Esta sección discute varias áreas que pueden requerir mayor explicación. 8.1 ¿Qué es esencial? La respuesta es: esencial para limpiar, crear, preparar, verificar, encontrar y montar otros sistemas de archivos (posiblemente en máquinas remotas). Hay otras definiciones, pero ésta es una definición general que la mayoría de las personas al menos la incorporará en la suya. 8.2 Red La red presenta un dilema interesante, algunas personas quieren separar los binarios y de configuración de la red de los que no lo son. Como sea, estamos en desacuerdo. Sentimos que la red no es un "paquete", sino una parte integral de la mayoría de la máquinas UNIX (y similares). Debido a lo anterior, la red no debe colocarse en un sólo directorio sino localizarse sistemáticamente en los directorios apropiados. /bin :Cualquier cosa que algún usuario querrá utilizar y que estambién considerado vital. hostname, netstat, ping /sbin :Cualquier cosa que sólo root necesita y se considere vital. arp, ifconfig, route /usr/bin : Algúnos binarios que algún usuario querrá utilizar y queno son vitales. finger, rep, rlogin, telnet, etc. /usr/sbin : Algúnos binarios sólo para el administrador que no sonvitales. in.ftpd, inetd, lpd, portmap, etc. Aunque puede parecer confuso al principio (y toma tiempo digerirlo), tiene sentido. Si por alguna razón usted sólo puede montar la partición raíz, y necesita accesar a la red para reparar su sistema, no se quiere que los archivos estén en /usr/etc (como están algunas veces). Los archivos que se necesitan para montar /usr en las situaciones normales (y de emergencia) están colocados dentro del sub-árbol raíz, y cualesquier otros se colocan en /usr, para mantener el tamaño del sistema de archivos raíz pequeño. Los archivos de configuración para la red pertenecen a /etc. 8.3 Estructuras independientes de la arquitectura El directorio /usr/share típicamente contiene archivos independientes de la arquitectura, tales como páginas del manual, zona horaria, información de terminfo, etc. En el momento presente no hay diferentes arquitecturas para Linux, pero con el tiempo, veremos que Linux incluirá otras arquitecturas y otros sistemas similares a UNIX. Nota: Ningún programa nunca deberá hacer referencia a alguna cosa en /usr/share. Por ejemplo, un programa de páginas del manual no debe nunca buscar directamente /usr/share/man/man1/1s.1, sino que siempre se debe referir a /usr/man/man1/1s.1. Cualquier cosa en /usr/share, será "apuntada" a través de uso de enlaces símbolos desde otras áreas del sistema de archivos, tales como /usr/man, /usr/lib/<algo>, etc... Aún se trabaja en las especificaciones de /usr/share. 8.4 Enlaces Simbólicos. Hay muchos usos para los enlaces simbólicos en cada sistemas de archivos. Aunque un estándar como éste no respalda el uso de enlaces simbólicos en la implementación por defecto (Los encontrados después de instalar Linux), se usan frecuentemente con buenos propósitos en diferentes sistemas. El punto es que los enlaces simbólicos deben estar allí para mantener todos los archivos y directorios donde cada quien los espera encontrar. Está preparado para aceptar que ciertos directorios, aún aquellos contenidos en el directorio raíz, aún sean enlaces simbólicos. Por ejemplo en algunos sistemas /home no estará en el raíz, sino enlazado simbólicamente a un directorio /var o algún otro lugar. /home podría tener también su propia partición física y desde luego, ser montado como tal. Similarmente, dado que /usr podría estar en un servidor de archivos central montado vía NFS, /usr/local se puede enlazar simbólicamente a /var/local. Este cambio se puede justificar recordando la razón principal de tener /var: separar directorios de archivos que varían con el tiempo y entre diferentes sistemas y máquinas de aquellos que se pueden compartir y sean sólo-lectura. Algunos sistemas además enlazarán /tmp a /var/<algo> si la partición raíz se vuelve muy pequeña (ó es muy pequeña). Hay más ejemplos de "buenos" usos de enlaces simbólicos, pero todo el asunto se reduce a dos cosas: Los paquetes deben ser capaces de encontrar las cosas donde lo esperan (razonablemente) y los enlaces simbólicos se pueden utilizar para resolver los problemas de muchos casos. Como sea, se pueden generar problemas con el uso de demasiados enlaces simbólicos. este problema incluye sobre-confianza en los enlaces simbólicos para resolver problemas, confusión resultante del sobre-uso de enlaces simbólicos y las preferencias estéticas de diferentes personas. 8.5 Binarios Compilados Estáticamente. Linux se ejecuta corre actualmente en una gama de sistemas, algunos con sólo un usuario y disco pequeño, otros como servidores en ambientes con redes muy grandes, dada esta variedad, este estándar no impone regla sobre qué binarios están compilados estáticamente o dinámicamente, con las siguientes excepciones. Ambos ln y sync, deben existir en /bin; cualquier versión estática se puede colocar en /sbin o remplazar aquellas en /bin. Los grandes sistemas Linux pueden desear incluir otros binarios estáticos (sh, init, mkfs, fsch, tunefs, mount, umount, swapon, swopff, getty, login y otros). Los desarrolladores y los administradores de sistemas, son libres de enlazar dinámica o estáticamente éstos y otros binarios según le convengan, siempre que la localización de los binarios no cambie. En sistemas de red, (especialmente aquellos que no tienen unidades de disco flexible), pueden querer compilar estáticamente ifconfig, route, hostname y otras herramientas de red. Ésto usualmente no es necesario. 9. La lista del correo del FSSTND La lista del correo del FSSTND se encuentra en <Linux-fsstnd@ucsd.edu>. Esta lista estaba originalmente localizada en <Linux-activists@niksula.hut.fi> "Mail Net" como el canal FSSTND. (Para subscribirse a la lista mande correo <listserv@ucsd.edu> con el mensaje "ADD Linux-fsstnd"). Gracias a Operaciones de Red en la Universidad de California en San Diego quien nos permitió utilizar su excelente servidor de listas de correo. 10. Reconocimientos: Se debe dar crédito por este texto a las activistas FSSTND, desarrolladores, administradores de sistemas y usuarios cuyos comentarios fueron esenciales a este estándar. También deseo agradecer a cada contribuyente que ayudó a escribir, compilar y componer éste, un estándar de consenso. Deseo también dar real crédito a aquellos desarrolladores que han visto que el dar a Linux un arreglo común del sistema de archivos es algo que expandirá el desarrollo del sistema operativo Linux. Deseo también la valentía y perseverancia de aquellos desarrolladores de Linux quienes comenzaron a seguir este estándar aún antes de que fuera completado. Los que contribuyeron originalmente: Drew Eckhard (US) drew@colorado.edu Brondon S. Allbery (US) bsa@kf8nh.wariat.org Ian Jackson (UK) ijackson@cus.cam.ac.uk Rik Faith (US) faith@cs.unc.edu Iar Mc Cloghrie (US) ian@ucsd.edu Stephen Harris (UK) sweh@spuddy.mew.co.uk Daniel Quilan (US) Daniel.Quinlan@linux.org Fred N. van Kemper (US) waltje@infomagic.com Mike Sangrey (US) mike@sojurn.lns.pa.us Jhon A. Martir (US) jmartin@csc.com David H. Silber (US) dhs@glowworm.firefly.com Chris Netcalf (US) metcalf@lcs.mit.edu Theodore Tsó (US) tytso@athena.mit.edu Ian Murdock (US) imurdock@debian.org Stephen Tweedie (UK) sct@dcs.ed.ac.uk David C. Niemi (US) niemid@clarck.net Estructura del sistema de archivos de Linux Abril 1996 FUENTE: http://server-die.alc.upv.es/alumno/linux/fsstnd12/fsstnd12.html#toc2 Información del Post
![]()
692 Visitas0 Favoritos 10 Puntos Creado el: Septiembre 12, 2009, 09:28:40 pm Categoría: Distros Tags: unix GNU debian LINUX estructura sistema de archivos Agregar a:
|