Differences between revisions 1 and 2
Revision 1 as of 2006-05-30 03:25:19
Size: 17511
Editor: ?RamónRamos
Comment:
Revision 2 as of 2009-03-16 03:29:48
Size: 17511
Editor: anonymous
Comment: converted to 1.6 markup
No differences found!
  • Capítulo 9 - El sistema operativo

9.1 Jerarquía del sistema de archivos

9.1.1 Estructura del sistema de archivos

La localización de todos los archivos y directorios instalados debe cumplir con el Estándar de Jerarquía del Sistema de Archivos (FHS), versión 2.1, a menos que hacerlo así viole otros términos de las políticas Debian. La versión de ese documento aquí referida se puede encontrar en el paquete debian-policy o en FHS, (copia Debian) junto con este manual (o, si tiene instalado el paquete debian-policy, puede intentar FHS, (copia local)). La última versión, que puede ser más reciente, se puede encontrar en FHS (original). Pueden hacerse preguntas específicas sobre el cumplimiento del estándar en la lista de correo debian-devel, o pueden referirse a la lista de correo del FHS (ver el sitio de FHS para mayor información).

9.1.2 Programas específicos del sitio

Como indica el FHS, los paquetes no deben colocar ningún archivo en /usr/local, sea poniéndolos en el repositorio de archivos a ser desempacado por dpkg o manipulándolos en los libretos del encargado.

Sin embargo, el paquete puede crear directorios vacíos bajo /usr/local de forma que el administrador del sistema sepa dónde colocar archivos específicos del sitio. Estos directorios deberían ser removidos al remover el paquete, si están vacíos.

Note que esto se aplica solamente a los directorios bajo /usr/local, no en el propio /usr/local, excepto aquellos listados en FHS, sección 4.5. Sin embargo, puede crear directorios por debajo como desee. No debe remover ninguno de los directorios listados en 4.5, aún si Ud. los creó.

Ya que /usr/local puede ser montado para sólo-lectura (read-only) desde un servidor remoto estos directorios deben ser creados y removidos por los libretos del encargado postinst y prerm y no deben ser incluidos en el archivo .deb. Estos libretos no deben fallar si alguna de estas operaciones falla.

Por ejemplo, el paquete emacsen-common podría contener algo como esto en el libreto postinst

  • if [ ! -e /usr/local/share/emacs ] then
    • if mkdir /usr/local/share/emacs 2>/dev/null then

      • chown root:staff /usr/local/share/emacs chmod 2775 /usr/local/share/emacs
      fi
    fi

y algo como esto en el libreto prerm (Note que esta forma se utiliza para asegurar que si el libreto se interrumpe, el directorio /usr/local/share/emacs sería removido igualmente).

  • rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true rmdir /usr/local/share/emacs 2>/dev/null || true

Si Ud. crea un directorio en /usr/local para las adiciones locales a un paquete, debería asegurar que los parámetros establecidos en /usr/local tienen precedencia sobre los equivalentes en /usr.

No obstante, ya que /usr/local y sus contenidos son para el uso exclusivo del administrador local, un paquete no debe confiar en la presencia o ausencia de archivos o directorios en /usr/local para su normal operación.

El directorio /usr/local mismo y todos los subdirectorios creados por el paquete deberían (por omisión) tener permisos 2775 (escribibles por el grupo y con identidad de grupo establecida) y pertenecer a root.staff.

9.1.3 El directorio de correo global

El directorio de correo global es /var/mail. Este directorio es parte del sistema base y no debería pertenecer a ningún agente de correo en particular. Se desaprueba el uso de la vieja localización /var/spool/mail, incluso aunque el almacén temporal (spool) pueda estar físicamente localizado allí. Para mantener compatibilidad parcial en la actualización de sistemas que tengan /var/spool/mail como su almacén temporal (spool) de correo, los paquetes que utilizan /var/mail deben depender de libc6 (>= 2.1.3-13), o de base-files (>= 2.2.0), o de versiones posteriores de cualquiera de estos paquetes.

9.2 Usuarios y grupos

9.2.1 Introducción

El sistema Debian puede ser configurado para utilizar contraseñas 'planas' o 'sombra'.

Algunas identidades de usuario (UIDs) e identidades de grupo (GIDs) están reservadas globalmente para su uso por ciertos paquetes. Ya que algunos paquetes necesitan incluir archivos que pertenecen a estos usuarios o grupos, o necesitan las identidades compiladas en binarios, estas identidades deben ser utilizadas en cualquier sistema Debian solamente para el propósito para el cual están destinadas. Esta es una restricción importante, y deberíamos evitar ir contra las políticas de administración locales. En particular, muchos sitios localizan usuarios y/o grupos del sistema local comenzando en 100.

Aparte de esto deberíamos tener identidades localizadas dinámicamente, las cuales deberían por omisión estar organizadas en algún orden, pero eso debería ser configurable.

Ningún paquete, aparte de base-passwd, debe modificar /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow.

9.2.2 Las clases UID y GID

Los números UID y GID se dividen en clases como sigue:

0-99

  • Asignados globalmente por el proyecto Debian, iguales en todos los sistemas Debian. Estos ids aparecerán en los archivos passwd y group de todos los sistemas Debian, los nuevas ids en este rango serán agregadas automáticamente al actualizarse el paquete base-passwd.

Los paquetes que necesiten un solo uid o gid asignado deberían utilizar uno de estos; sus encargados deberían pedir ids al encargado de base-passwd.

100-999

  • Grupos y usuarios del sistema asignados dinámicamente. Los paquetes que necesiten un usuario o un grupo, pero pueden tener este usuario o grupo asignado diferentemente en cada sistema, deberían utilizar adduser --system para crear el grupo y/o usuario. adduser revisará la existencia del usuario o grupo, y si es necesario elegirá un id no utilizado basado en los rangos en adduser.conf.

1000-29999

  • Cuentas de usuario asignadas dinámicamente. adduser elegirá por omisión UIDs y GIDs para cuentas de usuario en este rango, aunque adduser.conf puede ser utilizado para cambiar este comportamiento.

30000-59999

  • Reservados.

60000-64999

  • Asignados globlalmente por el proyecto Debian, pero creados solamente por solicitud. Los ids se asignan central y estáticamente, pero las cuentas efectivas sólo se crean en los sistemas de los usuarios por solicitud.

Estos ids son para paquetes que son oscuros o que requieren muchos ids asignados estáticamente. Estos paquetes deberían revisar y crear las cuentas en /etc/passwd o /etc/group (utilizando adduser si tuviese esta facilidad) si es necesario. Los paquetes que tienen probabilidad de requerir mayores asignaciones deberían tener un "hueco" detrás de ellos en la asignación, para darles espacio para crecer.

65000-65533

  • Reservados.

65534

  • Usuario nobody. El gid correspondiente se refiere al grupo nogroup.

65535

  • (uid_t)(-1) == (gid_t)(-1) no se debe usar, porque es el valor centinela de retorno de error.

9.3 Niveles de ejecución del sistema y libretos init.d

9.3.1 Introducción

El directorio /etc/init.d contiene los libretos ejecutados por init durante el arranque y cuando cambia el estado 'init' (o "nivel de ejecución") (ver =init(8)).

Hay al menos dos maneras, diferentes pero funcionalmente equivalentes, de manejar estos libretos. Para simplificar, este documento sólo describe el método del enlace simbólico. Sin embargo, los encargados de los libretos no deben asumir que éste método es el utilizado, y cualquier manipulación automática del comportamiento de cualquier nivel de ejecución realizada por libretos de encargado debe efectuarse utilizando update-rc.d como se describe más abajo, y no instalando o removiendo manualmente los enlaces simbólicos. Para más información sobre los detalles de la instrumentación del otro método, mediante el paquete file-rc, refiérase por favor a la documentación del paquete.

Estos libretos están referenciados por enlaces simbólicos en los directorios /etc/rc_n_.d. Al cambiar niveles de ejecución, init busca en el directorio /etc/rc_n_.d los libretos que debería ejecutar, donde n es el nivel de ejecución al cual se va a cambiar, o S para los libretos de arranque.

Los nombres de los enlaces tienen todos la forma S_mmlibreto_ o Kmmlibreto, donde mm es un número de dos dígitos y libreto es el nombre del libreto (debería ser el mismo que el libreto real en /etc/init.d).

Cuando init cambia el nivel de ejecución, se ejecutan primero los destinos de los enlaces cuyos nombres comienzan con K, cada uno con el argumento único stop, seguido por los libretos prefijados con S, cada uno con el argumento único start. (Los enlaces son aquellos en el directorio /etc/rc_n_.d que corresponde al nuevo nivel de ejecución). Los enlaces K son los responsables de eliminar (killing) servicios y el enlace S de iniciar los servicios al entrar al nivel de ejecución.

Por ejemplo, si cambiamos del nivel de ejecución 2 al nivel de ejecución 3, init ejecutará primero todos los libretos cuyo prefijo es K que encuentre en /etc=rc3.d, y luego todos los libretos cuyo prefijo es S en ese directorio. Los enlaces que comienzan con K causarán que el archivo referenciado sea ejecutado con un argumento de stop, y los enlaces S con un argumento de start.

El número de dos dígitos mm se usa para determinar el orden en el cual correrán los libretos: enlaces con números bajos ejecutarán sus libretos primero. Por ejemplo, los libretos K20 se ejcutarán antes que los libretos K30. Esto se utiliza cuando un cierto servicio debe ser iniciado antes que otro. Por ejemplo, el servidor de nombres de dominio bind podría necesitar ser iniciado antes que el servidor de noticias inn de forma que inn pueda configurar sus listas de acceso. En este caso, el libreto que inicia bind debería tener un número menor que el libreto que inicia inn para que se ejecute primero:

  • /etc/rc2.d/S17bind /etc/rc2.d/S70inn

Los niveles de ejecución 0 (detener) y 6 (reiniciar) son levemente diferentes. En estos niveles de ejecución, los enlaces con prefijo S aún siguen siendo ejecutados después de los que tienen prefijo K, pero también son invocados con el argumento único stop.

Además, si el libreto finaliza .sh, el libreto será tomado del nivel de ejecución S en lugar de ser ejecutado en un subproceso, pero será ejecutado explícitamente por sh en todos los demás niveles de ejecución.

9.3.2 Escribir los libretos

Los paquetes que incluyen "demonios" para servicios del sistema deberían situar los libretos en /etc/init.d para iniciar o detener servicios al arrancar o durante un cambio de nivel de ejecución. Estos libretos deberían nombrarse /etc/init.d/_paquete_, y deberían aceptar un argumento precisando qué hacer:

start

  • iniciar el servicio

stop

  • detener el servicio

restart

  • detener e iniciar el servicio si ya está en ejecución, de otro modo iniciar el servicio

reload

  • recargar la configuración del servicio sin que realmente se detenga y reinicie el servicio

force-reload

  • recargar la configuración si el servicio tiene esa capacidad, si no, reiniciar el servicio

Las opciones start, stop, restart y force-reload deberían estar previstas en todos los libretos en /etc/init.d, reload es opcional.

Los libretos init.d deberían asegurar que se comportarán con sentido si son invocados con start cuando el servicio ya está en ejecución, o con stop cuando no sea así, y que no eliminarán procesos de usuario desafortunadamente denominados. La mejor manera de hacer esto normalmente es utilizar el "demonio" start-stop-daemon.

Si un servicio recarga su configuración automáticamente (como es el caso de cron, por ejemplo), la opción reload del libreto init.d debería debería comportarse como si la configuración hubiese sido recargada exitosamente.

Los libretos /etc/init.d deben ser tratados como archivos de configuración, sea (si están presentes en el paquete, esto es, en el archivo =.deb) marcándolos como conffile=s, o, (si no están en el =.deb) manejándolos correctamente en los libretos del encargado (ver Archivos de configuración, Sección 10.7). Esto es importante porque queremos darle oportunidad al administrador del sistema local de adaptar los libretos al sistema local, p.e., para inhabilitar un servicio sin desinstalar el paquete, o para especificar alguna opción de línea de comandos especial cuando arranca un servicio, y asegurando que sus cambios no se perderán durante la siguiente actualización del paquete.

Estos libretos no deberían producir fallas oscuras cuando los archivos de configuración persisten pero el paquete ha sido removido, ya que los archivos de configuración persisten en el sistema después que el paquete ha sido removido. Sólo cuando dpkg se ejecuta con la opción --purge se eliminarán los archivos de configuración. En particular, ya que el propio libreto /etc/init.d/package es normalmente un conffile, permanecerá en el sistema si el paquete es eliminado pero no "purgado" (con la opción --purge). Por lo tanto, deberías incluir una instrucción de prueba en el principio del libreto, como esta:

  • test -f programa-ejecutado-posteriormente-en--el-libreto || exit 0

Con frecuencia hay algunas variables en los libretos init.d cuyos valores controlan la conducta de los libretos, y las cuales un administrador de sistemas probablemente quiera cambiar. Como los propios libretos son frecuentemente conffile=s, modificarlos requiere que el administrador combine sus cambios cada vez que el paquete se actualiza y el =conffile cambia. Para reducir la carga del administrador del sistema, tales valores configurables no deberían estar situados directamente en el libreto. En cambio, deberían estar situados en un archivo en /etc/default, el cual normalmente tendrá el mismo nombre base que el libreto init.d. Este archivo extra debería ser referido por el libreto cuando se ejecuta. Debe contener sólo asignaciones de variables y comentarios en formato sh POSIX. Puede ser un conffile o un archivo de configuración mantenido por los libretos del encargado del paquete. Ver [Archivos de configuración, Sección 10.7para más detalles.

Para aseguar que los valores configurables importantes están siempre disponibles, el libreto init.d debería establecer valores predeterminados para cada una de las variables shell (terminal) que utiliza, sea antes de referirse al archivo /etc/default/ o después, usando algo como la sintaxis : ${VAR:=default}. Además, el libreto init.d debe comportarse adecuadamente y no fallar si el archivo /etc/default es eliminado.

9.3.3 Relación con el sistema de libretos de inicio

Los encargados deberían utilizar la capa de abstracción provista por los programas update-rc.d y invoke-rc.d para tratar con los libretos de inicio en sus libretos de paquete tales como postinst, prerm y postrm.

El manejo directo de los enlaces /etc/re?.d y la invocación directa de los libretos en /etc/init.d sólo deberían ser realizados por los paquetes que proveen el subsistema de libretos de inicio (tales como sysv-rc y file-rc).

9.3.3.1 Manejo de los enlaces

Los encargados de los paquetes suministran el programa update-rc.d para disponer la adecuada creación y remoción de los enlaces simbólicos en /etc/rc_n_.d, o su equivalente funcional si es que se utiliza otro método. Esto podría ser utilizado por los encargados en los libretos de sus paquetes postinst y postrm.

No se debería incluir ningún enlace simbólico /etc/rc_n_.d en el archivo ni crear o remover los enlaces simbólicos en libretos de encargado; en su lugar se debería utilizar el programa update-rc.d. (Este fallará si se utiliza un método alternativo para mantener la información del nivel de ejecución). Tampoco se deben incluir los propios directorios /etc/rc_n_.d en el archivo. (Sólo el paquete sysvinit puede hacer eso).

De forma predeterminada, update-rc.d iniciará los servicios en cada uno de los niveles de ejecución multiusuario (2, 3, 4 y 5) y los detendrá en el nivel de ejecución 'detener' (0), en el nivel de ejecución monousuario (1) y el nivel de ejecuión 'reinicio' (6). El administrador del sistema tendrá la oportunidad de configurar los niveles de ejecución simplemente agregando, moviendo o eliminando los enlaces simbólicos en /etc/rc_n_.d si se utilizan enlaces simbólicos, o modificando /etc/runlevel.conf si se utiliza el método file-rc.

Para efectuar la conducta predeterminada en un paquete, coloque en el libreto postinst

  • update-rc.d _paquete_ defaults

y en postrm

  • if [ "$1" = purge ]; then update-rc.d _paquete_ remove fi

Note que si el paquete cambia niveles de ejecución o prioridad, podría tener que eliminar o recrear los enlaces, ya que de otro modo los enlaces antiguos podrían subsistir. Refíerase a la documentación de update-rc.d.

Esto utilizará un número de secuencia predeterminado de 20. Si no importa cuándo o en qué orden se ejecuta el libreto init.d, utilice este valor predeterminado. Si es relevante, entonces debería comunicarse con el encargado del paquete sysvinit o escribir a debian-devel quienes le ayudarán a elegir un número.

Para mayor información acerca del uso de update-rc.d, consulte su página de manual update-rc.d(8).