Client Binary Installer

of Kiss Coda Wiki

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-2.1-6.9.5-linux-ia32-3.bin
    ./cocli-2.1-6.9.5-linux-ia32-3.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.

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/....


At its former host wikidev.net this page has been accessed 941 times.


Last modified: Thu Jun 26 07:36:59 UTC 2014