share/doc/smm/02.config/5.t

   1 .\" Copyright (c) 1983, 1993
   2 .\"     The Regents of the University of California.  All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)5.t 8.1 (Berkeley) 6/8/93
  33 .\"
  34 .\".ds RH "Sample Configuration Files
  35 .ne 2i
  36 .NH
  37 SAMPLE CONFIGURATION FILES
  38 .PP
  39 In this section we will consider how to configure a
  40 sample VAX-11/780 system on which the hardware can be
  41 reconfigured to guard against various hardware mishaps.
  42 We then study the rules needed to configure a VAX-11/750
  43 to run in a networking environment.
  44 .NH 2
  45 VAX-11/780 System
  46 .PP
  47 Our VAX-11/780 is configured with hardware
  48 recommended in the document ``Hints on Configuring a VAX for 4.2BSD''
  49 (this is one of the high-end configurations).
  50 Table 1 lists the pertinent hardware to be configured.
  51 .DS B
  52 .TS
  53 box;
  54 l | l | l | l | l
  55 l | l | l | l | l.
  56 Item    Vendor  Connection      Name    Reference
  57 _
  58 cpu     DEC             VAX780
  59 MASSBUS controller      Emulex  nexus ? mba0    hp(4)
  60 disk    Fujitsu mba0    hp0
  61 disk    Fujitsu mba0    hp1
  62 MASSBUS controller      Emulex  nexus ? mba1
  63 disk    Fujitsu mba1    hp2
  64 disk    Fujitsu mba1    hp3
  65 UNIBUS adapter  DEC     nexus ?
  66 tape controller Emulex  uba0    tm0     tm(4)
  67 tape drive      Kennedy tm0     te0
  68 tape drive      Kennedy tm0     te1
  69 terminal multiplexor    Emulex  uba0    dh0     dh(4)
  70 terminal multiplexor    Emulex  uba0    dh1
  71 terminal multiplexor    Emulex  uba0    dh2
  72 .TE
  73 .DE
  74 .ce
  75 Table 1.  VAX-11/780 Hardware support.
  76 .LP
  77 We will call this machine ANSEL and construct a configuration
  78 file one step at a time.
  79 .PP
  80 The first step is to fill in the global configuration parameters.
  81 The machine is a VAX, so the
  82 .I "machine type"
  83 is ``vax''.  We will assume this system will
  84 run only on this one processor, so the
  85 .I "cpu type"
  86 is ``VAX780''.  The options are empty since this is going to
  87 be a ``vanilla'' VAX.  The system identifier, as mentioned before,
  88 is ``ANSEL,'' and the maximum number of users we plan to support is
  89 about 40.  Thus the beginning of the configuration file looks like
  90 this:
  91 .DS
  92 .ta 1.5i 2.5i 4.0i
  93 #
  94 # ANSEL VAX (a picture perfect machine)
  95 #
  96 machine vax
  97 cpu     VAX780
  98 timezone        8 dst
  99 ident   ANSEL
 100 maxusers        40
 101 .DE
 102 .PP
 103 To this we must then add the specifications for three
 104 system images.  The first will be our standard system with the
 105 root on ``hp0'' and swapping on the same drive as the root.
 106 The second will have the root file system in the same location,
 107 but swap space interleaved among drives on each controller.
 108 Finally, the third will be a generic system,
 109 to allow us to boot off any of the four disk drives.
 110 .DS
 111 .ta 1.5i 2.5i
 112 config  kernel  root on hp0
 113 config  hpkernel        root on hp0 swap on hp0 and hp2
 114 config  genkernel       swap generic
 115 .DE
 116 .PP
 117 Finally, the hardware must be specified.  Let us first just try
 118 transcribing the information from Table 1.
 119 .DS
 120 .ta 1.5i 2.5i 4.0i
 121 controller      mba0    at nexus ?
 122 disk    hp0     at mba0 disk 0
 123 disk    hp1     at mba0 disk 1
 124 controller      mba1    at nexus ?
 125 disk    hp2     at mba1 disk 2
 126 disk    hp3     at mba1 disk 3
 127 controller      uba0    at nexus ?
 128 controller      tm0     at uba0 csr 0172520     vector tmintr
 129 tape    te0     at tm0 drive 0
 130 tape    te1     at tm0 drive 1
 131 device  dh0     at uba0 csr 0160020     vector dhrint dhxint
 132 device  dm0     at uba0 csr 0170500     vector dmintr
 133 device  dh1     at uba0 csr 0160040     vector dhrint dhxint
 134 device  dh2     at uba0 csr 0160060     vector dhrint dhxint
 135 .DE
 136 .LP
 137 (Oh, I forgot to mention one panel of the terminal multiplexor
 138 has modem control, thus the ``dm0'' device.)
 139 .PP
 140 This will suffice, but leaves us with little flexibility.  Suppose
 141 our first disk controller were to break.  We would like to recable the
 142 drives normally on the second controller so that all our disks could
 143 still be used without reconfiguring the system.  To do this we wildcard
 144 the MASSBUS adapter connections and also the slave numbers.  Further,
 145 we wildcard the UNIBUS adapter connections in case we decide some time
 146 in the future to purchase another adapter to offload the single UNIBUS
 147 we currently have.  The revised device specifications would then be:
 148 .DS
 149 .ta 1.5i 2.5i 4.0i
 150 controller      mba0    at nexus ?
 151 disk    hp0     at mba? disk ?
 152 disk    hp1     at mba? disk ?
 153 controller      mba1    at nexus ?
 154 disk    hp2     at mba? disk ?
 155 disk    hp3     at mba? disk ?
 156 controller      uba0    at nexus ?
 157 controller      tm0     at uba? csr 0172520     vector tmintr
 158 tape    te0     at tm0 drive 0
 159 tape    te1     at tm0 drive 1
 160 device  dh0     at uba? csr 0160020     vector dhrint dhxint
 161 device  dm0     at uba? csr 0170500     vector dmintr
 162 device  dh1     at uba? csr 0160040     vector dhrint dhxint
 163 device  dh2     at uba? csr 0160060     vector dhrint dhxint
 164 .DE
 165 .LP
 166 The completed configuration file for ANSEL is shown in Appendix C.
 167 .NH 2
 168 VAX-11/750 with network support
 169 .PP
 170 Our VAX-11/750 system will be located on two 10Mb/s Ethernet
 171 local area networks and also the DARPA Internet.  The system
 172 will have a MASSBUS drive for the root file system and two
 173 UNIBUS drives.  Paging is interleaved among all three drives.
 174 We have sold our standard DEC terminal multiplexors since this
 175 machine will be accessed solely through the network.  This
 176 machine is not intended to have a large user community, it
 177 does not have a great deal of memory.  First the global parameters:
 178 .DS
 179 .ta 1.5i 2.5i 4.0i
 180 #
 181 # UCBVAX (Gateway to the world)
 182 #
 183 machine vax
 184 cpu     "VAX780"
 185 cpu     "VAX750"
 186 ident   UCBVAX
 187 timezone        8 dst
 188 maxusers        32
 189 options INET
 190 options NS
 191 .DE
 192 .PP
 193 The multiple cpu types allow us to replace UCBVAX with a
 194 more powerful cpu without reconfiguring the system.  The
 195 value of 32 given for the maximum number of users is done to
 196 force the system data structures to be over-allocated.  That
 197 is desirable on this machine because, while it is not expected
 198 to support many users, it is expected to perform a great deal
 199 of work.
 200 The ``INET'' indicates that we plan to use the
 201 DARPA standard Internet protocols on this machine,
 202 and ``NS'' also includes support for Xerox NS protocols.
 203 Note that unlike 4.2BSD configuration files,
 204 the network protocol options do not require corresponding pseudo devices.
 205 .PP
 206 The system images and disks are configured next.
 207 .DS
 208 .ta 1.5i 2.5i 4.0i
 209 config  kernel  root on hp swap on hp and rk0 and rk1
 210 config  upkernel        root on up
 211 config  hkkernel        root on hk swap on rk0 and rk1
 212
 213 controller      mba0    at nexus ?
 214 controller      uba0    at nexus ?
 215 disk    hp0     at mba? drive 0
 216 disk    hp1     at mba? drive 1
 217 controller      sc0     at uba? csr 0176700     vector upintr
 218 disk    up0     at sc0 drive 0
 219 disk    up1     at sc0 drive 1
 220 controller      hk0     at uba? csr 0177440     vector rkintr
 221 disk    rk0     at hk0 drive 0
 222 disk    rk1     at hk0 drive 1
 223 .DE
 224 .PP
 225 UCBVAX requires heavy interleaving of its paging area to keep up
 226 with all the mail traffic it handles.  The limiting factor on this
 227 system's performance is usually the number of disk arms, as opposed
 228 to memory or cpu cycles.  The extra UNIBUS controller, ``sc0'',
 229 is in case the MASSBUS controller breaks and a spare controller
 230 must be installed (most of our old UNIBUS controllers have been
 231 replaced with the newer MASSBUS controllers, so we have a number
 232 of these around as spares).
 233 .PP
 234 Finally, we add in the network devices.
 235 Pseudo terminals are needed to allow users to
 236 log in across the network (remember the only hardwired terminal
 237 is the console).
 238 The software loopback device is used for on-machine communications.
 239 The connection to the Internet is through
 240 an IMP, this requires yet another
 241 .I pseudo-device
 242 (in addition to the actual hardware device used by the
 243 IMP software).  And, finally, there are the two Ethernet devices.
 244 These use a special protocol, the Address Resolution Protocol (ARP),
 245 to map between Internet and Ethernet addresses.  Thus, yet another
 246 .I pseudo-device
 247 is needed.  The additional device specifications are show below.
 248 .DS
 249 .ta 1.5i 2.5i 4.0i
 250 pseudo-device   pty
 251 pseudo-device   loop
 252 pseudo-device   imp
 253 device  acc0    at uba? csr 0167600     vector accrint accxint
 254 pseudo-device   ether
 255 device  ec0     at uba? csr 0164330     vector ecrint eccollide ecxint
 256 device  il0     at uba? csr 0164000     vector ilrint ilcint
 257 .DE
 258 .LP
 259 The completed configuration file for UCBVAX is shown in Appendix C.
 260 .NH 2
 261 Miscellaneous comments
 262 .PP
 263 It should be noted in these examples that neither system was
 264 configured to use disk quotas or the 4.1BSD compatibility mode.
 265 To use these optional facilities, and others, we would probably
 266 clean out our current configuration, reconfigure the system, then
 267 recompile and relink the system image(s).  This could, of course,
 268 be avoided by figuring out which relocatable object files are
 269 affected by the reconfiguration, then reconfiguring and recompiling
 270 only those files affected by the configuration change.  This technique
 271 should be used carefully.