This document is a rough, living document intended to help people bootstrap into peering with and sharing in the mimezine inferno cluster. Inferno is a fully functioning cult, so they're going to ask you to adopt a second vocabulary for everything; characters are now unicode 'runes,' , everything is hierarchically namespaced, every property file's a database (or part of one), and everything's a service. If you wanna use it, grin and bear it. Having read Dante's Divine Comedy may be an asset or a liability, but the whole system is rife with references to these books. tasks: 1.1 install inferno 1.2 configure a "signer" (auth server) 1.3 configure a registry server 1.4 configure a file service (file server) 1.5 configure a database service. ========================================= 1.1 install inferno: see architecture-specific documentation at vitanuova.com. ( http://www.vitanuova.com/inferno/net_download4T.html ) ( http://www.vitanuova.com/dist/4e/20040527/install.pdf ) upon completing installation, verify that you can send TCP/IP packets via your machine from within the inferno instance. (the Inferno wwwbrowser Charon is a nice way to do this, if you're using the graphical interface. to bring up a local window manager instance, launch inferno and type "wm/wm" at the prompt. Select "Charon" from the menu associated with the vitanuova "Tree." network definition information lives in /lib/ndb/. files in this directory include: common - a general ports-definition file; for service-name/port mapping inferno - inferno-specific port mapping dns - dns service config file ?? local - the config file governing servers to use registry - the service registry file (starts blank except some comments) services - a sample /etc/services file for unix demonstrating cfg for inferno ports all these files are expressed in name=value pair format, which should be familiar enough to jump into immediately. these act as the configuration database for the svc command XXX "man ndb" will provide more info on these files. All server-name attributes may be entered in IP address or named format. All application network requests are brokered by the "connection server," a process which vends connections according the configuration information in a context independent manner. "man cs" will provide a description of namespace-specific connection servers, which you'll want to understand before configuring the network. CS acts as the default domain name server for your instance; you can run queries against it using the dnsquery command. It's backed by the /net/dns file, which it turn reflects the information provided by /lib/ndb/local. In hosted mode, inferno uses the hosts default resolver first... be warned, if you want to set up seperate name spaces, you'll need to check the manpage for dns. you can view your current namespace settings by typing "ns
" in the shell. XXX timezone? 1.2 configure a signer: The signer acts as a trusted third party to ceredentials transactions between nodes. signers maintain a central user list, listens on the specified port for requests, and checks certificate signatures of both parties to allow establishment of a common connection. access to the signer will require the ability to route TCP/IP packets on ports 6671 and 6672 between your machine and the relevant signer/countersigner. the primary file of interest for our purposes here will be lib/ndb/local open this file for editing in Edit (graphical) or (non-graphical). "dns" should be left commented out in order to rely on host operating system resolution, or modified to reflect a valid DNS server; you may make as many of these entries as you like. the primacy of namespaces within Inferno suggests that we may wish to begin hosting a mimezine-specific somewhat-dynamic dns for indentifying machines within our own cluster. SIGNER should be set to the primary mimezine signer (mimezine.com, pending evaluation). Again, the "Edit" option in the graphical environment provides a nice interface for beginners ininferno. setting up the main signer; man createsignerkey - empty secrets file (/keydb/keys)and chmod 600 the blank file. - auth/createsignerkey olococolo.mimezine.com - chmod 600 /keydb/signerkey (perm) - svc/auth (start auth svc) - (make sure it started) - auth/changelogin for each user. (use passwd to change later) XXX:uhtu; i don't see any info regarding running a cluster without a centralized signer. might be a good question to ask orn. might be possible for every server to also be a signer, but that would effectively reduce the whole topology to an nfs/coda thing. 1.3 configure a registry server: initial survey suggests that this is server-specific to each server in the cluster. 1.4 configuring file service: initial intention is not to have a central file service within the mimezine cluster. Individual mimeziners can and should configure their own intended shares accordingly. 1.5 configuring database service: initial intention is not to have a central database service withing the mimezine cluster. 1.6 configuring your node as a server: add the username through which you wish to provide the service on mimecom's signer via the auth/changelogin command. make sure your network service is started (make sure ndb/cs is running, and that /net is populated). Make sure you're configured to use mimecom as a signer. use "svc/net" to start sharing. use netstat to verify that your local registry service is running (port 6675). 1.7 configuring your node as a client: make sure your connection server is running. make sure you're configured to use mimezine.com as a signer. on a per-server-you-wish-to-use basis, add certificates using: getauthinfo tcp!hostname (agree 'yes' when asked to store cert) make a blank directory. use "mount " and "unmount " to see shared resources. (XXX: we should agree on settings here. mount's "-C" option allows hash and enc. algorithm specification)