<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Coda File System User and System Administrators Manual: Getting Started </TITLE>
<LINK HREF="manual-3.html" REL=next>
<LINK HREF="manual-1.html" REL=previous>
<LINK HREF="manual.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="manual-3.html">Next</A>
<A HREF="manual-1.html">Previous</A>
<A HREF="manual.html#toc2">Contents</A>
<HR>
<H2><A NAME="GettingStarted"></A> <A NAME="s2">2. Getting Started </A> </H2>
<P>
<P>The Coda file system expands the local file system hierarchy to
include shared files much like the <EM>Sun Network File System</EM>
and the <EM>Andrew File System</EM>. Figure
<A HREF="#FSView">XXX</A> below shows the users view of the file system hierarchy on
a machine with all three types of file systems.
<P>
<FIGURE>
<EPS FILE="figure1">
<CAPTION>
<A NAME="FSView"></A> Coda filesystem view at a workstation</CAPTION>
</FIGURE>
<P>Data sharing in Coda, like that in Andrew, is supported by a distributed
file system that appears as a single large subtree of the local file system
on each workstation. This subtree is identical on all workstations. Thus,
processes on two different workstations can read and write files in this
subtree just as if they were running on a single timesharing system
with the difference that processes on the different workstations see
changes only when files are opened and closed. Familiarity with AFS
is helpful when learning about Coda.
<P>This chapter introduces essential Coda commands. For more details on these
commands, refer to their man pages.
<P>
<H2><A NAME="ss2.1">2.1 Authentication</A>
</H2>
<P>Once you are logged in to your workstation, you need to get a Coda
authentication token by running the <B>clog</B> program.
<B>clog</B> will prompt you for your Coda password and use it
to get a token from the <EM>authentication server</EM>. This token will
expire in about 25 hours. After the token expires, you must use
<B>clog</B> to authenticate for another 25 hours. The
following in an example of running <B>clog</B> twice. The
first time, the wrong password was entered:
<P>
<P>
<P>
<HR>
<PRE>
% clog
Password:
Invalid login (RPC2_NOTAUTHENTICATED (F))
% clog
Password:
%
</PRE>
<HR>
<P>
<P>To see your newly acquired token, use <B>ctokens</B>. This
will display the tokens and their expiration time for your UID.
<P>
<HR>
<PRE>
% ctokens
Tokens held by the Cache Manager:
UID=2534 : [Expires Mar 19 10:50]
</PRE>
<HR>
<P>Use the <B>cpasswd</B> command to change your Coda password.
As with <B>passwd</B>, <B>cpasswd</B> will prompt for
your current password, then ask you to enter a new password twice.
<P>
<P>
<HR>
<PRE>
% cpasswd
Changing password for raiff
Old password:
New password for raiff:
Retype new password:
Password changed, it will be in effect in about 1 hour
</PRE>
<HR>
<P>You can "log out" of Coda by using the <B>cunlog</B> command to
tell <EM>venus</EM> to forget your tokens. Once you run
<B>unlog</B>, you will have the same privileges as an anonymous
Coda user until you acquire a new authentication token.
<P>
<H2><A NAME="ss2.2">2.2 Coda File Protection</A>
</H2>
<P>Coda provides a close approximation to UNIX protection semantics.
An <EM>access control list</EM> (ACL) controls access to directories by granting and
restricting the rights of users or groups of users. An entry in an access
list maps a member of the protection domain into a set of rights. User
rights are determined by the rights of all of the groups that he or she is
either a direct or inderect member. In addition to the Coda access lists, the
three owner bits of the file mode are used to indicate readability, writability,
and executability. You should use <EM>chmod</EM>(1) to set the permissions on
individual files. Coda rights are given as a combination of <B>rlidwka</B> where:
<P>
<UL>
<LI><B>r</B> <EM>Read</EM>. With this right, you can read any file in the directory.</LI>
<LI><B>l</B> <EM>Lookup</EM>. Lookup allows you to obtain status information about the files in the directory. An example is to list the directory contents.</LI>
<LI><B>i</B> <EM>Insert</EM>. Allows the user to create new files or subdirectories in the directory.</LI>
<LI><B>d</B> <EM>Delete</EM>. Allows the user to remove files or subdirectories.</LI>
<LI><B>w</B> <EM>Write</EM>. Allows the user to overwrite existing files in the directory.</LI>
<LI><B>k</B> <EM>Lock</EM>. The lock right is obsolete and only maintained for historical reasons.</LI>
<LI><B>a</B> <EM>Administer</EM>. Allows the user to change the directorys access control list.</LI>
</UL>
<P>Coda also has <EM>negative</EM> rights, which deny access. Any of the
normal rights listed above can also be negative.
<P>Access control lists are managed with the <B>cfs</B> command
through the <B>listacl</B> and <B>setacl</B> options. These commands can be
abbreviated as <B>la</B> and <B>sa</B> respectively. To see the access
control list of any directory in a Coda file system, use
<B>cfs la</B>. The following example displays the current
directorys ACL:
<P>
<HR>
<PRE>
% cfs la .
System:AnyUser rl
raiff rlidwka
</PRE>
<HR>
<P>The displayed list, shows that the user "raiff" has all of the access
rights possible on the directory and that the group "System:AnyUser"
has read and lookup privileges. System:AnyUser is a special Coda group
that includes all users.
<P>A second example shows another group, System:coda. Anyone who is a
member of the group, will have the groups access rights:
<HR>
<PRE>
% cfs la /coda
System:coda rlidwka
System:AnyUser rl
</PRE>
<HR>
<P>Use <B>cfs sa</B> to change or set a directorys access control
list. Options to <B>cfs sa</B> include <EM>-negative</EM> to assign
negative rights to a user and <EM>-clear</EM> to clear the access list
completely before setting any new access rights. You can also use
<EM>all</EM> or <EM>none</EM> to specify all rights or no rights respectively.
To remove System:AnyUsers access to the current directory, you would
issue the following command:
<HR>
<PRE>
% cfs sa . System:AnyUser none
</PRE>
<HR>
<P>To give System:AnyUser read and lookup rights, use:
<HR>
<PRE>
% cfs sa . System:AnyUser rl
</PRE>
<HR>
<P>To deny rights to a user, use the <B>-negative</B> switch:
<HR>
<PRE>
% cfs sa -negative . baduser rl
</PRE>
<HR>
This will deny "baduser" read and lookup rights, even though any other
user has these rights. Note that negative rights are maintained
separately from the normal rights, so to re-instate badusers read and
lookup access, you must use:
<HR>
<PRE>
% cfs sa -negative . baduser none
</PRE>
<HR>
If you omit the <EM>-negative</EM> switch, then "baduser" will still be
denied read and lookup access.
<P>
<P>
<H2><A NAME="ss2.3">2.3 Disconnected Operation</A>
</H2>
<P>If all of the servers that an object resides on become
inaccessable, then the client will use the cached copy of the object (if present) as a valid replica. When the client does this, it is operating in
<EM>disconnected mode</EM>.
<P>Disconnected mode may be the result of a network failure, or it could
be the result of removing a laptop from the network. If you make sure
all of the files you want to use are cached on your laptop, you can
travel with it and access your files as if you were still on the network.
<P>Unfortunately, a cache miss while operating in disconnected mode is
not maskable, and you will get a <EM>connection timed out</EM> error
message. Coda allows you to mark or <EM>hoard</EM> files with caching
priorities to help keep the ones you want in the cache.
<P>When you are in disconnected mode, you may want to checkpoint the
modify log that Coda keeps of which directories have
changed. Use <B>cfs checkpointml</B> to do this.
Checkpointing the modify log will ensure that changes you have made
will not be lost if the system crashes.
Coda uses this modify log when it reintegrates with the servers.
<P>Coda also supports low bandwidth access over SLIP. You can use this
to periodically reintegrate and cache new files when you are on a
trip.
<P>When you reintegrate after operating in disconnected mode, watch your
<B>codacon</B> or run the
command:
<HR>
<PRE>
% tail -f /usr/coda/etc/console
</PRE>
<HR>
<P>This file will let you know if the reintegration was successful. If
it was not, then the files that you modified will be put in a tar file
in <EM>/usr/coda/spool/<uid></EM>. Reintegration fails, for example,
when you modified a file in disconnected mode and someone else also
modified that file on the servers. Section
<A HREF="manual-3.html#reintegration">XXX</A> has more on reintegration.
<P>
<H2><A NAME="ss2.4">2.4 Hoarding</A>
</H2>
<P>Coda allows you to advise the cache manager, <EM>venus</EM>, of critical
files that it should try to keep in
the cache. You indicate the relative importance of the files by
assigning priorities to them.
This is known as <EM>hoarding</EM>. Venus maintains an internal <EM>hoard database</EM>
of these files. Hoarding a file helps to ensure that
it will be available when operating in disconnected mode. See the
<B>hoard</B>(1) man page for information on hoard files and sections
<A HREF="manual-3.html#ConstructHoard">XXX</A> and
<A HREF="manual-3.html#HoardDB">XXX</A> of this document for an example of how
to set up your hoard database. A convenient way of setting up your
hoard database is by creating a file with commands for the <B>hoard</B>
program. This file is known as a <EM>hoard file</EM>.
<P>
<P>
<H2><A NAME="ss2.5">2.5 Repairing Conflicts</A>
</H2>
<P>
<A NAME="Conflicts"></A>
As a result of Codas optimistic replica management, object replicas
can conflict on different servers. A conflict arises when the same object
is updated in different partitions of a network.
For instance, suppose a file is replicated at
two sites (say, serverA and serverB). If these two sites become partitioned
and a user on each side of the partition updates the file (userA updates the
file on serverA while userB updates the file on serverB), the file will be in
conflict when the partition ends. Conflicts may also arise at the end
of disconnected operation.
<P>Coda guarantees conflict detection at the first request for that object
when both servers are accessible. When a conflict is detected, Coda
attempts to perform automatic conflict resolution. In simple cases, the
conflict will be resolved automatically, a process which is transparent
to the user except for a time delay in accessing the object. However, in
more difficult cases, automatic conflict resolution fails and the object is
marked <EM>in conflict</EM>. File system calls on an object which is in conflict
fail with the same error code as if the object were a dangling, read-only
symbolic link (usually, ENOENT). The conflict must be resolved by
a user with appropriate access to the object. To help users resolve
conflicts, Coda provides a repair tool which is discussed in Section
<A HREF="manual-3.html#Inconsistent">XXX</A>.
<HR>
<A HREF="manual-3.html">Next</A>
<A HREF="manual-1.html">Previous</A>
<A HREF="manual.html#toc2">Contents</A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
37
