Ethernet was developed in the 1970s as a broadcast-style network. In the commonly used coax network, Ethernet cable was run in one long cable and each end was terminated with a 50-ohm resistor. Each machine that was on the Ethernet network hooked into this cable using a tap.

For machines to identify themselves, each Ethernet adapter has a unique address (Media Access Connector, or MAC address) assigned to it by the Ethernet adapter manufacturer. When an Ethernet adapter wants to talk to another Ethernet adapter, it sends a message containing its own MAC address, as well as the receiving MAC address, down the entire Ethernet cable. If the receiving MAC address is on that run, it gets the message. Collisions occur when two Ethernet adapters try to transmit at the same time. If this happens, both adapters stop transmission, wait a random amount of time, and retransmit. Having too many collisions indicates a network that has very heavy traffic and is running inefficiently. A link that has a high number of collisions should be broken up into two or more separate Ethernet runs.

Each Ethernet packet has to and from Ethernet addresses along with IP to and from addresses, followed by the data, and finally some error checking data to verify that a packet arrives complete. A typical Ethernet packet can be no larger than 1514 bytes. IPv4 takes up 40 bytes, and the Ethernet framing takes up another 18 bytes, leaving a maximum of 1456 bytes of data.

Even though all the other Ethernet adapters on a cable see a message, they do not answer or respond. The only message that all Ethernet adapters should receive is an Ethernet broadcast. Network monitors take advantage of this feature of Ethernet to give an overall view of a particular Ethernet run.

For a packet (say an IP packet) to get across a network to another Ethernet run, a router is used. The router doesn't look at the Ethernet header, but instead looks at the protocol being used. If the router knows that a particular packet needs to be forwarded to another network, it forwards the packet.

What allows Linux (and TCP /IP) to make connections between an Ethernet address and an IP address is the Address Resolution Protocol (or ARP) cache. When the Linux machine starts talking on an Ethernet network, it starts asking (via ARP) what the MAC addresses for other machines on the subnet are. Here's how it works:

Linux first sends an Ethernet broadcast asking for a mapping from an IP address to a MAC address. The receiving end with that IP address responds with an ARP reply, giving the IP address and its MAC address. Linux stores that MAC address in an ARP cache for future use. The cache times out every now and then, and this may happen several times a day. Don't worry, though—there are plenty of 10 Mbps for everyone on the network. If a packet has to go through a router to get somewhere else, Linux addresses the Ethernet packet to the router (or gateway), and the router then picks it up and forwards it to another network.

In the reverse situation, the BOOTP protocol involves a Reverse ARP (RARP) that announces its MAC address, asking which IP address to use. For diskless machines, or even Windows machines using Dynamic Host Configuration Protocol (DHCP), this is the way that these machines can get themselves configured. A machine that has RARP or DHCP running responds with the IP address and other information (the gateway and nameserver, for example).

Even though the Ethernet protocol is a standard, there are three main ways of actually implementing the physical layer. Thicknet is a 15-pin connection with very heavy gauge wire that is no longer in use. The best thing you can do with a thicknet connection is attach a transceiver on it to convert it to another physical layer.^[4] Thinnet, or coax, runs one long wire, which has all the Ethernet adapters adding taps or T-connectors along the wire to connect. Coax is very inexpensive to implement, but a wiring problem anywhere along the cable can cause failure of the entire network. Coax also requires termination on both ends to keep the Ethernet signals from reflecting and causing network problems. With the large number of wires and connectors that can be on an Ethernet run, your chances of failure for a large-scale installation increase. The last, and preferable, setup is RJ-45, also known as 10-BaseT. 10-BaseT costs more, since you have to buy a hub, and is harder to implement, since a cable has to go from the hub to each individual machine, but only the failure of a hub would cause more than one person to have network trouble at the same time. If a wire from the hub were to become disconnected, no other users would be affected.^[5] The RJ-45 connection also has the capability of running at 100 Mbps instead of the regular 10 Mbps, and most new cabling installations use Category 5 (Cat 5) cabling, which is required for 100 Mbps. Category 3 (Cat 3) is suitable for 10 Mbps.

/sbin/ifconfig eth0 netmask <addr> broadcast <addr> <IP address>

route add default gw <address>

DHCP stands for Dynamic Host Configuration Protocol. The purpose of DHCP is similar to BOOTP in that a client requests an IP address and gets one assigned to it. The similarities end there. DHCP provides much more configurability than BOOTP, including:

Aside from these features, why would you want to use DHCP on your network? The biggest advantage of DHCP is configurability. One central location stores networking information for an entire subnet. For setups where network settings are changed frequently (such as changing ISPs or changing a router IP address), all configuration is done in one location, as opposed to going to each client machine and changing the settings manually. As new machines are added to a network, they can be quickly put on the network using a dynamic IP address, then later changed to use a static IP address. This can make configuring a machine easy. For the convenience of visitors, anyone with a laptop and Ethernet card can pick up their email from the home office without tying up a phone line.

When installing DHCP on a network, the first question you should ask is: Do I want dynamic IPs or static IP addressing? That is, should hosts on the network get the same IP address every time they boot, or should you have a pool of addresses that you could use and assign as hosts request them? To us (you may do whatever you like), static IPs are the way to go in general. They allow you to use your existing DNS configuration and not have to worry about setting up a dynamic DNS server. It is advisable to leave 5 or 10 addresses available as dynamically allocated so that you can get a machine on the network temporarily.

There are two programs to give you access to DHCP services: the server software (dhcpd) and client software (dhcpcd). Note that you should have only one DHCP server on a network, and since the DHCP server also provides BOOTP services, you can turn off your existing BOOTP servers and use dhcpd instead. These packages exist on the Red Hat CD as dhcpd and dhcpcd. Also note that in some instances, dhcpd will be configured to automatically start on boot, so you should only install dhcpd on one machine per subnet.

The configuration file that dhcpd uses is /etc/dhcpd.conf. This file contains MAC addresses, IP information, and router/WINS/nameserver information. Two other files that get created when dhcpd is running are /etc/dhcpd.leases and /etc/dhcpd.pid. The .pid file contains the PID of the running dhcpd to make stopping or restarting dhcpd easier. The leases file is used if you have dynamic IP addresses being used in a network. It contains information about who is being leased IP addresses, and how long the leases last. In the event of a reboot or restart of dhcpd, the dhcpd.leases file should not be deleted as it is re-read on the startup of dhcpd to know what dynamic IP addresses have already been assigned.

Here's a sample configuration file for dhcpd, along with some running commentary:

# What's the DNS name of this server?
server-identifier wayga.auroratech.com;
#Also identify the DNS domain that clients will be under
option domain-name "auroratech.com";
#What DNS servers should clients look at? (put at least 2)
option domain-name-servers auratek.auroratech.com, row.auroratech.com;
# Define a Class C network (192.168.1.0->192.168.1.255)
subnet 192.168.1.0 netmask 255.255.255.0 {
#Set the network mask (again)
  option subnet-mask 255.255.255.0;
  option domain-name "auroratech.com";
  option domain-name-servers auratek.auroratech.com, row.auroratech.com;
#Define how long a lease for an IP address should be.
  default-lease-time 600;
#Max lease time, in case that's what the
# client requests.
  max-lease-time 7200;
#Specify the default router.
  option routers 192.168.1.142;
#The below IP range will be dynamically
# allocated to clients whose MAC address
# doesn't match any of the following hosts.
  range 192.168.1.46 192.168.1.50;
}
#A printer (called ipc)
host lpipc {
#MAC address for lpipc
   hardware Ethernet 0:60:b0:0f:c0:a9;
#It's FQDN (so that DNS knows what its IP is
# We could have used a plain IP address here, but why?
   fixed-address lpipc.auroratech.com;
}
#PC host
host camille {
  hardware Ethernet 0:0:bc:0f:12:d6;
  fixed-address camille.auroratech.com;
}
# PC host using a different default router.
host cyrus {
  hardware Ethernet 0:10:4b:a2:e2:4b;
  fixed-address cyrus.auroratech.com;
  option routers 192.168.1.95;
}

The client side is easy to set up. Using the network configuration (netcfg), set the IP configuration to be DHCP and activate the Ethernet card. The dhcpcd program will automatically start, request an IP configuration from the DHCP server, and re-create any needed files such as /etc/resolv.conf for DNS information. Linuxconf (see Chapter 3) can also be configured to start up an Ethernet interface with DHCP.

You can also choose to edit files manually if you do not have X running. Look at /etc/sysconfig/network-scripts, and edit the file for your Ethernet card (usually ipcfg-eth0). Clear out any IP settings you don't want to keep, and set PROTOCOL to read DHCP.

Windows machines can merely be set for DHCP configuration via the Network Control Panel. Other UNIX machines (such as Solaris) may come with DHCP client software already installed, or you can download and compile the ISC DHCP distribution available at http://www.isc.org/.

If you choose to use all dynamic IP addresses on your network, you can use a program like lanlord (http://linux.uhw.com/software/lanlord/) to view what IP addresses have been assigned.

The Point-to-Point Protocol (PPP) is the way to connect to the Internet or a TCP/IP network via a dial-up line. As the name implies, PPP is designed to work between two machines and two machines only. This makes it ideal for dial-up applications, or even connecting remote locations via a leased line. Many 56-Kb links use PPP to carry IP traffic over the line.

PPP depends on one machine running pppd server on one end of the phone line, and a pppd client running on the machine dialing up (yours). Unlike Ethernet, you have to configure the software differently, depending on whether you're the client or the server.

PPP doesn't quite have the overhead of Ethernet since no MAC addresses are used. Also, some compression is added to the IP frames to boost the amount of data that can be sent in a packet.

Like Ethernet, PPP can carry more than just IP traffic. It can route IPX, AppleTalk, or DECNET along with IP over a PPP link. Linux does not really take advantage of this functionality, but not many people need it. Since SMB packets can be encapsulated inside TCP/IP packets, you can use Samba or NT shares over a dial-up line from Linux.

pppd connect 'chat -v "+" ATDTphone CONNECT "" ogin: login word:
  password' 
/dev/cua1 38400 debug crtscts modem defaultroute

domain wayga.net
nameserver 192.33.4.10

Pmark:#56njvc893h:500:500:PPP user:/home/mark:/usr/local/bin/pppd

 -detach
modem
crtscts
lock
192.55.123.100:192.55.123.111
proxyarp

The /etc/services file contains information about a TCP/IP port number, and a name for the specified port which is later used in the /etc/inetd.conf file. It's not often that you'll need to add entries to this, but some programs may have you do it. Here's a portion of an /etc/services file:

chargen        19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp  21/tcp
telnet 23/tcp
smtp 25/tcp      mail
time 37/tcp      timserver
time 37/udp      timserver
rlp  39/udp        resource # resource location
name 42/udp      nameserver
whois 43/tcp nicname # usually to sri-nic
domain 53/tcp
domain 53/udp
mtp  57/tcp                     # deprecated
bootps 67/udp                # bootp server
bootpc 68/udp                # bootp client
tftp 69/udp
gopher  70/tcp               # gopher server

The first entry in the line is the service name. This is followed by the port number and the protocol (usually TCP or UDP), which are then followed by any aliases. As you can see above, the port where email comes in is called the smtp port and it is located on port 25. Its alias is mail, so you could run a command like:

[markk@wayga ~]$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 wayga.ratatosk.org ESMTP Sendmail 8.8.5/8.8.5; Mon, 1 Sep 1997
  18:54:30 -040

and the telnet command would connect you to TCP/IP port 25 (where sendmail is currently running).

The /etc/inetd.conf file takes the port information in the /etc/services file and tells inetd what ports to monitor. Here's a portion of a sample inetd.conf file:

# These are standard services.
#
ftp     stream  tcp  nowait  root
/usr/sbin/tcpd
in.ftpd-l -a
telnet    stream  tcp  nowait  root
/usr/sbin/tcpd in.telnetd
gopher    stream  tcp  nowait  root
/usr/sbin/tcpd gn

# do not uncomment smtp unless you *really* know what you are
# doing.
# smtp is handled by the sendmail daemon now, not smtpd.  It does # NOT
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
#smtp stream  tcp nowait  root /usr/bin/smtpd smtpd
#nntp stream  tcp nowait  root
/usr/sbin/tcpd in.nntpd

The entries in this file are as follows:

In the example from /etc/services, we made a connection to the mail port, but the inetd.conf example shows that smtp is not being monitored. What happened? For some high-throughput programs (httpd and sendmail are prime examples), you don't want to have a program constantly restarting since it takes a lot of time for a program to start initially. But, for a program that is already running to fork or spawn off a new process, the overhead is much less. Thus, it's better for programs like these to be constantly running and taking care of the connections themselves.

Programs like telnetd or ftpd don't need a lot of startup time, so inetd can handle starting up new copies as it needs them.

The nameserver is the program that matches an IP address (208.197.103.125) to a hostname ( wayga.net). It also provides for matching in the opposite direction as well, informing you that the machine that has the address 208.197.103.125 is called wayga.net. Since one of the jobs of a nameserver is to look up and cache DNS requests from client machines, it can be used at one end of a slow link (between two offices perhaps) and reduce the amount of DNS traffic across the link. It also has provisions for forwarding E-mail addressed from one host to another and can provide backups for particular hosts in case one Web server is busy while another is idle.

In any instance where you're connecting to a TCP/IP network, you'll want to use DNS^[7] for hostname resolution. The setup of this is easily done by putting a few lines in your /etc/resolv.conf file:

domain wayga.net
nameserver 192.33.4.10

Modify wayga.net to be your domain name and change the IP address to be the nameserver provided to you by your ISP. This IP address is an actual nameserver, and if you don't know your local nameserver, this IP address should work in a pinch to get you up and running. You can also put multiple nameserver entries in here, and it will search in order until it makes a connection to a DNS server.^[8]

If you plan on running named (the DNS server software) locally, you should change the IP address to read 127.0.0.1. Be sure to have a few other IP addresses in there in case named goes down.

directory       /var/named
;
cache           .                               named.ca
;
primary         wayga.net                       named.wayga
primary         a-muse.org                      named.a-muse
primary         0.0.127.in-addr.arpa            named.local

.                       3600000 IN      NS      A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.     3600000         A       198.41.0.4
;
; formerly NS1.ISI.EDU
;
.    3600000 NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.     3600000         A       128.9.0.107
;
; formerly C.PSI.NET
;
.                       3600000         NS      C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.     3600000         A      192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                       3600000         NS      D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.     3600000         A       128.8.10.90
;
; formerly NS.NASA.GOV
;

@               IN      SOA     wayga.net. enry.wayga.net. (
                1
                3600
                600
                3600000
                10800 )
                IN      NS      208.197.103.125
                IN      NS      208.197.103.21
wayga.net.      IN      A       208.197.103.125
galileo         IN      A       208.197.103.21
localhost       IN      A       127.0.0.1
wayga.net.      IN      MX      0 wayga.net.
                IN      MX      10 galileo
www             IN      CNAME   wayga.net.
mail            IN      CNAME   wayga.net.
ftp             IN      CNAME   wayga.net.
plan9           IN      CNAME   wayga.net.

21     IN   PTR  galileo.wayga.net.
125    IN   PTR  wayga.net.

options {
  directory "/var/named";
  /*
   * If there is a firewall between you and nameservers you want
   * to talk to, you might need to uncomment the query-source
   * directive below.  Previous versions of BIND always asked
   * questions using port 53, but BIND 8.1 uses an unprivileged
   * port by default.
   */
  // query-source address * port 53;
  listen-on { 127.0.0.1; 208.197.103.21; };
};


logging {
  category default {default_syslog; default_debug;};
  /* Uncomment to send debugging information to my own set of files */
  /*
  channel this_security_channel {
    file "named_security.log";
    severity info;
  };
  category security { my_security_channel; default_syslog;
  default_debug; };
  */
};

zone "." {
  type hint;
  file "named.ca";
};

zone "0.0.127.IN-ADDR.ARPA" {
  type master;
  file "named.local";
};     

zone "103.197.208.in-addr.arpa" {
  type slave;
  file "named.208.197.103";
  masters {
    208.197.103.2;
  };
};

zone "ratatosk.org" {
  type master;
  file "named.ratatosk";
};

zone "wayga.net" {
  type slave;
  file "named.wayga";
  masters {
    208.197.103.125;
  };
};

acl notlocal { ! localnets; };

acl first { 10.10.10/24 ; ! 10.10.10.128; };
acl second { ! 10.10.10.128 ; 10.10.10/24; };

acl trusted_slaves {localnets; 205.157.230.253; };

zone "ratatosk.org" {
  type master;
  file "named.ratatosk";
  allow-transfer {trusted_slaves; 208.197.103.125; };
};

listen-on [port]

listen-on port 7777 { 208.197.103.200; };

include

include "/etc/my_acls";

The nslookup program interacts with the nameserver to give IP information about a host or domain. This program will also allow you to examine things like A, MX, or CNAME records. When run with an option of a hostname, nslookup will contact the local DNS host and return information on that host as follows:

[markk@wayga named]$ nslookup wayga.net
Server:  wayga.net
Address:  208.197.103.125

Name:    wayga.net
Address:  208.197.103.125

[markk@wayga named]$

When run without any options, it puts you in an interactive mode, allowing you to enter hosts, set the kinds of queries, list hosts within a domain, and so on.

Entering a hostname from interactive mode will look up the host and return the results. The set type=X command will tell nslookup to report on only certain types of records (MX, PTR, A, CNAME, HINFO). Setting a type of ANY will search for all records.

[markk@wayga named]$ nslookup
Default Server:  wayga.net
Address:  208.197.103.125

> set type=ANY
> wayga.net
Server:  wayga.net
Address:  208.197.103.125

wayga.net       nameserver = 208.197.103.125.wayga.net
wayga.net       nameserver = 208.197.103.21.wayga.net
wayga.net       preference = 10, mail exchanger = galileo.wayga.net
wayga.net       preference = 0, mail exchanger = wayga.net
wayga.net
        origin = wayga.net
        mail addr = enry.wayga.net
        serial = 1
        refresh = 3600 (1 hour)
        retry   = 600 (10 mins)
        expire  = 3600000 (41 days 16 hours)
        minimum ttl = 10800 (3 hours)
wayga.net       internet address = 208.197.103.125
wayga.net       nameserver = 208.197.103.125.wayga.net
wayga.net       nameserver = 208.197.103.21.wayga.net
galileo.wayga.net       internet address = 208.197.103.21
wayga.net       internet address = 208.197.103.125
>

As you can see, this is a bit more information than you got earlier. The server command will allow you to request information from another server. This is good for debugging, since you can now ask a remote server for information about the domain you just set up and make sure the information is correct. The last command that is rather important is the ls DOMAIN command, which will list all the hosts under DOMAIN.. Using this on the domain you have just set up will verify that all hosts are being listed.

The Network File System (NFS) allows a server to export a directory or an entire filesystem to other systems. This feature provides for not only getting the most out of hard drives, but it can also allow a user's home directory to exist anywhere on the network, just as if it were local.

Setting up NFS for use is easy, as most Linux installations start up the necessary software at boot time. All that's left is to configure the NFS servers.

If NFS isn't started on bootup, all you need to do is fire up rpc.mountd and rpc.nfsd on startup. This is a script in the /etc/rc.d/rc3.d directory. The one other item that needs to exist is the /etc/exports file. The /etc/exports file lists what directories can be exported to other machines.

The /etc/exports file has a setup of the following:

directory               options

where directory is the directory to be exported, and options are any additional options to work on that export. The options are many and can provide different options per host. Any options not enclosed in a host are assumed to be for any hosts. Options can be the following:

Options can be prefaced with a hostname to apply them to only that host.

/pub wayga(rw)

The wayga machine can mount the directory in read write mode for all users (the default). The ro option means read only.

/pub/foo wayga(noaccess)

The foo subdirectory is not accessible to wayga. The only thing that wayga will see is permissions for the foo directory, and an ls of it will return only "." and "...".

Remember that unless you have a firewall or packet filter up, all NFS access will be TCP/IP-wide, unless you specify a host or group of hosts that can access that particular NFS directory.

From the NFS client, assume root power, and let's mount the /pub directory from above:

mount -t nfs wooba:/pub /mnt/pub

There are only a few changes in the mount command from mounting a hard drive or CD-ROM. The filesystem type is nfs, and the device name is replaced with a host:directory combo.

To have directories mount automatically on startup, you can enter them into the /etc/fstab file, or use the Red Hat fstool to add the mounts. Remember to replace the device file with the host:directory combo, and use the filesystem type of nfs. Once the network is started and NFS service has started, the NFS directories will mount.

One problem with NFS is that if the NFS server goes down, or the network connection between the client and server is broken, the client can effectively stop while trying to do file access. This can even include the situation where an NFS directory is in your $PATH. Running a command that searches through the path will cause your machine to appear to hang. There isn't a cure for it at this point. Just be sure that the server doesn't crash. Other network filesystems are in the works that will prevent some of these problems, but they don't quite work yet. The other important point is to make sure your networking is working correctly.

One additional program you may want to look at if you have a large amount of NFS drives is the amd program. This program is an automount daemon, and it automatically mounts and unmounts drives as needed. It's a bit outside the scope of this chapter, but you can download the program and give it a try if you have a lot of partitions to mount.

If you are installing from RPM, which is recommended, installation simply involves downloading the latest netatalk+asun distribution from ftp://contrib.redhat.com or a mirror. Then install/upgrade by running rpm -U <rpm file>.

In AppleTalk, there are two levels of access: guest and registered user. Being a guest user is basically like being the nobody user in UNIX: You have highly limited access to the server and typically can write only to areas that are world-writable. Often the guest account will also have printing privileges.

Under netatalk, users authenticate themselves using the user and password information in /etc/passwd, that is, they must have an account on the machine. If you don't want these users to have shell access, you can give them the shell /bin/false. This is analogous to what is done when setting up FTP-only accounts. If you would like to let your users change their passwords by logging in with ssh, telnet, or something similar, you can give them the shell /bin/passwd. If you choose to do this, be sure to add /bin/passwd to the /etc/shells file so that it is a valid shell.

In the configuration files for netatalk, you define which directories are available at the two levels of access, including the home directory of registered users, if wanted. For each instance of the AppleTalk daemon, you can specify a set of directories for guests and registered users to access.

Netatalk uses five configuration files. The RPM version also uses a sort of "meta" configuration file that serves to collect much of the configuration data in one place.

The AppleVolumes.default file lists directories to be shared. An entry of a tilde (~) will share the connected user's home directory. An optional second entry on the line will be used for the name of the volume. Otherwise, the name defaults to the last element of the path. Note that if you edit this in vi, a line with only ~ on it will appear no differently than other unused lines in the vi screen.

 #
 # Sample AppleVolumes.default
 #
 ~   # the user's home dir, will be named whatever the login name is
 /home/ftp/pub  "Public FTP Area"  # Share the public ftp area with an
                                   # appropriate name.
 /usr/local/Archives     # Share   the archive area, will be named
 'Archives'

AppleVolumes.system controls the mapping of file extensions to types that MacOS understands. You shouldn't have to do anything to this file except add new file extensions to it.

The afpd.conf file holds configuration information for the AppleTalk file protocol daemon. With the RPM version and a small network, you will likely leave this file empty, making any minor configuration changes in /etc/atalk/config.

To set up virtual servers (in the sense that there is only one physical machine), this file is the way to go. Each entry starts with a server name and is followed by various options.

 #
 # Sample afpd.conf
 #
 -                                  # A server going by the hostname
 foobar -address 10.1.1.34          # Server named 'foobar' bound to a
                                   # particular IP

atalkd.conf controls the interfaces to which netatalk binds, and any network numbers or zones you want to assign to them. In its simplest, empty form, atalkd.conf lets atalkd bind to every interface it finds. If it can't find all the interfaces you want it to bind to, you will have to specify them here. The simplest entry is just the interface to bind to. Additionally, zone names, network, node, and AppleTalk phase can be specified.

The phase is either 1 or 2, the latter being the default. The important difference is support for multiple zones in phase 2.

If there is more than one interface, it will automatically route between them. If there are other routers on the network, they can give configuration information to the Linux/netatalk router.

If you have more than one network, AppleTalk will break them into zones. In this case, you will want to use atalkd.conf to tell your server what zone to present itself as being in. You can also configure atalkd to listen to multiple interfaces and route AppleTalk packets among them.

Minimal atalkd.conf for use with multiple AppleTalk zones looks like the following:

eth0 -zone "Production"

The zone is basically a free-form string, although it must be 31 characters or less in length.

Unless you are on a very large network, you can also let atalkd set up its AppleTalk address. If this is not the case, you will have to assign one (or get one, if you are not in charge of the assignment of these addresses). Addresses are specified by network and node, like this:

-addr 45.10

In this example, the 45 is the network, while 10 is the node on that network.

The -net option is used to specify which address range is covered in this zone. This option lets you set the address range, which is automatically detected at server startup. If you have no zones, this number is irrelevant. The first number corresponds to the first network address of coverage in this range, and the optional last number corresponds to the last address covered in the address range. The address range should include netatalk's address number set with the -addr net.node option.

For example:

-net 106-110

The -zone option sets the name of the zone that atalkd should represent when talking on the network. This option, as discussed before, is merely a means of classification. It will be authoritatively broadcast if the -seed option is used and there are routers on the network whose zones don't conflict with that given after the -zone option.

The AppleTalk printer daemon reads its configuration information from papd.conf. If the conf file is empty, it will make all entries in /etc/printcap available. If you only want to make a subset of your print queues defined in /etc/printcap, you can specify them in papd.conf.

 #

 # Sample papd.conf
 #
 # We make two print queues available: the default 'lp' and 'lpcolor'
 # a color laser printer
 #
 # For the first printer we also provide the location of the printer
 # device driver file and the operator name for spooling.
 #
 B&W Laser Printer:
   :pr=lp:pd=/usr/share/lib/ppd/HPLJ_4M.PPD:op=nobody:

 Color LP:
   :pr=lpcolor:

If you're a sole Linux user on an AppleTalk network, your first priority—and perhaps the reason you're installing netatalk in the first place—might likely be to enable printing to a network Apple printer.

Start netatalk if it's not already running. Next, probe the AppleTalk network to determine the name of the printer.

Running the nbplkup program with no arguments will list all object types in the default zone. This will typically give you a few screens of information, even on a small network:

 # /usr/local/atalk/bin/nbplkup
      HP Color LaserJet 5M:SNMP Agent 150.128:8
      HP Color LaserJet 5M:HP Color LaserJet 5 150.128:158
      HP Color LaserJet 5M:LaserWriter 150.128:157
      HP Color LaserJet 5M:HP Zoner Responder 150.128:155
            CIC-2 BobM 4M+:SNMP Agent 150.151:8
            CIC-2 BobM 4M+:LaserWriter 150.151:157
            CIC-2 BobM 4M+:LaserJet 4 Plus 150.151:158
            CIC-2 BobM 4M+:HP Zoner Responder 150.151:152
     Judith's Laserjet 4mv:SNMP Agent 150.130:8
     Judith's Laserjet 4mv:LaserWriter 150.130:157
     Judith's Laserjet 4mv:LaserJet 4V 150.130:158
     Judith's Laserjet 4mv:HP Zoner Responder 150.130:152
  XRX_DC230ST_08003E30CC89:LaserWriter 150.225:128
     ...

To show only LaserWriters:

 # /usr/local/atalk/bin/nbplkup :LaserWriter
  XRX_DC230ST_08003E30CC89:LaserWriter                      150.225:128
     Judith's Laserjet 4mv:LaserWriter                      150.130:157
            CIC-2 BobM 4M+:LaserWriter                      150.151:157

Let's set up the first printer returned as the default. To be thorough, we will also check the status of the printer:

# /usr/local/atalk/bin/papstatus -p XRX_DC230ST_08003E30CC89
spooler: ready
#

It appears to be okay. Next, let's test the printer by sending a file to it with pap:

# /usr/local/atalk/bin/pap -p XRX_DC230ST_08003E30CC89:LaserWriter
  links.ps
Trying 150.225:128 ...
spooler: ready
Connected to XRX_DC230ST_08003E30CC89:LaserWriter@*.
Connection closed.
#

To use the printer via the Linux lpr command, an entry in /etc/printcap for the printer must be made. (See the chapter on printing for an explanation of the details of printcap entries.) The important items to note are the AppleTalk name of the printer in the first line and the last two lines, which tell the printer daemon which input and output filters to use; in this case, the filters that come with the netatalk distribution.

 lp|LaserWriter 1|XRX_DC230ST_08003E30CC89:
        :sd=/usr/spool/laserwriter1:
        :lp=/dev/null:
        :pl#63:pw#85:
        :mx#0:
        :sh:sf:
        :lf=/var/log/lpd-errs:
        :if=/usr/lib/atalk/filters/ifpap:
        :of=/usr/lib/atalk/filters/ofpap:

The spool directory, status file, and lock file need to be set up next:

 # mkdir /var/spool/tlaserwriter1
 # chown root.lp laserwriter1
 # chmod 775 laserwriter1
 # touch laserwriter1/lock
 # chown root.root laserwriter1/lock
 # chmod 004 laserwriter1/lock
 # touch laserwriter1/status
 # chown root.root laserwriter1/status
 # chmod 664 laserwriter1/status

Now, start (or restart if it is already running) the printer daemon. Do this by running /etc/rc.d/init.d/lpd (re)start.

This file is only present if you installed from RPM. It contains definitions for a number of variables used by the startup script installed at /etc/rc.d/init.d/atalk.

One of the variables you are likely to want to change is the maximum number of simultaneous connections, AFPD_MAX_CLIENTS. The default is 5, which, unless you have a very small network, will likely be too small. Other options you might want to change include enabling the guest account, setting its username, and choosing which daemons to run. If you do not need to share your print queues, set PAPD_RUN to No. Similarly, if you do not want to share any filesystems, set AFPD_RUN to No.

Note that some of the options in config are not actually supported yet and therefore shouldn't be turned on.

There are a few hardware caveats related to Ethernet cards. Netatalk doesn't function on cards based on DEC's Tulip chip, though it appears that activating the interface in promiscuous mode has been reported to fix this problem. Also, the driver for your card must support multicasting; check the Ethernet HOWTO to determine if your card's driver does.

Aside from these functional considerations, the best hardware investment is a good, fast disk. Spend the extra money to buy a faster disk and/or faster disk controller.

The latest netatalk-1.4b2+asun distribution can always be found at ftp://ftp.u.washington.edu/public/asun/. When you install from source, the installation is rooted at /usr/local/atalk by default. There, a nominal set of directories (bin, etc, include, lib, and man) is created for the netatalk binaries, config files, and so forth.

There are only a few differences between source-based installation and RPM-based installation. The config directory is /usr/local/atalk/etc. It contains the following configuration files: AppleVolumes.default, AppleVolumes.system, atalk. conf, afpd.conf,and papd.conf. There is no config file, so you will have to edit the startup script yourself to change or add options.

Second, the startup script is named rc.atalk. It is installed in /usr/local/atalk/etc/. You will need to add a line to /etc/rc.d/rc.local to call it upon bootup.

Lastly, as is the case for many network services, you will need to make a few entries in /etc/services as well (RPM does this for you), including:

 rtmp         1/ddp   # Routing Table Maintenance Protocol
 nbp          2/ddp   # Name Binding Protocol
 echo         4/ddp   # AppleTalk Echo Protocol
 zip          6/ddp   # Zone Information Protocol

Once you have config files set up, invoke the rc.atalk script:

# /usr/local/atalk/etc/rc.atalk

This will take a minute or two as netatalk scopes out the network, registers itself, and so forth.

Now, go to one of your Mac clients and start the chooser. Select the new AppleTalk server, as shown in Figure 6-1, select the volumes to attach to, and watch them show up on your desktop!

Figure 6-1. Galileo is a netatalk server.

It is most likely that your first encounter with NIS will be as a client. Setting up your Linux machine to be an NIS client is fairly straightforward.

Red Hat makes the process of working in an NIS network easy with two scripts included with the system: /etc/rc.d/init.d/ypbind and /etc/rc.d/init.d/autofs. The second script is only needed if you have automount maps in your NIS server. You can also set NIS client configuration during the installation process. See the installation chapter for more information on this.

You should make sure that the time service is enabled in /etc/inetd.conf. If it is not, uncomment it and restart inetd.

You will need to set the NIS domain that you're in. Edit (or create) the /etc/defaultdomain file to have one line—that of the NIS domain you're in. Remember that NIS domains and DNS domains are not the same (did we mention this yet?). Newer versions of Red Hat (like the 6.0 release) use the /etc/yp.conf file to edit the NIS domain or a server to bind to.

By default, ypbind will send an IP broadcast through the network to find an NIS server. If the NIS server is on another network, or you want to prevent spoofing on the network, you can manually specify an NIS server to use. Edit the /etc/yp.conf file and add the hostname for the server. Make sure the host listed here is listed in /etc/hosts:

ypserver nisserver.host.com

In the examples below, we've assumed /etc/passwd is fairly minimal, containing entries for the superuser, various daemons, and so forth, but no mortal user entries.

To append the whole NIS password map to the local /etc/passwd file, add this line:

+::::::

You can customize access by adding additional lines starting with + or −. For example, deny the user cary access, but allow all others (at least to the extent they have on any other NIS client) like this:

+::::::
-cary

The "+::::::" entry is not mandatory. Additionally, you can control access by groups, using "@." This entry:

+cary::::::
+rachel::::::
+@plan9::::::
-paul
-enry

allows access for cary, rachel, and the group plan9. The users paul and enry (who are presumably in the aforementioned group) are denied.

It is also possible to override sections of information in the passwd map entry or to add users that don't exist in the NIS at all. For example, to give paul the shell /bin/tcsh, change rachel's home directory (and allow access to only them), and add a user surya, use entries like this:

+::::::
+paul::::::/bin/tcsh
+rachel:::::/local/home/rachel:
+:*:::::/bin/false
surya:IUg6jkhgT:506:100::/home/surya:/bin/bash

Next, make sure that the portmapper is starting. If you're using NFS, then the portmapper is already started. If not, use /etc/rc.d/init.d/portmap start to get it started. Finally, you can start with ypbind: /etc/rc.d/init.d/ypbind start. This will read the /etc/defaultdomain file, start the ypbind program, and connect you to the NIS server.

The /etc/nsswitch.conf file determines the lookup order for all NIS information (unlike /etc/host.conf, which is only for host lookups). The example below is self-explanatory:

#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
#          nisplus           Use NIS+ (NIS version 3)
#          nis               Use NIS (NIS version 2), also called YP
#          dns               Use DNS (Domain Name Service)
#          files             Use the local files
#          db                Use the /var/db databases
#          [NOTFOUND=return] Stop searching if not found so far
#
  passwd:     compat
  group:      compat
  shadow:     compat
  passwd_compat: nis
  group_compat: nis
  shadow_compat: nis
  hosts:      nis files dns
  services:   nis [NOTFOUND=return] files
  networks:   nis [NOTFOUND=return] files
  protocols:  nis [NOTFOUND=return] files
  rpc:        nis [NOTFOUND=return] files
  ethers:     nis [NOTFOUND=return] files
  netmasks:   nis [NOTFOUND=return] files
  netgroup:   nis
  bootparams: nis [NOTFOUND=return] files
  publickey:  nis [NOTFOUND=return] files
  automount:  files
  aliases:    nis [NOTFOUND=return] files

The automounter will (as the name implies) automatically mount partitions over NFS based on an NIS map. The two typical maps used are auto.home and auto.vol, which mount off of /home and /vol, respectively. If you have these maps in your NIS domain, you can start the Linux autofs automounter using the following command:

 /etc/rc.d/init.d/autofs start

It should be noted that the automounter under Linux performs some of the same functions as vold under Solaris. CD-ROMs, floppy disks, local volumes, and NFS filesystems can be automatically mounted when the user changes to a certain directory. By default, Red Hat 6.0 includes /misc/cd and /misc/kernel, which mount /dev/cdrom onto /misc/cd and ftp.kernel.org via NFS onto /misc/kernel. We mention the automounter with NIS, since that is the most frequently used reason for using it.

NIS+ is Sun's successor to NIS. It has better security and handles a large number of clients. Historically, support for NIS+ under Linux was poor and limited to the client side only. Fortunately, recent Red Hat versions are based on glibc, which supports NIS+ more fully, though still not completely.

Despite this support, NIS+ is still much more difficult to use, particularly on the server end. We recommend that you only use Linux as an NIS+ client if you have to (if you are on a large network or are concerned about security) and not use Linux as an NIS+ server at all.

If you need to set up an NIS+ client, you will need to make a few changes to your system. First, you will need glibc 2.1 (for 32-bit systems, e.g., Intel machines) or glibc 2.1.1 (for 64-bit systems, e.g., Alpha machines). If you are running Red Hat 6.0, you have glibc 2.1.1 already. If not, you will need to upgrade glibc and recompile gcc/g++ against the new glibc. Both source and binary releases of glibc can be found at ftp://ftp.gnu.org/gnu/glibc.

Second, you need the NIS+ client programs. These programs can be found at ftp://ftp.kernel.org/pub/linux/utils/net/NIS+. You will need two files: nis-tools-1.4.tar.gz and pam_keylogin-1.1.tar.gz. Unpack and compile them.

Assuming your NIS+ server is set up to answer requests for your client (see your Solaris documentation for how to do this), you will need to set the NIS+ domain name as you would for NIS and then run nisinit as follows:

# nisinit -c -H <NIS+ server>

Edit /etc/nsswitch.conf, making sure the only service after publickey is nisplus (publickey: nisplus). Next, start keylogin. You should add keylogin to the rc boot up sequence so that it is the daemon started immediately after portmap:

# keylogin -r

Edit the /etc/pam.d/login file to match this:

#
# /etc/pam.d/login for use with NIS+
#
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_keylogin.so
auth       required     /lib/security/pam_unix_auth.so
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_unix_acct.so
password   required     /lib/security/pam_unix_passwd.so
session    required     /lib/security/pam_unix_session.so

Lastly, edit nisswitch.conf. Basically, you will want to replace nis with nisplus.

Make sure that you have the ypserv package installed. If you need to install it, it can be found on the Red Hat CD, FTP site, or one of their mirrors.

Next, edit /var/yp/Makefile to add or remove the maps you will be serving. The line starting with all: contains the list of maps.

Now edit /var/yp/securenets and /etc/ypserv.conf. The first defines the IPs from which the server will answer requests. It is fairly simple and well-commented.

#
# Sample /var/yp/securenets
#
#
# Allow localhost access. This is necessary!
#
host 127.0.0.1
#
# Allow access from machines on the local network
#
255.255.255.0 10.10.10.0
#
# Access from two class C networks 209.1.2.0 and 209.1.3.0
#
255.255.254.0 209.1.2.0

The /etc/ypserv.conf file lets you further customize the server's behavior at the host or network level on a per map basis. There are two types of entries: options and access rules. Options have the simple format of <option>: yes|no, i.e., the option is either on or off. Access rules have the format host : map : security : passwd_mangle. Access rules are read until a match is found for the host and map being requested, then the rule is applied.

An option that is commonly turned on is dns. The following line would tell the NIS master to consult DNS if it finds a host in its host maps.

dns: on

The following lines simulate shadow passwords for a particular network for privileged ports (those numbered under 1024) and deny access to the maps to other hosts:

 10.10.10.0/255.255.255.0   : passwd.byname    : port       : yes
 10.10.10.0/255.255.255.0   : passwd.byuid     : port       : yes
 *                          : passwd.byname    : port       : yes
 *                          : passwd.byuid     : port       : yes

Next, start the portmapper:

# /etc/rc.d/init.d/portmap start

and then ypserv:

# /etc/rc.d/init.d/ypserv start

You can verify that things are running with the following:

# rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting

Now run ypinit to generate the maps in /var/yp from the files in /etc:

# ypinit -m

If you are setting up a slave server, run:

# ypinit -s master

and you're ready to get the clients connected!

The netcfg program does many of the routing setups that would normally have to be done by hand automatically and on startup. These files get stored in /etc/sysconfig and are compatible with linuxconf's routing scheme.

These commands, entered by hand, will allow you to route between two networks:

/sbin/ifconfig eth0 192.168.1.10
/sbin/route add -net 192.168.1.0
/sbin/ifconfig eth1 192.168.2.10
/sbin/route add -net 192.168.2.0
/sbin/route add default gateway 192.168.1.15

If you use these in a file like rc.local, it will work, but it is not compatible with the way that linuxconf or netcfg stores its routing information. Make sure you're not conflicting with these other methods.

Here the machine is on two networks, 192.168.1.0 and 192.168.2.0, both class C with netmasks of 255.255.255.0 and broadcasts located at the .255 IP address. Since the netmasks and broadcasts are standard for class C, we don't have to tell ifconfig about them. As soon as ifconfig gets the message to start up, it activates the module (if necessary) and configures the device. The route tells the net-working section to pass packets for each kind of network to the specified Ethernet card. The final route designates a default location for packets that don't match any other route to go. In this case, it goes onto the 192.168.1.0 network to the machine with an IP address of 192.168.1.15. If this machine were acting as a company-wide router, this address would point to the router box installed by the ISP. Since Linux now knows how to route packets between the 1.0 and 2.0 networks, any packets that get directed to it to go to a network will automatically be sent there. So, 192.168.1.10 and 192.168.2.10 now become gateways for anyone on those respective networks.

This example only shows how to use static routing. There are other methods of routing, such as RIP (which is handled by routed), and OSPF (handled by gated). Since the networks we administer are not that large, and many configuration issues are only in a few locations, we prefer to use static routes so we know exactly what our networks look like. For some networks, you may need the above programs.

If you replace eth0 with ppp0, you now have a routing PPP dialin. The Linux machine is dialed into another machine, and is able to route data between the local Ethernet network and the remote PPP link. As previously mentioned, this method works for any two (or more) IP connections.

By default, all packets are allowed to pass between connected networks. If you want to implement some sort of security to prevent violation attempts, you'll need to get familiar with the built-in packet filtering tools ipfwadm and ipchains. The older 2.0 and 2.1 kernels used the ipfwadm command to implement packet monitoring, filtering, and accounting. The newer 2.2 and 2.3 kernels use ipchains, which implements all the functionality of ipfwadm plus some. See the next chapter for information on how to boost security between networks.

In the early 1990s, domains were free for the taking. If you filled out your template and sent in the form, you got yourself a domain name. Everyone thought this would go on forever, but alas...

In the mid 1990s, the National Science Foundation (NSF) started cutting off funding to the Internet and allowed commercial organizations to begin using the Internet to sell and advertise. The response was an explosive growth in the number of domains being added. This got into the hundreds of thousands per year. To impose some order on this and make up for some of the missing NSF funding, the InterNIC ( http://www.internic.net) was created to provide for a top-level DNS domain and to register new organizations within the United States. The downside to this was a new Internet fee: $70 for the first two years, then $35 each year after. After paying this fee, you are entitled to have your domain registered in the InterNIC database and your domain can be recognized by the rest of the Internet. This doesn't mean that the InterNIC will give you anything else, like DNS services or an Internet link. You will just have your domain name registered and a pointer to a DNS server. You're still responsible for getting Internet service and a DNS server.

The InterNIC only handles U.S. domains: .edu, .net, .org, .com, .gov, and .int. Other domains, such as .us or other country-based domains, are not registered with the InterNIC, and you'll have to find out who handles your regional DNS service to get registered with them. Many of these have a fee, but some (like .us) are free or have a smaller fee than the InterNIC. To register in the .us domain, go to http://www.isi.edu. The .us domain doesn't give the kind of general quality that, for example, .com would give. For example, instead of wayga.net, you'd probably get something like wayga.billerica.ma.us. but I could still build a domain under that such as ftp.wayga. billerica.ma.us. In some ways, this is preferable to just a .com domain since it allows you to specify the location of a site (ibm.armonk.ny.us) directly. Foreign companies have slightly different subdivisions and may subdivide by location, type of organization (commercial, educational, etc.), or a combination of these. To find out the contacts for a particular country's top-level domain, check out http://www.isi.edu/div7/iana/domain-names.html.

One other thing to remember about country codes is that they may not be what you think they are. For example, .ch is Switzerland, not China, and .ca is Canada, not California.

whois wayga.net

whois -h rs.internic.net wayga. net

The CERT Coordination Center was founded in 1988 to coordinate security problems on the Internet. It was founded after the great Internet Worm of the late 1980s and is located at Carnegie-Mellon University in Pittsburgh, Pennsylvania. If you don't know anything about the Internet Worm, either read The Cuckoo's Egg by Cliff Stoll or Cyberpunk: Outlaws and Hackers on the Computer Frontier by Katie Hafner and John Markoff. Both are excellent books and show some real-life examples of crackers and those who track them down. Anyway, CERT's purpose is to keep administrators aware of potential security holes in the OS or the software the OS runs. These security alerts often list the type of security hole, how it can be exploited, what versions are affected, and (if available) locations of patches or ways to prevent anyone from taking advantage of those holes. The comp.os.linux.announce group has posts every now and then from CERT related to Linux and programs it runs. Strangely enough, some of the security holes they have are not with Linux itself, but with the way a particular program was compiled, making the hole not a Linux problem at all, but a fault of whoever compiled that program.

If you have an intrusion that you need investigated, you can send an intrusion report to CERT and maybe they can help you track down the person responsible. Their Web site is http://www.cert.org/. It is probably best to give their site a visit before your site gets broken into so you can stay up-to-date with their advisories.

The Computer Incident Advisory Capability (CIAC) is run by the U.S. Department of Energy as something similar to CERT, but it primarily provides services for the U.S. Department of Energy (DOE) and its contractors. However, it does have a number of bulletins and advisory notes that may not be at CERT. It is also worthwhile to take a look at their site to keep up-to-date with security issues.