Chris Shumway Reescrito por El siguiente capítulo comprende la funcionalidad y órdenes básicas del sistema operativo &os;. Gran parte de este material es relevante para cualquier sistema operativo tipo &unix;. Puede saltarse este capítulo si considera que ya conoce el funcionamiento de &unix;. Si no tiene experiencia previa con &os; debería leer este capítulo con mucha atención. Después de leer este capítulo, usted sabrá: Cómo usar las «consolas virtuales» de FreeBSD. Cómo funcionan los permisos de fichero &unix; en relación con las banderas de fichero en &os;. La disposición de sistemas de ficheros por omisión en &os;. La organización de disco de &os;. Cómo montar y desmontar sistemas de ficheros. Qué son los procesos, dæmons y señales. Qué es una shell, cómo modificar sus variables de entorno por omisión. Cómo utilizar editores de texto básicos. Qué son los dispositivos y nodos de dispositivos. Qué formato binario se usa en &os;. Cómo buscar información en las páginas de manual. consola virtual terminales &os; puede utilizarse de muchas maneras. Una de ellas es tecleando órdenes en una terminal de texto. De este modo, mucha de la flexibilidad y poder de un sistema operativo &unix; está inmediatamente en sus manos cuando usa &os;. Esta sección describe qué son «terminales» y «consolas» y cómo puede usarlas en &os;. consola Si no ha configurado &os; para ejecutar automáticamente un entorno gráfico en el arranque, el sistema le presentará un «prompt» de entrada después del arranque, inmediatamente después de que los «scripts» de inicio terminen de ejecutarse. Verá algo similar a esto: Additional ABI support:. Local package initialization:. Additional TCP options:. Fri Sep 20 13:01:06 EEST 2002 FreeBSD/i386 (pc3.ejemplo.org) (ttyv0) login: Los mensajes pueden ser un poco diferentes en su sistema, pero verá algo similar. Las últimas dos líneas son las que nos interesan por el momento. La penúltima línea dice: FreeBSD/i386 (pc3.ejemplo.org) (ttyv0) Esta línea contiene información acerca del sistema que acaba de arrancar. Esta usted ante una consola «FreeBSD» que se ejecuta en un procesador Intel o compatible de la arquitectura x86 Esto es lo que i386 significa. Tenga en cuenta que incluso si no está ejecutando &os; en una CPU Intel 386, éste va a ser i386. No es el tipo de su procesador, sino la «arquitectura» la que se muestra aquí. . El nombre de esta máquina (todas las máquinas &unix; tiene un nombre) es pc3.ejemplo.org, y usted está ahora ante su consola de sistema (la terminal ttyv0). Para acabar, la última línea siempre es: login: Este es el lugar donde se usted tecleará su «nombre de usuario» para entrar en &os;. La siguiente sección describe cómo hacerlo. &os; es un sistema multiusuario multiprocesador. Esta es la descripción formal que se suele dar a un sistema que puede ser utilizado por muchas personas diferentes, que simultáneamente ejecutan muchos programas en un sola máquina. Cada sistema multiusuario necesita algún modo de distinguir a un «usuario» del resto. En &os; (y en todos los sistemas operativos de tipo &unix;) esto se logra requiriendo que cada usuario «acceda» al sistema antes de poder ejecutar programas. Cada usuario tiene un nombre único (el «nombre de usuario») y una clave secreta, personal (la «contraseña»). &os; preguntará por ambos antes de permitirle a un usuario ejecutar cualquier programa. scripts de inicio Justo después de que &os; arranque y termine de ejecutar sus «scripts» de inicio Los «scripts» de inicio son programas que &os; ejecuta automáticamente cuando arranca. Su función principal es preparar todo lo necesario para que todo lo demás se ejecute, e iniciar cualquier servicio que tenga configurado para ejecutarse en segundo plano algo útiles. , le presentará un «prompt» y solicitará un nombre válido de usuario: login: En este ejemplo vamos a asumir que su nombre de usuario es john. Teclée john en el «prompt» y pulse Intro. Debería presentársele un «prompt» donde introducir una «contraseña»: login: john Password: Teclée ahora la contraseña de john y pulse Enter. La contraseña no se muestra en pantalla, pero no debe preocuparse por ello. Esto se hace así por motivos de seguridad. Si ha tecleado su contraseña correctamente ya está usted en un sistema &os;, listo para probar todas las órdenes disponibles. Verá el MOTD (mensaje del día) seguido por un «prompt» (un caracter #, $ o %). Esto confirma que ha validado con éxito su usuario en &os;. Ejecutar órdenes &unix; en una consola está bien, pero &os; puede ejecutar muchos programas a la vez. Tener una consola donde se pueden teclear órdenes puede ser un desperdicio cuando un sistema operativo como &os; puede ejecutar docenas de programas al mismo tiempo. Aquí es donde las «consolas virtuales» muestran su potencial. &os; puede configurarse para presentarle diferentes consolas virtuales. Puede cambiar de una de ellas a cualquier otra consola virtual pulsando un par de teclas en su teclado. Cada consola tiene su propio canal de salida, y &os; se ocupa de redirigir correctamente la entrada del teclado y la salida al monitor cuando cambia de una consola virtual a la siguiente. Se han reservado ciertas combinaciones especiales de teclas para pasar de unas consolas virtuales a otras en &os; Tiene una descripción bastante técnica y correcta de todos los detalles de la consola &os; y los controladores de teclado pueden encontrarse en las páginas de manual de &man.syscons.4;, &man.atkbd.4;, &man.vidcontrol.1; y &man.kbdcontrol.1;. No nos extenderemos en los detalles aquí, pero el lector interesado siempre puede consultar dichas páginas de manual si quiere una explicación más detallada y profunda de cómo funcionan estas cosas. . Puede utilizar AltF1, AltF2 y así sucesivamente hasta AltF8 para cambiar a una consola virtual diferente en &os;. Mientras está cambiando de una consola a la siguiente, &os; se ocupa de guardar y restaurar la salida de pantalla. El resultado es la «ilusión» de tener varias pantallas y teclados «virtuales» que puede utilizar para teclear órdenes para que &os; los ejecute. El programa que usted lanza en una consola virtual no deja de ejecutarse cuando la consola no está visible. Continúan ejecutándose cuando se cambia a una consola virtual diferente. La configuración por omisión de &os; iniciará con ocho consolas virtuales. No es una configuración estática por hardware, así que puede personalizar fácilmente su sistema para arrancar con más o menos consolas virtuales. El número y propiedades de las consolas virtuales están detallados en /etc/ttys. En /etc/ttys es donde se configuran las consolas virtuales de &os;. Cada línea no comentada de este fichero (líneas que no comienzan con un caracter #) contiene propiedades para una sola terminal o consola virtual. La versión por omisión de este fichero en &os; configura nueve consolas virtuales y habilita ocho de ellas. Son las líneas que comienzan con ttyv: # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure Consulte &man.ttys.5; si quiere una descripción detallada de cada columna en este fichero y todas las opciones que puede usar para configurar las consolas virtuales. En la encontrará una descripción detallada de lo que es «modo monousuario». No importa que sólo exista una consola cuando ejecuta &os; en modo monousuario. No hay otra consola virtual disponible. Las configuraciones de la consola en modo monousuario se pueden encontrar también en /etc/ttys. Busque la línea que comienza por console: # name getty type status comments # # Si la consola está marcada como "insecure", entonces init # le pedirá la contraseña de root al entrar a modo monousuario. console none unknown off secure Tal y como indican los comentarios por encima de la línea console, puede editar esta línea y cambiar secure por insecure. Si lo hace, cuando &os; arranque en modo monousuario el sistema le pedirá la contraseña de root. Tenga cuidado si cambia esto a insecure. Si olvida la contraseña de root arrancar en modo monousuario será con seguridad más complicado. Sigue siendo posible, pero será un poco difícil para alguien que no esté familiarizado con le proceso de arranque de &os; y los programas involucrados en dicho proceso. La consola &os; por omisión tiene un modo de video que puede ajustarse a 1024x768, 1280x1024 o cualquier otra resolución que admita su chip gráfico y su monitor. Si quiere utilizar uno diferente tendrá que recompilar su kernel con estas dos opciones añadidas: options VESA options SC_PIXEL_MODE Una vez recompilado el kernel con esas dos opciones en él determine qué modos de video admite su hardware; para ello use &man.vidcontrol.1;. Con lo siguiente le mostrará una lista de modos de video soportados: &prompt.root; vidcontrol -i mode La salida de esta orden es una lista de los modos de que admite su tarjeta. Para elegir uno de ellos tendrá que ejecutar &man.vidcontrol.1; en una consola como root: &prompt.root; vidcontrol MODE_279 Si el modo de video que ha elegido le parece adecuado puede configurarlo de forma permanente haciendo que funcione desde el momento del arranque; para ello debe editar /etc/rc.conf file: allscreens_flags="MODE_279" UNIX &os;, cuya raíz histórica es el &unix; BSD, se fundamenta en varios conceptos clave de UNIX. El primero y más importante es que &os; es un sistema operativo multi-usuario. El sistema puede gestionar múltiples usuarios trabajando simultáneamente y en tareas que no guarden relación entre sí. El sistema se encarga de compartir y administrar peticiones de dispositivos de hardware, periféricos, memoria y tiempo de CPU de manera equitativa para cada usuario. Debido a que el sistema es capaz de soportar múltiples usuarios, todo lo que el sistema administra tiene un conjunto de permisos que usa para decidir quién puede leer, escribir y ejecutar un recurso. Estos permisos se guardan como octetos divididos en tres partes: una para el propietario del fichero, otra para el grupo al que el fichero pertenece, y otra para todos los demás grupos y usuarios. Veamos una representación numérica de esto: permisos permisos de fichero Valor Permiso Listado de directorio 0 No leer, no escribir, no ejecutar --- 1 No leer, no escribir, ejecutar --x 2 No leer, escribir, no ejecutar -w- 3 No leer, escribir, ejecutar -wx 4 Leer, no escribir, no ejecutar r-- 5 Leer, no escribir, ejecutar r-x 6 Leer, escribir, no ejecutar rw- 7 Leer, escribir, ejecutar rwx ls directorios Puede utilizar el parámetro de línea de órdenes -l de &man.ls.1; para ver un listado largo que incluya una columna con información acerca de los permisos de fichero para el propietario, grupo y los demás. Por ejemplo, un ls -l en un directorio puede mostrar algo como esto: &prompt.user; ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 mifichero -rw-r--r-- 1 root wheel 512 Sep 5 12:31 otrofichero -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt ... Aquí está como se divide la primera columna de ls -l: -rw-r--r-- El primer caracter (más a la izquierda) indica si este fichero es un fichero regular, un directorio, un dispositivo especial de caracter, un socket o cualquier otro dispositivo especial pseudo-ficheroa . En este caso, el - un fichero regular. Los siguientes tres caracteres, rw- en este ejemplo, dan los permisos para el propietario del fichero. Los siguientes tres caracteres, r--, dan los permisos para el grupo al que el fichero pertenece. Los últimos tres caracteres, r--, dan los permisos para el resto del mundo. Un guión indica que el permiso está desactivado. En el caso de este fichero, los permisos están asignados de tal manera que el propietario puede leer y escribir en el fichero, el grupo puede leer el fichero, y el resto del mundo sólo puede leer el fichero. De acuerdo con la tabla de arriba, los permisos para este fichero serían 644, donde cada dígito representa las tres partes de los permisos del fichero. Todo ésto está muy bien, pero ¿cómo controla el sistema los permisos de los dispositivos? &os; en realidad trata la mayoría de los dispositivos hardware como un fichero que los programas pueden abrir, leer y en los que pueden escribir datos como si de cualquier otro fichero se tratara. Estos ficheros especiales de dispositivo se encuentran en el directorio /dev. Los directorios también son tratados como ficheros. Tienen permisos de lectura, escritura y ejecución. El bit de ejecución en un directorio tiene un significado ligeramente distinto que para los ficheros. Cuando un directorio está marcado como ejecutable significa que se puede mirar dentro, se puede hacer un «cd» (cambiar directorio) a él. Esto también significa que dentro del directorio es posible acceder a ficheros cuyos nombres son conocidos (sujeto, claro está, a los permisos de los ficheros mismos). En particular, para poder realizar un listado de directorio, el permiso de lectura debe ser activado en el directorio, mientras que para borrar un fichero del que se conoce el nombre es necesario tener permisos de escritura y ejecución en el directorio que contiene el fichero. Existen más permisos, pero se usan principalmente en circunstancias especiales como los binarios ejecutables de tipo setuid y los los directorios de tipo «sticky». Si desea más información acerca de los permisos de ficheros y cómo establecerlos, consulte &man.chmod.1;. Tom Rhodes Escrito por permisossymbolic Los permisos simbólicos, también conocidos como expresiones simbólicas, utilizan caracteres en lugar de valores octales para asignar permisos a ficheros o directorios. Las expresiones simbólicas utilizan la sintaxis de (quién) (acción) (permisos) mediante los siguientes valores: Opción Letra Representa (quién) u Usuario (quién) g Grupo propietario (quién) o Otro (quién) a Todos («todo el mundo») (acción) + Añadir permisos (acción) - Quitar permisos (acción) = Activar permisos explícitamente (permisos) r Lectura (permisos) w Escritura (permisos) x Ejecución (permisos) t Bit Sticky («pegajoso») (permisos) s Activar UID o GID Estos valores se aplican con &man.chmod.1; de la misma manera que los anteriores, pero con letras. Por ejemplo, podría usar la siguiente orden para bloquear a otros usuarios el acceso a FICHERO: &prompt.user; chmod go= FICHERO Puede usarse una lista separada por comas cuando se quiera aplicar más de un conjunto de cambios a un fichero. Por ejemplo la siguiente orden eliminará los permisos de escritura de grupo y «mundo» a FICHERO, y añade permisos de ejecución para todos: &prompt.user; chmod go-w,a+x FILE Tom Rhodes Escrito por Además de los permisos de fichero previamente expuestos, &os; permite el uso de «banderas de fichero». Estas banderas añaden un nivel de seguridad y control adicional a los ficheros, pero no a los directorios. Las banderas de fichero añaden un nivel adicional de control sobre los ficheros ayudando a asegurar que en algunos casos ni siquiera root pueda eliminar o alterar ficheros. Las banderas de fichero se modifican mediante &man.chflags.1;, gracias a una interfaz muy sencilla. Por ejemplo, para habilitar la bandera imborrable de sistema en fichero1, escriba lo siguiente: &prompt.root; chflags sunlink fichero1 Y para dehabilitar la bandera imborrable de sistema, simplemente escriba la orden previa con «no» antes de sunlink. Observe: &prompt.root; chflags nosunlink fichero1 Para ver las banderas de este fichero, utilice &man.ls.1; con las opciones -lo: &prompt.root; ls -lo fichero1 La salida debería ser como esta: -rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 fichero1 Varias banderas solo pueden ser añadidas o retiradas de ficheros por el usuario root. En otros casos, el propietario del fichero puede activar estas banderas. Se recomienda que para más información la persona encargada de la administración del sistema consulte las páginas de manual &man.chflags.1; y &man.chflags.2;. Tom Rhodes Escrito por Además de los permisos que se han explicado hay más, hay tres tipos más que todos los administradores deberían conocer. Son los permisos setuid, setgid y sticky. Estos permisos juegan un papel clave en ciertas operaciones &unix; puesto que facilitan funcionalidades que no se suelen permitir a los usuarios normales. Para comprenderlas totalmente hay que comprender la diferencia entre el ID real del usuario y el ID efectivo. El ID del usuario real es el UID que arranca (y el propietario) del proceso. El UID efectivo es el ID bajo el que se ejecuta el proceso. Veamos un ejemplo; el programa &man.passwd.1; se ejecuta con el ID real del usuario puesto que el usuario está cambiando su contraseña. Pero para poder manipular la base de datos de contraseñas debe ejecutarse con el ID efectivo del usuario root. De este modo es posible que los usuarios cambien su contraseña sin llegar a ver un error de Permission Denied (permiso denegado). La opción nosuid de &man.mount.8; hace que estos binarios den errores silenciosos, es decir, fallarán pero el usuario no recibirá ningún mensaje de error por ello. Esta opción no funciona siempre, pues, según la página man de &man.mount.8;, un «wrapper» nosuid puede sortear esta limitación. El permiso setuid puede asignarse colocando un número cuatro (4) antes de los permisos. Se ve mejor con un ejemplo: &prompt.root; chmod 4755 ejemplosuid.sh Los permisos de ejemplosuid.sh deberían ser así: -rwsr-xr-x 1 trhodes trhodes 63 Aug 29 06:36 ejemplosuid.sh Fíjese atentamente en la s que ha aparecido en los permisos del fichero, en la parte de los permisos del propietario; esa s está en donde estaría el bit de ejecución. Gracias a esto el funcionamiento de aplicaciones que necesitan permisos elevados, como passwd, pueden funcionar. Si quiere ver un ejemplo con sus propios ojos abra dos terminales. En una arranque un proceso (ejecute) passwd con un usuario normal. Mientras la aplicación espera a que le de una nueva contraseña busque la información de usuario del proceso passwd en la tabla de procesos. En la terminal A: Changing local password for trhodes Old Password: En la terminal B: &prompt.root; ps aux | grep passwd trhodes 5232 0.0 0.2 3420 1608 0 R+ 2:10AM 0:00.00 grep passwd root 5211 0.0 0.2 3620 1724 2 I+ 2:09AM 0:00.01 passwd Tal y como se ha dicho, un usuario normal puede ejecutar passwd, pero en realidad está utilizando el UID efectivo de root. El permiso setgid actúa del mismo modo que el setuid, pero afecta a los permisos del grupo. Cuando una aplicación funciona con esta configuración lo hace con los permisos del grupo al que pertenece el fichero, no los del usuario que ha arrancado el proceso. Si quiere utilizar el permiso setgid debe situar un núnmero dos (2) al principio de los permisos que vaya a asignar mediante chmod. &prompt.root; chmod 2755 ejemplosuid.sh La nueva configuración tiene un aspecto muy similar a la que tenía antes, pero observe que la s de antes está ahora en el campo de los permisos de grupo: -rwxr-sr-x 1 trhodes trhodes 44 Aug 31 01:49 ejemplosuid.sh En ambos ejemplos, incluso si el «script» en cuestión es ejecutable, no se va a ejecutar con un EUID distinto o un ID efectivo de usuario porque los «scripts» de shell no pueden acceder a la llama del sistema &man.setuid.2;. Los dos permisos que acabamos de mostrar los bits de permisos (setuid y setgid) pueden reducir el nivel de seguridad haciendo que se escalen los permisos. Pero hay un tercer bit especial de permisos que puede ser de mucha ayuda para reforzar la seguridad del sistema: el sticky bit. El sticky bit( que podríamos traducir como «bit pegajoso») aplicado a un directorio hace que solamente el propietario de un fichero pueda borrarlo. Esto evita el borrado de ficheros ajenos en directorios públicos como /tmp. Si quiere usarlo coloque un uno (1) antes de los permisos. Veamos un ejemplo: &prompt.root; chmod 1777 /tmp Para ver el ;sticky bit en acción usamos ls: &prompt.root; ls -al / | grep tmp drwxrwxrwt 10 root wheel 512 Aug 31 01:49 tmp El sticky bit es la letra t al final de los permisos. jerarquía de directorios La jerarquía del sistema de ficheros de &os; es fundamental para obtener una compresión completa del sistema. El concepto más importante a entender es el del directorio raíz, «/». Este directorio es el primero en ser montado en el arranque y contiene el sistema básico necesario para preparar el sistema operativo para su funcionamiento en modo multiusuario. El directorio raíz también contiene puntos de montaje para cualquier otro sistema de ficheros que se pretenda montar. Un punto de montaje es un directorio donde se pueden insertar sistemas de ficheros al sistema de archivos raíz. Esto se explica con detalle en la . Los puntos de montaje estándar incluyen /usr, /var, /tmp, /mnt y /cdrom. Estos directorios suelen corresponderse con entradas en /etc/fstab. /etc/fstab es una tabla que sirve de referencia al sistema y contiene los diferentes sistemas de ficheros y sus respectivos puntos de montaje. La mayoría de los sistemas de ficheros en /etc/fstab se montan automáticamente en el arranque gracias al «script» &man.rc.8;, a menos que contengan la opción noauto. Si quiere más información consulte la . Veremos ahora una descripción de los directorios más comunes. Si desea información más completa consulte &man.hier.7;. Directorio Descripción / Directorio raíz del sistema de ficheros. /bin/ Utilidades de usuario fundamentales tanto para el ambiente monousuario como para el multiusuario. /boot/ Programas y ficheros de configuración necesarios durante el arranque del sistema operativo. /boot/defaults/ Ficheros de configuración por omisión del arranque; ver &man.loader.conf.5;. /dev/ Nodos de dispositivo; ver &man.intro.4;. /etc/ Ficheros de configuración y «scripts» del sistema. /etc/defaults/ Ficheros de configuración por omisión del sistema; ver &man.rc.8;. /etc/mail/ Ficheros de configuración para agentes de transporte de correo como &man.sendmail.8;. /etc/namedb/ Ficheros de configuración de named; ver &man.named.8;. /etc/periodic/ «Scripts» que se ejecutan diariamente, semanalmente y mensualmente mediante &man.cron.8;; ver &man.periodic.8;. /etc/ppp/ Ficheros de configuración de ppp; ver &man.ppp.8;. /mnt/ Directorio vacío utilizado de forma habitual por administradores de sistemas como punto de montaje temporal. /proc/ Sistema de ficheros de procesos; ver &man.procfs.5;, &man.mount.procfs.8;. /rescue/ Programas enlazados estáticamente para restauraciones de emergencia; ver &man.rescue.8;. /root/ Directorio local para la cuenta root. /sbin/ Programas del sistema y utilidades fundamentales de administración para ambientes monousuario y multiusuario. /tmp/ Ficheros temporales. El contenido de /tmp NO suelen conservarse después de un reinicio del sistema. Los sistemas de ficheros basados en memoria suelen montarse en /tmp Puede automatizarse mediante variables de tmpmfs en &man.rc.conf.5; (o con una entrada en /etc/fstab; ver &man.mdmfs.8;, o para FreeBSD 4.X, &man.mfs.8;). /usr/ La mayoría de utilidades y aplicaciones de usuario. /usr/bin/ Aplicaciones comunes, herramientas de programación y otras aplicaciones. /usr/include/ Ficheros «include» estándar de C. /usr/lib/ Bibliotecas. /usr/libdata/ Ficheros de datos con diversas funciones. /usr/libexec/ Dæmons del sistema y utilidades del sistema (ejecutados por otros programas). /usr/local/ Ejecutables locales, bibliotecas, etc. también se usa como destino por omisión de la infraestructura de ports de &os;. Dentro de /usr/local debe seguirse el esquema general definido en &man.hier.7; para /usr. Las excepciones son el directorio man, que está directamente bajo /usr/local en lugar de debajo de /usr/local/share, y la documentación de los ports está en share/doc/port. /usr/obj/ Arbol destino dependiente de arquitectura fruto de la compilación del árbol /usr/src. /usr/ports La colección de Ports de &os; (opcional). /usr/sbin/ Dæmons del sistema y utilidades del sistema (ejecutados por usuarios del sistema). /usr/share/ Ficheros independientes de arquitectura. /usr/src/ Ficheros fuente BSD y/o local. /usr/X11R6/ Ejecutables de la distribución X11R6, bibliotecas, etc (opcional). /var/ Ficheros multipropósito de log, temporales, en tránsito y de «spool». En ocasiones se monta en /var un sistema de ficheros basado en memoria. /var/log/ Diversos ficheros de log del sistema. /var/mail/ Ficheros de buzones de correo de usuarios. /var/spool/ Directorios diversos del sistema de spool de impresora y correo. /var/tmp/ Ficheros temporales. Suelen conservarse tras el Estos ficheros suelen conservarse tras el reinicio del sistema, a menos que /var sea un sistema de ficheros basado en memoria. /var/yp Mapas NIS. La unidad más pequeña que &os; utiliza para ubicar ficheros es el nombre de fichero. Los nombres de fichero son sensibles a las mayúsculas, lo que significa que readme.txt y README.TXT son dos ficheros distintos. &os; no utiliza la extensión (.txt) de un fichero para determinar si es un programa, o un documento o alguna otra forma de datos. Los ficheros se almacenan en directorios. Un directorio puede estar vacío, o puede contener cientos de ficheros. Un directorio también puede contener otros directorios, permitiéndole contruir una jerarquía de directorios dentro de otro. Esto hace mucho más fácil la organización de sus datos. Para referirse a ficheros o directorios se usa el nombre de archivo o de directorio, seguido por una barra, /, seguido por cualquier otro nombre de directorio que sea necesario. Si tiene un directorio tal, el cual contiene el directorio cual, el cual contiene el fichero readme.txt, entonces el nombre completo o ruta al fichero es tal/cual/readme.txt. Los directorios y ficheros se almacenan en un sistema de ficheros. Cada sistema de ficheros contiene un sólo directorio en el nivel más elevado, que es el directorio raíz de ese sistema de ficheros. Este directorio raíz puede contener otros directorios. Lo visto hasta ahora probablemente sea similar a cualquier otro sistema operativo que pueda haber utilizado, pero hay unas cuantas diferencias; por ejemplo, &ms-dos; utiliza \ para separar nombres de fichero y directorio, mientras que &macos; usa :. &os; no utiliza letras de unidades, u otro nombre de unidad en la ruta. Por tanto, no podrá escribir c:/tal/cual/readme.txt en &os;. En &os;, en cambio, un sistema de ficheros recibe el nombre de sistema de ficheros raíz. El directorio raíz del sistema de ficheros raíz se representa como /. Cualquier otro sistema de ficheros, por tanto, se monta bajo el sistema de ficheros raíz. No importa cuántos discos tenga en su sistema &os;, cada directorio parecerá ser parte del mismo disco. Suponga que tiene tres sistemas de ficheros, denominados A, B y C. Cada sistema de ficheros tiene un directorio raíz, el cual contiene otros dos directorios, llamados A1, A2 (y de la misma manera B1, B2 y C1, C2). Usaremos A como sistema de ficheros raíz. Si usara ls para ver el contenido de este directorio vería dos subdirectorios, A1 y A2. El árbol de directorios sería como este: / | +--- A1 | `--- A2 Un sistema de ficheros debe montarse en un directorio de otro sistema de ficheros. Ahora suponga que monta el sistema de ficheros B en el directorio A1. El directorio raíz de B reemplaza a A1, y los directorios en B aparecen de esta manera: / | +--- A1 | | | +--- B1 | | | `--- B2 | `--- A2 Cualquier fichero que esté en el directorio B1 o B2 puede encontrarse con la ruta /A1/B1 o /A1/B2 según sea necesario. Cualquier fichero que esté en /A1 ha desaparecido temporalmente. Aparecerán de nuevo si B se desmonta de A. Si B se monta en A2 entonces el diagrama se vería así: / | +--- A1 | `--- A2 | +--- B1 | `--- B2 y las rutas serían /A2/B1 y /A2/B2 respectivamente. Pueden montarse sistemas de ficheros uno sobre otro. Continuando con el ejemplo anterior, el sistema de ficheros C podría montarse en el directorio B1 en el sistema de ficheros B, lo que nos llevaría a esto: / | +--- A1 | `--- A2 | +--- B1 | | | +--- C1 | | | `--- C2 | `--- B2 O C podría montarse directamente en el sistema de ficheros A, bajo el directorio A1: / | +--- A1 | | | +--- C1 | | | `--- C2 | `--- A2 | +--- B1 | `--- B2 Si está familiarizado con &ms-dos; esto es similar, aunque no idéntico, a utilizar join. Esto no es algo a lo deba usted dedicar tiempo de forma habitual. Normalmente creará sistemas de ficheros al instalar &os; y decidirá dónde montarlos; lo más habitual es que no los cambie de sitio a menos que agregue un disco nuevo. Es perfectamente posible tener un sistema de ficheros raíz extenso y no necesitar crear otros. Este esquema tiene unos cuantos inconvenientes y una ventaja: Si dispone de varios sistemas de ficheros puede optar por usar distintas opciones de montaje. Por ejemplo, gracias a una planificación cuidadosa, el sistema de ficheros raíz puede montarse como sólo-lectura, haciendo imposible borrar sin querer o editar un fichero crítico. Al mantener separados sistemas de ficheros en los que los usuarios pueden escribir, como /home, de otros sistemas de ficheros también le permite montar con la opción nosuid; dicha opción previene que los bits suid/guid en los ejecutables almacenados en el sistema de ficheros tengan efecto, mejorando en cierto modo la seguridad. &os; optimiza automáticamente el esquema de ficheros en un sistema de ficheros, dependiendo de cómo el sistema de ficheros esté siendo utilizado. Uno que contenga muchos ficheros pequeños tendrá una optimización distinta de uno que contenga menos ficheros y más grandes. Si sólo tiene un gran sistema de ficheros no hay manera de aplicar esta optimización. Los sistemas de ficheros de &os; son muy robustos en caso de sufrir un caída eléctrica. De todas maneras, un fallo eléctrico en un momento crítico puede dañar la estructura del sistema de ficheros. Si reparte sus datos en múltiples sistemas de ficheros hará que sea más probable que el sistema arranque después de uno de esos fallos, haciéndole además más fácil la tarea de restaurarlo desde un respaldo si fuera necesario. Los sistemas de ficheros son de un tamaño fijo. Si crea un sistema de ficheros cuando instala &os; y le da un tamaño específico, tal vez descubra más tarde que necesita hacer la partición más grande. Esto no es fácil de realizar sin hacer una copia de seguridad, crear de nuevo el sistema de ficheros con el nuevo tamaño y entonces restaurar los datos respaldados. &os; dispone de &man.growfs.8;, que permite incrementar el tamanño de un sistema de ficheros «al vuelo», eliminando esta limitación. Los sistemas de ficheros están alojados en particiones. Este es un detalle muy importante, puesto que el término partición no significa aquí lo mismo que en otros entornos (por ejemplo, en &ms-dos;) debido a la herencia &unix; de &os;. Cada partición se identifica con una letra desde a hasta h. Cada partición puede contener solamente un sistema de ficheros, lo que significa que los sistemas de ficheros suelen definirse mediante su punto de montaje en la jerarquía del sistema de ficheros o por la letra de la partición en la que están alojados. &os; también utiliza espacio de disco como espacio de intercambio (swap). El espacio de intercambio le brinda a &os; memoria virtual. Esto permite al su sistema comportarse como si tuviera más memoria de la que realmente tiene. Cuando a &os; se le agota la memoria mueve algunos de los datos que no está utilizando en ese momento al espacio de intercambio, y los vuelve a poner donde estaban (desplazando alguna otra cosa) cuando los necesita. Algunas particiones tienen ciertas convenciones heredadas. Partición Representación a Normalmente contiene el sistema de ficheros raíz b Normalmente contiene el espacio de intercambio (swap) c Suele tener el mismo tamaño de la «slice» que la encierra. Esto permite a las utilidades que necesitan trabajar en toda la «slice» entera (por ejemplo durante una búsqueda de bloques dañados) trabajar en la partición c. Normalmente no debería usted crear un sistema de ficheros en esta partición. d La partición d solía tuvo un significado especial asociado pero ya no lo tiene. Cada partición que contiene un sistema de ficheros se almacena en lo que &os; llama una «slice». «slice» es en &os; lo que en otros ámbitos se denomina partición; es un hecho que deriva de los orígenes de &os; como ya sabemos basado en &unix;. slices particiones peligrosamente dedicadas Los números de «slice» muestran el nombre de dispositivo, al que precede una s y un número que puede ser un 1 u otro número mayor. Por lo tanto «da0s1» es la primera slice en la primera unidad SCSI. Sólo puede haber cuatro «slice» físicas en un disco, pero puede haber «slice» lógicas dentro «slice» físicas del tipo apropiado. Estas «slice»extendidas se numeran a partir de 5, así que «ad0s5» es la primera «slice» extendida en el primer disco IDE. Estos dispositivos se usan en sistemas de ficheros que se preve que ocupen una slice. Tanto las «slice» y las unidades físicas «peligrosamente dedicadas», como otras unidades contienen particiones, que se designan mediante letras desde la a hasta h. Esta letra se añade al nombre del dispositivo. Se verá mucho mejor mediante ejemplos: «da0a» es la partición a en la primera unidad da y es una de esas a las que llamamos «peligrosamente dedicada». «ad1s3e» es la quinta partición en la tercera slice de la segunda unidad de disco IDE. Para terminar, cada disco en el sistema tiene también su designación. El nombre de disco comienza por un código que indica el tipo de disco, luego un número, que indica qué disco es. A diferencia de las «slice», la numeración de discos comienza desde 0. Puede las numeraciones más comunes en el . Cuando se hace referencia a una partición, &os; necesita que también se nombre la «slice» y el disco que contiene la partició. Esto se hace con el nombre de disco, s, el número «slice» y por último la letra de la partición. Tiene varios casos en el . En el muestra un modelo conceptual del esquema de un disco que debería ayudarle a aclarar las cosas. Antes de instalar &os; tendrá que configurar las «slice» de disco, después crear particiones dentro de las «slice» que vaya a usar en &os; y luego crear un sistema de ficheros (o swap) en cada partición y luego decidir cuál va a ser el punto de montaje del sistema de ficheros. Código Significado ad Disco ATAPI (IDE) da Disco de acceso directo SCSI acd CDROM ATAPI (IDE) cd CDROM SCSI fd Disquete (floppy) Nombre Significado ad0s1a La primera partición (a) en la primera slice (s1) en el primer disco IDE (ad0). da1s2e La quinta partición (e) en la segunda slice (s2) en el segundo disco SCSI (da1). Este diagrama muestra cómo ve &os; el primer disco IDE en el sistema. Se asume que el disco es de 4 GB, y contiene dos «slices» de 2 GB (particiones &ms-dos;). La primera partición contiene un disco &ms-dos;, C:, y la segunda partición contiene una instalación de &os;. Esta instalación de ejemplo tiene tres particiones, y una partición swap. Cada una de las tres particiones tiene un sistema de ficheros. La partición a se utilizará para el sistema de ficheros raíz, e para la jerarquía del directorio /var, y f para la jerarquía del directorio /usr. .-----------------. --. | | | | DOS / Windows | | : : > Primera partición, ad0s1 : : | | | | :=================: ==: --. | | | Partición a, montada como / | | | > recibe el nombre de ad0s2a | | | | | :-----------------: ==: | | | | Partición b, usada como swap | | | > recibe el nombre de ad0s2b | | | | | :-----------------: ==: | Partición c, sin | | | Partición e, usada como /var > sistema de archivos, la | | > recibe el nombre de ad0s2e | porción completa de FreeBSD, | | | | ad0s2c :-----------------: ==: | | | | | : : | Partición f, usada como /usr | : : > referida como ad0s2f | : : | | | | | | | | --' | `-----------------' --' El sistema de ficheros se visualiza mejor como un árbol enraizado, tal y como esá, en /. /dev, /usr y todos los demás directorios en el directorio raíz son raamas, las cuales pueden tener sus propias ramas, como /usr/local y así sucesivamente. sistema de ficheros raíz Existen varias razones para albergar algunos de estos directorios en sistemas de ficheros separados. /var contiene los directorios log/, spool/ y varios tipos de ficheros temporales y pueden llegar a desbordarse. Agotar el espacio del sistema de ficheros raíz no es nada bueno desde cualquier punto de vista, así que separar /var de de / es algo que debería hacerse siempre que sea posible. Otra razón para meter ciertos árboles de directorios en otros sistemas de ficheros es si van a estar albergados en discos físicos separados, o si son discos virtuales separados, como un montaje por NFS en el caso de unidades de CDROM. sistemas de ficheros montaje con fstab Durante el proceso de arranque los sistemas de ficheros listados en /etc/fstab se montan automáticamente (a menos que estén listados con la opción noauto). /etc/fstab contiene una lista de líneas con el siguiente formato: dispositivo /punto-de-montaje punto de montaje opciones dumpfreq passno dispositivo Un nombre de dispositivo (debe existir). punto-de-montaje Un directorio (que debe existir) en el que montar el sistema de ficheros. tipo de sistema ficheros El tipo de sistema de ficheros es un parámetro que interpretará &man.mount.8;. El sistema de ficheros por omisión de &os; es ufs. opciones Ya sea rw para sistemas de ficheros de lectura-escritura, o ro para sistemas de ficheros de sólo lectura, seguido de cualquier otra opción que sea necesaria. Una opción muy habitual es noauto, que se suele usar en sistemas de ficheros que no se deben montar durante la secuencia de arranque. Tiene otras opciones en la página de manual de &man.mount.8;. dumpfreq &man.dump.8; la usa para determinar qué sistema de ficheros requieren volcado. Si el campo no está declarado se asume un valor de cero. passno Determina el orden en el cual los sistemas de ficheros deben revisarse. Los sistemas de ficheros que hayan de saltarse deben tener su passno a cero. El sistema de ficheros raíz (que obviamente debe ser revisado antes que cualquier otro) debe tener su passno puesto a uno, y los demás sistemas de ficheros deben tener valores mayores que uno. Si más de un sistema de ficheros tiene el mismo passno &man.fsck.8; tratará de revisarlos en paralelo en caso de ser posible. Consulte la página de manual de &man.fstab.5; para mayor información sobre el formato del fichero /etc/fstab y las opciones que contiene. sistemas de ficheros montaje &man.mount.8; es al fin y al cabo quien monta los sistemas de ficheros. En su forma más básica se usa lo siguiente: &prompt.root; mount dispositivo punto-de-montaje Existe una gran cantidad de opciones (las encontrará todas en &man.mount.8;) pero las más comunes son: -a Montar todos los sistemas de ficheros que aparezcan en /etc/fstab, excepto aquellos marcados como «noauto», excluidos por el parámetro -t o aquellos que ya estén montados. -d Realizar todo excepto la llamada real de montaje del sistema. Esta opción es muy útil en caso de problemas si se combina con la opción -v para determinar qué es lo que &man.mount.8; está haciendo realmente. -f Forzar el montaje de un sistema de ficheros inestable (por ejemplo uno que da errores tras un reinicio súbito, algo que es bastante peligroso), o forzar la revocación de accesos de escritura cuando se cambia el estátus de un sistema de archivos de lectura-escritura a só lectura. -r Montar el sistema de ficheros como sólo lectura. Esto es idéntico a utilizar el argumento ro (rdonly para versiones anteriores a &os; 5.2) en la opción -o. -t tipo de sistema de ficheros Montar un sistema de ficheros dado con el tipo de sistema de ficheros, o montar solamente sistemas de ficheros del tipo dado si se proporciona la opción -a. «ufs» es el sistema de ficheros por omisión. -u Actualizar puntos de montaje en el sistema de ficheros. -v Mostrar mayor información. -w Montar el sistema de ficheros como lectura-escritura. La opción -o toma una lista las siguientes opciones separada por comas: nodev No interpretar dispositivos especiales en el sistema ficheros. Es una opción de seguridad que puede ser muy útil. noexec No permitir la ejecución de binarios en este sistema de ficheros. Esta también es una opción de seguridad útil. nosuid No interpretar bits setuid o setgid en el sistema de ficheros. Esta también es una opción de seguridad útil. sistemas de ficheros desmontar &man.umount.8; toma como parámetro un punto de montaje, un nombre de dispositivo, o la opción -a o -A. Todas las formas toman -f para forzar el desmontaje y -v para mostrar más información. Tenga muy en cuenta que usar -f no suele ser una forma recomendable de proceder. Desmontar a la fuerza los sistemas de ficheros puede acarrear el congelar la máquina o dañar los datos en el sistema de ficheros. -a y -A se usan para desmontar todos los sistemas de ficheros montados, con la ventaja de poder elegir el tipo de sistema de ficheros que se use tras -t. De todas maneras -A no trata de desmontar el sistema de ficheros raíz. &os; es un sistema operativo multitarea. Esto significa que parece como si más de un programa se estuviera ejecutando al mismo tiempo. Cada programa uno de esos programas que se está ejecutando en un momento dado se denomina proceso. Cada orden que ejecuta iniciará al menos un proceso nuevo, y hay muchos procesos que se están que se están ejecutando en todo momento, manteniendo el sistema en funcionamiento. Cada proceso tiene un identificador individual consistente en un número llamado ID del proceso, o PID, y al igual que sucede con los ficheros, cada proceso tiene un propietario y un grupo. La información de propietario y grupo se usa para determinar qué ficheros y dispositivos puede abrir el proceso mediante los permisos de fichero explicados anteriormente. La mayoría de los procesos también tiene un proceso padre. El proceso padre es el proceso que los inició. Por ejemplo, si está tecleando órdenes en la shell, la shell es un proceso, y cualquier orden que usted ejecute también lo será. De este modo cada proceso que ejecute tendrá como proceso padre a su shell. La excepción es un proceso especial llamado &man.init.8;. init es siempre el primer proceso, así que su PID siempre es 1. El kernel arranca automáticamente init en el arranque de &os;. Hay dos órdenes particularmente útiles para ver los procesos en el sistema, &man.ps.1; y &man.top.1;. ps se usa para mostrar una lista estática de los procesos que se ejecutan en el sistema en es momento, y puede mostrar sus PID, cuánta memoria está usando, la línea de órdenes con la que fueron iniciados y muchas más cosas. top despliega todos los procesos que se están ejecutando y actualiza la pantalla cada pocos segundos para que pueda ver lo que está haciendo su sistema. Por omisión ps solo le muestra las órdenes que están ejecutando y que sean propiedad de su usuario. Por ejemplo: &prompt.user; ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi 48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish Como puede ver en este ejemplo la salida de &man.ps.1; está organizada en columnas. PID es el ID de proceso anteriormente expuesto. Los PIDs se asignan a partir del 1 y hasta 99999, y vuelven a comenzar desde el 1 otra cuando se terminan los números. La columna TT muestra la tty en la que el programa se está ejecutando; podemos ignorarla tranquilamente por el momento. STAT muestra el estado del programa; de momento también podemos ignorarlo. TIME es la cantidad de tiempo que el programa ha se ha estado ejecutando en la CPU (generalmente no es el tiempo transcurrido desde que se inició el programa, ya que la mayoría de los programas pasan mucho tiempo esperando antes de que necesiten gastar tiempo en la CPU. Finalmente, COMMAND es la línea de órdenes que se empleó para ejecutar el programa. &man.ps.1; admite muchas opciones sobre la información que se desea ver. Uno de los conjuntos más útiles es auxww. a muestra información acerca de todos los procesos ejecutándose, no solamente los suyos. u despliega el nombre de usuario del propietario del proceso, así como el uso de memoria. x despliega información acerca de los procesos dæmon y ww hace que &man.ps.1; despliegue la línea de órdenes completa, en lugar de truncarla cuando es demasiado larga para caber en la pantalla. La salida de &man.top.1; es similar. Veamos un ejemplo: &prompt.user; top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... La salida está dividida en dos secciones. La cabecera (las primeras cinco líneas) muestra el PID del último proceso en ejecutarse, la carga promedio del sistema (una medida de la carga del sistema), el «uptime» del sistema (tiempo desde el último reinicio) y la hora actual. Las otras cifras en la cabecera se relacionan con cuántos procesos hay en ejecución en el sistema (47 en este caso), cuánta memoria y espacio de intercambio (swap) está en uso, y cuánto tiempo está el sistema en diferentes estados de CPU. Más abajo hay una serie de columnas con información similar a la salida de &man.ps.1;. Igual que antes, puede usted ver el PID, el nombre de usuario, la cantidad de tiempo de CPU en uso y la orden que se ejecutó. &man.top.1; también mostrará por omisión la cantidad de espacio de memoria que emplea cada proceso. Está dividido en dos columnas, una para el tamaño total y otra para el tamaño residente (el tamaño total es cuánta memoria ha necesitado la aplicación y el tamaño residente es cuánta se está usando en ese momento concreto). En este ejemplo puede verse que &netscape; requerido casi 30 MB de RAM, pero actualmente solo está usando 9 MB. &man.top.1; actualiza automáticamente el listado cada dos segundos, pero este lapso puede cambiarse mediante la opción s. cuando ejecuta un editor es fácil controlarlo, decirle que cargue ficheros y demás. Puede hacerse porque el editor permite ese control y porque el editor depende de una terminal. Algunos programas no están diseñados para ejecutarse entradas continuas por parte del usuario, así que se desconectan de la terminal a la primera oportunidad. Por ejemplo, un servidor web pasa todo el dia respondiendo peticiones web y normalmente no necesita que usted le haga caso. Los programas que transportan correo electrónico de un sitio a otro son otro ejemplo de esta clase de aplicación. Llamamos a estos programas dæmons. Los Dæmons eran personajes de la mitología griega; no eran ni buenos ni malos, eran pequeños espíritus sirvientes que, en gran medida, hacían cosas útiles por la humanidad. Algo muy parecido a cómo los servidores web y los servidores de correo hacen hoy día tantas cosas útiles para nosotros. Por eso, desde hace mucho tiempo la mascota de BSD es ese dæmon de aspecto tan ufano con su tridente y su cómodo calzado deportivo. Hay una norma según la cual se da nombre a los programas que suelen ejecutarse como dæmons con una «d» final. BIND es el dæmon de nombres de Berkeley (y el programa que en realidad se ejecuta se llama named); el servidor web Apache se llama httpd, el dæmon de «spool» de impresora de línea es lpd y así sucesivamente. Se trata de un acuerdo, no una ley férrea; por ejemplo el dæmon principal de correo de Sendmail se llama sendmail, y no maild, como podría suponerse visto lo precedente. Algunas veces necesitará comunicarse con un dæmon. Estas comunicaciones se denominan señales; es posible comunicarse con un dæmon (o con cualquier otro proceso ejecutándose) mandándole una señal. Existen diversos tipos de señales diferentes que puede mandar: algunas tienen un significado especial, otras son interpretadas por la aplicación y la documentación de la aplicación le dirá cómo interpreta la señal esa aplicación). Solamente puede enviar una señal a un del que sea usted propietario. Si manda una señal a un proceso de otro usuario con &man.kill.1; o &man.kill.2; verá un mensaje del sistema en el que se le comunica que no tiene permiso para hacer tal cosa. La excepción a esto es el usuario root, que puede mandar señales a los procesos de cualquier usuario del sistema. &os; también enviará señales de aplicación en determinados casos. Si una aplicación está mal escrita y trata de acceder a memoria a la que no está previsto que acceda &os; manda al proceso la señal Violación de segmento (SIGSEGV). Si una aplicación ha utilizado la llamada de sistema &man.alarm.3; para ser avisada después de que un periodo de tiempo haya transcurrido se le mandará la señal de alarma (SIGALRM), y así sucesivamente. Hay dos señales que pueden usarse para detener un proceso, SIGTERM y SIGKILL. SIGTERM es la manera amable de matar un proceso; el proceso puede recibir la señal, darse cuenta que usted quiere que se apague, cerrar cualquier fichero de log que pueda tener abierto y generalmente terminar cualquier tarea que esté realizando en ese momento antes de apagarse. En algunos casos un proceso puede incluso ignorar SIGTERM si se encuentra inmerso en una tarea que no puede ser interrumpida. Por el contrario, un proceso no puede ignorar una señal SIGKILL. Esta es la señal «No me importa lo que estás haciendo, detente ahora mismo». Si manda un SIGKILL a un proceso &os; detendrá ese proceso inmediatamente. Esto no es del todo cierto (ciertas cosas no pueden ser interrumpidas. Por ejemplo, si el proceso está tratando de leer desde un fichero que está en otro sistema de la red, y el otro sistema no está disponible por alguna razón (por estar apagada, o que la red tenga un fallo), tenemos un caso de lo que llamamos «proceso ininterrumpible». Más tarde, al proceso se le acabará el tiempo de espera, generalmente pasados dos minutos. Tan pronto como esto ocurra el proceso será liquidado. . Otras señales que puede usar: SIGHUP, SIGUSR1 y SIGUSR2. Son señales de propósito general, y aplicaciones diferentes pueden hacer cosas diferentes cuando se utilicen. Suponga que ha cambiado el fichero de configuración de su servidor web; es un buen momento para decirle al servidor web que lea y aplique la configuración. Podría detener y reiniciar httpd, pero esto implicaría un período breve de suspensión del servicio de su servidor web, lo cual puede no ser asumible. La mayoría de los dæmons fueron creados pensando en que fueran capaces de responder a la señal SIGHUP releyendo su fichero de configuración. En lugar de matar y reiniciar httpd le podría mandar la señal SIGHUP. Dado que no hay una manera estándar para responder a estas señales, diferentes dæmons tendrán diferente comportamiento, así que asegúrese de leer la documentación del dæmon en cuestión. Las señales se envian mediante &man.kill.1;, como puede verse en el siguiente ejemplo. Este ejemplo muestra como enviar una señal a &man.inetd.8;. El fichero de configuración de inetd es /etc/inetd.conf e inetd releerá dicho fichero de configuración cuando se le envíe un SIGHUP. Identifique el ID de proceso del proceso al que quiere enviarle la señal mediante &man.ps.1; y &man.grep.1;. &man.grep.1; se usa para buscar cadenas de texto de su elección en la salida estándar. Puede ejecutarse como un usuario normal, mientras que &man.inetd.8; se ejecuta como root, así que debe pasarle los parámetros ax a &man.ps.1;. &prompt.user; ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW Vemos que el PID de &man.inetd.8; es 198. En algunos casos grep inetd también puede aparecer en esta salida. Esto se debe a la manera en que &man.ps.1; tiene que encontrar la lista de procesos ejecutándose. Utilice &man.kill.1; para enviar la señal. Debido a que &man.inetd.8; está siendo ejecutado po root tendrá que usar primero &man.su.1; para volverse root. &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 Del mismo modo que la mayoría de órdenes &unix; &man.kill.1; no imprimirá ninguna salida si ha funcionado bien. Si envía una señal a un proceso del que no es el propietario verá lo siguiente: kill: PID: Operation not permitted. Si no teclea bien el PID puede enviar la señal a un proceso equivocado, lo cual puede ser malo, o si tiene suerte, habrá enviado la señal a un proceso que no está en uso y verá el sistema le dir´ kill: PID: No such process. Muchas shells incorporan su propio kill; esto es, el shell mandará la señal directamente, en lugar de ejecutar /bin/kill. Esto puede ser útil pero las diferentes shells tienen diferentes sintaxis para especificar el nombre de la señal que envían. En lugar de tratar de aprederse todas ellas, es más fácil simplemente usar /bin/kill ... sea la que sea la shell que prefiera usar. El envío de otras señales es muy similar; sustituya TERM o KILL en la línea de órdenes según sea necesario. Matar procesos aleatorios en el sistema es una mala idea. En particular, &man.init.8;, ID de proceso 1, es muy especial. Ejecutar /bin/kill -s KILL 1 es una manera rápida de apagar su sistema. Siempre revise dos veces los argumentos con los que ejecuta &man.kill.1; antes de pulsar Intro. shells línea de órdenes En &os; gran parte del trabajo diario se hace en una interfaz de línea de órdenes llamada shell. El trabajo principal de la shell es ir recibiendo órdenes mediante un canal de entrada y ejecutarlos. Muchas shells también tienen funciones integradas para ayudar ayudar con las tareas diarias como manipulación de ficheros, gestión de archivos con expresiones regulares, edición en la propia línea de órdenes, macros de órdenes y variables de entorno. &os; incluye diversas shells, como sh, el shell Bourne y tcsh, el shell C mejorado. Hay muchas otras shells disponibles en la colección de ports de &os;, como zsh y bash. ¿Qué shell usar? es una cuestión de gustos. Si va a programar en C puede preferir usar una shell tipo C, como tcsh. Si viene del mundo Linux o si es nuevo en la interfaz de línea de órdenes de &unix; puede probar con bash. Tenga en cuenta que cada shell posee unas propiedades únicas que pueden o no funcionar con su entorno de trabajo preferido y que puede usted elegir qué shell usar. Una de las propiedades comunes de las shell es que completan los nombres de fichero. Una vez que ha introducido las primeras letras de una orden o del nombre de un fichero, se puede hacer que la shell complete automáticamente el resto de la orden o nombre de fichero pulsando la tecla Tab. Veamos un ejemplo. Suponga que tiene dos ficheros llamados talcual y tal.cual. Usted quiere borrar tal.cual. Lo que habría que teclear es: rm ta[tabulador].[tabulador]. La shell mostraría en pantalla rm ta[BIP].cual. El [BIP] es la campana de la consola, es decir, la shell está diciéndome que no pudo completar totalmente el nombre de fichero porque hay más de una coincidencia. Tanto talcual como tal.cual comienzan por ta, pero solo se pudo completar hasta tal. Si se teclea ., y de nuevo tabulador la shell es capaz de añadir el resto del nombre de fichero. variables de entorno Otra función de la shell son las variables de entorno. Las variables de entorno son parejas de valores clave almacenados en el espacio de entorno del shell. Este espacio puede ser leído por cualquier programa invocado por la shell y por lo tanto contiene mucha configuración de programas. Esta es una lista de las variables de entorno más comunes y su significado: variables de entorno Variable Descripción USER Nombre de usuario en el sistema. PATH Lista de directorios, separados por punto y coma, en los que se buscan ejecutables. DISPLAY Nombre de red de la pantalla X11 a la que conectarse, si está disponible. SHELL La shell actual. TERM El nombre de la terminal del usuario. Se usa para determinar las características de la terminal. TERMCAP Base de datos donde encontrar los códigos de escape necesarios para realizar diferentes funciones en la terminal. OSTYPE Tipo de sistema operativo. Por ejemplo, &os;. MACHTYPE Arquitectura de CPU en la que se está ejecutando el sistema. EDITOR El editor de texto preferido por el usuario. PAGER El paginador de texto preferido por el usuario. MANPATH Lista de directorios separados por punto y coma en los que se buscan páginas de manual. Shells Bourne Establecer una variable de entorno difiere ligeramente de shell a shell. Por ejemplo, en las shells al estilo C como tcsh y csh, se usa setenv para establecer las variables de entorno. Bajo shells Bourne como sh y bash, se usa export para establecer las variables de entorno actuales. Por ejemplo, para establecer o modificar la variable de entorno EDITOR (bajo csh o tcsh) la siguiente orden establece EDITOR como /usr/local/bin/emacs: &prompt.user; setenv EDITOR /usr/local/bin/emacs Bajo shells Bourne: &prompt.user; export EDITOR="/usr/local/bin/emacs" También se puede hacer que la mayoría de las shells muestren el contenido de una variable de entorno situando el carácter $ delante del nombre de la variable en la línea de órdenes. Por ejemplo, echo $TERM mostrará cualquiera que sea el valor que haya establecido para $TERM, porque la shell expande el valor de $TERM y se lo pasa al programa echo. Las shells manejan muchos caracteres especiales, llamados metacaracteres, como representaciones especiales de datos. El más común es el caracter *, que representa cualquier número de caracteres en un nombre de fichero. Estos metacaracteres especiales se pueden usar para la expansión de nombres de fichero. Por ejemplo, teclear echo * es casi lo mismo que introducir ls porque la shell toma todos los ficheros que coinciden con * y se los pone en la línea de órdenes para que echo los vea. Para evitar que la shell interprete estos caracteres especiales pueden escamotearse anteponiéndoles una contrabarra (\). echo $TERM imprime el nombre de terminal que esté usando. echo \$TERM imprime $TERM, literalmente. La manera más fácil de cambiar de shell es mediante chsh. chsh le colocará dentro del editor que esté configurado en la variable de entorno EDITOR; si no la ha modificado, el sistema ejecutará vi, el editor por omisión. Cambie la línea «Shell:» según sus gustos. También se le puede suministrar a chsh la opción -s; ésto establecerá la shell sin necesidad de entrar en el editor de texto. Si por ejemplo quiere que bash sea su shell por omisión puede configurarlo del siguiente modo: &prompt.user; chsh -s /usr/local/bin/bash Ejecutar chsh sin parámetros y editar la shell desde ahí también funciona. La shell que se desee usar debe estar incluida en /etc/shells. Si se ha instalado una shell desde la colección de ports esto deberí estar hecho automáticamente. Si ha instalado la shell manualmente, tendrá usted que realizar el cambio oportuno en /etc/shells. Por ejemplo, si instaló manualmente bash y lo ubicó en /usr/local/bin debería hacer lo siguiente: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Hecho esto vuelva a ejecutar chsh. editores de texto editores Gran parte de la configuración de &os; se realiza modificando ficheros de texto, así que le conviene familiarizarse con alguno de ellos. &os; viene con unos cuantos como parte del sistema base y encontrará muchos más en la colección de ports. ee editors ee El editor de textos más sencillo y fácil de aprender es uno llamado ee, cuyo nombre proviene del inglés «easy editor» (editor fácil). Para iniciar ee se debe teclear en la línea de órdenes ee nombre-de-fichero, donde nombre-de-fichero es el nombre del fichero que se quiere editar. Por ejemplo, para editar /etc/rc.conf teclée ee /etc/rc.conf. Una vez dentro de ee todas las órdenes para manipular las funciones del editor están listadas en la parte superior de la pantalla. El caracter ^ representa la tecla Ctrl del teclado, por lo tanto ^e significa la combinación de teclas Ctrle. Para salir de ee pulse la tecla Esc y elija abandonar («leave») el editor. El editor preguntará entonces si quiere conservar los cambios si el fichero hubiera sido modificado. vi editors vi emacs editors emacs &os; viene también con editores de texto mucho más potentes, como vi, como parte del sistema base, mientras que otros editores, como Emacs y vim son parte de la colección de ports de &os; (editors/emacs y editors/vim). Estos editores son muchísimo más poderosos, pero tienen la desventaja de ser un poco más complicados de aprender a manejar. De cualquier manera si planea hacer mucho trabajo de edición de texto, aprender a usar un editor de texto más poderoso como vim o Emacs le ahorrará muchísimo más tiempo a la larga. Dispositivo es un término utilizado la mayoría de las veces para actividades relacionadas con hardware del sistema, como discos, impresoras, tarjetas gráficas y teclados. Cuando &os; arranca, la mayoría de lo que &os; despliega son dispositivos en el momento de ser detectados. Si lo desea, puede volver a ver todos los mensajes que el sistema emite durante el arranque consultando /var/run/dmesg.boot. Por ejemplo, acd0 es la primera unidad CDROM IDE, mientras que kbd0 representa el teclado. En un sistema operativo &unix; debe accederse a la mayoría de estos dispositivos a través de ficheros especiales llamados nodos de dispositivo, que se encuentran en el directorio /dev. Cuando agregue un nuevo dispositivo a su sistema, o compile soporte para dispositivos adicionales, puede que necesite crear uno o más nodos de dispositivo. El dispositivo de sistema de ficheros, o DEVFS, ofrece acceso a dispositivos del espacio de nombres del kernel en el espacio de nombres del sistema de ficheros global. En lugar de tener que crear y modificar nodos de dispositivo, DEVFS se encarga del mantenimiento dinámico de este sistema de fichero. Consulte &man.devfs.5; si quiere más información. Para poder entender por qué &os; utiliza el formato &man.elf.5; primero debe saber ciertas cosas sobre los tres formatos de ejecutables «dominantes» en &unix;: &man.a.out.5; El formato objeto de &unix; más antiguo y «clásico». Utiliza una cabecera corta y compacta con un número mágico al inicio que se usa frecuentemente para identificar el formato (vea &man.a.out.5; para más información). Contiene tres segmentos cargados: .text, .data, y .bss además de una tabla de símbolos y una tabla de cadena («strings»). COFF El formato objeto de SVR3. La cabecera consiste en una tabla de sección, para que pueda tener más contenido además de las secciones .text, .data, y .bss. &man.elf.5; Es el sucesor de COFF; dispone de secciones múltiples y valores posibles de 32-bits o 64-bits. Una gran desventaja: ELF fué también diseñado asumiendo que solamente existiría una ABI por cada arquitectura de sistema. Esa suposición es en realidad bastante incorrecta y ni siquiera en el mundo comercial SYSV (el cual tiene al menos tres ABIs: SVR4, Solaris y SCO) se puede dar por buena. &os; trata de solucionar este problema de alguna manera ofreciendo una herramienta para marcar un ejecutable ELF conocido con información acerca de la ABI con la que funciona. Si quiere más información consulte la página de manual de &man.brandelf.1;. &os; viene del campo «clásico» y ha utilizado el formato &man.a.out.5;, una tecnología usada y probada en muchas de muchas generaciones de versiones de BSD hasta el inicio de la rama 3.X. Aunque era posible compilar y ejecutar binarios nativos ELF (y kernels) en un sistema &os; desde algún tiempo antes de esto, &os; al principio se mantuvo «contra corriente» y no cambió a ELF como formato por defecto. ¿Por qué? Bueno, cuando el mundo Linux efectuó su dolorosa transición a ELF no fué tanto por huir del formato a.out como por su inflexible mecanismo de bibliotecas compartidas basado en tablas de saltos, que hacía igual de difícil la construcción de bibliotecas compartidas tanto para los desarrolladores como para los proveedores. Ya que las herramientas ELF disponibles ofrecían una solución al problema de las bibliotecas compartidas y eran vistas por mucha gente como «la manera de avanzar», el costo de migración fué aceptado como necesario y se realizó la transición. El mecanismo de bibliotecas compartidas de &os; está diseñado de manera más cercana al estilo del sistema de bibliotecas compartidas de &sunos; de Sun y, como tal, es muy sencillo de utilizar. Entonces, ¿por qué existen tantos formatos diferentes? En un tiempo muy, muy lejano, existía hardware simple. Este hardware tan simple soportaba un sistema pequeño, simple. a.out era idóneo para el trabajo de representar binarios en este sistema tan simple (un PDP-11). A medida que la gente portaba &unix; desde este sistema simple, retuvieron el formato a.out debido a que era suficiente para los primeros portes de &unix; a arquitecturas como 68k de Motorola, VAXen, etc. Entonces algún brillante ingeniero de hardware decidió que si podía forzar al software a hacer algunos trucos sucios podría sortear ciertos obstáculos del diseño y permitir al núcleo de su CPU correr más rápidamente. Aunque estaba hecho para trabajar con este nuevo tipo de hardware (conocido entonces como RISC), a.out no estaba bien adaptado para este hardware, así que varios formatos fueron desarrollados para obtener un rendimiento mayor de este hardware que el podía extraerse del limitado y simple formato a.out. Así fué cómo COFF, ECOFF y algunos otros formatos más extraños fueron inventados y sus limitaciones exploradas hasta que se fué llegando a la elección de ELF. Además, el tamaño de los programas estaba volviendose gigante y los discos (y la memoria física) eran relativamente pequeños, así que el concepto de una biblioteca compartida nació. El sistema VM también se volvió más sofisticado. A pesar de que todos estos avances se hicieron utilizando el formato a.out, su utilidad se iba reduciendo paulatinamente con cada nueva opción. Además, la gente quería cargar cosas dinámicamente en el momento de ejecución, o descartar partes de su programa después de que el código de inicio se ejecutara para ahorrar memoria principal y espacio de swap. Al volverse más sofisticados los lenguajes, la gente empezó a ver la necesidad de introducir código antes del inicio del programa de forma automática. Se hicieron muchos hacks al formato a.out para permitir que todas estas cosas sucedieran y lo cierto es que por un tiempo funcionaron. Pero a.out no estaba para solucionar todos estos problemas sin incrementar la carga y complejidad del código. Aunque ELF resolvía muchos de estos problemas, en ese momento hubiera sido terrible dejar de lado un sistema que funcionaba, así que ELF tuvo que esperar hasta que fué más doloroso permanecer con a.out que migrar a ELF. De todas maneras, con el paso del tiempo las herramientas de compilación de las que &os; derivó las suyas (en especial el ensamblador y el cargador) evolucionaron en dos árboles paralelos. El árbol &os; &os; añadió bibliotecas compartidas y corrigió algunos errores. La gente de GNU (que fueron quienes escribieron estos programas) los reescribió y añadieron una forma más simple de disponer de compiladores cruzados («cross compilers»), el uso de diferentes formatos, etc. Aunque mucha gente quería compiladores cruzados con &os; como «blanco» no hubo suerte, porque los fuentes que que &os; tenía para as y ld no estaban listos para cumplir esa tarea. La nueva cadena de herramientas GNU (binutils) soporta compilación cruzada, ELF, bibliotecas compartidas, extensiones C++, etc. Además, muchos proveedores están liberando binarios ELF y es algo muy bueno que &os; los pueda ejecutar. ELF es más expresivo que a.out y permite un sistema base más extensible. Las herramientas ELF están mejor mantenidas y ofrecen soporte de compilación cruzada, muy importante para mucha gente. ELF puede ser un poco más lento que a.out, pero tratar de medirlo puede ser difícil. También existen numerosos detalles que son diferentes entre los dos en cómo gestionan páginas, cómo gestionan código de inicio, etc. Ninguna es muy importante, pero las diferencias existen. Con el tiempo, el soporte para a.out será eliminado del kernel GENERIC y es muy posible que se elimine del kernel la posibilidad de ejecutar tales binarios una vez que la necesidad de usar programas a.out haya pasado. páginas de manual La documentación más exhaustiva de &os; está en las páginas de manual. Casi todos los programas del sistema vienen con un breve manual de referencia explicando el funcionamiento básico y sus diferentes argumentos. Estos manuales pueden revisarse mediante man. El uso de man es simple: &prompt.user; man orden orden es el nombre de la orden sobre la que que desea saber más. Por ejemplo, para más información sobre ls escriba: &prompt.user; man ls El manual en línea está dividido en secciones numeradas: Comandos de usuario. Llamadas al sistema y números de error. Funciones en las bibliotecas de C. Controladores de dispositivo. Formatos de fichero. Juegos y demás pasatiempos. Información sobre temas diversos. Comandos relacionados con el mantenimiento del sistema y su funcionamiento. Desarrolladores del Kernel. En algunos casos, el mismo tema puede aparecer en más de una sección del manual en línea. Por ejemplo, existe una orden de usuario chmod y una llamada del sistema chmod(). En este caso se le puede decir a man cuál desea consultar especificando la sección: &prompt.user; man 1 chmod Esto desplegará la página de manual de la orden de usuario chmod. Las referencias a una sección concreta del manual en línea tradicionalmente suelen colocarse entre paréntesis en la documentación escrita, por lo tanto &man.chmod.1; se refiere a la orden de usuario chmod y &man.chmod.2; se refiere a la llamada de sistema. Esto está muy bien si se conoce el nombre del programa y simplemente se quiere saber como usarlo. Pero ¿y si no puede recordar el nombre de la orden? Se puede usar man para que realice una búsqueda mediante palabras clave en las descripciones de programas utilizando el argumento -k: &prompt.user; man -k mail Dicha orden mostrará una lista de órdenes que contengan la palabra clave «mail» en sus descripciones. Esto es funcionalmente equivalente a usar apropos. Así que, ¿está viendo todos esos programas tan atractivos en /usr/bin pero no tiene ni la menor idea de lo que la mayoría de ellos hace? Haga lo siguiente: &prompt.user; cd /usr/bin &prompt.user; man -f * o &prompt.user; cd /usr/bin &prompt.user; whatis * que hace exactamente lo mismo. Free Software Foundation &os; incluye muchas aplicaciones y utilidades producidas por la FSF (Free Software Foundation). Además de con las correspondientes páginas de manual, estos programas vienen con documentos de hipertexto más detallados, llamados ficheros info, los cuales pueden ser visualizados con info, o si tiene instalado emacs, con el modo info de emacs. Si quiere utilizar la orden &man.info.1; teclée: &prompt.user; info Para una breve introducción teclée h. Cuando necesite una referencia rápida, teclée ?.