of Kiss Coda Wiki
The original Coda Administration and User Manual has not kept pace with development, and is now misleading in places. Most of the answers are available in the mailing list archives.
If you find something you think should be here then please fill it in.
In the original the first paragraph of this secton has been moved to the end of the page.
Perhaps this belongs in Troubleshooting? When using clog as directed on one client I got kerberos-related error messages, and login failed. Using ‘clog -coda username’ sorted it. The client was a Gentoo linux box with the ‘kerberos’ USE variable set, so when coda was installed it was compiled with kerberos support. (note kerberos support if not using the modular clog is broken)
Shouldn’t this go under the next section?
Up-to-date Coda support is present by default in Linux 2.6, FreeBSD 6..8, NetBSD >= 2.0.
No known error. Only here to stop Wiki numbering getting out of step with the original.
The original document only goes as far as 2.1 series kernels. Coda support is available in both 2.4 and 2.6 series kernels.
Linux 2.4 default Coda module is outdated and can not be used without patching.
Linux 2.6 has a good Coda module which is present by default (at least in Debian, Knoppix, Red Hat EL, SuSE and probably in any distribution which is not purposedly cut down to be very “minimalistic”).
The Coda module is small (about 50k on my machine), so no reasonable packager would spare on it. For comparison, nfs module on the same system is about 90k.
If you compile Coda module yourself, do not enable “compatibility” with older Coda, it does not help anything nowadays. The fids shall be 128 bits, not 96 as it was in the past.
Depending on the distribution you may need to add “coda” to /etc/modules or alike and/or “mknod /dev/cfs0 67 0”.
You’re lucky! the coda ebuild does it all for you (it did for me with coda-6.0.8 anyway).
By default, coda does not load during startup, so here’s how we get it loaded at boot:
yast2 sysconfig -> System -> Kernel -> MODULES_LOADED_ON_BOOT
Add the module name “coda” without quotes. If you already have other modules listed use spaces for delimiters. After boot, you can verify that it loaded with:
# dmesg |grep coda coda: module not supported by Novell, setting U taint flag. Coda Kernel/Venus communications, v6.0.0, firstname.lastname@example.org
# lsmod |grep coda coda 29892 0
This section deals with the installation and configuration of a Coda master server. This section needs many updates. The following list is far from exhaustive.
There are four phases of installing and configuring a Coda server.
Once these steps are complete, the server is usable (if not particularly useful).
Unlike some other network file systems, Coda requires some thought be put into the actual server system configuration. Beyond the usual considerations of memory, network capabilities, processor speed, it is important to make sure you have a solid partition and disk scheme in place before beginning.
Coda has three main directories/files that need consideration.
Unlike older versions of Coda, the RVM log and RVM data no longer need to be on seperate partitions. In fact, it is preferable to use files.
If you decide to store this data in files, rather than on their own partition(s), you do not need any extra configuration at this point.
If you decide to store this data in a partition, you will need a partition formatted with the ext2 or ext3 filesystems. Reiserfs used to cause problems earlier . This partition should be large enough to match the sizes specified when you configure the server. Before creating any partitions, read up on configuring the server so you know how much space to reserve.
Coda stores information about the server in the /vice directory under UNIX systems. This information does not take up much space, and does not need its own partition, except to keep it seperate from the operating system, if you wish to do so. If you decide this is necessary, the partition need not be large.
You will need a partition(s) or disk(s) on which the actual volume will reside. This partition can be any size you wish, and merely needs to large enough to hold all the data you plan on storing. On Linux the partition can be formatted with “ext2, ext3, reiserfs, ramfs, tmpfs, probably even jffs2” http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2002/4737.html. On BSD “ufs will work just fine” [ibid.].
The traditional mount location for volumes is /vicepa, /vicepb, /vicepc… (meaning Vice partition A, Vice partition B…), but any mount point could be used. Nothing needs to be done to this partition as of yet. It will be configured for use with Coda when configuring the server itself.
Coda can be installed from pre-built packages or from source. The latest releases can be found on the Downloads page.
The traditional UNIX build methodology works to compile and install Coda under Linux. Alternatively, packages have been rolled for some distributions.
If you have troubles with any other method of installation, fall back to this one. It should work on any *nix platform provided you have the proper development environment installed.
The following illustration was performed on a GNU/Linux system:
Prerequisites: Ensure that you have the following installed prior to compiling as they are required:
What to do:
Download the source:
First of all, we need to get the latest (6.0.14 at the time of this writing) source tarballs from one of the coda mirrors
cd /usr/src wget http://www.coda.cs.cmu.edu/pub/coda/linux/src/coda-6.1.2.tar.gz wget http://www.coda.cs.cmu.edu/pub/coda/linux/src/lwp-2.3.tar.gz wget http://www.coda.cs.cmu.edu/pub/coda/linux/src/rpc2-2.4.tar.gz wget http://www.coda.cs.cmu.edu/pub/coda/linux/src/rvm-1.13.tar.gz
Unpack the tarballs:
tar zxf coda-6.1.2.tar.gz tar zxf lwp-2.3.tar.gz tar zxf rpc2-2.4.tar.gz tar zxf rvm-1.13.tar.gz
Compile and install them in the following order:
cd /usr/src/lwp-2.3 ./configure make make install cd /usr/src/rpc2-2.4 ./configure make make install cd /usr/src/rvm-1.13 ./configure make make install cd /usr/src/coda-6.1.2 ./configure make make server-install
After downloading the packages, do:
rpm -Uvh lwp-version.i386.rpm rpm -Uvh rpc2-version.i386.rpm rpm -Uvh rvm-version.i386.rpm rpm -Uvh rvm-tools-version.i386.rpm rpm -Uvh coda-debug-server-version.i386.rpm
Write me! For FC3 use the FC2 RPMs. They work.
A simple emerge should be enough to install the coda client, server and required dependencies. Note: if you have the ‘kerberos’ USE variable set you will build a coda client with kerberos as the default authentication mechanism. note kerberos support without modular clog is broken.
The official coda ebuild only supports 32-bit. The 64-bit version os in the way, read here: http://bugs.gentoo.org/show_bug.cgi?id=193012
Use the coda repositories on www.coda.cs.cmu.edu. Add the following line to your /etc/apt/sources.list, replacing stable with testing or unstable if appropriate:
deb http://www.coda.cs.cmu.edu/debian stable/
aptitude update aptitude install coda-server
There are no maintained SuSE packages available, you will need to compile from source.
Configuring Coda is relatively simple, thanks to a provided setup script that (hopefully) will do all the work for us. However, undoing a Coda installation is somewhat difficult, and so you want to get it right the first time. If you mess something up, your best bet is to uninstall Coda (if you used RPM’s, DEB’s, portage, or some other package management system), remove all the created directories and files (including the configuration files in /etc/coda/) and start over.
Before starting, there is an issue you may wish to resolve. If you do not have (or are not using) a DNS server (ie, you want to access your Coda server by IP address only) you may have to edit /etc/hosts and remove any extraneous binds that connect your server’s hostname to the loopback IP address (127.?.?.?). If you do not, Coda may get confused and configure itself as if the loopback is a valid device to connect to, which of course creates problems. Read more on thise Configure_Coda_without_DNS.
When you are ready to configure the server, do:
An interactive script will run, which will prompt you for information as it configures the server. The following is a walkthrough of the various prompts you need to answer.
Configuring a Coda Server (2002/10) - Runs through a Coda 5.3.19-1 vice-setup (hardly relevant???).
So now our server is configured and running. Until we configure a volume for access, however, it can’t actually do anything, and clients cannot connect. Because we told vice-setup about our volume in the previous section, all that is necessary now is to prepare it for use. Note that this is a one time operation. This does not need to be repeated after this time.
To configure the root volume, simply run the command as shown in the final output of vice-setup. For example, you might do the following:
createvol_rep / server.hostname.here
Make sure you execute the command specified in the final output of vice-setup exactly, even if it disagrees with other sources of information. vice-setup knows best!
To be written. Depends on the OS in question.
There are two systems in place for managing users on a Coda server: pdbtool and au. pdbtool is provided with the server software, and is used to create and manage users and groups on a broad scale. au is provided with the client software and is used to perform modifications to accounts (usually remotely, though if the client software is installed on the server it could be run from there as well).
A typical situation might consist of the owner setting up some number of users and groups via pdbtool and then informing users to change their passwords via au.
Like in a typical UNIX environment, users authorized for access on a Coda server are designated with a name, a user id (uid), and a group id (gid). Groups hold some number of users, and allow for grouping users for common file permissions.
It is very important to keep in mind that uids and gids (and names) have no bearing on actual users on the clients or server. They are constructs of Coda, and exist only within that frame of reference.
No longer valid (?) (and totally irrelevant) : You may not create a user or group with an id of 0. Beyond that, there are no real restrictions (beyond the typical naming regulations) on user creation.
pdbtool runs as an interactive shell on the server.
Commands are entered at the prompt, along with any arguments.
The “help” command displays a listing of all the available commands. Administrative actions can be performed using these commands, as shown here. Note that this list is not exhaustive.
Important note: new users are created without any password (they can not authenticate until they also get a record in the Coda password database, see au).
[Create a user with the username "nate".] pdbtool> nu nate [Create a user, this time specifying the uid manually, **don't**] pdbtool> nu molly 678 [Delete a user] pdbtool> d bob [Get info on a particular user, either by name or by uid] pdbtool> i nate pdbtool> i 678 [Change "nate"s uid and "molly"s name] pdbtool> ci nate 654 pdbtool> cn 678 mollywolly [Clone "nate". Note that you are cloning a uid, and providing the copy with a new name.] pdbtool> cu nate_clone 654 [Delete "mollywolly"] pdbtool> d mollywolly [Add "nate" to the "awesome" group. Either argument could be replaced with its id.] pdbtool> ag awesome nate [Remove "nate" from the group. The above id comment applies here as well.] pdbtool> rg awesome nate
pdbtool has several advanced features for easing larger scale user management.
[Execute a pre-written set of pdbtool commands.] source /home/nate/my_commands [The user database can be exported and imported for saving and restoring. User and group info are stored in seperate files.] export /home/nate/my_coda_users /home/nate/my_coda_groups import /home/nate/my_other_coda_users /home/nate/my_other_coda_groups
au manipulates coda user password records.
au runs as a command line program on a client. It can be run on the server, if it is configured as a client as well.
au has two phases of operation. First, you connect and authorize with the Coda server. Second, the chosen operation is executed. The first phase can only fail if you fail to provide a valid name and password to the server. The second phase can fail if the provided information for the chosen operation does not make sense, or if you do not have sufficient permissions to execute the command as attempted.
au should only really be used to make minor adjustments to the user system. For instance, new users would need to set their passwords. Or a server administrator might wish to modify an account on the fly, without connecting to the server directly.
[Create a new account. This can only be executed by administrators.] au -h MY_CODA_SERVER nu Your Vice name: MY_ACCOUNT_NAME Your password: MY_PASSWORD Vice user: NEW_USER_NAME New password: NEW_PASSWORD [Note: this echos in cleartext!] New info: NEW_INFO_STRING [Change a user's password. This can only be applied to yourself, unless you are an administrator.] au -h MY_CODA_SERVER cp Your Vice name: MY_ACCOUNT_NAME Your password: MY_PASSWORD User name: TARGET_USER_NAME New password: NEW_PASSWORD [Note: this echos in cleartext!] [Change a user's information. This can only be executed by administrators.] au -h MY_CODA_SERVER cu Your Vice name: MY_ACCOUNT_NAME Your password: MY_PASSWORD Vice user: TARGET_USER_NAME New password: NEW_PASSWORD [Note: this echos in cleartext!] New info: NEW_INFO_STRING [Delete a user. This can only be executed by administrators.] au -h MY_CODA_SERVER du Your Vice name: MY_ACCOUNT_NAME Your password: MY_PASSWORD Vice user to delete: TARGET_USER_NAME
At its former host wikidev.net this page has been accessed 13201 times.
Last modified: Thu Jun 26 07:37:02 UTC 2014