![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 5.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 02.config|
Return to 5.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 02.config |
1.1 root 1: .\" Copyright (c) 1983 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)5.t 6.2 (Berkeley) 6/3/86
6: .\"
7: .\".ds RH "Sample Configuration Files
8: .ne 2i
9: .NH
10: SAMPLE CONFIGURATION FILES
11: .PP
12: In this section we will consider how to configure a
13: sample VAX-11/780 system on which the hardware can be
14: reconfigured to guard against various hardware mishaps.
15: We then study the rules needed to configure a VAX-11/750
16: to run in a networking environment.
17: .NH 2
18: VAX-11/780 System
19: .PP
20: Our VAX-11/780 is configured with hardware
21: recommended in the document ``Hints on Configuring a VAX for 4.2BSD''
22: (this is one of the high-end configurations).
23: Table 1 lists the pertinent hardware to be configured.
24: .DS B
25: .TS
26: box;
27: l | l | l | l | l
28: l | l | l | l | l.
29: Item Vendor Connection Name Reference
30: _
31: cpu DEC VAX780
32: MASSBUS controller Emulex nexus ? mba0 hp(4)
33: disk Fujitsu mba0 hp0
34: disk Fujitsu mba0 hp1
35: MASSBUS controller Emulex nexus ? mba1
36: disk Fujitsu mba1 hp2
37: disk Fujitsu mba1 hp3
38: UNIBUS adapter DEC nexus ?
39: tape controller Emulex uba0 tm0 tm(4)
40: tape drive Kennedy tm0 te0
41: tape drive Kennedy tm0 te1
42: terminal multiplexor Emulex uba0 dh0 dh(4)
43: terminal multiplexor Emulex uba0 dh1
44: terminal multiplexor Emulex uba0 dh2
45: .TE
46: .DE
47: .ce
48: Table 1. VAX-11/780 Hardware support.
49: .LP
50: We will call this machine ANSEL and construct a configuration
51: file one step at a time.
52: .PP
53: The first step is to fill in the global configuration parameters.
54: The machine is a VAX, so the
55: .I "machine type"
56: is ``vax''. We will assume this system will
57: run only on this one processor, so the
58: .I "cpu type"
59: is ``VAX780''. The options are empty since this is going to
60: be a ``vanilla'' VAX. The system identifier, as mentioned before,
61: is ``ANSEL,'' and the maximum number of users we plan to support is
62: about 40. Thus the beginning of the configuration file looks like
63: this:
64: .DS
65: .ta 1.5i 2.5i 4.0i
66: #
67: # ANSEL VAX (a picture perfect machine)
68: #
69: machine vax
70: cpu VAX780
71: timezone 8 dst
72: ident ANSEL
73: maxusers 40
74: .DE
75: .PP
76: To this we must then add the specifications for three
77: system images. The first will be our standard system with the
78: root on ``hp0'' and swapping on the same drive as the root.
79: The second will have the root file system in the same location,
80: but swap space interleaved among drives on each controller.
81: Finally, the third will be a generic system,
82: to allow us to boot off any of the four disk drives.
83: .DS
84: .ta 1.5i 2.5i
85: config vmunix root on hp0
86: config hpvmunix root on hp0 swap on hp0 and hp2
87: config genvmunix swap generic
88: .DE
89: .PP
90: Finally, the hardware must be specified. Let us first just try
91: transcribing the information from Table 1.
92: .DS
93: .ta 1.5i 2.5i 4.0i
94: controller mba0 at nexus ?
95: disk hp0 at mba0 disk 0
96: disk hp1 at mba0 disk 1
97: controller mba1 at nexus ?
98: disk hp2 at mba1 disk 2
99: disk hp3 at mba1 disk 3
100: controller uba0 at nexus ?
101: controller tm0 at uba0 csr 0172520 vector tmintr
102: tape te0 at tm0 drive 0
103: tape te1 at tm0 drive 1
104: device dh0 at uba0 csr 0160020 vector dhrint dhxint
105: device dm0 at uba0 csr 0170500 vector dmintr
106: device dh1 at uba0 csr 0160040 vector dhrint dhxint
107: device dh2 at uba0 csr 0160060 vector dhrint dhxint
108: .DE
109: .LP
110: (Oh, I forgot to mention one panel of the terminal multiplexor
111: has modem control, thus the ``dm0'' device.)
112: .PP
113: This will suffice, but leaves us with little flexibility. Suppose
114: our first disk controller were to break. We would like to recable the
115: drives normally on the second controller so that all our disks could
116: still be used without reconfiguring the system. To do this we wildcard
117: the MASSBUS adapter connections and also the slave numbers. Further,
118: we wildcard the UNIBUS adapter connections in case we decide some time
119: in the future to purchase another adapter to offload the single UNIBUS
120: we currently have. The revised device specifications would then be:
121: .DS
122: .ta 1.5i 2.5i 4.0i
123: controller mba0 at nexus ?
124: disk hp0 at mba? disk ?
125: disk hp1 at mba? disk ?
126: controller mba1 at nexus ?
127: disk hp2 at mba? disk ?
128: disk hp3 at mba? disk ?
129: controller uba0 at nexus ?
130: controller tm0 at uba? csr 0172520 vector tmintr
131: tape te0 at tm0 drive 0
132: tape te1 at tm0 drive 1
133: device dh0 at uba? csr 0160020 vector dhrint dhxint
134: device dm0 at uba? csr 0170500 vector dmintr
135: device dh1 at uba? csr 0160040 vector dhrint dhxint
136: device dh2 at uba? csr 0160060 vector dhrint dhxint
137: .DE
138: .LP
139: The completed configuration file for ANSEL is shown in Appendix C.
140: .NH 2
141: VAX-11/750 with network support
142: .PP
143: Our VAX-11/750 system will be located on two 10Mb/s Ethernet
144: local area networks and also the DARPA Internet. The system
145: will have a MASSBUS drive for the root file system and two
146: UNIBUS drives. Paging is interleaved among all three drives.
147: We have sold our standard DEC terminal multiplexors since this
148: machine will be accessed solely through the network. This
149: machine is not intended to have a large user community, it
150: does not have a great deal of memory. First the global parameters:
151: .DS
152: .ta 1.5i 2.5i 4.0i
153: #
154: # UCBVAX (Gateway to the world)
155: #
156: machine vax
157: cpu "VAX780"
158: cpu "VAX750"
159: ident UCBVAX
160: timezone 8 dst
161: maxusers 32
162: options INET
163: options NS
164: .DE
165: .PP
166: The multiple cpu types allow us to replace UCBVAX with a
167: more powerful cpu without reconfiguring the system. The
168: value of 32 given for the maximum number of users is done to
169: force the system data structures to be over-allocated. That
170: is desirable on this machine because, while it is not expected
171: to support many users, it is expected to perform a great deal
172: of work.
173: The ``INET'' indicates that we plan to use the
174: DARPA standard Internet protocols on this machine,
175: and ``NS'' also includes support for Xerox NS protocols.
176: Note that unlike 4.2BSD configuration files,
177: the network protocol options do not require corresponding pseudo devices.
178: .PP
179: The system images and disks are configured next.
180: .DS
181: .ta 1.5i 2.5i 4.0i
182: config vmunix root on hp swap on hp and rk0 and rk1
183: config upvmunix root on up
184: config hkvmunix root on hk swap on rk0 and rk1
185:
186: controller mba0 at nexus ?
187: controller uba0 at nexus ?
188: disk hp0 at mba? drive 0
189: disk hp1 at mba? drive 1
190: controller sc0 at uba? csr 0176700 vector upintr
191: disk up0 at sc0 drive 0
192: disk up1 at sc0 drive 1
193: controller hk0 at uba? csr 0177440 vector rkintr
194: disk rk0 at hk0 drive 0
195: disk rk1 at hk0 drive 1
196: .DE
197: .PP
198: UCBVAX requires heavy interleaving of its paging area to keep up
199: with all the mail traffic it handles. The limiting factor on this
200: system's performance is usually the number of disk arms, as opposed
201: to memory or cpu cycles. The extra UNIBUS controller, ``sc0'',
202: is in case the MASSBUS controller breaks and a spare controller
203: must be installed (most of our old UNIBUS controllers have been
204: replaced with the newer MASSBUS controllers, so we have a number
205: of these around as spares).
206: .PP
207: Finally, we add in the network devices.
208: Pseudo terminals are needed to allow users to
209: log in across the network (remember the only hardwired terminal
210: is the console).
211: The software loopback device is used for on-machine communications.
212: The connection to the Internet is through
213: an IMP, this requires yet another
214: .I pseudo-device
215: (in addition to the actual hardware device used by the
216: IMP software). And, finally, there are the two Ethernet devices.
217: These use a special protocol, the Address Resolution Protocol (ARP),
218: to map between Internet and Ethernet addresses. Thus, yet another
219: .I pseudo-device
220: is needed. The additional device specifications are show below.
221: .DS
222: .ta 1.5i 2.5i 4.0i
223: pseudo-device pty
224: pseudo-device loop
225: pseudo-device imp
226: device acc0 at uba? csr 0167600 vector accrint accxint
227: pseudo-device ether
228: device ec0 at uba? csr 0164330 vector ecrint eccollide ecxint
229: device il0 at uba? csr 0164000 vector ilrint ilcint
230: .DE
231: .LP
232: The completed configuration file for UCBVAX is shown in Appendix C.
233: .NH 2
234: Miscellaneous comments
235: .PP
236: It should be noted in these examples that neither system was
237: configured to use disk quotas or the 4.1BSD compatibility mode.
238: To use these optional facilities, and others, we would probably
239: clean out our current configuration, reconfigure the system, then
240: recompile and relink the system image(s). This could, of course,
241: be avoided by figuring out which relocatable object files are
242: affected by the reconfiguration, then reconfiguring and recompiling
243: only those files affected by the configuration change. This technique
244: should be used carefully.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.