| blob | 81f2a52b773581a690530314902c718844c776d3 |
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
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.