En esta secci�n se describen algunos de los servicios m�s importantes en UNIX, pero sin mucho detalle. Se describir�n m�s profundamente en cap�tulos posteriores.
El servicio individual m�s importante en un sistema UNIX es provisto por init. init es el primer proceso que se inicia en todo sistema UNIX, siendo la �ltima acci�n que el n�cleo realiza al arrancar. Cuando init comienza su ejecuci�n, contin�a con el proceso de arranque del sistema, realizando varias tareas de inicio (chequear y montar sistemas de archivos, iniciar demonios, etc.).
La lista exacta de cosas que init realiza depende del sistema tipo UNIX con el que estemos trabajando; existen varios para elegir. init normalmente proporciona el concepto de modo de usuario individual (single user mode), en el cual nadie puede iniciar una sesi�n y root utiliza un int�rprete de comandos en la consola; el modo usual es llamado modo multiusuario (multiuser mode). Algunos sistemas UNIX generalizan esto como niveles de ejecuci�n (run levels). As�, los modos individual y multiusuario son considerados dos niveles de ejecuci�n, y pueden existir otros niveles adicionales para, por ejemplo, ejecutar X-Windows en la consola.
GNU/Linux permite tener hasta 10 niveles de ejecuci�n (runlevels) distintos, 0-9,
pero normalmente solo algunos de estos niveles est�n definidos por defecto. El
nivel de ejecuci�n 0 se define como “sistema detenido (system halt)”. El nivel
de ejecuci�n 1 se define como “modo de usuario individual (single user mode)”.
El nivel de ejecuci�n 6 se define como “reinicio del sistema (system reboot)”.
Los niveles de ejecuci�n restantes dependen de como la distribuci�n particular
de GNU/Linux los haya definido, y var�an significativamente entre
distribuciones. Observando el contenido del archivo
/etc/inittab
podemos hacernos una idea de los niveles de
ejecuci�n preestablecidos en nuestro sistema y de como se encuentran definidos.
En el funcionamiento normal, init se asegura de que getty se encuentre trabajando para permitir que los usuarios puedan iniciar una sesi�n, y tambi�n se encarga de adoptar procesos hu�rfanos (aquellos cuyo proceso padre muri�; en UNIX todos los procesos deben estar en un �rbol individual, y por esta raz�n los procesos hu�rfanos deben ser adoptados).
Al cerrar el sistema, es init quien se encarga de matar todos los procesos restantes, desmontar todos los sistemas de archivos, y por �ltimo detener el procesador, adem�s de cualquier otra cosa que haya sido configurado para hacer.
El inicio de sesiones desde terminales (a trav�s de l�neas serie) y la consola (cuando no se est� ejecutando X-Windows) es suministrado por el programa getty. init inicia una instancia independiente de getty por cada terminal en el que est� permitido iniciar sesiones. Getty lee el nombre de usuario y ejecuta el programa login, el cual se encarga de leer la password. Si el nombre de usuario y la password son correctas, login ejecuta el int�rprete de comandos. Al finalizar el int�rprete de comandos (en el caso en que, por ejemplo, el usuario finaliza su sesi�n; o cuando login finaliza debido a que no concuerdan el nombre de usuario y la password), init se entera de este suceso e inicia una nueva instancia de getty. El n�cleo no tiene noci�n sobre los inicios de sesiones, esto es gestionado totalmente por los programas del sistema.
El n�cleo y muchos programas de sistema producen mensajes de error, de advertencia y de otros tipos. La mayor�a de las veces, es importante que puedan ser visualizados mas tarde, o tal vez mucho despu�s, por lo que tales mensajes deben guardarse en un archivo. El programa que realiza esta tarea es syslog. Syslog puede ser configurado para ordenar los mensajes en diferentes archivos, de acuerdo a quien lo emite o al grado de importancia. Por ejemplo, los mensajes del n�cleo son frecuentemente dirigidos a un archivo separado de los dem�s, debido a que son m�s importantes, y necesitan ser le�dos regularmente para detectar problemas.
Los administradores de sistemas y los usuarios, a menudo necesitan
ejecutar comandos peri�dicamente. Como ejemplo, supongamos que el administrador
del sistema desea ejecutar un comando que elimine los archivos m�s antiguos de
los directorios con archivos temporales (/tmp
y
/var/tmp
) para evitar as� que el disco se llene, debido a
que no todos los programas eliminan correctamente los archivos temporales que
ellos mismos generan.
El servicio cron se configura para que realice la
tarea anterior. Cada usuario tiene un archivo crontab
, en
el cual se listan los comandos que se desea ejecutar y la fecha y hora de
ejecuci�n. El servicio cron se encarga con precisi�n de
iniciar cada comando, a la fecha y hora adecuada de acuerdo a lo especificado en
cada archivo crontab.
El servicio at es similar a cron, pero este se inicia �nicamente una vez: el comando es ejecutado a la hora especificada, pero esta ejecuci�n no vuelve a repetirse.
Se puede encontrar informaci�n adicional sobre cron(1), crontab(5), at(1) y atd(8) en las p�ginas de manual.
UNIX y GNU/Linux no incorporan la interfaz gr�fica de usuario dentro del n�cleo; en su lugar, es implementada por programas a nivel de usuario. Esto se aplica tanto a entornos gr�ficos como al modo texto.
Esta disposici�n hace que el sistema sea m�s flexible, pero tiene la desventaja de que, al ser simple implementar una interfaz de usuario diferente para cada programa, dificulta el aprendizaje del sistema.
El entorno gr�fico principalmente utilizado con GNU/Linux se llama Sistema X-Windows (X para abreviar). X tampoco implementa por s� mismo una interfaz de usuario, sino solo un sistema de ventanas. Es decir, las herramientas base con las cuales se puede construir una interfaz gr�fica de usuario. Algunos administradores de ventanas populares son: fvwm, icewm, blackbox y windowmaker. Existen tambi�n dos populares administradores de escritorios: KDE y Gnome.
Una red se construye al conectar dos o m�s ordenadores para que puedan comunicarse entre s�. Los m�todos actuales de conexi�n y comunicaci�n son ligeramente complicados, pero el resultado final es muy �til.
Los sistemas operativos UNIX tienen muchas caracter�sticas de red. La mayor�a de los servicios b�sicos (sistemas de archivos, impresi�n, copias de seguridad, etc) pueden utilizarse a trav�s de la red. Aprovechar estas caracter�sticas puede ayudar a que la administraci�n del sistema sea m�s f�cil debido a que permiten tener una administraci�n centralizada, a la vez que disfrutamos de los beneficios de la micro inform�tica y la inform�tica distribuida, tales como costes m�s bajos y mejor tolerancia a fallos.
De cualquier modo, este libro s�lo aborda superficialmente la teor�a de redes; Se puede encontrar informaci�n adicional sobre este tema en La Gu�a De Administraci�n De Redes con Linux (Linux Network Administrators' Guide http://www.tldp.org/LDP/nag2/index.html), incluyendo una descripci�n b�sica de como operan las redes.
Los inicios de sesi�n a trav�s de la red funcionan de un modo un poco diferente al inicio de sesiones normales. Existe una l�nea serie f�sica separada para cada terminal a trav�s de la cual es posible iniciar sesi�n. Por cada persona iniciando una sesi�n a trav�s de la red existe una conexi�n de red virtual, y puede haber cualquier n�mero (no hay l�mite). [2] Por lo tanto, no es posible ejecutar getty por separado por cada conexi�n virtual posible. Existen tambi�n varias maneras diferentes de iniciar una sesi�n a trav�s de la red, las principales en redes TCP/IP son telnet y rlogin. [3]
Los inicios de sesi�n a trav�s de la red tienen, en vez de una cantidad enorme de getty's, un servicio individual por tipo de inicio de sesi�n (telnet y rlogin tienen servicios separados) que "escucha" todos los intentos de inicio de sesi�n entrantes. Cuando el servicio advierte un intento de inicio de sesi�n, inicia una nueva instancia de si mismo para atender la petici�n individual; la instancia original contin�a atenta a otros posibles intentos. La nueva instancia trabaja de manera similar a getty.
Una de las cosas m�s �tiles que se pueden hacer con los servicios de red es compartir archivos a trav�s de un sistema de archivos de red. El m�s utilizado normalmente para compartir archivos se llama Network File System, o NFS, desarrollado por Sun Microsystems.
Con un sistema de archivos de red, cualquier operaci�n sobre un archivo realizada por un programa en una m�quina es enviada a trav�s de la red a otra m�quina. Se "enga�a" al programa, haci�ndole creer que todos los archivos en el ordenador remoto se encuentran de hecho en el ordenador en el que el programa se est� ejecutando. Con esta manera de trabajar, compartir informaci�n es extremadamente simple, ya que no se requieren modificaciones en el programa.
Otra manera muy popular de compartir archivos es a trav�s de Samba (http://www.samba.org). Este protocolo (llamado SMB) permite compartir archivos con m�quinas Windows a trav�s del Entorno de Red. Tambi�n permite compartir impresoras.
El correo electr�nico es el m�todo m�s popularmente utilizado para comunicarse a trav�s del ordenador. Una carta electr�nica se almacena en un archivo con un formato especial, y se utilizan programas de correo especiales para enviar y leer las cartas.
Cada usuario tiene un buz�n de correo entrante (un archivo con formato especial), en donde se almacena todo el correo nuevo. Cuando alguien env�a un correo, el programa de correo localiza el buz�n del destinatario y agrega la carta al archivo de buz�n de correo entrante. Si el buz�n del destinatario se encuentra en otra m�quina, la carta es enviada all�, donde se traslada al buz�n de correo como corresponda.
El sistema de correo se compone de muchos programas. El transporte del
correo a buzones locales o remotos es realizado por un programa: el
agente de transporte de correo o MTA.
(Sendmail y Smail son dos ejemplos de
esto), mientras que existe un sin n�mero de programas muy variados que los
usuarios utilizan para leer y escribir correos (Estos son conocidos
como agentes de usuario de correo o MUA,
Pine y Elm son ejemplos de esto). Los
archivos de buzones de correo est�n usualmente ubicados en
/var/spool/mail
.
Solo una persona puede utilizar la impresora en un momento dado, pero ser�a antiecon�mico no compartir impresoras entre los usuarios. La impresora es por lo tanto administrada por software que implementa una cola de impresi�n: todos los trabajos de impresi�n son colocados dentro de la cola, y una vez que la impresora termina de imprimir una trabajo, el siguiente es enviado a la impresora autom�ticamente. Esto alivia al usuario de la organizaci�n de la cola de impresi�n y de luchar por el control de la impresora.
El software de la cola de impresi�n tambi�n coloca los trabajos de impresi�n en disco, es decir, el texto a imprimir es mantenido en un archivo mientras que el trabajo se encuentre en la cola. Esto permite a los programas de aplicaci�n entregar r�pidamente los trabajos a imprimir al software que administra la cola de impresi�n; as�, las aplicaciones no tienen que esperar a que el trabajo (en ingl�s "job") est� de hecho impreso para poder continuar su ejecuci�n. Esta forma de trabajar es realmente c�moda, ya que permite enviar a imprimir una versi�n de un trabajo y no tener que esperar a que �sta sea impresa antes de poder hacer una versi�n nueva completamente revisada.
El sistema de archivos est� dividido en muchas partes; normalmente en las
l�neas de un sistema de archivos ra�z con /bin
,
/lib
, /etc
, /dev
,
y otros pocos directorios; un sistema de archivos /usr
con programas y datos que
no tendr�n cambios; un sistema de archivos /var
con datos que pueden cambiar
(como los archivos de log); y un sistema de archivos /home
para todos los archivos personales de los usuarios. Dependiendo de la
configuraci�n del hardware y de las decisiones del administrador del sistema, la
divisi�n puede llegar a ser diferente; a pesar de esto, y aunque la divisi�n es
aconsejable, es tambi�n posible distribuir todos los archivos en un solo sistema
de archivos.
En el Cap�tulo�4, Visi�n General del �rbol de Directorios se describe la distribuci�n del sistema de archivos con algo de detalle; el documento "Est�ndar de la Jerarqu�a del Sistema de Archivos de Linux" cubre este tema m�s en profundidad. [4]
[2] Al menos puede haber muchas. Dado que el ancho de banda es un recurso escaso, existe a�n en la pr�ctica alg�n l�mite al n�mero de inicios de sesi�n concurrentes a trav�s de una conexi�n de red.
[3] Hoy en d�a muchos administradores de sistemas Linux consideran que telnet y rlogin son inseguros y prefieren ssh , el “int�rprete de comandos seguro” que encripta el tr�fico en la red, haciendo as� bastante menos probable que usuarios malintencionados puedan “espiar” la conexi�n y obtener datos sensibles como nombres de usuario y passwords. Est� altamente recomendado usar ssh en lugar de telnet o rlogin.