![[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 / 01.setup / common|
Return to 5.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 01.setup / common |
1.1 root 1: .\" Copyright (c) 1980, 1986, 1988 Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted
5: .\" provided that the above copyright notice and this paragraph are
6: .\" duplicated in all such forms and that any documentation,
7: .\" advertising materials, and other materials related to such
8: .\" distribution and use acknowledge that the software was developed
9: .\" by the University of California, Berkeley. The name of the
10: .\" University may not be used to endorse or promote products derived
11: .\" from this software without specific prior written permission.
12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
15: .\"
16: .\" @(#)5.t 6.4 (Berkeley) 6/22/90
17: .\"
18: .ds lq ``
19: .ds rq ''
20: .ds LH "Installing/Operating \*(4B
21: .ds RH Network setup
22: .ds CF \*(DY
23: .LP
24: .nr H1 5
25: .nr H2 0
26: .bp
27: .LG
28: .B
29: .ce
30: 5. NETWORK SETUP
31: .sp 2
32: .R
33: .NL
34: .ds B3 4.3BSD
35: .PP
36: \*(B3 provides support for the DARPA standard Internet
37: protocols IP, ICMP, TCP, and UDP. These protocols may be used
38: on top of a variety of hardware devices ranging from the
39: IMP's (PSN's) used in the ARPANET to local area network controllers
40: for the Ethernet. Network services are split between the
41: kernel (communication protocols) and user programs (user
42: services such as TELNET and FTP). This section describes
43: how to configure your system to use the Internet networking support.
44: \*(B3 also supports the Xerox Network Systems (NS) protocols.
45: IDP and SPP are implemented in the kernel,
46: and other protocols such as Courier run at the user level.
47: \*(B3 provides some support for the ISO OSI protocols CLNP
48: TP4, and ESIS. User level process
49: complete the application protocols such as X.400 and X.500.
50: .NH 2
51: System configuration
52: .PP
53: To configure the kernel to include the Internet communication
54: protocols, define the INET option.
55: Xerox NS support is enabled with the NS option.
56: ISO OSI support is enabled with the ISO option.
57: In either case, include the pseudo-devices
58: ``pty'', and ``loop'' in your machine's configuration
59: file.
60: The ``pty'' pseudo-device forces the pseudo terminal device driver
61: to be configured into the system, see \fIpty\fP\|(4), while
62: the ``loop'' pseudo-device forces inclusion of the software loopback
63: interface driver.
64: The loop driver is used in network testing
65: and also by the error logging system.
66: .PP
67: If you are planning to use the Internet network facilities on a 10Mb/s
68: Ethernet, the pseudo-device ``ether'' should also be included
69: in the configuration; this forces inclusion of the Address Resolution
70: Protocol module used in mapping between 48-bit Ethernet
71: and 32-bit Internet addresses.
72: Also, if you have an IMP connection,
73: you will need to include the pseudo-device ``imp.''
74: .PP
75: Before configuring the appropriate networking hardware, you should
76: consult the manual pages in section 4 of the Programmer's Manual.
77: The following table lists the devices for which software support
78: exists.
79: .DS
80: .TS
81: l l.
82: Device name Manufacturer and product
83: _
84: .if \n(Vx \{\
85: acc ACC LH/DH interface to IMP
86: css DEC IMP-11A interface to IMP
87: ddn ACC ACP625 DDN Standard mode X.25 interface to IMP
88: dmc DEC DMC-11 (also works with DMR-11)
89: de DEC DEUNA 10Mb/s Ethernet
90: ec 3Com 10Mb/s Ethernet
91: en Xerox 3Mb/s prototype Ethernet (not a product)
92: ex Excelan 204 10Mb/s Ethernet
93: hdh ACC IF-11/HDH IMP interface
94: hy NSC Hyperchannel, w/ DR-11B and PI-13 interfaces
95: il Interlan 1010 and 10101A 10Mb/s Ethernet interfaces
96: ix Interlan NP100 10Mb/s Ethernet interface
97: pcl DEC PCL-11
98: vv Proteon 10Mb/s and 80Mb/s proNET ring network (V2LNI)
99: .\}
100: .if \n(Th \{\
101: ace ACC 10Mb/s Ethernet
102: enp CMC 10Mb/s Ethernet
103: .\}
104: .TE
105: .DE
106: .PP
107: All network interface drivers including the loopback interface,
108: require that their host address(es) be defined at boot time.
109: This is done with
110: .IR ifconfig (8C)
111: commands included in the \fI/etc/netstart\fP file.
112: Interfaces that are able to dynamically deduce the host
113: part of an address may check that the host part of the address is correct.
114: The manual page for each network interface
115: describes the method used to establish a host's address.
116: .IR Ifconfig (8C)
117: can also be used to set options for the interface at boot time.
118: Options are set independently for each interface, and
119: apply to all packets sent using that interface.
120: These options include disabling the use of the Address Resolution Protocol;
121: this may be useful if a network is shared with hosts running software
122: that does not yet provide this function.
123: Alternatively, translations for such hosts may be set in advance
124: or ``published'' by a \*(B3 host by use of the
125: .IR arp (8C)
126: command.
127: Note that the use of trailer link-level is now negotiated between \*(B3 hosts
128: using ARP,
129: and it is thus no longer necessary to disable the use of trailers
130: with \fIifconfig\fP.
131: .PP
132: The OSI equivalent to ARP is ESIS (End System to Intermediate System Routeing
133: Protocol); running this protocol is mandatory, however one can manually add
134: translations for machines that do not participate by use of the
135: .IR route (8C)
136: command.
137: Additional information is provided in the manual page describing
138: .IR ESIS (4).
139: .PP
140: To use the pseudo terminals just configured, device
141: entries must be created in the /dev directory. To create 32
142: pseudo terminals (plenty, unless you have a heavy network load)
143: execute the following commands.
144: .DS
145: \fB#\fP \fIcd /dev\fP
146: \fB#\fP \fIMAKEDEV pty0 pty1\fP
147: .DE
148: More pseudo terminals may be made by specifying \fIpty2\fP, \fIpty3\fP,
149: etc. The kernel normally includes support for 32 pseudo terminals
150: unless the configuration file specifies a different number.
151: Each pseudo terminal really consists of two files in /dev:
152: a master and a slave. The master pseudo terminal file is named
153: /dev/ptyp?, while the slave side is /dev/ttyp?. Pseudo terminals
154: are also used by several programs not related to the network.
155: In addition to creating the pseudo terminals,
156: be sure to install them in the
157: .I /etc/ttys
158: file (with a `none' in the second column so no
159: .I getty
160: is started).
161: .NH 2
162: Local subnets
163: .PP
164: In \*(B3 the DARPA Internet support
165: includes the notion of ``subnets''. This is a mechanism
166: by which multiple local networks may appears as a single Internet
167: network to off-site hosts. Subnetworks are useful because
168: they allow a site to hide their local topology, requiring only a single
169: route in external gateways;
170: it also means that local network numbers may be locally administered.
171: The standard describing this change in Internet addressing is RFC-950.
172: .PP
173: To set up local subnets one must first decide how the available
174: address space (the Internet ``host part'' of the 32-bit address)
175: is to be partitioned.
176: Sites with a class A network
177: number have a 24-bit host address space with which to work, sites with a
178: class B network number have a 16-bit host address space, while sites with
179: a class C network number have an 8-bit host address space.*
180: .FS
181: * If you are unfamiliar with the Internet addressing structure, consult
182: ``Address Mappings'', Internet RFC-796, J. Postel; available from
183: the Internet Network Information Center at SRI.
184: .FE
185: To define local subnets you must steal some bits
186: from the local host address space for use in extending the network
187: portion of the Internet address. This reinterpretation of Internet
188: addresses is done only for local networks; i.e. it is not visible
189: to hosts off-site. For example, if your site has a class B network
190: number, hosts on this network have an Internet address that contains
191: the network number, 16 bits, and the host number, another
192: 16 bits. To define 254 local subnets, each
193: possessing at most 255 hosts, 8 bits may be taken from the local part.
194: (The use of subnets 0 and all-1's, 255 in this example, is discouraged
195: to avoid confusion about broadcast addresses.)
196: These new network
197: numbers are then constructed by concatenating the original 16-bit network
198: number with the extra 8 bits containing the local subnet number.
199: .PP
200: The existence of local subnets is communicated to the system at the time a
201: network interface is configured with the
202: .I netmask
203: option to the
204: .I ifconfig
205: program. A ``network mask'' is specified to define the
206: portion of the Internet address that is to be considered the network part
207: for that network.
208: This mask normally contains the bits corresponding to the standard
209: network part as well as the portion of the local part
210: that has been assigned to subnets.
211: If no mask is specified when the address is set,
212: it will be set according to the class of the network.
213: For example, at Berkeley (class B network 128.32) 8 bits
214: of the local part have been reserved for defining subnets;
215: consequently the /etc/netstart file contains lines of the form
216: .DS
217: /etc/ifconfig en0 netmask 0xffffff00 128.32.1.7
218: .DE
219: This specifies that for interface ``en0'', the upper 24 bits of
220: the Internet address should be used in calculating network numbers
221: (netmask 0xffffff00), and the interface's Internet address is
222: ``128.32.1.7'' (host 7 on network 128.32.1). Hosts \fIm\fP on
223: sub-network \fIn\fP of this network would then have addresses of
224: the form ``128.32.\fIn\fP.\fIm\fP''; for example, host
225: 99 on network 129 would have an address ``128.32.129.99''.
226: For hosts with multiple interfaces, the network mask should
227: be set for each interface,
228: although in practice only the mask of the first interface on each network
229: is actually used.
230: .NH 2
231: Internet broadcast addresses
232: .PP
233: The address defined as the broadcast address for Internet networks
234: according to RFC-919 is the address with a host part of all 1's.
235: The address used by 4.2BSD was the address with a host part of 0.
236: \*(B3 uses the standard broadcast address (all 1's) by default,
237: but allows the broadcast address to be set (with \fIifconfig\fP)
238: for each interface.
239: This allows networks consisting of both 4.2BSD and \*(B3 hosts
240: to coexist while the upgrade process proceeds.
241: In the presence of subnets, the broadcast address uses the subnet field
242: as for normal host addresses, with the remaining host part set to 1's
243: (or 0's, on a network that has not yet been converted).
244: \*(B3 hosts recognize and accept packets
245: sent to the logical-network broadcast address as well as those sent
246: to the subnet broadcast address, and when using an all-1's broadcast,
247: also recognize and receive packets sent to host 0 as a broadcast.
248: .NH 2
249: Routing
250: .PP
251: If your environment allows access to networks not directly
252: attached to your host you will need to set up routing information
253: to allow packets to be properly routed. Two schemes are
254: supported by the system. The first scheme
255: employs the routing table management daemon \fI/etc/routed\fP
256: to maintain the system routing tables. The routing daemon
257: uses a variant of the Xerox Routing Information Protocol
258: to maintain up to date routing tables in a cluster of local
259: area networks. By using the \fI/etc/gateways\fP
260: file created by
261: .IR htable (8),
262: the routing daemon can also be used to initialize static routes
263: to distant networks (see the next section for further discussion).
264: When the routing daemon is started up
265: (usually from \fI/etc/rc\fP) it reads \fI/etc/gateways\fP if it exists
266: and installs those routes defined there, then broadcasts on each local network
267: to which the host is attached to find other instances of the routing
268: daemon. If any responses are received, the routing daemons
269: cooperate in maintaining a globally consistent view of routing
270: in the local environment. This view can be extended to include
271: remote sites also running the routing daemon by setting up suitable
272: entries in \fI/etc/gateways\fP; consult
273: .IR routed (8C)
274: for a more thorough discussion.
275: .PP
276: The second approach is to define a default or wildcard
277: route to a smart
278: gateway and depend on the gateway to provide ICMP routing
279: redirect information to dynamically create a routing data
280: base. This is done by adding an entry of the form
281: .DS
282: /etc/route add default \fIsmart-gateway\fP 1
283: .DE
284: to \fI/etc/netstart\fP; see
285: .IR route (8C)
286: for more information. The default route
287: will be used by the system as a ``last resort''
288: in routing packets to their destination. Assuming the gateway
289: to which packets are directed is able to generate the proper
290: routing redirect messages, the system will then add routing
291: table entries based on the information supplied. This approach
292: has certain advantages over the routing daemon, but is
293: unsuitable in an environment where there are only bridges (i.e.
294: pseudo gateways that, for instance, do not generate routing
295: redirect messages). Further, if the
296: smart gateway goes down there is no alternative, save manual
297: alteration of the routing table entry, to maintaining service.
298: .PP
299: The system always listens, and processes, routing redirect
300: information, so it is possible to combine both of the above
301: facilities. For example, the routing table management process
302: might be used to maintain up to date information about routes
303: to geographically local networks, while employing the wildcard
304: routing techniques for ``distant'' networks. The
305: .IR netstat (1)
306: program may be used to display routing table contents as well
307: as various routing oriented statistics. For example,
308: .DS
309: \fB#\fP \fInetstat \-r\fP
310: .DE
311: will display the contents of the routing tables, while
312: .DS
313: \fB#\fP \fInetstat \-r \-s\fP
314: .DE
315: will show the number of routing table entries dynamically
316: created as a result of routing redirect messages, etc.
317: .NH 2
318: Use of \*(B3 machines as gateways
319: .PP
320: Several changes have been made in \*(B3 in the area of gateway support
321: (or packet forwarding, if one prefers).
322: A new configuration option, GATEWAY, is used when configuring
323: a machine to be used as a gateway.
324: This option increases the size of the routing hash tables in the kernel.
325: Unless configured with that option,
326: hosts with only a single non-loopback interface never attempt
327: to forward packets or to respond with ICMP error messages to misdirected
328: packets.
329: This change reduces the problems that may occur when different hosts
330: on a network disagree as to the network number or broadcast address.
331: Another change is that \*(B3 machines that forward packets back through
332: the same interface on which they arrived
333: will send ICMP redirects to the source host if it is on the same network.
334: This improves the interaction of \*(B3 gateways with hosts that configure
335: their routes via default gateways and redirects.
336: The generation of redirects may be disabled with the configuration option
337: IPSENDREDIRECTS=0 in environments where it may cause difficulties.
338: .PP
339: Local area routing within a group of interconnected Ethernets
340: and other such networks may be handled by
341: .IR routed (8C).
342: Gateways between the Arpanet or Milnet and one or more local networks
343: require an additional routing protocol, the Exterior Gateway Protocol (EGP),
344: to inform the core gateways of their presence
345: and to acquire routing information from the core.
346: An EGP implementation for \*(B3 is available
347: by anonymous ftp from ucbarpa.berkeley.edu. If necessary, contact the
348: Berkeley Computer Systems Research Group for assistance.
349: .NH 2
350: Network data bases
351: .PP
352: Several data files are used by the network library routines
353: and server programs. Most of these files are host independent
354: and updated only rarely.
355: .DS
356: .TS
357: l l l.
358: File Manual reference Use
359: _
360: /etc/hosts \fIhosts\fP\|(5) host names
361: /etc/networks \fInetworks\fP\|(5) network names
362: /etc/services \fIservices\fP\|(5) list of known services
363: /etc/protocols \fIprotocols\fP\|(5) protocol names
364: /etc/hosts.equiv \fIrshd\fP\|(8C) list of ``trusted'' hosts
365: /etc/netstart \fIrc\fP\|(8) command script for initializing network
366: /etc/rc \fIrc\fP\|(8) command script for starting standard servers
367: /etc/rc.local \fIrc\fP\|(8) command script for starting local servers
368: /etc/ftpusers \fIftpd\fP\|(8C) list of ``unwelcome'' ftp users
369: /etc/hosts.lpd \fIlpd\fP\|(8C) list of hosts allowed to access printers
370: /etc/inetd.conf \fIinetd\fP\|(8) list of servers started by \fIinetd\fP
371: .TE
372: .DE
373: The files distributed are set up for ARPANET or other Internet hosts.
374: Local networks and hosts should be added to describe the local
375: configuration; the Berkeley entries may serve as examples
376: (see also the section on on /etc/hosts).
377: Network numbers will have to be chosen for each Ethernet.
378: For sites connected to the Internet,
379: the normal channels should be used for allocation of network
380: numbers (contact [email protected]).
381: For other sites,
382: these could be chosen more or less arbitrarily,
383: but it is generally better to request official numbers
384: to avoid conversion if a connection to the Internet (or others on the Internet)
385: is ever established.
386: .NH 3
387: Network servers
388: .PP
389: Most network servers are automatically started up at boot time
390: by the command file /etc/rc
391: or by the Internet daemon (see below).
392: These include the following:
393: .DS
394: .TS
395: l l l.
396: Program Server Started by
397: _
398: /etc/syslogd error logging server /etc/rc
399: /etc/named Internet name server /etc/rc
400: /etc/routed routing table management daemon /etc/rc
401: /etc/rwhod system status daemon /etc/rc
402: /etc/timed time synchronization daemon /etc/rc.local
403: /usr/lib/sendmail SMTP server /etc/rc.local
404: /etc/rshd shell server inetd
405: /etc/rexecd exec server inetd
406: /etc/rlogind login server inetd
407: /etc/telnetd TELNET server inetd
408: /etc/ftpd FTP server inetd
409: /etc/fingerd Finger server inetd
410: /etc/tftpd TFTP server inetd
411: .TE
412: .DE
413: Consult the manual pages and accompanying documentation (particularly
414: for named and sendmail) for details about their operation.
415: .PP
416: The use of \fIrouted\fP and \fIrwhod\fP is controlled by shell
417: variables set in /etc/netstart.
418: By default, \fIrouted\fP is used, but \fIrwhod\fP is not;
419: they are enabled by setting the variables \fIroutedflags\fP
420: and \fIrwhod\fP to strings other than ``NO.''
421: The value of \fIroutedflags\fP is used to provide host-specific options
422: to \fIrouted\fP.
423: For example,
424: .DS
425: routedflags=-q
426: rwhod=NO
427: .DE
428: would run \fIrouted -q\fP and would not run \fIrwhod\fP.
429: .PP
430: To have other network servers started as well,
431: commands of the following sort should be placed in the site-dependent
432: file \fI/etc/rc.local\fP.
433: .DS
434: if [ -f /etc/timed ]; then
435: /etc/timed & echo -n ' timed' >/dev/console
436: f\&i
437: .DE
438: .NH 3
439: Internet daemon
440: .PP
441: In \*(B3 most of the servers for user-visible services are started up by a
442: ``super server'', the Internet daemon. The Internet
443: daemon, \fI/etc/inetd\fP, acts as a master server for
444: programs specified in its configuration file, \fI/etc/inetd.conf\fP,
445: listening for service requests for these servers, and starting
446: up the appropriate program whenever a request is received.
447: The configuration file contains lines containing a service
448: name (as found in \fI/etc/services\fP), the type of socket the
449: server expects (e.g. stream or dgram), the protocol to be
450: used with the socket (as found in \fI/etc/protocols\fP), whether
451: to wait for each server to complete before starting up another,
452: the user name as which the server should run, the server
453: program's name, and at most five arguments to pass to the
454: server program.
455: Some trivial services are implemented internally in \fIinetd\fP,
456: and their servers are listed as ``internal.''
457: For example, an entry for the file
458: transfer protocol server would appear as
459: .DS
460: ftp stream tcp nowait root /etc/ftpd ftpd
461: .DE
462: Consult
463: .IR inetd (8C)
464: for more detail on the format of the configuration file
465: and the operation of the Internet daemon.
466: .NH 3
467: Regenerating /etc/hosts and /etc/networks
468: .PP
469: When using the host address routines that use the Internet name server,
470: the file \fI/etc/hosts\fP is only used for setting interface addresses
471: and at other times that the server is not running,
472: and therefore it need only contain addresses for local hosts.
473: There is no equivalent service for network names yet.
474: The full host and network name data bases are normally derived from
475: a file retrieved from the Internet Network Information Center at
476: SRI.
477: To do this you should use the program /etc/gettable
478: to retrieve the NIC host data base, and the program
479: .IR htable (8)
480: to convert it to the format used by the libraries.
481: You should change to the directory where you maintain your local
482: additions to the host table and execute the following commands.
483: .DS
484: \fB#\fP \fI/etc/gettable sri-nic.arpa\fP
485: \fBConnection to sri-nic.arpa opened.\fP
486: \fBHost table received.\fP
487: \fBConnection to sri-nic.arpa closed.\fP
488: \fB#\fP \fI/etc/htable hosts.txt\fP
489: \fBWarning, no localgateways file.\fP
490: \fB#\fP
491: .DE
492: The \fIhtable\fP program generates three files
493: in the local directory: \fIhosts\fP, \fInetworks\fP and \fIgateways\fP.
494: If a file ``localhosts'' is present in the working directory its
495: contents are first copied to the output file. Similarly, a
496: ``localnetworks'' file may be prepended to the output created
497: by \fIhtable\fP,
498: and `localgateways'' will be prepended to \fIgateways\fP.
499: It is usually wise to run \fIdiff\fP\|(1) on
500: the new host and network data bases before installing them in /etc.
501: If you are using the host table for host name and address
502: mapping, you should run \fImkhosts\fP\|(8) after installing
503: \fI/etc/hosts\fP.
504: If you are using the name server for the host name and address mapping,
505: you only need to install \fInetworks\fP and a small copy of \fIhosts\fP
506: describing your local machines. The full host table in this case might
507: be placed somewhere else for reference by users.
508: The gateways file may be installed in \fI/etc/gateways\fP if you use
509: .IR routed (8C)
510: for local routing and wish to have static external routes installed
511: when \fIrouted\fP is started.
512: This procedure is essentially obsolete, however, except for individual hosts
513: that are on the Arpanet or Milnet and do not forward packets from a local
514: network.
515: Other situations require the use of an EGP server.
516: .PP
517: If you are connected to the DARPA Internet, it is highly recommended that
518: you use the name server for your host name and address mapping, as this
519: provides access to a much larger set of hosts than are provided in the
520: host table. Many large organizations on the network currently have
521: only a small percentage of their hosts listed in the host table retrieved
522: from NIC.
523: .NH 3
524: /etc/hosts.equiv
525: .PP
526: The remote login and shell servers use an
527: authentication scheme based on trusted hosts. The \fIhosts.equiv\fP
528: file contains a list of hosts that are considered trusted
529: and, under a single administrative control. When a user
530: contacts a remote login or shell server requesting service,
531: the client process passes the user's name and the official
532: name of the host on which the client is located. In the simple
533: case, if the host's name is located in \fIhosts.equiv\fP and
534: the user has an account on the server's machine, then service
535: is rendered (i.e. the user is allowed to log in, or the command
536: is executed). Users may expand this ``equivalence'' of
537: machines by installing a \fI.rhosts\fP file in their login directory.
538: The root login is handled specially, bypassing the \fIhosts.equiv\fP
539: file, and using only the \fI/.rhosts\fP file.
540: .PP
541: Thus, to create a class of equivalent machines, the \fIhosts.equiv\fP
542: file should contain the \fIofficial\fP names for those machines.
543: If you are running the name server, you may omit the domain part
544: of the host name for machines in your local domain.
545: For example, four machines on our local
546: network are considered trusted, so the \fIhosts.equiv\fP file is
547: of the form:
548: .DS
549: ucbarpa
550: okeeffe
551: monet
552: ucbvax
553: .DE
554: .NH 3
555: /etc/ftpusers
556: .PP
557: The FTP server included in the system provides support for an
558: anonymous FTP account. Because of the inherent security problems
559: with such a facility you should read this section carefully if
560: you consider providing such a service.
561: .PP
562: An anonymous account is enabled by creating a user \fIftp\fP.
563: When a client uses the anonymous account a \fIchroot\fP\|(2)
564: system call is performed by the server to restrict the client
565: from moving outside that part of the file system where the
566: user ftp home directory is located. Because a \fIchroot\fP call
567: is used, certain programs and files used by the server
568: process must be placed in the ftp home directory.
569: Further, one must be
570: sure that all directories and executable images are unwritable.
571: The following directory setup is recommended. The
572: use of the \fIawk\fP commands to copy the /etc/passwd and /etc/group
573: files are \fBSTRONGLY\fP recommended.
574: .DS
575: \fB#\fP \fIcd ~ftp\fP
576: \fB#\fP \fIchmod 555 .; chown ftp .; chgrp ftp .\fP
577: \fB#\fP \fImkdir bin etc pub\fP
578: \fB#\fP \fIchown root bin etc\fP
579: \fB#\fP \fIchmod 555 bin etc\fP
580: \fB#\fP \fIchown ftp pub\fP
581: \fB#\fP \fIchmod 777 pub\fP
582: \fB#\fP \fIcd bin\fP
583: \fB#\fP \fIcp /bin/sh /bin/ls .\fP
584: \fB#\fP \fIchmod 111 sh ls\fP
585: \fB#\fP \fIcd ../etc\fP
586: \fB#\fP \fIawk -F: '{$2="*";print$1":"$2":"$3":"$4":"$5":"$6":"}' < /etc/passwd > passwd\fP
587: \fB#\fP \fIawk -F: '{$2="*";print$1":"$2":"}' < /etc/group > group\fP
588: \fB#\fP \fIchmod 444 passwd group\fP
589: .DE
590: When local users wish to place files in the anonymous
591: area, they must be placed in a subdirectory. In the
592: setup here, the directory \fI~ftp/pub\fP is used.
593: .PP
594: Aside from the problems of directory modes and such,
595: the ftp server may provide a loophole for interlopers
596: if certain user accounts are allowed.
597: The file \fI/etc/ftpusers\fP is checked on each connection.
598: If the requested user name is located in the file, the
599: request for service is denied. This file normally has
600: the following names on our systems.
601: .DS
602: uucp
603: root
604: .DE
605: Accounts without passwords need not be listed in this file as the ftp
606: server will refuse service to these users.
607: Accounts with nonstandard shells (any not listed in /etc/shells)
608: will also be denied access via ftp.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.