contents

Introduction - 1

Background - 2

Deployment - 3

Starkits - 4

Tclkit - 5

Advanced topics - 6

Repositories - 7

Server apps - 8

Who uses this - 9

Examples - 10

Conclusion - 11

Acknowledgements

References

7.3 - Setting up a Starsync Server

The SDX “ update” command can use servers other than SDarchive (via the “-from” option). It is a simple task to set up private servers, mirrored servers, etc.

As mentioned, SDX includes a basic implementation of a Starsync server. It serves Starkits contained in a single directory on the server. This initial implementation is not optimised (sync catalog comparison for a very large Starkit such as Kitten may take several seconds of CPU time), but for most purposes it is quite workable.

You need:

• a directory with *.kit files to be made available
• tclkit and sdx
• a web server set up to launch CGI scripts

These examples assume a Unix system with all necessary files in the directory "/my/starkits/", and a server URL of http://my.server.com/cgi-bin/sync:

• create the "sync" CGI script as a shell script containing the following lines:

        #!/bin/sh
        cd /my/starkits/
        exec ./tclkit ./sdx.kit starsync \
                                    starlog

• make sure the shell script has the proper permissions:

        $ chmod a+rx sync

• create an empty file to which log entries will be appended:

        $ >/my/starkits/starlog
        $ chmod a+rw /my/starkits/starlog

• make sure /my/starkits is readable from your CGI script:

        $ chmod a+x /my/starkits \
            /my/starkits/tclkit
        $ chmod a+r /my/starkits/*

• note that the /my/starkits/ directory need not be accessible from the web

At this point, you should be able to test access to CGI from a web browser, i.e. http://my.server.com/cgi-bin/sync. You should get back an empty page, no errors, and no errors in the webserver log. You should also see your access logged as "0 0 -" (since it was not a meaningful request).

That's it. You should now be able to fetch Starkits, using the SDX "update" command, by specifying the path to your server:

sdx update -from http://my.server.com/cgi-bin/sync oneofmystarkits.kit

Updates are a matter of replacing the Starkits on the server, and doing an "sdx update" on the clients. If you add Starkits to the server, they become available to clients for downloading. If you remove a Starkit, clients will check-and-ignore the server and continue as is (Starkits are not deleted on the client side, clients simply cease to track updates). All accesses will be logged.

If you are concerned about race conditions during an update of a very active server, then the way to update Starkits is to not overwrite the starkit, but to *move* them in place (i.e. rename) as last step. The server logic is such that this will not cause a failed sync ever, even for sessions which are in progress. With this approach, clients always see either the old *or* the new version of a Starkit, never anything in between.

The server never alters any Starkits, not does it access any files outside the current directory. For security reasons, only a very strict set of Starkit names are recognized on the server:

• the files have to have a suffix ".kit"
• filenames must be lowercase and pass Tcl's "string is wordchar" test, i.e. alphabetics, numerics, and "_"
• anything not matching the above is not visible or accessible through the CGI interface
• the CGI interface does not let you browse, you have to know a Starkit's name to fetch/update it

There is one exception to the read-only behavior of the server: log entries are appended to the optionally specified logfile ("starlog" in the example above).

see also

• Starkit Home Page

• Tclkit Home Page

• Metakit Home Page

• SDX Utility

• Wikit Home Page

• Tclers' Wiki

• Author's Website

Updated paper, by Steve Landers, as presented at Tcl/Tk 2002 conference - see also original PDF.