Installation on RH 9 -------------------- The following RPMs are necessarily to be installed (from http://www.coda.cs.cmu.edu/pub/coda/linux/RedHat-9.0/): 1) lwp 2) rpc2 3) rvm 4) rvm-tools 4) coda-server (or coda-debug-server) Configuration and utilities --------------------------- * venus-setup - for client configuration * vice-setup - for SCM configuration * pdbtool - for managing Coda users on SCM machine * au - for authenticating on client machine * clog, cunlog, cpasswd, cmon - client machine functions for logging as Coda user, changing the password etc. * cfs - file system interface utilities on client machine * rvmutl - checks status of RVM log and data by 'open_log logfile', 'status' commands sequence Starting server --------------- * /etc/rc.d/init.d/auth2.init start * /etc/rc.d/init.d/update.init start * /etc/rc.d/init.d/codasrv.init start or * /usr/sbin/codastart Starting client --------------- * /usr/sbin/venus & Stopping server --------------- * /etc/rc.d/init.d/codasrv.init stop * /etc/rc.d/init.d/update.init stop * /etc/rc.d/init.d/auth2.init stop Stopping client --------------- * vutil shutdown * umount /coda Realms ------ * Must be defined for client in /etc/coda/realms (or defined in '/etc/coda/venus.conf'). For example, replicated ds-i1.cs.technion.ac.il ds-i3.cs.technion.ac.il Creating/purving volume on SCM ------------------------------ * createvol_rep / / ... For example, createvol_rep ReplicatedVolume ds-i1/vicepa ds-i3/vicepa * purgevol_rep --kill purges the volume from all the servers, it has been deployed on Adding a server to cell ----------------------- 1. Your server needs a unique server number, to be added to the /vice/db/servers file on SCM 2. This step is obsolete since release 6.0.7 of Coda * Make two new entries in the /vice/db/VSGDB file. One for your new server by itself, one of the form: E0000104 scm-server second-server. E0000104 is an example of unique id assigned to the Storage Group containing our two servers. Each set of servers that contains replicated volumes should be assigned its unique id 3. Start updatesrv and updateclnt on the second server 4. Start codasrv on the second server 5. Make a new volume using createvol_rep giving the unique address of the volume, for example: createvol_rep E0000104 ds-i1/vicepa ds-i3/vicepa 6. Mount the volume on the client, for example: cfs mkmount /coda/replicated/ReplicatedVolume ReplicatedVolume or, alternatively, just authorize using 'clog', for example: clog coda (default password is 'changeme') Checking the replication feature -------------------------------- To temporarily disable a server, and see that things continue to function normally, either shut the server down with volutil shutdown or disconnect its network. You can also isolate the server using our network filters with filcon isolate -s Using filcon clear clears the filter. Troubleshooting --------------- * Several solutions can be found here - http://coda.wikidev.net/Common_error_messages * Generally it is advisable to use full qualified host names wherever possible * Error : 'Version Skew with kernel' Solution: upload right coda.o to the kernel * Error : in the client machine the /coda subdirectory, which stands for the realm to which the client connects, is broken (appears as symbolic link) Solution: createvol_rep / on SCM ************************************************************************************************************* Coda issues ----------- 1. Installation 1.1 System Control Machine (SCM) - main server, containing and maintaining all Coda metadata database * Installation order: lwp, rpc2, rvm, rvm-tools, coda-server (or coda-debug-server) 1.2 Non-SCM server 1.3 Client * On Linux 2.4.21-40 requires recompilation of coda.o in order to dynamically load into the kernel modules. The rpms for Coda client on Linux are not relocatable, so that in order to install it one must possess the superuser privileges. Installation order: lwp, rpc2, rvm, coda-client (or coda-debug-client) After installing rpms one must upload the correct coda.o file to dynamic kernel modules by insmod coda.o After starting 'venus' on client, one must log in as Coda user (for instance, 'clog coda') in order to see the realms in '/coda' 1.4 Installation in user space * Impossible per se, talk with Mark about workarounds 2. Volume groups 2.1 Adding/removing replication server to a volume group * As described in 'Adding a server to cell' chapter 2.2 Basic functionality 2.2.1 Creating a new file * While one of the replication servers is not synchronized, file writing may cause I/O error, after which it becomes possible to store a file 2.2.2 Removing a file 2.2.3 Modifying a file 2.2.4 Failing one of the replication servers, doing one of the above points (2.2.1-2.2.3), raising the failed server back and checking the synchronization 2.2.5 Simulate a conflict in some replicated file and checking how it can be fixed by means of Coda semi-automatic conflict resolution mechanism * 'repair' tool on client offers variety of methods to solve the emerging conflicts, such as to discard the worst replica or to show all the possibilities and after fixing the conflict replacing the conflict with the correct replica * Common Coda error messages and conflict-related solutions can be found here: http://coda.wikidev.net/Common_error_messages 3. Users 3.1 Adding/removing Coda user to users' database * By means of 'pdbtool' on SCM machine 3.2 Security of users' files * By means of Coda ACLs 4. Extending/customizing Coda functionality 4.1 Software APIs 4.2 Understanding and extending the very Coda code 4.3 Integration with Condor/Demo program for Coda proof of correctness for HA and replication/Demo program for dynamically building the Coda DFS by means of Condor 5. Miscellaneous 5.1 Coda scalability 5.2 Support issues: mailing lists, maybe, support groups in Carnegie Mellon University * coda-announce-request@coda.cs.cmu.edu * codalist-request@coda.cs.cmu.edu *************************************************************************************************************