  CODA COMO
  Iaki Fernndez Villanueva (autor y maquetador Linuxdoc-
  SGML), iniaki@mail.com
  Javier Ruiz Gonzlez, javierrg77@yahoo.es
  Josu Abajo Marn, jabajo00@yahoo.es
  v1.0, Mayo 2000

  El objetivo de este documento es mostrar las caractersticas bsicas
  del Sistema de Ficheros Distribuido Coda. Tambin trata su instalacin
  y configuracin en un PC con Linux (Debian y Red Hat). No es una tra
  duccin de _T_h_e _C_o_d_a _H_o_w_t_o (http://coda.cs.cmu.edu/doc/html/coda-
  howto.html), sino de un COMO redactado por sus autores que tambin
  incluye traducciones de otros documentos citados en la bibliografa.
  ______________________________________________________________________

  ndice general


  1. Copyright y propiedad intelectual
  2. Renuncia de responsabilidad
  3. Dnde obtener este COMO
  4. Introduccin
     4.1 El cliente Coda
     4.2 Las operaciones desconectadas
     4.3 Volmenes, servidores y replicaciones.
     4.4 Aplicaciones de Coda
     4.5 Desventajas

  5. Instalacin y configuracin
     5.1 Dnde obtener los binarios de Coda
     5.2 Sincronizacin de los servidores
     5.3 Instalacin de los Servidores
        5.3.1 Servidor SCM en Red Hat
        5.3.2 Servidor no SCM en Red Hat
        5.3.3 Debian
     5.4 Configuracin de los servidores Coda
        5.4.1 Creacin de volmenes
        5.4.2 Eliminacin de volmenes
        5.4.3 Ficheros de configuracin del servidor
     5.5 Instalacin de los clientes Coda
        5.5.1 Mdulo del ncleo Coda
        5.5.2 Instalacin de los binarios
           5.5.2.1 Red Hat
           5.5.2.2 Debian
        5.5.3 Desinstalacin
           5.5.3.1 Servidor Red Hat
           5.5.3.2 Servidor Debian
           5.5.3.3 Cliente (Red Hat y Debian)

  6. Administracin
     6.1 Creacin de cuentas de usuario
     6.2 Acceso a las cuentas y rdenes
        6.2.1 Comando cfs
        6.2.2 Reparacin de conflictos
           6.2.2.1 Conflictos servidor-servidor
           6.2.2.2 Conflicto local-global
        6.2.3 Otras rdenes
     6.3 Herramientas de monitorizacin

  7. Pruebas realizadas y resultados
  8. Bibliografa
  9. Agradecimientos
  10. Anexo: El INSFLUG



  ______________________________________________________________________

  11..  CCooppyyrriigghhtt yy pprrooppiieeddaadd iinntteelleeccttuuaall


  Este COMO es Copyright  2000 Iaki Fernndez Villanueva & Javier Ruz
  Martnez & Josu Abajo Marn. Todos los derechos reservados.

  Este trabajo puede ser reproducido en su totalidad o en parte, tanto
  de forma impresa como electrnica, sujeto a las siguientes
  condiciones:


  1. La notificacin del copyright y esta licencia debe preservarse
     completa en todas las copias, tanto completas como parciales.

  2. Cualquier traduccin o trabajo derivado debe de ser aprobado por
     los autores por escrito antes de su distribucin.

  3. Si se distribuye el Trabajo parcialmente, deben de incluirse
     instrucciones de dnde obtener la versin completa original (en
     forma impresa o electrnica), as como los medios para conseguirla.

  4. Pueden ser reproducidas pequeas porciones como ilustraciones para
     revistas o citas para otros trabajos sin esta notificacin de
     permiso si se cita apropiadamente su procedencia.


  22..  RReennuunncciiaa ddee rreessppoonnssaabbiilliiddaadd


  Este documento intenta ser una introduccin a la instalacin y
  configuracin de Coda as como de su funcionamiento. Los autores de
  este documento NO SE HACEN RESPONSABLES DE NINGN DAO PRODUCIDO POR
  ACCIONES CON BASE EN ESTE DOCUMENTO, el cual puede contener erratas
  y/o fallos.


  33..  DDnnddee oobbtteenneerr eessttee CCOOMMOO


  Puede obtener la ltima versin de este documento en el sitio web del
  proyecto Insflug http://www.insflug.org


  44..  IInnttrroodduucccciinn


  Un sistema de ficheros distribuido almacena ficheros en uno o ms
  ordenadores sincronizados entre s llamados servidores, y los hace
  accesibles a otros ordenadores llamados clientes, para quienes el
  acceso a estos ficheros es transparente. La principal ventaja es la
  comparticin de ficheros y su gestin centralizada desde los
  servidores (como por ejemplo el control de acceso y la gestin de
  copias de seguridad). Esta comparticin de ficheros es especialmente
  til para grupos de trabajo que comparten documentos, aunque tambin
  es posible compartir software, como por ejemplo, un procesador de
  textos.

  Un buen sistema de ficheros distribuido debe tener en cuenta cosas tan
  importantes como la latencia de la red, los posibles cuellos de
  botella y sobresaturacin del servidor, la seguridad de datos
  comprometidos y los posibles fallos de red y servidores. Evidentemente
  todo esto toma especial importancia en el caso de que el sistema
  funcione bajo una _W_A_N.

  El Sistema de Ficheros Distribuido Coda es el sucesor de _A_n_d_r_e_w _F_i_l_e
  _S_y_s_t_e_m (AAFFSS) y es un desarrollo de la Universidad de Carnegie-Mellon
  como ejemplo de entorno de trabajo distribuido. Coda destaca sobre AFS
  por permitir la Computacin Mvil (trabajar en modo desconectado),
  soportar mejor la tolerancia a fallos del sistema (por ejemplo cada
  de los servidores o fallos de la red) y por disponer de tcnicas de
  replicacin de los servidores. Al ser gratuito, su cdigo fuente est
  disponible (la licencia de Coda se puede encontrar en
  ftp://ftp.coda.cs.cmu.edu/pub/coda/LICENSE) y est diseado para
  trabajar tanto en _L_A_N como en _W_A_N.

  Coda se implement originalmente en MMaacchh 22..66 y ha sido portado
  recientemente a LLiinnuuxx, NNeettBBSSDD y FFrreeeeBBSSDD.  Tambin se est portando a
  Windows95/NT, pero el estado de desarrollo es menor.

  La Computacin Mvil [MAR99] permite por ejemplo que un usuario pueda
  trabajar con su porttil enganchado a la red Coda, llevrselo a su
  casa para trabajar con l, y cuando vuelva a conectarse a la red los
  datos se reintegrarn automticamente, sin que el usuario se percate
  de ello (entendiendo por reintegrar el proceso en el que tras una
  reconexin se ponen al da en los servidores los cambios realizados
  por el cliente durante la desconexin).


  44..11..  EEll cclliieennttee CCooddaa

  [BRA98] Bajo el directorio /coda el cliente monta un sistema de
  ficheros de tipo Coda, desde donde se accedern a todos los ficheros
  del Sistema Coda. Un cliente se conecta a todo el sistema Coda y no a
  un servidor individual como ocurre en NFS, donde existe un nico
  directorio o punto de montaje por servidor. La ventaja de un slo
  punto de montaje reside en que todos los clientes pueden ser
  configurados de forma idntica, y en que los usuarios siempre vern el
  mismo rbol de ficheros. Con NFS los clientes necesitan actualizar la
  lista de servidores y la ruta de directorios que exportan en
  /etc/fstab, mientras que en Coda los clientes slo deben acceder al
  directorio /coda para ver los cambios incluso cuando se aaden nuevos
  servidores. En las dos siguientes figuras se aprecia la diferencia
  funcional entre un sistema NFS y un sistema Coda [MAR99]:



  Sistema de Ficheros Distribuido, entorno Cliente-Servidor NFS:

                                  RED
                +---------+     +-----+
                |         |     |     |
                |Servidor |<----|-----|------->Cliente 1
                |  NFS 1  |<----|-----|--+
                |         |     |     |  |
                +---------+     |     |  +---->Cliente 2
                                |     |  |
                                |     |  |
                +---------+     |     |  |
                |         |     |     |  |
                |Servidor |<----|-----|--+
                |  NFS 2  |<----|-----|------->Cliente 3
                |         |     |     |
                +---------+     +-----+

  Sistema de Ficheros Distribuido, entorno Coda:

                Sistema Coda
              +-------------+       RED
              | +---------+ |     +-----+
              | |         | |     |     |
              | |Servidor | |<----|-----|------->Cliente 1
              | | Coda 1  | |     |     |
              | |         | |     |     |
              | +----+----+ |<----|-----|------->Cliente 2
              |      |      |     |     |
              |      |      |     |     |
              | +----+----+ |     |     |
              | |         | |     |     |
              | |Servidor | |     |     |
              | | Coda 2  | |<----|-----|------->Cliente 3
              | |         | |     |     |
              | +---------+ |     +-----+
              +-------------+



  La implementacin de Coda en Linux est constituida por un conjunto de
  demonios que se ejecutan en los servidores, normalmente llamados _V_i_c_e,
  y un demonio (VVeennuuss)) mmss uunn mmdduulloo ddeell _N__c_l_e_o en la parte del cliente.
  La comunicacin se establece entre los demonios, siendo el mdulo del
  _n__c_l_e_o la interfaz entre el Sistema Coda y el VVFFSS (_V_i_r_t_u_a_l _F_i_l_e
  _S_y_s_t_e_m) de Linux.

  Cuando un usuario intenta leer un fichero del Sistema Coda (por
  ejemplo con cat /coda/users/user15/doc.txt) el programa cat realizar
  unas llamadas al sistema relacionadas con el fichero, que se
  comunicarn con el VFS del _n__c_l_e_o. El VFS comprueba entonces que la
  peticin se refiere a un fichero Coda, y encamina la peticin al
  mdulo del sistema de ficheros Coda en el _N__c_l_e_o (_C_o_d_a _F_S). Este
  mdulo mantiene una cach de peticiones recientes resueltas, y si la
  respuesta no se encuentra en esta cach, se encamina de nuevo la
  peticin al gestor de cach Coda Venus (a travs del dispositivo de
  caracter /dev/cfs0). Venus comprobar si el fichero user15/doc.txt se
  encuentra en una segunda cach, almacenada en disco, y en caso
  contrario contactar con los servidores (Vice) para obtenerlo. Una vez
  conseguido el fichero, Venus responder al _n__c_l_e_o, quien devolver la
  respuesta al programa cat.

  Cuando el _n__c_l_e_o solicita a Venus la apertura de un fichero por
  primera vez, ste obtiene el fichero completo de los servidores
  utilizando las llamadas a procedimientos remotos (RPC) para
  comunicarse con los ellos. Despus almacena el fichero en el rea de
  cach (en el directorio /usr/coda/venus.cache/), desde donde ser
  controlado por el sistema de ficheros ext2 de Linux. Si un fichero ya
  se encuentra en la cach del cliente, Venus permitir trabajar con l
  sin contactar con los servidores, de modo que si el fichero se abre
  una segunda vez, no se obtendr del almacn remoto (trabajo en modo
  desconectado) sino de la cach.

  As pues, Venus slo almacena aquella informacin que necesita el
  cliente, como ficheros o directorios (los directorios en Linux son
  ficheros) y sus atributos (propietario, permisos y tamao). Si el
  fichero ha sido modificado y cerrado, entonces Venus actualiza los
  servidores envindoles el nuevo fichero. Cualquier otra operacin que
  modifique el sistema de ficheros (como la creacin o eliminacin de
  directorios y enlaces -_l_i_n_k_s-) se propagar tambin a los servidores.

  Coda ofrece distintos niveles de seguridad mediante KKeerrbbeerrooss: no
  cifrar; cifrar slo los paquetes de protocolo interno; cifrar adems
  las cabeceras de los mensajes; y cifrado completo.


  44..22..  LLaass ooppeerraacciioonneess ddeessccoonneeccttaaddaass

  Si el cliente est desconectado e intenta actualizar un fichero que
  tiene en la cach, Venus se da cuenta que los servidores no estn
  disponibles, se declara en modo desconectado y registra los cambios
  realizados en el CCMMLL (_C_l_i_e_n_t _M_o_d_i_f_i_c_a_t_i_o_n _L_o_g o Registro de
  Modificacin del Cliente) sobre el sistema de ficheros para
  actualizarlos en los servidores durante la siguiente conexin. Este
  proceso es transparente para el usuario, quien no se percata que ha
  cambiado a modo desconectado. Asimismo el CML est optimizado (por
  ejemplo, si un fichero es creado y luego borrado, se eliminan estos
  pasos del CML).

  En ocasiones un cliente intenta acceder a un fichero que no tiene en
  su cach. Si est conectado lo consigue de los servidores, pero si no
  lo est, no hay nada que hacer y se devuelve un error al programa que
  haya hecho la peticin. Para evitarlo existen los ffiicchheerrooss HHOOAARRDD, que
  son un conjunto de ficheros relativamente importantes establecidos por
  el usuario que se mantienen en la cach. El usuario define la base de
  datos de ficheros HOARD, y puede solicitar a los servidores las
  ltimas actualizaciones antes de desconectarse. Esta base de datos la
  puede construir automticamente el sistema haciendo un seguimiento de
  los accesos que hace el usuario. Los ficheros Hoard permiten, por
  ejemplo, que un cliente forzar la carga del cach local antes de
  entrar en modo desconectado, y tener la garanta de que todo lo que
  necesita estar en su porttil tras la desconexin.

  Puede ocurrir que dos o ms clientes hayan actualizado el mismo
  fichero cuando estaban en modo desconectado. Cuando los clientes se
  conecten se producir un ccoonnfflliiccttoo LLOOCCAALL//GGLLOOBBAALL entre cliente y
  servidor y se debe decidir por una de las actualizaciones. Para
  reparar este conflicto, el usuario dispone de la orden repair. La
  reparacin la puede realizar a veces automticamente reparadores
  especficos de la aplicacin (por ejemplo, si dos usuarios modifican
  registros distintos de una misma base de datos, la propia base de
  datos los actualizara sin que existiera un posible conflicto).


  44..33..  VVoollmmeenneess,, sseerrvviiddoorreess yy rreepplliiccaacciioonneess..

  Los servidores Coda no almacenan los ficheros en un sistema de
  ficheros tradicional. En lugar de disco, particin o directorio, se
  utiliza el concepto de vvoolluummeenn.. FFssiiccaammeennttee [[MMAARR9999]] rreepprreesseennttaa uunn
  ggrruuppoo ddee ffiicchheerrooss mmaappeeaaddooss eenn mmeemmoorriiaa ppoorr eell ddeemmoonniioo sseerrvviiddoorr codasrv,
  que contienen la informacin almacenada en dicho volumen. Los
  volmenes proporcionan mayor flexibilidad al administrador, y su
  tamao medio aproximado es de 10 MB, llegando a existir cientos de
  volmenes por servidor.

  RRVVMM (_R_e_c_o_v_e_r_a_b_l_e _V_i_r_t_u_a_l _M_e_m_o_r_y o Memoria Virtual Persistente)
  registra la informacin de volmenes y directorios, listas de control
  de accesos y atributos de los ficheros en particiones crudas


  .  En caso de una cada del host repara el sistema accediendo a la
  informacin de estas particiones, consiguiendo velocidad y
  consistencia. Hay dos particiones crudas: _L_o_g _P_a_r_t_i_t_i_o_n y _D_a_t_a
  _P_a_r_t_i_t_i_o_n.

  Existe un volumen raz que se monta bajo /coda, desde donde se montan
  el resto de los volmenes. Obviamente este volumen es propiedad del
  administrador Coda. Un volumen tiene un nombre y un identificador _I_d,
  y se monta en cualquier subdirectorio de /coda (por ejemplo el volumen
  de un usuario users.user15 se puede montar bajo /coda/users/user15).
  Cada fichero se identifica con un identificador Fid nico en un
  sistema Coda y est compuesto por tres enteros de 32 bits:


     VVoolluummeeIIdd::
        identifica el volumen en el que reside el fichero.

     VVnnooddeeIIdd::
        nmero de inodo del fichero.

     UUnniiqquuiiffiieerr::
        identificador necesario para la resolucin de conflictos.

  Un volumen replicado es aqul que est almacenado en un grupo de
  servidores que pertenecen al mismo VVSSGG (_V_o_l_u_m_e _S_t_o_r_a_g_e _G_r_o_u_p), de modo
  que cualquier operacin sobre los ficheros de ese volumen afectar a
  todo el VSG al que pertenece (lo cual no supone mucho coste, ya que
  Coda implementa difusin

  ).El objetivo de esto es la alta disponibilidad del volumen. Asimismo
  existe el subgrupo AAVVSSGG (_A_v_a_i_l_a_b_l_e _V_S_G), que son aquellos servidores
  accesibles y pertenecientes a un mismo VSG (puede ocurrir por ejemplo
  que uno de los servidores del VSG se avere, con lo cual deja de ser
  accesible y deja de pertenecer al AVSG). Otros tipos de volmenes son
  los locales (no replicados) y volmenes _b_a_c_k_u_p. Los volmenes _b_a_c_k_u_p
  permiten realizar copias de seguridad del Sistema de Ficheros Coda;
  sin embargo no se tratar en este documento.

  La replicacin de servidores puede provocar ccoonnfflliiccttooss gglloobbaalleess cuando
  el nmero de servidores que forman parte de un mismo AVSG es inferior
  al VSG (por ejemplo si las mquinas de un VSG son separados de los
  dems por una cada de la red). En este caso las actualizaciones de
  los ficheros no pueden propagarse a todos los miembros del VSG y es
  necesario resolver el conflicto con la orden repair (muchas veces slo
  hay que decirle a Coda que lo repare como cuando hay que sustituir un
  disco duro y el sistema se encarga de actualizarlo).


  44..44..  AApplliiccaacciioonneess ddee CCooddaa

  En Internet, las rplicas de sseerrvviiddoorreess FFTTPP podran ser clientes Coda
  que se actualizaran cada vez que los servidores Coda sufrieran
  cualquier modificacin. Lo mismo pasara con la rplica de sseerrvviiddoorreess
  WWWWWW, los cuales tambin pueden ser clientes Coda (los cuales pueden
  ser optimizados guardando en su cach local todos los datos a
  replicar). En ambos casos NFS es inadecuado ya que est diseado para
  un entorno _L_A_N, y hasta la aparicin de Coda eran necesarias
  herramientas de sincronizacin entre servidores como rsync, que
  peridicamente contrastan las diferencias entre nodos y actualizan las
  diferencias. La computacin mvil de Coda tambin puede ser
  aprovechada para aquellos clientes de proveedores de Internet que
  actualizan su pgina Web tras disearla en modo desconectado.

  En las redes locales un usuario podra, por ejemplo, conectarse al
  sistema Coda cargando en su cach local los datos que vaya a utilizar
  ese da (promoviendo el acceso a servicios locales frente a remotos,
  lo cual incrementa el rendimiento disminuyendo los costes de
  comunicacin), desconectarse


  y, cuando acabe el da, volver a conectarse para reintegrar los
  cambios efectuados.



  44..55..  DDeessvveennttaajjaass

  [MAR99] Debido a sus caractersticas Coda tiene una serie de
  desventajas (algunas ya mencionadas):


    Las operaciones de bloqueo de ficheros no estn implementadas
     debido a que no es posible un algoritmo de bloqueo que tenga en
     cuenta un funcionamiento en modo desconectado.

    Existe un problema de sincronizacin intrnseco al modo
     desconectado: cuando al reconectar un cliente, un fichero ha
     cambiado tanto en el cliente como en el servidor, cal es la
     versin que se debe sincronizar con el resto del sistema?. Existen
     diversos algoritmos, pero frecuentemente se requiere la mano del
     operador.

    La implementacin de cuotas es limitada y slo existe para los
     directorios (no existen cuotas para usuarios). Para solucionarlo se
     puede asignar un volumen por usuario, pero cambiar la cuota a un
     usuario es complicado porque los volmenes Coda no son
     redimensionables.

    Coda no es estable y actualmente no se soportan bien volmenes de
     ms de 100 usuarios, ni mezcla de servidores Coda que no estn
     replicados (cada servidor Coda sirviendo un volumen independiente).

    Todas las operaciones de administracin deben hacerse desde un
     cliente Coda sin que se pueda trabajar directamente con los
     volmenes.  Esto dificulta enormemente las tareas de mantenimiento
     y administracin.

    Una mquina no puede ser a la vez cliente y servidor Coda.


  55..  IInnssttaallaacciinn yy ccoonnffiigguurraacciinn



  55..11..  DDnnddee oobbtteenneerr llooss bbiinnaarriiooss ddee CCooddaa


  Todos los servidores deben tener la misma versin Coda para evitar
  problemas. La versin de los clientes puede ser anterior a la de los
  servidores pero mayor que una dada (dependiendo de la versin del
  servidor, aunque es conveniente que todas las versiones coincidan).

  Tambin es aconsejable instalar Coda a partir de los paquetes binarios
  para evitar compilar el cdigo fuente. Existen binarios para las dos
  distribuciones Linux ms utilizadas, Debian http://www.debian.org y
  Red Hat http://www.redhat.com. El cdigo fuente se puede obtener junto
  a los binarios de Red Hat en ftp://ftp.coda.cs.cmu.edu/pub/coda, y los
  binarios de Debian de
  ftp://ftp.debian.org/debian/project/experimental. Estos paquetes
  binarios tienen unas dependencias o requisitos y deben ser compatibles
  con la versin de Linux en la que queremos instalar Coda. Por ejemplo
  en Debian se puede conocer las dependencias de un paquete binario con


       dpkg --info nombrePaquete.deb



  , y si nuestro sistema Linux lo cumple lo podremos instalar sin prob
  lemas.

  En este informe se ha utilizado la versin 5.2.0-1 de Coda bajo Debian
  2.1 _s_l_i_n_k. Existe en binario la versin 5.3.1-1 para Debian 2.2, pero
  hemos optado por la primera para evitar actualizar Linux. An as
  suponemos que entre ambas versiones no existen cambios importantes en
  la instalacin y administracin.

  Tambin hemos trabajado con la versin Coda de Red Hat, aunque
  recomendamos la de Debian por ser ms fcil su instalacin y
  administracin. Por ejemplo, en Debian el programa de instalacin pasa
  automticamente a su configuracin y el servidor Coda se lanza con el
  script /etc/init.d/coda-server, mientras que en Red Hat son varios los
  scripts.


  55..22..  SSiinnccrroonniizzaacciinn ddee llooss sseerrvviiddoorreess

  Los servidores deben estar sincronizados en fecha y hora. Para
  lograrlo hemos optado por XNTP, basado en sincronizacin externa UTC
  (Tiempo Universal Coordinado). En el caso de dos servidores Coda hay
  que aadir las siguientes lneas en sus ficheros de configuracin
  ntp.conf del programa xntp (en Debian este fichero se encuentra en el
  directorio /etc/):


     SSeerrvviiddoorr CCooddaa 11::


          server mquinaServidorXntp1
          server mquinaServidorXntp2
          peer  servidorCoda2



     SSeerrvviiddoorr CCooddaa 22::


          server mquinaServidorXntp1
          server mquinaServidorXntp2
          peer servidorCoda1



  Las dos primeras lneas de cada configuracin especifican con qu
  servidor o servidores xntp se sincronizan. Si por redundancia se
  sincronizan con ms de un servidor xntp como en el ejemplo, estos
  servidores deben tener el mismo nivel xntp garantizando la
  sincronizacin entre s. La tercera lnea


       peer servidorCodax



  asegura la sincronizacin entre los dos servidores Coda en el caso de
  que se pierda la comunicacin con los servidores xntp (es importante
  mantener bien sincronizados los relojes locales del sistema dis
  tribuido).


  55..33..  IInnssttaallaacciinn ddee llooss SSeerrvviiddoorreess


  De todos los servidores Coda slo uno puede ser el servidor SCM, desde
  donde se administra el sistema de volmenes y las cuentas de usuario.

  Se explicarn los procesos de instalacin y configuracin de las
  versiones 5.2.0-1 para Red Hat y Debian. Ntese que para la
  instalacin y configuracin de los servidores es necesario ser el
  superusuario del sistema Linux.


  55..33..11..  SSeerrvviiddoorr SSCCMM eenn RReedd HHaatt


  Se proceder a instalar el paquete, para lo que introduciremos por la
  lnea de rdenes:



       # rpm -i coda-debug-server-5.2.0-1.i386.rpm



  Una vez instalado el servidor, iniciaremos su configuracin, la cual
  difiere entre el servidor maestro SCM y el resto de servidores.



       # vice-setup



  A continuacin se detalla el proceso de configuracin con vice-setup.
  Introducimos una cadena de 8 caracteres (debe ser exactamente de 8
  caracteres para evitar problemas causados por un posible _b_u_g de Coda).
  Un ejemplo puede ser elephant:



       Setting up config files (under /vice).
       Directories under /vice are set up.

       Setting up tokens for authentication.
       The following tokens must be identical on all servers.
       Enter a random token for auth2 authentication : elephant

  Introducimos, al igual que antes, una cadena de exactamente 8
  caracteres.  Debe ser distinta a la anterior (otro _b_u_g), por ejemplo,
  elephann:



       The following tokens must be identical on all servers.
       Enter a random token for volutil authentication : elephann



  A partir de aqu empiezan las diferencias entre la configuracin del
  servidor maestro y del resto de servidores. Contestar y si se trata
  del maestro y n en el caso de un servidor normal. Continuaremos como
  si hubiramos contestado y a esta pregunta , y posteriormente
  comentaremos las diferencias que habra si se tratase de un servidor
  no SCM:



       tokens done!

       Setting up the file list for update
       filelist for update ready.

       Populating /vice/vol...
       lockfiles created.
       /etc/services ready for Coda
       Is this the master server, aka the SCM machine? (y/n) y



  Introduciremos un identificador para el servidor, por ejemplo el '1'.
  Esta pregunta se har solamente al configurar el SCM, por lo que el
  resto de servidores habr que aadirlos directamente en el fichero
  /vice/db/servers del SCM:



       Now installing files specific to the SCM...

       Setting up servers file.
       Enter an id for this server (a number > 0 < 255) : 1



  Aqu se establece el VSG (_V_o_l_u_m_e _S_t_o_r_a_g_e _G_r_o_u_p) del servidor que se
  est configurando, asignndosele un identificador (el valor por
  defecto es el E0000100). Toda la informacin correspondiente a los
  grupos de servidores se guarda en el fichero /vice/db/VSGDB.  Si se
  quiere aadir un nuevo servidor a un grupo de servidores, o se quiere
  incluir un nuevo grupo, habr que hacerlo editando directamente este
  archivo del SCM:



       done!
       Initializing the VSGDB to contain the SCM as E0000100
       /vice/db/VSGDB set up



  Se pide el nombre del _r_o_o_t_v_o_l_u_m_e, que es el volumen que se montar
  como raz en los clientes. Un posible valor es coda:root.



       Setting up ROOTVOLUME file
       Enter the name of the rootvolume (< 32 chars) : coda:root



  En este paso se debe introducir un identificador de usuario que ser
  el administrador del sistema. Este identificador deber ser
  obligatoriamente 500.



       Setting up users and groups for Coda

       You need to give me a uid (not 0) and username (not root)
       for a Coda System:Administrator member on this server,
       (sort of a Coda super user)

       Enter the uid of this user:500



  Ahora hay que darle un nombre a la cuenta del administrador Coda (el
  nombre con que trabajaremos ser admin).



       Enter the username of this user: admin



  Se ha creado el nuevo usuario (nombre de usuario admin e identificador
  500), que tendr su contrasea inicializada a changeme. Si se quiere
  cambiar habr que utilizar o bien cpasswd o la utilidad de
  administracin de usuarios au.



       An initial administrative user admin (id 500)
       with Coda password changeme now exists.



  Aqu se pregunta si se quieren configurar las particiones RVM del
  servidor. Durante la instalacin de cada servidor Coda es aconsejable
  dedicar 2 particiones tipo ext2 por razones de eficiencia (en otro
  caso se tratar como ficheros). Ambos ficheros forman la RVM usada
  para lograr una persistencia de la memoria virtual del host en caso de
  una cada:



  You need a small log disk partition, preferrably on a disk by itself.
  You need a metadata partition of approx 4% of you filespace.

  For trial purposes you may give oridnary files instead of raw
  partitions. Keep all size small if you do this.
  Production servers will want partitions for speed.

  -------------------------------------------------------
  WARNING: you are going to play with your partitions now.
  verify all answers you give.
  -------------------------------------------------------

  WARNING: these choices are not easy to change once you are up and
  running.
  Are you ready to set up RVM? [yes/no] yes



  Hay que indicar cual es la particin o fichero que se va a utilizar
  como _l_o_g (por ejemplo /dev/hda4 para una particin o
  /codap/logpartition en el caso de un fichero):



       What is your log partition? /dev/hda4



  En la particin de _l_o_g (_l_o_g _p_a_r_t_i_t_i_o_n) se registran las transacciones
  de volmenes coda que quizs no hayan sido an actualizadas en la
  particin de datos coda. No debe sobrepasar los 30MB (el sistema coda
  no ha sido puesto a prueba con tamaos mayores a ste) y es
  aconsejable tener una particin de 2MB (lo merjo es ceirse a lo que
  se indica en la instalacin). Nunca se debe tener una particin menor
  que el tamao indicado en la instalacin (por ejemplo si la particin
  es de 11.6MB y en la instalacin se indica que tiene 12MB, puede
  fallar la instalacin):



       The log size must be smaller than you log partition.
       We recommend not more than 30M log size, and 2M is a good choice.
       What is your log size? (enter as e.g. '12M') 2M



  Eleccin de la particin de datos RVM (_d_a_t_a _p_a_r_t_i_t_i_o_n). Indicar una
  particin (/dev/hdxx) o el nombre de un archivo:



       What is your data partition (or file)? /dev/hda5



  Se indicar el tamao de la particin de datos. Recomendamos
  encarecidamente que se utilice uno de los valores dados por el _s_c_r_i_p_t,
  ya que nicamente as se har una configuracin vlida de las
  particiones (si se opta por poner otro tamao de particin se deber
  inicializar la particin de datos mediante el programa rdsinit.  Este
  programa es difcil de manejar, siendo aconsejable poner el tamao de
  la particin que viene por defecto en la instalacin). Si se pone una
  particin menor que 22MB puede fallar la instalacin. El script es muy
  sensible a las maysculas y minsculas, por lo que es importante poner
  22M y no 22m al indicar el tamao de la particin:



       The data size must be approx 4% of you server file space.
       We have templates for servers of approx: 500M, 1G, 2.2G, 3.3G,8G
       (you can store less, but not more on such servers).
       The corresponding data sizes are  22M, 44M, 90M, 130M, 315M.
       (use 330M only on very fast machines)
       Pick one of the defaults, otherwise I will bail out

       What is the size of you data partition (or file) [22M,44M, 90M,130M, 315M]:
       22M



  Aqu se pide confirmacin para inicializar las particiones. Si se ha
  configurado bien saldr lo siguiente:



       --------------------------------------------------------
       WARNING: DATA and LOG partitions are about to be wiped.
       --------------------------------------------------------

         --- log area: /dev/hda4, size 2M.
         --- data area: /dev/hda5, size 22M.

       Proceed, and wipe out old data? [y/n]  y



  Se pregunta por el nombre del directorio en el que se guardarn los
  datos de los volmenes coda. Pulse intro para que el directorio por
  defecto sea /vicepa:



       LOG file has been initialized!

       Rdsinit will initialize data and log.
       This takes a while.

       Your server directories will hold the files (not directories).
       You can currently only have one directory per disk partition.

       Where shall we store your data [/vicepa]?



  Pregunta por el nmero aproximado de entradas de fichero que se van a
  tener:



       Shall I set up a vicetab entry for approx 256000 files for y (y/n)  y



  Una vez termine la ejecucin de vice-setup habr que levantar los
  servicios Coda ejecutando los correspondientes demonios:



       Read vicetab(5) and makeftree(8) for set up info.
       Server directory is set up!

       Congratulations: your configuration is ready...and now
       to get going do the following:
        - start the auth2 server as: auth2
        - start rpc2portmap as: rpc2portmap
        - start updateclnt as:  updateclnt -h ha0 -q coda_udpsrv
        - start updatesrv as: updatesrv -p /vice/db
        - start the fileserver: startserver &
        - wait until the server is up: tail -f /vice/srv/SrvLog
        - create your root volume: createvol_rep coda:root E0000100 /vicepa
        - setup a client: venus-setup ha0 20000
        - start venus: venus
        - enjoy Coda.



  Los demonios estn disponibles en el directorio /etc/rc.d/init.d/, y
  son los siguientes:



       update.init
       auth2.init,
       codasrv.init



  Para lanzarlos bastar con pasarles como parmetro la clusula
  start:


    /etc/rc.d/init.d/update.init start, ejecuta rpc2portmap, updateclnt
     y updatesrv. Este script no ejecuta bien el demonio updatesrv, hay
     que hacer una pequea modificacin aadiendo "> /dev/null" al final
     de la lnea en la que se le ejecuta.

    /etc/rc.d/init.d/auth2.init start, ejecuta auth2.

    /etc/rc.d/init.d/codasrv.init start, ejecuta startserver, quien a
     su vez ejecuta el codasrv.

  Se puede comprobar que el servidor ha empezado a funcionar mirando el
  siguiente _l_o_g:



       $ tail -f /vice/srv/SrvLog &



  El siguiente paso es instalar el resto de los servidores no-SCM y
  configurarlos.



  55..33..22..  SSeerrvviiddoorr nnoo SSCCMM eenn RReedd HHaatt


  La configuracin de un servidor no SCM es prcticamente idntica a la
  del servidor maestro, aunque se omiten una serie de pasos (los de la
  creacin de usuarios y especificacin del volumen root).

  Es importante indicar que por razones de seguridad todos los
  servidores de un mismo VSG debern tener los mismos _t_o_k_e_n_s de
  autentificacin.

  En esta ocasin no se pedir un nmero de identificacin del servidor
  (tenemos que introducirlo antes o despus en /vice/db/servers de la
  mquina SCM), pero s se nos preguntar la ruta a la mquina maestra
  (direccin IP  nombre de la mquina).

  Tenemos que configurar, de igual manera, los RVM's (particiones log y
  de datos). Tras terminar con la configuracin lanzaremos los demonios
  del servidor no-SCM:


    /etc/rc.d/init.d/update.init

    /etc/rc.d/init.d/auth2.init

    /etc/rc.d/init.d/codasrv.init


  55..33..33..  DDeebbiiaann


  La instalacin en Debian es bastante similar a la de Red Hat, por lo
  que solamente contaremos las diferencias entre una y otra.
  Comenzaremos por instalar el paquete binario, para ello teclearemos:



       # dpkg -i coda-server_5.2.0-1.i386.deb



  La propia instalacin del paquete lanza el programa de configuracin
  vice-setup, que es idntico al de la distribucin Red Hat (la nica
  diferencia es que ste lanza los demonios directamente).

  Una vez hecha la configuracin (siguiendo los mismos pasos que hemos
  descrito en el apartado anterior para Red Hat) estarn lanzados todos
  los demonios a excepcin de startserver y codasrv (los cuales habr
  que lanzar a mano con  startserver &).

  Para que estos dos demonios se ejecuten automticamente tenemos que
  crear el siguiente fichero /vice/srv/STARTFROMBOOT. Una forma de
  hacerlo es con:



       # echo >/vice/srv/STARTFROMBOOT



  o



  # touch /vice/srv/STARTFROMBOOT



  En Debian existe un nico script encargado de lanzar o matar todos los
  demonios de un servidor Coda (ntese que la ruta del script cambia con
  respecto a la ruta de Red Hat):


     /etc/init.d/coda-server stop
        para parar el servidor Coda.

     /etc/init.d/coda-server start
        para iniciarlo.

  Tras todo esto ya slo nos queda configurar los servidores desde el
  SCM para que Coda empiece a funcionar correctamente.


  55..44..  CCoonnffiigguurraacciinn ddee llooss sseerrvviiddoorreess CCooddaa


  Los volmenes son unidades de informacin que permiten gestionar
  conjuntamente los datos que contienen. Es posible que un volumen
  pertenezca slo a un servidor (vvoolluummeenn nnoo rreepplliiccaaddoo) y que slo unos
  pocos usuarios puedan leer y escribir sobre l. Tambin es posible que
  un volumen pertenezca a ms de un servidor (vvoolluummeenn rreepplliiccaaddoo) y que
  todos los usuarios coda puedan leer y escribir sobre l.


  55..44..11..  CCrreeaacciinn ddee vvoollmmeenneess


  El primer paso para configurar los servidores es crear el volumen _r_o_o_t
  desde el SCM (el nico que puede crear y borrar volmenes) con una de
  las siguientes rdenes:



       # createvol_rep coda:root E0000100 /vicepa

       # createvol coda:root sipt30 /vicepa



  En ambos casos el volumen _r_o_o_t se llama coda:root, pero con la
  diferencia que en el primero creamos el volumen replicado y en el
  segundo no (donde sipt30 es el servidor Coda que contiene el volumen
  _r_o_o_t).

  En el ejemplo del volumen root replicado E0000100 es el identificador
  del VSG al que pertenece el servidor SCM (por defecto el SCM pertenece
  a este VSG) y el resto de servidores Coda donde queremos replicar el
  volumen. Para aadir nuevos servidores a este VSG (al que inicialmente
  slo pertenece el SCM) el administrador debe modificar los siguientes
  ficheros del SCM:


    /vice/db/VSGDB, para indicar a qu servidores corresponde el
     identificador de grupo E0000100. Por ejemplo:



  E0000100 sipt30 sipt31



    /vice/db/servers, para indicar cules son los identificadores de
     cada servidor (el del SCM ya ha sido escogido durante el proceso de
     instalacin). En el siguiente ejemplo el identificador del servidor
     coda y SCM sipt30 es 1 y el del servidor sipt31 es 2



       sipt30  1
       sipt31  2



  Dichos ficheros habr que modificarlos en el SCM cada vez que se
  quiera aadir o eliminar un nodo del grupo de servidores.

  Cuando se conecten los servidores No-SCM, se actualizarn por la red
  sus ficheros del directorio /vice (los ficheros de configuracin del
  servidor) incluyendo los dos anteriores.

  Al igual que el _r_o_o_t _v_o_l_u_m_e, el servidor SCM puede crear otros
  volmenes necesarios con createvol_rep (volmenes replicados) o con
  createvol (volmenes locales al servidor sin replicar). De este modo
  podemos encontrarnos con la siguiente configuracin del fichero
  /vice/db/VSGDB:



       E0000100 ha0 ha1
       E0000200 ha1



  donde los servidores ha0 y ha1 pertenecen al grupo E0000100 y slo ha1
  pertenece al grupo E0000200 (aunque el identificador pertenezca a un
  volumen replicado).


  55..44..22..  EElliimmiinnaacciinn ddee vvoollmmeenneess


  Para eliminar un volumen se utiliza la orden purgevol (para volmenes
  no replicados) o purgevol_rep (para volumenes replicados), que slo
  puede ser ejecutada desde el servidor SCM:

  # purgevol_rep NombreVolumen


  55..44..33..  FFiicchheerrooss ddee ccoonnffiigguurraacciinn ddeell sseerrvviiddoorr


  La informacin almacenada en los servidores Coda est organizada en
  varios directorios, que estn descritos a continuacin:


    /vice/auth2 Este directorio contiene informacin relacionada con el
     proceso de autenticacin, incluyendo sus ficheros _l_o_g.

    /vice/bin Contiene los binarios del sistema de ficheros Coda para
     los servidores y el SCM.

    /vice/db Contiene las bases de datos con informacin importante
     para los servidores y los ficheros _l_o_g de las actualizaciones.

    /vice/srv Contiene informacin relacionada con los demonios del
     servidor, incluyendo sus ficheros _l_o_g.

    /vice/vol Contiene informacin de los volmenes Coda.

    /vice/vol/remote Existe slo en el SCM y contiene informacin de
     todos los servidores remotos.

    En /vicepa (si no se ha cambiado por otro directorio durante la
     instalacin) se guardan los datos de los volmenes Coda que tiene
     el servidor. La informacin se guarda en forma de ficheros que se
     distribuyen a lo largo de un rbol de directorios codificado
     numricamente. Consideramos interesante resear que en nuestro caso
     los ficheros comenzaban a guardarse ordenadamente en el directorio
     /vicepa/0/0/, aunque desconocemos el sistema de codificacin.


  55..55..  IInnssttaallaacciinn ddee llooss cclliieenntteess CCooddaa


  El cliente debe instalar dos cosas: un mdulo del ncleo para
  reconocer el sistema de ficheros Coda, y el propio programa cliente
  Coda. Se recuerda que un cliente y un servidor Coda no funcionan bajo
  una misma mquina, por lo que debemos evitar que ocurra.


  55..55..11..  MMdduulloo ddeell nncclleeoo CCooddaa


  Para que el cliente tenga acceso al sistema de ficheros distribuido
  Coda es necesario que el Ncleo lo reconozca. Esto se puede conseguir
  de varias formas:


  1. Compilando uno de los _n__c_l_e_os 2.2.x que ya disponen de soporte Coda
     y habilitndolo dentro del Ncleo (parte del proceso de compilacin
     de un _n__c_l_e_o en Linux).

  2. Compilando uno de los _n__c_l_e_o_s 2.2.x para que soporte Coda, pero
     esta vez obteniendo un mdulo coda.o que podremos cargar y
     descargar del _N__c_l_e_o cuando queramos.

  3. Si nuestro _N__c_l_e_o tiene una versin anterior al 2.2.x, podemos
     obtener el mdulo coda.o mencionado antes compilando el cdigo
     fuente de Coda (normalmente se encuentra en el fichero linux-
     coda-(versin).tgz)

  Si nos hemos decidido por trabajar con el mdulo coda (opciones ``1''
  y ``2''), dicho mdulo no se cargar en memoria una vez arrancado
  Linux. Para cargarlo en memoria existen varios mtodos, por ejemplo:


    Mediante la lnea de rdenes del _r_o_o_t con:



  # insmod coda



    Cargando obligatoriamente el mdulo cuando se arranque Linux
     (introduciendo en el fichero /etc/modules la lnea coda).

    Cargando automticamente el mdulo slo cuando sea necesario
     (introduciendo en el fichero /etc/modules la lnea auto).

  NNoottaa: el mdulo coda.o debe encontrarse en
  /lib/modules/versionNcleo/fs, donde versionNcleo es la versin del
  _n__c_l_e_o de Linux (para consultar la versin del _n__c_l_e_o desde la lnea
  de rdenes probar con uname -r).


  55..55..22..  IInnssttaallaacciinn ddee llooss bbiinnaarriiooss


  La instalacin del cliente a partir de un paquete binario Linux se
  realiza de distinta forma dependiendo de la distribucin a la que
  pertenece:


  55..55..22..11..  RReedd HHaatt


  El primer paso es instalar el paquete binario:



       # rpm -i coda-debug-client-5.2.0-1.i386.rpm



  Venus es el gestor de la cach del cliente. Para configurarlo tenemos
  el _s_c_r_i_p_t venus-setup:


       # /usr/bin/venus-setup <lista_de_hosts_separados_por_comas>
       <tamao_de_cach_en_kb>


  con lo que decimos a Venus cul es su lista de servidores Coda a los
  que debe conectarse. Tambin inicializa un directorio para utilizarlo
  como cach de disco del cliente Coda, con el tamao indicado en el
  _s_c_r_i_p_t venus-setup (para empezar se recomienda un a pequea cach de
  20 MB, aunque funciona bien hasta 300 MB). Asimismo venus-setup crear
  el dispositivo /dev/cfs0 para comunicarse con el _N__c_l_e_o y dejar todos
  los ficheros del cliente Coda en el directorio /usr/coda.

  Tambin sera recomendable probar nuestro cliente Coda con el servidor
  Coda testserver.coda.cs.cmu.edu, aunque deber asegurarse que no tiene
  ningn _f_i_r_e_w_a_l_l que le impida comunicarse con l. Una cach de 20000
  es aconsejable para probar este servidor.

  Tras la instalacin del paquete binario se puede lanzar Venus en
  _b_a_c_k_g_r_o_u_n_d con la orden:



       # venus &

  y se puede parar con



       # kill -9 venus



  o con



       vutil shutdown
       umount /coda



  Aunque una manera ms limpia de lanzar y parar Venus es desde su
  _s_c_r_i_p_t de inicio /etc/rc.d/init.d/venus.

  NNoottaa: Antes de volver a lanzar Venus el directorio /coda debe ser
  desmontado. Si esto diera problemas asegrese de matar todos los
  procesos que cuelgan de Coda, por ejemplo cuando tenemos ficheros de
  Coda abiertos por una aplicacin o porque estamos dentro del
  directorio /coda. Las utilidades lsof y fuser pueden ayudarnos para
  solucionar estas cosas.


  55..55..22..22..  DDeebbiiaann


  Instalamos el binario del cliente Coda:



       # dpkg -i coda-client_5.2.0-1_i386.deb



  El proceso es similar al de Red Hat, aunque en Debian venus-setup se
  ejecuta en la propia instalacin. An as siempre se puede utilizar
  venus-setup y venus & para una posterior configuracin.

  /etc/init.d/coda-client es el script que lanza y para el demonio
  Venus.


  55..55..33..  DDeessiinnssttaallaacciinn


  A continuacin se describe el proceso de desinstalacin de un servidor
  Coda, til cuando nos hemos equivocado en el proceso de instalacin o
  configuracin y queremos volver a empezar.


  55..55..33..11..  SSeerrvviiddoorr RReedd HHaatt


  Comenzaremos por parar a todos los demonios utilizando los lanzadores
  de los que disponemos en etc/rc.d/init.d/:



  # /etc/rc.d/init.d/auth2.init stop
  # /etc/rc.d/init.d/update.init stop
  # /etc/rc.d/init.d/codasrv.init stop



  Tras esto verificaremos que ninguno de los siguientes procesos est
  cargado en memoria con ps uax | less:



        auth2
        rpc2portmap
        update
        updateclnt
        updatesrv
        startserver
        codasrv



  Si alguno de estos procesos est en ejecucin lo podemos parar con:


       kill -9 pid



  donde pid es el identificador del proceso que aparece indicado al eje
  cutar ps.

  Ahora ya nos hemos asegurado de que no hay ningn proceso del servidor
  coda en funcionamiento, por lo que podemos proceder a la
  desinstalacin del paquete.



       # rpm -e coda-debug-server-5.2.0-1



  Por ltimo, slo nos queda borrar los directorios de Coda:



       # rm -rf /vicepa
       # rm -rf /vice
       # rm -f /var/lock/subsys/auth2.init
       # rm -f /var/lock/subsys/update.init
       # rm -f /var/lock/subsys/codasrv.init



  NNoottaa: Se pueden producir fallos en la configuracin de Coda si se
  intenta instalar de nuevo sin borrar antes los directorios /vicepa y
  /vice.



  55..55..33..22..  SSeerrvviiddoorr DDeebbiiaann


  Comenzaremos por dar de baja a todos los demonios:



       # /etc/init.d/coda-server stop



  El resto del proceso es idntico al de Red Hat, salvo que el paquete
  binario de Coda de desinstala con:



       # dpkg -r coda-debut-server_5.2.0-1



  o con la herramienta dselect de Debian.


  55..55..33..33..  CClliieennttee ((RReedd HHaatt yy DDeebbiiaann))


  El cliente es mucho ms sencillo y es suficiente con desinstalar el
  paquete binario de la distribucin (orden rpm en Red Hat y dpkg en
  Debian). Asimismo la desinstalacin del mdulo Coda del _n__c_l_e_o
  depender del proceso escogido para su instalacin.


  66..  AAddmmiinniissttrraacciinn



  66..11..  CCrreeaacciinn ddee ccuueennttaass ddee uussuuaarriioo


  [HAR98] Una vez instalados y configurados correctamente los servidores
  Coda debemos crear las ccuueennttaass ddee llooss uussuuaarriiooss CCooddaa.  Para ello
  emplearemos la orden interactiva pdbtool. Las rdenes ms utilizadas
  en pdbtool son:


     nu nombreusuario
        crea un nuevo usuario (el sistema le asigna un identificador).

     nui nombreusuario idusuario
        crea un nuevo usuario con el identificador especificado.

     ng nombregrupo idpropietario
        crea un nuevo grupo con el propietario especificado.

     ci usuario/nombregrupo nuevoid
        cambia el identificador de un usuario o grupo existente.

     ag id-grupo usuario/idgrupo
        aade un usuario o grupo a un grupo.

     n usuario/nombregrupo
        lista toda la informacin del usuario o del grupo especificado.

  donde los identificadores de usuario son enteros positivos y los
  identificadores de grupo son enteros negativos. Como ejemplo se crear
  una cuenta Coda con la herramienta pdbtool. Esta operacin debemos
  realizarla sobre el servidor SCM, ya que es el nico que puede
  realizarla.



       root@scm# pdbtool
       pdbtool> nu tux
       pdbtool> n tux
       USER tux
            *    id: 779
            *    belongs to no groups
            *    cps:  [  779  ]
            *    owns no groups
       pdbtool> ng users 779
       pdbtool> n users
       GROUP users OWNED BY tux
            *    id: -205
            *    owner id:  779
            *    belongs to no groups
            *    cps:  [  -205  ]
            *    has members: [ 779 ]
       pdbtool> n System:AnyUser
       GROUP System:AnyUser OWNED BY System
            *    id: -101
            *    owner id:  777
            *    belongs to no groups
            *    cps:  [  -101  ]
            *    has members: [ 777 ]
       pdbtool> ag -101 779
       pdbtool> ag -205 779
       pdbtool> n tux
       USER tux
            *    id: 779
            *    belongs to groups:  [ -101   -205]
            *    cps:  [ -101   -205   779 ]
            *    owns: [ -205 ]
       pdbtool> q



  La anterior secuencia ha creado una nueva cuenta de usuario llamada
  tux y se ha hecho que forme parte del tambin creado grupo users.
  Igualmente se ha introducido esta nueva cuenta en el grupo
  System:AnyUser, el cual contiene a todas las cuentas del Sistema Coda.
  Para activar la cuenta es necesario asignarle una contrasea desde
  cualquier servidor, autenticndose antes como el administrador de Coda
  (durante la instalacin del SCM se ha solicitado el nombre y la
  contrasea de la cuenta de administracin, que en nuestro caso son
  admin y changeme respectivamente):



       admin@cualquiermquina$ au -h scm nu
       Your Vice Name: admin
       Your Vice Password: ********
       New User Name: tux
       New User Password: nuevaContrasea



  A continuacin creamos un _h_o_m_e _v_o_l_u_m_e replicado llamado users:tux con
  VSG E0000100, lo montamos, le asignamos todos los permisos de usuario
  posibles sobre ese volumen (ver siguiente seccin ``orden cfs'', donde
  en el apartado 3 se explican los permisos de Coda), y lo desmontamos.
  Ntese que la orden cfs mkm crea y monta a la vez el directorio del
  volumen asociado.



       root@scm# createvol_rep users:tux E0000100 /vicepa
       admin@cualquiermquina$ cfs mkm /coda/usr/tux users:tux
       admin@cualquiermquina$ cfs sa /coda/usr/tux tux all
       admin@cualquiermquina$ cfs rmm /coda/usr/tux



  Finalmente el usuario tux podr cambiar su contrasea desde cualquier
  mquina cliente Coda con:



       tux@cualquiermquina$ cpasswd -h scm



  siendo SCM la mquina SCM del sistema Coda.


  66..22..  AAcccceessoo aa llaass ccuueennttaass yy rrddeenneess


  Si todo va bien el cliente debera ser capaz de montar el sistema de
  ficheros Coda bajo el directorio /coda (donde se monta el volumen
  _r_o_o_t).  Si existe el fichero /coda/NOT_REALLY_CODA entonces an no se
  ha montado Coda y debemos comprobar que el demonio Venus est lanzado.

  Para acceder a una cuenta Coda existe la orden clog user, donde _u_s_e_r
  es el nombre de usuario o _l_o_g_i_n. Desde cualquier mquina con cliente
  Coda:



       $ clog tux
       username: tux
       password: ********



  A partir de entonces el usuario autenticado puede montar los volmenes
  a los que tiene acceso (nuestro usuario tux tiene acceso al volumen
  users:tux y lo monta bajo /coda/usr/tux):



       tux@cualquiermquina$ cfs mkm /coda/usr/tux users:tux



  El usuario ya puede trabajar con el directorio /coda/usr/tux como si
  se tratara de uno tradicional. Despus siempre podr desmontar el
  volumen con la orden:

  cfs rmm /coda/directoriomontaje



  NNoottaa: la versin Coda 5.2.0 tiene problemas si en cfs mkm se indica el
  _p_a_t_h de montaje acabado en '/'. Al parecer se ha conseguido arreglar
  este _b_u_g en versiones posteriores.  Asimismo hemos tenido problemas al
  intentar editar un fichero Coda con el editor emacs (lo hemos
  solucionado trabajando con vi en las pruebas).


  66..22..11..  CCoommaannddoo ccffss


  [SAT97-1] La orden cfs (_C_o_d_a _F_i_l_e _S_y_s_t_e_m _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m) permite a
  los usuarios ejecutar operaciones especficas del Sistema de Ficheros
  Coda. A menudo se utiliza para ver el espacio de almacenamiento
  utilizado y para cambiar los permisos de proteccin de un directorio.
  A continuacin se detallan los opciones de cfs ms importantes:


  1. cfs mkmount <directorio> <nombre-volumen> [-rw]

     Crea un directorio de montaje especificado en <directorio> y monta
     un volumen especificado en <nombre-volumen>. Si se utiliza el _f_l_a_g
     _-_r_w el volumen se monta con permisos de lectura y escritura, ya que
     de otro modo los permisos seran de slo lectura si su volumen
     padre tambin lo es. Ntese que en ambos casos el usuario debe
     tener los privilegios necesarios.

     Abreviatura: mkm


  2. cfs rmmount <dir> [<dir> <dir> ...]

     Elimina uno o ms directorios de montaje (especificados por <dir>)
     del sistema de ficheros. En s mismo el volumen no cambia.

     Abreviatura: rmm


  3. cfs setacl [-clear] [-negative] <dir> <id> <perm> [<id> <perm>
     ....]

     En Coda el concepto tradicional de permisos de usuario, grupo y
     otros desaparece.  En su lugar CODA utiliza las denominadas Listas
     de Control de Acceso (ACL's), las cuales consisten en una serie de
     datos que definen qu usuarios o grupos pueden hacer qu cosas con
     cada elemento de un espacio de direccionamiento Coda. Estos
     permisos [MAR99] constituyen un modelo mucho ms elaborado que los
     tradicionales permisos de ejecucin/lectura/escritura de Unix. Los
     permisos no son establecidos para cada fichero, sino para todos los
     ficheros de un directorio (aunque en la documentacin de la orden
     cfs se aconseja el uso de la orden Unix chmod para cambiar los
     permisos de los ficheros):



     r       Read, permiso de lectura.
     l       Lookup, permiso para obtener el status de un fichero.
     i       Insert, permiso de creacin de ficheros o directorios.
     d       Delete, permiso de borrado.
     w       Write, permiso de modificacin.
     a       Administer, permiso de control de los permiso de acceso.



  Con la orden cfs setacl (cfs sa abreviado) se configura la ACL del
  directorio <dir> para cada usuario identificado por <id> con los
  permisos <perm> _r_l_i_d_w_a explicados anteriormente (_r_e_a_d_, _l_o_o_k_u_p_, _i_n_s_e_r_t_,
  _d_e_l_e_t_e_, _w_r_i_t_e y _a_d_m_i_n_i_s_t_e_r). El _f_l_a_g _-_c_l_e_a_r borra toda la lista de
  control de accesos a excepcin de lo especificado en la propia orden
  cfs.  El _f_l_a_g _-_n_e_g_a_t_i_v_e niega los permisos especificados en la orden
  en lugar de concederlos.

  Abreviatura: sa


  4. cfs listacl <dir> [<dir> <dir> ...]

     Muestra la lista de control de accesos para los directorios dados.

     Abreviatura: la


  5. cfs whereis <dir> [<dir> <dir> ...]

     Lista los servidores donde residen los ficheros especificados.


  6. cfs disconnect

     Desconecta el cliente Coda de los servidores Coda. til por ejemplo
     cuando queramos trabajar localmente desde nuestra cach Coda en
     modo desconectado y aumentar as el rendimiento en los tiempos de
     acceso.


  7. cfs reconnect

     Reconecta el cliente a los servidores Coda, deshaciendo los efectos
     de cfs disconnect.

     NNoottaa:Hasta la versin 5.2.2 de Coda esta orden tena un _b_u_g
     conocido que impeda la reconexin (cfs disconnect pone un software
     de filtrado en los niveles de rpc2 pero reconnect falla al
     borrarlo). Para solucionarlo ejecutar desde el servidor SCM:


       # filcon clear -c hostcliente



  consiguiendo el rid del filtro sin arrancar Venus.


  8. cfs writedisconnect [-age <secs> -time <secs> <dir>]

     Indica a Venus que va a escribir en modo desconectado en los
     volmenes/directorios dados o en todos los volmenes si no se
     especifica ninguno, para lo cual se cargar en la cach los
     ficheros correspondientes de los servidores (no propagar los
     cambios inmediatamente). El argumento _-_a_g_e especifica el tiempo de
     _c_a_c_h_i_n_g en la cach del cliente antes de reintegrar los datos. El
     argumento _-_t_i_m_e proporciona el nmero de segundos que debera
     tardar el envo de un fragmento de reintegracin.


     Abreviatura : wd


  9. cfs writereconnect [<dir> <dir> ...]

     Conexin estricta de los directorios Coda a los servidores.


     Abreviatura : wr


  10.
     cfs examineclosure

     Examina el cierre de reintegracin, mostrando la localizacin de
     los ficheros no reintegrados y modificados durante la desconexin.

     Abreviatura: ec


  11.
     cfs replayclosure

     Repite el cierre de reintegracin (til por ejemplo si falta algn
     fichero con conflictos por reintegrar).

     Abreviatura: rc


  12.
     cfs listcache [<dir> <dir> ...]

     Muestra los contenidos de la cach de los directorios/volmenes
     dados (si no se especifican por defecto se muestra toda la cach).

     Abreviatura: lc


  13.
     cfs listvol <dir> [<dir> <dir> ...]

     Muestra el estado actual del volumen en el que el directorio
     especificado se almacena.

     Abreviatura: lv


  14.
     cfs lsmount <dir> [<dir> <dir> ...]

     Lista los contenidos de un directorio de montaje. Esta orden se
     puede utilizar para conocer a qu volumen se asocia un directorio
     de montaje dado.

  Para ms informacin consultar las man de la orden cfs.


  66..22..22..  RReeppaarraacciinn ddee ccoonnfflliiccttooss


  [SAT97-2] Como se ha explicado en la introduccin, sucede
  ocasionalmente que un directorio se vuelve inconsistente debido a un
  conflicto global, es decir, cuando Coda no puede resolver
  automticamente una replicacin entre servidores de un mismo VSG (por
  ejemplo cuando un mismo grupo de servidores VSG se particiona y un
  mismo fichero se modifica en ms de una de las particiones). Tambin
  es posible una inconsistencia local de algn cliente con respecto al
  estado global (conflicto local/global que se produce en los fallos de
  reintegracin), normalmente porque un cliente desconectado actualiza
  un fichero que tambin ha sido actualizado en los servidores por otro
  cliente. Cuando ocurre algn conflicto de stos, el directorio que
  contiene el conflicto se convertir en un enlace simblico que apunta
  a su fid. Por ejemplo, si el directorio conflicto es inconsistente
  aparecer as:



       $ ls -l conflicto


       lr--r--r-- 1 root     27 Mar 23 14:52 conflicto ->
       @@7f0000b3.00000005.0000011a


  La mayora de las aplicaciones devolvern un error de Fichero no
  encontrado cuando intenten abrir un fichero inconsistente. Para
  resolver este conflicto existe la herramienta repair.


  66..22..22..11..  CCoonnfflliiccttooss sseerrvviiddoorr--sseerrvviiddoorr


  Tras ejecutar repair desde un cliente Coda, es necesario hacer begin
  del objeto inconsistente, tras lo cual el directorio inconsistente
  tendr una entrada por cada uno de los volmenes replicados. Con una
  observacin a estos subdirectorios el usuario podr elegir qu copia
  quiere, y con la orden repair podr copiar la versin correcta y
  eliminar la inconsistencia. En el siguiente ejemplo el fichero
  conflicto/ejemplo.txt est replicado en tres servidores y queremos
  resolver la inconsistencia entre servidores:



       $ ls -lL conflicto


       lr--r--r-- 1 root     27 Dec 20 13:12 conflicto ->
       @@7f0002ec.000000e3.000005d1



  $ repair
  The repair tool can be used to manually repair files and directories
  that have diverging replicas.  You will first need to do a "beginRepair"
  which will expose the replicas of the inconsistent object as its
  children.

  If you are repairing a directory, you will probably use the "compareDir"
  and "doRepair" commands.

  For inconsistent files you will only need to use the "doRepair" command.
  If you want to REMOVE an inconsistent object, use the "removeInc" command.

  Help on individual commands can also be obtained using the "help"
  facility.

  repair> begin conflicto
  a server-server-conflict repair session started
  use the following commands to repair the conflict:
          comparedirs
          removeinc
          dorepair
  repair> ^Z
  Stopped
  $ ls conflicto
  gershwin.coda.cs.cmu.edu        schumann.coda.cs.cmu.edu
  $ ls conflicto/*
  conflicto/gershwin.coda.cs.cmu.edu:
  ejemplo.txt

  conflicto/schumann.coda.cs.cmu.edu:
  ejemplo.txt
  $ fg
  repair
  compare
  Pathname of Object in conflict?  [conflicto]
  Pathname of repair file produced?  []  /tmp/fix

  NAME/NAME CONFLICT EXISTS FOR ejemplo.txt

  -rw-r--r-- 1 tux 0 Dec 20 13:10 gershwin.coda.cs.cmu.edu/ejemplo.txt
  -rw-r--r-- 1 -101 0 Dec 20 13:11 schumann.coda.cs.cmu.edu/ejemplo.txt


  /coda/project/conflicto/gershwin.coda.cs.cmu.edu/ejemplo.txt
          Fid: (0xb0.612) VV:(0 2 0 0 0 0 0 0)(0x8002f23e.30c6e9aa)
  /coda/project/conflicto/schumann.coda.cs.cmu.edu/ejemplo.txt
          Fid: (0x9e.5ea) VV:(2 0 0 0 0 0 0 0)(0x8002ce17.30d56fb9)

  Should /coda/project/conflicto/gershwin.coda.cs.cmu.edu/ejemplo.txt be
  removed?  [no] yes

  Should /coda/project/conflicto/schumann.coda.cs.cmu.edu/ejemplo.txt be
  removed?  [no]

  Do you want to repair the name/name conflicts [yes]
  Operations to resolve conflicts are in /tmp/fix
  repair> do
  Pathname of object in conflict?  [conflicto]
  Pathname of fix file?  [/tmp/fix]
  OK to repair "conflicto" by fixfile "/tmp/fix"?  [no]  yes
  SCHUMANN.CODA.CS.CMU.EDU  succeeded
  GERSHWIN.CODA.CS.CMU.EDU  succeeded
  repair> quit
  $ ls conflicto
  ejemplo.txt
  $ exit
  66..22..22..22..  CCoonnfflliiccttoo llooccaall--gglloobbaall

  El uso de la orden repair es similar al caso anterior. Despus de
  empezar la sesin de reparacin con begin e indicar el _p_a_t_h del objeto
  en conflicto, las rplicas local y global sern visibles en
  pathObjetoEnConflicto/local (slo lectura) y en
  pathObjetoEnConflicto/global (modificable). Con la orden listlocal se
  muestra la lista de todas las modificaciones locales sobre el objeto
  inconsistente o sobre sus descendientes, siendo necesario reparar de
  uno en uno y en el orden de la lista los posibles conflictos de estas
  modificaciones. checklocal nos dice si el primer elemento de la lista
  a tratar tiene algn conflicto o no. El siguiente algoritmo muestra el
  proceso principal de reparacin:



       ______________________________________________________________________
       listlocal (para visualizar la lista)
       para cada elemento de la lista listlocal hacer
           checklocal(se refiere al primer elemento de la lista de modificaciones
                      locales)
           si el elemento a tratar tiene conflicto:
               resolver conflicto
           sino
               decidir si queremos preservar la copia local en el servidor
           finsi
       ______________________________________________________________________



  Con discardlocal se descarta la copia local preservando la del
  servidor, y con preservelocal la copia que se preserva es la local.
  Ambas opciones se pueden utilizar tanto si se trata de un conflicto
  como si no (ambos casos del _i_f del algoritmo). Para acelerar el
  proceso existen las rdenes preservealllocal (preserva todos los
  elementos del objeto en conflicto)  y discardalllocal (todos los
  elementos modificados localmente se desechan para preservar el estado
  global del servidor).

  Se pueden utilizar herramientas o editores como vi para actualizar
  convenientemente la rplica global del objeto en conflicto, ya que
  como se ha dicho antes, la rplica global es la nica modificable. La
  orden quit se utiliza para comprometer o abortar la sesin de
  reparacin. Las pginas man ofrecen informacin ms detallada acerca
  de estas rdenes de reparacin. En el siguiente ejemplo se ilustra el
  proceso de reparacin de un conflicto local/global, en el cual se
  supone que durante la desconexin un usuario crea un nuevo directorio
  /coda/usr/tux/doc y actualiza el fichero /coda/usr/tux/fichero.txt.
  Simultneamente otro usuario con permisos tambin crea un directorio
  /coda/usr/tux/doc y almacena varios ficheros en l, producindose el
  conflicto local/global del objeto /coda/usr/tux durante la
  reintegracin:



  tux@clientecoda$ ls -l /coda/usr/tux/doc
  lr--r--r-- 1 root 27 Dec 20 00:36 doc -> @@7f000279.00000df3.0001f027

  tux@clientecoda$ repair
  repair> begin
  Pathname of object in conflict?  []  /coda/usr/tux
  a local-global-conflict repair session started
  the conflict is caused by a reintegration failure
  use the following commands to repair the conflict:
          checklocal
          listlocal
          preservelocal
          preservealllocal
          discardlocal
          discardalllocal
          setglobalview
          setmixedview
          setlocalview
  a list of local mutations is available in the .cml file in the coda
  spool directory

  repair> !ls -l /coda/usr/tux/
  total 4
  drwxr-xr-x  3 tux         2048 Dec 20 00:51 global
  drwxr-xr-x  3 tux         2048 Dec 20 00:51 local


  repair> listlocal
  local mutations are:

  Mkdir   /coda/usr/tux/local/doc
  Store   /coda/usr/tux/local/fichero.txt (length = 19603)

  repair> checklocal
  local mutation: mkdir /coda/usr/tux/local/doc
  conflict: target /coda/usr/tux/global/doc exist on servers

  repair> discardlocal
  discard local mutation mkdir /coda/usr/tux/local/doc

  repair> checklocal
  local mutation: store /coda/usr/tux/local/fichero.txt
  no conflict

  repair> preservelocal
  store /coda/usr/tux/global/fichero.txt succeeded

  repair> checklocal
  all local mutations processed

  repair> quit
  commit the local/global repair session?  [yes]
  reintegrate



  66..22..33..  OOttrraass rrddeenneess


  Otras rdenes importantes a tener en cuenta son:


    cliente:

       hoard: hoard database front-end. _F_r_o_n_t_-_e_n_d de la base de datos
        Hoard (HDB), con el cual es posible aadir un fichero a la base
        de datos Hoard, borrar un fichero, listar el contenido del HDB,
        o modificar los atributos de un fichero hoard.

       ctokens: lista los tokens del usuario con la fecha de
        expiracin, la identificacin del usuario y si est o no
        autenticado.


    Servidor:

       filcon: utilidad de control de filtrado RPC2. Por ejemplo se
        puede aislar un servidor con:


          filcon isolate -s nombre-servidor



     y deshacer esta operacin con:


          filcon clear nombre-servidor.



  66..33..  HHeerrrraammiieennttaass ddee mmoonniittoorriizzaacciinn


  Existen herramientas de monitorizacin del sistema Coda que ayudan a
  comprobar su correcto funcionamiento. Las siguientes herramientas se
  utilizan desde el cliente Coda:


    cmon


     para monitorizar desde un cliente el estado de los servidores Coda,
     til entre otras cosas para comprobar la conexin entre un cliente
     y sus servidores. Por ejemplo, con


       cmon -t 1 sipt30 sipt31



  se comprueba y se visualiza cada segundo el estado de los servidores
  sipt30 y sipt31. Si un servidor no es accesible se visualizar una
  interrogacin en los resultados estadsticos referentes al diagnstico
  de un mismo servidor.


    codacon

     para visualizar las acciones del cliente.


    Ficheros _l_o_g del cliente:



  $ tail -f /usr/coda/venus.cache/venus.log
  $ tail -f  /usr/coda/etc/console



  Como ya se ha mencionado anteriormente, los servidores Coda guardan
  sus ficheros _l_o_g en /vice/srv/.


  77..  PPrruueebbaass rreeaalliizzaaddaass yy rreessuullttaaddooss


  Para nuestras pruebas con el Sistema Coda hemos dispuesto de dos
  servidores Coda y un cliente Coda. Los dos servidores forman parte de
  un mismo VSG replicado con identificador E0000100 y coinciden con la
  configuracin del ejemplo de configuracin utilizado en este
  documento.

  El cliente Coda funciona perfectamente en modo conectado actualizando
  inmediatamente los cambios del cliente en los servidores. Sin embargo
  tras una desconexin la reintegracin no se produce inmediatamente y
  puede llegar a tardar un tiempo variable (este proceso sigue siendo
  transparente para el usuario).

  Cuando uno de los servidores cae o resulta inaccesible durante un
  periodo de tiempo en el que el otro servidor se ha modificado, el
  primero tambin tarda un tiempo variable en actualizarse tras su
  reconexin e igualmente resulta transparente para el usuario.

  Hemos probado todas las configuraciones expuestas en este documento.
  Sin embargo Coda es un sistema relativamente complejo y no hemos
  trabajado con la base de datos Hoard ni con el sistema de copias de
  seguridad de Coda.  Existen mltiples configuraciones y pruebas a
  realizar pero hemos preferido centrarnos en sus caractersticas ms
  relevantes: la replicacin y la computacin mvil.


  88..  BBiibblliiooggrraaffaa


  [[BBRRAA9988]] PPeetteerr JJ.. BBrraaaamm:: _T_h_e _C_o_d_a _D_i_s_t_r_i_b_u_t_e_d _F_i_l_e _S_y_s_t_e_m.
  http://coda.cs.cmu.edu/ljpaper/lj.html.School of Computer Science,
  Carnegie Mellon University, february 1998.

  [[HHAARR9988]] JJaann HHaarrkkeess:: _U_s_e_r _A_d_m_i_n_i_s_t_r_a_t_i_o_n _i_n _C_o_d_a _5_._2_._x.
  http://coda.cs.cmu.edu/doc/html/pdbtool-mini-howto.html.  School of
  Computer Science, Carnegie Mellon University, 1998.

  [[MMAARR9999]] JJuuaann AAnnttoonniioo MMaarrttnneezz:: _E_l _s_i_s_t_e_m_a _d_e _f_i_c_h_e_r_o_s _C_o_d_a.
  Revista _L_i_n_u_x _A_c_t_u_a_l n 9, pginas 20-22, diciembre 1999.

  [[SSAATT9977--11]] MM.. SSaattyyaannaarraayyaannaann,, MMaarriiaa RR.. EEbblliinngg,, JJoosshhuuaa RRaaiiffff,, PPeetteerr JJ..
  BBrraaaamm:: _C_o_d_a _F_i_l_e _S_y_s_t_e_m_. _U_s_e_r _a_n_d _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_o_r_s _M_a_n_u_a_l _(_E_.
  _U_n_i_x _M_a_n_u_a_l _P_a_g_e_s_).
  http://coda.cs.cmu.edu/doc/html/manual-19.html.  School of Computer
  Science, Carnegie Mellon University, august 1997.

  [[SSAATT9977--22]] MM.. SSaattyyaannaarraayyaannaann,, MMaarriiaa RR.. EEbblliinngg,, JJoosshhuuaa RRaaiiffff,, PPeetteerr JJ..
  BBrraaaamm:: CCooddaa FFiillee SSyysstteemm.. UUsseerr aanndd SSyysstteemm AAddmmiinniissttrraattoorrss MMaannuuaall ((33..66
  RReeppaaiirriinngg aann IInnccoonnssiisstteenntt DDiirreeccttoorryy))..
  http://coda.cs.cmu.edu/doc/html/manual-3.html.  School of Computer
  Science, Carnegie Mellon University, august 1997.



  99..  AAggrraaddeecciimmiieennttooss


  A Alberto Lafuente y a Igor Armendariz, profesores de la Facultad de
  Informtica de San Sebastin de la Universidad Pblica del Pas Vasco.
  Gracias a ellos hemos dispuesto de los mejores recursos en el
  Laboratorio E04 de la facultad para Instalar Debian en tres equipos y
  probar Coda.Tambin queremos agradecer la importante valoracin de
  este documento dentro de la asignatura Sistemas Distribuidos (gracias
  Alberto!). Sin la ayuda de ambos este _C_O_M_O nunca hubiera existido.

  A Francisco Jos Montilla Blanco del Insflug, por ayudarme con el sgml
  y con mis mltiples preguntas sobre los _C_O_M_O_s.

  A Juan Antonio Martnez, por permitirme refundir algunos prrafos de
  su artculo _E_l _s_i_s_t_e_m_a _d_e _f_i_c_h_e_r_o_s _C_O_D_A.

  Y en general a todos aquellos que creen en mi.


  1100..  AAnneexxoo:: EEll IINNSSFFLLUUGG


  El _I_N_S_F_L_U_G forma parte del grupo internacional _L_i_n_u_x _D_o_c_u_m_e_n_t_a_t_i_o_n
  _P_r_o_j_e_c_t, encargndose de las traducciones al castellano de los Howtos,
  as como de la produccin de documentos originales en aquellos casos
  en los que no existe anlogo en ingls, centrndose, preferentemente,
  en documentos breves, como los _C_O_M_O_s y _P_U_F_s (PPreguntas de UUso
  FFrecuente, las _F_A_Q_s. :) ), etc.

  Dirjase a la sede del Insflug para ms informacin al respecto.

  En lla encontrar siempre las llttiimmaass versiones de las traducciones
  oficiales:  www.insflug.org. Asegrese de comprobar cul es la
  ltima versin disponible en el Insflug antes de bajar un documento de
  un servidor rplica.

  Adems, cuenta con un sistema interactivo de gestin de fe de erratas
  y sugerencias en lnea, motor de bsqueda especfico, y ms servicios
  en los que estamos trabajando incesantemente.

  Se proporciona tambin una lista de los servidores rplica (_m_i_r_r_o_r)
  del Insflug ms cercanos a Vd., e informacin relativa a otros
  recursos en castellano.

  En http://www.insflug.org/insflug/creditos.php3 cuenta con una
  detallada relacin de las personas que hacen posible tanto esto como
  las traducciones.

  Dirjase a http://www.insflug.org/colaboracion/index.php3 si desea
  unirse a nosotros!.

  Francisco Jos Montilla, pacopepe@insflug.org.



