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