Página siguiente Página anterior Índice general

6. Administración

6.1 Creación de cuentas de usuario

[HAR98] Una vez instalados y configurados correctamente los servidores Coda debemos crear las cuentas de los usuarios Coda. Para ello emplearemos la orden interactiva pdbtool. Las órdenes más 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

añade un usuario o grupo a un grupo.

n usuario/nombregrupo

lista toda la información 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 operación 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 también 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 contraseña desde cualquier servidor, autenticándose antes como el administrador de Coda (durante la instalación del SCM se ha solicitado el nombre y la contraseña de la cuenta de administración, que en nuestro caso son admin y changeme respectivamente): 

            
admin@cualquiermáquina$ au -h scm nu
Your Vice Name: admin
Your Vice Password: ********
New User Name: tux
New User Password: nuevaContraseña

A continuación creamos un home volume replicado llamado users:tux con VSG E0000100, lo montamos, le asignamos todos los permisos de usuario posibles sobre ese volumen (ver siguiente sección orden cfs, donde en el apartado 3 se explican los permisos de Coda), y lo desmontamos. Nótese 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@cualquiermáquina$ cfs mkm /coda/usr/tux users:tux
admin@cualquiermáquina$ cfs sa /coda/usr/tux tux all
admin@cualquiermáquina$ cfs rmm /coda/usr/tux

Finalmente el usuario tux podrá cambiar su contraseña desde cualquier máquina cliente Coda con: 

tux@cualquiermáquina$ cpasswd -h scm

siendo SCM la máquina SCM del sistema Coda.

6.2 Acceso a las cuentas y órdenes

Si todo va bien el cliente debería ser capaz de montar el sistema de ficheros Coda bajo el directorio /coda (donde se monta el volumen root). Si existe el fichero /coda/NOT_REALLY_CODA entonces aún 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 user es el nombre de usuario o login. Desde cualquier máquina con cliente Coda: 

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

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

tux@cualquiermáquina$ 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. Después siempre podrá desmontar el volumen con la orden: 

cfs rmm /coda/directoriomontaje

Nota: la versión Coda 5.2.0 tiene problemas si en cfs mkm se indica el path de montaje acabado en '/'. Al parecer se ha conseguido arreglar este bug 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).

Comando cfs

[SAT97-1] La orden cfs (Coda File System Interface Program) permite a los usuarios ejecutar operaciones específicas del Sistema de Ficheros Coda. A menudo se utiliza para ver el espacio de almacenamiento utilizado y para cambiar los permisos de protección de un directorio. A continuación se detallan los opciones de cfs más 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 flag -rw el volumen se monta con permisos de lectura y escritura, ya que de otro modo los permisos serían de sólo lectura si su volumen padre también lo es. Nótese que en ambos casos el usuario debe tener los privilegios necesarios.

    Abreviatura: mkm

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

    Elimina uno o más 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 más elaborado que los tradicionales permisos de ejecución/lectura/escritura de Unix. Los permisos no son establecidos para cada fichero, sino para todos los ficheros de un directorio (aunque en la documentación 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 creación de ficheros o directorios.
d       Delete, permiso de borrado.
w       Write, permiso de modificación.
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> rlidwa explicados anteriormente (read, lookup, insert, delete, write y administer). El flag -clear borra toda la lista de control de accesos a excepción de lo especificado en la propia orden cfs. El flag -negative 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.

    Nota:Hasta la versión 5.2.2 de Coda esta orden tenía un bug conocido que impedía la reconexión (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 volúmenes/directorios dados o en todos los volúmenes 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 -age especifica el tiempo de caching en la caché del cliente antes de reintegrar los datos. El argumento -time proporciona el número de segundos que debería tardar el envío de un fragmento de reintegración.

    Abreviatura : wd

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

    Conexión estricta de los directorios Coda a los servidores.

    Abreviatura : wr

  10. cfs examineclosure

    Examina el cierre de reintegración, mostrando la localización de los ficheros no reintegrados y modificados durante la desconexión.

    Abreviatura: ec

  11. cfs replayclosure

    Repite el cierre de reintegración (útil por ejemplo si falta algún fichero con conflictos por reintegrar).

    Abreviatura: rc

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

    Muestra los contenidos de la caché de los directorios/volúmenes 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 más información consultar las man de la orden cfs.

Reparación de conflictos

[SAT97-2] Como se ha explicado en la introducción, sucede ocasionalmente que un directorio se vuelve inconsistente debido a un conflicto global, es decir, cuando Coda no puede resolver automáticamente una replicación entre servidores de un mismo VSG (por ejemplo cuando un mismo grupo de servidores VSG se particiona y un mismo fichero se modifica en más de una de las particiones). También es posible una inconsistencia local de algún cliente con respecto al estado global (conflicto local/global que se produce en los fallos de reintegración), normalmente porque un cliente desconectado actualiza un fichero que también ha sido actualizado en los servidores por otro cliente. Cuando ocurre algún conflicto de éstos, el directorio que contiene el conflicto se convertirá en un enlace simbólico 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 mayoría de las aplicaciones devolverán un error de «Fichero no encontrado» cuando intenten abrir un fichero inconsistente. Para resolver este conflicto existe la herramienta repair.

Conflictos servidor-servidor

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 volúmenes replicados. Con una observación a estos subdirectorios el usuario podrá elegir qué copia quiere, y con la orden repair podrá copiar la versión 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

Conflicto local-global

El uso de la orden repair es similar al caso anterior. Después de empezar la sesión de reparación con begin e indicar el path del objeto en conflicto, las réplicas local y global serán visibles en pathObjetoEnConflicto/local (sólo 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 algún conflicto o no. El siguiente algoritmo muestra el proceso principal de reparación: 

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 if 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 réplica global del objeto en conflicto, ya que como se ha dicho antes, la réplica global es la única modificable. La orden quit se utiliza para comprometer o abortar la sesión de reparación. Las páginas man ofrecen información más detallada acerca de estas órdenes de reparación. En el siguiente ejemplo se ilustra el proceso de reparación de un conflicto local/global, en el cual se supone que durante la desconexión un usuario crea un nuevo directorio /coda/usr/tux/doc y actualiza el fichero /coda/usr/tux/fichero.txt. Simultáneamente otro usuario con permisos también crea un directorio /coda/usr/tux/doc y almacena varios ficheros en él, produciéndose el conflicto local/global del objeto /coda/usr/tux durante la reintegración: 

        
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

Otras órdenes

Otras órdenes importantes a tener en cuenta son:

6.3 Herramientas de monitorización

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

Como ya se ha mencionado anteriormente, los servidores Coda guardan sus ficheros log en /vice/srv/.

Página siguiente Página anterior Índice general