Todos los servidores deben tener la misma versión Coda para evitar problemas. La versión de los clientes puede ser anterior a la de los servidores pero mayor que una dada (dependiendo de la versión del servidor, aunque es conveniente que todas las versiones coincidan).
También es aconsejable instalar Coda a partir de los paquetes binarios
para evitar compilar el código fuente. Existen binarios para las dos
distribuciones Linux más utilizadas, Debian
http://www.debian.org y Red Hat
http://www.redhat.com. El código 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 versión 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
En este informe se ha utilizado la versión 5.2.0-1 de Coda bajo Debian 2.1 slink. Existe en binario la versión 5.3.1-1 para Debian 2.2, pero hemos optado por la primera para evitar actualizar Linux. Aún así suponemos que entre ambas versiones no existen cambios importantes en la instalación y administración.
También hemos trabajado con la versión Coda de Red Hat, aunque
recomendamos la de Debian por ser más fácil su instalación y
administración. Por ejemplo, en Debian el programa de instalación pasa
automáticamente a su configuración y el servidor Coda se lanza con el
script /etc/init.d/coda-server, mientras que en Red Hat son
varios los scripts.
Los servidores deben estar sincronizados en fecha y hora. Para lograrlo
hemos optado por XNTP, basado en sincronización externa UTC
(Tiempo Universal Coordinado). En el caso de dos servidores Coda hay que
añadir las siguientes líneas en sus ficheros de configuración
ntp.conf del programa xntp (en Debian este fichero se
encuentra en el directorio /etc/):
server máquinaServidorXntp1
server máquinaServidorXntp2
peer servidorCoda2
server máquinaServidorXntp1
server máquinaServidorXntp2
peer servidorCoda1
Las dos primeras líneas de cada configuración especifican con qué servidor o servidores xntp se sincronizan. Si por redundancia se sincronizan con más de un servidor xntp como en el ejemplo, estos servidores deben tener el mismo nivel xntp garantizando la sincronización entre sí. La tercera línea
peer servidorCodax
De todos los servidores Coda sólo uno puede ser el servidor
SCM, desde donde se administra el sistema de volúmenes y las
cuentas de usuario.
Se explicarán los procesos de instalación y configuración de las versiones 5.2.0-1 para Red Hat y Debian. Nótese que para la instalación y configuración de los servidores es necesario ser el superusuario del sistema Linux.
Se procederá a instalar el paquete, para lo que introduciremos por la línea de órdenes:
# rpm -i coda-debug-server-5.2.0-1.i386.rpm
Una vez instalado el servidor, iniciaremos su configuración, la cual difiere entre el servidor maestro SCM y el resto de servidores.
# vice-setup
A continuación se detalla el proceso de configuración con
vice-setup. Introducimos una cadena de 8 caracteres (debe ser
exactamente de 8 caracteres para evitar problemas causados por un posible
bug 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 bug), 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 configuración 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 hubiéramos contestado «y» a esta pregunta , y posteriormente comentaremos las diferencias que habría 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 añadirlos 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 (Volume Storage Group) del servidor
que se está configurando, asignándosele un identificador (el valor por
defecto es el E0000100). Toda la información correspondiente a
los grupos de servidores se guarda en el fichero /vice/db/VSGDB.
Si se quiere añadir 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 rootvolume, que es el volumen que se
montará como raíz 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 contraseña inicializada a
changeme. Si se quiere cambiar habrá que utilizar o bien
cpasswd o la utilidad de administración 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 instalación 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 caída:
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 partición o fichero que se va a utilizar como
log (por ejemplo /dev/hda4 para una partición o
/codap/logpartition en el caso de un fichero):
What is your log partition? /dev/hda4
En la partición de log (log partition) se registran las transacciones de volúmenes coda que quizás no hayan sido aún actualizadas en la partición de datos coda. No debe sobrepasar los 30MB (el sistema coda no ha sido puesto a prueba con tamaños mayores a éste) y es aconsejable tener una partición de 2MB (lo merjo es ceñirse a lo que se indica en la instalación). Nunca se debe tener una partición menor que el tamaño indicado en la instalación (por ejemplo si la partición es de 11.6MB y en la instalación se indica que tiene 12MB, puede fallar la instalación):
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
Elección de la partición de datos RVM (data partition). Indicar una
partición (/dev/hdxx) o el nombre de un archivo:
What is your data partition (or file)? /dev/hda5
Se indicará el tamaño de la partición de datos. Recomendamos
encarecidamente que se utilice uno de los valores dados por el
script, ya que únicamente así se hará una configuración válida de las
particiones (si se opta por poner otro tamaño de partición se deberá
inicializar la partición de datos mediante el programa rdsinit.
Este programa es difícil de manejar, siendo aconsejable poner el tamaño
de la partición que viene por defecto en la instalación). Si se pone una
partición menor que 22MB puede fallar la instalación. El script es muy
sensible a las mayúsculas y minúsculas, por lo que es importante poner
22M y no 22m al indicar el tamaño de la partición:
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 confirmación 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 guardarán los datos
de los volúmenes 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 número 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 ejecución 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 están 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 parámetro la cláusula «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 pequeña modificación
añadiendo "> /dev/null" al final de la
línea 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 log:
$ tail -f /vice/srv/SrvLog &
El siguiente paso es instalar el resto de los servidores no-SCM y configurarlos.
La configuración de un servidor no SCM es prácticamente idéntica a la del servidor maestro, aunque se omiten una serie de pasos (los de la creación de usuarios y especificación del volumen root).
Es importante indicar que por razones de seguridad todos los servidores de un mismo VSG deberán tener los mismos tokens de autentificación.
En esta ocasión no se pedirá un número de identificación del servidor
(tenemos que introducirlo antes o después en /vice/db/servers de
la máquina SCM), pero sí se nos preguntará la ruta a la máquina
maestra (dirección IP ó nombre de la máquina).
Tenemos que configurar, de igual manera, los RVM's (particiones log y de datos). Tras terminar con la configuración 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
La instalación 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 instalación del paquete lanza el programa de configuración
vice-setup, que es idéntico al de la distribución Red Hat
(la única diferencia es que éste lanza los demonios directamente).
Una vez hecha la configuración (siguiendo los mismos pasos que hemos
descrito en el apartado anterior para Red Hat) estarán lanzados todos los
demonios a excepción de startserver y codasrv (los
cuales habrá que lanzar a mano con startserver &).
Para que estos dos demonios se ejecuten automáticamente 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 (nótese que la ruta del script cambia con respecto a la ruta de Red Hat):
/etc/init.d/coda-server stoppara parar el servidor Coda.
/etc/init.d/coda-server startpara iniciarlo.
Tras todo esto ya sólo nos queda configurar los servidores desde el SCM para que Coda empiece a funcionar correctamente.
Los volúmenes son unidades de información que permiten gestionar conjuntamente los datos que contienen. Es posible que un volumen pertenezca sólo a un servidor (volumen no replicado) y que sólo unos pocos usuarios puedan leer y escribir sobre él. También es posible que un volumen pertenezca a más de un servidor (volumen replicado) y que todos los usuarios coda puedan leer y escribir sobre él.
El primer paso para configurar los servidores es crear el volumen root desde el SCM (el único que puede crear y borrar volúmenes) con una de las siguientes órdenes:
# createvol_rep coda:root E0000100 /vicepa
# createvol coda:root sipt30 /vicepa
En ambos casos el volumen root 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 root).
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 añadir nuevos servidores a este VSG (al que
inicialmente sólo 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 cuáles son los
identificadores de cada servidor (el del SCM ya ha sido escogido durante
el proceso de instalación). 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 añadir o eliminar un nodo del grupo de servidores.
Cuando se conecten los servidores No-SCM, se actualizarán por la red
sus ficheros del directorio /vice (los ficheros de configuración
del servidor) incluyendo los dos anteriores.
Al igual que el root volume, el servidor SCM puede crear
otros volúmenes necesarios con createvol_rep (volúmenes
replicados) o con createvol (volúmenes locales al servidor sin
replicar). De este modo podemos encontrarnos con la siguiente
configuración del fichero /vice/db/VSGDB:
E0000100 ha0 ha1
E0000200 ha1
donde los servidores ha0 y ha1 pertenecen al grupo
E0000100 y sólo ha1 pertenece al grupo E0000200
(aunque el identificador pertenezca a un volumen replicado).
Para eliminar un volumen se utiliza la orden purgevol (para
volúmenes no replicados) o purgevol_rep (para volumenes replicados),
que sólo puede ser ejecutada desde el servidor SCM:
# purgevol_rep NombreVolumen
La información almacenada en los servidores Coda está organizada en varios directorios, que están descritos a continuación:
/vice/auth2 Este directorio contiene información
relacionada con el proceso de autenticación, incluyendo sus ficheros
log. /vice/bin Contiene los binarios del sistema de ficheros
Coda para los servidores y el SCM. /vice/db Contiene las bases de datos con información
importante para los servidores y los ficheros log de las
actualizaciones. /vice/vol Contiene información de los volúmenes Coda. /vice/vol/remote Existe sólo en el SCM y contiene
información de todos los servidores remotos. /vicepa (si no se ha cambiado por otro directorio
durante la instalación) se guardan los datos de los volúmenes Coda que
tiene el servidor. La información se guarda en forma de ficheros que se
distribuyen a lo largo de un árbol de directorios codificado
numéricamente. Consideramos interesante reseñar que en nuestro caso los
ficheros comenzaban a guardarse ordenadamente en el directorio
/vicepa/0/0/, aunque desconocemos el sistema de codificación.
El cliente debe instalar dos cosas: un módulo del núcleo 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 máquina, por lo que debemos evitar que ocurra.
Para que el cliente tenga acceso al sistema de ficheros distribuido Coda es necesario que el Núcleo lo reconozca. Esto se puede conseguir de varias formas:
coda.o que
podremos cargar y descargar del Núcleo cuando queramos.
coda.o mencionado antes compilando el código fuente
de Coda (normalmente se encuentra en el fichero
linux-coda-(versión).tgz) Si nos hemos decidido por trabajar con el módulo coda (opciones 1 y 2), dicho módulo no se cargará en memoria una vez arrancado Linux. Para cargarlo en memoria existen varios métodos, por ejemplo:
# insmod coda
/etc/modules la línea
coda).
/etc/modules la línea
auto).Nota: el módulo coda.o debe encontrarse en
/lib/modules/versionNúcleo/fs, donde «versionNúcleo» es la
versión del núcleo de Linux (para consultar la versión del
núcleo desde la línea de órdenes probar con uname -r).
La instalación del cliente a partir de un paquete binario Linux se realiza de distinta forma dependiendo de la distribución a la que pertenece:
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
script venus-setup:
# /usr/bin/venus-setup <lista_de_hosts_separados_por_comas>
<tamaño_de_caché_en_kb>
con lo que decimos a Venus cuál es su lista de servidores Coda a los
que debe conectarse. También inicializa un directorio para utilizarlo como
caché de disco del cliente Coda, con el tamaño indicado en el script
venus-setup (para empezar se recomienda un a pequeña caché de 20 MB,
aunque funciona bien hasta 300 MB). Asimismo venus-setup creará el
dispositivo /dev/cfs0 para comunicarse con el Núcleo y
dejará todos los ficheros del cliente Coda en el directorio
/usr/coda.
También sería recomendable probar nuestro cliente Coda con el servidor
Coda
testserver.coda.cs.cmu.edu, aunque deberá asegurarse que no
tiene ningún firewall que le impida comunicarse con él. Una caché de
20000 es aconsejable para probar este servidor.
Tras la instalación del paquete binario se puede lanzar Venus en background con la orden:
# venus &
y se puede parar con
# kill -9 venus
vutil shutdown
umount /coda
Aunque una manera más limpia de lanzar y parar Venus es desde su
script de inicio /etc/rc.d/init.d/venus.
Nota: Antes de volver a lanzar Venus el directorio /coda
debe ser desmontado. Si esto diera problemas asegúrese de matar todos los
procesos que cuelgan de Coda, por ejemplo cuando tenemos ficheros de Coda
abiertos por una aplicación o porque estamos dentro del directorio
/coda. Las utilidades lsof y fuser pueden
ayudarnos para solucionar estas cosas.
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 instalación. Aún así siempre
se puede utilizar venus-setup y venus & para una posterior
configuración.
/etc/init.d/coda-client es el script que lanza y para el demonio
Venus.
A continuación se describe el proceso de desinstalación de un servidor Coda, útil cuando nos hemos equivocado en el proceso de instalación o configuración y queremos volver a empezar.
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 ejecución lo podemos parar con:
kill -9 pid
pid es el identificador del proceso que aparece indicado al
ejecutar ps.
Ahora ya nos hemos asegurado de que no hay ningún proceso del servidor coda en funcionamiento, por lo que podemos proceder a la desinstalación del paquete.
# rpm -e coda-debug-server-5.2.0-1
Por último, sólo 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
/vicepa y
/vice.
Comenzaremos por dar de baja a todos los demonios:
# /etc/init.d/coda-server stop
El resto del proceso es idéntico 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.
El cliente es mucho más sencillo y es suficiente con desinstalar el
paquete binario de la distribución (orden rpm en Red Hat y
dpkg en Debian). Asimismo la desinstalación del módulo Coda del
núcleo dependerá del proceso escogido para su instalación.