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