1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423 |
- .de EX
- .nr x \\$1v
- \\!h0c n \\nx 0
- ..
- .de FG \" start figure caption: .FG filename.ps verticalsize
- .KF
- .BP \\$1 \\$2
- .sp .5v
- .EX \\$2v
- .ps -1
- .vs -1
- ..
- .de fg \" end figure caption (yes, it is clumsy)
- .ps
- .vs
- .br
- \l'1i'
- .KE
- ..
- \" step numbers
- .nr ,s 0 1
- .af ,s a
- .am NH
- .nr ,s 0 1
- ..
- .de Sn \" .Sn "step"
- •\ Step \\n(H1\\n+(,s: \\$1
- ..
- .de Ss
- .P1
- .B
- .Sn "\\$1"
- .P2
- ..
- .TL
- Installing the Inferno Software
- .AU
- Vita Nuova
- .br
- support@vitanuova.com
- .br
- 12 June 2003
- .SP 4
- .LP
- Inferno can run as either a native operating system, in the usual way, or as a
- .I hosted
- virtual operating system,
- running as an application on another operating system.
- This paper explains how to install Inferno from the distribution media
- to a hosted environment and how to configure the system for
- basic networking.
- .LP
- Inferno can run as a hosted virtual operating system on top of
- Plan 9, Unix or Windows.
- In this paper, the term
- .I Unix
- is used to cover all supported variants, currently FreeBSD, Linux, HP/UX, Irix and Solaris,
- and the term
- .I Windows
- covers Microsoft Windows (98, Me, Nt, 2000, and XP).
- (Windows 98 might first require installation of the Unicode layer update from Microsoft.)
- .NH
- Preparation
- .LP
- You should ensure at least 150 Mbytes of free space on the filesystem.
- The installation program will copy files from the distribution CD to a
- directory on the filesystem called the
- .I inferno_root
- directory.
- You can choose the location of this directory.
- If you are installing to a multiuser filesystem outside your control a subdirectory of your home
- directory might be most sensible. If you plan to share the Inferno
- system with other users then common choices for
- .I inferno_root
- are
- .CW /usr/inferno
- on Unix and Plan 9 systems, and
- .CW c:\einferno
- on Windows systems.
- Where these appear in examples in this paper you should substitute
- your own
- .I inferno_root
- directory.
- .Ss "Choose the \fIinferno_root\fP directory."
- Ensure that the user who will run the installation program has
- appropriate filesystem permissions to create the
- .I inferno_root
- directory and
- files and subdirectories beneath it.
- .NH
- Copying Files
- .LP
- On all platforms the files will be owned by the user doing the installation,
- except for installation onto a FAT file system (eg, on Windows), where the files
- appear to be owned by
- .CW Everyone
- because FAT does not record ownership.
- .Ss "Insert the distribution CD into the CD drive."
- On Unix and Plan 9,
- mount the CD to a suitable location on the filesystem, call this location
- .I cd_path .
- On Windows, note the drive letter of the CD, call this drive letter
- .I cd_drive .
- The files will be copied by an Inferno hosted installation program which runs
- directly from the CD.
- The directory
- .CW /install
- on the CD contains an installation program for each supported platform \- a shell
- script for Unix and Plan 9 and an executable for Windows.
- The Plan 9 install script is called
- .CW Plan9.rc
- and determines the CPU type from the environment variable
- .CW cputype .
- The Unix install scripts all have names of the form
- .CW \fIhost_os\fP-\fIhost_arch\fP.sh
- where
- .I host_os
- will be one of:
- .CW FreeBSD ,
- .CW Linux ,
- or
- .CW Solaris
- and
- .I host_arch
- will be one of:
- .CW 386 ,
- .CW mips ,
- .CW power
- or
- .CW sparc .
- Most platforms offer just the one obvious combination.
- The Windows installation program is called
- .CW setup.exe ;
- it is used on all varieties of Windows.
- The next step describes how to begin the installation by running the program
- that corresponds to your host system.
- .Ss "Run the installation script."
- The installation program will copy files from the CD to the filesystem.
- The Windows installation program will also create registry entries and add
- an Inferno item to the Windows
- .I start
- menu.
- On Plan 9, run
- .P1
- rc \fIcd_path\fP/install/Plan9.rc \fIinferno_root\fP
- .P2
- Where
- .I inferno_root
- is the path to the chosen Inferno root directory. The CPU architecture
- will be inferred from the environment variable
- .CW cputype .
- On Unix, run
- .P1
- sh \fIcd_path\fP/install/\fIhost-os\fP-\fIhost_arch\fP.sh \fIinferno_root\fP
- .P2
- Where
- .I host_os
- is the Unix variant name
- .CW FreeBSD , (
- .CW Irix ,
- .CW Linux
- or
- .CW Solaris ).
- .I host_arch
- is the CPU type (eg,
- .CW 386 ),
- and
- .I inferno_root
- is the path to the chosen Inferno directory.
- On Windows, run
- .P1
- \fIcd_drive\f(CW:\einstall\esetup.exe
- .P2
- The Windows installation program will ask you to choose the location of the installation
- directory on the hard disk.
- .LP
- On all platforms, a copy of Inferno
- on the CD will install from various installation packages on the CD to the
- .I inferno_root
- subtree on the filesystem.
- On any platform it installs support for all.
- .LP
- Inferno is now installed, but it needs to be configured
- for your site.
- The process acts as a quick tour of parts of the system.
- The main tasks are to add local parameters to the network data base,
- and to set up the authentication system.
- If you are going to run Inferno standalone, for instance to experiment with Limbo
- and the file serving interface,
- most of what follows can be deferred indefinitely.
- It is still worthwhile skimming through it, because the first few sections tell how
- to start up Inferno with correct parameters (eg, root directory and graphics resolution).
- (A configuration program that runs under the window system would be more convenient,
- and fairly easy to do, but that has not yet been done.)
- .NH
- Running Inferno
- .LP
- Inferno host executables are all kept in a single directory corresponding
- to the combination of host operating system and CPU architecture \- the Inferno
- .CW bin
- directory.
- .P1
- \fIinferno_root\fP/\fIhost_os\fP/\fIhost_arch\fP/bin
- .P2
- (On Windows the path might need
- .CW \e
- not
- .CW /
- of course.)
- That directory can be added to the search path of the host system's command interpreter,
- and that process will be described first, although as discussed later one can use a script
- instead and that is sometimes more convenient.
- (Of course, the script will still need to refer to that directory.)
- .LP
- .I "Plan 9:\ \ "
- Plan 9 users should add a line to their
- .CW lib/profile
- file that binds this directory after their
- .CW /bin
- directory.
- .P1
- bind -a /usr/inferno/Plan9/$cputype/bin /bin
- .P2
- The bind is done after the existing
- .I bin
- directory to avoid hiding the existing Plan 9 compilers.
- If, at a later stage, you build either the hosted or native Inferno kernels for ARM or StrongARM
- you should ensure that the Inferno compilers are used rather than
- the Plan 9 compilers, since they differ in the implementation of
- floating-point instructions (the Plan 9 ARM suite uses a byte order that is more plausible
- than the order ARM dictates but therefore wrong).
- That difference is likely to be resolved at some point but it has not yet been done.
- .LP
- .I "Windows:\ \"
- The
- .I host_os
- is always
- .CW Nt
- (even for Windows 98, 2000 or XP)
- and
- .I host_arch
- is always
- .CW 386
- and the installation program will create an entry on the
- .I "start menu"
- to invoke Inferno.
- For Unix systems or Windows systems in which Inferno will be started
- from a command shell, the environment variable
- .CW PATH
- should be set to include the Inferno
- .CW bin
- directory.
- For Windows 95 and Windows 98 this should be done in the
- .CW \eautoexec.bat
- file by adding a line like
- .P1
- PATH=c:\einferno\eNt\e386\ebin;%PATH%
- .P2
- You will need to reboot Windows to have the system reread the
- .CW \eautoexec.bat
- file.
- For Windows NT and Windows 2000 modify the
- .CW Path
- environment variable through
- .I "Control Panel -> System -> Environment" .
- .LP
- If you are using an MKS or Cygwin Unix-like shell environment,
- you might instead set:
- .P1
- PATH="c:/inferno/Nt/386/bin;$PATH"
- .P2
- and export it if necessary.
- .LP
- .I "Unix:\ \"
- For Unix systems, for
- .CW sh
- derivatives, the environment variable
- .CW PATH
- should be set to include the Inferno
- .CW bin
- directory.
- This might be done in your
- .CW .profile
- file by adding a line like
- .P1
- PATH="/usr/inferno/Linux/386/bin:$PATH"
- .P2
- Don't forget to ensure that
- .CW PATH
- is exported.
- You may need to log out and back in again for the changes to take effect.
- .KS
- .Ss "Start Inferno."
- Hosted inferno is run by invoking an executable called
- .I emu .
- .KE
- On Windows, select the Inferno option from the
- .I "start menu" .
- This will invoke
- .I emu
- with appropriate arguments to find its files in
- .I inferno_root .
- If you need to change any of the options passed to
- .I emu
- when invoked from the
- .I "start menu"
- you need to do this by clicking the right mouse button
- on the Windows task bar and choosing
- .I "Properties -> Start Menu Programs -> Advanced"
- to modify the shortcut used for Inferno.
- For Unix and Plan 9, you will need to tell
- .I emu
- where to find the Inferno file tree by passing it the
- .CW -r\fIrootpath\f(CW
- command line option. For example
- .P1
- emu -r/usr/john/inferno
- .P2
- Without the
- .CW -r
- option it will look for the file tree in
- .CW /usr/inferno
- on Plan 9 and Unix and, when invoked from the command line on WIndows,
- the default is
- .CW \einferno
- on the current drive.
- (The Windows start menu by contrast has already been set to use the right directory by the installation software.)
- .LP
- When using graphics,
- .I emu
- will use a window with a resolution of 640 x 480 pixels by default. To use a larger resolution
- you will need to pass
- .I emu
- an option
- .CW -g\fIXsize\f(CWx\fIYsize\f(CW
- on the command line. So, for example, to invoke
- .I emu
- as above but with a resolution of 1024 x 768 pixels the full command line
- would be
- .P1
- emu -r/usr/john/inferno -g1024x768
- .P2
- When invoked in this way
- .I emu
- displays a command window running the Inferno shell
- .CW /dis/sh.dis .
- To avoid typing the command line options each time you invoke
- .I emu
- you can store them in the environment variable
- .CW EMU
- which is interrogated when
- .I emu
- is started and might as well be set along side the
- .CW PATH
- environment variable if the same configuration options are to be used on
- each invocation.
- .P1
- set EMU="-rd:\eDocuments and Settings\ejohn\einferno -g1024x768"
- .P2
- for Windows.
- .P1
- EMU=(-r/usr/john/inferno -g1024x768)
- .P2
- for Plan 9, and
- .P1
- EMU="-r/usr/john/inferno -g1024x768"
- .P2
- for Unix.
- An alternative to using the
- .CW EMU
- environment variable is to place the correct invocation in a
- script file (or batch file, for Windows) and invoke that instead
- of running
- .I emu
- directly.
- It is important to note that for Windows the
- .CW -r
- option also serves to indicate both the drive and directory on to which the software
- has been installed. Without a drive letter the system will assume the
- current drive and will fail if the user changes to an alternative drive.
- Once the environment variables or scripts are set up, as described above, invoking plain
- .P1
- emu
- .P2
- or the appropriate script file,
- should result in it starting up Inferno's command interpreter
- .I sh (1),
- which prompts with a semicolon:
- .P1
- ;
- .P2
- You can add a further option
- .CW -c1
- to start up
- .I emu
- in a
- mode in which the system compiles a module's
- Dis operations to native machine instructions when a module
- is loaded.
- (See the
- .I emu (1)
- manual page.)
- In
- .I compile
- mode programs that do significant computation will run much faster.
- Whether in compiled or interpreted mode you should now have a functional
- hosted Inferno system.
- When Inferno starts the initial
- .CW /dis/sh.dis
- it reads commands from the file
- .CW /lib/sh/profile
- before becoming interactive. See the manual pages for the shell
- .I sh (1)
- to learn more about tailoring the initial environment.
- .LP
- The semicolon is the default shell prompt. From this command window
- you should be able to see the installed Inferno files and directories
- .P1
- lc /
- .P2
- The command
- .I lc
- presents the contents of its directory argument in columnar fashion to standard
- output in the command window.
- .P1
- ; lc /
- FreeBSD/ Unixware/ icons/ libkern/ man/ prof/
- Hp/ acme/ include/ libkeyring/ mkconfig prog/
- Inferno/ appl/ keydb/ libmath/ mkfile services/
- Irix/ asm/ legal/ libmemdraw/ mkfiles/ tmp/
- LICENCE chan/ lib/ libmemlayer/ mnt/ tools/
- Linux/ dev/ lib9/ libtk/ module/ usr/
- MacOSX/ dis/ libbio/ licencedb/ n/ utils/
- NOTICE doc/ libcrypt/ limbo/ net/ wrap/
- Nt/ emu/ libdraw/ locale/ nvfs/
- Plan9/ env/ libfreetype/ mail/ o/
- Solaris/ fonts/ libinterp/ makemk.sh os/
- ;
- .P2
- Only the files and directories in and below the
- .I inferno_root
- directory on the host filesystem are immediately visible to an Inferno process;
- these files are made visible in the root of the Inferno file namespace.
- If you wish to import or export files
- from and to the host filesystem you will need to use tools on your
- host to move them in or out of the Inferno visible portion of your host
- filesystem (see the manual pages
- .I os (1)
- and
- .I cmd (3)
- for an interface to host commands).
- (We plan to make such access direct, but the details are still being worked out.)
- From this point onwards in this paper all file paths not qualified with
- .I inferno_root
- are assumed to be in the Inferno namespace.
- Files created in the host filesystem will be created with the user id of
- the user that started
- .I emu
- and on Unix systems with that user's group id.
- .NH
- Setting the site's time zone
- .LP
- Time zone settings are defined by
- files in the directory
- .CW /locale .
- The setting affects only how the time is displayed; the internal representation does not vary.
- For instance, the file
- .CW /locale/GMT
- defines Greenwich Mean Time,
- .CW /locale/GB-Eire
- defines time zones for Great Britain and the Irish Republic
- (GMT and British Summer Time), and
- .CW /locale/US_Eastern
- defines United States
- Eastern Standard Time and Eastern Daylight Time.
- The time zone settings used by applications are read
- (by
- .I daytime (2))
- from the file
- .CW /locale/timezone ,
- which is initially a copy of
- .CW /locale/GB-Eire .
- If displaying time as the time in London is adequate, you need change nothing.
- To set a different time zone for the whole site,
- copy the appropriate time zone file into
- .CW /locale/timezone :
- .P1
- cp /locale/US_Eastern /locale/timezone
- .P2
- To set a different time zone for a user or window,
- .I bind (1)
- the file containing the time zone setting over
- .CW /locale/timezone ,
- either in the user's profile or in a name space description file:
- .P1
- bind /locale/US_Eastern /locale/timezone
- .P2
- .NH
- Running the
- Window Manager
- .I wm
- .LP
- Graphical Inferno programs normally run under the window manager
- .I wm (1).
- Inferno has a simple editor,
- .I wm/edit ,
- that can be used to edit the inferno configuration files.
- The `power environment' for editing and program development is
- .I acme (1),
- but rather that throwing you in at the deep end, we shall stick to
- the simpler one for now.
- If you already know Acme from
- Plan 9, however, or perhaps Wily from Unix, feel free to use Inferno's
- .I acme
- instead of
- .I edit .
- .Ss "Start the window manager."
- Invoke
- .I wm
- by typing
- .P1
- wm/wm
- .P2
- You should see a new window open with a blue-grey background and a small
- .I "Vita Nuova"
- logo in the bottom left hand corner. Click on the logo with mouse button 1
- to reveal a small menu.
- Selecting the
- .I Edit
- entry will start
- .I wm/edit .
- In common with most
- .I wm
- programs the editor has three small buttons in a line at its top right hand corner.
- Clicking on the X button, the rightmost button,
- will close the program down. The leftmost of the three buttons will allow the window
- to be resized \- after clicking it drag the window from a point near to either one of its
- edges or one of its corners. The middle button will minimise the window, creating
- an entry for it in the application bar along the bottom of the main
- .I wm
- window. You can restore a minimised window by clicking on its entry in the application bar.
- The initial
- .I wm
- configuration is determined by the contents of the shell
- script
- .CW /lib/wmsetup
- (see
- .I toolbar (1)
- and
- .I sh (1)).
- .Ss "Open a shell window."
- Choose the
- .I shell
- option from the menu to open up a shell window. The configuration of Inferno
- will be done from this shell window.
- .NH
- Manual Pages
- .LP
- Manual pages for all of the system commands are available from a shell
- window. Use the
- .I man
- or
- .I wm/man
- commands. For example,
- .P1
- man wm
- .P2
- will give information about
- .I wm .
- And
- .P1
- man man
- .P2
- will give information about using
- .I man .
- .I Wm/man
- makes use of the Tk text widget to produce slightly more
- attractive output than the plain command
- .I man .
- Here, and in other Inferno documentation you will see references to manual page
- entries of the form \fIcommand\f(CW(\fIsection\f(CW)\fR.
- You can display the manual page for the command by running
- .P1
- man \fIcommand\fP
- .P2
- or
- .P1
- man \fIsection\fP \fIcommand\fP
- .P2
- if the manual page appears in more than one section.
- .NH
- Initial Namespace
- .LP
- The initial Inferno namespace is built
- by placing the root device '#/' (see
- .I root (3))
- at the root of the namespace and binding
- .nr ,i 0 1
- .af ,i i
- .IP \n+(,i)
- the host filesystem device '#U' (see
- .I fs (3))
- containing the
- .I inferno_root
- subtree of the host filesystem at the root of the Inferno filesystem,
- .IP \n+(,i)
- the console device '#c' (see
- .I cons (3))
- in
- .CW /dev ,
- .IP \n+(,i)
- the prog device '#p' (see
- .I prog (3))
- onto
- .CW /prog ,
- .IP \n+(,i)
- the IP device '#I' (see
- .I ip (3))
- in
- .CW /net ,
- and
- .IP \n+(,i)
- the environment device '#e' (see
- .I env (3))
- at
- .CW /dev/env .
- .rr ,i
- .LP
- You can see the sequence of commands required to construct the current namespace
- by running
- .P1
- ns
- .P2
- .NH
- Inferno's network
- .LP
- If you are just going to use Inferno for local Limbo programming, and not use its
- networking interface, you can skip to the section ``Adding new users'' at the end of this document.
- You can always come back to this step later.
- .LP
- To use IP networking, the IP device
- .I ip (3)) (
- must have been bound into
- .CW /net .
- Typing
- .P1
- ls -l /net
- .P2
- (see
- .I ls (1))
- should result in something like
- .P1
- --rw-rw-r-- I 0 network john 0 May 31 07:11 /net/arp
- --rw-rw-r-- I 0 network john 0 May 31 07:11 /net/ndb
- d-r-xr-xr-x I 0 network john 0 May 31 07:11 /net/tcp
- d-r-xr-xr-x I 0 network john 0 May 31 07:11 /net/udp
- .P2
- There might be many more names on some systems.
- .LP
- A system running Inferno, whether native or hosted, can by agreement attach to any or all resources that
- are in the name space of another Inferno system (or even its own).
- That requires:
- .IP •
- the importing system must know where to find them
- .IP •
- the exporting system must agree to export them
- .IP •
- the two systems must authenticate the access (not all resources will be permitted to all systems or users)
- .IP •
- the conversation can be encrypted to keep it safe from prying eyes and interference
- .LP
- On an Inferno network, there is usually one secure machine that acts as authentication server.
- All other systems variously play the rôles of server and client as required: any system can import some resources (or none)
- and export others (or none), simultaneously, and differently in different name spaces.
- In following sections, we shall write as though there were three distinct machines:
- authentication server (signer); server (exporting resources); and client (importing resources).
- With Inferno, you can achieve a similar effect on a single machine by starting up distinct
- instances of
- .I emu
- instead.
- That is the easiest way to become familiar with the process (and also avoids having to install
- the system on several machines to start).
- It is still worthwhile setting up a secured
- authentication server later, especially if you are using Windows on a FAT file system
- where the host system's file protections are limited.
- .LP
- We shall now configure Inferno to allow each of the functions listed above:
- .IP •
- change the network database to tell where to find local network resources
- .IP •
- set up the authentication system, specifically the authentication server or `signer'
- .IP •
- start network services (two distinct sets: one for the authentication services and the other for
- all other network services)
- .NH
- Network database files
- .LP
- In both hosted and native modes, Inferno uses a collection of text files
- of a particular form to store all details of network and service configuration.
- When running hosted, Inferno typically gets most of its data from the host operating system,
- and the database contains mainly Inferno-specific data.
- .LP
- The file
- .CW /lib/ndb/local
- is the root of the collection of network database files.
- The format is defined by
- .I ndb (6),
- but essentially it is a collection of groups of attribute/value pairs of the form
- \fIattribute\fP\f(CW=\fP\fIvalue\fP.
- Attribute names and most values are case-sensitive.
- .LP
- Related attribute/value pairs are grouped into database `entries'.
- An entry can span one or more
- lines: the first line starts with a non-blank character,
- and any subsequent lines in that entry start
- with white space (blank or tab).
- .NH 2
- Site parameters
- .LP
- The version of
- .CW /lib/ndb/local
- at time of writing looks like this:
- .P1
- database=
- file=/lib/ndb/local
- file=/lib/ndb/dns
- file=/lib/ndb/inferno
- file=/lib/ndb/common
- infernosite=
- #dnsdomain=your.domain.com
- #dns=1.2.3.4 # resolver
- SIGNER=your_Inferno_signer_here
- FILESERVER=your_Inferno_fileserver_here
- smtp=your_smtpserver_here
- pop3=your_pop3server_here
- registry=your_registry_server
- .P2
- The individual files forming the data base are listed in order in the
- .CW database
- entry.
- They can be ignored for the moment.
- The entry labelled
- .CW infernosite=
- defines a mapping from symbolic host names of the form
- .CW $\fIservice\f(CW
- to a host name, domain name, or a numeric Internet address.
- For instance, an application that needs an authentication service
- will refer to
- .CW $SIGNER
- and an Inferno naming service will translate that at run-time to the appropriate network name for
- that environment.
- Consequently,
- the entries above need to be customised for a given site.
- (The items that are commented out are not needed when the host's own DNS resolver is used instead
- of Inferno's own
- .I dns (8).)
- For example, our
- .CW infernosite
- entry in the
- .CW local
- file might look something like this
- .P1
- infernosite=
- dnsdomain=vitanuova.com
- dns=200.1.1.11 # resolver
- SIGNER=doppio
- FILESERVER=doppio
- smtp=doppio
- pop3=doppio
- registry=doppio
- .P2
- where
- .CW doppio
- is the host name of a machine that is offering the given services to Inferno,
- and
- .CW 200.1.1.11
- is the Internet address of a local DNS resolver.
- .Ss "Enter defaults for your site"
- .LP
- The only important names initially are:
- .IP \f(CWSIGNER\fP 20
- the host or domain name, or address of the machine that will act as signer
- .IP \f(CWregistry\fP
- the name or address of a machine that provides the local dynamic service
- .I registry (4)
- .IP \f(CWFILESERVER\fP
- the primary file server (actually needed only by clients with no storage of their own)
- .LP
- All others are used by specific applications such as
- .I acme (1)
- mail or
- .I ftpfs (4).
- .LP
- If you are using a single machine for signer and server/client, put its name in those three entries.
- .NH 2
- Connection server
- .I cs (8)
- and name translation
- .LP
- The connection server
- .I cs (8)
- uses the network database
- and other
- data (such as that provided by the host system and
- the Internet DNS servers) to translate symbolic network names and services into instructions
- for connecting to a given service.
- In hosted mode,
- network and service names are passed through to the host for conversion to numeric IP
- addresses and port numbers. If the host is unable to convert a service name
- the connection server will attempt to convert the name using mappings
- of service and protocol names to Internet port numbers
- in the file
- .CW /lib/ndb/inferno :
- .P1
- tcp=infgamelogin port=6660 # inferno games login service
- tcp=styx port=6666 # main file service
- tcp=mpeg port=6667 # mpeg stream
- tcp=rstyx port=6668 # remote invocation
- tcp=infdb port=6669 # database server
- tcp=infweb port=6670 # inferno web server
- tcp=infsigner port=6671 # inferno signing services
- tcp=infcsigner port=6672 # inferno countersigner
- tcp=inflogin port=6673 # inferno credential service
- tcp=infsds port=6674 # software download
- tcp=registry port=6675 # registry(4)
- udp=virgil port=2202 # naming service
- .P2
- For the moment, leave that file as it is.
- You will only need to modify this file if in future
- you add new statically-configured services to Inferno.
- (Services that come and go dynamically might use
- .I registry (4)
- instead, a registry manager that allows a service to be found
- using a description of it.)
- .NH
- Configuring a Signer
- .LP
- Before an Inferno machine can authenticate establish a secure connection to an Inferno
- service on another machine, each system needs to obtain a certificate from a common signer.†
- We talk here as though there is only one `signer' per site but in fact there can be application- or
- group-specific ones.
- For instance, a version of the Inferno games server automatically starts its own signing service to
- keep the identities and keys used for game service separate from those of the primary
- system, allowing users to set up their own gaming groups without fuss.
- .FS
- .FA
- †The authentication system will shortly expand to a rôle-based one allowing a chain of certificates to be used,
- from several signers, with delegation etc.
- .FE
- To use authenticated connections for the primary
- file services we need to set up a signer to generate
- certificates for users (see
- .I createsignerkey (8)
- and
- .I logind (8)).
- .LP
- Choose an Inferno machine to become the signer.
- If this is the first or only
- Inferno machine on your network then make this machine the signer.
- (It is more realistic if you start up a separate copy of
- .I emu
- and leave it in `console' mode without starting the window system.)
- You can always move the function elsewhere later.
- .Ss "Empty the secret file of secrets."
- The authentication server verifies a user's identity by checking that the user knows a shared secret.
- (In fact the secret is not used directly, but instead a scrambled value that was derived from it.)
- The file
- .CW /keydb/keys
- holds those secrets; it is encrypted using a secret password or phrase known only to the
- manager of the authentication server.
- Having just installed Inferno, the file
- should exist and be readable only by you (or the user as which the authentication service will run).
- On the signer machine, type
- .P1
- ls -l /keydb/keys
- .P2
- You should see something like:
- .P1
- --rw------- M 7772 yourname inf 0 Jun 12 03:08 /keydb/keys
- .P2
- You should see something like the above.
- If the file does not exist or is not empty or has the wrong mode, use:
- .P1
- cp /dev/null /keydb/keys; chmod 600 /keydb/keys
- .P2
- to set it right.
- .Ss "Generate a signer key."
- Next on the signer machine, run
- .P1
- auth/createsignerkey \fIname\fP
- .P2
- In place of
- .I name
- enter the network name of the signer. A fully-qualified domain name of a
- host or individual is fine.
- This value will appear as the signer name in each
- certificate generated by the signer.
- .I Createsignerkey
- creates public and private keys that are used by the signer when generating
- certificates.
- They are stored in
- .CW /keydb/signerkey ;
- check that it has permissions that limit access to the user that will run the
- authentication services:
- .P1
- ; ls -l /keydb/signerkey
- --rw------- M 32685 secrets inf 1010 Jul 07 2000 /keydb/signerkey
- .P2
- Use
- .I chmod (1)
- to set the mode to read/write only for the owner if necessary:
- .P1
- chmod 600 /keydb/signerkey
- .P2
- .Ss "Start the authentication network services"
- Still at the signer console, type
- .P1
- svc/auth
- .P2
- That script (see
- .I svc (8))
- will check that the
- .CW /keydb/keys
- and
- .CW /keydb/signerkey
- files exist, and then
- start the program
- .I keyfs (4),
- which manages the
- .CW keys
- file.
- It will prompt for the password (pass phrase) you wish to use to protect the
- .CW keys
- file, now and on subsequent runs:
- .P1
- ; svc/auth
- Key:
- Confirm key:
- .P2
- It prompts twice to confirm it.
- If successfully confirmed, it will then
- start the
- network services used by Inferno to authenticate local and remote users and hosts.
- (If confirmation fails, retry by running
- .CW svc/auth
- again.)
- .LP
- You can check that they are running by typing:
- .P1
- ps
- .P2
- which should show something like the following:
- .P1
- 1 1 john release 74K Sh[$Sys]
- 3 2 john alt 15K Cs
- 10 9 john recv 25K Keyfs
- 11 9 john release 44K Styx[$Sys]
- 12 9 john recv 25K Keyfs
- 14 1 john alt 8K Listen
- 16 1 john release 8K Listen[$Sys]
- 18 1 john alt 9K Listen
- 20 1 john release 9K Listen[$Sys]
- 22 1 john alt 9K Listen
- 24 1 john release 9K Listen[$Sys]
- 26 1 john alt 8K Listen
- 28 1 john release 8K Listen[$Sys]
- 29 1 john ready 73K Ps[$Sys]
- .P2
- There should be
- .CW Keyfs
- and
- .CW Listen
- processes.
- .Ss "Enter user names and secrets."
- For each user to be authenticated by the signer run
- .P1
- auth/changelogin \fIusername\fP
- .P2
- You will be prompted to supply a secret (ie, password or pass phrase) and expiration date.
- The expiration date will be used
- as the maximum expiration date of authentication certificates granted to that user.
- .I Changelogin
- (see
- .I changelogin (8))
- accesses the name space generated by
- .I keyfs (4),
- which has just been started above by
- .CW svc/auth .
- A user can later change the stored secret using the
- .I passwd (1)
- command.
- For the signer to generate a certificate there must be at least one entry in the
- password file.
- If you are not sure at this stage of the names of the users that you want to
- authenticate then create an entry for the user
- .CW inferno
- and yourself.
- .NH
- Establishing a Secure Connection
- .LP
- To establish a secure connection between two Inferno machines, each needs to present a public key with
- a certificate signed by a common signer.
- We shall make two public/private key sets, one for the server and one for a client
- (they differ only in where they are stored).
- We shall do the server first, because the usual network services require
- the server possess some keys before they can start.
- We shall then start those services, and finally sort out the client.
- .Ss "Start the connection service."
- The server still needs to make contact with the signer, so we need to start the basic connection service
- .I cs (8).
- If you are using the same instance of
- .I emu
- in which you invoked
- .CW svc/auth
- above, you should skip this step.
- To check, you should see a new file in the
- .CW /net
- directory called
- .CW cs .
- Run the command
- .P1
- ls /net
- .P2
- You should see at least the following names in the output:
- .P1
- /net/cs
- /net/ndb
- /net/tcp
- /net/udp
- .P2
- Otherwise, type
- .P1
- ndb/cs
- .P2
- That starts
- .I cs (8).
- Try the
- .CW "ls /net"
- again to check that the
- .CW cs
- file has appeared.
- .LP
- .Ss "Generate a server key set."
- On the server machine (or in the `server' window),
- use
- .I getauthinfo (8)
- to obtain a certificate and save it in a file named
- .CW default
- by running
- .P1
- getauthinfo default
- .P2
- .I Getauthinfo
- will prompt for the address of your signer (you can often
- just use its host name or even
- .CW localhost )
- and for a remote username and password
- combination.
- .I Getauthinfo
- will connect to the
- .I inflogin
- service on the signer and authenticate you against its user and password database,
- .CW /keydb/keys ,
- using the username and password that you entered above.
- Answer
- .CW yes
- to the question that asks if you want to save the certificate in a file.
- .I Getauthinfo
- will save a certificate in the file
- .CW /usr/\fIuser\f(CW/keyring/default
- where
- .I user
- is the name in
- .CW /dev/user .
- .NH
- Network Services
- .LP
- As mentioned above, in a full Inferno network
- the authentication services will usually be run on a secured machine of their own (the signer),
- and the ordinary network services such as file service are not run on a signer.
- If you are, however, using one machine for all functions, you can get the right
- effect by starting another instance of
- .I emu ,
- to act as an Inferno host that is not a signer.
- This one will run the services of a primary file server
- and the site
- .I registry (4).
- .LP
- Commands described in
- .I svc (8)
- start listeners for various local network services.
- (The commands are actually shell scripts.)
- As we saw above,
- .CW svc/auth
- starts the services on a signer.
- .LP
- Here we shall start the usual set of services.
- .KS
- .Ss "Start the network listener services."
- Type
- .P1
- svc/net
- .P2
- .KE
- Various network services will (should!) now be running. To confirm this type
- .P1
- ps
- .P2
- which should show something like the following:
- .P1
- ; ps
- 1 1 inferno release 74K Sh[$Sys]
- 7 6 inferno alt 15K Cs
- 13 1 inferno recv 15K Registry
- 14 1 inferno release 44K Styx[$Sys]
- 15 1 inferno recv 15K Registry
- 17 1 inferno alt 8K Listen
- 19 1 inferno release 8K Listen[$Sys]
- 22 1 inferno alt 8K Listen
- 24 1 inferno release 8K Listen[$Sys]
- 25 1 inferno ready 74K Ps[$Sys]
- .P2
- There should be a few
- .CW Listen
- processes and perhaps a
- .CW Registry .
- .LP
- You can also try
- .P1
- netstat
- .P2
- .I Netstat
- prints information about network connections. You should see
- several lines of output, each one describing an announced TCP or UDP service.
- Depending upon the contents of the network configuration files we included on the CD,
- you might see output something like this:
- .P1
- tcp/1 Announced inferno 200.1.1.89!6668 ::!0
- tcp/2 Announced inferno 200.1.1.89!6666 ::!0
- tcp/3 Announced inferno 200.1.1.89!6675 ::!0
- .P2
- Each line corresponds to a network connection:
- the connection name, the name of the user running the server,
- the address of the local end of the connection,
- the address of the remote end of the connection,
- and the connection status.
- The connection name is actually the protocol and conversation directory
- in
- .CW /net .
- The connection addresses are all of the form \fIhost\f(CW!\fIport\fR
- for these IP based services, and the remote addresses are not filled in
- because they all represent listening services that are in the
- .CW Announced
- state.
- In this example the third line shows a TCP service listening on port 6675.
- Examining
- .CW /lib/ndb/inferno
- with
- .CW grep
- (see
- .I grep (1))
- shows that the listener on port 6675 is the Inferno registry service
- .P1
- grep 6675 /lib/ndb/inferno
- .P2
- gives
- .P1
- tcp=registry port=6675 # default registry
- .P2
- .LP
- Now the server is ready but we need a client.
- .LP
- Either use a third machine or (more likely at first) simply start another
- .I emu
- instance in a new window.
- Start its connection server, again by typing
- .P1
- ndb/cs
- .P2
- The connection server is fundamental to the Inferno network.
- Once networking is set up, when subsequently starting up
- a client you should start
- .I cs
- before starting the window system.
- Note that if you are running the Inferno instance as a server, or combined
- server and client,
- the
- .CW svc/net
- that starts the network services
- automatically starts
- .I cs ,
- and you need not do so explicitly.
- .LP
- .Ss "Generate a client certificate."
- Obtain a certificate for the client in the same way as on the server.
- We shall obtain a certificate for use with a specific server
- by storing
- it in a file whose name exactly matches the network address of the server
- .P1
- getauthinfo tcp!\fIhostname\fP
- .P2
- Use the current machine's
- .I hostname .
- .I Getauthinfo
- stores the certificate in the file
- .CW /usr/\fIuser\fP/keyring/\fIkeyname\fP
- where
- .I user
- is the name in
- .CW /dev/user
- and
- .I keyname
- is the argument given to
- .I getauthinfo .
- Again,
- answer
- .CW yes
- to the question that asks if you want to save the certificate in a file.
- .LP
- Now that both client and server have a certificate obtained from the same signer
- it is possible to establish a secure connection between them.
- Note that getting keys and certificates with
- .I getauthinfo
- is normally done just once (or at most once per server when the
- .CW default
- key is not used).
- In short, all the work done up to now need not be repeated.
- After this, provided the keys were saved to a keyring file,
- as many authenticated connections can be made as desired
- until the certificate expires (which by default is whenever the password entry
- was set to expire).
- Also note that the certificates for different machines can have
- different signers, and one can even use different certificates for the same machine
- when the remote user name is to differ
- (the
- .CW -f
- option of
- .I getauthinfo
- can then be useful to force an appropriate keyring name).
- .Ss "Make an authenticated connection."
- The script
- .CW svc/net
- on the server started fundamental name services and also a Styx file service.
- That can also be started separately using
- .CW svc/styx .
- In either case the namespace that is served
- is the one in which the command was invoked.
- Now you can test the service.
- .LP
- Confirm that
- .CW /n/remote
- is an empty directory by typing
- .P1
- lc /n/remote
- .P2
- You can now mount the server's name space
- onto the client's directory
- .CW /n/remote
- by typing
- .P1
- mount \fIserveraddr\fP /n/remote
- .P2
- Where
- .I serveraddr
- is the IP address of the server or a name that the host can resolve to the
- IP address of the server.
- Now
- .P1
- lc /n/remote
- .P2
- should reveal the files and directories in the namespace being served by the server.
- Those files are now also visible in the namespace of your shell.
- You will notice that these changes only affect the shell in which you ran the
- .I mount
- command \- other windows are unaffected.
- You can create, remove or modify files and directories in and under
- .CW /n/remote
- much as you can any other file or directory in your namespace.
- In fact, in general, a process does not need to know whether a file
- actually resides locally or remotely.
- You can unmount the mounted directory with
- .I unmount .
- Type
- .P1
- unmount /n/remote
- .P2
- You can confirm that it has gone by running
- .P1
- ls /n/remote
- .P2
- All connections made by Inferno are authenticated. The default connection
- made by
- .I mount
- is authenticated but uses neither encryption nor secure digests.
- You can pass an argument to
- .I mount
- to specify
- a more secure connection:
- its
- .CW -C
- option gives it a hashing and an encryption algorithm to be applied to
- the connection.
- .KS
- .Ss "Make a secure authenticated connection."
- For example,
- .P1
- mount -C sha1/rc4_256 \fIserveraddr\fP /n/remote
- .P2
- makes an authenticated connection to the machine given by
- .I serveraddr ,
- then engages SHA1 hashing for message digesting and 256-bit RC4 for encryption.
- .KE
- It mounts the namespace served by
- .I serveraddr 's
- Styx service on the local Inferno directory
- .CW /n/remote .
- .NH
- Adding new users
- .LP
- Every inferno process has an associated
- .I "user name" .
- At boot time the user name is set equal to your login name on the host
- operating system.
- The user name is used by
- .I wm/logon
- to select the home directory, and
- by other programs like
- .I mount
- when it searches for certificates.
- (It can also control permission for file access on the local system in native Inferno
- and some hosted Inferno configurations.)
- When you attach to a server on another
- system the user name in the authenticating certificate can be used by
- the remote file service to set the user name appropriately there.†
- .FS
- .FA
- †The details are system-dependent and currently subject to change.
- .FE
- .LP
- To create a new user, copy the directory
- .CW /usr/inferno
- into
- \f(CW/usr/\fP\fIusername\fP.
- If the user is to have access to services on the network,
- make an authentication server entry using
- .I changelogin (8).
- The user can change the stored secret using
- .I passwd (1),
- if desired.
- Having logged in for the first time, the user should generate
- a default public/private key set using
- .I getauthinfo (8).
- (The authentication services must be running somewhere.)
- .LP
- The
- .I wm
- window manager program
- .I wm/logon
- allows a user to login to the local Inferno system as an Inferno
- user (different from the host user name).
- Its use is shown next.
- .Ss "Re-start Inferno."
- You should now close down any instances of
- .I emu
- that you are currently running.
- The quickest way to do this is to
- type
- .I control-c
- in the emu window in which you ran
- .I wm/wm .
- Start a new
- .I emu ,
- as before, by either running
- .P1
- emu
- .P2
- or by choosing the appropriate entry from your start menu on
- Windows machines. This time, start network services
- .P1
- svc/net
- .P2
- and then run
- .P1
- wm/wm wm/logon
- .P2
- and log in as user
- .I inferno .
- When you log in,
- .I wm/logon
- will change directory to
- .CW /usr/inferno
- and then write the name
- .CW inferno
- to
- .CW /dev/user .
- If the file
- .CW /usr/inferno/namespace
- exists it will be used to construct a new namespace for the user
- based on the commands that it contains (see
- .I newns (2)).
- .NH
- What next
- .LP
- You should now have a fully functional Inferno system.
- You will need to have a three button mouse to use
- .I acme ,
- .I wm ,
- or
- .I plumbing .
- .LP
- To learn more you could start with the manual pages for:
- .I intro (1),
- .I emu (1),
- .I wm (1),
- .I wm-misc (1),
- .I sh (1),
- .I acme (1),
- and
- .I limbo (1)
- and also the papers in sections 1, 2 and 3
- of Volume 2 of
- .I "The Inferno Programmer's Manual" .
|