Linux Avanzado Tema 5: Comandos Administrativos

Transcripción

1 Linux Avanzado Tema 5: Comandos Administrativos Registro del sistema Acerca de los registros Muchos procesos y servidores bajo un sistema Linux anexan información de estado variable a "archivos de registro." Estos archivos de registro a menudo están localizados en el directorio /var/log/ y frecuentemente comienzan con una marca de tiempo indicando cuando ocurrió el evento descrito. Pero, para bien o para mal, no existe una consistencia real en cuanto al formato preciso de los archivos de registro. La única característica confiable es que los archivos de registro de Linux son simples archivos ASCII, y contienen solo un "evento" por línea de archivo. A menudo (pero no siempre) los archivos de registro contienen un conjunto, relativamente consistente, de campos de datos delimitados por espacios o por pestañas. Algunos procesos, especialmente los servicios de Internet, controlan la escritura de los archivos de registro dentro de su propio proceso. En el fondo, escribir a un archivo de registro son solo datos anexados a un control de archivo abierto. Pero muchos programas (especialmente los daemons y los trabajos cron usan el syslog API estándar para permitir que los daemons syslogd o klogd controlen el proceso de registro específico. Análisis de chivos de registro La forma exacta de cómo realizar el análisis de un archivo de registro dependerá mucho del formato específico que tome. Para los archivos de registro con formato de tabla normal, herramientas tales como cortet, separe, cabeza, y cola seguramente serán útiles. Para todos los archivos de registro, grep es una excelente herramienta para hallar y filtrar contenidos de interés. Para tareas de procesamiento más complejas, probablemente se considere sed, awk, perl o python como herramientas opcionales. Para una buena introducción a muchas de las herramientas de procesamiento de texto, que probablemente se utilicen en el proceso y análisis de archivos de registro, ver el tutorial developerworks de IBM de David en las utilidades de procesamiento de textos GNU. También existen distintas buenas herramientas de mayor nivel para trabajar con archivos de registro, pero estas herramientas son generalmente utilidades de distribución específica y/o no estándar (pero a menudo de Software Libre). Registrar con syslogd y klogd El klogd daemon intercepta y registra mensajes kernel de Linux. En general, klogd utiliza las capacidades más generales de syslogd, pero en casos especiales puede registrar mensajes directamente a un archivo. El syslogd daemon general provee registro para muchos programas. Cada mensaje registrado contiene al menos un campo de tiempo y de nombre de host y generalmente un campo de nombre del programa. El comportamiento específico del syslogd está controlado por el archivo de configuración /etc/syslog.conf. Los mensajes de aplicaciones (incluyendo los de kernel) pueden ser registrados a archivos, que generalmente se encuentran bajo /var/log/ o en forma remota sobre el socket de red. Configuración del /etc/syslog.conf El archivo /etc/syslog.conf contiene un conjunto de reglas, una por línea. Se deberán ignorar las líneas vacías y las líneas que comienzan con un "#". Cada regla consiste en dos campos separados por espacios en blanco, un campo selector y un campo de acción. El selector, a su vez, contiene uno de varios pares de facilidades separadas por puntos/prioritarios. Una facilidad es un subsistema que intenta registrar mensajes y puede tener valores (puede no distinguir mayúsculas de minúsculas): auth,authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uu cp y local0 hasta local7. 1

2 Las prioridades tienen un orden específico y el hecho de coincidir con una determinada prioridad significa "ésta o una más alta" a menos que se inicie con un "=" (o "!="). Las prioridades son, en orden ascendente: debug, info, notice, warning o warn,err o error, crit, alert, emerg o panic (algunos nombre tienen sinónimos). none significa que no se indica una prioridad. Ambas facilidades y prioridades pueden aceptar el comodín "*". Hay múltiples facilidades que pueden ser separadas por una coma y múltiples selectores que pueden ser separados por un punto y coma. Por ejemplo: # from /etc/syslog.conf # all kernel mesages kern.* -/var/log/kern.log # `catch-all' logfile *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # Emergencies are sent to everybody logged in *.emerg * Configuración de un registro remoto Para habilitar el registro remoto de mensajes syslogd (en realidad mensajes de aplicación controlados por syslogd), se debe primero habilitar el servicio "syslog" tanto en las máquinas de escucha como en las de envío. Para ello, se debe agregar una línea a cada archivo de configuración /etc/services que contenga algo como: syslog 514/UDP Para configurar el syslogd (de envío) local para que pueda enviar mensajes a un host remoto, se especifica una facilidad y una prioridad normal pero se indica una acción comenzando con un símbolo "@" para el host de destino. Un host se puede configurar de la manera habitual, ya sea con /etc/hosts o vía DNS (no se necesita tenerlo ya resuelto al momento de lanzar syslogd por primera vez). Por ejemplo: # from /etc/syslog.conf # log all critical messages to master.example.com # log all mail messages except info level to mail.example.com Rotación de archivos de registro Frecuentemente no es deseable dejar crecer ciertos archivos de registro de forma descontrolada. La utilidad logrotate se puede utilizar para archivar información registrada con anterioridad. Usualmente, logrotate se ejecuta como un trabajo cron(programador de tareas a intervalos de tiempo predeterminados), por lo general siempre en forma diaria. logrotate permite una rotación automática, compresión, eliminación, y envío de archivos de registro. Cada archivo de registro puede ser controlado en forma diaria, semanal, mensual o sólo cuando crece de manera desmesurada. El comportamiento de logrotate se controla mediante el archivo de configuración /etc/logrotate.conf (o algún otro archivo especificado). El archivo de configuración puede contener tanto opciones globales como opciones de archivos específicos. Generalmente, los registros archivados se guardan por un período de tiempo finito y se les da nombres de copias de seguridad secuenciales. Por ejemplo, tengo un sistema que contiene los siguientes archivos debido a su calendario de rotación. -rw-r root adm :00 /var/log/syslog -rw-r root adm :36 /var/log/syslog.0 -rw-r root adm :35 /var/log/syslog.1.gz -rw-r root adm :35 /var/log/syslog.2.gz -rw-r root adm :35 /var/log/syslog.3.gz -rw-r root adm :35 /var/log/syslog.4.gz -rw-r root adm :35 /var/log/syslog.5.gz 2

3 Empaquetamiento de software En el principio era el En realidad, para distribuir software personalizado en Linux, se requiere mucho menos de lo que se cree. Linux tiene un estándar bastante claro en cuanto a la ubicación de archivos de distintos tipos e instalar software personalizado, en el fondo, no implica mucho más que ubicar los archivos correctos en el lugar correcto. La herramienta Linux tar (que significa "tape archive [archivo de almacenamiento de cinta]" a pesar de que no necesita y generalmente no utiliza cintas) es perfectamente adecuada para crear un archivo de almacenamiento de archivos con las ubicaciones de los sistemas de archivos especificadas. Para la distribución, generalmente es deseable comprimir un archivo de almacenamiento tar con gzip (GNU ZIP) (o bzip2). Para más información sobre estas utilidades ver la sección final de este tutorial en la copia de seguridad. Generalmente se denomina a un archivo de almacenamiento comprimido tar con las extensiones.tar.gz o.tgz (o.tar.bz2). Las primeras distribuciones Linux, y algunas de las actuales, tales como Slackware, usan simplemente tarballs como mecanismo de distribución. Para una distribución personalizada de software interno de la empresa a sistemas Linux mantenidos centralmente, continúa siendo el método más sencillo. Formatos de archivos de almacenamiento personalizados Muchos lenguajes de programación y otras herramientas vienen con sistemas de distribución personalizados que son neutrales entre las distribuciones Linux y, generalmente, entre sistemas operativos totalmente diferentes. Python tiene sus herramientas distutils y formatos de archivo de almacenamiento; Perl tiene archivos de almacenamiento CPAN; Java tiene archivos.jar; Ruby (lenguaje de programación) tiene gems. Muchas aplicaciones no idiomáticas tienen un sistema estándar para distribuir los complementos, u otras mejoras, también a una base de aplicación. Si bien se puede usar perfectamente un formato de paquete como DEB o RPM para, por ejemplo, distribuir un paquete Python, en general tiene más sentido seguir los estándares de empaquetamiento de la herramienta para la cual se creó el paquete. Por supuesto, para utilidades y aplicaciones a nivel sistema o para la mayoría de las aplicaciones userland compiladas, ese estándar equivale a los estándares de empaquetamiento de distribución Linux. Pero para las herramientas personalizadas escritas en lenguajes de programación específicos, algo diferente podría promover una más simple reutilización de las herramientas en todas las distribuciones y plataformas (ya sea que los destinatarios elegidos sean usuarios internos de la empresa o externos). Los dos grandes de los formatos de paquetes Existen dos formatos de paquetes principales utilizados por las distribuciones Linux: Redhat Package Manager (RPM) y Debian (DEB). Ambas son similares en cuanto al propósito pero difieren en sus detalles. En general, los dos son un formato para un archivo de almacenamiento de archivos mejorado. Las mejoras aportadas por estos formatos de paquete incluyen anotaciones para números de versión, dependencias de una aplicación sobre otras aplicaciones o bibliotecas, descripciones de herramientas empaquetadas de legibilidad humana, y un mecanismo general para gestionar la instalación, actualización y desinstalación de herramientas empaquetadas. Bajo los archivos DEB, el archivo de configuración anidado control contiene la mayor parte de los metadatos del paquete. Para los archivos RPM, el archivo spec es el que juega este rol. Todos los detalles de la creación de buenos paquetes, en cualquiera de los formatos, va más allá de este tutorial, de todas formas esbozaremos aquí los fundamentos básicos. "> Qué hay dentro de un archivo.deb? Un paquete DEB se crea con la herramienta de archivos de almacenamiento, y primo de tar, ar (o mediante alguna herramienta de mayor nivel que utilice ar). Por lo tanto podemos usar ar solo para ver que hay realmente dentro de un archivo.deb file. Normalmente se usarían herramientas de 3

4 mayor nivel tales como dpkg, dpkg-deb o apt-get para de hecho trabajar con un paquete DEB. Por ejemplo: % ar tv unzip_5.51-2ubuntu1.1_i386.deb rw-r--r-- 0/0 4 Aug 1 07: debian-binary rw-r--r-- 0/ Aug 1 07: control.tar.gz rw-r--r-- 0/ Aug 1 07: data.tar.gz El archivo debian-binario simplemente contiene la versión DEB (actualmente 2.0). El tarball data.tar.gz contiene en realidad los archivos de aplicación; ejecutables, documentación, páginas del manual, archivos de configuración, etc. El control.tar.gz tarball es el más interesante desde una perspectiva de empaquetamiento. Veamos el ejemplo de paquete DEB elegido: % tar tvfz control.tar.gz drwxr-xr-x root/root :23:43./ -rw-r--r-- root/root :23:43./md5sums -rw-r--r-- root/root :23:43./control Como es de esperar, md5sums contiene hashes cifrados de todos los archivos distribuidos con fines de verificación. El archivocontrol es do nde se aloja la metadata. En algunos casos también se podría encontrar o desear incluir scripts llamadospostinst y prerm en control.tar.gz para, realizar los determinados y respectivos pasos luego de la instalación o antes de la remoción. Creación de un archive de control DEB Los scripts de instalación pueden hacer todo lo que podría hacer un script shell. (para hacerse una idea ver algunos ejemplos en paquetes existentes). Pero esos scritps son opcionales y, a menudo, no necesarios o incluidos. Lo que se requiere para un paquete.deb es su archivo de control. El formato de este archivo contiene varios campos de metadata que se ilustra mejor por medio de un ejemplo: % cat control Package: unzip Version: ubuntu1.1 Section: utils Priority: optional Architecture: i386 Depends: libc6 (>= ds1-4) Suggests: zip Conflicts: unzip-crypt (<< 5.41) Replaces: unzip-crypt (<< 5.41) Installed-Size: 308 Maintainer: Santiago Vila <sanvila@debian.org> Description: De-archiver for.zip files InfoZIP's unzip program. With the exception of multi-volume archives (ie,.zip files that are split across several disks using PKZIP's /& option), this can handle any file produced either by PKZIP, or the corresponding InfoZIP zip program.. Esta versión soporta encriptado. Básicamente, exceptuando los valores de datos personalizados, se debería hacer que el archivo de control sea igual a éste. Para paquetes específicamente no-cpu5, ya sean scripts, documentación pura o código fuente, se debe usar Architecture: all (Arquitectura: todas). Creación de un paquete DEB La creación de un paquete DEB se realiza con la herramienta dpkg-deb. No se pueden cubrir todas las complejidades de un buen empaquetamiento, pero la idea básica es la de crear un directorio de trabajo,./debian/, y agregarle los contenidos necesarios antes de ejecutar dpkg-deb. También sería deseable establecer permisos en sus archivos para que coincidan con el estado pretendido al momento de su instalación. Por ejemplo: % mkdir -p./debian/usr/bin/ % cp foo-util./debian/usr/bin # copy executable/script % mkdir -p./debian/usr/share/man/man1 % cp foo-util.1./debian/usr/share/man/man1 # copy the manpage % gzip --best./debian/usr/share/man/man1/foo-util.1 % find./debian -type d xarg chmod 755 4

5 # set dir permissions % mkdir -p./debian/debian % cp control./debian/debian # first create a matching 'control' % dpkg-deb --build debian # create the archive % mv debian.deb foo-util_1.3-1all.deb # rename to final package name Más sobre la creación de paquetes DEB En el panel previo se puede observar que la estructura del directorio local debajo de./debian/ debería coincidir con la estructura de instalación pretendida. Vale la pena tomar en cuenta algunos otros puntos con respecto a la creación de un buen paquete. Generalmente se debería crear un archivo llamado./debian/usr/share/doc/foo-util/copyright como parte de su distribución (adaptar al nombre del paquete). También es de buena práctica crear los archivos./debian/usr/share/doc/fooutil/changelog.gz y./debian/usr/share/doc/foo-utils/changelog.debian.gz. La herramienta lintian verificará cualquier aspecto cuestionable de un paquete DEB. No es necesario rep arar absolutamente todo lo que lintian señale como cuestionable; pero si se pretende una distribución más amplia, sería bueno reparar todos los problemas que indique. La herramienta fakeroot es útil para que el empaquetamiento se realice con el dueño correcto. Habitualmente el destino desea herramientas instaladas como raíz, no como el usuario individual que simplemente generó el paquete (lintian advertirá sobre esto). Esto se puede lograr con: % fakeroot dpkg-deb --build debian Qué hay dentro de un archivo.rpm? Cuando crea paquetes RPM adopta una estrategia ligeramente distinta a DEB. Su archivo de configuración se llama spec en vez de control, pero el archivo spec también realiza más trabajo que un archivo de control. Todos los detalles sobre los pasos previos necesarios para la instalación, los posteriores a la instalación, los previos a la eliminación y los necesarios para la instalación en sí, están contenidos como archivos script incrustados en una configuración spec. De hecho, el formato spec incluye hasta un macros para acciones comunes. Cuando se crea un paquete RPM, se lo hace con la utilidad rpm -b. Por ejemplo: % rpm -ba foo-util-1.3.spec # perform all build steps Este proceso de construcción de paquetes no depende de directorios con nombres específicos como es el caso de DEB, sino más bien de las directivas de un archivo spec más complejo. Creación de metadatos RPM Los metadatos básicas en un RPM es muy similar a la que está en un DEB. Por ejemplo, foo-util- 1.3.spec podría contener algo como: # spec file for foo-util 1.3 Summary: A utility that fully foos Name: foo-util Version: 1.3 Release: 1 Copyright: GPL Group: Application/Misc Source: ftp://example.com/foo-util.tgz URL: Distribution: MyLinux Vendor: Acme Systems Packager: John Doe <jdoe@acme.example.com> %description The foo-util program is an advanced fooer that combines the capabilities of OneTwo's foo-tool and those in the GPL bar-util. Scripting en un RPM Distintas secciones de un archivo spec RPM pueden contener mini scripts de shell. Las mismas incluyen: %prep: Pasos necesarios para preparar la construcción tales como la limpieza general de construcciones anteriores (parciales). A menudo el siguiente macro es útil y suficiente: 5

6 %prep%setup %build: Pasos para la construcción en sí de la herramienta. Si se usa la facilidad make, esto podría equivaler a: %buildmake %install: Pasos para instalar la herramienta. Nuevamente si se usa make esto podría significar: %installmake install %files: Se debet incluir un listado de archivos que sean parte del paquete. Aún cuando el Makefile pueda usar estos archivos, el programa de gestión de paquete (rpm) no se enterará a menos que se los incluya aquí: %files%doc README /usr/bin/foo-util /usr/share/man/man1/foo-util.1 Operaciones de copias de seguridad Acerca de copias de seguridad La primera regla para hacer copias de seguridad es: Hágalas! Es muy fácil, en la administración de servidores, o aún con Linux en el escritorio, descuidar la realización de las copias de seguridad con una determinada frecuencia adecuada a sus necesidades. La forma más sencilla de hacer copias de seguridad en forma sistemática y programada es hacerlas en un trabajo cron. Ver en el tutorial del Tema 213 una discusión sobre la configuración de crontab. En parte, la elección de la frecuencia depende de la herramienta de copias de seguridad y del medio que se utilice para realizarlo. Hacer copias de seguridad en cinta es una técnica tradicional y una unidad de cinta continúa ofreciendo la mayor capacidad dentro de lo que son los medios relativamente económicos. Pero, recientemente, los CDs y DVD con acceso de escritura y reescritura se han convertido en algo de uso común y con frecuencia serán un medio extraíble razonable para hacer copias de seguridad. Que se debe guardar en las copias de seguridad Algo positivo acerca de Linux es que usa una organización de archivos jerárquica predecible. Consecuentemente, rara vez será necesario hacer copias de seguridad de toda una jerarquía de sistemas de archivo; la mayor parte de una jerarquía de sistemas de archivos Linux puede ser reinstalada fácilmente desde un medio de distribución. En ámbitos grandes, una imagen master server se podría usar para crear un sistema básico Linux que se puede personalizar mediante la restauración de unos pocos archivos seleccionados que hayan sido guardados en copias de seguridad en alguna otra parte. Básicamente, lo que se desea resguardar es /home/, /etc/, /usr/local/, y tal vez /root/ y /boot/. Frecuentemente también se deseará resguardar algunas partes de /var/, tales como /var/log/ y /var/mail/. Hacer copias de seguridad con cp y scp Quizás la forma más simple de hacer una copia de seguridad sea con cp o scp y el switch - r (recursión). Los primeros copian a medios locales (pero que incluyen montajes NFS), los últimos pueden copiar a servidores remotos en una forma cifrada segura. En cualquiera de los casos, se necesitará una unidad de disco montada que, por supuesto, tenga suficiente espacio para poder acomodar los archivos que se desean guardar. Para poder lograr cualquier protección real de hardware, es deseable que la partición que se copia sea un dispositivo físico distinto al de la/las unidades de disco desde las cuales se hacen las copias de seguridad. 6

7 Copiar con cp o scp puede ser parte de una frecuencia para copias de seguridad adicionales actualizadas. El truco está en usar la utilidad find para descifrar cuales archivos han sido modificados recientemente. He aquí un simple ejemplo en el que copiamos todos los archivos en /home/ que fueron modificados durante el primer día: #!/bin/bash# File: backup-daily.sh # ++ Run this on a daily cron job ++ #-- first make sure the target directories exist for d in `find /home -type d` ; do mkdir -p /mnt/backup$d ; done #-- then copy all the recently modified files (one day) for f in `find /home -mtime -1` ; do cp $f /mnt/backup$f ; done El indicador cp -u es bastante similar, pero depende de la continuidad del sistema de archivos en cuanto a los eventos en los que se efectúan las copias de seguridad. El enfoque de búsqueda funciona bien si se le cambia el punto de montaje de /mnt/backup a una ubicación NFS distinta. Además el sistema de búsqueda trabaja igualmente bien con scp una vez que se especifica la información de inicio de sesión necesaria al sitio remoto. Hacer copias de seguridad con tar A pesar de que el cp y el scp son trabajables para hacer copias de seguridad, en general se usa más tar, ya que se diseñó específicamente para crear archivos de cinta. A pesar del origen del nombre, tar (tape archive archive de cinta) es igualmente capaz de de crear un simple archivo.tar como datos sin procesar en una unidad de cinta. Por ejemplo, se podrían hacer copias de seguridad en una cinta usando un comando como: % tar -cvf /dev/rmt0 /home # Archive /home to tape Dirigir los datos de salida a un archivo, no es muy distinto de: % tar -cvf /mnt/backup/ tar /home De hecho, dado que gzip es transmisible por secuencias, se puede fácilmente comprimir un archivo durante la creación: % tar -cv /home gzip - > /mnt/backup/ tgz Se puede combinar tar con find usando las mismas formas indicadas para cp o scp. Para listar los archivos en una unidad de cinta, se podría usar: % tar -tvf /dev/rmt0 Para recuperar un archivo específico: % tar -xvf /dev/rmt0 file.name Hacer copias de seguridad con cpio La utilidad cpio es un superconjunto de tar. Maneja archivos tar, pero también podría trabajar con varios otros formatos y tiene muchas más opciones incorporadas. cpio viene con una gran variedad de switches para filtrar aquellos archivos que están respaldados con copias de seguridad e inclusive da soporte interno de copias de seguridad remotas (más que necesitar canalizar a través 7

8 de scp o similares). La principal ventaja que cpio tiene sobre tar es que puede tanto agregar archivos a archivos de mantenimiento como eliminar archivos en retroceso. He aquí algunos rápidos ejemplos de cpio: Crear un archivo de almacenamiento en un dispositivo de cinta: % find /home -print cpio - ocbv /dev/rmt0. Listar las entradas en un archivo de almacenamiento en un dispositivo de cinta: % cpio - itcvb < /dev/rmt0. Recuperar un archivo de una unidad de cinta: % cpio -icvdbum file.name < /dev/rmt0. Hacer copias de seguridad con dump y restore Los conjuntos de herramientas llamados dump y restore (o nombres relacionados) son, cada tanto, utilizados para hacer copias de seguridad de sistemas de archivos enteros. Lamentablemente, estas herramientas son específicas para tipos de sistemas de archivo y no están uniformemente disponibles. Por ejemplo, los dump y restore originales son ext2/3-specific mientras que las herramientas xfsdump y xfsrestore son usadas para sistemas de archivos XFS. No todo tipo de sistema de archivos tiene las herramientas equivalentes y aún si así fuera, los switches no son necesariamente uniformes. Es bueno estar al tanto de estas utilidades, pero no son muy uniformes en todos los sistemas Linux. Para algunos propósitos, como por ejemplo si solo se usa particiones XFS, el rendimiento de dump y restore puede significar un gran avance por sobre un simple tar o cpio. Copias de seguridad adicionales actualizadas con rsync rsync es una utilidad que provee una rápida transferencia de archivos adicionales actualizados. Para copias de seguridad remotas automatizadas, rsync es a menudo la mejor herramienta para hacer el trabajo. Una buena característica de rsync sobre otras herramientas es que puede, en forma opcional, imponer una sincronización bidireccional. Es decir, más que simplemente hacer copias de seguridad de archivos más nuevos o modificados, también puede eliminar de forma automática archivos borrados localmente de las copias de seguridad remotas. Para tener una idea sobre las distintas opciones, es de gran utilidad ver este ligeramente complejo script (ubicado en las páginas Web de rsync): #!/bin/sh# This script does personal backups to a rsync backup server. You will # end up with a 7 day rotating incremental backup. The incrementals will # go into subdirs named after the day of the week, and the current # full backup goes into a directory called "current" # tridge@linuxcare.com # directory to backup BDIR=/home/$USER # excludes file - this contains a wildcard pats of files to exclude EXCLUDES=$HOME/cron/excludes # the name of the backup machine BSERVER=owl # your password on the backup server export RSYNC_PASSWORD=XXXXXX BACKUPDIR=`date +%A` OPTS="--force --ignore-errors --delete-excluded --exclude-from=$excludes --delete --backup --backup-dir=/$backupdir -a" export PATH=$PATH:/bin:/usr/bin:/usr/local/bin # the following line clears the last weeks incremental directory [ -d $HOME/emptydir ] mkdir $HOME/emptydir rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/ rmdir $HOME/emptydir # now the actual transfer rsync $OPTS $BDIR $BSERVER::$USER/current Recursos Aprender "Uso de utilidades de texto GNU" (developerworks, marzo 2004) muestra cómo usar la colección de utilidades de texto GNU para procesar archivos de registro, documentación, base de datos de textos estructurados y otras fuentes en texto de datos o contenidos. "Comprensión de archivos de configuración Linux" (developerworks, diciembre 2001) explica los archivos de configuración en un sistema Linux, que controlan los permisos del 8

9 usuario, las aplicaciones del sistema, los daemons, los servicios y otras tareas administrativas en un ámbito de múltiples tareas para múltiples usuarios. "Windows-to-Linux roadmap: Part 8. Backup and recovery" (developerworks, noviembre 2003) es una rápida guía a las copias de seguridad y recuperación de Linux. Encuentre más recursos para desarrolladores en la zona developerworks de Linux. Autor: David Mertz es Turing completo, pero probablemente no apruebe la Prueba de Turing. Para conocer más acerca de su vida, consulte su página Web personal. David escribe las columnas developerworks Charming Python y XML Matters desde el año Consulte su librotext Processing in Python [Procesamiento de texto en Python]. Compilación y edición: Ing. Sergio Aguilera. Facultad de Tecnología Informática. Universidad de Belgrano. sergio.aguilera@ub.edu.ar Todos los Derechos Reservados a IBM Corp. Marzo