Client Binary Installer

From Codawiki

Obtain and Install Coda Client

The following takes just a few seconds and should work on virtually any Linux distribution. It has been tested e.g. on Debian, Ubuntu and Red Hat Enterprise Linux. RHEL was the only one which needed a separate compile and installation of the kernel module, not described here. (Module compilation is documented at Quick_Kernel_Module_Action).

Download a client installer corresponding to your architecture from

http://www.aetey.se/index.php?Static&pg=CodaInstHowto

Make the downloaded file executable and run it as root:

chmod +x cocli-1.7-20080111-linux-ia32-0.bin
./cocli-1.7-20080111-linux-ia32-0.bin

Just press Enter when asked.

Otherwise you may also run ./cocli.... help

After the installation is complete (in a couple of seconds), you need to start Coda client:

codaclient start

Now you are running Coda!

Note: do not try to be overly creative and directly run the binaries you may find in the installed .<something>/ directory.

• codaclient start/stop is the only sane way to start and stop the client.
• ./cocli.... --init/--fullinit is the only sane way to reinitialize the client.
• The new entries in /bin (or otherwise what you may have chosen with ./cocli.... --bin <yourchoice>) are the only sane way to run the corresponding commands.

Another warning, do not try to keep different Coda clients on the same machine, always fully remove the old one, if any. Otherwise sooner or later you will run a wrong binary and possibly mess up the client state.

To make the Coda client itself start at system boot (on Debian/Ubuntu) use

ln -s /bin/codaclient /etc/init.d
update-rc.d codaclient defaults

FIXME: describe how to arrange the automatic start on Red Hat / Fedora / other distros...

The client provides the modular clog, including support for authentication via Kerberos 5 and some new features. No manuals are included though, so until there is an online version of the man pages use

clog -help

Customize Your Clog

To make your Coda authentication easy, you may wish to create a file ~/.codafs/clog/pref according to the following syntax:

# 5 is the current version of the format
5 {
# as a default, authenticate as bob@example.com and bobby@some-cool-place.org
  loginto = job cool
# list of shortcuts available for "clog <shortcut>" :
  identities {
# to access the work-related data
    job {
      desc = Me at the Coda realm of my employer
      identity = bob/krbdb@example.com
##### authmethod and methodopts are only necessary here
##### if the realm in question does not run the authentication advertisement service
##### or if it is using a non-standard Coda service principal for some odd reason
#      authmethod = kerberos5
#      methodopts {
#        krb5realm = EXAMPLE.COM
#        krb5kdcs {
#        }
#        krb5options {
## with dce we would need as follows:
##          withaddrs = yes
##          proxiable = no
#        }
##### this entry would be necessary if the realm would be using such non-standard service principal:
#        krb5service {
#          coda/service/example.com
#        }
#        tokensrvs {
#          codasrv1.example.com
#          codasrv2.example.com
#        }
#      }
    }
# to make special things at the Coda realm at work
    admin {
      desc = When I need power at work
      identity = bob/admin/krbdb@example.com
    }
# to share data with cool people at a cool place
    cool {
      desc = Me at That Cool Place
      identity = bobby@some-cool-place.org
    }
  }
}

Then a mere "clog" will give you tokens to two Coda realms, asking for the corrresponding passwords if it needs them - it uses available Kerberos TGTs if a Coda realm is trusting Kerberos and there are suitable TGTs.

"clog admin" would give you a different Coda identity.

"clog cool" would only provide tokens for /coda/some-cool-place.org/....