Manuales. Tutoriales - Linux Basico
Manuales. Tutoriales - Linux Basico
Manuales. Tutoriales - Linux Basico
Tabla de contenidos
1.1. Introducción a GNU/Linux ..............................................................................2
1.1.1. ¿ Que es Linux ? ...........................................................................2
1.1.2. Razones para utilizar GNU/Linux ..................................................3
1.2. Instalación de un servidor linux ........................................................................3
1.2.1. Requerimientos de Hardware ........................................................3
1.2.2. Métodos de Instalación .................................................................4
1.2.3. Creación de un disquete de arranque ..............................................6
1.2.4. Clases de Instalación ....................................................................7
1.2.5. Particionando el disco duro ...........................................................7
1.2.6. Instalación de paquetes ...............................................................10
1.1. Introducción a GNU/Linux
Hoy en día existen muy buenas razones para optar por Linux ya que, el sistema ofrece es-
tabilidad, seguridad y velocidad. Otro aspecto importante es su capacidad de conectividad en
redes que ha sido decisiva para la conquista del mercado de servidores. Los gurús del Linux
aprecian la disponibilidad del código fuente lo que proporciona al sistema operativo un alto
nivel de independencia y flexibilidad. Debido a esta disponibilidad nadie está a merced de
ningún productor de software sino que es posible hacer adaptaciones y extensiones según las
necesidades. Tampoco hay que olvidar que el uso de Linux no exige la adquisición de licen-
cias; da igual si se usa de forma particular o con propósitos comerciales.
Además de la gran cantidad de aplicaciones libres, cada vez hay mas aplicaciones de uso
comercial para Linux. Productores de Bases de Datos como Oracle, Informix y Sybase al
igual que de suites ofimáticas como Aplix, Corel o OpenOffice ofrecen sus productos para
Linux.
En cuanto a las utilidades se trata generalmente de la versión GNU de los programas co-
rrespondientes de Unix, que la mayoría de las veces ofrecen mayor funcionalidad. El más co-
nocido es el compilador GNU C/C++, considerado uno de los mejores compiladores del
mundo. Tampoco se debe de olvidar todas aquellas utilidades que se pueden usar en la línea
de comandos o en scripts: utilidades de tratamiento de textos o ficheros como sed, awk y perl
(que es mucho mas que una utilidad), hasta editores como el vi o entornos de trabajo comple-
tos como Emacs.
Todo se complementa con el Servidor X Window para sistemas Unix de PC, Xfree86
(actualmente en la versión 4.3.0). Esta versión se ha portado de la distribución oficial
X11R6.3 del consorcio X Consortium Inc., lo que proporciona total compatibilidad con este
estándar.
Como ya se ha mencionado, existe para Unix una cantidad enorme de software libre, lo
que permite a su vez componer una multitud de sistemas Linux. En este punto aparecen las
distribuciones (SuSE, RedHat, Slackware, Debian, OpenLinux, Mandrake ... ), las cuales
contemplan la enorme oferta de software libre y eligen los programas más adecuados para
distribuirlos en forma de CD o través de Internet, así que no hace falta comprar una distribu-
ción para tener un sistema GNU/Linux en nuestros servidores.
Linux se ejecuta en más CPU's y plataformas diferentes que cualquier otro sistema opera-
tivo, ya que Linux viene con el código fuente del Kernel y es fácilmente portable. Si necesi-
tas soporte, Linux representa una ventaja real, especialmente al comparar el coste de otros
sistemas operativos. Además suele ser inmune a la cantidad de virus que afectan a otros sis-
temas operativos.
Como su propio nombre indica, necesitará un CD-ROM de Red Hat Linux, una unidad de
CD-ROM soportada, y una manera de arrancar el programa de instalación.
Los sistemas Intel necesitarán usar un disquete de arranque (y el disquete con soporte
PCMCIA si se usa un dispositivo PCMCIA durante la instalación). Hay un método alternati-
vo para instalar desde CD-ROM que no usa disquetes, pero requiere que el sistema esté eje-
cutando DOS. El CD-ROM de Fedora Linux/Intel también puede ser el disco de arranque pa-
ra los ordenadores nuevos que soporten CD-ROMs auto arrancables. No todos los ordenado-
res aceptan esta característica, así que si el suyo no puede arrancar desde CD-ROM, tendrá
que utilizar un disquete de arranque (o aoutoboot desde DOS) para comenzar el proceso.
Tenga en cuenta que puede necesitar cambiar la configuración de su BIOS para habilitar esta
característica.
Al realizar una instalación por FTP, necesitará acceso a una red basada en LAN; una co-
nexión telefónica vía módem no funcionará. Si su Red de Área Local (Local Area Network)
tiene acceso a Internet, puede usar uno de los muchos sitios FTP que hacen espejo de Red
Hat Linux. Puede encontrar una lista de sitios en http://www.redhat.com/mirrors.html. Si su
LAN carece de acceso a Internet, no todo está perdido. Si hay un ordenador en su LAN que
acepte peticiones anónimas de FTP, simplemente ponga una copia de la distribución Red Hat
Linux en ese sistema, y estará listo para empezar.
Su servidor de FTP debe ser capaz de manejar nombres largos de archivo. Para instalar
por FTP, debe utilizar el disco de arranque específico a la instalación por red, y un disquete
con soporte PCMCIA si va a usar un dispositivo PCMCIA durante la instalación. Necesitará
tener configurado un servidor de nombres válido o deberá especificar la dirección IP del ser-
vidor de FTP que vaya a utilizar. También necesitará saber el path o camino del directorio de
Red Hat Linux en el servidor de FTP.
El método de instalación desde disco duro requiere un poco de esfuerzo por adelantado de
su parte, pues debe copiar todos los archivos necesarios en una partición antes de comenzar
el programa de instalación de Red Hat Linux. Primero debe crear un directorio Fedora en el
directorio raíz de su árbol de directorios. Todo lo que vaya a instalar debe estar colocado en
ese directorio. A continuación, copie las imágenes ISO de los CD's en ese directorio. El sis-
tema de instalación se encargará de acceder a los paquetes una vez hemos indicado la ruta a
Un archivo imagen es un fichero que contiene una copia exacta (o imagen) del contenido
de un disquete. Como el disquete contiene información del sistema de archivos, aparte de la
información contenida en los ficheros, el archivo imagen no se podrá usar hasta que lo escri-
bamos en un disquete. Para hacer esto, necesitará un disquete de 3,5 pulgadas de alta densi-
dad (1.44 MB), y un ordenador con unidad de disquetes adecuada para este formato, capaz
de ejecutar un programa DOS o la utilidad dd, que puede encontrar en la mayoría de los sis-
temas operativos del estilo de Linux.
Puede encontrar los ficheros imagen en los siguientes directorios de su CD de Red Hat
Linux. Suponiendo que el CD-ROM se encuentra en la unidad D: bajo DOS, habrá que acce-
der al directorio d:\images.
Para preparar un disquete bajo MS-DOS, emplee la utilidad rawrite que incluímos en el
CD de Red Hat Linux en el directorio dosutils. Primero etiquete un disquete formateado con
el nombre adecuado. Introdúzcalo en la unidad de disquetes, y emplee las siguientes órdenes
en su computadora. Asumimos que su unidad de CD es D::
D:> cd dosutils
D:> rawrite
Enter disk image source file name: ..\images\boot.img
Enter target diskette drive: a:
Please insert a formatted diskette into drive A: and press ENTER
rawrite le preguntará primero por el nombre del archivo imagen. Introduzca el nombre
completo, incluyendo el directorio, del archivo que desea escribir en el disquete, por ejem-
plo: ..\images\boot.img. A continuación, rawrite pregunta por la unidad de disquete a donde
transferir el fichero imagen. Por último, rawrite le pide que confirme que hay un disquete
formateado en la unidad seleccionada. Una vez que haya pulsado Intro para confirmar, rawri-
te copia el fichero imagen al disquete. Si precisa preparar otro disquete, etiquételo y utilice
rawrite de nuevo, indicando el achivo imagen apropiado.
Para preparar un disquete de instalación bajo Linux, u otro sistema operativo de su mismo
tipo, precisa de permiso de escritura para el dispositivo asociado a la unidad de disquetes de
3.5" (/dev/fd0 bajo Linux). Primero etiquete un disquete formateado y en blanco de manera
grooucho@fferrer$ cd /mnt/cdrom/images
grooucho@fferrer$ dd if=boot.img of=/dev/fd0
De todas formas vamos a analizar algunas situaciones con las que nos podemos encontrar
a la hora de particionar nuestro disco duro.
Que las particiones de Fedora Linux vayan a compartir el disco duro con particiones usa-
das por otros sistemas operativos, la mayoría de las veces, no le supondrá ningún problema.
Aún así, hay ciertas combinaciones de Linux con otros sistemas operativos que requieren
precauciones adicionales. Hay información sobre cómo crear particiones compatibles con
otros sistemas operativos en varios COMOs y Mini-COMOs (HOWTOs y Mini-HOWTOs),
incluídos en el CD de Red Hat Linux en los directorios doc/HOWTO y doc/HOWTO/mini.
En particular, los Mini-COMOs cuyos nombres comienzan con Linux+ son bastante útiles.
Si Fedora Linux/Intel va a coexistir en su sistema con OS/2, debe crear las particiones de
su disco duro con el software de particionamiento de OS/2--de otro modo, OS/2 puede no re-
conocer las particiones. Durante la instalación, no cree particiones nuevas, pero establezca
correctamente los tipos de partición de sus particiones Linux usando fdisk para Linux.
Esto es completamente distinto a cómo Linux maneja las particiones y, a los efectos, el
almacenamiento en disco en general. La diferencia principal es que cada partición se integra
en el sistema de almacenamiento necesario para formar parte de un sólo juego de archivos y
directorios. Esto se consigue asociando una partición con un directorio mediante un proceso
conocido como montaje. Montar una partición significa disponer de su capacidad de almace-
namiento comenzando en el directorio especificado (conocido como punto de montaje).
Por ejemplo, si la partición /dev/hda5 estuviera montada en /usr, significaría que todos los
archivos y directorios bajo /usr estarían físicamente alojados en /dev/hda5. Por lo tanto, el ar-
chivo /usr/doc/FAQ/txt/Linux-FAQ estaría almacenado en /dev/hda5, mientras que el archivo
/etc/X11/gdm/Sessions/Gnome no lo estaría. Continuando con nuestro ejemplo, también es
posible que uno o más directorios bajo /usr fueran puntos de montaje para otras particiones.
Como ejemplo, una partición (digamos /dev/hda7) estaría montada en /usr/local, queriendo
decir que, por ejemplo, /usr/local/man/whatis residiría en /dev/hda7 y no en /dev/hda5.
Número de particiones
En este punto del proceso de preparación para instalar Fedora Linux, necesitará considerar el
número y el tamaño de las particiones que utilizará su nuevo sistema operativo. Se recomien-
da, a no ser que tenga una razón para no hacerlo, crear las siguientes particiones como míni-
mo.
Una partición de intercambio (swap). Las particiones de intercambio se usan como apoyo
a la memoria virtual. Si su ordenador tiene 16 MB de RAM o menos, debería crear una parti-
ción para el intercambio. Incluso teniendo suficiente memoria, se sigue recomendando tener
una partición swap. El tamaño mínimo debería ser igual a la RAM presente en su ordenador.
Una partición /boot. La partición montada en /boot contiene el kernel del sistema operati-
vo, así como los archivos usados durante el arranque. Debido a las limitaciones de la mayo-
ría de las BIOS de los PCs, no es mala idea crear una pequeña partición para alojar estos ar-
chivos. Esta partición no debería ser mayor de 16MB.
La partición raíz o partición root. La partición raíz es donde reside / (el directorio raíz).
En este perfil de particiones, todos los archivos (excepto los alojados en /boot) se encuentran
en la partición raíz. Por ello, interesa maximizar el tamaño de la partición raíz. Una partición
raíz de unos 1500 MB le proporcionará el equivalente a una instalación de tipo workstation
(con muy poco espacio libre, mientras que una partición raíz de 4 GB le permitirá instalar to-
dos los paquetes.
De todas formas, es posible crear una estructura de particiones diferentes para adecuarla a
las funciones que realice nuestro servidor. No sería mala idea colocar los directorios /tmp y /
home en particiones separadas de la partición raíz, ya que si los usuarios van a acceder al
servidor, esta división prevendrá que estos puedan llenar cualquier sistema de ficheros críti-
co. Tampoco sería mala idea colocar /var y /usr en particiones separadas, por las mismas ra-
zones esgrimidas anteriormente.
Por último comentar que será a través de la herramienta Disk Druid, donde podremos de-
finir el número y el tipo de las particiones que requerirá nuestro sistema. Hay que comentar
que el tipo de las particiones que utiliza Linux es el ext3 (por lo menos la particiones del sis-
tema deberán de ser de este tipo), lo cual no le impide que pueda ser capaz de leer o crear
otro tipo de particiones.
GRUB (GRand Unified Bootloader), el cargador por defecto, es el mas poderoso. Puede
cargar una gran variedad de sistemas operativos libres, así como sistemas operativos propie-
tarios utilizando la técnica de chain-loading.
LILO (LInux LOader) es también un cargador para linux muy eficaz. No depende de un
sistema de ficheros específico y puede arrancar/cargar imágenes del kernel linux desde dis-
quete o disco duro, así como otros sistemas operativos.
Los componentes agrupan paquetes según la funcionalidad que proporcionan. Por ejem-
plo, Desarrollo C [C Development], Estación de Trabajo en Red [Networked Workstation], o
Servidor Web [Web Server]. Seleccione cada componente que desee instalar y presione Es-
pacio. Si selecciona Todo [Everything] (puede ser encontrado al final de la lista de compo-
nentes) se instalan todos los paquetes incluidos en Red Hat Linux. Si selecciona todos los pa-
quetes, necesitará cerca de 1Gb de espacio de disco libre.
Después de seleccionar los componentes que desea instalar, puede querer seleccionar o
deseleccionar paquetes individuales. El programa de instalación presenta una lista de los gru-
pos de paquetes disponibles; utilizando las flechas, seleccione un grupo para examinar, y
presione Intro o Espacio. El programa de instalación presenta una lista de los paquetes de ese
grupo, que debe seleccionar o deseleccionar utilizando las flechas para resaltar un paquete, y
presionando Espacio. Algunos paquetes (tales como el núcleo y ciertas librerías) son necesa-
rios en todos los sistemas Red Hat Linux y no están disponibles para ser seleccionados o de-
seleccionados.
Muchos de los paquetes software, para trabajar correctamente, dependerán de otros pa-
quetes software, o librerías que deben ser instaladas en su sistema. Por ejemplo, muchas de
las herramientas gráficas de administración de sistema de Red Hat requieren los paquetes
python y pythonlib. Para asegurar que su sistema tenga todos los paquetes que necesite para
ser completamente funcional, Red Hat Linux comprueba las dependencias de estos paquetes
cada vez que instala o elimina paquetes software. Después de que haya acabado de seleccio-
nar paquetes para instalar, el programa de instalación comprueba la lista de dependencias de
los paquetes seleccionados. Si cualquier paquete necesita otro paquete que no ha selecciona-
do para instalar, el programa presenta una lista de estas dependencias sin resolver y le da la
oportunidad de resolverlas. Si simplemente presiona Aceptar [Ok], el programa las resolverá
automáticamente añadiendo todos los paquetes requeridos por la lista de paquetes seleccio-
nados.
Después de haber resuelto todas las dependencias de los paquetes, el programa de instala-
ción presenta un cuadro de diálogo indicándonos que se va a escribir el fichero /
tmp/install.log con un registro de todos los paquetes instalados en su Red Hat Linux. Selec-
cione la opción Aceptar [Ok] y presione Espacio para continuar. En este punto, el programa
de instalación formateará todas las particiones que haya seleccionado para formatear. Este
proceso puede llevar varios minutos, (e incluso será más largo si le indicó al programa de
instalación que comprobara los bloques dañados). Una vez formateadas las particiones, el
programa de instalación empieza a instalar paquetes.
Tabla de contenidos
2.1. Configuración del Proceso de arranque ...........................................................12
2.1.1. La Secuencia de Arranque ...........................................................12
2.1.2. Niveles de ejecución ...................................................................13
2.1.3. Configuración de los niveles de ejecución ....................................16
2.1.4. Configuración del gestor de arranque GRUB ................................19
2.2. Configuración del Sistema .............................................................................22
2.2.1. /etc/sysconfig .............................................................................22
2.2.2. Configuración de Red .................................................................23
2.2.3. Configuración del entorno gráfico ...............................................26
2.1. Configuración del Proceso de arranque
Una vez que se haya cargado, la BIOS chequea los periféricos y localiza un dispositivo
con el que arrancar el sistema. Habitualmente, en primer lugar comprueba cualquier disquete
y unidades de CD-ROM presente por los medios de arranque, y a continuación si esto falla,
echa un vistazo a las unidades de disco duro del sistema. El orden de las unidades necesario
para arrancar puede ser controlado por la BIOS. La BIOS carga en memoria cualquier pro-
grama que resida en el primer sector de este dispositivo, llamado Master Boot Record o
MBR. El MBR sólo tiene 512 bytes de tamaño y contiene las instrucciones de código de má-
quina para el arranque del equipo, llamado gestor de arranque así como también la tabla de
particiones. Una vez que la BIOS haya encontrado y cargado el gestor de arranque en memo-
ria, le deja el control del proceso de arranque a éste.
Los gestores de arranque de Linux para la plataforma x86 se dividen en dos etapas. La
primera es un pequeño código binario que se encuentra en el MBR. Su única función es la de
localizar el gestor de arranque de la segunda etapa y cargar la primera parte de éste en me-
moria. GRUB es uno de los gestores de arranque más modernos, siendo capaz de leer parti-
ciones casi de cualquier tipo, pudiendo cargar su archivo de configuración — /
boot/grub/grub.conf — en el momento de arranque desde cualquiera de ellas
Una vez que la segunda etapa del gestor de arranque está en memoria, presenta al usuario
una pantalla gráfica mostrando los diferentes sistemas operativos o kernels que puede arran-
car. En esta pantalla el usuario puede usar las flechas direccionales para escoger el sistema
operativo o kernel con el que desea arrancar y presionar la tecla [Intro]. Si no se presiona
ninguna tecla, el gestor de arranque carga la entrada predeterminada después de un período
de tiempo de espera (también configurable).
Una vez que el gestor de arranque de la segunda etapa haya determinado qué kernel
arrancar, localizará el binario del kernel correspondiente en el directorio /boot/. La llamada
al kernel sigue el siguiente formato — /boot/vmlinuz-<kernel-version> (donde
Cuando el comando init arranca, se convierte en el proceso padre de todos los procesos
que comienzan automáticamente en el sistema. Init lee el fichero /etc/inittab que describe
cómo el sistema debería configurarse en cada nivel de ejecución (ver sección Sección 2.1.2,
“Niveles de ejecución”). Básicamente, antes de establecer el nivel de ejecución, init ejecuta
el script /etc/rc.d/rc.sysinit, que establece la variable PATH, activa el swap, controla los sis-
temas de fichero y se encarga de todo lo que el sistema necesita tener hecho al momento de
la inicialización. A continuación procede a ejecutar todos los servicios que estén definidos en
el nivel de ejecución predeterminado (ver sección Sección 2.1.2, “Niveles de ejecución” )
Bajo esta perspectiva, un sistema Linux no se arranca o detiene, sino que simplemente se
cambia su nivel de ejecución. Algunas consideraciones importantes sobre los niveles son:
• Desde el cargador puede expresarse el nivel de ejecución deseado pasándole como pará-
metro al kernel el nivel de ejecución.
id:5:initdefault:
El programa init inicia todas las entradas de /etc/inittab que se correspondan con
el nivel de ejecución por defecto. Un listado con las entradas más relevantes que se ejecuta-
rán en el nivel 5 se muestra a continuación:
l5:5:wait:/etc/rc.d/rc 5
Realmente, /etc/rc.d/rc cuando entra en un determinado nivel de ejecución realiza las si-
guientes acciones:
1. Ejecuta, por orden de nombre, todos los scripts que comienzan por K en el directorio
correspondiente al nivel, utilizando como argumento para dicho script la opción stop.
2. Ejecuta, por orden de nombre, todos los scripts que comienzan por S en el directorio co-
rrespondiente al nivel, utilizando como argumento para dicho script la opción start.
total 0
lrwxrwxrwx 1 root root 13 Apr 1 1998 K15gpm -> ../init.d/gpm
lrwxrwxrwx 1 root root 13 Apr 1 1998 K60lpd -> ../init.d/lpd
lrwxrwxrwx 1 root root 15 Apr 1 1998 K95nfsfs -> ../init.d/nfsfs
lrwxrwxrwx 1 root root 17 Apr 1 1998 S01kerneld -> ../init.d/kerneld
lrwxrwxrwx 1 root root 17 Apr 1 1998 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Apr 1 1998 S20random -> ../init.d/random
lrwxrwxrwx 1 root root 16 Apr 1 1998 S30syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 13 Apr 1 1998 S40atd -> ../init.d/atd
lrwxrwxrwx 1 root root 15 Apr 1 1998 S40crond -> ../init.d/crond
lrwxrwxrwx 1 root root 18 Apr 1 1998 S75keytable -> ../init.d/keytable
lrwxrwxrwx 1 root root 11 Apr 1 1998 S99local -> ../rc.local
Como puede apreciar, ninguno de los scripts que inician y apagan los servicios están loca-
lizados en el directorio /etc/rc.d/rc3.d/. Casi todos los ficheros en /
El administrador puede configurar las acciones que deben realizarse al entrar en un deter-
minado nivel de ejecución. A modo de resumen, los directorios y ficheros relevantes para
configurar el proceso de arranque se detallan a continuación:
/etc/rc.d/init.d Aquí residen todos los scripts reales que pueden ser ejecutados
cuando se entra en un nivel de ejecución.
Hay que tener en consideración que los scripts que residen en el directorio /
etc/rc.d/init.d pueden utilizarse directamente, lo que permite iniciar o detener servi-
cios de forma manual. Por ejemplo, los siguientes mandatos detienen el subsistema de red y
lo vuelven a iniciar:
# /etc/rc.d/init.d/network stop
# /etc/rc.d/init.d/network start
El sistema Linux, según la distribución elegida, vendrá con una configuración predetermi-
nada de servicios que se deben lanzar en el proceso de arranque del sistema. De nuevo el ad-
ministrador puede variar ese comportamiento. Si hemos seguido con atención la sección an-
terior, la forma más directa de hacer que un determinado servicio no se lance en un nivel de
ejecución, sería borrar el enlace simbólico que exista en el directorio predeterminado del ni-
vel de ejecución ( /etc/rc.d/rc<x>.d ). Si queremos volver a arrancar en el proceso de
Si por el contrario, nuestras necesidades pasan por añadir al proceso de arranque un nue-
vo servicio, los pasos necesarios para integrarlo serían los siguientes:
2. Crear los enlaces simbólicos necesarios para parar y arrancar el servicio en el directorio
que represente el nivel de ejecución predeterminado:
# cd /etc/rc.d/rc5.d
# ln -s /etc/rc.d/init.d/miservicio S90miservico
Para facilitar la tarea al administrador, CentOS posee un par de herramientas que ayudan
en todo este proceso.
chkconfig
El comando chkconfig permite añadir y eliminar servicios en los niveles de ejecución, así
como consultar la configuración de cada servicio. La sintaxis de este mandato es la siguiente:
chkconfig --list [name] chkconfig [--level levels] name <on|off|reset>
Utilizado con la opción --list, este mandato visualiza la configuración de todos los servi-
cios o de un nivel concreto. Las acciones on y off activan y desactivan respectivamente un
servicio en los niveles especificados. La acción reset reestablece los valores predeterminados
para este servicio.
redhat-config-services
Desde la versión RedHat 8, el sistema incorpora una serie de utilidades gráficas para poder
configurar las diferentes opciones del sistema. En CentOS, las herramientas que aparecen ba-
jo el nombre redhat-config-<servicio> son las encargadas de la configuración.
Esta herramienta nos permite Arrancar, Parar y Reiniciar un servicio, así como definir en
que niveles se ejecutará por defecto.
ntsysv
La utilidad basada en la librería ncurses /usr/sbin/ntsysv proporciona una interfaz interactiva
en modo texto, más fácil de usar que chkconfig. No es tan versátil pero permite definir que
servicios serán arrancados en el nivel de ejecución por defecto.
GRUB posee una serie de características que lo convierten en el método favorito respecto
al resto de gestores de arranque disponibles para la arquitectura x86. A continuación expone-
mos una lista de las características más importantes:
3. GRUB puede leer casi todo tipo de particiones. Esto permite que GRUB acceda a su ar-
chivo de configuración, /boot/grub/grub.conf, cada vez que el sistema arranca,
eliminando la necesidad que tiene el usuario de escribir una nueva versión de la primera
etapa del gestor de arranque al MBR en caso de que se produzcan cambios de la confi-
guración. El único caso en el que el usuario necesitaría reinstalar GRUB en el MBR es
en caso de que la localización física de la partición /boot/ se traslade en el disco.
Instalación de GRUB
Si decidió no instalar GRUB durante el proceso de instalación, se puede hacer después. Una
vez instalado, se convierte en el gestor de arranque por defecto. Para instalar el paquete que
contiene GRUB en CentOS, ejecute el siguiente comando:
# yum install grub
Una vez que el paquete GRUB esté instalado, abra un intérprete de comandos de la shell
y ejecute el comando /sbin/grub-install <location>, donde <location> es la ubicación en la
que la Etapa 1 de GRUB debería ser instalado. Por ejemplo, el comando siguiente instala
GRUB al MBR del dispositivo maestro IDE en el bus IDE primario:
# /sbin/grub-install /dev/hda
La próxima vez que arranque el sistema, el menú del gestor de arranque gráfico de GRUB
aparecerá antes de que el kernel se cargue en memoria.
Los comandos disponibles en esta sección son un subconjunto de los que pueden aparecer
en el fichero de configuración de GRUB. A continuación se muestran los más importantes:
• hide <partition>. Oculta la partición especificada por la opción <partition>. Este coman-
do es útil cuando se pretende arrancar un sistema operativo como Windows donde exis-
ten múltiples particiones FAT o NTFS en el mismo disco.
• default=<valor>. Entrada que será ejecutada por defecto sino hay intervención del usua-
rio.
2.2.1. /etc/sysconfig
Existen algunos ficheros de configuración específicos de Fedora Core 1 en el directorio /
Por ejemplo, la red se configura a base de ejecutar scripts que se encuentran en este direc-
torio. El sentido básico de este directorio es mantener información de configuración que leen
los diferentes servicios del sistema antes de ejecutarse.
Básicamente la información que se necesita para configurar una tarjeta de red adecuada-
mente y que tengamos acceso a la red es una dirección IP y una máscara de red. Luego debe-
ríamos saber cual es el servidor DNS ( que resolverá nombres en direcciones IP ) y si quere-
mos tener acceso a Internet, el nombre del gateway o pasarela.
Ifconfig es la utilidad que permite configurar manualmente nuestra tarjeta de red. Pero
hay que tener en mente que cuando se configura nuestro dispositivo de red manualmente, es-
tas propiedades no permanecerán ante un reinicio del sistema, por tanto habrá que habilitar
algún mecanismo para que esto no sea un problema ( estos y otros aspectos se verán en el
punto Arranque y Parada del sistema ).
Para asignar al interfaz de red ( representada para el sistema como el dispositivo eth0 ) la
dirección IP 158.42.48.111 usaremos el siguiente comando:
Para ver todas las tarjetas que tenemos y la información relativa a ellas podremos usar el
comando:
[root@mis01]# ifconfig
Como se puede observar, en Fedora Core Linux, todas las comunicaciones de red se pro-
ducen entre interfaces de software configuradas y dispositivos de red físicos conectados al
sistema. Si queremos que nuestra configuración de red se mantenga en cada arranque habrá
que definir la información de TCP/IP en los diferentes ficheros que utiliza Fedora Core para
levantar la red.
NETMASK=255.255.255.0
IPADDR=10.0.0.1
USERCTL=no
• /etc/modules.conf. Este fichero mantiene los módulos del kernel que serán carga-
dos en el arranque. El driver de la tarjeta de red debría aparecer aquí.
alias eth0 e100
Si no lo consigue, system-config-display presentará una lista con todas las tarjetas de ví-
deo. Se selecciona una tarjeta de vídeo de la lista y pulse Intro. Si su tarjeta de vídeo no apa-
rece en la lista puede deberse a que no esté soportada por XFree86. No obstante, si posee las
características técnicas de su tarjeta, debe seleccionar Tarjeta no incluida en la lista e intentar
configurarla estableciendo el chipset de vídeo de su tarjeta con uno de los servidores-X dis-
ponibles.
Tabla de contenidos
3.1. Introducción .................................................................................................30
3.2. Creación de un sistema de ficheros .................................................................31
3.3. Montaje de sistemas de ficheros .....................................................................31
3.3.1. /etc/fstab ....................................................................................32
3.4. Sistema de cuotas ..........................................................................................33
3.4.1. Activación de las cuotas ..............................................................33
3.4.2. Cuotas de usuario .......................................................................34
3.5. Memoria virtual: swap ...................................................................................35
3.5.1. Sistema de ficheros de swap ........................................................35
3.5.2. Creación de un fichero de swap ...................................................36
3.6. Copias de seguridad en linux ..........................................................................36
3.6.1. dump y restore ...........................................................................36
3.6.2. tar ..............................................................................................38
3.1. Introducción
3.1. Introducción
Un sistema de ficheros son los métodos y las estructuras de datos que emplea el sistema ope-
rativo (en nuestro caso, Linux) para organizar los ficheros en disco. El término Sistema de
Ficheros se utiliza tanto para referirse a una partición o a un disco. Pero hablando con pro-
piedad, muchos programas no trabajarán satisfactoriamente con una partición que no conten-
ga un sistema de ficheros.
Linux soporta varios tipos de sistemas de ficheros. Entre los más importantes podemos
destacar los siguientes:
• MINIX: el más antiguo, presume de ser el más seguro, pero es bastante limitado en las
características que proporciona. Un sistema de ficheros de este tipo solo puede tener 64
MB.
• EXT2: es el sistema de ficheros nativo de Linux. Está diseñado para ser compatible con
versiones anteriores, así que las nuevas versiones del código del sistema de ficheros no
requerirán rehacer los sistemas de ficheros existentes.
• VFAT: este tipo permite utilizar sistemas de ficheros de Windows (FAT, FAT32), y ac-
tualmente está soportado el sistema de ficheros de Windows NT, pero solo fiable en solo-
lectura.
• NFS: un sistema de ficheros en red que permite compartir sistemas de ficheros entre dife-
rentes máquinas conectadas en red y tratarlos de forma local.
Existe también un sistema de ficheros especial denominado proc, y que es accesible via el
directorio /proc, el cual no es realmente un sistema de ficheros. El sistema de ficheros /proc
permite acceder fácilmente a ciertas estructuras de datos del kernel, como es la lista de pro-
cesos. Convierte estas estructuras de datos en algo parecido a un sistema de ficheros y por
tanto da la posibilidad de manipularlas con las herramientas habituales de manipulación de
ficheros. Hay que tener en cuenta que aunque se le denomine sistema de ficheros, ninguna
parte del sistema de ficheros /proc toca el disco. El existe únicamente en la imaginación del
kernel.
Para crear un sistema de ficheros del tipo ext2 en disquete, podríamos seguir los siguien-
tes pasos:
fdformat -n /dev/fd0H1440
badblocks /dev/fd0H1440 1440 > listadebloquesmalos
mkfs -t ext2 -l listadebloquesmalos /dev/fd0H1440
En primer lugar formateamos el disquete con la opción -n que previene que chequee blo-
ques malos, para en un segundo paso generar una lista de bloques defectuosos con el coman-
do badblocks. Esa lista se la pasaremos al comando mkfs que creará el sistema de ficheros en
el disquete.
Imaginemos dos sistemas de ficheros separados, cada uno con su propio directorio raiz.
Cuando el segundo sistema de ficheros se monte bajo el directorio /home en el primer siste-
ma de ficheros, se obtendrá un único árbol de directorios.
Si por ejemplo no deseáramos que nadie pudiera escribir en el sistema de ficheros se po-
dría haber usado la opción -r de mount para indicar que es un sistema de ficheros de solo lec-
tura. Esto obligará al kernel a detener cualquier intento de escritura sobre el sistema de fiche-
ros y también detendrá cualquier actualización de los tiempos de acceso de los inodos.
En este momento alguien puede preguntarse como es posible que el sistema de ficheros
raiz se monte, ya que no puede ser montado en otro sistema de ficheros. Entonces si es siste-
ma de ficheros raíz no puede ser montado, el sistema no arrancará nunca. La respuesta está
en que ese sistema de ficheros que se monta como root está compilado en kernel o definido
utilizando LILO o el comando rdev.
Un ejemplo claro son los disquetes, que no deberían ser extraídos sin previamente haber
desmontado el sistema de ficheros. Ya que debido al caché de disco los datos no son necesa-
riamente escritos hasta que se desmonta.
3.3.1. /etc/fstab
En la mayoría de sistemas existen otras particiones además de la raíz que son necesarias se
monten en el arranque. Estas serán especificadas en el fichero /etc/fstab que contiene todas
las informaciones que conciernen el montaje de sus particiones.
#/etc/fstab
# Dispositivo Direct type options frequence passe
/dev/hda2 / ext3 defaults 5 1
/dev/hdb2 /usr2 ext3 defaults 5 2
/dev/sda2 /usr3 ext3 defaults 10 2
/dev/hda1 /dos msdos defaults 0 0
/dev/hdb1 /dos2 msdos defaults 0 0
none /proc proc defaults 0 0
/dev/hda3 none swap defaults 0 0
/usr2/swapfile /usr2 swap defaults 0 0
• tipo de la partición.
• frecuencia: correspondiente al número de días entre dos tratamientos del archivo por la
orden dump. Esta orden existe solamente para ext2fs (es una migración de la versión
Existen mas opciones que la de por defecto a la hora de montar un dispositivo. Para auto-
rizar a un usuario a montar un volumen, tiene que crear una linea que contenga la opción
"user" Ejemplo (caso de un CD-ROM SCSI) :
Además, se puede configurar las cuotas no sólo para que controlen el número de bloques
de disco sino también el número de inodos. Debido a que los inodos son usados para almace-
nar información relacionada a los archivos, esto permite controlar el número de archivos que
pueden ser creados.
El soporte de cuotas de disco ha sido integrado en el kernel Linux desde la versión 1.3.46.
Se necesita utilizar un kernel posterior para poder beneficiarse de las cuotas. El paquete soft-
ware necesario que permite gestionar las cuotas es quota. Además necesitamos tener esa op-
ción compilada en el kernel respondiendo afirmativamente a la opción Quota support. Con
esto conseguiremos limitar el espacio de disco consumido por usuario o por un grupo de
usuarios.
Para activar las cuotas para los usuarios es necesario indicar la opción usrquota para los
sistemas de archivos referidos en /etc/fstab. Las cuotas que conciernen a los grupos son regu-
ladas por la opción grpquota. Los archivos de definición de cuotas se llaman respectivamente
quota.user y quota.group y están situados en la raíz de cada sistema de archivos involucrado.
Es posible modificar los nombres de los archivos de gestión de cuotas utilizando la sintá-
xis siguiente:
usrquota=nombredearchivo
grpquota=nombredearchivo
La activación de las cuotas es lanzada por la orden quotaon. Para activarlas automática-
mente a la inicialización del sistema, se debe agregar al archivo de inicialización (/etc/rc.d)
las líneas:
quotaon -avug
quotacheck -avug
Para cada usuario o grupo existen dos limitaciones: el número de archivos y el número de
bloques disco (expresados en bloques de 1024 octetos). Para cada uno existen dos límites:
• El límite "duro": cuando este límite es alcanzado el usuario no puede escribir nuevos ar-
chivos o nuevos bloques.
Se puede definir una plantilla de usuario al cual se le asignan las cuotas y utilizarla para
adjudicar cuotas a los demás usuarios del sistema.
Todo usuario puede obtener el estado de la cuota que le ha sido asignada (limites como el
número de archivos y de bloques que le han sido atribuidos) gracias a la orden quota.
El superusuario puede obtener las mismas informaciones sobre cualquier usuario o grupo
con la misma orden : quota -u usuario o quota -g grupo. Además es posible utilizar la orden
repquota para obtener una lista de cuotas asociadas a uno o varios sistemas de archivos.
Para que esto se tenga en cuanta cada vez que arranque el sistema habría que añadir la lí-
nea
Hay que tener en cuenta que se debe poner esta línea después del montaje de la partición /
usr2. Sino, no funcionará nunca.
swapoff -a
reboot
Una vez que las fuentes han sido compiladas e instaladas, la utilización de dump y restore
es relativamente simple. Para realizar la copia de seguridad de una partición /dev/sda1 sobre
/dev/rmt0, es suficiente hacer:
Existen otras opciones. Para mayor información, consultar las páginas del manual. Exis-
ten dos maneras de efectuar una restauración : en línea de ordenes o en modo llamado "inte-
ractivo". El segundo modo es más simple para las restauraciones parciales. El primero es so-
bre todo utilizado para las restauraciones completas.
En este caso, un mini-intérprete de órdenes es ejecutado. Utilice la orden help para más
detalles.
# restore rf /dev/rmt0
Para la utilización de dump y restore a través de una red (copia de seguridad sobre dispo-
sitivos remotos), debe utilizar los archivos .rhosts. En el siguiente ejemplo de copia de segu-
ridad, la máquina "mis01" debe tener:
# cat ~root/.rhosts
fferrer
Cuidado de todas formas con los fallos de seguridad engendrados por los ficheros .rhosts.
El uso de dispositivos remotos necesita igualmente de la presencia del programa rmt en la
máquina que maneja los dispositivos de copia de seguridad. Este programa está incluido en
la distribución fuente de dump para Linux.
3.6.2. tar
A diferencia de dump o restore, tar permite copia de seguridad de los archivos deseados, ex-
cluir ciertos repertorios, etc. Es necesario notar que el tar utilizado bajo Linux es el tar GNU.
Este posee ciertas opciones particulares.
Para conocer todas las opciones posibles, te aconsejo hacer tar --help. Una utilización
simple de tar puede ilustrarse con la copia de seguridad de una partición de usuarios:
La lista de archivos será así enviada al usuario backup-user. Ciertos sitios utilizan exclu-
sivamente tar para efectuar sus copia de seguridad, cada cual escoge lo mas apropiado.
Tabla de contenidos
4.1. La tabla de usuarios .......................................................................................40
4.2. La extension de la tabla de usuarios ................................................................40
4.3. La tabla de grupos .........................................................................................41
4.4. Procedimientos para la creación de grupos y usuarios ......................................42
4.5. Atributos de protección de los procesos ..........................................................43
4.6. Atributos de protección de los ficheros ...........................................................44
4.7. Las reglas de protección básicas .....................................................................45
4.8. Cambio de atributos de protección en ficheros .................................................46
4.9. Los bits SETUID y SETGID en ficheros ejecutables .......................................47
4.10. El bit SETGID en directorios .......................................................................47
4.11. La máscara de creación de ficheros ...............................................................47
4.12. La estrategia de los grupos privados .............................................................48
4.13. Sintaxis y funcionamiento de los mandatos Unix relacionados ........................48
4.1. La tabla de usuarios
usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:1002:2000:Usuario 1:/home/usu1:/bin/bash
Elemento Significado
usu1 Nombre de usuario ( login name)
Contraseña cifrada
$1$ZtoHwEykKW/eCLH zSUigg5KAEyxa51
Cada línea de este fichero se corresponde con una línea del fichero /etc/passwd y la
usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:10989:0:99999:7:-1:-1:134538436
Elemento Significado
usu1 Nombre de usuario ( login name)
Contraseña cifrada
$1$ZtoHwEykKW/eCLH zSUigg5KAEyxa51
Cuando el sistema emplea esta tabla, la contraseña que debería estar almacenada en el fi-
chero /etc/passwd se sustituye por una 'x'. Dado que el fichero /etc/passwd es legi-
ble por todos los usuarios mientras que /etc/shadow sólo es legible por el administrador,
mediante este cambio se consigue que ningún usuario tenga acceso a las contraseñas cifra-
das.
proy1::65534:usu1,usu2,usu3
Elemento Significado
proy1 Nombre del grupo
Contraseña cifrada (vacía en el ejemplo). De co-
nocerla, un usuario podría cambiar su grupo pri-
mario. Sin embargo, esta funcionalidad está en de-
suso
65534 Identificador del grupo (GID)
Lista de usuarios que pertenecen a este grupo
usu1,usu2,usu3
(separados por comas)
Como se deduce del ejemplo, un usuario puede figurar en la lista de distintos grupos, es
decir, puede pertenecer a varios grupos. De todos esos grupos, aquél cuyo GID figura en la
entrada correspondiente al usuario en el fichero /etc/passwd se considera el grupo pri-
mario de dicho usuario. El resto de grupos se denominan grupos suplementarios.
Al igual que sucede con los usuarios, existen ciertos grupos que son especiales, en con-
creto aquellos cuyo GID es menor que 500. De forma análoga a los usuarios especiales, re-
presentan servicios, usuarios anónimos, etc. No deben, por tanto, ser modificados.
Mandato Uso
useradd Añadir un usuario
userdel Eliminar un usuario
usermod Modificar los atributos de un usuario
groupadd Añadir un grupo
groupdel Eliminar un grupo
groupmod Modificar los atributos de un grupo
passwd Cambiar la contraseña de un usuario
chage Gestionar la caducidad de la contraseña
Estos mandatos son especialmente útiles cuando la gestión de usuarios debe realizarse
desde \e{scripts} del \e{shell}, por ejemplo, cuando debe crearse una gran cantidad de usua-
rios de forma automática. La sintaxis y opciones más usuales de estos mandatos se citan en
el Sección 4.13, “Sintaxis y funcionamiento de los mandatos Unix relacionados” al final de
este capítulo.
Identificadores del En realidad, cada proceso contiene dos versiones del identificador
usuario propietario del de usuario, la denominada versión real (rUID) y la versión efectiva
proceso (eUID).
Identificadores del En este caso, el proceso también contiene una versión real (rGID) y
grupo propietario del otra efectiva (eGID) del identificador.
proceso
La versión real corresponde al grupo primario al que pertenece
el usuario que creó el proceso. La versión efectiva corresponde al
grupo bajo el cual se comporta el proceso y es el utilizado en el
mecanismo de protección. Ambos identificadores suelen ser igua-
les, salvo que intervenga el denominado bit SETGID en el fichero
ejecutable que está ejecutando el proceso, tal como se describe más
adelante en este documento (ver Sección 4.9, “Los bits SETUID y
SETGID en ficheros ejecutables ”).
Lista de grupos suple- Es la lista formada por los grupos suplementarios del usuario que
mentarios creó el proceso.
acredita al sistema mediante su nombre de usuario y contraseña asociada. Los atributos rUID
y rGID se extraen de la tabla de usuarios /etc/passwd. La lista de grupos suplementarios
es confeccionada a partir de la tabla de grupos /etc/group. Los atributos eUID y eGID
son asignados a los valores respectivos de rUID y rGID. Un mandato interesante al respecto
es id, el cual muestra todos estos atibutos.
Bits de permiso Un total de 12 bits que expresan las operaciones del fichero que
son permitidas en función del proceso que acceda a este fichero. La
Tabla 4.5, “Significado de los bits de permiso en Unix” a continua-
ción muestra el significado de cada uno de estos bits.
Bit Significado
11 SETUID
10 SETGID
9 Sticky
8 Lectura para el propietario.
7 Escritura para el propietario.
6 Ejecución para el propietario
5 Lectura para el grupo.
4 Escritura para el grupo.
3 Ejecución para el grupo.
2 Lectura para el resto de usuarios.
1 Escritura para el resto de usuarios.
0 Ejecución para el resto de usuarios.
El significado de los bits de lectura, escritura y ejecución es diferente en función del tipo
de archivo que los defina. Para ficheros regulares, su significado es el esperable (permiten
leer, modificar y ejecutar el fichero respectivamente). Evidentemente, el bit de ejecución só-
lo tiene sentido si el fichero es un ejecutable o contiene un shellscript.
Ejecución Permite la utilización del directorio al cual se aplica este bit para
formar parte de un nombre de ruta, es decir, puede utilizarse el di-
rectorio para nombrar un fichero.
• Si el eUID del proceso es igual al ownerUID del fichero, se autoriza la operación si es-
tá permitida en el grupo de bits 6 al 8, los que corresponden al propietario. Si no...
• Si el eGID del proceso o alguno de los grupos suplementarios del proceso es igual al
ownerGID del fichero, se autoriza la operación si está permitida en el grupo de bits 3 al
5, los que corresponden al grupo. Si no...
Debe notarse que sólo se aplica una regla, aquella que corresponde a la primera condición
que se cumple para los atributos del proceso. Es decir, el sistema determina primero qué gru-
po de tres bits debe aplicar y después autoriza (o deniega) la operación en función del tipo de
operación requerida y del estado de dichos tres bits.
a. Cambio en los bits de permiso. Un proceso puede cambiar los bits de permiso de un fi-
chero sólo si:
c. Cambio de grupo propietario. El cambio del grupo propietario de un fichero puede rea-
lizarse sólo si:
• lo realiza el propietario del fichero, siempre que el nuevo ownerGID del fichero
sea igual a alguno de los grupos de dicho usuario.
• Si el fichero ejecutable tiene el bit SETUID activo, el eUID del proceso que ejecuta el fi-
chero es hecho igual al ownerUID del fichero.
• Si el fichero ejecutable tiene el bit SETGID activo, el eGID del proceso que ejecuta el fi-
chero es hecho igual al ownerGID del fichero.
• si se crea un fichero dentro de D, el ownerGID del nuevo fichero es hecho igual al ow-
nerGID del directorio D.
ejecutable. Puede observarse, por tanto, que todos los permisos son activados.
Para modificar este funcionamiento, cada usuario puede especificar al sistema aquellos
bits que no desea que sean activados, mediante la máscara de creación de ficheros. La más-
cara se establece mediante el mandato umask. Cada bit activo en la máscara es un bit que se-
rá desactivado cuando se cree un fichero. Por ejemplo, una máscara 022 desactivaría los bits
de escritura para el grupo y el resto de usuarios.
El administrador debe velar porque exista una máscara de creación de ficheros razonable
por defecto para cualquier usuario. Esto puede conseguirse fácilmente utilizando el fichero /
etc/profile, el cual sirve para personalizar el entorno de los usuarios en el momento de
su conexión.
• Crear un grupo privado para cada usuario (utilizando para ello el mismo nombre del
usuario), y hacer que éste sea el grupo primario del usuario.
• Asignar como máscara por defecto para todos los usuarios 00X, es decir, todos los per-
misos activos para el propietario y para el grupo y lo que se considere oportuno para el
resto de usuarios.
---------------------------------------------------------------------------
useradd [-u uid [-o]] [-g group] [-G group,...]
[-d home] [-s shell] [-c comment] [-m [-k template]]
[-f inactive] [-e expire mm/dd/yy] [-p passwd] [-n] [-r] name
useradd -D [-g group] [-b base] [-s shell] [-f inactive]
[-e expire mm/dd/yy]
userdel
---------------------------------------------------------------------------
userdel [-r] name
usermod
---------------------------------------------------------------------------
usermod [-u uid [-o]] [-g group] [-G group,...]
[-d home [-m]] [-s shell] [-c comment] [-l new_name]
[-f inactive] [-e expire mm/dd/yy] [-p passwd] [-L|-U] name
groupadd
---------------------------------------------------------------------------
groupadd [-g gid [-o]] [-r] group
groupmod
---------------------------------------------------------------------------
groupmod [-g gid [-o]] [-n name] group
groupdel
---------------------------------------------------------------------------
groupdel group
passwd
---------------------------------------------------------------------------
passwd [-l] [-u [-f]] [-d] [-S] [ username ]
chage
---------------------------------------------------------------------------
chage [ -l ] [ -m min_days ] [ -M max_days ] [ -W warn ]
[ -I inactive ] [ -E expire ] [ -d last_day ] user
-d
Asigna la fecha del último cambio de contraseña
-E
Asigna la fecha en la cual la cuenta de usuario será desactivada
-l
Muestra la información de caducidad
-I
Número de días tras los cuales la cuenta será desactivada si no
se realiza el cambio de contraseña exigido
-m Número de días mínimo permitido entre cambios de contraseña
-M Número de días máximo permitido entre cambios de contraseña
-W Número de días previos al próximo cambio de contraseña exigido
---------------------------------------------------------------------------
chown
---------------------------------------------------------------------------
chwon [ -R ] owner file
chgrp
---------------------------------------------------------------------------
chgrp [ -R ] group file
chmod
---------------------------------------------------------------------------
chmod -R MODE[,MODE]... FILE...
MODE indica como deben modificarse los bits de permiso. Su sintaxis es:
[ugoa][+-=][rwxXstugo]
[rwxXstugo] r lectura
w escritura
x ejecución
X ejecución si activo para el propietario
s SETUID o SETGID
t sticky
u igual al propietario
g igual al grupo
o igual a otros
---------------------------------------------------------------------------
Tabla de contenidos
5.1. Introducción .................................................................................................54
5.2. Configuración de un servidor nfs ....................................................................55
5.2.1. El archivo /etc/exports ................................................................55
5.2.2. Arranque y parada del servidor NFS ............................................56
5.3. Configuración del cliente nfs .........................................................................57
5.1. Introducción
5.1. Introducción
NFS (Network File System) permite acceder a ficheros y directorios remotos de la misma
forma que se accedería a ficheros locales. NFS utiliza al igual que NIS, RPC. En Linux esto
es posible, gracias a una mezcla de funcionalidad del Kernel en el cliente y un demonio ser-
vidor de NFS en el servidor.
El comando mount intenta conectar con el demonio mountd en el host remoto via RPC.
El servidor chequeará si el cliente tiene permitida la operación, y si es así le devolverá un
manejador de fichero.
Cuando alguien accede a un fichero a través de NFS, el kernel coloca un allamada RPC
en el demonio nfsd en la máquina servidora. Esta llamada toma el manejador de fichero, el
nombre de fichero a ser accedido, y el uid y el gid del usuario como parámetros, que se utili-
zan para determinar los derechos de acceso.
El NFS de Linux es un poco diferente ya que el código del cliente está integrado en el ni-
vel del Sistema de Ficheros Virtual (VFS) del kernel y no requiere control adicional a través
de un demonio biod.
Actualmente existen dos implementaciones del servidor NFS bajo Linux. Una es el servi-
dor NFS en el espacio del usuario y otra el servidor NFS en el espacio del Kernel.La del es-
pacio del usuario tiene que copiar memoria extra entre el espacio del kernel y el espacio del
usuario y además es una sobrecarga para el cambio de contexto. No se permiten bloqueos a
nivel de registro ni de fichero. Mientras que el servidor NFS en el espacio del kernel no tiene
que mover memoria entre los dos espacios ya que se ejecuta en el espacio del kernel y realiza
las llamadas RPC dentro del kernel. Si que permite bloqueo de regisros y ficheros lo cual es
importante cuando tienes un entorno heterogéneo, y además permite lanzar varias del demo-
nio servidor.
RedHat Linux implementa por defecto el servidor NFS en el espacio del Kernel.
Para proporcionar servicios NFS se deben ejecutar los demonios rpc.mountd y rpc.nfsd.
Como son programas basados en RPC, por tanto no son manejados por inetd ( el internet
daemon ), tienen que lanzarse en tiempo de boot y registrarse con el portmap ( como ocurría
con los servicios de NIS ), el cual deberá ejecutarse anteriormente.
El paquete necesario en RedHat Linux para convertir un sistema en un servidor nfs es nfs-
utils que se corresponde con el servidor NFS en el espacio del kernel.
como se observa, primero se define el sistema de ficheros a exportar, seguido de las má-
quinas que van a tener acceso, y al final se define el tipo de acceso ( de solo lectura, lectura y
escritura etc ... )
Entre las opciones que se pueden utilizar a la hora de exportar un directorio podemos en-
contrar las siguientes:
• MAPIDENTITY: esta opción le indica al servidor que asuma que el cliente utiliza los
mismos UID's y GID's que el servidor. Esta opción es por defecto.
/home mis*.dsic.upv.es(rw)
/cdrom mis*.dsic.upv.es(ro)
Donde estamos compartiendo el directorio /home del servidor para que sea accesible des-
de todos los clientes y en conjunción con las páginas amarillas,, los usuarios puedan tener el
mismo entorno en cualquier máquina que entren. Por defecto al usuario root de cada máqui-
na no se le permitirá tener privilegios de superusuario sobre el directorio /home del servidor.
Para que el servidor NFS tenga en cuanta estos cambios, habría que relanzar los demonios
mountd y nfsd, pero existe una utilidad llamada exportfs que realiza este trabajo por noso-
tros.
cuando recibe una petición de montaje de un cliente NFS chequea el fichero /etc/exports para
comprobar si este está autorizado, devolviendo un manejador de fichero al cliente y rpc.nfsd
vistos anteriormente y ademas se lanza otro servicio denominado rpc.rquotad que es un ser-
vidor RPC que devuelve la cuota de un usuario de un sistema de ficheros local que está mon-
tado a través de NFS.
Solo quedaría añadir el script a los diferentes niveles de ejecución donde queremos que se
arranque o pare, utilizando linuxconf o el comando chkconfig.
La forma de que un cliente tiene de utilizar un sistema de ficheros exportado por un servi-
dor NFS, es con el comando mount. Es decir los volúmenes NFS se montan de la misma for-
ma que el resto de sistemas de ficheros:
Entre las opciones que se le pueden pasar al comando mount se encuentran las siguientes:
• RSIZE=n , WSIZE=n Especifican el tamaño del datagrama utilizado por los clientes NFS
cuando realizan peticiones de Lectura/Escritura.
• TIMEO=n Establece el tiempo en segundos que un cliente NFS esperará a que se com-
plete una petición. El valor por defecto es 7.
• HARD Esta opción se refiere al tipo de montaje. En esta ocasión un montaje duro provo-
ca que el programa que está accediendo a un fichero montado por NFS se colgará cuando
el servidor falle. El proceso no puede ser interrumpido a menos que se indique la opción
INTR. Cuando el servidor esté disponible, el programa continuará como si nada.
• SOFT Esta opción permite al kernel obtener un timeout si el servidor NFS no responde
durante algún tiempo. El tiempo puede ser especificado con la opción timeo.
• INTR Colocar esta opción, permite a las señales de interrupción abortar el proceso cuan-
do el servidor no responde.
Pero no sería lógico que el administrador tuviera que montar el directorio exportado por
un servidor NFS, cada vez que un usuario lo necesite ( ya que el comando mount solo se
puede ejecutar con privilegios de superusuario. Debe de existir alguna manera de automati-
zar este proceso y que el sistema se encargue de montarlo en el arranque.
No existe ningún script que se pueda lanzar en determinado nivel de ejecución que alcan-
ce la máquina cada vez que arranque. Lo que se hace es tratar al sistema de ficheros nfs, co-
mo si fuera un sistema de ficheros más y añadir una entrada en el fichero /etc/fstab que se
encarga de definir los sistemas de ficheros que se montaran en el arranque.
Tabla de contenidos
6.1. Introducción .................................................................................................60
6.2. Funcionamiento ............................................................................................60
6.3. Configuración de NIS ....................................................................................61
6.3.1. Configuración de un cliente NIS ..................................................62
6.3.2. El fichero /etc/nsswitch.conf .......................................................62
6.3.3. Configuración de un servidor NIS ................................................63
6.1. Introducción
6.1. Introducción
Cuando en una red existen varios sistema Linux que quieren acceder a recursos comunes,
hay que asegurar que la lista de usuarios y grupos esté disponible en todas las máquinas
clientes. La red debe de ser transparente para el usuario, da igual en la máquina que trabaje,
siempre debe de encontrar el mismo entorno. Para conseguir es objetivo utilizaremos el Ser-
vicio de Información de Red (NIS).
Las siguientes líneas están sacadas del Sun(tm) System and Network Administration Ma-
nual:
NIS viene de Network Information Service. Su propósito es proveer información, que tie-
ne que ser conocida a lo largo de la red, a todas las máquinas de la red. La información más
indicada para ser distribuida por NIS es:
Así que, por ejemplo, si la entrada de tu password está grabada en la base de datos
passwd de NIS, serás capaz de entrar en todas las máquinas de la red que tengan corriendo
los programas clientes NIS.
6.2. Funcionamiento
En una red debe haber al menos una máquina actuando como un servidor NIS. Puedes tener
múltiples servidores NIS, cada uno sirviendo a diferentes "dominios" NIS - o puedes tener
servidores NIS cooperativos, donde uno es el llamado servidor NIS maestro, y todos los de-
más son los llamados servidores NIS esclavos (para un "dominio" NIS determinado), o pue-
des tener una mezcla de ellos.
Los servidores esclavos solo tienen copias de las bases de datos NIS y reciben estas co-
pias del servidor NIS maestro cada vez que se realizan cambios a las bases de datos maes-
tras. Dependiendo del número de máquinas que haya en tu red y de la seriedad de tu red, po-
drías decidir si instalar uno o más servidores esclavos. Cada vez que un servidor NIS se cae
o va muy lento respondiendo peticiones, un cliente NIS conectado a ese servidor intentará
encontrar otro que no esté caído o que vaya más rápido.
Las bases de datos NIS están en el formato DBM, que deriva de las bases de datos ASCII.
Por ejemplo, los ficheros /etc/passwd y /etc/group pueden ser directamente convertidos a for-
mato DBM usando software de translación ASCII a DBM ("dbload", incluído con el softwa-
re del servidor). El servidor NIS maestro debería tener ambas, las bases de datos ASCII y las
DBM.
Los servidores esclavos serán notificados de cualquier cambio en los mapas NIS, (vía el
programa "yppush"), y recibirán automáticamente los cambios necesarios para sincronizar
sus bases de datos. Los clientes NIS no necesitan hacer esto ya que éstos siempre hablan di-
rectamente con el servidor NIS para leer la información almacenada en sus bases de datos
DBM.
Los clientes NIS para Linux son capaces de obtener el servidor a partir de un fichero de
configuración --lo que quiere decir que no es necesario un broadcast (lo cual es inseguro, de-
bido al hecho de que cualquiera podría instalar un servidor NIS y contestar a las peticiones
de broadcast...).
ypserv
yp-tools
ypbind
Normalmente los servidores RPC estándar son arrancados por xinetd, de modo que el ma-
peador de puertos (portmap) debe ser iniciado antes de que inetd sea invocado.
6. Comprobar que puedes acceder a los mapas que sirve el servidor NIS: ypcat passwd Es-
to debería devolver el mapa passwd del servidor.
Si todo ha funcionado correctamente, deberías automatizar este proceso para que se reali-
zara cada vez que arranque el cliente. En RedHat Linux existe un script llamado /
etc/rc.d/init.d/ypbind que acepta {star|stop} para lanzar o parar el servicio. El dominio de
NIS se define añadiendo la variable NISDOMAIN al fichero de configuración /
etc/sysconfig/network.
especifica que las funciones de búsqueda de host deben primero mirar en el fichero /
etc/hosts local, seguido de una búsqueda NIS y, finalmente, usar el DNS (/etc/resolv.conf y
named). Si al llegar a este punto no se encuentra el host correspondiente se devuelve un
error.
Existen dos tipos de servidores NIS: maestros y esclavos. El primero será el servidor
principal donde se generarán los mapas que tenemos que servir, mientras que un servidor es-
clavo mantendrá una copia de los mapas por si no estuviera disponible en algún momento el
servidor maestro.
Habrá que editar el fichero /etc/ypserv.conf que nos permitirá configurar algunas opcio-
nes para el sevidor ypserv. Normalmnete contiene una lista de reglas para hosts especiales y
reglas de acceso a los mapas. El fichero /var/yp/securenets define los derechos de acceso al
servidor NIS por parte de los clientes. El fichero contiene pares netmask/network de forma
que si la dirección IP del cliente se corresponde con la entrada podrá actuar como cliente de
NIS.
Hay que asegurarse que el portmap está corriendo ( rpcinfo -p localhost ) y entonces y so-
lo entonces lanzar el demonio ypserv. El siguiente paso sería generar las bases de datos
(mapas) de NIS. En el servidor maestro habrá que ejecutar lo siguiente:
[root@mis01]# /usr/lib/yp/ypinit -m
De esta forma se definirán los servidores esclavos y los mapas que sirve el servidor de
NIS. Si se necesita actualizar un mapa, se tiene que ejecutar make en directorio /var/yp del
servidor maestro de NIS. Esta acción actualizará el mapa si el fichero fuente es mas nuevo, y
colocará los ficheros en los servidores esclavos.
En el servidor esclavo ( puede haber más de uno ) se tendrán que realizar los siguientes
pasos. Asegurarse que el portmap está corriendo, ejecutar el demonio ypserv, y entonces lla-
mar al siguiente comando:
Habrá que asegurarse de que el nuevo servidor esclavo tiene una entrada en el fichero de
configuración /etc/ypservers del servidor maestro.
También sería una buena idea editar el fichero crontab de root del servidor esclavo y aña-
dir las sigueintes lineas:
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
Esto asegurará que la mayoría de los mapas NIS estén actualizados, incluso si una actuali-
zación se perdió debido a que el servidor esclavo estaba fuera de servicio en el momento en
que el servidor maestro actualizó los mapas.
Si quisiéramos restringir el acceso de los usuarios a nuestro servidor NIS, tendríamos que
configurarlo también como un cliente NIS y añadir las entradas necesarias en el /etc/passwd.
El último paso sería automatizar el proceso de poner en marcha el servidor NIS cada vez
que arranque la máquina. En RedHat Linux existe el script /etc//init.d/ypserv que acepta los
parámetros {start|stop} para lanzar o parar el servicio. Colcándolo en los niveles de ejecu-
ción apropiados tendremos listo este proceso.
Habría que considerar que con este método de autentificación en red, si los usuarios qui-
sieran cambiarse sus passwords, el comando normalmente utilizado passwd no cumplirá su
función ya que debería actualizar los mapas NIS del servidor pertinentes. Para ello en el ser-
vidor NIS debe estar corriendo el demonio rpc.yppasswdd, el cual maneja los cambios de
passwords y asegura que la información de los mapas de NIS se actualiza correctamente. En
los clientes deberíamos utilizar el comando yppasswd en vez de passwd.
Tabla de contenidos
7.1. Introducción .................................................................................................66
7.2. El código binario del núcleo ...........................................................................67
7.3. El código fuente del núcleo ............................................................................68
7.4. Compilación e instalación de un nuevo núcleo ................................................69
7.1. Introducción
7.1. Introducción
El núcleo de un sistema operativo es el programa que gobierna el hardware del ordenador y
ofrece una interfaz de servicios al resto de programas (procesos) que se ejecutan en dicho or-
denador. Normalmente, el núcleo es el primer código que se carga en memoria cuando en-
cendemos el ordenador y permanece en dicha memoria mientras el sistema está en funciona-
miento, entrando en ejecución cada vez que un proceso requiere uno de sus servicios o un
dispositivo físico requiere su atención. Una de las diferencias fundamentales entre el núcleo
del sistema y los procesos que se ejecutan "por encima" del mismo es que uno y otros se eje-
cutan en modos de procesador distintos (siempre que el hardware del ordenador soporte esta
característica). El núcleo suele ejecutarse en alguno de los modos privilegiados del procesa-
dor, en el que tiene completo acceso a todo el hardware (incluyendo la programación de los
dispositivos), mientras que los procesos se ejecutan en "modo usuario", en el que no pueden
ejecutar un buen número de de instrucciones máquina del procesador. De esta forma, el nú-
cleo se convierte en una especie de intermediario obligado en la mayoría de las acciones que
los procesos ejecutan, lo que le permite implementar de forma adecuada la multitarea, repar-
tiendo de forma equitativa y segura los recursos del sistema entre los diferentes procesos que
se ejecutan en cada momento.
En el caso concreto de Linux, el tema del núcleo puede inducir a error, dado que se suele
denominar Linux al sistema operativo completo (incluyendo todos los programas y utilidades
que podemos ejecutar cuando instalamos el sistema) además de al núcleo en sí mismo. En
otros sistemas operativos comerciales (como por ejemplo Windows 2000 o Solaris) esta dis-
tinción no es necesaria, puesto que ambos (el núcleo y dicho conjunto de utilidades y progra-
mas que se distribuyen junto con él) provienen de la misma empresa (en el ejemplo, Micro-
soft y SUN Microsystems, respectivamente) y se distribuyen conjuntamente. Sin embargo,
en el caso de Linux esto no es así. El núcleo propiamente dicho es desarrollado por un grupo
de personas (lideradas por el creador de Linux, Linus Torvalds) de forma independiente del
resto de utilidades, herramientas y aplicaciones que tenemos disponibles cuando instalamos
Linux. A este conjunto de utilidades (más un núcleo concreto) se lo conoce como una distri-
bución de Linux, y existen numerosas empresas, organizaciones e incluso individuos que
mantienen distintas distribuciones: Red Hat, Fedora, Debian, SuSe, Mandrake, Caldera, Gen-
to, etc. Puesto que el núcleo se distribuye líbremente como código GPL, en realidad cual-
quiera de dichas organizaciones puede realizar modificaciones en el núcleo (y algunas lo ha-
cen), pero Linus y su equipo siguen manteniendo el control sobre el núcleo reconocido.
De esta manera, las distribuciones y los núcleos tienen versiones distintas e independien-
tes. Por ejemplo, en estos momentos la versión actual de Fedora Linux se denomina "Core
1", y el núcleo que instala por defecto es el 2.4.22. La nomenclatura de la versión del núcleo
es significativa del estado del mismo: el segundo número indica si la versión es estable
(número par) o de desarrollo (número impar), mientras que el último dígito indica un número
de orden (creciente) de la versión. Un número mayor indica un núcleo más reciente y
(probablemente) con mayor y mejor soporte.
te con los procesos), que internamente interactúan con el núcleo. Sin embargo, existen situa-
ciones en las que necesitamos modificar el soporte ofrecido por el núcleo, para conseguir
mejores prestaciones, un sistema más seguro o mejor adaptado a un uso concreto, o simple-
mente para poder acceder a un nuevo tipo de dispositivo físico. Este capítulo explica los pa-
sos necesarios para poder modificar el soporte del núcleo de Linux.
En realidad, el código binario del núcleo puede dividirse entre diferentes ficheros: el fi-
chero binario principal vmlinuz mencionado arriba (que es absolutamente necesario) y, op-
cionalmente, un conjunto de ficheros denominados módulos de núcleo (kernel modules). Los
módulos de núcleo son ficheros objeto (compilados de forma especial) que incorporan fun-
cionalidades concretas que pueden ser instaladas y desinstaladas del núcleo de Linux sin te-
ner que generar un nuevo ejecutable vmlinuz e incluso sin tener que reiniciar el ordenador.
Normalmente, la misma funcionalidad puede ser incorporada al núcleo (en fase de compila-
ción) como parte del binario principal o como un módulo de núcleo.
De hecho, el soporte de módulos está tan bien integrado en el sistema que también resulta
transparente para los usuarios en la mayoría de ocasiones. Por ejemplo, si montamos por pri-
mera vez una partición de tipo FAT32 en un sistema en el que dicho sistema de archivos está
soportado por módulos de núcleo, Linux cargará automáticamente dichos módulos y luego
montará la partición en el directorio correspondiente, sin ninguna intervención al respecto
del usuario (ni del administrador).
Hoy en día, distribuciones como Fedora incorporan un núcleo con un soporte razonable
en el binario principal y un número muy elevado de módulos de núcleo que cubren buena
parte del soporte extra que podemos necesitar en el sistema. Sin embargo, existen ocasiones
en las que necesitamos conseguir un soporte distinto. A continuación se enumeran algunas
de ellas:
• Núcleo más pequeño. Algunos sistemas necesitan ejecutarse con poca memoria principal.
Puesto que el binario principal del núcleo nunca se desaloja de memoria, en ocasiones
necesitamos eliminar de dicho binario código que nuestro sistema no necesita y así con-
seguir más memoria para los procesos de usuario.
• Núcleo más seguro. Otra razón para eliminar código del núcleo que no necesitamos es in-
crementar su robustez y seguridad. Mantener más código (que no se usa) eleva la proba-
bilidad de que nuestro sistema presente vulnerabilidades ante ataques que comprometan
la seguridad del mismo.
• Núcleo más portable. El caso contrario al anterior es conseguir un núcleo que funcione
correctamente en el mayor número posible de ordenadores. Esto se consigue mediante un
binario principal mínimo y el máximo número posible de módulos de núcleo.
Puesto que la mayoría de distribuciones incorporan los binarios de varios núcleos como
ficheros preparados para instalar (por ejemplo, en formato rpm en el caso de Fedora), si sólo
queremos obtener un núcleo más moderno para nuestra instalación de Linux lo más sencillo
es obtener el último de dichos paquetes e instalarlo en el sistema.
Sin embargo, si desamos tener un núcleo para el que aún no hay versión binaria instala-
ble, o simplemente deseamos cambiar el tipo de soporte del núcleo que tenemos actualmente
instalado, necesitamos obtener el código fuente de dicho núcleo y recompilarlo.
Es posible que la distribución que estamos utilizando posea también como paquetes insta-
lables los fuentes de varios núcleos (normalmente sólo de versiones estables). Si nos interesa
uno de dichos núcleos, tendremos que obtener e instalar el paquete correspondiente, lo que
normalmente instalará el código fuente bajo el directorio /usr/src/, en un directorio de-
nominado linux-(versión)/ (por ejemplo, /usr/src/linux-2.4.22-1).
Por el contrario, si el núcleo que buscamos no lo tenemos disponible como paquete insta-
lable en nuestra distribución, tendremos que acudir a los lugares de internet que mantienen
en línea los distintos núcleos disponibles de Linux, como por ejemplo The Linux kernel ar-
chives [http://www.kernel.org].
Si optamos por esta última opción, tenemos que considerar que el código fuente se distri-
buye normalmente en dos formatos distintos: como un fichero en formato tar comprimido
que contiene todos los ficheros fuentes del núcleo, o bien como un "parche" que contiene só-
lo las diferencias respecto a otra versión anterior. Si no se es un usuario experto en aplicar
parches a código fuente (se realiza mediante la orden patch) se recomienda la primera op-
ción, porque aunque lógicamente el fichero a descargarse es mucho mayor, su instalación re-
sulta mucho más sencilla. Una vez descargado el fichero, se descomprime en un directorio
(/usr/src/ es una opción razonable) y ya estamos en condiciones de comenzar la compi-
lación del nuevo núcleo.
obtenemos una ventana que ejecuta un script escrito en Tcl/Tk que visualiza un me-
nú como el que aparece en la Figura 7.1, “El menú principal de configuración del nú-
cleo.”
Como vemos, la ventana muestra multitud de botones, que ocultan a su vez menús
de configuración organizados temáticamente. Al pulsar cada botón nos aparece el menú
correspondiente, en donde configuraremos el soporte que deseamos para nuestro nuevo
núcleo. La Figura 7.2, “Uno de los submenús de configuración del núcleo.” muestra,
como ejemplo, el menú de configuración del tipo de procesador para el que se compila-
rá el núcleo y sus características principales.
En esta figura aparecen buena parte de las alternativas de configuración que pode-
mos encontrarnos en todos los submenús: las opciones que aparecen en gris están habi-
litadas, porque son incompatibles con otras que hemos escogido (posiblemente en otros
submenús). Las opciones que aparecen en negrita (opciones selecionables) pueden ser
de tres tipos fundamentalmente:
• Opciones "sí/módulo/no". En este tipo de opciones podemos elegir entre tres alter-
nativas: y, indicando que queremos incluir ese soporte en el binario principal del
nuevo núcleo; m, indicando que queremos el soporte pero como módulo de núcleo;
y finalmente n, indicando que no queremos ese soporte. Como vemos en la figura,
en algunas de las opciones no existe la posibilidad de compilarla como módulo.
El menú con dichos tipos aparece al pulsar el botón correspondiente del submenú.
• Valor numérico. Existen opciones que permiten introducir un valor numérico con-
creto, que luego se pasará a los ficheros fuente involucrados como una constante de
preproceso.
Cuando hemos acabado de configurar todas las opciones del núcleo que necesitamos
para nuestro nuevo núcleo, hemos de pulsar el botón de salvar los cambios (botón "Sa-
ve and Exit" en la Figura 7.1, “El menú principal de configuración del núcleo.”) y
salir de la herramienta de configuración.
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 20
EXTRAVERSION = -20.9custom
Por ejemplo, con esta información se generaría un núcleo cuya versión sería
2.4.20-20.9custom. En el caso de que coincidiera con un núcleo actualmente ins-
talado y que no queremos sobreescribir, deberíamos modificar sólo el campo EXTRA-
VERSION. De hecho, el Makefile ya nos propone un sufijo denominado "custom"
que no se encuentra en ningún núcleo "oficial".
4. Compilar el núcleo. Para compilar el binario principal y los módulos del núcleo hay que
ejecutar las siguientes órdenes:
5. Instalar el núcleo. Los ficheros binarios del nuevo núcleo (binario principal y módulos)
residen todavía en ciertos subdirectorios de /usr/src/linux/ y no en los lugares
definitivos donde el sistema podrá encontrarlos. Para llevar a cabo esta acción hay que
ejecutar:
config-2.4.20-20.9
initrd-2.4.20-20.9.img
module-info-2.4.20-20.9
System.map-2.4.20-20.9
vmlinux-2.4.20-20.9
vmlinuz-2.4.20-20.9
module-info -> module-info-2.4.20-20.9
vmlinuz -> vmlinuz-2.4.20-20.9
System.map -> System.map-2.4.20-20.9
6. Reiniciar. Para que el núcleo nuevo sea cargado y ejecutado debemos reiniciar el siste-
ma y asegurarnos de que en la lista de arranque de lilo o grub elegimos este núcleo y no
el antiguo. En el caso de que algo salga mal (el núcleo no arranca, ciertos servicios no
funcionan, etc.), deberemos reiniciar el sistema con el núcleo antiguo y probablemente
volver al punto 2 para revisar la combinación de opciones con las que hemos configura-
do el nuevo núcleo.
7. Eliminar los ficheros objeto. Una vez el núcleo nuevo funciona correctamente y posee
todas las funcionalidades que queríamos de él, podemos eliminar los objetos del direc-
torio /usr/src/linux/, puesto que no los necesitamos más. Para ello ejecutaremos
lo siguiente:
La diferencia entre esta orden y la del punto 1 es que en este caso no se borran los fi-
cheros de configuración del núcleo, con lo que si volvemos a ejecutar make xconfig
tendremos en pantalla las mismas opciones con las que compilamos el núcleo la última
vez.
para poder recuperarla más tarde. Esto se realiza mediante los botones "Store Con-
figuration to File" y "Load Configuration from File" de la ventana
principal de configuración (ver Figura 7.1, “El menú principal de configuración del nú-
cleo.”). Si elegimos esta opción (guardarnos el fichero de configuración) podemos in-
cluso borrar el directorio completo de los fuentes, puesto que siempre podremos volver
a obtenerlo más tarde si es necesario.
Tabla de contenidos
8.1. Introducción .................................................................................................76
8.2. El sistema de archivos /proc ...........................................................................77
8.3. Obtener información del núcleo .....................................................................78
8.4. Modificar información del núcleo ...................................................................83
8.4.1. El directorio /proc/sys .........................................................................83
8.4.2. El mandato sysctl ...............................................................................85
8.1. Introducción
8.1. Introducción
En la mayoría de sistemas operativos suele ser habitual disponer de herramientas que permi-
ten conocer el estado interno del núcleo desde nivel de usuario. Normalmente, existen dife-
rentes herramientas para cubrir distintos aspectos de dicho estado (procesos e hilos, memo-
ria, ficheros, interrupciones y dispositivos, etc.) y, en función del sistema operativo, la infor-
mación que puede obtenerse es más o menos completa. Cualquier distribución de Linux in-
corpora herramientas de este tipo, tales como:
• ps. Visualiza los procesos en memoria el momento actual. En función de los modificado-
res, puede mostrar sólo los procesos lanzados en el shell actual o todos los procesos del
sistema y, para cada uno, más o menos información. Para mostrar el máximo de informa-
ción, puede utilizarse: "ps aux"
• mount. Invocado sin argumentos, muestra una lista de las particiones (locales o remotas)
montadas actualmente en el sistema.
• free. Muestra información acerca de la memoria ocupada y libre del sistema, tanto la físi-
ca como la virtual (ubicada en las particiones "swap").
• uptime. Muestra cuánto tiempo ha estado funcionando el sistema (desde el último reini-
cio), así como el número de usuarios conectados actualmente y la carga media del proce-
sador en los últimos 1, 5 y 15 minutos.
A diferencia de muchos de esos sistemas operativos, Linux incorpora además una forma
totalmente distinta de conocer, e incluso modificar, el estado interno del núcleo y de los pro-
cesos de usuario, mediante una interfaz de sistema de archivos denominado "proc". Este ca-
pítulo comenta las características fundamentales de este "sistema de archivos" y cómo pode-
mos utilizarlo para interrogar el estado (y modificar el comportamiento) del núcleo de Linux
en cualquier momento.
Sin embargo, este contenido no se encuentra guardado en ningún dispositivo físico (disco,
disquete, cd, etc.), sino que es construido y presentado dinámicamente cada vez que le pedi-
mos al núcleo que lo muestre, y lo mismo ocurre cuando visualizamos el contenido de sus ar-
chivos y subdirectorios. Este tipo de sistema de archivos se denomina sistema de archivos
virtual. Si listamos de nuevo este directorio en otro momento, o en otro sistema, es posible
que el listado no coincida exactamente con el del ejemplo, aunque algunos ficheros siempre
serán listados; de igual forma, es posible que el contenido de los archivos y directorios tam-
bién difiera. Ello es debido a que el contenido del directorio refleja el estado actual del nú-
cleo de Linux, y evidentemente este estado varía con el tiempo y de un sistema a otro (por
ejemplo, por disponer de hardware distinto).
Más formalmente, podemos definir /proc/ como una interfaz entre el núcleo de Linux
y el nivel de usuario con la forma de un sistema de archivos virtual. Así, el núcleo de Linux
presenta una manera única y homogénea de presentar su información interna y se convierte
en la alternativa a utilizar múltiples herramientas particulares como las que citábamos en el
apartado anterior. La ventaja principal es que, aunque Linux incorpora muchas de ellas (en
algunos casos, por compatibilidad con otras versiones de UNIX), no es imprescindible dispo-
ner de una herramienta por cada información que el núcleo pone a disposición del usuario,
puesto que toda esa información está en /proc. Esto es especialmente útil en el caso de Li-
nux, puesto que como veíamos en el Capítulo 7, El núcleo de Linux, el desarrollo del núcleo
es independiente del desarrollo de las herramientas y programas que se ejecutan por encima
(lo que se denomina "distribución").
Por ejemplo, veamos la información del mandato mount, seguida de la consulta del fi-
chero correspondiente de /proc/:
Los dos siguientes apartados enseñan, respectivamente, cómo obtener y modificar la in-
formación del núcleo de Linux interactuando con el sistema de archivos /proc/.
Esta sección presenta un repaso de los archivos y directorios más relevantes, junto con
instrucciones para interpretar su contenido. Para una descripción más exhaustiva, se reco-
mienda documentación especializada como la "Reference Guide" de Red Hat 9 que mencio-
nábamos en el apartado anterior, o la propia página de manual de "proc" (man proc).
1. /proc/cmdline. Muestra los parámetros con los que se inició el núcleo en tiempo
de arranque. Por ejemplo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 498.858
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips : 996.14
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext2
nodev ramfs
iso9660
nodev devpts
nodev usbdevfs
nodev usbfs
nodev autofs
nodev binfmt_misc
vfat
La primera columna indica si actualmente existe alguna partición montada con dicho
sistema de archivos (vacío) o no (nodev). La segunda columna indica el tipo de siste-
ma de archivos. Si el núcleo soporta otros sistemas de archivos como módulos que aún
no se han cargado, estos no aparecen en la lista (hasta que son cargados, obviamente).
Las dos primeras líneas muestran un resumen del estado de la memoria RAM y de la
memoria de intercambio (o swap), con cantidades expresadas en bytes. El resto de lí-
neas muestran la misma información de manera más detallada y expresada en Kbytes.
Los campos más relevantes son MemTotal (memoria física total), MemFree
(memoria física no utilizada actualmente), SwapTotal (total de memoria de intercam-
bio) y SwapFree (cantidad de memoria de intercambio no utilizada actualmente).
3131.40 2835.67
En cuanto a los subdirectorios más relevantes de /proc/, podríamos destacar los si-
guientes:
• exe. Enlace simbólico que apunta al fichero ejecutable (normalmente binario) del
proceso.
• fd/. Directorio que contiene enlaces simbólicos a los descriptores de fichero abier-
tos por el proceso actualmente.
• maps. Contiene información acerca de los mapas de memoria (virtual) ocupada por
el proceso, incluyendo información sobre la ubicación de sus ejecutables y bibliote-
cas.
• stat, statm, y status. Estos archivos contienen diferentes imágenes del estado
actual del proceso, incluyendo estado de la memoria, información de protección,
etc.
3. /proc/fs/. Contiene información sobre los directorios que actualmente se están ex-
portando (sólo tiene información si el sistema es un servidor NFS).
4. /proc/ide/. Contiene información sobre los discos duros IDE que están conectados
en el sistema, incluyendo datos de los manejadores, opciones de configuración y esta-
dísticas de uso.
7. /proc/sys/. Este subdirectorio es especial y distinto del resto de directorios que he-
mos visto hasta ahora, puesto que no sólo permite leer informacion actual del núcleo, si-
no que permite modificarla en algunos casos. Esto se explica con más detalle en la si-
guiente sección.
La orden sysctl se utiliza para leer y modificar claves que, como vemos, coinciden con las
rutas de los archivos correspondientes dentro del directorio /proc/sys/. Para un listado
completo de las claves que podemos modificar, podemos teclear sysctl -a.
Este documento puede ser copiado y distribuido en cualquier medio con o sin fines co-
merciales, siempre que la licencia GNU Free Documentation License (FDL)
[http://www.gnu.org/copyleft/fdl.html], las notas de copyright y esta nota legal diciendo que
la GNU FDL se aplica al documento se reproduzcan en todas las copias y que no se añada
ninguna otra condición a las de la GNU FDL.