Server Binary Installer

of Kiss Coda Wiki

Obtain and Install Coda Server

Warning: server setup needs a lot more understanding than a client setup, even if it is easy to set up a server. You have to learn how to administrate the resulting realm. We describe here a quick and handy way of server setup but do not cover administration.

The following should work on virtually any Linux distribution. It works also on FreeBSD and should work on NetBSD, given that Linux ABI support is activated in the kernel (you don’t need any Linux-specific libraries).

Download a server installer corresponding to your architecture from

http://www.aetey.se/index.php?Static&pg=CodaInstHowto

Make the file executable, then run it as root as follows, using the real file name:

    chmod +x coser-.........
    ./coser-......... help

For the first server use something like

    ./coser-......... /vice 768 this.hostA.doma.in

then follow the installer dialogue.

The utilities to be used for starting, stopping and otherwise administrating the server will be placed in /vice/bin, the data container files will be in /vice/pa. All server files will be under /vice so that you get a clean “uninstall” if you remove /vice.

NOTE: do not try to be overly creative and directly run any binary you may find under the installed /vice directory. The entries in /vice/bin are the only sane way to run the corresponding commands.

NOTE: realm naming is done via DNS and in general has nothing to do with host names of the servers. For testing you may choose the hostname of the only server to be used as the realm name, but this is not a scalable setup! Use DNS SRV records, as described somewhere else.

Note that the same installer is well suited for setting up multiple servers.

For creating an extra server in the same realm (in the example, on hostB) get a copy of the scm server’s /vice/db/update.tk, put it somewhere, in this example in /tmp, and run

    ./coser-......... /vice 768 this.hostB.doma.in this.hostA.doma.in /tmp/update-tk-file

The dialogue gives you all the relevant information.

If you want to use a Kerberos realm for authentication

The description below assumes that the clients are using the newer “modular” clog. The Kerberos support in the traditional clog is not adequate.

Choose an existing Kerberos realm (or setup a new one) to use. The name of the Kerberos realm does not have to have any relation to the name of your Coda realm.

Edit /vice/server.conf for the following statements being present and not commented out:

    kerberos5servprinc=codaauth/<your.coda.realm>
    kerberos5realm=<kerberos.realm>

You can also use any principal name instead of codaauth/your.coda.realm, but then each user will have to configure her clog to trust the principal for your Coda realm authentication, to prevent possible principal spoofing. So as long as you have some influence on the Kerberos realm in question, ask them for codaauth/your.coda.realm.

Put the keytab for the chosen principal into /vice/db/krb5.keytab

Restart the authentication server:

    /vice/bin/auth2server restart

From now on the users might be able to authenticate against your Coda realm by a clog command like the following:

    clog -method kerberos5 <account>@<coda.realm> -krealm <kerberos.realm> [-servprinc <your.chosen.principal>]

To avoid the need for the users to supply the options (and possibly more options depending on how the Kerberos realm is set up) you should setup a Coda realm authentication advertisement service, a trivial inetd service for delivering a small text file to the clients. clog tries to retrieve this information automatically. It is best to have the service on all servers of the Coda realm.

The corresponding files can be placed anywhere on the Coda server hosts, in the examples below they are placed in /vice.

An inetd example:

    codaauth2      stream  tcp     nowait  root    /bin/cat cat /vice/codaauth.conf

A xinetd example:

    service codaauthcat
    {
            type            = UNLISTED
            flags           = REUSE
            socket_type     = stream
            wait            = no
            user            = root
            server          = /vice/codaauthcat
            port            = 370
    }

codaauthcat for xinetd:

    #!/bin/sh
    exec /bin/cat /vice/codaauth.conf
    exit

The codaauth.conf file is to contain the information necessary for clog to carry out the authentication. Below is an example to start with. Note that most of the options can often be omitted, the ones to be present are authority names, method types and in case of kerberos5 the krb5realm option.

# indents below are only for legibility but other whitespaces are significant
# 4 is the current version of the format
4 {
  authorities {
    <authority1> {
      authmethod = kerberos5
      methodopts {
        krb5realm = <kerberos.realm>
# optional:
        krb5kdcs {
# if the Kerberos realm is not represented by SRV records in DNS, then you may need the following:
#         <kdc1>[:port]
#         <kdc2>[:port]
#         ...
        }
# optional:
        krb5options {
# most probably not needed, but with DCE Kerberos servers you would need
#          withaddrs = yes
#          proxiable = no
        }
# optional (used for reference only, useful if non-standard) :
        krb5service {
# normally the following is of the form codaauth/<your.coda.realm> :
          <your.service.principal>
        }
# the following section is only necessary if you are running authd on hosts other than the file servers or on non-standard ports
# but it is no error to always supply this information here
        tokensrvs {
# hosts running authd, the port field is necessary if you are running some authd server on a port other than 370
#         <server1>[ port]
#         <server2>[ port]
#         ...
        }
      }
    }
    <authority2> {
      authmethod = codapassword
# optional:
      methodopts {
# the following section is only necessary if you are running authd on hosts other than the file servers or on non-standard ports
# but it is no error to always supply this information here
        tokensrvs {
# hosts running authd, the port field is necessary if you are running some authd server on a port other than 370
#         <server1>[ port]
#         <server2>[ port]
#         ...
        }
      }
    }
  }
}

Authority names are words of your choice designating different ways to authenticate against your Coda realm. In the example above the default is authority1, verifying the passwords against the given Kerberos realm using the given service principal. The user may choose to use her non-Kerberos Coda password instead by doing

    clog <account>/<authority2>@<your.coda.realm>

Coda accounts shall be created explicitly even if Kerberos passwords are being used.

In the example above Coda account names must match the Kerberos user principal names.

Note that you can put Coda accounts corresponding to different authentication authorities into different name spaces, to avoid synchronization/collisions issues. This is to recommend, but it is slightly more complicated to setup. This is accomplished by supplying different authority options to different instances of authd daemons, you may need to run them on non-standard ports as well. This is not covered here.


At its former host wikidev.net this page has been accessed 595 times.


Last modified: Thu Jun 26 07:36:59 UTC 2014