close Warning:

Changes between Version 4 and Version 5 of CodaHOWTO/Introduction


Ignore:
Timestamp:
Jan 21, 2010, 4:47:23 AM (8 years ago)
Author:
wk5r
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CodaHOWTO/Introduction

    v4 v5  
    11[[TracNav(CodaHOWTO)]]
    22
    3 == '''Warning! The contents of this page seems to be very old. At least the description of realms (''not'' cells as they are called here) is thus very confusing. This article has to be edited! ''' ==
     3== '''The contents of this page may be old in certain places. Take it with a grain of salt.''' ==
    44
    55
     
    1212
    1313 '''A single name space'''::
    14     All of Coda appears under a single directory `/coda` on the client (or under a single drive under Windows). Coda does not have different exports or shares as do NFS and Samba that are individually mounted. Under `/coda` the volumes (aka file sets) of files exported by all the servers (living in your Coda cell) are visible. Coda automatically finds servers and all a client needs to know is the name of one bootstrap server that gives it information how to find the root volume of Coda.
     14    All of Coda appears under a single directory `/coda` on the client (or under a single drive under Windows). Coda does not have different exports or shares as do NFS and Samba that are individually mounted. Under `/coda` you can see the realm names, further containing file data and the "mount points" of the volumes (aka file sets) of files exported by all the servers (living in the corresponding Coda realm). Coda automatically finds servers and all a client needs to know is the name(s) of the realm(s) it wants to access.
    1515
    16  '''A Coda cell'''::
    17     is a group of servers sharing one set of configuration databases. A cell can consist of a single server or up to hundreds of servers. One server is designated as the '''SCM''', the System Control Machine. It is distinguished by being the only server modifying the configuration databases shared by all servers, and propagating such changes to other servers. At present a Coda client can belong to a single cell. We hope to get a cell mechanism into Coda whereby a client can see files in multiple cells.
     16 '''A Coda realm'''::
     17    is a group of servers sharing one set of configuration databases. A realm can consist of a single server or up to hundreds of servers. One server is designated as the '''SCM''', the System Control Machine. It is distinguished by being the only server modifying the configuration databases shared by all servers, and propagating such changes to other servers.
    1818
    1919 '''Coda volumes'''::
    20     File servers group the files in volumes. A volume is typically much smaller than a partition and much larger than a directory. Volumes have a root and contain a directory tree with files. Each volume is "Coda mounted" somewhere under /coda and forms a subtree of the /coda. Volumes can contain mount points of other volumes. A volume mount point is not a Unix mount point or Windows drive - there is only one drive or Unix mountpoint for Coda. A Coda mount point contains enough information for the client to find the server(s) which store the files in the volume. The group of servers serving a volume is called the ''Volume Storage Group'' of the volume.
     20    File servers group the files in volumes. A volume is typically much smaller than a partition and much larger than a directory. Volumes have a root and contain a directory tree with files. Each volume is "Coda mounted" somewhere under /coda and forms a subtree of the /coda. Volumes can contain mount points of other volumes. A volume mount point is not a Unix mount point or Windows drive - there is only one Windows drive or Unix mountpoint for Coda. A Coda mount point contains enough information for the client to find the server(s) which store the files in the volume. The group of servers serving a volume is called the ''Volume Storage Group'' of the volume.
    2121
    2222 '''Volume Mount points'''::
    23     One volume is special, it is the root volume, the volume which Coda mounts on `/coda`. Other volumes are grafted into the `/coda` tree using `cfs mkmount`. This command installs a volume mount point in the Coda directory tree, and in effect its result is similar to `mkdir mountpoint ; mount device mountpoint` under Unix. When invoking `cfs mkmount` the two arguments given are the name of the mount point and the name of the volume to be mounted. Coda mount points are persistent objects, unlike Unix mount points which needs reinstating after a reboot.
     23    One volume is special, it is the root volume, the volume which Coda mounts on `/coda/<realmname>`. Other volumes are grafted into the `/coda` tree using `cfs mkmount`. This command installs a volume mount point in the Coda directory tree, and in effect its result is similar to `mkdir mountpoint ; mount device mountpoint` under Unix. When invoking `cfs mkmount` the two arguments given are the name of the mount point and the name of the volume to be mounted. Coda mount points are persistent objects, unlike Unix mount points which needs reinstating after a reboot.
    2424
    2525 '''Data storage'''::
    26     The servers do not store and export volumes as directories in the local disk file system, like NFS and Samba. Coda needs much more meta data to support server replication and disconnected operation and it has complex recovery which is hard to do within a local disk file system. Coda servers store files identified by a number typically all under a directory `/vicepa`. The meta data (owners, access control lists, version vectors) and directory contents is stored in an RVM data file which would often be a raw disk partition.
     26    The servers do not store and export volumes as directories in the local disk file system, like NFS and Samba. Coda needs much more meta data to support server replication and disconnected operation and it has complex recovery which is hard to do within a local disk file system. Coda servers store files identified by a number typically all under a directory `/vicepa`. The meta data (owners, access control lists, version vectors) and directory contents is stored in an RVM data file.
    2727
    2828 '''RVM'''::
     
    3030
    3131 '''Client data'''::
    32     is stored somewhat similarly: meta data in RVM (typically in `/usr/coda/DATA` ) and cached files are stored by number under `/usr/coda/venus.cache`. The cache on a client is persistent. This cache contains copies of files on the server. The cache allows for quicker access to data for the client and allows for access to files when the client is not connected to the server.
     32    is stored somewhat similarly: meta data in RVM and cached files are stored by number under `..../venus.cache`. The cache on a client is persistent. This cache contains copies of files on the server. The cache allows for quicker access to data for the client and allows for access to files when the client is not connected to the server.
    3333
    3434 '''Validation'''::
     
    3636
    3737 '''Authentication'''::
    38     Coda manages authentication and authorization through a token. Similar (the details are very different) to using a Windows share, Coda requires users to log in. During the log in process, the client acquires a session key, or token in exchange for a correct password. The token is associated with a user identity, at present this Coda identity is the uid of the user performing the log in.
     38    Coda manages authentication and authorization through a token. Similar (the details are very different) to using a Windows share, Coda requires users to log in. During the log in process, the client acquires a session key, or token in exchange for a correct password. The token is associated with a user identity, at present this Coda identity is the numerical Coda uid (which is a totally internal Coda business) of the Coda user performing the log in.
    3939
    4040 '''Protection'''::
    41     To grant permissions the cache manager and servers use the token with its associated identity and match this against priviliges granted to this identity in access control lists (ACL). If a token is not present, anonymous access is assumed, for which permissions are again granted through the access control lists using the `System:AnyUser` identity.
     41    To grant permissions the cache manager and servers use the token with its associated identity and match this against privileges granted to this identity in access control lists (ACL). If a token is not present, anonymous access is assumed, for which permissions are again granted through the access control lists using the `System:AnyUser` identity.
    4242
    4343= Organization of the client = #ClientOrganization
     
    5353To manipulate ACLs, the cache, volume mount points and possibly the network behavior of a Coda client a variety of small utilities is provided. The most important one is the `cfs` command.
    5454
    55 There is also a `clog` program to authenticate to the Coda authentication server. The `codacon` program allows one to monitor the operation of the cache manager, and the `cmon` program gives summary information about a list of servers.
     55There is also a `clog` program to authenticate to the Coda authentication server. The `codacon` program allows the client host superuser to monitor the operation of the cache manager, and the `cmon` program gives summary information about a list of servers.
    5656
    5757= Organization of the server = #ServerOrganization
     
    6161The Coda authentication server `auth2` handles requests from `clog` for tokens, and changes of password from `au` and `cpasswd`. Only the `auth2` process on the SCM will modify the password database.
    6262
    63 All servers in a Coda realm share the configuration databases in `/vice/db` and retrieve them from the SCM when changes have occurred. The `updateclnt` program is responsible for retrieving such changes, and it polls the `updatesrv` on the SCM to see if anything has changed.
     63All servers in a Coda realm share the configuration databases (usually in `/vice/db`) and retrieve them from the SCM when changes have occurred. The `updateclnt` program is responsible for retrieving such changes, and it polls the `updatesrv` on the SCM to see if anything has changed.
    6464
    6565== Utilities ==