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.
After the installation is complete (in a couple of seconds), you need to start Coda client:
codaclient start
Now you are running Coda.
(If your Coda kernel module does not load automatically, run modprobe coda and echo coda >> /etc/modules to both load the module and schedule it for automatic load on every boot).
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/....
