I.

ADMINISTRACIN DE LINUX 1. Software Libre y OpenSource

Bajo la idea de los movimientos (o filosofas) de Software Libre y Open Source (tambin llamado de cdigo abierto o software abierto), se encuentran varias formas de software, no todas del mismo tipo, pero s compartiendo muchas ideas comunes. La denominacin de un producto de software como de cdigo abierto conlleva como idea ms importante la posibilidad de acceder a su cdigo fuente, y la posibilidad de modificarlo y redistribuirlo de la manera que se considere conveniente, estando sujeto a una determinada licencia de cdigo abierto, que nos da el marco legal. Frente a un cdigo de tipo propietario, en el cual un fabricante (empresa de software) encierra su cdigo, ocultndolo y restringindose los derechos a s misma, sin dar posibilidad de realizar ninguna adaptacin ni cambios que no haya realizado previamente la empresa fabricante, el cdigo abierto ofrece, entre otras consideraciones: a) Acceso al cdigo fuente, ya sea para estudiarlo (ideal para educacin) o modificarlo, sea para corregir errores, adaptarlo o aadir ms prestaciones. b) Gratuidad: normalmente, el software, ya sea en forma binaria o en la forma de cdigo fuente, puede obtenerse libremente o por una mdica cantidad en concepto de gastos de empaquetamiento, distribucin y valores aadidos. c) Evitar monopolios de software propietario: no depender de una nica opcin o nico fabricante de nuestro software. Esto es ms importante cuando se trata de una gran organizacin, ya sea una empresa o estado, los cuales no pueden (o no deberan) ponerse en manos de una determinada nica solucin y pasar a depender exclusivamente de ella. d) Un modelo de avance, no basado en la ocultacin de informacin, sino en la comparticin del conocimiento (semejante al de la comunidad cientfica), para lograr progresos de forma ms rpida, con mejor calidad, ya que las elecciones tomadas estn basadas en el consenso de la comunidad, y no en los caprichos de empresas desarrolladoras de software propietario. Crear programas y distribuirlos junto al cdigo fuente no es nuevo. Ya desde los inicios de la informtica y en los inicios de la red Internet se haba hecho as. Sin embargo, el concepto de cdigo abierto como tal, la definicin y la redaccin de las condiciones que tena que cumplir datan de mediados de 1997

Un pequeo resumen (interpretacin) de la definicin: Un Open Source Software, o software de cdigo fuente abierto, debe cumplir los requisitos siguientes: 1) Se puede copiar, regalar o vender a terceros el software, sin tener que pagar a nadie por ello. Se permite copiar el programa.

2) El programa debe incluir el cdigo fuente y tiene que permitir la distribucin tanto en forma compilada, como en fuente. O, en todo caso, hay que facilitar algn modo de obtener los cdigos fuente (por ejemplo, descarga desde Internet). No est permitido ocultar el cdigo, o darlo en representaciones intermedias. Garantiza que se pueden hacer modificaciones. 3) La licencia del software tiene que permitir que se puedan realizar modificaciones y trabajos que se deriven, y que entonces se puedan distribuir bajo la misma licencia que la original. Permite reutilizar el cdigo original. 4) Puede requerirse la integridad del cdigo del autor, o sea, las modificaciones se pueden presentar en forma de parches al cdigo original, o se puede pedir que tengan nombres o nmeros distintos a los originales. Esto protege al autor de qu modificaciones puedan considerarse como suyas. Este punto depende de lo que diga la licencia del software. 5) La licencia no debe discriminar a ninguna persona o grupo. No se debe restringir el acceso al software. Un caso aparte son las restricciones por ley, como las de las exportaciones tecnolgicas fuera de USA a terceros pases. Si existen restricciones de este tipo, hay que mencionarlas. 6) No discriminar campos laborales. El software puede utilizarse en cualquier ambiente de trabajo, aunque no haya estado pensado para l. Otra lectura es permitir fines comerciales, nadie puede impedir que el software se utilice con fines comerciales. 7) La licencia es aplicable a todo el mundo que reciba el programa. 8) Si el software forma parte de producto mayor, debe permanecer con la misma licencia. Esto controla que no se separen partes para formar software propietario (de forma no controlada). En el caso de software propietario, hay que informar que hay partes (y cules) de software de cdigo abierto. 9) La licencia no debe restringir ningn software incorporado o distribuido conjuntamente, o sea, incorporarlo no debe suponer ninguna barrera para otro producto de software distribuido conjuntamente. ste es un punto polmico, ya que parece contradecirse con el anterior, bsicamente dice que cualquiera puede coger software de cdigo abierto y aadirlo al suyo sin que afecte a las condiciones de su licencia (por ejemplo propietaria), aunque s que, segn el punto anterior, tendra que informar que existen partes de cdigo abierto. 10) La licencia tiene que ser tecnolgicamente neutra. No deben mencionarse medios de distribucin nicos, o excluirse posibilidades. Por ejemplo, no puede limitarse (por licencia) que se haga la distribucin en forma de CD, ftp o mediante web. La licencia que traiga el programa tiene que cumplir las especificaciones anteriores para que el programa se considere de cdigo abierto. La organizacin OSI se encarga de comprobar que las licencias cumplen las especificaciones. En la pgina web de Open Source Licenses se puede encontrar la lista de las licencias, siendo una de las ms famosas y utilizadas, la GPL (GNU Public License). Bajo GPL, el software puede ser copiado y modificado, pero las modificaciones deben hacerse pblicas bajo la misma licencia. Y se impide que el cdigo se mezcle con cdigo propietario, para evitar as que el cdigo propietario se haga con partes abiertas. Existe una licencia LGPL que es prcticamente igual, pero permite que software con esta licencia sea integrado en

software propietario. Un ejemplo clsico es la biblioteca (library) C de Linux (con licencia LGPL); si sta fuera GPL, slo podra desarrollarse software libre, con la LGPL se permite usar para desarrollar software propietario. Muchos proyectos de software libre, o con parte de cdigo abierto y parte propietario, tienen su propia licencia: Apache (basada en BSD), Mozilla (MPL y NPL de Netscape), etc. Bsicamente, a la hora de poner el software como open source podemos poner nuestra propia licencia que cumpla la definicin anterior (de cdigo abierto), o podemos escoger licenciar bajo una licencia ya establecida, o como en el caso de la GPL, nos obliga a que nuestra licencia tambin sea GPL.

2.

Historia de Unix

3.

Kernel

El kernel del sistema GNU/Linux (al que habitualmente se le denomina Linux) [Vas03b] es el corazn del sistema: Se encarga de arrancar el sistema y, una vez ste es ya utilizable por las aplicaciones y los usuarios, gestiona los recursos de la mquina en forma de gestin de la memoria, sistema de ficheros, entrada/salida, procesos e intercomunicacin de procesos.

El ncleo o kernel es la parte bsica de cualquier sistema operativo, y en l descansa el cdigo de los servicios fundamentales para controlar el sistema entero. Bsicamente, su estructura se puede separar en: Gestin de procesos: qu tareas se van a ejecutar y en qu orden y prioridad. Un aspecto importante es la planificacin de CPU, cmo se optimiza el tiempo de la CPU para ejecutar las tareas con el mayor rendimiento o interactividad posible con los usuarios. Intercomunicacin de procesos y sincronizacin: cmo se comunican tareas entre s, con qu diferentes mecanismos y cmo pueden sincronizarse grupos de tareas. Gestin entrada/salida (E/S): control de perifricos y gestin de recursos asociados. Gestin de memoria: optimizacin del uso de la memoria, sistema de paginacin y memoria virtual. Gestin de ficheros: cmo el sistema controla y organiza los ficheros presentes en el sistema y el acceso a los mismos.

4.

FHS (Filesystem Hierchachy Standard)

En el estndar FHS (Filesystem Hierchachy Standard) se describen la estructura de rbol del sistema de ficheros principal (/), donde se especifica la estructura de los directorios y los principales ficheros que contendrn.

Un esquema bsico de directorios podra ser:

 /bin: utilidades de base del sistema, normalmente programas empleados por los usuarios, ya sean desde los comandos bsicos del sistema (como /bin/ls, listar directorio), pasando por los shells (/bin/bash), etc. /boot: archivos necesarios durante el arranque del sistema, por ejemplo la imagen del kernel Linux, en /boot/vmlinuz. /dev: aqu encontramos ficheros especiales que representan los dispositivos posibles en el sistema, el acceso a los perifricos en sistemas UNIX se hace como si fueran perifricos. Podemos encontrar ficheros como /dev/console, /dev/modem, /dev/mouse, /dev/cdrom, /dev/floppy, ... que suelen ser enlaces a dispositivos ms especficos del tipo de controlador o interfaz que utilizan los dispositivos: /dev/mouse /dev/psaux, un ratn de tipo PS2; o /dev/cdrom /dev/hdc, un CD-ROM que es un dispositivo del segundo conector IDE y mster. Aqu encontramos los dispositivos IDE como /dev/hdx, los scsi /dev/sdx, ... con x variando segn el dispositivo. /etc: ficheros de configuracin. La mayora de tareas de administracin necesitarn examinar o modificar los ficheros contenidos en este directorio. Por ejemplo: /etc/passwd contiene la informacin de las cuentas de los usuarios del sistema. /home: contiene las cuentas de los usuarios, es decir, los directorios personales de cada usuario. /lib: las bibliotecas del sistema, compartidas por los programas de usuario, ya sean estticas (extensin .a) o dinmicas (extensin .so). Por ejemplo, la biblioteca C estndar, en ficheros libc.so o libc.a. /mnt: punto para montar (comando mount) sistemas de ficheros extrables; por ejemplo: /mnt/cdrom, para montar el lector de CD-ROM. /opt: suele colocarse el software aadido al sistema posterior a la instalacin; otra instalacin vlida es en /usr/local. /sbin: utilidades de base del sistema. Suelen ser comandos reservados al administrador (root). Por ejemplo: /sbin/fsck para verificar el estado de los sistemas de ficheros. /tmp: ficheros temporales de las aplicaciones o del propio sistema. /usr: diferentes elementos instalados en el sistema. Algn software de sistema ms completo se instala aqu, adems de complementos multimedia (iconos, imgenes, sonidos, por ejemplo en: /usr/share) y la documentacin del sistema (/usr/doc). Tambin en /usr/local se suele utilizar para instalar software. /var: ficheros de registro de sesin o de estado (ficheros de tipo log) y/o errores del propio sistema y de diversos servicios, tanto locales como de red. Por ejemplo, ficheros de sesin en /var/log, contenido de los mails en /var/spool/mail, o trabajos de impresin en /var/spool/lpd.

5.

Documentacin del sistema en lnea

a) man es la ayuda por excelencia. Nos permite consultar el manual de GNU/Linux, que est agrupado en varias secciones, correspondientes a comandos administracin, formatos de ficheros, comandos de usuario, llamadas de lenguaje C, etc. Normalmente, para obtener la ayuda asociada, tendremos suficiente con: man comando

b) info es otro sistema de ayuda habitual. Es un programa desarrollado por GNU para la documentacin de muchas de sus herramientas. Es bsicamente una herramienta textual en la que los captulos y pginas se pueden recorrer por medio de un sistema de navegacin simple (basado en teclado). c) Documentacin de las aplicaciones: adems de ciertas pginas man, es habitual incluir en las aplicaciones documentacin extra, ya sea en forma de manuales o tutoriales, o simples guas de usuario. Normalmente, estos componentes de documentacin se instalan en el directorio /usr/doc, en donde se crea un directorio por paquete de aplicacin.

6.

Variables del Sistema

Se pueden consultar con el comando ECHO

Prctica: Uso del comando ENV

7.

Tareas del Administrador de Servidores

Arranque y apagado del sistema: cualquier sistema basado en UNIX tiene unos sistemas de arranque y apagado valorables, de manera que podemos configurar qu servicios ofrecemos en el arranque de la mquina y cundo hay que pararlos, o programar el apagado del sistema para su mantenimiento.

 Gestin de usuarios y grupos: dar cabida a los usuarios es una de las principales tareas de cualquier administrador. Habr que decidir qu usuarios podrn acceder al sistema, de qu forma y bajo qu permisos; y establecer comunidades mediante los grupos. Un caso particular ser el de los usuarios de sistema, pseudousuarios dedicados a tareas del sistema. Gestin de recursos del sistema: qu ofrecemos, cmo lo ofrecemos y a quin damos acceso. Gestin de los sistemas de ficheros: el ordenador puede disponer de diferentes recursos de almacenamiento de datos y dispositivos (disquetes, discos duros, pticos, etc.) con diferentes sistemas de acceso a los ficheros. Pueden ser permanentes o extrables o temporales, con lo cual habr que modelar y gestionar los procesos de montaje y desmontaje de los sistemas de ficheros que ofrezcan los discos o dispositivos afines. Cuotas del sistema: cualquier recurso que vaya a ser compartido tiene que ser administrado, y segn la cantidad de usuarios, habr que establecer un sistema de cuotas para evitar el abuso de los recursos por parte de los usuarios o establecer clases (o grupos) de usuarios diferenciados por mayor o menor uso de recursos. Suelen ser habituales sistemas de cuotas de espacio de disco, o de impresin, o de uso de CPU (tiempo de computacin usado). Seguridad del sistema: seguridad local, sobre protecciones a los recursos frente a usos indebidos o accesos no permitidos a datos del sistema o de otros usuarios o grupos. Backup y restauracin del sistema: es necesario establecer polticas peridicas (segn importancia de los datos), de copias de seguridad de los sistemas. Hay que establecer periodos de copia que permitan salvaguardar nuestros datos, de fallos del sistema (o factores externos) que puedan provocar prdidas o corrupcin de datos. Automatizacin de tareas rutinarias: muchas de las tareas rutinarias de la administracin o del uso habitual de la mquina pueden ser fcilmente automatizables, ya debido a su simplicidad (y por lo tanto, a la facilidad de repetirlas), como a su temporizacin, que hace que tengan que ser repetidas en periodos concretos. Estas automatizaciones suelen hacerse, bien mediante programacin por lenguajes interpretados de tipo script (shells, Perl, etc.), como por la inclusin en sistemas de temporizacin (crontab, at, ...). Gestin de impresin y colas: los sistemas UNIX pueden utilizarse como sistemas de impresin para controlar una o ms impresoras conectadas al sistema, as como gestionar las colas de trabajo que los usuarios o aplicaciones puedan enviar a las mismas. Accounting (o log) de sistema: para poder verificar el funcionamiento correcto de nuestro sistema, es necesario llevar polticas de log que nos puedan informar de los posibles fallos del sistema o del rendimiento que se obtiene de una aplicacin, servicio o recurso hardware. O bien permitir resumir los recursos gastados, los usos realizados o la productividad del sistema en forma de informe. System performance tunning: tcnicas de optimizacin del sistema para un fin dado. Suele ser habitual que un sistema est pensado para una tarea concreta y que podamos verificar su funcionamiento adecuado (por ejemplo, mediante logs), para examinar sus parmetros y adecuarlos a las prestaciones que se esperan. Personalizacin del sistema: reconfiguracin del kernel. Los kernels, por ejemplo en GNU/Linux, son altamente personalizables, segn las caractersticas que queramos incluir y el

tipo de dispositivos que tengamos o esperemos tener en nuestra mquina, as como los parmetros que afecten al rendimiento del sistema o que consigan las aplicaciones.

7.1 Checklist de Instalacin

A. Sistema Operativo

a. b. c. d. e. f. g. h. i. j. k.

Medio de instalacin Verificacin de licencia Nombre de la mquina Nombre del dominio Profile de seguridad Time Zone Idioma Configuracin de DD / FS Componentes de software Identificacin de red Grficos y video

B. Particiones y File Systems

a.

b.

Particiones Unix Windows File Systems

Filesystem / /stand

Description Root filesystem Boot filesystem

Default vxfs EAFS slice off off

Type

Size

__________ _____(MB) EAFS slice _____(MB) _____(MB)

/dev/swap Swap slice /dev/dump Dump slice /u User filesystem

__________ _____(MB) __________ _____(MB) __________ _____(MB) __________ _____(MB)

Renameable FS/slice off Renameable FS/slice off

/usr/local

Renameable FS/slice off off off off

__________ _____(MB) __________ _____(MB) __________ _____(MB) __________ _____(MB) __________ _____(MB) __________ _____(MB)

/tmp /var/tmp

Temporary filesystem off Temporary filesystem off

/ -- the root filesystem Contains the bulk of the system, including files, commands, log files, and other data. This filesystem is required and can be of type vxfs or HTFS.

/stand -- the boot filesystem Contains all stand-alone programs and text files necessary to boot SCO OpenServer. The filesystem type must be EAFS, and the default size provided should be adequate for your system.

/dev/swap -- the swap slice Used to swap processes into and out of memory. The default size for the swap slice is adequate for most installations. The amount of swap space allocated during the installation is based on disk size, the total amount of memory in the system, and on the total amount of memory used by memfs filesystems.

/dev/dump -- the dump slice Stores a memory image of the running system should the system crash. This slice is not enabled by default, and in most cases is not necessary. If you create a dump slice, it should be as large as your system's RAM. The maximum supported dump slice is 16GB.

If no dump slice is created, a system crash results in dump data being placed in the swap slice. Upon reboot, the system will prompt you to save the dump somewhere else before it is overwritten in swap. Swap space requirements are smaller if a dump slice is defined, but the disk space is used less efficiently.

/u -- user filesystem Contains user accounts and data. This filesystem can be configured as vxfs, HTFS, EAFS, AFS, or S51K. If you do not enable this filesystem, it is created as a subdirectory of the root filesystem.

Administrator-defined -- additional filesystems and slices These entries are administrator-configurable, and are not created if not enabled. Slices can also be allocated for databases, or for future filesystem creation. If you create a slice using these entries, a symbolic link is created using the name you specify that points to the character special device node for the slice. For example, if you create a slice named /database, a symbolic link named /database is created on the root filesystem that points to the character special device for the slice. This makes it easy to identify the correct device node for the slice after installation is complete.

/tmp -- temporary filesystem Contains files that might be removed at any time. This filesystem is not configured by default. Can be of type memfs, in which case all files and directories are automatically flushed during each reboot, or as type vxfs. If you want to make use of SCO OpenServer emergency recovery utilities, you must define /tmp as a memfs filesystem.

/var/tmp -- installation temporary filesystem Used when adding packages to your system. This filesystem must be configured as memfs. All files and directories are automatically flushed during each reboot. If you do not enable this filesystem, /var/tmp is created as a subdirectory of the root filesystem. If both the /tmp and /var/tmp filesystems are configured as memfs, they share the total amount of memory assigned to them. The size of /var/tmp will be indicated as ``Auto''.

7.2 Particiones y Puntos de Montaje Por ejemplo, si la particin /dev/hda5 estuviera montada en /usr, significara que todos los archivos y directorios bajo /usr estaran fsicamente alojados en /dev/hda5. Continuando con el ejemplo, tambin es posible que uno o ms directorios bajo /usr fueran puntos de montaje para otras particiones. Como ejemplo, una particin (digamos /dev/hda7) estara montada en /usr/local, queriendo decir que, por ejemplo, /usr/local/man/whatis residira en /dev/hda7 y no en /dev/hda5. Linux emplea una jerarqua (rbol) de directorios nico. Por tanto la operacin de montaje har que los contenidos de un sistema de ficheros nuevo parezcan los contenidos de un subdirectorio existente de algn sistema de ficheros ya montado Comandos: df h du -sh /etc/fstab Archivos y Directorios mkdir cd rm cp (cp R, cp -rf) mv pwd less tail df (df h, df -Th) fdisk l Enlace simblico ln s original enlace

7.3 Usuarios y Grupos Un usuario Unix representa tanto a una persona (usuario real) como a una entidad que gestiona algn servicio o aplicacin (usuario lgico). Todo usuario definido en el sistema se corresponde con un identificador nico (UID) y con una cuenta, donde se almacenan sus datos personales en una zona de disco reservada. Un grupo es una construccin lgica con un nombre y un identificador (GID) nicos usada para conjuntar varias cuentas en un propsito comn, compartiendo los mismos permisos de acceso en algunos recursos. Cada cuenta debe estar incluida como mnimo en un grupo de usuarios, conocido como grupo primario.

Las caractersticas que definen la cuenta de un usuario son: - Tiene un nombre y un identificador de usuario (UID) nicos en el sistema. - Pertenece a un grupo principal. - Puede pertenecer a otros grupos de usuarios. - Puede definirse una informacin asociada con la persona propietaria de la cuenta. - Tiene asociado un directorio personal para los datos del usuario. - El usuario utiliza en su conexin un determinado intrprete de mandatos, donde podr ejecutar sus aplicaciones y las utilidades del sistema operativo. - Debe contar con una clave de acceso personal y difcil de averiguar por parte de un impostor. - Tiene un perfil de entrada propio, donde se definen las caractersticas iniciales de su entorno de operacin. - Puede tener una fecha de caducidad. - Pueden definirse cuotas de disco para cada sistema de archivos. - Es posible contar con un sistema de auditora que registre las operaciones realizadas por el usuario.

Existen varios usuarios especiales predefinidos en el sistema, normalmente aquellos cuyo UID es inferior a 500. Entre estos usuarios cabe destacar a root, cuyo UID es igual a 0. Este es el administrador del sistema, conocido generalmente como el superusuario. Otros usuarios especiales sirven para asociar niveles de acceso a ciertos servicios del sistema, como por ejemplo los usuarios mail o news. Otro caso destacable es el usuario nobody, normalmente empleado para representar conexiones de red realizadas por usuarios desconocidos o anmimos. Todos estos usuarios se crean durante la instalacin del sistema o cuando se instalan ciertos paquetes y, en principio, no deben modificarse nunca.

En especial el usuario root con UID 0 es el administrador de la mquina, con un control total sobre el sistema. Existe tambin un grupo root con GID 0 con caractersticas administrativas, al que pertenece el citado usuario. Al igual que sucede con los usuarios, existen ciertos grupos que son especiales, en concreto aquellos cuyo GID es menor que 500. De forma anloga a los usuarios especiales, representan servicios, usuarios annimos, etc. No deben, por tanto, ser modificados

Comandos importantes Useradd-> Aadir un usuario

userdel -> Eliminar un usuario (userdel, userdel -r) usermod -> Modificar los atributos de un usuario groupadd -> Aadir un grupo groupdel -> Eliminar un grupo groupmod -> Modificar los atributos de un grupo passwd -> Cambiar la contrasea de un usuario chage -> Gestionar la caducidad de la contrasea gpasswd -> Adiciona usuarios a un grupo (gpasswd a usuario grupo)

Fundamentalmente, deben realizarse las siguientes operaciones previas antes de crear cualquier cuenta: - Crear los distintos grupos de usuarios, uno para cada conjunto de tareas que vayan a ejecutar los usuarios, o uno por cada rol administrativo. - Definir los parmetros globales del sistema, tales como: restricciones para la creacin de claves, mtodo principal de acceso, posibilidad de almacenamiento remoto de las cuentas, etc. - Crear la estructura de directorios bsica para las cuentas, separando los subdirectorios de cada grupo principal. Asignando los permisos adecuados, puede evitarse que usuarios con menor privilegio accedan a zonas reservadas de otros grupos. - Definir listas privadas donde el administrador pueda comprobar la identidad de cada usuario, almacenando los datos bsicos de cada persona y de su cuenta asociada. - Crear los programas para la gestin de las cuentas, generando ficheros de configuracin que automaticen los procesos de creacin, modificacin, revisin, caducidad y borrado de usuarios.

Permisos Normales

Los atributos de un fichero que intervienen en el mecanismo de proteccin son: OwnerUID -> Identificador del usuario propietario del fichero. OwnerGID -> Identificador del grupo propietario del fichero. Bits de permiso Un total de 12 bits que expresan las operaciones del fichero que son permitidas en funcin del proceso que acceda a este fichero. La siguiente tabla, Significado de los bits de permiso en Unix a continuacin muestra el significado de cada uno de estos bits.

Cada usuario tiene un nombre de conexin nico en el sistema y pertenecer a uno o varios grupos de usuarios. El propietario de un fichero o directorio puede seleccionar qu permisos desea activar y cuales deshabilitar. Para comprobarlo de manera ms clara, tmese el primer grupo de valores obtenidos con el mandato ls l, que permitir observar los permisos. Estos 10 caracteres indican: - 1 carcter mostrando el tipo: fichero (-), directorio (d), enlace (l), tubera (p), etc. - 3 caracteres para los permisos del propietario. - 3 caracteres para los permisos de otros usuarios del grupo. - 3 caracteres para los permisos del resto de usuario. Segn el tipo de entrada del directorio, los caracteres de permisos normales pueden variar de significado:

Reglas de Proteccin bsicas Las reglas de proteccin bsicas se activan cuando un proceso notifica al sistema que desea utilizar un determinado fichero. El proceso tambin notifica al sistema qu tipo de operaciones quiere realizar: lectura, escritura o ejecucin. Si el eUID del proceso es 0 se concede el permiso (estamos en el caso en el que el proceso pertenece al superusuario). Si no... Si el eUID del proceso es igual al ownerUID del fichero, se autoriza la operacin si est 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 operacin si est permitida en el grupo de bits 3 al 5, los que corresponden al grupo. Si no... En cualquier otro caso, se autoriza la operacin si est permitida en el grupo de bits 0 al 2, los que corresponden al resto de usuarios. Debe notarse que slo se aplica una regla, aquella que corresponde a la primera condicin que se cumple para los atributos del proceso. Es decir, el sistema determina primero qu grupo de tres bits debe aplicar y despus autoriza (o deniega) la operacin en funcin del tipo de operacin requerida y del estado de dichos tres bits.

Cambio de atributos de proteccin en ficheros Unix establece unas reglas de proteccin especficas para controlar los cambios de cualquier atributo de proteccin de un fichero, dado que dichas modificaciones se consideran operaciones distintas de la de escritura, y por tanto no pueden ser concedidas/denegadas en funcin de los bits de permiso del fichero. En concreto, las reglas establecidas al respecto son las siguientes: a. Cambio en los bits de permiso. Un proceso puede cambiar los bits de permiso de un fichero slo si: el eUID del proceso es 0 (estamos en el caso en el que el proceso pertenece al superusuario), o bien el eUID del proceso es igual al ownerUID del fichero. Es decir, slo el superusuario o el propietario de un fichero pueden modificar sus bits de permiso. b. Cambio de propietario. El cambio de propietario de un fichero puede realizarlo tan slo el superusuario. c. Cambio de grupo propietario. El cambio del grupo propietario de un fichero puede realizarse slo si:

 lo realiza el superusuario, o bien lo realiza el propietario del fichero, siempre que el nuevo ownerGID del fichero sea igual a alguno de los grupos de dicho usuario.

Permisos Especiales Los permisos especiales complementan, potencian la seguridad del sistema y se utilizan para soportar ciertas operaciones especficas

Los bits SETUID y SETGID en ficheros ejecutables Estos bits se emplean para permitir que un programa se ejecute bajo los privilegios de un usuario distinto al que lanza la ejecucin del programa. Su funcionamiento es el siguiente: Si el fichero ejecutable tiene el bit SETUID activo, el eUID del proceso que ejecuta el fichero es hecho igual al ownerUID del fichero. Si el fichero ejecutable tiene el bit SETGID activo, el eGID del proceso que ejecuta el fichero es hecho igual al ownerGID del fichero. Normalmente estos programas pertenecen al superusuario, y permiten a los usuarios ejecutar tareas privilegiadas bajo ciertas condiciones. El cambio de la contrasea de un usuario es un ejemplo de esta tcnica. La existencia de estos ficheros en el sistema de archivos debe ser cuidadosamente supervisada por el superusuario. Muchos de los ataques de seguridad a Unix utilizan estos ficheros para conseguir atentar contra la seguridad del sistema. El bit SETGID en directorios La utilizacin de este bit est orientada a facilitar el trabajo en grupo cuando varios usuarios deben acceder a una coleccin comn de ficheros y directorios. Su funcionamiento es el siguiente: si un directorio, llammosle D, tiene el bit SETGID activo, entonces:

 si se crea un fichero dentro de D, el ownerGID del nuevo fichero es hecho igual al ownerGID del directorio D. si se crea un directorio dentro de D, el ownerGID del nuevo directorio es hecho igual al ownerGID del directorio D y su bit SETGID es activado. Puede observarse que se trata, en esencia, de un mecanismo de herencia. Cuando el bit SETGID no est activo, el ownerGID de un fichero o directorio se toma del eGID del proceso que lo crea. En cambio, utilizando el SETGID, aunque varios usuarios creen ficheros dentro de un directorio, todos ellos pertenecern al menos al mismo grupo, con lo que una utilizacin adecuada de los bits de permiso puede hacer que todos ellos puedan, por ejemplo, leer y modificar dichos ficheros.

Notaciones simblica y octal La orden chmod se utiliza para modificar los permisos de acceso descritos anteriormente y soporta dos tipos de notaciones: simblica y numrica en formato octal. La siguiente tabla muestra la forma de asignar permisos en ambas notaciones.

Ejercicio

7.4 Niveles de Ejecucin

Un servicio es una funcionalidad proporcionada por la mquina. La activacin o parada de servicios se realiza mediante la utilizacin de scripts. La mayora de los servicios estndar, los cuales suelen tener su configuracin en el directorio /etc, suelen controlarse mediante los scripts presentes en /etc/init.d/. En este directorio suelen aparecer scripts con nombres similares al servicio donde van destinados, y se suelen aceptar parmetros de activacin o parada. Se realiza:
/etc/init.d/servicio start arranque del servicio. /etc/init.d/servicio stop parada del servicio. /etc/init.d/servicio restart parada y posterior arranque del servicio.

Cuando un sistema GNU/Linux arranca, primero se carga el kernel del sistema, despus se inicia el primer proceso, denominado init, que es el responsable de ejecutar y activar el resto del sistema, mediante la gestin de los niveles de ejecucin (o runlevels). En el caso del modelo runlevel de System V, cuando el proceso init arranca, utiliza un fichero de configuracin llamado /etc/inittab para decidir el modo de ejecucin en el que va a entrar. En este fichero se define el runlevel por defecto en arranque, y una serie de servicios de terminal por activar para atender la entrada del usuario. Despus, el sistema, segn el runlevel escogido, consulta los ficheros contenidos en /etc/rcn.d, donde n es el nmero asociado al runlevel, en el que se encuentra una lista de servicios por

activar o parar en caso de que arranquemos en el runlevel, o lo abandonemos. Dentro del directorio encontraremos una serie de scripts o enlaces a los scripts que controlan el servicio. Cada script posee un nombre relacionado con el servicio, una S o K inicial que indica si es el script para iniciar (S) o matar (K) el servicio, y un nmero que refleja el orden en que se ejecutarn los servicios. Debian dispone de comandos de gestin de los runlevels como updaterc.d, que permite instalar o borrar servicios arrancndolos o parndolos en uno o ms runlevels; invoke-rc.d, permite las clsicas acciones de arrancar, parar o reiniciar el servicio. El runlevel por defecto en Debian es el 2, el X Window System no se gestiona desde /etc/inittab, sino que existe el gestor (por ejemplo, gdm o kdm) como si fuera un servicio ms del runlevel 2.

7.5 Observar el Estado del Sistema Una de las principales tareas del administrador (root) en su da a da, ser verificar el correcto funcionamiento del sistema y vigilar la existencia de posibles errores o de saturacin de los recursos de la mquina (memoria, discos, etc.). Comando dmesg: da los mensajes del ltimo arranque del kernel. Fichero /var/log/messages: log general del sistema, que contiene los mensajes generados por el kernel y otros daemons. Comando uptime: indica cunto tiempo hace que el sistema est activo. Ficheros /proc: ficheros que utiliza el kernel para almacenar la informacin que gestiona.

Procesos de sistema, o bien procesos asociados al funcionamiento local de la mquina y del kernel, o bien procesos (denominados daemons) asociados al control de diferentes servicios, ya sean locales, o de red, porque estamos ofreciendo el servicio (actuamos de servidor) o estamos recibiendo el servicio (actuamos de clientes). La mayora de estos procesos aparecern asociados al usuario root, aunque no estemos presentes en ese momento como usuarios. Puede haber algunos servicios asociados a otros usuarios de sistema (lp, bin, www, mail, etc.), estos son usuarios virtuales que utiliza el sistema para ejecutar ciertos procesos. Procesos del usuario administrador: en caso de actuar como root, nuestros procesos interactivos o aplicaciones lanzadas tambin aparecern como procesos asociados al usuario root. Procesos de usuarios del sistema: asociados a la ejecucin de sus aplicaciones, ya sea tareas interactivas en modo texto o en modo grfico. Como comandos rpidos y ms tiles podemos utilizar: ps: el comando estndar, lista los procesos con sus datos de usuario, tiempo, identificador de proceso y lnea de comandos usada. Una de las opciones utilizada es ps -ef, pero hay muchas opciones disponibles (ver man). top: una versin que nos da una lista actualizada a intervalos.

 kill: nos permite eliminar procesos del sistema mediante el envo de seales al proceso como, por ejemplo, la de terminacin kill -9 PID, donde indicamos el identificador del proceso. til para procesos con comportamiento inestable o programas interactivos que han dejado de responder.

Logs del Sistema Tanto el kernel como muchos de los daemons de servicios, as como diferentes aplicaciones o subsistemas de GNU/Linux, pueden generar mensajes que vayan a parar a ficheros log, ya sea para tener una traza de su funcionamiento, o bien para detectar errores o advertencias de malfuncionamiento o situaciones crticas. Este tipo de logs son imprescindibles en muchos casos para las tareas de administracin y se suele emplear bastante tiempo de administracin en el procesamiento y anlisis de sus contenidos. Un daemon particular del sistema (importante) es el daemon Syslogd. Este daemon se encarga de recibir los mensajes que se envan por parte del kernel y otros daemons de servicios y los enva a un fichero log que se encuentra en /var/log/messages. ste es el fichero por defecto, pero Syslogd es tambin configurable (fichero /etc/syslog.conf), de manera que se puede generar otro fichero o bien, segn el daemon que enva el fichero, dirigirlo a un log u a otro (clasificar por fuente) o clasificar los mensajes por importancia: alarm, warning, error, critical , etc.

Memoria Respecto a la memoria del sistema, tendremos que tener en cuenta que disponemos: a) de la memoria fsica de la propia mquina, b) memoria virtual, que puede ser direccionada por los procesos. Normalmente, no dispondremos de cantidades demasiado grandes, de modo que la memoria fsica ser menor que el tamao de memoria virtual necesario. Esto obligar a utilizar una zona de intercambio (swap) sobre disco. Esta zona de intercambio (swap) puede implementarse como un fichero en el sistema de archivos, pero es ms habitual encontrarla como una particin de intercambio (llamada de swap), creada durante la instalacin del sistema. En el momento de particionar el disco, se declara como de tipo Linux Swap. Para examinar la informacin sobre memoria tenemos varios mtodos y comandos tiles: Fichero /etc/fstab: aparece la particin swap (si existiese). Con un comando fdisk podemos averiguar su tamao. Comando ps: permite conocer qu procesos tenemos, y con las opciones de porcentaje y memoria usada. Comando top: es una versin ps dinmica actualizable por periodos de tiempo. Puede clasificar los procesos segn la memoria que usan o el tiempo de CPU. Comando free: informa sobre el estado global de la memoria. Da tambin el tamao de la memoria virtual. Comando vmstat: informa sobre el estado de la memoria virtual, y el uso que se le da.

7.6 Tareas Programadas

Cron es el nombre del programa que permite a usuarios Linux/Unix ejecutar automticamente comandos o scripts (grupos de comandos) a una hora o fecha especfica. Es usado normalmente para comandos de tareas administrativas, como respaldos, pero puede ser usado para ejecutar cualquier cosa. Como se define en las pginas del manual de cron (#> man cron) es un demonio que ejecuta programas agendados. En prcticamente todas las distribuciones de Linux se usa la versin Vixie Cron, por la persona que la desarroll, que es Paul Vixie, uno de los grandes gurs de Unix, tambin creador, entre otros sistemas, de BIND que es uno de los servidores DNS ms populares del mundo. Iniciar cron Cron es un demonio (servicio), lo que significa que solo requiere ser iniciado una vez, generalmente con el mismo arranque del sistema. El servicio de cron se llama crond. En la mayora de las distribuciones el servicio se instala automticamente y queda iniciado desde el arranque del sistema, se puede comprobar de varias maneras:
#> /etc/rc.d/init.d/crond status #> /etc/init.d/crond status Usa cualquiera de los dos dependiendo de tu distro crond (pid 507) is running... o si tienes el comando service instalado: #> service crond status crond (pid 507) is running... se puede tambin revisar a travs del comando ps: # ps -ef | grep crond si por alguna razn, cron no esta funcionando: #> /etc/rc.d/init.d/crond start Starting crond: [ OK ]

Si el servicio no estuviera configurado para arrancar desde un principio, bastara con agregarlo con el comando chkconfig:
#> chkconfig --level 35 crond on

Con esto lo estaras agregando al nivel de ejecucin 3 y 5, para que inicie al momento del arranque del sistema. Usando cron Hay al menos dos maneras distintas de usar cron: La primera es en el directorio etc, donde muy seguramente encontrars los siguientes directorios:

cron.hourly cron.daily cron.weekly cron.monthly Si se coloca un archivo tipo script en cualquiera de estos directorios, entonces el script se ejecutar cada hora, cada da, cada semana o cada mes, dependiendo del directorio. Para que el archivo pueda ser ejecutado tiene que ser algo similar a lo siguiente:
#!/bin/sh #script que genera un respaldo cd /usr/documentos tar czf * respaldo cp respaldo /otra_directorio/.

Ntese que la primera lnea empieza con #!, que indica que se trata de un script shell de bash, las dems lneas son los comandos que deseamos ejecute el script. Este script podra nombrarse por ejemplo respaldo.sh y tambin debemos cambiarle los permisos correspondientes para que pueda ser ejecutado, por ejemplo:
#> chmod 700 respaldo.sh #> ls -l respaldo.sh -rwx------ 1 root root 0 Jul 20 09:30 respaldo.sh

La "x" en el grupo de permisos del propietario (rwx) indica que puede ser ejecutado. Si este script lo dejamos en cron.hourly, entonces se ejecutar cada hora con un minuto de todos los das. Como segundo modo de ejecutar o usar cron es a travs de manipular directamente el archivo/etc/crontab. En la instalacin por defecto de varias distribuciones Linux, este archivo se ver a algo como lo siguiente:
#> cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root 02 4 * * * root 22 4 * * 0 root 42 4 1 * * root run-parts run-parts run-parts run-parts /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Las primeras cuatro lneas son variables que indican lo siguiente: SHELL es el 'shell' bajo el cual se ejecuta el cron. Si no se especifica, se tomar por defecto el indicado en la lnea /etc/passwd correspondiente al usuario que este ejecutando cron. PATH contiene o indica la ruta a los directorios en los cuales cron buscar el comando a ejecutar. Este path es distinto al path global del sistema o del usuario. MAIL TO es a quien se le enva la salida del comando (si es que este tiene alguna salida). Cron enviar un correo a quien se especifique en este variable, es decir, debe ser un usuario vlido del sistema o de algn otro sistema. Si no se especifica, entonces cron enviar el correo al usuario propietario del comando que se ejecuta. HOME es el directorio raz o principal del comando cron, si no se indica entonces, la raz ser la que se indique en el archivo /etc/passwd correspondiente al usuario que ejecuta cron. Los comentarios se indican con # al inicio de la lnea. Despus de lo anterior vienen las lneas que ejecutan las tareas programadas propiamente. No hay lmites de cuantas tareas pueda haber, una por rengln. Los campos (son 7) que forman estas lneas estn formados de la siguiente manera:
Minuto Hora DiaDelMes Mes DiaDeLaSemana Usuario Comando

Campo Minuto

Descripcin Controla el minuto de la hora en que el comando ser ejecutado, este valor debe de estar entre 0 y 59. Controla la hora en que el comando ser ejecutado, se especifica en un formato de 24 horas, los valores deben estar entre 0 y 23, 0 es medianoche.

Hora

Da del Mes

Da del mes en que se quiere ejecutar el comando. Por ejemplo se indicara 20, para ejecutar el comando el da 20 del mes. Mes en que el comando se ejecutar, puede ser indicado numricamente (1-12), o por el nombre del mes en ingls, solo las tres primeras letras. Da en la semana en que se ejecutar el comando, puede ser numrico (0-7) o por el nombre del da en ingls, solo las tres primeras letras. (0 y 7 = domingo) Usuario que ejecuta el comando. Comando, script o programa que se desea ejecutar. Este campo puede contener mltiples palabras y espacios.

Mes

Da de la semana Usuario Comando

Un asterisco * como valor en los primeros cinco campos, indicar inicio-fin del campo, es decir todo. Un * en el campo de minuto indicar todos los minutos. Para entender bien esto de los primeros 5 campos y el asterisco usar mejor varios ejemplos: Ejemplo 01 * * * * 15 8 * * * 15 20 * * * 00 5 * * 0 * 5 * * Sun 45 19 1 * * 01 * 20 7 * 10 1 * 12 1 00 12 16 * Wen 30 9 20 7 4 30 9 20 7 * 20 * * * 6 20 * * 1 6 Descripcin Se ejecuta al minuto 1 de cada hora de todos los das A las 8:15 a.m. de cada da A las 8:15 p.m. de cada da A las 5 a.m. todos los domingos Cada minuto de 5:00a.m. a 5:59a.m. todos los domingos A las 7:45 p.m. del primero de cada mes Al minuto 1 de cada hora del 20 de julio A la 1:10 a.m. todos los lunes de diciembre Al medioda de los das 16 de cada mes y que sea Mircoles A las 9:30 a.m. del dia 20 de julio y que sea jueves A las 9:30 a.m. del dia 20 de julio sin importar el da de la semana Al minuto 20 de cada hora de los sbados Al minuto 20 de cada hora de los sbados de enero

Tambin es posible especificar listas en los campos. Las listas pueden estar en la forma de 1,2,3,4 o en la forma de 1-4 que sera lo mismo. Cron, de igual manera soporta incrementos en las listas, que se indican de la siguiente manera:
Valor o lista/incremento

De nuevo, es ms fcil entender las listas e incrementos con ejemplos: Ejemplo 59 11 * 1-3 1,2,3,4,5 45 * 10-25 * 6-7 Descripcin A las 11:59 a.m. de lunes a viernes, de enero a marzo Al minuto 45 de todas las horas de los das 10 al 25 de todos los meses y que el da sea sbado o domingo En el minuto 10, 30 y 50 de todas las horas de los das lunes, mircoles y viernes Cada quince minutos de las 10:00a.m. a las 2:00p.m. Todos los minutos de las 12 del da, en los das 1,3,5,7 y 9 de febrero y agosto. (El incremento en el tercer campo es de 2 y comienza a partir del 1)

10,30,50 * * * 1,3,5 */15 10-14 * * *

* 12 1-10/2 2,8 *

0 */5 1-10,15,20-23 * Cada 5 horas de los das 1 al 10, el da 15 y del da 20 al 23 de cada mes 3 y que el da sea mircoles Cada 3 minutos empezando por el minuto 3 (3,6,9, etc.) de las horas 2,6,10, etc (cada 4 horas empezando en la hora 2) del da 2 de febrero y que sea martes

3/3 2/4 2 2 2

Como se puede apreciar en el ltimo ejemplo la tarea cron que estuviera asignada a ese rengln con esos datos, solo se ejecutara si se cumple con los 5 campos (AND). Es decir, para que la tarea se ejecute tiene que ser un martes 2 de febrero a las 02:03. Siempre es un AND booleano que solo resulta verdadero si los 5 campos son ciertos en el minuto especfico. El caso anterior deja claro entonces que: El programa cron se invoca cada minuto y ejecuta las tareas que sus campos se cumplan en ese preciso minuto. Incluyendo el campo del usuario y el comando, los renglones de crontab podran quedar entonces de la siguiente manera:
0 22 * * * root /usr/respaldodiario.sh 0 23 * * 5 root /usr/respaldosemanal.sh 0 8,20 * * * sergio mail -s "sistema funcionando" sgd@ejemplo.com

Las dos primeras lneas las ejecuta el usuario root y la primera ejecuta a las 10 de la noche de todos los das el script que genera un respaldo diario. La segunda ejecuta a las 11 de la noche de todos los viernes un script que genera un respaldo semana. La tercera lnea la ejecuta el usuario Sergio y se ejecutara a las 8 de la maana y 8 de la noche de todos los da y el comando es enviar un correo a la cuenta sgd@ejemplo.com con el asunto "sistema funcionando", una manera de que un administrador este enterado de que un sistema remoto esta activo en las horas indicadas, sino recibe un correo en esas horas, algo anda mal. Siendo root, es posible entonces, modificar directamente crontab:

#> vi /etc/crontab

Ejecutando Cron con mltiples usuarios, comando crontab

Linux es un sistema multiusuario y cron es de las aplicaciones que soporta el trabajo con varios usuarios a la vez. Cada usuario puede tener su propio archivo crontab, de hecho el/etc/crontab se asume que es el archivo crontab del usuario root, aunque no hay problema que se incluyan otros usuarios, y de ah el sexto campo que indica precisamente quien es el usuario que ejecuta la tarea y es obligatorio en /etc/crontab. Pero cuando los usuarios normales (e incluso root) desean generar su propio archivo de crontab, entonces utilizaremos el comando crontab. En el directorio /var/spool/cron (puede variar segn la distribucin), se genera un archivo cron para cada usuario, este archivo aunque es de texto, no debe editarse directamente. Se tiene entonces, dos situaciones, generar directamente el archivo crontab con el comando:
$> crontab -e

Con lo cual se abrir el editor por default (generalemente vi) con el archivo llamado crontab vacio y donde el usuario ingresar su tabla de tareas y que se guardar automticamente como /var/spool/cron/usuario. El otro caso es que el usuario edite un archivo de texto normal con las entradas de las tareas y como ejemplo lo nombre 'mi_cron', despus el comando $> crontab mi_cron se encargar de establecerlo como su archivo cron del usuario en /var/spool/cron/usuario:
$> vi mi_cron # borra archivos de carpeta compartida 0 20 * * * rm -f /home/sergio/compartidos/* # ejecuta un script que realiza un respaldo de la carpeta documentos el primer da de cada mes 0 22 1 * * /home/sergio/respaldomensual.sh # cada 5 horas de lun a vie, se asegura que los permisos sean los correctos en mi home 1 *5 * * * 1-5 chmod -R 640 /home/sergio/* :wq (se guarda el archivo) $> ls mi_cron $> crontab mi_cron (se establece en /var/spool/cron/usuario)

Resumiendo lo anterior y considerando otras opciones de crontab:

$> crontab archivo.cron del usuario) $> crontab -e podr crear o editar el $> crontab -l tareas de cron) $> crontab -r (establecer el archivo.cron como el crontab (abrir el editor preestablecido donde se archivo crontab) (lista el crontab actual del usuario, sus (elimina el crontab actual del usuario)

En algunas distribuciones cuando se editan crontabs de usuarios normales es necesario reiniciar el servicio para que se puedan releer los archivos de crontab en /var/spool/cron.
#> service crond restart

Controlando el acceso a cron Cron permite controlar que usuarios pueden o no pueden usar los servicios de cron. Esto se logra de una manera muy sencilla a travs de los siguientes archivos:

/etc/cron.allow /etc/cron.deny Para impedir que un usuario utilice cron o mejor dicho el comando crontab, basta con agregar su nombre de usuario al archivo /etc/cron.deny, para permitirle su uso entonces sera agregar su nombre de usuario en etc/cron.allow, si por alguna razn se desea negar el uso de cron a todos los usuarios, entonces se puede escribir la palabra ALL al inicio de cron.deny y con eso bastara.
#> echo ALL >>/etc/cron.deny o para agregar un usuario mas a cron.allow #> echo juan >>/etc/cron.allow

Si no existe el archivo cron.allow ni el archivo cron.deny, en teora el uso de cron esta entonces sin restricciones de usuario. Si se aaden nombres de usuarios en cron.allow, sin crear un archivo cron.deny, tendr el mismo efecto que haberlo creado con la palabra ALL. Esto quiere decir que una vez creado cron.allow con un solo usuario, siempre se tendrn que especificar los dems usuarios que se quiere usen cron, en este archivo.

7.7 Shells El trmino genrico shell se utiliza para denominar un programa que sirve de interfaz entre el usuario y el ncleo (kernel ) del sistema GNU/Linux. El shell es lo que los usuarios ven del sistema. El resto del sistema operativo permanece esencialmente oculto a sus ojos. El shell est escrito de la misma forma que un proceso (programa) de usuario; no est integrado en el kernel, sino que se ejecuta como un programa ms del usuario.

Los shells suelen proporcionar los tres mecanismos siguientes: 1) Redireccin: dado que los dispositivos de E/S y los ficheros se tratan de la misma manera en UNIX, el shell los trata a todos simplemente como ficheros. Desde el punto de vista del usuario, se pueden redefinir los descriptores de los ficheros para que los flujos de datos de un descriptor vayan a cualquier otro descriptor; a esto se le llama redireccin. Por ejemplo, nos referiremos a la redireccin de los descriptores 0 o 1 como a la redireccin de la E/S estndar. Por ejemplo: comando op fichero donde op puede ser: < : recibir entrada del fichero. > : enviar salida al fichero. >>: indica que se aada la salida (por defecto, con > se crea de nuevo el fichero).
grep l #include /usr/include/*.h > ListaArchivos

Para redirigir el error estndar se utiliza >& o 2>

2) Tuberas (pipes): la salida estndar de un programa puede usarse como entrada estndar de otro por medio de pipes. Varios programas pueden ser conectados entre s mediante pipes para formar lo que se denomina un pipeline. comando1 | comando2 | comando3
grep l #include /usr/include/*.h | sort > ListaOrdenada

3) Concurrencia de programas de usuario: los usuarios pueden ejecutar varios programas simultneamente, indicando que su ejecucin se va a producir en segundo plano (background), en trminos opuestos a primer plano (o foreground), donde se tiene un control exclusivo de pantalla. Otra utilizacin consiste en permitir trabajos largos en segundo plano cuando interactuamos con el shell con otros programas en primer plano. Uso del &
find . name '*.so' print | sort >ListaOrdenada &

Shells disponibles a) El shell Bash (bash). El shell Linux por defecto. b) El shell Bourne (sh). ste ha sido desde siempre el shell estndar UNIX, y el que todos los UNIX poseen en alguna versin. Normalmente, es el shell por defecto del administrador (root). En GNU/Linux suele ser el Bash, una versin mejorada del Bourne. El sh fue creado por Stephen Bourne en AT&T a finales de los setenta. El indicador (o prompt) por defecto suele ser un $ (en root un #). c) El shell Korn (ksh). Es un superconjunto del Bourne (se mantiene cierta compatibilidad), escrito en AT&T por David Korn (a mediados de los ochenta), en el cual se hizo cierta mezcla de funcionalidades del Bourne y del C, ms algn aadido. El prompt por defecto es el $. d) El shell C (csh). Fue desarrollado en la Universidad de Berkeley por Bill Joy a finales de los setenta y tiene unos cuantos aadidos interesantes al Bourne, como un histrico de comandos, alias, aritmtica desde la lnea de comandos, completa nombres de ficheros y control de trabajos en segundo plano. El prompt por defecto para los usuarios es %. Los usuarios UNIX suelen preferir este shell como interactivo, pero los administradores UNIX prefieren utilizar el Bourne, ya que los scripts suelen quedar ms compactos, y la ejecucin suele ser ms rpida. Por otro lado, una ventaja de los scripts en C shell es que, como su nombre indica, su sintaxis est basada en el lenguaje C.

Una forma rpida de conocer bajo qu shell nos encontramos como usuarios es mediante la variable $SHELL, desde una lnea de comandos con la instruccin: echo $SHELL Algunas cuestiones que encontraremos comunes a todos los shells:

 Todos permiten la escritura de shell scripts que son luego interpretados ejecutndolos bien por el nombre (si el fichero tiene permiso de ejecucin) o bien pasndolo como parmetro al comando del shell. Los usuarios del sistema tienen un shell por defecto asociado a ellos. Esta informacin se proporciona al crear las cuentas de los usuarios. El administrador asigna un shell a cada usuario, o bien si no se asigna el shell por defecto (bash en GNU/Linux). Esta informacin se guarda en el fichero de passwords en /etc/passwd. Cada shell es en realidad un comando ejecutable, normalmente presente en los directorios /bin en GNU/Linux (o /usr/bin). Se pueden escribir shell scripts en cualquiera de ellos, pero ajustndose a la sintaxis de cada uno, que es normalmente diferente (a veces hay slo pequeas diferencias). La sintaxis de las construcciones, as como los comandos internos, estn documentados en la pgina man de cada shell. Cada shell tiene algunos ficheros de arranque asociados (ficheros de inicializacin), cada usuario puede adaptarlos a sus necesidades, incluyendo cdigo, variables, caminos (path), ... La potencia en la programacin est en combinar la sintaxis de cada shell (de sus construcciones), con los comandos internos de cada shell, y una serie de comandos UNIX muy utilizados en los scripts, como por ejemplo los grep, sed, awk. Si como usuarios estamos utilizando un shell determinado, nada impide arrancar una copia nueva de shell (lo llamamos subshell), ya sea el mismo u otro diferente. Sencillamente, lo invocamos por el nombre del ejecutable, ya sea el sh, bash, csh o ksh. Tambin cuando ejecutamos un shell script se lanza un subshell con el Shell que corresponda para ejecutar el script pedido.

Algunas diferencias bsicas entre ellos: a) Bash es el shell por defecto en GNU/Linux (si no se especifica lo contrario al crear la cuenta del usuario). En otros sistemas UNIX suele ser el shell Bourne (sh). Bash es compatible con sh, y adems incorpora algunas caractersticas de los otros shells, csh y ksh. b) Ficheros de arranque: sh, ksh tienen .profile (en la cuenta del usuario, y se ejecuta en el login del usuario) y tambin ksh suele tener un .kshrc que se ejecuta a continuacin, csh utiliza . login (se ejecuta al iniciarse el login del usuario una sola vez), .logout (antes de la salida de la sesin del usuario) y .cshrc (parecido al .profile, en cada subshell C que se i nicia). Y Bash utiliza el .bashrc y el .bash_profile. Adems, el administrador puede colocar variables y caminos comunes en el fichero /etc/profile que se ejecutar antes que los ficheros que tenga cada usuario. Los ficheros de inicializacin de los shell se ponen en la cuenta del usuario al crearla (normalmente se copian del directorio /etc/skel), donde el administrador puede dejar unos esqueletos de los ficheros preparados c) Los scripts de configuracin del sistema o de servicios suelen estar escritos en shell Bourne (sh), ya que la mayora de los UNIX as los tenan. En GNU/Linux tambin nos podemos encontrar con algunos en Bash.

d) Podemos identificar en qu shell se ejecuta el script mediante el comando file, por ejemplo file <nombrescript>. O bien examinando la primera lnea del script, que suele ser: #!/bin/nombre, donde nombre es bash, sh, csh, ksh ... Esta lnea le dice, en el momento de ejecutar el script, qu shell hay que utilizar a la hora de interpretarlo (o sea, qu subshell hay que lanzar para ejecutarlo). Es importante que todos los scripts la contengan, ya que si no, se intentarn ejecutar en el shell por defecto (Bash en nuestro caso), y la sintaxis puede no corresponder, causando muchos errores sintcticos en la ejecucin.

Secuencia de comandos en Shell

Se pueden colocar secuencias de comandos dentro de un archivo para que dichos comandos se ejecuten en cualquier momento. Es lo mismo que hacer un programa, con la diferencia de que los comandos sern interpretados es decir, no se compila el fichero. El shell posee muchas caractersticas de un lenguaje de programacin normal, como variables e instrucciones de control. Casi todas las secuencias de comandos empiezan con #!/bin/sh. Los primeros caracteres indican al sistema que dicho archivo es una secuencia de comandos, y /bin/sh inicia el shell bash. Esto es as ya que se puede indicar que el programa se ejecute con otro Shell (tcsh, ksh, etc.) o programa intrprete. Por ejemplo, si se crea un programa en perl es necesario iniciar con la lnea: #!/usr/bin/perl. Una vez iniciado el shell indicado, ste ejecuta una a una las lneas restantes del archivo. Las secuencias de comandos de shell deben tener encendido su bit de permiso de ejecucin. Variables Cuando se estn ejecutando una secuencia de comandos, ya estn definidas algunas variables tiles: $$: El identificador del proceso que se est ejecutando. $0: El nombre de la secuencia de comandos. $1 hasta $9: Los primeros 9 argumentos de lnea de comandos que se pasan a la secuencia de comandos. $#: El nmero de parmetros de lnea de comandos que se pasan a la secuencia de comandos.

Estructuras de control bash soporta la mayora de las instrucciones de control utilizadas en los lenguajes de programacin comunes, aunque la sintaxis cambia un poco. A continuacin se presenta un ejemplo de una secuencia de comandos en las que se demuestra el uso de casi todas las instrucciones de control disponibles en bash:
#!/bin/bash #el nombre de este archivo debe ser programa.sh MAX=9

#Uso de la instruccin if if [ $# gt $MAX ] then echo "$0: $MAX o menos argumentos requeridos" exit 1 fi #Imprimir los dos primeros argumentos echo "$0 : El argumento 1 es $1" echo "$0 : El argumento 2 es $2" echo "" #Uso del for for i in $1 $2 do ls l $i; done echo "" #Uso de la instruccin case echo "ejemplo case" for i do case "$i" in archivo1) echo "caso a";; archivo2) echo "caso b";; *) echo "Este es el famoso default: $i";; esac done echo "" #Uso de la instruccin whiledone echo "ejemplo whiledone" i=1; #mientras que $i sea menor al nmero de argumentos while [ $i le $# ] do echo $i; i=$[$i+1]; done echo ""; #Uso de la instruccin untildone echo "ejemplo until" i=1; #hasta que $i sea mayor al nmero de argumentos until [ $i gt $# ] do echo "$i argumentos se balanceaban sobre la tela de una araa"; i=$[$i+1]; done echo "" exit 0

La lnea "MAX=9" establece una variable llamada MAX y le asigna el valor entero 9. Luego, el bloque if-fi comprueba si el nmero de argumentos es mayor de 9, en cuyo caso imprime un mensaje de error y aborta el programa. Las instrucciones echo se utilizan para imprimir en pantalla. El shell entiende que cuando se presenta algo como: echo "algo $1", no debe imprimir "algo $1" sino "algo primerargumento", es decir, reconoce las variables dentro de cadenas de texto (como perl o php).

Las siguientes agrupaciones de comandos muestran el uso de las instrucciones de control disponibles en shell. La primera de ellas es el for-done (equivalente a for en C/C++ o Java). Es interesante ver que adems de imprimir valores con echo, es posible utilizar comandos del shell, en este caso se toman los dos primeros argumentos y se utilizan para completar el comando ls -l. Despus, en el uso del case (equivalente al switch-case de C o Java), se puede observar el uso de esta instruccin de seleccin. En el ejemplo de while, se imprime la cantidad de argumentos proporcionados al programa; igualmente acta la instruccin until. Tambin es posible utilizar comentarios con el signo numeral (#) Ejecucin del programa de ejemplo: ./programa.sh archivo1 archivo2 arg3 arg4 arg5
Ejercicios -

Ejercicio 1 #!/bin/bash echo Hola Mundo

Comparacin de cadenas

Comparacin de valores numricos

Utilidades para archivos:

Ejercicio asignacin de men a un usuario: 1. Se crea un usuario nuevo: $ useradd igaleano 2. Se asigna una clave al nuevo usuario $ passwd igaleano 3. Se verifica el home directory y se cambia el Shell para el usuario en /etc/passwd $ vi /etc/passwd
igaleano::1001:1002::/home/igaleano:/bin/bash

4. Se crea el directorio por defecto para el usuario /home/igaleano $ cd /home $ mkdir igaleano 5. Como el directorio se crea con root, es necesario cambiar el propietario al nuevo usuario igaleano: $ chown igaleano /home/igaleano 6. Dado que el usuario est recin creado, es necesario copiar el archivo .profile de otro usuario a la carpeta por defecto del nuevo. Este archivo es el que se ejecuta inmediatamente despus de la autenticacin del usuario. Es un archivo oculto por lo que inicia con . $ cp /home/utp/.profile /home/igaleano 7. Se copia el shell script generado a la carpeta por defecto del usuario $ cp /home/utp/menu.sh /home/igaleano 8. Se cambian los permisos del archive .profile y del shell menu.sh. Adicional, con el mismo cambio de permisos nos aseguramos que el Shell script tenga permisos de ejecucin para el usuario: $ cd /home/igaleano $ chmod 744 .profile $ chmod 744 menu.sh $ chown igaleano .profile $ chown igaleano menu.sh

9. Se modifica el .profile del usuario nuevo insertando la ejecucin del menu.sh en la ltima lnea: $ vi /home/igaleano/.profile [Esc] : $ # Para ir al final del archivo [Esc] o # Para insertar una nueva lnea ./menu.sh [Esc] : wq # Para guardar y salir 10.Se prueba cambiando de usuario. Debera aparecer el men creado en el Shell script: $ su igaleano Se digita la clave Debe aparecer el men creado Bienvenido al Men de Administrador 1) Salir 2) Reiniciar 3) Empaquetar /home/utp 7.8 Empaquetado y compresin de archivos con tar y gzip

Comprimir un archivo, agrupar varios en uno solo o ver qu contiene un archivo comprimido son tareas que se utilizan frecuentemente para hacer copias de seguridad, transportar archivos de un sitio a otro, etc. Aunque existen multitud de programas diferentes que permiten hacer esta clase de operaciones, generalmente en todos los sistemas UNIX se encuentra la herramienta tar. Este programa permite manipular de cualquier forma uno o varios archivos para comprimirlos, agruparlos, etc. Aunque con el mismo tar se pueden comprimir archivos, la aplicacin en s misma no es de compresin. para ello utiliza programas externos como el gzip. $ gzip archivo1 archivos.gz
$ gunzip archivos.gz

Se debe indicar que si se desea crear un nico archivo con mltiples componentes que puedan extraerse posteriormente de forma independiente, es recomendable utilizar tar, pues gzip est pensado para complementar a tar, no para sustituirlo.

Empaquetar Archivos La orden tar se utiliza para empaquetar un grupo de archivos en un nico archivo, que tiene la estructura de un encabezado de 512 bytes y el archivo, tantas veces como archivos se empaqueten.

Se utiliza para almacenar jerarquas de directorios, tener copias de seguridad y ahorrar espacio. Es la forma habitual de suministrar parches y distribuciones de sistemas. La sintaxis de la orden tar es:
tar [opciones] [archivos] Las opciones de tar pueden ir o no precedidas del c r t f x v z Crea un nuevo paquete para almacenar los archivos. Graba archivos al final del paquete Enumera el contenido del paquete. Especifica el archivo en el que se crear el paquete Extrae los archivos del paquete Utiliza en modo verboso Comprime utilizando gzip

$ tar cvzf misPracticas.tgz mispracticas $ tar xvzf misPracticas.tgz

7.9 Uso de Alias [No visto en clase pero es til] Un alias es un nombre ms corto (seudnimo) para un comando que se usa muy a menudo. El mecanismo de alias permite adaptar el comportamiento de las rdenes LINUX cuando se ejecutan. Es similar a la capacidad de definicin de macros en otros lenguajes. En Bash, la orden alias, se encarga de crear un seudnimo para una orden. alias [nombre_alias]=[definicin_orden] Asocia un nombre_alias con la definicin_orden. $bash$ alias dir=ls l # asigna a ls l el nombre de dir Cuando ya no nos es til la definicin de un alias, se puede borrar sin salir del sistema. La sintaxis es unalias nombre_alias

donde nombre_alias es el nombre del alias que se va a borrar