BuleBule

Registrate y eliminá la publicidad! Eliminar el uso del menú DOCUMENTOS RECIENTES en Ubuntu (o en cualquier distribución con Gnome) A mi, particularmente por un tema de privacidad y que comparto la computadora con otras personas, me molesta mucho que todos los documentos que voy abriendo generen enlaces (accesos directos) en el menú “documentos recientes”. Jamás abrí un documento desde ese menú, y en ese sentido nunca me sirvió para nada. Además tengo que estar siempre pendiente de ir borrando su contenido siempre que dejo la pc. Es por eso que decidí bloquear el uso de dicho menú para que los documentos que vaya abriendo no se guarden ahí. Como hacerlo En nuestra carpeta personal (por ejemplo: “/home/taringa”) existe un archivo llamado “ .recently-used.xbel “. Lo que debemos hacer es borrar este archivo, y crear una carpeta con el mismo nombre (a saber: .recently-used.xbel). Listo, eso es todo. (Lo de la carpeta es para que cuando el sistema intente generar el archivo nuevamente al abrir cualquier documento, no pueda hacerlo ya que hay una carpeta con el mismo nombre.) Ahora podremos abrir cualquier documento tranquilamente, que el menú permanecerá siempre vacío como si no hubieramos abierto nada. PD: Yo por las dudas antes de borrar el archivo, me hice una copia de seguridad del mismo (creé un archivador .tar.gz en la misma carpeta, o tambien se puede copiar a otro lado) Si lo prefieren hacer por consola cd /home/taringa (por ejemplo) rm .recently-used.xbel mkdir .recently-used.xbel Como verán es muy sencillo, pero muy útil. FUENTE: Algún foro hace mucho tiempo y mi memoria

Encontré este manual de sudo, y me parece muy completo, conciso y bien explicado. Les va a venir bien a más de un usuario de ubuntu por ejemplo, que tira sudo sin saber bien que es. Como se verá, SUDO es un programa que tiene múltiples posibilidades de configuración, y es muy útil especialmente en sistemas con administradores y varios usuarios. Aprendí muchas cosas que no sabía leyendo este manual, y me parece que vale la pena. MANUAL DE SUDO, VISUDO Y SUDOERS Copyright 2005-2008 Sergio González Durán Se concede permiso para copiar, distribuir y/o modificar este documento siempre y cuando se cite al autor y la fuente de linuxtotal.com.mx y según los términos de la GNU Free Documentation License, Versión 1.2 o cualquiera posterior publicada por la Free Software Foundation. autor: [email protected] En ambientes donde varios usuarios usan uno o más sistemas GNU/Linux, es necesario otorgar distintos permisos o privilegios para que estos puedan hacer uso de comandos propios del usuario administrador 'root'. Totalmente fuera de lugar e impensable es 'entregar' la contraseña de root para que los usuarios puedan hacer uso de los programas propios de sus funciones pero que son propiedad de 'root'. Por otro lado, hacer uso del comando su tampoco es práctico porque es lo mismo, necesitan la contraseña de root, asi que la mejor alternativa es hacer uso de sudo. ¿Exáctamente que es y que hace sudo?. sudo permite implementar un control de acceso altamente granulado de que usuarios ejecutan que comandos. Si un usuario normal desea ejecutar un comando de root (o de cualquier otro usuario), sudo verifica en su lista de permisos y si está permitido la ejecución de ese comando para ese usuario, entonces sudo se encarga de ejecutarlo. Es decir, sudo es un programa que basado en una lista de control (/etc/sudoers) permite (o no) la ejecución al usuario que lo invocó sobre un determinado programa propiedad de otro usuario, generalmente del administrador del sistema 'root'. sudo, para fines prácticos se puede dividir en tres partes: . sudo, el comando con permisos de SUID, que los usuarios usan para ejecutar otros comandos a los que se les permite usar. . visudo, el comando que permite al administrador modificar /etc/sudoers. . /etc/sudoers, el archivo de permisos que le indica a sudo que usuarios ejecutan cuáles comandos. sudo sudo (SUperuser DO) lo ejecuta un usuario normal, al que se supone tiene permisos para ejecutar cierto comando. Entonces, sudo requiere que los usuarios se autentifiquen a si mismos a través de su contraseña para permitirles la ejecución del comando. Veamos un ejemplo: $ sudo /sbin/ifconfig Password: eth0 Link encap:Ethernet HWaddr 4C:00:10:60:5F:21 inet addr:200.13.110.62 Bcast:200.13.110.255 Mask:255.255.255.0 inet6 addr: fe80::4e00:10ff:fe60:5f21/64 Scope:Link ... Como se podrá observar se usa el comando sudo seguido del comando (con toda su ruta si es que este no esta en el PATH del usuario) al que se tiene permiso. sudo pregunta por la contraseña del usuario que ejecuta el comando y listo. Por defecto, después de hacer lo anterior tendrás 5 minutos para volver a usar el mismo comando u otros a los que tuvieras derecho, sin necesidad de ingresar la contraseña de nuevo. Si se quiere extender el tiempo por otros 5 minutos usa la opción sudo -v (validate). Por el contario, si ya terminaste lo que tenías que hacer, puedes usar sudo -k (kill) para terminar con el tiempo de gracia de validación. Ahora bien, ¿Qué comandos son los que puedo utilizar?, pues la opción -l es la indicada para eso: $ sudo -l User sergio may run the following commands on this host: (root) /sbin/ifconfig (root) /sbin/lspci En el caso anterior se ejecutó un comando de root, pero no tiene que ser asi, también es posible ejecutar comandos de otros usuarios del sistema indicando la opción -u: $ sudo -u ana /comando/de/ana Una de las opciones más interesantes es la que permite editar archivos de texto de root (claro, con el permiso otorgado en 'sudoers' como se verá más adelante), y esto se logra con la opción -e, esta opción esta ligada a otro comando de sudo llamado sudoedit que invoca al editor por defecto del usuario, que generalmente es 'vi'. $ sudo -e /etc/inittab (Permitira modificar el archivo indicado como si se fuera root) Cuando se configura sudo se tienen múltiples opciones que se pueden establecer, estás se consultan a través de la opción -L $> sudo -L Available options in a sudoers ``Defaults'' line: syslog: Syslog facility if syslog is being used for logging syslog_goodpri: Syslog priority to use when user authenticates successfully syslog_badpri: Syslog priority to use when user authenticates unsuccessfully long_otp_prompt: Put OTP prompt on its own line ignore_dot: Ignore '.' in $PATH mail_always: Always send mail when sudo is run mail_badpass: Send mail if user authentication fails mail_no_user: Send mail if the user is not in sudoers mail_no_host: Send mail if the user is not in sudoers for this host mail_no_perms: Send mail if the user is not allowed to run a command tty_tickets: Use a separate timestamp for each user/tty combo lecture: Lecture user the first time they run sudo lecture_file: File containing the sudo lecture authenticate: Require users to authenticate by default root_sudo: Root may run sudo ... varias opciones más Bastante útil, ya que nos muestra las opciones y una pequeña descripción, estás opciones se establecen en el archivo de configuración 'sudoers'. Una de las opciones más importantes de consulta es -V, que permite listar las opciones (defaults) establecidas por defecto para sudo todos los usuarios, comandos, equipos, etc. Más adelante en este tutorial, aprenderemos como establecer opciones específicas para ciertos usuarios, comandos o equipos. NOTA: tienes que ser 'root' para usar esta opción. # sudo -V Sudo version 1.6.9p5 Sudoers path: /etc/sudoers Authentication methods: 'pam' Syslog facility if syslog is being used for logging: local2 Syslog priority to use when user authenticates successfully: notice Syslog priority to use when user authenticates unsuccessfully: alert Send mail if the user is not in sudoers Lecture user the first time they run sudo Require users to authenticate by default Root may run sudo Log the hostname in the (non-syslog) log file Allow some information gathering to give useful error messages Visudo will honor the EDITOR environment variable Set the LOGNAME and USER environment variables Reset the environment to a default set of variables Length at which to wrap log file lines (0 for no wrap): 80 Authentication timestamp timeout: 5 minutes Password prompt timeout: 5 minutes Number of tries to enter a password: 3 Umask to use or 0777 to use user's: 022 Path to log file: /var/log/sudo.log ... varias opciones más listadas Con intención, trunque el listado anterior en la línea "Path to log file: /var/log/sudo.log", donde se indica cual es el archivo 'log' o de bitacora por defecto de sudo, en este archivo se loguea absolutamente todo lo que se haga con sudo, que usuarios ejecutaron que, intentos de uso, etc. visudo Permite la edición del archivo de configuración de sudo sudoers. Invoca al editor que se tenga por defecto que generalemente es 'vi'. visudo cuando es usado, bloquea el archivo /etc/sudoers de tal manera que nadie más lo puede utilizar, esto por razones obvias de seguridad que evitarán que dos o más usuarios administradores modifiquen accidentalmente los cambios que el otro realizó. Otra característica importande de visudo es que al cerrar el archivo, verifica que el archivo este bien configurado, es decir, detectará si hay errores de sintaxis principalmente en sus múltiples opciones o reglas de acceso que se tengan. Por esta razón no debe editarse /etc/sudoers directamente (perfectamente posible ya que es un archivo de texto como cualquier otro) sino siempre usar visudo. Si al cerrar visudo detecta un error nos mostrará la línea donde se encuentra, y la pregunta "What now?": >>> sudoers file: syntax error, line 15 <<< What now? Se tienen tres opciones para esta pregunta: e - edita de nuevo el archivo, colocando el cursor en la línea del error (si el editor soporta esta función.) x - salir sin guardar los cambios. Q - salir y guarda los cambios. Por defecto el archivo de configuración es /etc/sudoers pero se pueden editar otros archivos que no sean ese y que se aplique la sintaxis de sudo, y esto se logra con la opción -f (visudo -f /otro/archivo). Si tan solo se desea comprobar que /etc/sudoers esta bien configurado se usa la opción -c, toma por el archivo de configuración por defecto o si no se indica algún otro. #> visudo -c /etc/sudoers file parsed OK La opción -s activa el modo 'estricto' del uso de visudo, es decir no solo se comprobará lo sintáctico sino también el orden correcto de las reglas, por ejemplo si se define el alias para un grupo de comandos y este se usa antes de su definición, con esta opción se detectará este tipo de errores. Sudoers Archivo de configuración de sudo, generalmente ubicado bajo /etc y se modifica a través del uso de visudo. En este archivo se establece quien (usuarios) puede ejecutar que (comandos) y de que modo (opciones), generando efectivamente una lista de control de acceso que puede ser tan detallada como se desee. Es más fácil entender sudo si dividimos en tres partes su posible configuración, estás son: . Alias . Opciones (Defaults) . Reglas de acceso Por extraño que parezca ninguna de las secciones es obligatoria, o tienen que estar en algún orden específico, pero la que al menos debe de existir es la tercera, que es la definción de los controles o reglas de acceso. Se detallará cada uno de estos en un momento. Para los que les gusta saber más la cuestión técnica es interesante saber que la construcción de un archivo sudoers esta basado en la forma BNF (Backus-Naur Form), concretamente en versión extendida (EBNF), si estudiaste algún curso de informática universitario seguramente sabes de lo que hablo. EBNF describe de una forma precisa y exacta la gramática de un lenguaje, esta se va creando a través de reglas de producción que a la vez son la base para ser referenciadas por otras reglas. Afortunadamente no necesitas saber nada de esto, solo entender como se aplican estas reglas. Alias Un alias se refiere a un usuario, un comando o a un equipo. El alias engloba bajo un solo nombre (nombre del alias) una serie de elementos que después en la parte de definición de reglas serán refiridos aplicados bajos cierto criterio. Es decir, regresando a EBNF estamos creando las reglas de producción inicial. La forma para crear un alias es la siguiente: tipo_alias NOMBRE_DEL_ALIAS = elemento1, elemento2, elemento3, ... elementoN tipo_alias NOMBRE1 = elemento1, elemento2 : NOMBRE2 = elemento1, elemento2 En el segundo caso, separado por ":" es posible indicar más de un alias en una misma definción. El tipo_alias define los elementos, es decir, dependiendo del tipo de alias serán sus elementos. Los tipo de alias son cuatro y son los siguientes: Cmnd_Alias - define alias de comandos. User_Alias - define alias de usuarios normales. Runas_Alias - define alias de usuarios administradores o con privilegios. Host_Alias - define alias de hosts o equipos. El NOMBRE_DEL_ALIAS puede llevar letras, números o guión bajo ( _ ) y DEBE de comenzar con una letra mayúscula, se acostumbra a usarlos siempre en mayúsculas. Los elementos del alias varian dependiendo del tipo de alias, asi que veámoslos por partes asi como varios ejemplos para que comience a quedar claro todo esto. Cmnd_Alias Definen uno o más comandos y otros alias de comandos que podrán ser utilizados después en alias de usuarios. Ejemplos: Cmnd_Alias WEB = /usr/sbin/apachectl, /usr/sbin/httpd, sudoedit /etc/httpd/ Indica que a quien se le aplique el alias WEB podrá ejecutar los comandos apachectl, httpd y editar todo lo que este debajo del directorio /etc/httpd/, nótese que debe de terminar con '/' cuando se indican directorios. También, la ruta completa a los comandos debe ser indicada. Cmnd_Alias APAGAR = /usr/bin/shutdown -h 23\:00 Al usuario que se le asigne el alias APAGAR podrá hacer uso del comando 'shutdown' exactamente con los parámetros como están indicados, es decir apagar -h (halt) el equipo a las 23:00 horas. Nótese que es necesario escapar el signo ':', asi como los símbolos ' : , = \ Cmnd_Alias NET_ADMIN = /sbin/ifconfig, /sbin/iptables, WEB NET_ADMIN es un alias con los comandos de configuración de interfaces de red ifconfig y de firewall iptables, pero además le agregamos un alias previamente definido que es WEB, asi que a quien se le asigne este alias podrá hacer uso de los comandos del alias WEB. Cmnd_Alias TODO_BIN = /usr/bin/, !/usr/bin/rpm A quien se le asigne este alias podrá ejecutar todos los comandos que estén dentro del directorio /usr/bin/ menos el comando 'rpm' ubicado en el mismo directorio. NOTA IMPORTANTE: este tipo de alias con un permiso muy amplios menos '!' algo, generalmente no son una buena idea, ya que comandos nuevos que se añadan después a ese directorio también podrán ser ejecutados, es mejor siempre definir específicamente lo que se requiera. User_Alias Definen a uno o más usuarios, grupos del sistema (indicados con %), grupos de red (netgroups indicados con +) u otros alias de usuarios. Ejemplos: User_Alias MYSQL_USERS = andy, marce, juan, %mysql Indica que al alias MYSQL_USERS pertenecen los usuarios indicados individualmente más los usuarios que formen parte del grupo 'mysql'. User_Alias ADMIN = sergio, ana 'sergio' y 'ana' pertenecen al alias ADMIN. User_Alias TODOS = ALL, !samuel, !david Aqui encontramos algo nuevo, definimos el alias de usuario TODOS que al poner como elemento la palabra reservada 'ALL' abarcaría a todos los usuarios del sistema, pero no deseamos a dos de ellos, asi que negamos con '!', que serían los usuarios 'samuel' y 'david'. Es decir, todos los usuarios menos esos dos. NOTA IMPORTANTE: este tipo de alias con un permiso muy amplios menos '!' algo, generalmente no son una buena idea, ya que usuarios nuevos que se añadan después al sistema también serán considerados como ALL, es mejor siempre definir específicamente a los usuarios que se requieran. ALL es válido en todos los tipos de alias. User_Alias OPERADORES = ADMIN, alejandra Los del alias ADMIN más el usuario 'alejandra'. Runas_Alias Funciona exactamente igual que User_Alias, la única diferencia es que es posible usar el ID del usario UID con el caracter '#'. Runas_Alias OPERADORES = #501, fabian Al alias OPERADORES pertenecen el usuario con UID 501 y el usuario 'fabian' Host_Alias Definen uno o más equipos u otros alias de host. Los equipos pueden indicarse por su nombre (si se encuentra en /etc/hosts) por nombre de dominio, si existe un resolvedor de dominios, por dirección IP, por dirección IP con máscara de red. Ejemplos: Host_Alias LANS = 192.168.0.0/24, 192.168.0.1/255.255.255.0 El alias LANS define todos los equipos de las redes locales. Host_Alias WEBSERVERS = 172.16.0.21, web1 : DBSERVERS = 192.168.100.10, dataserver Se define dos alias en el mismo renglón: WEBSERVERS y DBSERVERS con sus respectivas listas de elementos, el separador ':' es válido en cualquier definición de tipo de alias. Opciones (defaults) Las opciones o defaults permiten definir ciertas características de comportamiento para los alias previamente creados, para usuarios, usuarios privilegiados, para equipos o de manera global para todos. No es necesario definir opciones o defaults, sudo ya tiene establecidas el valor de cada uno, y es posible conocerlas a través de sudo -V (ver en la sección sudo de este tutorial). Sin embargo, la potencia de sudo está en su alta granularidad de configuración, asi que es importante conocer como establecer opciones espécificas. Las opciones o defaults es posible establecerlos en cuatro niveles de uso: . De manera global, afecta a todos . Por usuario . Por usuario privilegiado . Por equipo (host) Se usa la palabra reservada 'Defaults' para establecer las opciones y dependiendo del nivel que deseamos afectar su sintaxis es la siguiente: . Global: Defaults opcion1, opcion2 ... . Usuario: Defaults:usuario opcion1, opcion2 ... . Usuario Privilegiado: Defaults>usuario opcion1, opcion2 ... . Equipo: Defaults@equipo opcion1, opcion2 ... La lista de opciones es algo extensa, pueden consultarse en las páginas del manual (man sudoers) o en el excelente manual sobre sudo del sitio web de www.rpublica.net , está en español y define muy claramente lo que significa cada opción. En este tutorial de LinuxTotal.com.mx me concretaré a ejemplificar varios ejemplos del uso de establecer opciones. Los defaults los divide el manual (man sudoers) en cuatro: flags o booleanos, enteros, cadenas y listas. Veamos entonces algunos ejemplos de uso para cada uno de ellos: flags o booleanos Generalemente se usan de manera global, simplemente se indica la opción y se establece a 'on' para desactivarla 'off' se antepone el símbolo '!' a la opción. Es necesario consultar el manual para saber el valor por defecto 'on' o 'off' para saber si realmente necesitamos invocarla o no. Defaults mail_always Establece a 'on' la opción 'mail_always' que enviara un correo avisando cada vez que un usuario utiliza sudo, a la vez, este opción requiere que 'mailto_user' este establecida. Defaults !authenticate, log_host Desactiva 'off' el default 'authenticate' que por defecto esta activado 'on' e indica que todos los usuarios que usen sudo deben identificarse con su contraseña, obviamente esto es un ejemplo y sería una pésima idea usarlo realmente, ya que ningún usuario necesitaria autenticarse, esto es porque estamos usando Defaults de manera global. La segunda opción 'log_host' que por defecto está en 'off' la activamos y bitacoriza el nombre del host cuando se usa un archivo (en vez de syslog) como bitácora de sudo. Defaults:ana !authenticate Aqui se aprecia algo más lógico, usamos opciones por usuario en vez de global, indicando que el usuario 'ana' no requerira auténticarse. Pero todos los demás si. Defaults>ADMIN rootpw Opciones para usuarios privilegiados, en vez de usar una lista de usuarios, usamos un alias 'ADMIN' que se supone fue previamente definido, y establecemos en 'on' la opción 'rootpw' que indica a sudo que los usuarios en el alias 'ADMIN' deberán usar la contraseña de 'root' en vez de la propia. Enteros Tal como su nombre lo indica, manejan valores de números enteros en sus opciones, que deben entonces usarse como opción = valor. Defaults:fernanda, regina passwd_tries = 1, passwd_timeout = 1 Ejemplo donde se aprecia el uso de opciones con valores enteros. En este caso se establecen opciones para los usuarios 'fernanda' y 'regina' solamente, que solo tendrán una oportunidad de ingresar la contraseña correcta 'passwd_tries' el valor por defecto es de 3 y tendrán un minuto para ingresarla 'passwd_timeout' el valor por defecto son 5 minutos. La mayoría de las opciones de tiempo o de intentos, al establecerlas con un valor igual a cero entonces queda ilimitado la opción. Defaults@webserver umask = 011 Se establecen opciones solo para los usuarios que se conectan al servidor 'webserver' y el valor 'umask' indica que si mediante la ejecución del comando que se invoque por sudo es necesario crear archivos o diectorios, a estos se les aplicará la máscara de permisos indicada en el valor de la opción. Cadenas Son valores de opciones que indican mensajes, rutas de archivos, etc. Si hubiera espacios en el valor es necesario encerrar el valor entre comillas dobles (" ". Defaults badpass_message = "Intenta de nuevo: " Para todos los usuarios, cuando se equivoquen al ingresar la contraseña, es el mensaje que saldría. En este caso la opción por defecto es "Sorry: try again". Listas Permite establecer/eliminar variables de entorno propias de sudo. Los 'Defaults' para variables es de los menos usados en las configuraciones de sudo y ciertamente de los más confusos. Para entender como se aplican es más fácil si primero ejecutas como 'root' el comando sudo -V, y al final del listado encontrarás en mayúsculas las posibles variables de entorno que se pueden establecer o quitar y que vienen del shell. Solo existen tres opciones de listas: env_check, env_delete y env_keep, las listas pueden ser remplazadas con '=', añadidas con '+=', eliminadas con '-=' o deshabilitadas con '!'. Con un par de ejemplos quedará más claro. Defaults env_delete -= HOSTNAME Elimina la variable de entorno 'HOSTNAME', (pero preserva todas las demás que hubiera) y comandos que se ejecuten bajo sudo y que requieran de esta variable no la tendrían disponible. Defaults env_reset Defaults env_check += DISPLAY, PS1 La primera opción 'env_reset' reinicializa las variables de entorno que sudo utilizará o tendrá disponibles, y solo quedan disponibles LOGNAME, SHELL, USER y USERNAME. La siguiente línea indica que agregue (+=) a lo anterior, también la variable de entorno DISPLAY a su valor establecido antes del reset. Reglas de acceso Aunque no es obligatorio declarar alias, ni opciones (defaults), y de hecho tampoco reglas de acceso, pues el archivo /etc/sudoers no tendría ninguna razón de ser si no se crean reglas de acceso. De hecho podríamos concretarnos a crear solamente reglas de acceso, sin opciones ni alias y podría funcionar todo muy bien. Las reglas de acceso definen que usuarios ejecutan que comandos bajo que usuario y en que equipos. La mejor y (según yo, única manera) de entender y aprender a configurar sudoers es con ejemplos, asi que directo al grano: usuario host = comando1, comando2, ... comandoN Sintaxis básica, 'usuario' puede ser un usuario, un alias de usuario o un grupo (indicado por %), 'host' puede ser ALL cualquier equipo, un solo equipo, un alias de equipo, una dirección IP o una definición de red IP/máscara, 'comandox' es cualquier comando indicado con su ruta completa. Si se termina en '/' como en /etc/http/ entonces indica todos los archivos dentro de ese directorio. daniela ALL = /sbin/iptables Usuario 'daniela' en cualquier host o equipo puede utiliar iptables. ADMIN ALL = ALL Los usuarios definifos en el alias 'ADMIN' desde cualquier host pueden ejecutar cualquier comando. %gerentes dbserver = (director) /usr/facturacion, (root) /var/log/* Un ejemplo más detallado. Los usuarios que pertenezcan al grupo del sistema llamado 'gerentes' pueden en el equipo llamado 'dbserver' ejecutar como si fueran el usuario 'director' la aplicación llamada 'facturacion', además como usuarios 'root' pueden ver el contendido de los archivos que contenga el directorio /var/log. Lo anterior intoduce algo nuevo, que en la lista de comandos es posible indicar bajo que usuario se debe ejecutar el permiso. Por defecto es el usuario 'root', pero no siempre tener que asi. Además la lista 'hereda' la primera definición de usuario que se indica entre paréntesis ( ), por eso si se tiene más de alguno hay que cambiar de usuario en el comando conveniente, el ejemplo anterior también sería válido de la siguiente manera: %gerentes dbserver = /var/log/*, (director) /usr/facturacion No es necesario indicar (root) ya que es el usuario bajo el cual se ejecutan los comandos por defecto. También es válido usar (ALL) para indicar bajo cualquier usuario. El ejemplo siguiente da permisos absolutos. sergio ALL = (ALL) ALL Se establece permiso para el usuario 'sergio' en cualquier host, ejecutar cualquier comando de cualquier usuario, por supuesto incluyendo los de root. SUPERVISORES PRODUCCION = OPERACION Una regala formada solo por alias. En el alias de usuario 'SUPERVISORES' los usuarios que esten indicados en ese alias, tendrán permiso en los equipos definidos en el alias de host 'PRODUCCION', de ejecutar los comandos definidos o listados en el alias de comandos 'OPERACION'. En este último ejemplo se aprecia lo últil que pueden ser los alias, ya que una vez definida la regla, solo debemos agregar o eliminar elementos de las listas de alias definidos previamente. Es decir, se agrega un equipo más a la red, se añade al alias 'PRODUCCION', un usuario renuncia a la empresa, alteramos el alias 'SUPERVISORES' eliminándolo de la lista, etc. checo ALL = /usr/bin/passwd *, !/usr/bin/passwd root Este es un ejemplo muy interesante de la potencia y flexibilidad . Al usuario 'checo', desde cualquier equipo, tiene permiso de cambiar la contraseña de cualquier usuario (usando el comando 'passwd'), excepto '!' la contraseña del usuario 'root'. Lo anterior se logra mediante el uso de argumentos en los comandos. En el primer ejemplo '/usr/bin/passwd *' el asterisco indica una expansión de comodin (wildcard) que indica cualquier argumento, es decir, cualquier usuario. En el segundo caso '!/usr/bin/passwd root', si indica un argumento específico 'root', y la '!' como ya se sabe indica negación, negando entonces el permiso a cambiar la contraseña de root. Cuando se indica el comando sin argumentos: /sbin/iptables sudo lo interpreta como 'puede usar iptables con cualquiera de sus argumentos'. mariajose ALL = "/sbin/lsmod" Al estar entre comillas dobles un comando, entonces sudo lo interpreta como 'puede hacer uso del comando lsmod pero sin argumentos'. En este caso el usuario 'mariajose' podrá ver la lista de módulos del kernel, pero solo eso. Tags (etiquetas de comandos) Cuando se definen reglas, en la lista de comandos, estos pueden tener cero (como en los ejemplos anteriores) o más tags. Existen 6 de estas etiquetas o tags, NOPASSWD Y PASSWD Por defecto sudo requiere que cualquier usuario se identifique o auténtifique con su contraseña. Aprendimos en la sección de 'Opciones' o 'Defaults' que es posible indicar que un usuario o alias de usuario no requiera de autentificación. Pero el control granular propio de sudo, permite ir aun más lejos al indicar a nivel de comandos, cuáles requieren contraseña para su uso y cuáles no. gerardo webserver = NOPASSWD: /bin/kill, /usr/bin/lprm, /etc/httpd/conf/ Usuario 'gerardo' en el equipo 'webserver' no requerira contraseña para los comandos listados. El tag se hereda, es decir no solo el primer elemento de la lista de comandos, sino los subsiguientes. Suponiendo que el último '/etc/httpd/conf/' elemento, que permite modificar cualquier archivo contenido en el directorio, si deseamos que use contraseña, lo siguiente lo conseguirá: gerardo webserver = NOPASSWD: /bin/kill, /usr/bin/lprm, PASSWD: /etc/httpd/conf/ Aunque ya que solicitar contraseña es el default o defecto preestablecido, lo anterior también funcionará de la siguiente manera: gerardo webserver = /etc/httpd/conf/, NOPASSWD: /bin/kill, /usr/bin/lprm, NOEXEC Y EXEC Este es un tag muy importante a considerar cuando sobre se otorgan permisos sobre programas que permiten escapes a shell (shell escape), como en el editor 'vi' que mediante el uso de '!' es posible ejecutar un comando en el shell sin salir de 'vi'. Con el tag NOEXEC se logra que esto no suceda, aunque no hay que tomarlo como un hecho, ya que siempre existe la posibilidad de vulnerabilidades no conocidas en los múltiples programas que utilizan escapes a shell. Al igual que los tags anteriores, el tag se hereda y se deshabilita con su tag contrario (EXEC), en caso de que en la lista de comandos hubiera varios comandos. valeria ALL = NOEXEC: /usr/bin/vi SETENV Y NOSETENV Una de las múltiples opciones que pueden establecerse en la sección 'Defaults' u 'opciones' es la opción booleana o de flag 'setenv' que por defecto y para todos los usuarios esta establecida en 'off'. Esta opción si se activa por usuario (Defaults:sergio setenv) permitirá al usuario indicado cambiar el entorno de variables del usuario del cual tiene permisos de ejecutar comandos, y como generalmente este es 'root' pues es obvio que resulta bastante peligrosa esta opción. A nivel de lista de comandos, es posible entonces especificar el tag 'SETENV' a un solo comando o a una pequeña lista de estos y solo cuando se ejecuten estos se podrán alterar su entorno de variables. Es decir, en vez de establecerlo por usuario, sería mas conveniente establecerlo por comando a ejcutarse solamente. ADMIN ALL = SETENV: /bin/date, NOSETENV ALL A los usuarios definidos en el alias de usuario 'ADMIN' en cualquier host, pueden alterar las variables de entorno cuando ejecuten el comando 'date' (que puede ser útil por ejemplo para cambiar variables del tipo LOCALE), y cualquier otro comando, no tendrá esta opción al habilitar el tag contrario 'NOSETENV'. Y ya que este es el default, también sería válido de la siguiente manera y harían lo mismo: ADMIN ALL = ALL, SETENV: /bin/date ARCHIVO /ETC/SUDOERS DE EJEMPLO Para concluir este manual, veamos un pequeño ejemplo de un archivo /etc/sudoers: # *********************** # LinuxTotal.com.mx, ejemplo de un archivo sudoers # [email protected] # *********************** # *********************** # DEFINCION DE ALIAS # *********************** # administradores con todos los privilegios User_Alias ADMINS = sergio, ana # administradores de red - network operators User_Alias NETOPS = marcela, andrea # webmasters - User_Alias WEBMAS = cristina, juan # supervisores de producción (todos los del grupo de sistema supervisores) User_Alias SUPPRO = samuel, %supervisores # usuarios que pueden conectarse desde Internet User_Alias INETUS = NETOPS, ADMINS, samuel # servidores web Host_Alias WEBSERVERS = 10.0.1.100, 10.0.1.101 # servidores de aplicaciones Host_Alias APLICACIONES = WEBSERVERS, 10.0.1.102, 10.0.1.103, mailserver # comandos de red permitidos Cmnd_Alias REDCMDS = /sbin/ifconfig, /sbin/iptables # comandos de apache Cmnd_Alias APACHECMDS = /usr/sbin/apachectl, /sbin/service httpd * # *********************** # DEFINCION DE OPCIONES # *********************** # Los usuarios administradores, requieren autentificarse con la contraseña de 'root' Defaults>ADMINS rootpw # Para todos los usuarios, tienen hasta dos intentos para ingresar su contraseña y 3 minuto para que esta expire Defaults passwd_tries = 4, passwd_timeout = 1 # Los usuarios que se conectan desde Internet, solo tienen una oportunidad y cero timeout lo que implica # que cada comando que usen a través de sudo requerira siempre de autentificación. Defaults:INETUS passwd_tries = 1, passwd_timeout = 0 # Máscara de directorios y archivos por default, para los que ejecuten sudo en los servidores web Defaults@WEBSERVERS umask = 022 # *********************** # DEFINCION DE REGLAS # *********************** # administradores todo se les permite en cualquier equipo (¡¡¡¡¡cuidado con esto en la vida real!!!!! ADMINS ALL = (ALL) ALL # administradores de red, en todos los equipos, los comandos de red NETOPS ALL = REDCMDS # webmasters, en los servidores web con los comandos indicados en apachecmds y además sin necesidad # de contraseña acceder a las bítacoras de apache y reiniciar los servidores. WEBMAS WEBSERVERS = APACHECMDS, NOPASSWD: /var/log/apache/, /sbin/reboot # supervisores, pueden ejecutar los comandos indicados en los equipos indicados en el alias # aplicaciones y además son ejecutados bajo el usuario apps. SUPPRO APLICACIONES = NOEXEC: (apps) /usr/local/facturacion.exe, /usr/local/ventas.exe, /usr/local/nomina.exe # no definidos por alias previos, sino directamente # regina es de recursos humanos y puede cambiar contraseñas de cualquier usuario menos de root regina ALL = /usr/bin/passwd *, !/usr/bin/passwd root # david, puede apagar los equipos de aplicaciones david APLICACIONES = /sbin/shutdown, /sbin/halt # El equipo firewall de la red puede ser reiniciado (no apagado) por fernanda que es asistente de redes fernanda firewall = /sbin/shutdown -r now Referencias Como siempre, la referencia más a la mano la tienes en las páginas de manual: man sudo man visudo man sudoers Y en los siguientes sitios encuentras información que complementa esta manual. http://www.sudo.ws/ - sitio oficial de sudo http://www.rpublica.net/sudo/sudo.html - Aqui puedes consultar en español, varias de las opciones de sudo, además de que es un buen manual de sudo en lo general. http://www.onlamp.com/pub/a/bsd/2002/08/29/Big_Scary_Daemons.html - sitio en inglés con una explicación muy completa de como funciona sudo. ------FIN------ FUENTE: http://www.linuxtotal.com.mx/index.php?cont=info_admon_014

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) ESTRUCTURA DEL SISTEMA DE ARCHIVOS DE LINUX Grupo de Standard de el Sistema de Archivos Daniel Quinlan Traductor: Israel Barrientos mailto:[email protected] Maquetador Linuxdoc-SGML: Antonio Ismael Olea González, mailto:[email protected] 2:345/[email protected] r1.2, abril de 1996 El proceso abierto y distribuido en el cual el sistema operativo Linux se ha desarrollado propicia un rápido crecimiento, tanto del sistema operativo, como de aplicaciones, y distribuciones integradas. Por tanto, existe la necesidad de la estandarización de la estructura del sistema de archivos de Linux. Este documento intenta especificar la localización estándar de archivos y directorios en sistemas Linux. Una estructura del sistema de archivos estandarizada permite a usuarios, desarrolladores, y distribuidores, el obtener componentes del sistema de varias fuentes que trabajarán juntas tan bien como si hubiesen sido desarrolladas bajo un proceso de desarrollo centralizado. Ésto también facilita la administración del sistema, así como el desarrollo de paquetes de segundas y terceras personas, y la escritura de documentación que no depende de la implementación. 1. Advertencia legal Linux no es una Marca Registrada y no tiene conexión con UNIX UNIX es una marca registrada de XOpen Company, Ltd/. HP-UX es una marca registrada de Hewlett-Packard. Novell y Novell NetWare son marcas registradas de Novell. SunOS Sun Microsystems, Sun NIS, Sun RPC, y NFS son marcas registradas de Sun Microsystems. System V y SVR4 son marcas registradas de AT&T. X Windows System es una marca registrada de el X Consortium, Inc. Todos los otros copyrights son de los propietarios, a menos que se especifique otra cosa . El uso de cualquier término en este documento no debería ser tomado como que afecte la validez de una marca registrada o servicio registrado. Copyright 1994 Daniel Quinlan Se permite la distribución y copia de este estándar siempre que se preserve este copyright y este mensaje en todas las copias. Se permite a los participantes y contribuyentes de la FSSTND copiar y distribuir versiones modificadas de este estándar para propósitos de las actividades de estandarizacion del sistema de archivos solamente, bajo las condiciones abajo especificadas. Todas las copias o porciones de este documento deben identificar el titulo del documento y la sección, y deben acompañar este aviso en un lugar prominente. Ninguna porción de este documento puede ser redistribuida en una forma modificada o recortada sin la aprobación previa de el coordinador del FSSTND. Cualquier entidad que busque permiso para distribuir cualquier material derivado de este documento (Que no sean copias idénticas) debe de contactar al coordinador del FSSTND para la licencia apropiada. 2. Prefacio 2.1 Estatus del Estándar Ésta es la versión 1.2 de la Estructura del Sistema de Archivos de Linux (Linux Filesystems Structure) FSSTND Las guías de este estándar están sujetas a cambio. El uso de la información contenida en este documento es bajo su propio riesgo. 3. Organización del Estándar Este estándar está dividido en 6 partes: * General: incluyendo un enunciado de enfoque, problemas, objetivos, y requerimientos de conformidad. ( Sección 1). * El Sistema de Archivos: Un enunciado de algunos principios guías. ( Sección 2). * El Directorio raíz /: ( Sección 3). * La jerarquía /usr: ( Sección 4). * La jerarquía /var: ( Sección 5). * Razonamientos adicionales y asuntos sin resolver ( Sección 6). 3.1 Convenciones Tipográficas La fuente tipo courier se usa para los nombres de archivos y directorios. Los componentes de nombres de archivos que varían son representados por una descripción del contenido encerrada entre los caracteres " < " y " > ". Las direcciones de correo electrónico están también encerradas entre " < " y " > " pero se muestran en la fuente usual. Los componentes adicionales de los nombres de los archivos se encierran entre los caracteres " [ " y " ] " y pueden ser combinados con la convención " < " y " > ". Por ejemplo, si existe un archivo que puede ser encontrado con o sin extensión, éste podría ser representado por <nombre>[.extensión]. Las subcadenas variables de los nombres de archivos y directorios se indican con " * ". 4. General 4.1 Enfoque Este documento especifica una estructura estándar del sistema de archivos para los sistemas Linux, incluyendo la localización de archivos y directorios, y el contenido de algunos archivos de sistema. El estándar de sistema de archivos ha sido diseñado para ser usado por desarrolladores de distribuciones, desarrolladores de paquetes e implementadores de sistemas. De cualquier forma está hecho para ser una referencia y no es un tutorial de como manejar un sistema de archivos Linux ó jerarquía de directorios. Éstos son algunos de los problemas fundamentales que motivaron originalmente el esfuerzo de estandarización. No había una estructura única, bien aceptada estructura de directorios Linux, en su lugar había muchas estructuras cada una incompatible con las demás. Las jerarquías más ampliamente usadas no estaban bien estructuradas y diferían bastante de las estructuras de directorios modernas "estándares" (tales como System V, BSD, SunOS, y otras). El sistema de archivos era poco familiar e incómodo para los usuarios de UNIX con experiencia y los administradores que habían tenido experiencia con otros sistemas operativos similares a UNIX. La falta de regularidad también confundía a los recién-iniciados en Linux, especialmente aquellos que no tenían un conocimiento previo de UNIX. Cualquier incompatibilidad entre las distribuciones primarias de Linux y los paquetes de aplicación se resolvían por métodos de una naturaleza poco elegante. Los enlaces simbólicos(symbolic links) eran usados demasiado frecuentemente para arreglar los problemas. (De todas maneras, hay veces en las que los enlaces se usan para asegurar compatibilidad hacia atrás o para permitir a algunos sistemas específicos que tengan un sistema de archivos individual y muy particular). En cualquier esfuerzo de estandarización surgen diferencias de opinión. La necesidad del consenso y la práctica común dentro de la comunidad de Linux deben opacar estas diferencias. Este estándar del sistema de archivos fue primeramente desarrollado dentro de la lista de correo FSSTND y previamente, en el canal FSSTND de la lista de correo de los LINUX-ACTIVISTS. Los comentarios y recomendaciones fueron recibidos de un gran numero de desarrolladores de Linux, notables programadores de Linux, administradores de sistemas y usuarios. Estos voluntarios quienes han contribuido extensivamente al estándar están listados en el final de este documento. Este estándar representa la visión en consenso de éstos y otros contribuyentes. Este estándar busca atacar los problemas estos problemas con una estructura de sistema de archivos bien diseñada que esperamos que la comunidad Linux seguirá voluntariamente. Aunque este estándar comprende más y es más completo que cualquier anterior intento de estandarización, lo más seguro es que nunca esté verdaderamente terminado. Las necesidades de la comunidad Linux cambiarán continuamente debido a las tecnologías emergentes. Es también muy posible que se descubran mejores soluciones a los problemas que nosotros atacamos o que las soluciones que nosotros ahora proponemos dejen de ser las mejores es por eso que el FSSTND planea publicar suplementos y actualizaciones periódicas a este documento. Los comentarios relacionados con este documento se agradecen y son bienvenidos por el grupo FSSTND. Cualquier comentario o sugerencia de cambio deberá ser dirigida a al coordinador del FSSTND o si lo prefiere, cualquier coordinador listado en este documento. Los comentarios tipográficos o gramáticos deberán ser dirigidos a el coordinador FSSTND. Existe también una FAQ mantenida por Ian McCloghrie, que responde algunas de las preguntas más frecuentemente hechas acerca de este estándar. Si desea implementar el FSSTND o si tiene alguna pregunta por favor lea antes el FSSTND FAQ. Ésta está disponible vía ftp anonymous en tsx-11.mit.edu en el directorio /pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ. Por favor no mande correo a la lista de correo sin antes contactar a el coordinador del FSSTND o a un colaborador listado. Los mensajes impropios no van a ser bien recibidos en la lista. Preguntas de como interpretar ciertos artículos en este documento pueden ocasionalmente hacerse, si tiene necesidad de aclarar algún punto, por favor contacte al coordinador. Dado que este estándar representa el consenso de muchos participantes es importante asegurarse que cierta interpretación es también el consenso de su opinión colectiva. Por esa razón puede no ser posible una respuesta inmediata a menos que la pregunta halla sido objeto de discusión previa. El coordinador del FSSTND es Daniel Quinlan <[email protected]> 4.2 Problemas específicos. Naturalmente, existían ciertos problemas específicos que tratábamos de corregir cuando estandarizamos la estructura del sistema de archivos de Linux, estos son algunos de los más obvios y más grandes. Los directorios binarios principales /bin y /usr/bin no tienen divisiones bien definidas entre ellos. Como resultado la distribución de los binarios entre estos dos directorios varía grandemente entre en cada distribución de Linux. Al incluir ambos, los archivos binarios y los de configuración en /etc hace más confuso este directorio y más difícil de mantener para ambos, el administrador de sistema y el usuario inexperto (especialmente aquellos con sistemas grandes) La división entre lo que debe ser un archivo de configuración específico de un site, y lo que es un archivo de configuración local de una máquina es difícil de establecer. Muchas implementaciones comunes de /usr no pueden ser montadas sólo-lectura debido a que contienen archivos variables y directorios a los cuales se necesita escribir En un ambiente en red es deseable servir software a las estaciones de trabajo vía NFS. Tales sistemas de archivos pueden necesitar ser montados sólo-lectura, para que los accidentes o malicia deliberada desde un estación de trabajo no puedan dañar los archivos en el servidor. Ésto requiere la identificación y la separación de los archivos a los que una máquina debe escribir y los que son específicos de una máquina. Las estructuras de los sistemas de archivos Linux tradicionales no eran muy adecuadas para instalaciones en red, las cuales podrían requerir que componentes sólo-lectura dentro del sistema de archivos ( principalmente en la jerarquía /usr ) o involucrar estaciones sin discos. Mientras que algunos de los mayores problemas fueron atacados, surgieron numerosos y adicionales que necesitan ser resueltos. Este estándar intenta atacar muchos de estos problemas, pero puede haber algo que fue pasado por alto. Si desea traer algo a nuestra atención, por favor note que hubo asuntos que se han discutido largamente y que no fueron incluidos en este estándar. 4.3 Objetivos Al tratar de resolver los problemas arriba mencionados, se identificaron varios objetivos que necesitaban ser alcanzados en adición a los problemas más técnicos. Estas metas comprenden la corrección de problemas sobresalientes así como la validación de este estándar. Resolver los problemas listados antes, y al mismo tiempo limitar las dificultades transicionales mientras se traslada desde los antiguos estandartes de facto. Ganar la aprobación de los distribuidores, desarrolladores y otra gente importante en la comunidad Linux, así como alentarlos a que compartan con nosotros sus sugerencias. Proveer un estándar que la comunidad Linux escoja seguir por que resuelve los problemas anteriores y provee la más sensata estructura de sistemas de archivos de las instalaciones Linux. Algunos de estos objetivos se han completado total o parcialmente debido a la distribución limitada de este documento (en borrador) al distribuidor o desarrollador que solicitó alguno. 4.4 Historia y Progreso El mensaje original que motivó este esfuerzo para reestructurar el sistema de archivos Linux fue escrito por Olaf Kirsh <[email protected]> el 02 de Agosto de 1993 en el entonces canal NORMAL de la lista de correo de los LINUX-activists. En corto tiempo se decidió que la mejor manera para acometer la necesaria reestructuración de el sistema de archivos de Linux sería la creación de una lista de correo separada con el fin de desarrollar un standard de consenso. Después de una discusión comprensiva y con muy pocas discordias un borrador preliminar fue emitido, con la ayuda de algunas personas dedicadas, el borrador fue terminado y el borrador resultante sometido a consideración en el canal FSSTND para mayor discusión. El primer borrador fue emitido al canal el 18 de Septiembre de 1993 por Daniel Quinlan. Al tiempo que la discusión continuaba y los borradores de las recomendaciones de el FSSTND se desarrollaban más, se establecieron contactos con los desarrolladores más accesibles quienes entonces ofrecieron su apoyo y comentarios a nuestro esfuerzo. Muchos desarrolladores de Linux estuvieron de acuerdo en que este esfuerzo de estandarización valía la pena y lo apoyaron. A continuación estan algunos de los desarrolladores que intentan seguir el estándar FSSTND, parcial o completamente, listados en orden alfabético: ATIM LINUX PRO/ Fred N van Kempen et al. <[email protected]> BOGUS LINUX Rik Faith, Kevin E. Martin, y Doug L. Hoffman <[email protected]> DEBIAN LINUX Ian A. Murdock <[email protected]> LILO boot loader Werner Almesberger <[email protected]> MCC Interim LINUX Owen LeBlanc <[email protected]> Red Hat Software LINUX (RHS LINUX) Marc Ewing <[email protected]> Slackware LINUX Patrick J. Volkerding <[email protected]> TAMU LINUX Dave Safford <[email protected]> util-linux (paquete) Rik Faith <[email protected]> Yggdrasil Plug-and-Play LINUX Adam J. Richter <[email protected]> 4.5 Conformidad con este Documento Esta sección define los términos "conforme" y "compatible" con respecto a este estándar, y el de " "parcialmente" conforme y compatible. Una "implementación" aquí se refiere a una distribución, un sistema instalado, un programa, un paquete ( o alguna pedazo similar de software o datos), o algún componente de ellos. Una implementación es totalmente conforme con este estándar si cada requerimiento en este estándar es cubierto. Cada archivo o directorio que sea parte de la implementación debe estar localizado como se especifica en este documento. Si el contenido de un archivo es descrito aquí, el contenido actual debe corresponder con el de la descripción. La implementación también debe intentar encontrar a los archivos o directorios (externos a sí mismo) primeramente o exclusivamente en el lugar especificado en este estándar. Una implementación es totalmente compatible con este estándar si cada archivo o directorio que contiene puede ser encontrado viendo en el lugar especificado aquí, aún cuando este no sea el lugar primario o el lugar físico del archivo o directorio en cuestión. La implementación debe, cuando intente encontrar cualquier archivo o directorio que no sea parte de sí, en el lugar especificado en este estándar, aunque también puede intentar encontrarlos en otros lugares no-estándar. Una implementación es parcialmente conforme o compatible si cumple con o es compatible con un subconjunto significante de este documento. La conformidad o compatibilidad parcial se aplica solamente a distribuciones y no a programas separados. La frase subconjunto significante es deliberadamente subjetiva y en casos marginales, la parte interesada deberá contactar al coordinador del FSSTND. Se anticipa que cierta variación será tolerada en casos marginales. Para calificar como parcialmente conforme con FSSTND o parcialmente compatible con FSSTND, una implementación debe de proporcionar una lista de lugares en los cuales ella y el FSSTND difieren, junto con una nota breve explicando la razón de la discrepancia. Esta lista deberá de ser provista con la distribución en cuestión y deberá estar disponible para la lista FSSTND o el coordinador del FSSTND. Los términos "tiene que ", "debe", "contiene", "es" y demás deben ser leídos como requerimientos para la conformidad o compatibilidad. Note que una implementación no necesita contener todos los archivos y directorios especificados en este estándar para ser conforme o compatible. Sólo es necesario que aquellos archivos y directorios que sí contiene, que estén localizados apropiadamente. Por ejemplo si el sistema de archivos ext2 no está soportado por una distribución, las herramientas ext2 no necesitan estar incluidas, aunque se mencionen explícitamente en la sección sobre /sbin. Más aún, ciertas porciones de este documento son opcionales. En este caso se enunciará explícitamente, o se indicará con el uso de una o más de las palabras " puede", "se recomienda" o "se sugiere" . Los artículos marcados como opcionales no tienen influencia en la conformidad o compatibilidad de una implementación, sólo son sugerencias pensadas para motivar la práctica común, pero pueden estar localizados en cualquier lugar a juicio del implementador. 5. El sistema de Archivos El sistema de archivos UNIX está caracterizado por: Una estructura jerárquica. Un tratamiento consistente de la informacion de los archivos. Proteccion de los archivos. Este estándar del sistema de archivos Linux sigue el mismo principio basico que la mayoría de los sistemas de archivos UNIX siguen. Note, sin embargo que este estándar no intenta concordar en cada aspecto posible con alguna implementacion particular del sistema UNIX. De cualquier forma, muchos de los aspectos de este estándar estan basados en ideas encontradas en UNIX y sistemas similares a UNIX. Es posible después de cuidadosa consideracion de otros factores, incluyendo: Prácticas comunes en la comunidad Linux. La implementación de otras estructuras de sistemas de archivos. Los estándares aplicables. Definir dos categorizaciones ortogonales de archivos: Compartibles vs. no compartibles, y variables vs. estaticos. La informacion compartible es aquella que puede ser compartida entre varias máquinas diferentes; la no compartible es aquella que debe ser local a una máquina particular. Por ejemplo. Los directorios hogar de los usuarios son compartibles, pero los archivos de bloqueo de dispositivo (lock files) son no compartibles. La información estática incluye binarios, librerias, documentación y todo aquello que no cambia sin la intervención del administrador del sistema. La informacion variable es todo lo que cambia sin la intervención del administrador. El entendimiento de estos principios básicos ayudará a guiar la estructura, a lo largo de este documento, y en cualquier sistema de archivos bien planeado, esto brindará consistencia adicional. La distinción entre información compartible y no compartible es necesaria por varias razones: En un ambiente de red (i.e. más de un host en un site), existe una buena cantidad de información que se puede compartir entre diferentes máquinas para ahorrar espacio y facilitar la tarea de administración. En un ambiente de red, ciertos archivos contienen información específica a una sola máquina, por tanto, estos sistemas de archivos no pueden ser compartidos (sin tomar medidas especiales). Las implementaciones de facto del sistema de archivos no permitían que la jerarquía /usr fuera montada sólo-lectura, porque contenía archivos y directorios que nesecitaban ser escritos muy frecuentemente. Éste es un factor que debe atacarse cuando algunas partes de /usr se comparten en una red, o se montan sólo-lectura debido a otras consideraciones tales como la seguridad. La distincion "compartible" puede ser usada para soportar, por ejemplo: * Una partición /usr (o componentes de /usr) montada (sólo-lectura) atraves de la red (usando NFS). * Una particion /usr (o componentes de /usr) montada desde medios de sólo-lectura.Un cd-rom puede ser considerado como un sistema de archivos sólo-lectura compartido con otros sistemas Linux utilizando el sistema de correo como una red. La distincion "estática" contra "variable" afecta el sistema de archivos de dos maneras principales: Dado que / contiene ambos tipos de información, variable y estática necesita montarse lectura-escritura. Dado que el /usr tradicional contiene ambos tipos de información variable y estática y dado que podríamos desear montarlo sólo-lectura (vea arriba), es necesario proporcionar un método para hacer que /usr se monte sólo-lectura. Ésto se logra con la creación de una jerarquía /var que se monta lectura-escritura (o es parte de una partición lectura-escritura tal como /), que toma mucho de la funcionalidad tradicional de la particion /usr. 5.1 Tabla con ejemplos. CompartibleNo-CompartibleEstática/usr/etc/home/bootVariable/var/spool/mail/var/run/var/spool/news/var/lock3. El directorio raíz /. Esta sección describe la estructura del directorio raíz. El contenido del sistema de archivos raíz será el adecuado para arrancar, bootear, restaurar,recuperar y/o reparar el sistema: Para arrancar el sistema, debe estar presente lo suficiente como para montar /usr y otras partes no-esenciales del sistema de archivos. Ésto 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. Para restaurar un sistema, estarán presentes en el sistema de archivos raíz aquellas herramientas necesarias para restaurar el sistema desde respaldos (en floppy, cintas, etc). 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 meta de mantener / tan pequeno como sea razonablemente posible. Por varias razones es deseable mantener el sistema de archivos / Es frecuentemente montado desde media muy pequena. Por ejemplo muchos usuarios de Linux instalan y recuperan sistemas montando / como un disco ram, que es copiado de un disco de 1.44Mb único. El sistema de archivos / tiene muchos archivos de configuración específicos de un sistema. Posibles ejemplos son un kernel que es específico al sistema, un hostname diferente, etc. Ésto significa que el sistema de archivos / no es siempre compartible entre sistemas en red. Manteniéndolo pequeño en sistemas en red, se minimiza el espacio perdido en los servidores por archivos no-compartibles. También permite estaciones de trabajo con discos duros locales más pequeños. Aunque usted podría tener el sistema de archivos / en una partición grande, y ser capaz de llenarla según sus deseos, siempre habrá gente con particiones más pequeñas. Si usted tiene más archivos instalados, podría encontrar incompatibilidades con otros sistemas que utilizan un sistema de archivos / en particiones más pequeñas. Si usted es un desarrollador entonces estaría volviendo su suposición en un problema para un gran número de usuarios. 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 / pequeño es menos propenso a corromperse como resultado de una falla del sistema. En este documento, actualmente se requiere un sistema de archivos / escribible (debido principalmente a /etc/mtab). De cualquier forma, no se necesita que el sistema de archivos / esté totalmente almacenado localmente. La partición / no tiene porque estar almacenada localmente para ser específica del sistema por ejemplo, podría estar montada de un servidor NFS. El software no deberá crear o requerir archivos o subdirectorios especiales en el directorio /. La estructura del sistema de archivos Linux proporciona más que suficiente flexibilidad para cualquier paquete. Cualquier paquete que ocupe un directorio bajo la raíz / del sistema de archivos sufre de bastante arrogancia. 5.2 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 Cada directorio listado será discutido en detalle en una subsección separada más delante. /usr y /var, cada uno tiene en su propia sección en este documento. El kernel de Linux estaría localizado en, ya sea / ó en /boot. Si está localizado en / recomendamos usar el nombre VMLINUX o VMLINUZ, nombres que han sido usados en paquetes fuentes del kernel de Linux recientes. Más información de la localización del kernel se puede encontrar en la sección acerca de / más delante. 5.3 /bin Binarios de comandos esenciales de usuarios (disponibles para todos los usuarios). bin contiene comandos que pueden ser utilizados por ambos los usuarios y /el administrador del sistema, pero que son requeridos en el modo /mono-usuario (single-user mode) puede también contener comandos que son /utilizados indirectamente por algunos scripts. Todos los binarios utilizables sólo por root, tales como daemons,init,getty, update, etc. Estarían localizados en /sbin ó /usr/sbin dependiendo si son o no esenciales. Para una mayor discusión de la definición de que es esencial en el sistema de archivos /, lea por favor la sección 6, "Razonamientos adicionales y asuntos sin resolver". No habrá subdirectorios dentro de /bin. Los binarios de los comandos que no son suficientemente esenciales para estar en /bin estarán localizados en /usr/bin, los elementos que son utilizados por usuarios solamente (pero no por root) (mail,chsh, etc) no son suficientemente esenciales para estar dentro de la partición /. Archivos requeridos en /bin: Comandos generales: Los siguientes comandos han sido incluidos porque son esenciales. algunos están presentes debido a que tradicionalmente han estado en /bin. arch, cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, ed, false,kill, in, login, mxdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, setserial, sh, sfty, su, sinc, true, umount, uname. Si /bin/sh es Bash, entonces /bin/sh sería en enlace simbólico o duro a /bin/bash dado que bash se comporta diferente cuando es llamado como sh ó bash. La pdksh que puede ser la /bin/sh en los discos de instalación y sería igualmente arreglada a que /bin/sh sea un enlace simbólico a /bin/ksh. El uso de enlaces simbólicos en estos casos permite que los usuarios vean fácilmente que /bin/sh no es una shell estilo bourne. Dado que la localización estándar de facto de shell estilo c es /bin/csh,si y sólo si está disponible en el sistema una shell estilo c ó equivalente (tal como /bin/tcsh, esta, estaría disponible con el nombre /bin/csh. /bin/csh puede ser un enlace simbólico a /bin/tcsh ó /usr/bin/tcsh). Los comandos [ y test están interconstruidos en bash, pdksh, zsh, y las shell korn recientes, esencialmente cada remplazo de las shell tipo bourne que hay para Linux. Estos comandos estarían localizados dentro de /usr/bin. (se deben incluir como binarios separados con cualquier sistema Linux que intente cumplir con el estándar POSIX). bin/arch produciría el mismo resultado que uname-m, especificamente; 386 /o; 486 para sistemas intel y compatibles. Comandos para restauración. Estos comandos se han incluido para hacer posible el restaurar el sistema(siempre que / este intacto). tar, gzip, gunzip (enlace hacia gzip), zcat (enlace hacia gzip). Si se hacen respaldos de sistemas utilizando otros programas, entonces la particion / contendrá los componentes mínimos necesarios. Por ejemplo,muchos sistemas incluirían cpio como la segunda utilería más usada para respaldos después de tar. Pero si jamás se espera restaurar el sistema desde la partición /, entonces estos binarios se pueden omitir (i.e.,montar / en chip ROM, montar /usr desde NFS). Si la restauración del sistema se planea a traves de la red, Entonces FTP ó TFTP (junto con todo lo necesario para obtener una conexión FTP) estarían disponibles en la partición /. Los comandos de restauración pueden aparecer en, ya sea /bin ó /usr/bin en sistemas Linux diferentes. Comandos de red. Éstos son unicamente los binarios de red que los usuarios y root querrán o necesitarán ejecutar que no sean los que estan en /usr/bin ó /usr/local/bin domainname, hostname, netstat, ping. 5.4 /boot: Archivos estáticos del cargador de arranque (boot loader). Este directorio contiene todo para arrancar excepto los archivos de configuración y el instalador de mapas. En su sentido más sencillo /boot es para cualquier cosa que se utiliza antes de que el kernel ejecute /sbin/init. Ésto incluye sectores maestros de arranque (master boot sectors) guardados, archivos de mapeo de sectores y cualquier otra cosa que no es editada directamente a mano.Los programas necesarios para arreglar que el cargador de arranque sea capaz de arrancar un archivo (tal como el instalador de mapas ) estarán localizados en /sbin. Los archivos de configuración para cargadores de arranque podrían estar localizados en /etc. Como se expuso arriba, el kernel de Linux puede estar localizado en / ó en /boot, si se localiza en /boot, recomendamos que se le dé un nombre más descriptivo. 5.5 /dev Archivos de dispositivos. Éste es el directorio de los dispositivos. Contendría un archivo por cada dispositivo que el kernel de Linux puede soportar. dev también contiene un script llamado MAKEDEV el cual puede crear /dispositivos cuando se necesiten. Puede contener un MAKEDEV local para /dispositivos sólo-local. MAKEDEV debe hacer previsión para crear cualquier archivo de dispositivo especial listado en la lista de numeros mayores/menores, no sólo aquellos de una distribución particular. Los enlaces simbólicos no se deben distribuir en sistemas Linux, sino sólo como se preveé en la lista de dispositivos de Linux. Ésto es porque las instalaciones locales seguro diferirán de aquellas de la máquina del desarrollador. Ademas si un script de instalación configura enlaces simbólicos en la instalación, estos enlaces seguramente no se actualizarán si se hacen cambios locales en el hardware. Cuando se usan responsablemente,como sea, son de buen uso. Este documento incorpora como referencia la lista de dispositivos de Linux, mantenida por: [email protected]: El encargado de los dispositivos Linux.Todos los archivos especiales de dispositivo seguirán el estándar en ese documento, que está disponible en ftp.yggdrasil.com en /pub/device-list. 5.6 /etc : Configuración del sistema local a la máquina. etc contiene archivos y directorios que son locales al sistema actual. Ningún binario debe ir directamente dentro de /etc. Los binarios que en el pasado se encontraban en /etc, irán en /sbin ó /usr/sbin. Ésto incluye archivos tales como init, getty y update. Los binarios tales como hostname que son utilizados por usuarios ordinarios y por root no irían en /sbin sino en /bin. /etc --- Configuracion de sistemas locales de máquina. X11 Archivos deconfiguracion para el x11 skel Esqueletos de configuracion de usuarios etc/skel es la localidad para los llamados archivos esqueletos de /usuarios, que le son dados por defecto cuando un nuevo usuario recibe una /cuenta, este directorio puede contener subdirectorios para diferentes /grupos de usuarios (i.e./etc/skell/apoyo, /etc/skell/usuarios). etc/X11 es el lugar recomendado para todos los archivos de configuración /de X11 locales a la máquina. Este directorio es necesario para permitir el /control local si /usr se monta sólo-lectura. Los archivos que deben ir en /este directorio incluyen Xconfig (y/o XF86Config) y Xmodmap. Los subdirectorios de /etc/X11 pueden incluir aquellos para xdm y para cualesquier otros programas (como algunos manejadores de ventanas por ejemplo) que lo necesiten. Recomendamos que los manejadores de ventanas con un solo archivo de configuración que es un archivo .*wmrc por defecto, que lo llamen system.*wmrc (a menos que exista una alternativa ampliamente aceptada) y que no utilize un subdirectorio. Cualquier subdirectorio de un manejador de ventanas se llamaría idéntico al binario del manejador de ventanas. etc/X11/xdm retiene los archivos de configuración de xdm. Ésto es la /mayoría de los archivos normalmente hallados en /usr/lib/X11/xdm; Vea la /seccion 5,/var/lib/xdm, para mayor información. La siguiente sección intenta parcialmente examinar la descripción del contenido de /etc con algunos ejemplos: Definitivamente ésta no es una lista exhaustiva. Archivos requeridos en /etc: Archivos generales: Estos archivos son necesarios en la mayoría de los sistemas Linux. adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group, inittab, issue, ld.so.conf, lilo.conf, magic, motd, mtab, mtools, passwd, profile, psdatabase, securetty, shells, syslog.conf, tercamp, ttytype Archivos de Red: Estos archivos estarían instalados en la mayoria de los sistemas Linux. exports, ftpusers, gateways, hosts, host.conf, host.equiv, host.lpd, inetd.conf, networks, printcap, protocols, resolv.conf.rpc, services Hay dos modelos para la instalación de los scripts de comandos "rc" los cuales son invocados por init(8) al momento de arrancar, el modelo /etc/rc.d/* estilo SystemV. Cualquiera puede ser utilizado o una mezcla de los dos. Los sistemas con la suite de passwords sombreadas (shadow password) tendrán archivos de configuración adicionales, en /etc (/etc/shadow y otros) y /usr/bin (useradd, usermod, y otros). 5.7 /home: Directorios hogar de los usuarios (opcional) home es un concepto algo estándar, pero es claramente un sistema de /archivos específico de un site. El arreglo diferirá de máquina a máquina. /Esta sección describe una localización sugerida para los directorios hogar /de los usuarios, aun así, recomendamos que todas las distribuciones /Linux usen este lugar como la localización por defecto de los /directorios hogar. En sistemas pequeños, cada directorio de usuario es uno de los subdirectorios debajo de /home, p.ej. /home/smith, /home/torvalds, /home/operador, etc. En sistemas grandes (especialmente cuando los directorios /home son compartidos entre varias máquinas usando NFS) es útil subdividir los directorios hogar. La subdivisión puede ser llevada a cabo utilizando subdirectorios tales como /home/apoyo, /home/huéspedes, /home/estudiantes, etc. Muchas personas prefieren poner las cuentas de los usuarios en una variedad de lugares. Por tanto, ningún programa deberá confiar en esta localización. Si usted desea encontrar el directorio hogar de cualquier usuario, debería usar la función de librería getpwent(3) en vez de contar con /etc/passwd, por que la información puede estar almacenada remotamente usando usando sistemas como NIS. 5.8 /lib: Librerías compartidas y módulos de kernel escenciales El directorio /lib contiene aquellas imágenes de las librerías compartidas que se necesitan para arrancar el sistema y ejecutar los comandos en el sistema de archivos raíz. lib --- librerías compartidas y modulos de kernel esenciales. modules Modulos de kernel cargables. Esto incluye /lib/libc.so.*, /lib/libm.so.*, el enlazador dinámico compartido /lib/ld.so.*, y otras librerías compartidas requeridas por binarios en /bin y /sbin. Las librerías que son necesitadas sólo por los binarios en /usr (como cualquier binario de X Window) no pertenecen a /lib. Sólo las librerías compartidas requeridas para ejecutar los binarios dentro de /bin y /sbin deben estar aquí. La librería libm.so.* podría estar localizada en /usr/lib si no es requerida por nada en /bin ó /sbin. Por razones de compatibilidad, /lib/cpp necesita existir como una referencia al pre-procesador C instalado en el sistema. La localización usual del binario es /usr/lib/gcc-lib/<target>/<version>/cpp. Puede existir un enlace/lib/cpp apuntando a este binario o a cualquier otra referencia a este binario que exista en el sistema de archivos. (Por ejemplo, /usr/bin/cpp se usa frecuentemente). La especificación para /lib/modules está aún por aparecer. 5.9 /mnt: Punto de montaje para sistemas de archivos montados temporalmente. Este directorio se ha provisto para que el administador pueda montar temporalmente sistemas de archivos cuando lo necesite. El contenido de este directorio es un asunto local y no debe afectar la manera en la cual se ejecuta ningún programa. Recomendamos la no utlización de este directorio por programas de instalación, y sugerimos utilizar un directorio temporal adecuado que no este en uso por el sistema. 5.10 /proc: Sistema de archivos virtual de informacion de procesos y del kernel. El sistema de archivos proc se está convirtiendo en el estándar de facto para el manejo de informacion de procesos y de sistema en vez de /dev/kmem y otros metodos similares. Recomendamos fuertemente esto para el almacenamiento y obtención de información de procesos asi como otra información del kernel y de memoria. 5.11 /root: Directorio hogar de root (opcional) El directorio / es tradicionalmente el directorio hogar del usuario root en los sistemas UNIX. /root se usa en muchos sistemas Linux y en algunos sistemas UNIX. El directorio hogar de la cuenta de el usuario root puede ser determinada por el desarrollador o por preferencias locales. Las posibilidades obvias incluyen /, /root, y /home/root. Si el directorio hogar de root no está almacenado en la partición raíz, será necesario asegurarse que tome / por defecto si no puede ser localizado. NOTA: Recomendamos contra el uso de la cuenta root para cosa mundanas tales como leer el correo y ver las noticias (mail & news) sino que se use solamente para la administración del sistema. Por esta razón recomendamos que no aparezcan subdirectorios como Mail y News en el directorio hogar de la cuenta del usuario root. Recomendamos que el Mail para root y postmaster sean redirigidos a un usuario más adecuado. 5.12 /sbin: Binarios del Sistema (Alguna vez mantenidos en /etc) Los útiles usados por la administración del sistema ( y otros comandos que sólo root utiliza ) están almacenados en /sbin, /usr/sbin, y /usr/local/sbin. /sbin típicamente contiene binarios escenciales para arrancar el sistema ademas de los binarios en /bin. Cualquier cosa que se ejecuta después de que se sabe que /usr se ha montado (cuando no hay problemas) debería estar en /usr/sbin. Los binarios de administración de sistema sólo-locales deben estar localizados en /usr/local/sbin. Decidir que cosa va en los directorios de /sbin es sencillo: Si un usuario necesitará ejecutarlo, debe de ir en otro lado. Si sólo será ejecutado por el administrador del sistema o por root como scripts de administración, entonces debe ir en /sbin (o en /usr/sbin o en /usr/local/sbin, si el archivo no es vital para la operación del sistema). Archivos como chfn que los usuarios usan sólo ocasionalmente deben aun estar en /usr/bin. ping aunque es absolutamente necesario para el root (recuperación de la red y diagnóstico) es tambien frecuentemente usado por los usuarios y por esa razon debe ir en /bin. Los usuarios ordinarios no tendrán que poner ninguno de los directorios sbin en su búsqueda (path). Recomendamos que los usuarios tengan permisos de lectura y ejecución en todo lo que se encuentra en /sbin excepto tal vez ciertos programas; setuid y setgid. La división entre /sbin y /bin no fue creada por motivos de seguridad o para evitar que los usuarios vieran el sistema operativo, sino para proveer una buena partición entre binarios que todos usan y los que se usan, principalmente las tareas de administración. No hay ganancia inherente en seguridad en hacer que /sbin este fuera del alcance de los usuarios. Archivos requeridos en /sbin: Comandos Generales. clock, getty, init, update, mkswap, swapon, swapoff, telinit. Comandos de Apagado. fastboot, fasthalt, halt, reboot, shutdown. Comandos de manejo de sistemas de archivos. fdisk, fsck, fsck.*, mkfs, mkfs.* donde * = uno de los siguientes. ext, ext2 minix, msdos, xia, y tal vez otros. Comandos del sistema de archivos ext2 (opcional) badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs. Instalador del mapa del cargador de arranque. lilo Comandos de Red. arp, ifconfig, route. Archivos opcionales en /sbin: Binarios estáticos. (compilados estáticamente) ln estático sln y sync estático ssync son útiles cuando las cosas salen mal. El principal uso de sln (reparar enlaces simbólicos incorrectos en /lib despues de una actualización mal orquestrada) ya no es preocupación mayor ahora que existe el programa ldconfig (usualmente localizado en /usr/sbin) y puede actuar como una mano guiadora al actualizar las librerías dinámicas. sync estático es útil en algunas ocasiones de emergencia. Note que estas no necesitan ser versiones compiladas estáticamente de los ln y sync estándares, pero pueden ser. El binario ldconfig es opcional en /sbin, dado que un site puede escoger ejecutar ldconfig al arrancar, en vez de sólo cuando se actualizan las librerías compartidas. (No está claro si es o no ventajoso ejecutar ldconfig en cada arranque). Aun así, a algunos les gusta tener ldconfig a la mano para las siguientes (muy comunes) situaciones: Se acaba de remover /lib/<archivo>. No se puede encontrar el nombre de la librería porque ls está enlazado dinámicamente. Se está usando una shell que no tiene ls interconstruida y no se sabe como usar "echo * " como remplazo. Se tiene un sln, pero no se sabe como nombrar al enlace. ldconfig, sln, ssync. Misceláneos Para lidiar con el hecho de que muchos teclados vienen con una tasa de repeticion tan alta como para hacerlos inutilizables, se puede instalar kbdrate en /sbin en algunos sistemas. Dado que la acción por defecto del kernel ante la combinacion de teclas Ctrl-Alt-Del es un rearranque instantáneo duro, es recomendable generalmente deshabilitar esta conducta antes de montar el sistema de archivos raíz con modo lectura-escritura. Algunas suites init son capaces de deshabilitar Ctrl-Alt-Del, pero otras pueden requerir el programa ctrlaltdel, el cual puede ser instalado en /sbin en estos sistemas. ctrlaltdel, kbdrate 5.13 /tmp: Archivos temporales. tmp se utiliza para archivos temporales, preferentemente en un /dispositivo rápido (un sistema de archivos basado en memoria por ejemplo) La "persistencia" de la informacion que es almacenada en /tmp es diferente de aquella que sea almacenada en /var/tmp. /tmp puede ser limpiada en cada arranque o a intervalos relativamente frecuentes. Por tanto, no se debe esperar que la informacion almacenada en /tmp permanezca por algún periodo largo de tiempo. Los programas deben utilizar /tmp ó /var/tmp (que era originalmente /usr/tmp) de acuerdo a los requerimientos esperados de la informacion, pero no deben confiar en alguna persistencia temporal particular en cualquier directorio de almacenamiento temporal. Los administradores de sistemas pueden elegir enlazar /tmp a algun otro directorio, tal como /var/tmp; esto es útil, por ejemplo, para conservar espacio en la partición raíz. Si ésto se lleva a cabo, entonces la persistencia de archivos en /var/tmp debe ser al menos tan larga como la de /tmp. tmp puede estar e un disco RAM. /var/tmp no debe nunca localizarse en /algun dispositivo RAM. Parte 2 FUENTE: http://server-die.alc.upv.es/alumno/linux/fsstnd12/fsstnd12.html#toc2