![[Previous Section]](b_prev.gif){kind=small}
![[Back to Table of Contents]](b_toc.gif){kind=small}
![[Next Section]](b_next.gif){kind=small}
IRIX Advanced Site and Server Administration Guide |
This chapter contains common sense approaches to planning the physical and logical aspects of your network environment. The information contained in this chapter should be read prior to setting up a new network or integrating into an existing network (homogeneous or heterogeneous). The following topics are covered:
Planning the physical layout of your network. See "Planning
the Physical Network".
Helpful information for connecting to the Internet is provided in "The
Internet".
A complete description of Internet addresses and how to obtain one.
See "Internet Addresses".
A listing of common network applications and their uses. See "Format
of Internet Protocol (IP) addresses".
Instructions for creating subnetworks within your site. See "Planning
to Subnet Local Networks".
Information on maintaining network security. See "Planning for Network Security".
Planning the physical network requires that you first answer the question, "What network media and topology configuration would best suit the needs of my users?" A review of the MAC (Medium Access Control) level and application-level performance information about the products you are considering will help you determine the appropriate choice of media for your environment. In your review, consider the size (number of stations) of your network. Your network size will influence the media type and topology you choose for your network. If your network requires different types of media, determine whether you have the correct equipment for integrating the various media types.
The subsections that follow will help you answer this list of planning questions:
What will my physical network look like?
Do I have a map of my network?
Will I need a repeater, bridge, router, and/or gateway?
Will this network configuration meet my user's needs?
Where are my performance bottlenecks? Can I reduce or avoid them?
Your choice of media and the number of stations, networks, and protocols in your network may require the use of a repeater, bridge, router, or gateway. This section suggests the type of device required for certain network functions.
Note: The terms router and gateway are sometimes used interchangeably. Be sure you know the function of the device you are considering, as the term may be technically inaccurate.
Note that each device may not be limited to a single function. For example, a gateway may also perform router functions if it is configured as a router. Table 16-1 summarizes the characteristics of each network device.
| Device Name | Media | Protocol | LAN | Purpose |
|---|---|---|---|---|
| repeater | same | same | same | extends physical length of the network |
| bridge | different/same | different/same | same/different | bridge network media differences |
| router | same/different | same | different | provides physical and logical route between networks |
| gateway | same/different | different | same/different | communication between stations with different networking protocols |
You can circumvent some performance bottlenecks with appropriate planning. These bottlenecks might occur as a result of your choice of media, topology, number of network devices, controller boards, or your network design.
Chances are, you will want to connect your system or network to the Internet. Wherever you may be, there is likely an Internet gateway available within your local calling range. The following sections offer some information that should help you get set up and running. Obviously, each situation is somewhat different, and your local service provider will have variations in service and equipment. Some research and experimentation is usually required before everything works smoothly.
Before you sign up for an internet connection, consider what level of service you need. For example, if you are an individual looking for basic E-mail, news and file transfer capabilities, it probably wouldn't make sense to install a dedicated network cable in your home for economic reasons. A better choice for single user access might be to subscribe to a network provider who establishes an account for you on their system (One who is currently connected to Internet). Typically access to their system is through a modem connection.
If you are trying to establish a connection to the Internet for a corporation, you will likely need the bandwidth of a network cable, and all the required hardware that goes with it, including an IP router, CSU/DSU (In effect a digital modem to interface the cable to the router). You will have to take into consideration the many administrative issues of running a site. These issues include, but are not limited to:
Cost Analyses/Budget
Establishing a domain
Applying for IP addresses
Establishing site policy
Establishing site security
Administration of network services (i.e.Domain Name Services, NIS, Mail, etc.)
There are providers of network connectivity that can provide varying levels of service. You must investigate the providers, and decide who provides the level of service you need, at the appropriate cost.
If you are going for an individual account on a provider's machine, the service provider deals with most, if not all the administrative tasks, and you simply enjoy access to the Internet.
If you would like a somewhat broader range of services, most providers will set you up with a dedicated modem and phone line for your exclusive use, or they can provide a network-only service (using SLIP, PPP, or UUCP) either through modems or other network connections.
If you are trying to set up internet access for a company, or corporation, you should research the issues listed above. Based on the information you obtain, formulate a plan for your site based on the needs and expectations of your organization. One of the best sources of information is the Internet itself. You should first obtain an individual account from a local provider. With the individual account, you can gain access to a large amount of information pertaining to establishing a site on the Internet.
With an individual account, or access to the Internet you can get the information you need to provide access to your own site.
Usually, the provider of an individual account will also provide new user documentation that describes the basics of using the Internet. There are FTP (File Transfer Protocol) sites available on the Internet that have a wealth of information on many subjects, including Internet connectivity.
If you have never used ftp, here is a brief summary on how to use the ftp command. Anonymous FTP is a conventional way of allowing you to sign onto a computer on the Internet in order to obtain copies of files that are made available to the public. Some sites offer anonymous FTP accounts to distribute software and various kinds of information. Many systems will allow any password and request that the password you choose is your userid. If this fails, the generic password is usually "guest".
Note: In order to obtain a file through an ftp connection the command you will use is get. The get command copies one file from the remote system to your local system. If you wish to obtain multiple files from the remote system use the mget command.
On FTP.RS.INTERNIC.NET, in the rfc directory, you will find fyi16.txt, entitled Connecting to the Internet - What Connecting Institutions Should Anticipate. This paper describes the issues and processes of establishing a site. There is no better documentation than this for establishing a site.
Another important set of problems you will face when connecting a site to the net is that of security. On moink.nmsu.edu, there is a directory called firewalls that contains two files in postscript format that give an overview of firewall configurations.
On FTP.RS.INTERNIC.NET, in the rfc directory, you will find fyi8.txt, entitled Site Security Handbook. This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet.
Other places to look are on FTP.RS.INTERNIC.NET:
An Internet address is required if your network is attached to the Internet. The Internet Network Information Center (InterNIC) is responsible for assigning the network portion of an Internet address for each site. For example, if Company A applies for an Internet address, the InterNIC provides the network portion of the Internet address for the entire Company A site. A centralized organization within Company A is responsible for assigning and managing the station ID portion of the Internet address.
Internet addresses are maintained on each station or in a centralized network database such as NIS or BIND. See "Format of Internet Protocol (IP) addresses". Each station that wishes to communicate must have a valid Internet address registered in the appropriate database. The standard hosts name-address database on IRIX stations is the /etc/hosts file.
The subsections that follow will help you answer this list of planning questions:
How do I get a valid Internet address for my site?
Do I understand the purpose of the /etc/hosts file?
Do I have valid Internet addresses ready for all required stations?
An IP address is a 32-bit number that network software uses to identify a system on a network. The format is ###.###.###.###. Every system on an IP network must have its own unique IP address for the network to function properly.
Note: Unlike a system's Ethernet address, a system's IP address is determined by the network and network system administrators.
Conceptually, each IP 32-bit IP address is a pair of numbers where one number is representing the network and the other the system itself. There are 5 classes of addresses determined by the highest bits of the network.
The Format of Internet Protocol (IP) addresses:
CLASS A (128 networks with 16,777,214 systems each):
Bit #s 0 1-----7 8---------------------31
|-|-------|------------------------|
|-|-------|------------------------|
IP Address 0 NETWORK HOST
CLASS B (16,384 networks with 65,534 systems each):
Bit #s 01 2-----------15 16------------31
|--|--------------|----------------|
|--|--------------|----------------|
IP Address 10 NETWORK HOST
CLASS C (2,097,152 networks with 254 systems each):
Bit #s 012 3------------------23 24----31
|---|---------------------|--------|
|---|---------------------|--------|
IP Address 110 NETWORK HOST
CLASS D (multicast group address within a network site):
Bit #s 0123 4--------------------------31
|----|-----------------------------|
|----|-----------------------------|
IP Address 1110 MULTICAST ADDRESS
CLASS E - Not implemented.
To simplify Internet addressing, dotted decimal notation is used to break the 32-bit number into 4 decimal numbers separated by dots.
Example: The IP address 128.74.41.123 in binary is:
10000000| 01001010| 00101001| 01111011
or
128 | 74 | 41 | 123
IP addresses of different classes in valid dot notation conform to the following specifications:
Class A -- 001.hhh.hhh.hhh through 126.hhh.hhh.hhh* Class B -- 128.001.hhh.hhh through 191.254.hhh.hhh* Class C -- 192.000.001.hhh through 223.255.254.hhh*
*where hhh is the local system and the leading numbers are the network.
Classes D and E are special cases:
Class D -- multicast within a network site. Class E -- reserved for future use.
If a system is to be on a network that is part of the Internet, then the IP address for the system must be obtained according to the information provided in "Obtaining an Internet Address".
However, coordinate with your local network administrator as he or she may already have an allotment of IP addresses available for your site.
You should obtain an Internet network address from the InterNIC before you begin setting up your network.
To request an Internet network address, supply the following information to the InterNIC:
Your administrative point of contact (POC). The administrative POC is
the person responsible for answering administrative and policy questions
about the network. You need to know his/her name, title, mailing address,
and phone number.
Your technical point of contact (POC). The technical POC is responsible
for the technical support of the network. You need to know his/her name,
title, mailing address, and phone number.
Your network name (up to 12 characters).
Your network's geographic location and organization name.
The name and location of the network document plan.
Gateway information (connectivity, hardware, software, address).
The approximate size of your network, initially and within five years.
Justification for other than a Class C network number.
You may send your request for an Internet Number by electronic mail to:
hostmaster@INTERNIC.NET
Or you can transfer the files:
templates/domain-template.txt
templates/in-addr-template.txt
using anonymous FTP from the site:
FTP.RS.INTERNIC.NET
Or you may mail your hardcopy request through the public mails or phone the InterNIC at:
Network Solutions
Attn: InterNIC Registration Services
505 Huntmar Park Drive
Herndon, VA 22070
Phone: 1-800-444-4345 or 1-703-742-4777
This section discusses the hosts database. Procedures for setting up a hosts file are described in Chapter 17, "Setting Up a Network."
The host name-address database on IRIX stations correlates an Internet address with the name of each station on the network. This information must exist on each station on a network. When a host name is referenced by an application program, the program accesses the /etc/hosts database, or equivalent database, with the gethostbyname(3N) routine to find the internet address of the station.
The /etc/hosts database is an ASCII file that you can modify with any text editor. The file contains lines of text that specify a station's address, its "official" name, and any aliases. The "official" name should be the fully qualified domain name. The address and name(s) are separated by blanks, tabs, or both. Comments begin with a pound sign (#) and continue to the end of the line.
An /etc/hosts database is shown in this sample /etc/hosts file:
# This is a comment 127.0.0.1 localhost 119.0.3.20 mint.spices.com mint # mint is an alias 119.0.3.21 ginger.spices.com ginger 119.0.3.22 sassafras.spices.com sassafras sas
Each IRIS must have a copy of /etc/hosts that contains entries for localhost and all of its network interfaces. As shipped, the /etc/hosts database contains two entries. The first entry is a name you can use to test the local network software:
127.0.0.1 localhost
When you reference localhost, the message is looped back internally; it is never transmitted across the network.
Caution: Many important programs depend on the localhost entry - do NOT remove or modify it. If the master copy of /etc/hosts is not maintained on an IRIS station or if you are using BIND or NIS, make sure that the host database contains the localhost entry.
The second entry in the hosts file is the default address and name for your IRIS. To enable the IRIS to access the network, change this entry to contain a newly assigned IP address and the name in /etc/sys_id. The entry must contain the sys_id name, either as the official host name or as an alias.
Using the example /etc/hosts file above, the /etc/sys_id file for the host ginger should contain either "ginger" or "ginger.spices.com".
If you change the IRIS's name in /etc/sys_id, make sure to update the entry in /etc/hosts; otherwise the network software will not initialize properly. If the following message appears during station startup, then the /etc/hosts and /etc/sys_id files are inconsistent and must be fixed:
*** Can't find hostname's Internet address in /etc/hosts
If your IRIS is a gateway, each network interface must be assigned an Internet address and have an entry in /etc/hosts, as described in "Setting Up a Router".
It is important that each station have a consistent version of the host database. The proper method for maintaining the consistency depends on the size of your network and whether the network is connected to the Internet.
For a small network of stations under the same administrative control, maintaining a consistent /etc/hosts database is straightforward. Establish a master copy on one station and make additions or deletions from its file. Then use rcp(1C) or rdist(1C) to copy the file to the other stations in the network.
Maintaining consistent versions of /etc/hosts on every station in a large network is troublesome. NIS and/or the BIND name server make maintenance easier by providing a centralized version of the host database. See "Format of Internet Protocol (IP) addresses" for additional information about BIND and NIS.
This guide is written specifically to support the standard network hardware and software Internet protocols over Ethernet. However, when discussing networking in general, it is difficult, if not impossible, to ignore network applications that are not standard, but are common to most network environments. This section presents a brief overview of some of the common network applications that you should consider when planning your network.
The subsections that follow will help you answer this planning question:
What network applications do I need on my network?
Electronic mail is a group of programs (sendmail) used to send and receive messages to and from users on the same local station or between remote stations. Mail can be sent using UUCP or TCP/IP protocols. IRIX supports both System V (/bin/mail) and 4.3BSD (/usr/sbin/Mail) mail programs.
UUCP, also called the Basic Networking Utilities, is a set of utilities that lets stations using a version of the UNIX operating system (such as IRIX) communicate with each other over serial lines. The utilities provided range from those used to copy files between computers to those used for remote login and command execution.
You may consider setting up UUCP for long haul communications using modems and telephone lines. It is usually used to distribute electronic mail and network news.
SLIP provides simultaneous operation of multiple processes on a serial cable or telephone line. It allows network users the freedom to use TCP/IP based applications over a serial cable or modem connection.
You might consider setting up a SLIP network when cost and distance are large factors in your network planning.
The Point to Point Protocol is similar in nature to SLIP. PPP provides a network connection as if your system were connected to the remote host by a LAN connection. Multiple processes and TCP/IP based applications are supported.
NIS is a network-based information service and an administrative tool. It allows centralized database administration and a distributed lookup service. NIS supports multiple databases based on regular text files. For example, NIS databases can be generated from the hosts, passwd, group, and aliases files on the NIS master.
NIS is best suited for a moderate-sized network (one containing approximately 1000 stations, or a small collection of interconnected networks). NIS is part of the NFS optional software and is detailed in the NFS and NIS Administration Guide.
BIND is the Internet's Domain Name System (DNS). BIND is used by various network applications and programs to map station names to internet addresses and vice-versa. If your network interfaces with the Internet, it should run DNS.
BIND is best suited for large networks, or networks connected directly or indirectly to the Internet. BIND provides access to a much larger set of stations than is provided in the /etc/hosts database. A drawback of BIND is its complicated setup. BIND is described in more detail in Chapter 19, "The BIND Name Server"
NFS is a network program that can access a remote station's file system and attach it and its data to the local station's file system. On the local station, the remote file system is accessed as if it were a local file system.
NFS should be considered in a network when you want to share files between stations. With NFS, software or data used by a group is put on an NFS server. Authorized NFS clients access the data over the network when needed. This approach ensures consistent information, frees up disk space on client stations, and simplifies the backup procedure. NFS is an optional software product and is described in the NFS and NIS Administration Guide.
Subnetting allows multiple local networks to appear as a single internetwork to off-site stations. Subnetworks are useful because they allow a site to hide its local topology. The standard describing subnetting of Internet addresses is RFC 950.
Subnetting should be considered when the class limits are unrealistic for your network. For example, a Class B network gives you approximately 64,000 stations per network. This far exceeds the maximum number of stations allowed on most networks. Subnetting allows the local organization to designate some of the host id bits to form a subnet. Subnetting generates a realistic number of stations per network. All changes are made at the local site by the site administration group and are transparent to off-site stations.
Planning is required for subnetting a network (see "Configuring an IRIS for a Network" for subnetting procedure). Primarily, you must determine how to partition the host part of the 32-bit Internet address. To define local subnetworks, use bits from the host number sequence to extend the network portion of the Internet address. This reinterpretation of internet addresses is done only for local networks. It is not visible to off-site stations.
Sites with a Class A network number have 24 bits of host part with which to work; sites with a Class B network number, 16 bits; and sites with a Class C network number, 8 bits. For example, if your site has a Class B network number, each station on the network has an Internet address that contains 16 bits for the network number and 16 bits for the host number. To define 254 local subnetworks, each possessing at most 254 stations, you can use 8 bits from the host portion of the address. Construct new network numbers by concatenating the original 16-bit network number with the extra 8 bits containing the local subnetwork number.
Figure 16-1 shows what happens to the bit assignments in a Class B Internet address that is subnetted.
Figure 16-1 : Subnetted Class B Address
For example, the Class B Internet address for an entire site as seen from other sites might be 128.50. If subnetting is enabled within the site, the site might be composed of several subnets with network IDs like 128.50.20, 128.50.21, 128.50.22, and so on. A station that resides on the subnet 128.50.21 might have the Internet address 128.50.21.5.
Note: The numbers 0 and 1 are reserved for broadcast addresses. Do not use subnetwork numbers with all 0s or all 1s.
Securing a network is a difficult if not impossible task. If you can discourage potential intruders and quickly isolate or pinpoint successful intruders, you can consider your network secure. Some security approaches are basic UNIX procedures focusing on local and remote stations; for example, the /etc/hosts.equiv and .rhosts files. There are additional security approaches that deal specifically with the physical network (network layout, firewalls) and those that are application based. For additional information on network security and system security in general, see Chapter 12, "System Security."
The subsections that follow will help you answer this list of planning questions:
Do I understand the purpose of the /etc/hosts.equiv and .rhosts
files?
Do I have any security holes in my physical network?
Should I consider a network security application?
Are my ftp accounts secure?
Should I use remote access logging?
The authentication scheme used by remote login and shell servers such as rcp, rdist, and rsh is based on the concept of trusted stations. Trusted stations are placed in the file /etc/hosts.equiv. Users on these stations are allowed to remotely log in or to perform various shell server commands with minimum verification. Minimum verification means that the remote user is equivalent to a local user (password not required and shell servers executed as if locally initiated).
For the /etc/hosts.equiv file to function properly, the following criteria must be met:
It must be owned by root.
Permissions must be set to 644, writable by root only.
The name used in the /etc/hosts.equiv file must be the remote
station's fully-qualified name.
If the remote station is a router, all fully-qualified names for all interfaces must be included in the /etc/hosts.equiv file.
Note: The fully-qualified name is the name returned by gethostbyname(3). The ping(1M) command provides a station's fully-qualified name as part of its output.
The /etc/hosts.equiv file format consists of the trusted station's name and user's name (optional). Table 16-2 provides some of the common /etc/hosts.equiv entries. Explanations of the entries are also provided. The remote station is friend.trust.com and safe.trust.com is the local station.
| hosts.equiv Entry | Meaning |
|---|---|
| friend.trust.com | Allows any user on friend.trust.com to perform as that user on safe.trust.com. |
| friend.trust.com bob | Allows the user bob on the station friend.trust.com to perform as any user (except root) on safe.trust.com. |
| + | Allows any user (except root) from any station to perform as that user on safe.trust.com. |
| -friend.trust.com | Denies access to any user from friend.trust.com. |
| friend.trust.com + | Allows any user (except root) on friend.trust.com to perform as a very trusted user (except root) on safe.trust.com. |
| friend.trust.com - bob | Denies access to the user bob from the station friend.trust.com
|
Note: If you are using NIS, netgroup names in the /etc/hosts.equiv file are supported. See the NFS and NIS Administration Guide as well as the hosts.equiv(4) reference page for more details.
The .rhosts file is an extension of the trusted users provided with the /etc/hosts.equiv file. The .rhosts files are not default files, but are created by the user as needed. Remote login and server shells rely on both the /etc/hosts.equiv and .rhosts (if available) files for reliable authentication. The .rhosts files are used to provide access to remote root or regular users without divulging or removing existing passwords. The .rhosts file can be created by regular users and root.
Entry format for the .rhosts file is the same as for the /etc/hosts.equiv file (see Table 16-2). For the .rhosts file to be recognized and to function properly, the following criteria must be met:
It must be owned by the user.
Permissions must be set to 644; writable by user only.
The name used in the .rhosts file must be the remote station's
fully-qualified name.
If the remote station is a router, all fully-qualified names for all interfaces must be included in the .rhosts file.
Note: The fully-qualified name is the name returned by gethostbyname(3). The ping(1M) command provides a stations fully-qualified name as part of its output.
If the /etc/hosts.equiv file does not give access to a particular user, a local user can set up a .rhosts file in his/her home directory. If the remote user is specified in a local users .rhosts file, the user is trusted and allowed access to the local users account. A local user's .rhosts file overrides the station's /etc/hosts.equiv file entries.
The local /etc/hosts.equiv file is never checked when authenticating remote root access. The /.rhosts file is checked to authenticate remote root access. Entries in this file allow users to have local root privileges. You should be very selective about setting up the /.rhosts file and, in particular, about the stations you trust with root access to your station. Be very careful about putting a "+" in the /.rhosts file; it gives the root user on any remote station root privileges on the local station.
A firewall is a network security measure that slows or eliminates network trespassing. Firewalls make it physically difficult to jump from one network to another. Firewalls are implemented in two ways:
Externally
Internally
External firewalls put a wall between your local site and the outside world. A solid external firewall includes a choke and a gate. The choke and the gate may be two separate stations or the same station with multiple interfaces and forwarding turned off.
The choke is the bridge between the inside network and the outside network. It blocks all packets, except those destined for the gate or sent from the gate. You can also screen packets based on protocols, for example, the choke may pass mail related packets, but not telnet packets.
The gate is the station that enforces security, authenticates users, and sanitizes data. Typically, the gate stations serves as the mail server, the Usenet server (for news), and the FTP repository. The gate station should meet the following criteria:
Minimum user accounts; no regular users.
No NIS or NFS services without portmap access controls.
No unnecessary program or development tools.
711 permissions on many system directories.
Full logging on.
Process and file quotas on.
No unnecessary network services.
No /etc/hosts.equiv file.
Internal firewalls provide a second layer of protection to network intruders. If a network intruder manipulates their way through your external firewall, the internal firewalls make it difficult for them to move around on your network. This slowdown provides you with more time to track and possibly isolate the intruder. Implementing internal firewalls is simple; separate your site into groups of networks which communicate through routers and/or gateways with high levels of security. Be careful not to create so many local networks that it creates a network bottleneck. The purpose of internal firewalls is to slow down an intruder, not your network performance.
In general, most networks are susceptible to two kinds of security leaks: eavesdropping and imposters. Eavesdroppers are users who record network packets intended for another destination. Imposters actually take the identity of another station and receive information destined for that station. In either case, this susceptibility is primarily due to the promiscuous nature of certain types of media (Ethernet, token ring, and so on.).
Many network applications transmit authentication information (user id and passwords) when requesting service, making eavesdropping and imposter scenarios profitable. Encryption based applications can help minimize security leaks. Encryption scrambles the data making it more difficult to decipher if intercepted by an eavesdropper or imposter. The intruder must know the encryption system used and the key to decipher the data. Kerberos is one such encryption system that is gaining popularity.
Kerberos is an authentication system that uses the Data Encryption Standard (DES) cryptology to pass sensitive information, such as passwords, on an open network. It is an add-on system and can be used with any network protocol. Kerberos was developed by the Massachusetts Institute of Technology (MIT) Athena project. Silicon Graphics Inc. does not supply or support Kerberos, but you can obtain Kerberos source code and papers using anonymous FTP from the computer ATHENA-DIST.MIT.EDU or from the following address:
MIT Software Center
W32-300
20 Carlton Street
Cambridge, MA 02139
(617) 253-7686
The File Transfer Protocol (FTP) allows remote users to transfer files between stations. ftp requires passwords and keeps a record of all ftp requests in the /var/adm/wtmp log and in /var/adm/SYSLOG, if configured correctly. The ftp server included in the system provides support for anonymous ftp. Because of the inherent security problems with such a facility, read this section carefully if you are considering providing such a service.
For security reasons, the ftpusers file should be created and should list the names of any nontrusted ftp users. It is checked on each ftp connection. If the user's name is located in the file, the request for service is denied. Accounts with nonstandard shells should be listed in this file. Accounts without passwords need not be listed in this file; the ftp server does not service these users.
A restricted account has limited access to files on the station. When a client uses the restricted account, the server performs a chroot(2) system call to restrict the client from moving outside that part of the file system where the account's home directory is located. Because the server uses a chroot call, certain programs and files used by the server process must be placed in the account's home directory. Furthermore, all directories and executable images must be unwritable.
A restricted account must be listed in /etc/ftpusers with a line containing the account name followed by the word restricted. For example, this command specifies that the "support" account allows restricted ftp access:
support restricted
A client must specify a password to access a restricted account. When the account logs in, the file called README in the account's home directory is printed, if it exists, before the client can execute commands. The README file is a good place for station notices and account usage policy.
An "anonymous" account is a special type of restricted account that does not require a password and does not need to be listed in the ftpusers file. See the ftpd(1M) reference page for complete information. You can enable an anonymous account by creating an entry in /etc/passwd for the user ftp:
ftp:*:997:999:FTP anonymous account:/usr/people/ftp:/dev/null
Using an asterisk (*) for the password prevents anyone from logging into the account by any other means. See "Setting Up Anonymous ftp" for instructions on setting up anonymous ftp.
|
|
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information