• Target on Windows NT 4 Server and Redhat Linux 6.2
• To learn pre-installation configuration on different OSes
• Compare the similarity and differences between two major OS platform available in the market.

1. Install NT and reserve some space for Linux installation (about 1G)
2. Install Linux on the partition that reserve for it.
3. Using Linux boot loader selector, select the os that you want to boot in to it.
4. During the installation, TCP/IP support should be setup. In the introductory practical, we will use a block of Class C for our ip address assignment. The ip address should be in this form: 202.75.0.x where x is an arbitrary number. The netmask should be 255.255.255.0. (for detail on TCP/IP, please attend the following practical :-)
5. These ip addresses should be same in Linux and NT Server.
6. For detail on how to install the OS, please refer to appendix 1 for Linux and appendix 2 for NT.

Submit a single page report on the similarity and difference between the two Oses.

Guide: take note on the file system, ip assigning, system structure, security……

Appendix 1 and Appendix 2.

1. Before we go into detail, there are some files that we should taken care of. First, you must have your hostname and ip address ready in your machine. You can configure these two particular parameter by editing the two files in /etc/hosts and /etc/networks.
2. In this experiment, the class is divided into two group. Each group will be assign with Class C address. The Class C address should looks like this: 192.168.0.x and 192.168.1.x where x is an arbitrary number, netmask 255.255.255.0. By doing this, we have divide the machine into 2 different network.
3. By default the machine in the same network should be able to talk to each other. Try to do a ping test to several machine in the same network. After that, do a ping test to the machine in different network.

Can it be done? Why?

4. Display your kernel routing table on the screen to observe what is being routed. (Take note on it)
5. Add a routing statement on the kernel routing table. The routing statement should looks like this:

route add –net 192.168.0.0 netmask 255.255.255.0 eth0 or

route add –net 192.168.1.0 netmask 255.255.255.0 eth0

6. Now, try to display your kernel routing table again. What do you observed?
7. Can you ping to the machine in different network? Why?
8. Now, delete the routing statement that you just added.

route del –net 192.168.0.0 netmask 255.255.255.0 eth0 or

route del –net 192.168.1.0 netmask 255.255.255.0 eth0

9. Add another routing statement to the kernel to use other machine as gateway.

route add –net 192.168.0.0 mask 255.255.255.0 gw

10. Now, try to ping to the other machine on different network. Can it work?

Submit your observation during the experiment.

Appendix 3 & Appendix 4

• In this experiment, we are going to setup our system so that it act as both a client and server for other server for other machine in the network.
• For Linux, we are going to look into the tools, configuration files and command needed to setup network storage sharing.
• For Windows NT, we look into the service and protocol need to be install and tools needed to access network storage sharing.

1. Check whether the rpc.nfsd and rpc.mountd daemons are running in the background.
   ps –ef | grep rpc

If these daemons haven’t start, execute it in /usr/sbin

2. If the daemons were running, you can start sharing your directory to others by editing the file /etc/exports. E.g.: the following sample shows the shareable directory in the local machine.

# /etc/export

/usr/local/data user1 (rw) user2 (rw)

/usr/ftp (ro)

3. Once you get the server running, other people can mount your shared directory to their local mount point by this command:

1. Right click the folder that you want to share and select the sharing menu item. This will share your NT Server folder to other.
2. Set the access permission such as

1. Share the folder to every one
2. Share the folder as read only
3. Share the folder for a certain group

3. Test the setup and observe the difference between each configuration.

Appendix 5 & Appendix 6

1. Before configure the SAMBA Server, try to use Windows Explorer to view the content of the Linux Server. Can the content displayed in the NT Explorer? What happen?
2. By referring to Appendix 7, setup the Linux Server with a simple configuration as follow:

1. Setting up a file server to provide home folder for the user u have created.
2. Use your SAMBA Server to authenticate the user.
3. Configure your SAMBA Server so that it provides shares for group access.
4. Configure your SAMBA Server to accept clear text password and observe the difference between Windows 98 login and Windows NT login.
5. Configure your SAMBA Server to accept encrypted password and observe the difference between Windows 98 login and Windows NT login.

3. Try to use smbclient to connect to a NT folder. Can it work?
4. After that, use Windows Explorer to view the content of the shared folder in the Linux Machine. Can it work?

Appendix 7

1. First we are going to setup some basic configuration so that we can query our own name server.
2. If we successfully query our own server, we can start putting in some record to our name server zone file.
3. After that, the reverse zone file should be created.
4. Please refer to Appendix for the zone file and reverse zone file configuration format.
5. After all, you should be able to query the ip address to get the host name or vice versa.

Appendix 8 & Appendix 9

1. Kill any mail server that run in the background.
2. Customize your mail server, such as:
1. Customize SMTP login message.
2. Maximum e-mail size
3. Restriction Policy
4. Mail header configuration.
5. Additional Features.
3. Restart your mail server and test your configuration.

Try send an email out by telnet into your smtp server.

Look for the SMTP RFC.

Appendix 10 and Appendix 11

In this experiment, we are going to setup the server to serve as a multi-hosting server.

1. By referring to Appendix, configure your server so that it can show the default page of the web server. For Linux, you just have to look at the ServerName and DocumentRoot directive under httpd.conf. For IIS, all you have to do is to ensure the default page is located in the webserver public root directory.
2. Test your server by using a web browser. Just type in localhost or 127.0.0.1 or the web server ip address in the url box.
3. Configure your web server, such as:
1. Virtual hosting was enabled.
2. Display directory listing.
3. Securing the Web Server.
4. Serving Dynamic Content.
4. Restart the server and test the configuration.

Create your own web page and host it in your own web server. Assessment is base on the functionality of the web pages. You can use any third party software (i.e. Dreamweaver, Frontpage, etc…), language (javascript, vb script, cgi, perl …) to create your own web page.

Appendix 12 & Appendix 13

1. Set up an authentication enable FTP Server. Then test your server by restarting the inetd.
2. Try to be familiar with the ftp command by upload and download file to and from the server.
3. Setup an anonymous FTP Server with some security and feature such as:
1. Limited Shell Command.
2. Read Only Directory.
3. Upload Restriction.
4. Welcome message.
5. Password Type.
6. Log your FTP Server Access.
4. Restart the Server and test the configuration.

Try to list the content of the ftp server by telnet into ftp server. Submit a report on this. Assessment is base on the functionality that telnet can do. e.g. download file, upload file, etc.

Refer to FTP RFC.

Appendix 13 & Appendix 14

All Linux distribution nowadays come with bootable CDROM. So installation of Linux was a simple task. When the installation program boot up, it will probe your system and attempt to identify your CD-ROM drive.

After booting, the installation program begins by displaying the language screen. If you wish to abort the installation process at this time, simply eject the boot diskette or CD-ROM now and reboot your machine.

Using your mouse, you can select your preferred language to use for the installation and the system default

First, choose the model that best fits your system. Next, choose the correct layout type for your keyboard (for example, U.S. English).

First, choose the correct mouse type for your system. Try to find an exact match. If an exact match cannot be found, choose a mouse type that you are sure is compatible with your system

After all, you will see a welcome screen. Now, the hardware are set. So lets the software begin.

This section will let you choose what type of installation method you want. You can perform a full installation or an upgrade. If you choose to perform a full installation, you must also choose the class of the installation. Your options include: Custom, GNOME Workstation, KDE Workstation or Server.

Only the custom-class installation allows you complete flexibility. The workstation-class and server-class installations automatically go through the installation process for you and omit certain steps. During a custom-class installation, it is up to you how disk space should be partitioned. You have complete control over the packages that will be installed on your system. You can also determine whether you’ll use LILO to boot your system.

The installation process for Red Hat Linux 6.2 includes the ability to upgrade from prior versions of Red Hat Linux (version 2.0 and later) that are based on RPM technology.

Upgrading your system installs the modular 2.2.x kernel as well as updated versions of the packages, which are currently installed on your machine.

Once you have chosen which drive to partition, you will be presented with the fdisk command screen: as shown…

After partitioning of the hard disk has been done, you can choose which partition to be format and which partition should not. Note: all newly created partition should be formatted.

In order to be able to boot your Red Hat Linux system, you usually need to install LILO (the LInux LOader). You may install LILO in one of two places:

Recommended if you are already using another boot loader on your system (such as

OS/2’s Boot Manager). In this case, your other boot loader will take control first. You can then configure that boot loader to start LILO (which will then boot Red Hat Linux).

Note: If you have Windows NT (and you want to install LILO) you should choose to install LILO on the first sector of the root partition, not the MBR.

Create boot disk -- The Create boot disk option is checked by default. If you do not want to create a boot disk, you should deselect this option.

A boot disk can be handy for a number of reasons:

• Use It Instead of LILO -- You can use a boot disk instead of LILO. This is handy if you’re trying Red Hat Linux for the first time, and you’d feel more comfortable if the boot process for your other operating system is left unchanged. With a boot disk, going back to your other operating system is as easy as removing the boot disk and rebooting.

• Use It If Another Operating System Overwrites LILO -- Other operating systems may not be as flexible as Red Hat Linux when it comes to supported boot methods. Quite often, installing or updating another operating system can cause the master boot record (originally containing LILO) to be overwritten, making it impossible to boot your Red Hat Linux installation. The boot disk can then be used to boot Red Hat Linux so you can reinstall LILO.

Do not install LILO -- if you have Windows NT installed on your system, you may not want to install LILO. If you choose not to install LILO for this reason, make sure that you have chosen to create a boot disk; otherwise you will not be able to boot Linux. You can also choose to skip LILO if you do not want to write LILO to your hard drive.

The network configuration in Red Hat Linux is simple. You can choose your device type and whether you would like to configure the device using DHCP or manually. If you have multiple ethernet devices, each device will keep the information you have provided. You may switch between devices, for example eth0 and eth1, and the information you give will be specific to each device. If you select Activate on boot, your network interface will be started when you boot.

Next enter, where applicable, the IP Address, Netmask, Network, and Broadcast numbers.

You can set your time zone either by selecting your computer’s physical location, or by your time zone’s offset from Universal Coordinated Time (also known as UTC).

Post-configuration

After all these basic configuration, the system was basically being setup, and the installation of packages will begin. After all the selected package had been installed, the system have to be reboot. And the system is ready to run.

When you insert the Windows NT CD ROM, it will automatically bring up the setup window. If you don't see this, double click on the CD ROM.

Press the Windows NT Setup button.

You must confirm the location of your Windows NT setup files.

Press Enter to continue.

Setup will take quite a while to copy files to your hard disk (Ten minutes or more). Once it is complete, press enter to leave setup and then restart your computer.

When the computer restarts, you will be in a dual-boot configuration and it will allow you to select which system to start. Use the arrow keys to select Windows NT 4.0 Installation/Upgrade.

The setup process will continue and you will be asked to confirm a number of hardware-related settings.

• Be sure to select the proper drive letter for the installation. In our case, drive D:
• You should convert to NTFS during the installation.
• To save yourself lots of headaches, let NT install into the \WinNT directory.

After all the options are set, Windows NT setup will finish copying files and restart again.

When the computer restarts, you will again be allowed to select which system to start. Use the arrow keys to select Windows NT Server Version 4.0

You will be placed in Windows NT Setup and asked to finish setting up the remainder of the Windows NT configuration.

Part One is information about your computer.

• License and registration information
• Computer Name
• Type of server: select Primary Domain Controller for your first server.
• Password
• System Components

Part Two is information about your network.

• Install the Internet Information Server.
• Select and set the settings for your ethernet adapter.
• Network Protocols: This subject is open to debate, but I suggest selecting only TCP/IP.
• Network Services: Keep it simple for now, and leave at the defaults.
• Select that you do not wish to use DHCP.
• TCP/IP Properties: set your IP Address, subnet mask, and gateway.
  Click on the DNS tab, set your Host Name and Domain and Add the IP address of your DNS service.
  Press OK, and you will get an error message about noWINS address. Select to continue.
  If you don't know the above settings, consult with your network administrator or Internet Service Provider.
• Domain: Set the Domain name for your NT Network. Note that this is not the same as your DNS domain name.

Part Three is the configuration of your computer.

• Time zone, date, and time.
• Monitor settings.

Finally, setup will copy more files, complete the configuration, and ask you to restart your computer.

The first step in setting up TCP/IP on your Linux machine is to make the network interface accessible. This is done with the ifconfig command. When run, ifconfig essentially makes the network layer of the kernel work with the network interface by giving it an IP address, and then issuing the command to make the interface active. When the interface is active, the kernel can send and receive data through the interface.

You need to set up several interfaces for your machine, including the loopback driver and the Ethernet interface (or whatever other network interface you are using). The ifconfig command is used for each interface in turn. The general format of the ifconfig command is

where interface_type is the interface's device driver name, such as lo for loopback, ppp for PPP, and eth for Ethernet. The IP_Address is the IP address used by that interface.

Once the ifconfig command has been run and the interface is active, you must use the route command to add or remove routes in the kernel's routing table. This is needed to allow the local machine to find other machines. The general format of the route command is:

where either add or del is specified to add or remove the route from the kernel's routing table, and IP_Address is the remote route being affected.

You can display the current contents of the kernel's routing table at any time by entering the command route all by itself on the command line. For example, if your system is set up only with the loopback driver, you will see an output like this:

The important columns are the destination name, which shows the name of the configured target (in this case only loopback), the mask to be used (Genmask), and the interface (Iface, in this case /dev/lo). You can force route to display the IP addresses instead of symbolic names by using the -n option:

A typical Linux network configuration will include a couple of interfaces. The loopback interface should exist on every machine. The network interface, whether Ethernet or other device, is also present (unless you only want a loopback driver). This chapter assumes you want to set up your system for a loopback and an Ethernet card, both of which need to be done separately.

The loopback interface should exist on every networked machine (as well as machines that are stand-alone, for that matter). The loopback interface always has the IP address 127.0.0.1, so the /etc/hosts file should have an entry for this interface. The loopback driver may have been created by the kernel during software installation, so check the /etc/hosts file for a line similar to this:

If the line exists, the loopback driver is in place. Make sure the line doesn't have a pound sign ahead of it to comment it out. If the line doesn't exist in the /etc/hosts file, add it using an ASCII editor.

If the loopback interface was not in the /etc/hosts file, you will need to create the interface as well using the ifconfig command. Issue the following command to complete the addition of the loopback driver:

If you are not sure about the configuration, you can use the ifconfig command to display all the information it knows about the loopback driver. Use the following command:

You should see several lines of information like the following:

If you get an error message such as unknown interface, the loopback driver does not exist and must be added.

Once the ifconfig routine has been checked, add the loopback driver to the kernel routing tables with one of these two commands:

It doesn't matter which command you use because they both refer to the same thing. The command essentially tells the kernel that it can use the route for address 127.0.0.1 or the name localhost.

As a quick check that all is correct with the loopback driver, you can use the ping command to check the routing. For example, if you issue either of these two commands

you should see output like this:

The ping command's progress was interrupted by the user issuing a Ctrl-C after seven transmissions. You can let as many transmissions as you want go by. If you get a "no replies" from the ping command, then the address 127.0.0.1 or the name localhost wasn't recognized and you should check the configuration files and route entry again.

If the configuration files look correct and the route command was accepted properly, but the ping command still doesn't produce the proper results, then you have a serious problem. In some cases, the network kernel is not properly configured and the entire process must be conducted again. Sometimes a mismatch in versions of kernel drivers and network utilities can cause hang-ups with the ping routine, as well.

Now that the loopback driver is installed and operational, you can do the same configuration process with the Ethernet driver (or whatever driver you are using). The process is exactly the same: use ifconfig to tell the kernel about the interface, and then add the routes to the remote machines on the network. If the network is attached, you can then test the connections with ping.

To begin, set up the Ethernet interface using ifconfig. To make the interface active, use the ifconfig command with the Ethernet device name and your local IP address. For example, use the command

to set up the local machine with the IP Address 147.123.20.1. The interface is to the Ethernet device /dev/eth0. You don't have to specify the network mask with the ifconfig command, because it will deduce the proper value from the IP address entered. If you want to explicitly provide the network mask value, append it to the command line with the keyword netmask:

This command explicitly sets the network mask to 255.255.255.0. You can then check the interface with the ifconfig command using the interface name:

You may have noticed in the output from the command that the broadcast address was set based on the local machine's IP address. This is used by TCP/IP to access all machines on the local area network at once. The Message Transfer Unit (MTU) size is usually set to the maximum value of 1500 (for Ethernet networks).

Next, you need to add an entry to the kernel routing tables that let the kernel know about the local machine's network address. That lets it send data to other machines on the same network. The IP address that is used with the route command to do this is not your local machine's IP address, but that of the network as a whole without the local identifier. To set the entire local area network at once, the -net option of the route command is used. In the case of the IP addresses shown previously, the command would be:

This command adds all the machines on the network identified by the network address 147.123.20 to the kernel's list of accessible machines. If you didn't do it this way, you would have to manually enter the IP address of each machine on the network. An alternative method is to use the /etc/networks file which can contain a list of network names and their IP addresses. If you have an entry in the /etc/networks file for a network called foobar_net, you could add the entire network to the routing table with the command:

Once the route has been added to the kernel routing tables, you can try the Ethernet interface out. This step assumes, of course, that you are connected to other machines and that you know the IP address of one of them. If your network isn't installed yet or you are not connected to another machine that is running TCP/IP, you can't try this step now. To ping another machine, you need either its IP address or its local name. Suppose you know the IP address and want to ping the machine 142.12.130.12. The command and output looks like the following:

Again, the ping routine was interrupted after four attempts. You can see the diagnostic messages and summaries as ping sends a request to the remote machine and waits for a reply.

If you don't get anything back from the remote machine, verify that the remote is connected and you are using the proper IP address. If all is well there, check the configuration and route commands. If that checks out, try pinging another machine. If that fails, you can resort to the netstat utility, discussed in more detail in, "Network Utilities."

Local area networks are connected by a gateway. The gateway is one machine that acts as the connection between the two networks, routing data between the two based on the IP address of the destination machine. The simplest use of a gateway is to connect to the rest of the world through the Internet. A machine that connects into the Internet can then connect to any other network on the Internet.

You have to make some changes to the network configuration files whenever your local machine is going to use a gateway, as well as if your machine is going to act as a gateway. To use the services of another machine as a gateway, you have to tell the routing tables about the gateway and the networks it connects to by using the route command

where net_gate is the name of the machine on your local area network that acts as the gateway out. The gateway machine follows the keyword gw in the route command. The use of the word default in the command indicates that the kernel's routing table should assume all networks can be reached through that gateway. (Physically, the default network setting translates to an IP address of 0.0.0.0.)

If you want to configure a gateway to another network, the name of that network should be in the /etc/networks file (see earlier in this chapter for details of the /etc/networks file). For example, if you have a gateway machine called gate_serv that leads from your own local area network to a neighboring network called big_corp (and an entry exists in the /etc/networks file for big_corp with their network IP address), you could configure the routing tables on your local machine to use gate_serv to access big_corp machines with this command:

An entry should be made on the remote network's routing table to reflect your network's address, otherwise you would only be able to send data and not receive it.

If you want to set up your local machine to act as a gateway itself, you need to configure the two network connections that your machine is joining. This usually requires two network boards, PPP connections, or SLIP connections in some combination. Assume your machine is going to act as a simple gateway between two networks called small_net and big_net, and you have two Ethernet cards installed in your machine. You configure both Ethernet interfaces separately with their respective network IP addresses, (For example, your machine many have an IP address on big_net of 163.12.34.36 and have the IP address 147.123.12.1 on small_net.)

Add the two IP addresses to your /etc/hosts file to simplify resolution. For the networks and IP addresses mentioned previously, you will have the following two entries in the /etc/hosts file:

In this case, the fully qualified domain names have been added to the /etc/hosts file (this example assumes the machine has the name merlin on both networks, which is perfectly legal). You can also add shorter forms of the name, as well (such as merlin, merlin.big_net, and so on). Finally, the interface names have been included for convenience (so merlin-iface1 is the first interface on merlin, while merlin-iface2 is the second).

You then use the ifconfig commands to set up the connections between the interface and the names used in the /etc/hosts file:

These commands assume that the Ethernet device /dev/eth0 is for the interface to big_net, and /dev/eth1 is for small_net. Of course, you could have used the IP addresses of the networks instead of the interface name, as you saw earlier in this chapter.

Finally, the kernel routing table must be updated to reflect the two network names. The commands for this example are:

When these steps are completed, you must make sure that IP Forwarding has been enabled in the kernel. You can enable IP Forwarding by rebuilding the kernel. Once the kernel supports IP Forwarding, you can use your machine as a gateway between the two networks. Other machines on either network can also use your machine as a gateway between the two networks.

Although the examples shown here are for Ethernet connections to two networks, you could have any kind of interface. You could, for example, use an Ethernet card for your local area network, and then use a SLIP or PPP connection to another network (including the Internet).

A symbolic name is an alternative to using an IP address. For example, it is much easier to call a neighboring machine darkstar than 147.23.13.32. Whenever a symbolic name is used as an address by an application, the TCP/IP software must be able to resolve that name into a network address (as TCP/IP only uses IP addresses). The ASCII file /etc/hosts is usually employed, with the symbolic names matched to network addresses. (Note that the /etc/hosts file does not apply when Yellow Pages (YP), Network Information Services (NIS), or Domain Name Server (DNS) systems are used. These services use their own configuration files.)

Linux uses the file /etc/hosts to hold the network addresses and symbolic names, as well as a connection called the loopback (which is examined later in this chapter in the section, "Loopback Drivers"). The loopback connection address is usually listed as the machine name loopback or localhost.

The /etc/hosts file consists of the network address in one column and the symbolic name in another. Although the network addresses can be specified in decimal, octal, or hexadecimal format, decimal is the most commonly used form (and use of the others can be downright confusing). You can specify more than one symbolic name on a line by separating the names with white space characters (spaces or tabs). The following is a sample Linux /etc/hosts file:

Whenever a user or an application specifies a symbolic name, Linux searches the /etc/hosts file for a matching name and then reads the proper address from the same line. You can change the contents of the /etc/hosts file at any time, and the changes are essentially in effect immediately.

This file allows networks to be addressed by a symbolic name, just as machines are, instead of by their IP address. To resolve the network names, the file /etc/networks is used to specify symbolic network names. The format of the file provides a network symbolic name, its network address, and any alias that might be used. A sample /etc/networks file is shown below:

The last entry in the file gives the loopback name. The first entry specifies the local machine name, its network address, and its name variants that may be used by applications.

TCP/IP uses a special number, called a protocol number, to identify the specific transport protocol a Linux system receives. This allows the TCP/IP software to properly decode the information coming in. A configuration file called /etc/protocols identifies all the transport protocols available on the Linux and gives their respective protocol numbers. All systems have this file, although some entries may be commented out to prevent unwanted intrusion or abuse.

Usually the /etc/protocols file is not modified by the administrator. Instead, the file is maintained by the networking software and updated automatically as part of the installation procedure. The file contains the protocol name, its number, and any alias that may be used for that protocol. A sample /etc/protocols file is shown below:

The exact contents of the /etc/protocols file on your system may differ a little from the file shown above, but the protocol numbers and names are probably very similar. There may be additional protocols listed, depending on the version of Linux and networking software.

The last TCP/IP configuration file used on most Linux systems identifies existing network services. This file is called /etc/services. As with the /etc/protocols file, this file is not usually modified by an administrator, but is maintained by software when installed or configured. The exception is when the /etc/services file has services missing that the application software did not add automatically. In addition, a system administrator can trim the /etc/services file in order to enhance security, such as when setting up a firewall to the local area network.

The /etc/services file is in ASCII format, and consists of the service name, a port number, and the protocol type. The port number and protocol type are separated by a slash. Any optional service alias names follow. The following is a short extract from a sample /etc/services file (the file is usually quite lengthy):

Most /etc/services files will have many more lines, because a wide number of TCP/IP services are supported by most versions of Linux. Most Linux systems are not used as firewalls to the Internet or between LANs, so administrators of most Linux machines will never have to worry about the contents of this file. On the other hand, if your machine is going to act as a firewall or you are very worried about security, you may want to manually modify the /etc/services file.

When a networked Linux machine is started, it activates TCP/IP and immediately accepts connections at its ports, spawning a process for each. To control the processes better, the inetd program was developed to handle the port connections itself, offloading that task from the server. The primary difference is that inetd creates a process for each connection that is established, whereas the server would create a process for each port (which leads to many unused processes). On many systems, some of the test programs and status information utilities are run through inetd.

The inetd program uses the configuration file /etc/inetd.conf. The following code is an extract of a sample /etc/inetd.conf file. The first column shows the service name (which corresponds to an entry in the services file such as /etc/services), the socket type (stream, raw, or datagram), protocol name, whether inetd can accept further connections at the same port immediately (nowait) or must wait for the server to finish (wait), the login that owns the service, the server program name, and any optional parameters needed for the server program.

The actual /etc/inetd.conf file may be much longer, but the extract above shows the general format of the file. The /etc/inetd.conf file is read when the server is booted and every time a hangup signal is received from an application. This allows dynamic changes to the file, as any modifications would be read and registered on the next file read.

The netstat program provides comprehensive information about the local system and its TCP/IP system. Administrators commonly use this program to quickly diagnose a problem with TCP/IP. Although netstat's format and specific information differ with the version of Linux, netstat usually supplies the following important summaries, each of which is covered in more detail later:

• Communications end points
• Network interface statistics
• Routing table information
• Protocol statistics

With some later versions, information about the interprocess communications and other protocol stacks may be appended as well. The information to be displayed can usually be toggled with a command line option. The following are valid options for most versions of netstat are:

The output from a typical Linux installation that uses the netstat command is shown in the next few sections, which discuss netstat and its output in more detail. As already mentioned, the output and meaning may be different with other versions, but the general purpose of the diagnostic tool remains the same.

The netstat command with no options provides information on all active communications end points. To display information about a particular type of end point, use the letter of the type from the following list:

To display all end points that are waiting for a connection (in addition to the sockets specified by one of the above flags), netstat uses the -a option. The -a option by itself will display all sockets.

The output is formatted into columns showing the protocol (Proto), the amount of data in the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and the current state of the connection. The following is a truncated sample output:

In the preceding sample extract, three TCP connections are active, as identified by the state ESTABL. One has data being sent (as shown in the Send-Q column), while another has incoming data in the queue. The network names and port numbers of the connection ends is shown whenever possible. An asterisk means no end point has yet been associated with that address.

One connection is waiting to be hung up, identified by TIME_WAIT in the state column. After thirty seconds, these sessions are terminated and the connection freed. Any row with LISTEN as the state has no connection at the moment, and is waiting.

You can use the -a option by itself to display a complete list of all connections. The output, which is quite lengthy, looks the same, but includes all connections (active and passive):

The output is similar to that for the -ta options shown previously, except the UDP (User Datagram Protocol) connections have been added. UDP sessions have no state column because they do not have an end-to-end connection.

The behavior of the network interface (such as the network interface card) can be shown by using the -i option to the netstat command. This information quickly shows you whether major problems exist with the network connection.

The netstat -i command displays the name of the interface (Iface), the maximum number of characters a packet can contain (MTU), the metric value (not used with Linux), and a set of columns for the number of packets received without problem (RX-OK), received with errors (RX-ERR), received but dropped (RX-DRP), and received but lost due to overrun (RX-OVR). The transmitted packets have similar columns. The last column contains a list of flags set for the interface. The following is a sample output from a netstat -i command:

This extract shows two interfaces in use: an Ethernet device (/dev/eth0) and the loopback driver (lo0). In this case, you can see the Ethernet interface has had a few bad packet receptions. This is normal because of the nature of the Ethernet system, although if the numbers become too high a percentage of the total packets sent, you should start diagnostic methods to find out why.

You can obtain more specific information about one interface by using the -i option with a device name and a time interval, specified in seconds, such as netstat -i eth0 30, to obtain specific information about the behavior of the "eth0" (Ethernet) interface over the last thirty seconds. For example, the output below shows the activity of the Ethernet interface for the last 30 seconds:

The flags column in the netstat output matches the types of flags you saw with the ifconfig command. The meaning of the flags is shown in the following list:

As you can see in the extracts from the previous commands above, several of the flags can be combined into one block.

Versions of netstat that are based on System V UNIX (instead of BSD UNIX) allow displays of data buffer statistics. Information about the TCP/IP data buffers can be obtained with the netstat command's -m option. Monitoring the behavior of the buffers is important, because they directly impact the performance of TCP/IP. The output of the netstat -m command differs depending on the version of Linux networking software in use, reflecting the different implementations of the TCP/IP code.

The netstat -m command output is shown below. In this version, entries are provided for the streamhead, queue, message descriptor table (mblks), data descriptor table (dblks), and the different classes of data descriptor tables. The columns show the number of blocks currently allocated (alloc), the number of columns free (free), the total number of blocks in use (total), the maximum number of blocks that were in use at one time (max), and the number of times a block was not available (fail).

The failure column is important, and tt should always show zeros. If a larger number appears there, it means that the particular resource in question has been overtaxed and the number of blocks assigned to that resource should be increased (followed by a kernel rebuild and a reboot of the system to effect the changes).

Routing tables are continually updated to reflect connections to other machines. To obtain information about the routing tables, the netstat -r and -rs options are used (the latter generates statistics about the routing tables).

The output from netstat -r and netstat -rs commands are shown below. The columns show the destination machine, the address of the gateway to be used (an asterisk means no gateway to be used), the Genmask which specifies the generality of the route (which IP addresses can be matched to it), a set of flags, a metric value (not used), a reference counter (Refs) that specifies how many active connections may use that route simultaneously, the number of packets that have been sent over the route (Use), and the interface name.

The flags are used to show different characteristics of the route. The following are valid flags:

You can combine the -s and -rs options with the -n option to display the IP addresses of the entries in the routing table, instead of the symbolic name (as shown above). The layout and information displayed by the netstat command will vary depending on the Linux implementations, as in the following example:

This flag saves you from having to figure out the symbolic to IP address translations yourself.

System V-based versions of netstat (as opposed to most Linux BSD-based versions) enable you to display protocol statistics. Statistics about the overall behavior of network protocols can be obtained with the netstat -s command. This usually provides summaries for IP (Internet Protocol), ICMP (Internet Control Message Protocol), TCP (Transmission Control Protocol), and UDP (User Datagram Protocol). The output from this command is useful for determining where an error in a received packet was located, and then leading the user to try to isolate whether that error was due to a software or network problem.

Issuing the netstat -s command provides a verbose output, as shown in the following example:

Again, the exact layout of the output changes depending on the version of the networking code. However, you can use the basic information with all formats.

The arp program manages entries in the system's Address Resolution Protocol (ARP) tables. ARP provides the link between the IP address and the underlying physical address. With arp, you can create, modify, or delete entries in the ARP table. Typically, this will have to be performed whenever a machine's network address changes (either because of a change in the network hardware or because of a physical move).

To use the arp program, you need to follow one of the following formats:

When specifying a hostname you can use either a symbolic name or the IP address.

To display the entry for a host or IP address, use the first format shown above. If you do not give a hostname, all hosts are shown. For example, to check the ARP entry for the remote machine darkstar, issue the following command:

This command shows that the machine darkstar has the IP address 147.12.32.1, and is reached through a 10Mbps Ethernet connection. You can slightly alter the output by using the -t option with a specific type of interface. Valid values are ax25 (AMPR AX.25 networks), ether (10Mbps Ethernet), and pronet (IEEE 802.5 Token Ring). For example, to show all the Ethernet connections only, use the following command:

To add an entry to the ARP tables, use the second format of the command shown earlier, using the -s option. When adding an entry, the hwaddress refers to the hardware address of the adapter (usually six sets of hexadecimal digits separated by colons). For example, to add an entry for the remote system big_cat, you would issue the command

where the hardware address of the network card is as shown.

Finally, the last format of the arp command shown above is used to delete entries from the ARP table. This format may be necessary when you have incorrectly added an entry to the table or the network has changed. To delete the entry for the machine x-wing, issue this command:

Several other options are valid with many versions of arp, but you will probably never have to use the arp command at all (let alone these more obscure options). If you need more information, the man pages include a list of all valid options and their functions.

Most Linux systems have a utility called traceroute available that sends a series of UDP (User Datagram Protocol) datagrams to a target machine. The datagrams are constructed slightly differently depending on their location in the stream sent to the remote machine. The first three datagrams have a field called Time to Live (TTL) set to a value of one, meaning that the first time a router encounters the message it is returned with an expiry message (the datagram has been discarded). The next three messages have the TTL field set to two, three, four, and so on so that each router the messages pass through will return an expiry message until the destination machine is successfully reached.

The traceroute output shows the round trip time of each message (which is useful for identifying bottlenecks in the network) and the efficiency of the routing algorithms (through a number of routers which may not be the best route). The following is sample output from a traceroute command:

This output shows each router the messages were received by until the destination machine was reached. The traceroute command has many options to tailor its behavior, which are all explained in the man page. The traceroute command is usually used by system or network administrators when there are delivery problems with messages or network behavior seems very slow. Because most Linux systems are on small local area networks or are stand-alone, you may never have to use traceroute.

For RPC (Remote Procedure Call) services, a utility called rpcinfo can determine which RPC services are currently active on the local machine or any remote system that supports RPC. The options supported by rpcinfo vary with the implementation, but all implementations allow flags to decide which type of service to check.

For example, the -p option displays the local portmapper. The following example shows the options supported by the Slackware Linux version of rpcinfo, as well as the output for the portmapper:

As with the traceroute command, most system administrators will never need to use rpcinfo. If you are a network programmer or a network administrator, they may be handy utilities to know about, though.

NFS, the network filesystem, is probably the most prominent network services using RPC. It allows to access files on remote hosts in exactly the same way as a user would access any local files. This is made possible by a mixture of kernel functionality on the client side (that uses the remote file system) and an NFS server on the server side (that provides the file data). This file access is completely transparent to the client, and works across a variety of server and host architectures.

NFS offers a number of advantages:

• Data accessed by all users can be kept on a central host, with clients mounting this directory at boot time. For example, you can keep all user accounts on one host, and have all hosts on your network mount /home from that host. If installed alongside with NIS, users can then log into any system, and still work on one set of files.
• Data consuming large amounts of disk space may be kept on a single host. For example, all files and programs relating to LaTeX and METAFONT could be kept and maintained in one place.
• Administrative data may be kept on a single host. No need to use rcp anymore to install the same stupid file on 20 different machines.

If you want to provide NFS service to other hosts, you have to run the nfsd and mountd daemons on your machine. As RPC-based programs, they are not managed by inetd, but are started up at boot time, and register themselves with the portmapper. Therefore, you have to make sure to start them only after rpc.portmap is running. Usually, you include the following two lines in your rc.inet2 script:

The ownership information of files a NFS daemon provides to its clients usually contains only numerical user and group id's. If both client and server associate the same user and group names with these numerical id's, they are said to share the same uid/gid space. For example, this is the case when you use NIS to distribute the passwd information to all hosts on your LAN.

While the above options applied to the client's NFS configuration, there is a different set of options on the server side that configure its per-client behavior. These options must be set in the /etc/exports file.

By default, mountd will not allow anyone to mount directories from the local host, which is a rather sensible attitude. To permit one or more hosts to NFS-mount a directory, it must exported, that is, must be specified in the exports file. A sample file may look like this:

Each line defines a directory, and the hosts allowed to mount it. A host name is usually a fully qualified domain name, but may additionally contain the * and ? wildcard, which act the way they do with the Bourne shell. For instance, lab*.foo.com matches lab01.foo.com as well as laber.foo.com. If no host name is given, as with the /home/ftp directory in the example above, any host is allowed to mount this directory.

When checking a client host against the exports file, mountd will look up the client's hostname using the gethostbyaddr(2) call. With DNS, this call returns the client's canonical hostname, so you must make sure not to use aliases in exports. Without using DNS, the returned name is the first hostname found in the hosts file that matches the client's address.

The host name is followed by an optional, comma-separated list of flags, enclosed in brackets. These flags may take the following values:

insecure

Permit non-authenticated access from this machine.

unix-rpc

Require UNIX-domain RPC authentication from this machine. This simply requires that requests originate from a reserved internet port (i.e. the port number has to be less than 1024). This option is on by default.

secure-rpc

Require secure RPC authentication from this machine. This has not been implemented yet. See Sun's documentation on Secure RPC.

kerberos

Require Kerberos authentication on accesses from this machine. This has not been implemented yet. See the MIT documentation on the Kerberos authentication system.

root squash

This is a security feature that denies the super user on the specified hosts any special access rights by mapping requests from uid 0 on the client to uid 65534 (-2) on the server. This uid should be associated with the user nobody.

no root squash

Don't map requests from uid 0. This option is on by default.

ro

Mount file hierarchy read-only. This option is on by default.

rw

Mount file hierarchy read-write.

link relative

Convert absolute symbolic links (where the link contents start with a slash) into relative links by prepending the nec- essary number of ../'s to get from the directory containing the link to the root on the server. This option only makes sense when a host's entire file system is mounted, else some of the links might point to nowhere, or even worse, files they were never meant to point to.

This option is on by default.

link absolute

Leave all symbolic link as they are (the normal behavior for Sun-supplied NFS servers).

map daemon

This option tells the NFS server to assume that client and server do not share the same uid/gid space. nfsd will then build a list mapping id's between client and server by query- ing the client's ugidd daemon.

An error parsing the exports file is reported to syslogd's daemon facility at level notice whenever nfsd or mountd is started up.

Note that host names are obtained from the client's IP-address by reverse mapping, so you have to have the resolver configured properly. If you use BIND and are very security-conscious, you should enable spoof checking in your host.conf file.

NFS volumes are mounted very much the way usual file systems are mounted. You invoke mount using the following syntax:

nfs_volume is given as remote_host:remote_dir. Since this notation is unique to NFS file systems, you can leave out the -t nfs option.

There are a number of additional options that you may specify to mount upon mounting an NFS volume. These may either be given following the -o switch on the command line, or in the options field of the /etc/fstab entry for the volume. In both cases, multiple options are separated from each other by commas. Options specified on the command line always override those given in the fstab file.

A sample entry in /etc/fstab might be

This volume may then be mounted using

In the absence of a fstab entry, NFS mount invocations look a lot uglier. For instance, suppose you mount your users' home directories from a machine named moonshot, which uses a default block size of 4K for read/write operations. You might decrease block size to 2K to suit ' datagram size limit by issuing

The following is an incomplete list of option those you would probably want to use:

rsize=n and wsize=n
These specify the datagram size used by the NFS clients on read and write requests, respectively. They cur- rently default to 1024 bytes, due to the limit on UDP datagram size described above.

timeo=n
This sets the time (in tenths of a second) the NFS client will wait for a request to complete. The default values is 0.7 sec- onds.

hard
Explicitly mark this volume as hard-mounted. This is on by default.

soft
Soft-mount the driver (as opposed to hard-mount).

intr
Allow signals to interrupt an NFS call. Useful for aborting when the server doesn't respond.

Except for rsize and wsize, all of these options apply to the client's behavior if the server should become inaccessible temporarily. They play together in the following way: whenever the client sends a request to the NFS server, it expects the operation to have finished after a given interval (specified in the timeout option). If no confirmation is received within this time, a so-called minor timeout occurs, and the operation is retried with the timeout interval doubled. After reaching a maximum timeout of 60 seconds, a major timeout occurs.

By default, a major timeout will cause the client to print a message to the console and start all over again, this time with an initial timeout interval twice that of the previous cascade. Potentially, this may go on forever. Volumes that stubbornly retry an operation until the server becomes available again are called hard-mounted. The opposite variety, soft-mounted volumes gerenates an I/O error for the calling process whenever a major timeout occurs. Because of the write-behind introduced by the buffer cache, this error condition is not propagated to the process itself before it calls the write(2) function the next time, so a program can never be sure that a write operation to a soft-mounted volume has succeeded at all.

Whether you hard- or soft-mount a volume is not simply a question of taste, but also has to do with what sort of information you want to access from this volume. For example, if you mount your X-programs by NFS, you certainly would not want your X-session to go berserk just because someone brought the network to a grinding halt by firing up seven copies of xv at the same time, or by pulling the Ethernet plug for a moment. By hard-mounting these, you make sure that your computer will wait until it is able to re-establish contact with your NFS-server. On the other hand, non-critical data such as NFS-mounted news partitions or FTP archives may as well be soft-mounted, so it doesn't hang your session in case the remote machine should be temporarily unreachable, or down. If your network connection to the server is flaky or goes through a loaded router, you may either increase the initial timeout using the timeo option, or hard-mount the volumes, but allow for signals interrupting the NFS call so that you may still abort any hanging file access.

Usually, the mountd daemon will in some way or other keep track of which directories have been mounted by what hosts. This information can be displayed using the showmount program, which is also included in the NFS server package. The mountd, however, does not do this yet.

1. Click on the button.
2. Click on and then open Windows NT Explorer.
3. Select the Folder or File you wish to Share using the LEFT mouse button.
4. Then click the RIGHT mouse button to bring up this menu:
5. Choose Sharing... as indicated in the above step.
6. You should now see this box:



7. Make sure the Shared As radio button is selected. You can now enter a Share Name for your folder and set a maximum number of users.
8. In this window you need to put the names of any users or groups to who you want to give permission to use your folder or file. Click on the Add button to bring up the Add Users and Groups window.



10. Next click the Permissions button to specify who you want to share the file with. It will bring up the following window:



11. Click the Show Users button to view all users in your list. Then use the Add button to add the names of users and groups you wish to make the folder available to.
12. **Note: If you do not have any users or groups to add, you must first create them. Please refer to the Create New Users documentation.
13. By selecting a user or groups name in the Add Names box, you can then choose the Type of Access they will have from the drop down list.



14. Now click the OK button to return to the previous window.
15. You should now see the names of the users and groups that you chose in this window. You can also change the Type of Access users and groups have in this window.
16. If you want to block a certain user or group access to your folder or file, simly select their name and choose No Access from the drop down list. This person can no longer share your folder or file.
17. Click OK to save these new options and to close any windows that are still open.

There are four basic things that one can do with Samba:

1. Share a Linux drive with Windows machines.
2. Access an SMB share with Linux machines.
3. Share a Linux printer with Windows machines.
4. Share a Windows printer with Linux machines.

The following two daemons are required for the Samba package. They are typically installed in /usr/sbin and run either on boot from the systems startup scripts or from inetd.

The two SMB daemons are /usr/sbin/smbd and /usr/sbin/nmbd. Under most Linux distributions, these are started, stoped and restarted via the startup script located in /etc/rc.d/init.d/smb and symlinked to the appropriate runlevels.

If you choose not to use the standard startup script, you can run the Samba daemons from inetd or as stand-alone processes. Samba will respond slightly faster as a standalone daemon than running from inetd.

In either case, you should check the file /etc/services for lines that look like this:

Make sure they are all uncommented. Depending on your distribution, you may even need to add them. Samba will not be able to bind to the appropriate ports unless /etc/services has these entries.

Samba configuration on a Linux (or other UNIX machine) is controlled by a single file, /etc/smb.conf. This file determines which system resources you want to share with the outside world and what restrictions you wish to place on them.

Since the following sections will address sharing Linux drives and printers with Windows machines, the smb.conf file shown in this section is as simple as you can get, just for introductory purposes.

Each section of the file starts with a section header such as [global], [homes], [printers], etc.

The [global] section defines a few variables that Samba will use to define sharing for all resources.

The [homes] section allows a remote users to access their (and only their) home directory on the local (Linux) machine). That is, users trying to connect to this share from Windows machines, will be connected to their personal home directories. Note that to do this, they must have an account on the Linux box.

The sample smb.conf file below allows remote users to get to their home directories on the local machine and to write to a temporary directory. For a Windows user to see these shares, the Linux box has to be on the local network. Then the user simply connects a network drive from the Windows File Manager or Windows Explorer.

As shown in the simple smb.conf above, sharing Linux drives with Windows users is easy. However, like everything else with Samba, you can control things to a large degree. Here are some examples:

To share a directory with the public, create a clone of the [tmp] section above by adding something like this to smb.conf:

To make the above directory readable by the public, but only writable by people in group staff, modify the entry like this:

It used to be that easy; you would now be able to start Samba and browse the shares from a Windows PC. However, Microsoft has recently made life slightly more difficult for those using Samba. Windows 98, Windows NT (service pack 3 or higher) and later builds of Windows 95 now use encrypted passwords by default. Samba uses unencrypted passwords by default. You can't browse servers when either the client or server is using encrypted passwords, because a connection cannot be made anonymously.

You can tell if you have a password type mismatch between client and server if when you try to connect to a share you see a dialog box which reads something like "You are not authorized to access that account from this machine".

You can either configure your Samba server to use encrypted passwords, or configure the Windows machines to use unencrypted passwords.

To get Windows to work with encrypted SMB passwords:

Windows 95/98 =============

Using the registry editor (regedit), create the registry setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP Add a new DWORD value: Value Name: EnablePlainTextPassword Data: 0x01.

Windows NT ==========

Using the registry editor (regedit), create the registry setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters Add a new DWORD value: Value Name: EnablePlainTextPassword Data: 0x01

Windows 2000 ============

Using the registry editor (regedit), create the registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters Add a new DWORD value: Value Name: EnablePlainTextPassword Data: 0x01

Once these registry changes have been made, reboot the Windows machine and try to map a network drive on the Samba server again. It should work as long as the Samba server is using plain text passwords.

To configure Samba to use encrypted passwords:

In the [global] section of /etc/smb.conf, add the following lines:

If your clients and server are using encrypted passwords, you will not be able to browse the available shares on the server until an initial connection has been made with the appropriate authentication. To get the initial connection, enter the share name manually in the Windows File Manager or Explorer dialog box, in the form '\\<hostname>\<sharename>'. Log onto the server with a username and password that is valid on the server!

If you suspect that your NetBIOS name service is not correctly configured (perhaps because you get 'host not found' errors when trying to connect), try using just the IP address of the server: '\\<host ip address>\<sharename>'.

In order to get filenames to appear correctly, you may also need to set some options in the appropriate share section. These work for Windows 95/98/NT clients, but may need to be modified if you have Windows 3.X clients:

Linux (UNIX) machines can also browse and mount SMB shares. Note that this can be done whether the server is a Windows machine or a Samba server!

An SMB client program for UNIX machines is included with the Samba distribution. It provides an ftp-like interface on the command line. You can use this utility to transfer files between a Windows 'server' and a Linux client.

Most Linux distributions also now include the useful smbfs package, which allows one to mount and umount SMB shares. More on smbfs below.

To see which shares are available on a given host, run:

where 'host' is the name of the machine that you wish to view. this will return a list of 'service' names - that is, names of drives or printers that it can share with you. Unless the SMB server has no security configured, it will ask you for a password. Get it the password for the 'guest' account or for your personal account on that machine.

For example:

The output of this command should look something like this:

The browse list shows other SMB servers with resources to share on the network.

To use the client, run:

where 'service' is a machine and share name. For example, if you are trying to reach a directory that has been shared as 'public' on a machine called zimmerman, the service would be called \\zimmerman\public. However, due to shell restrictions, you will need to escape the backslashes, so you end up with something like this:

where 'mypasswd' is the literal string of your password.

You will get the smbclient prompt:

Type 'h' to get help using smbclient:

If you can use ftp, you shouldn't need the man pages for smbclient.

Although you can use smbclient for testing, you will soon tire of it for real work. For that you will probably want to use the smbfs package. Smbfs comes with two simple utilties, smbmount and smbumount. They work just like mount and umount for SMB shares.

One important thing to note: You must have smbfs support compiled into your kernel to use these utilities!

The following shows a typical use of smbmount to mount an SMB share called "customers" from a machine called "samba1":

Issuing a mount command will now show the share mounted, just as if it were an NFS export:

A caching only name server will find the answer to name queries and remember the answer the next time you need it. This will shorten the waiting time the next time significantly, especially if you're on a slow connection.

This is read when named starts. For now it should simply contain:

The file describes the root name servers in the world. The servers change over time and must be maintained now and then.

nameserver 127.0.0.1

This `zone file' contains 3 `resource records' (RRs): A SOA RR. A NS RR and a PTR RR. SOA is short for Start Of Authority. The `@' is a special notation meaning the origin, and since the `domain' column for this file says 0.0.127.in-addr.arpa the first line really means

NS is the Name Server RR. There is no '@' at the start of this line; it is implicit since the previous line started with a '@'. Saves some typing that. So the NS line could also be written

Upon careful examination you will discover a bug. The line

is all wrong. It should be

I deliberately made a mistake so you could learn from it :-) Looking in the zone file we find this line:

MX 10 mail.linux.bogus. ; Primary Mail Exchanger

or

MX 10 mail ; Primary Mail Exchanger

So having made my point here is the new zone file, with some extra information in it as well:

There are a number of new RRs here: HINFO (Host INFOrmation) has two parts; it's a good habit to quote each. The first part is the hardware or CPU on the machine, and the second part the software or OS on the machine. The machine called 'ns' has a Pentium CPU and runs Linux 2.0. CNAME (Canonical NAME) is a way to give each machine several names. So www is an alias for ns.

CNAME record usage is a bit controversial. But it's safe to follow the rule that a MX, CNAME or SOA record should never refer to a CNAME record, they should only refer to something with an A record, so it is inadvisable to have

but correct to have

Now we're halfway.

Now programs can convert the names in linux.bogus to addresses which they can connect to. But also required is a reverse zone, one making DNS able to convert from an address to a name. This name is used by a lot of servers of different kinds (FTP, IRC, WWW and others) to decide if they want to talk to you or not, and if so, maybe even how much priority you should be given. For full access to all services on the Internet a reverse zone is required.

so, it looks OK, dump the whole thing to examine that too:

Installing the DNS Service

Verify DNS information in Windows NT

Before installing the actual Microsoft DNS service, it is important that the Windows NT Server 4.0 server's TCP/IP stack is configured correctly. In particular, the DNS section needs to be verified, because the DNS service gets many of its default settings from this section during setup.

To verify this information, run Control Panel and go into Network. Click the Protocols tab. Pull up the properties dialog box for the TCP/IP Protocol and click the DNS tab. Verify that you have a correct Host Name and Domain filled in on this screen.

Note If the domain name and host name are supplied in the network control panel setup when you create a zone, DNS will add SOA, A, and NS records to the database. If the information is not configured, only the SOA record is created.

To install the Microsoft DNS Service on a Windows NT 4.0-based system, run the Control Panel and go into Network. Click the Services tab, then click the Add button. Highlight Microsoft DNS Server and click OK.

At this point, a default installation of Microsoft DNS server service will be installed on the Windows NT-based server. This installation will install files in your \<SystemRoot>\system32\Dns directory as shown. At this point, you will be prompted to restart your server.

To configure the DNS server, run the DNS Manager under the Administrative Tools. Initially, the DNS Manager will not have any servers in its list. To add the local server, pull down the DNS menu and click New Server. Fill in the name of your local server and click OK. The server will then show up in the Server List. Double-click the server to see the server statistics and zones that have been defined.

Since the DNS server initially has no information about your specific network, the DNS server service installs as a caching-only name server for the Internet. This means that DNS only contains information on the Internet root servers. For most DNS configurations, additional information must be supplied to obtain the desired operation.

The first step in configuring the DNS server is to determine the hierarchy for your DNS domains and zones. Design considerations for a DNS hierarchy are discussed in the next section of this paper. Once the domain and zone information have been determined, the information must be entered into the DNS configuration using the DNS Manager.

Since DNS information is grouped and controlled by zones, a zone must first be created. To do this, click the server name with the alternate mouse button and then click New Zone.

Note If you double-click the CACHE zone, you can see all of the hosts that the DNS server has statically defined and dynamically cached due to a previous query. The CACHE will also show all of the WINS entries that have been resolved and have not elapsed their WINS-specific Cache Time-out Value.

At this point, a dialog is presented that asks if the zone you are creating is a primary zone (information stored locally) or a secondary zone (information obtained from a master server by a zone transfer). If it is a primary zone, no additional information is needed at this step. If it is a secondary zone, you must also enter the zone and master server names in this screen.

The next step is to fill in the zone name and zone file information for the local server. This will determine how the zone shows up in the DNS Manager and what file name it is stored under. If this is a secondary zone, this zone name should match the master server zone name. If this zone file already exists in the DNS directory, DNS will import these records automatically when this zone is created.

If this is a secondary zone, you would then be asked to enter the IP address of the master name servers (the name servers with which you will do zone transfers for this zone).

Once all this information is entered, the zone will be added to the DNS hierarchy. If you have additional zones that need to be added, follow the same procedure for each zone. Once all zones have been added to the server, you should then add any DNS subdomains under the zones that your hierarchy might contain. To do this, click the appropriate zone with the alternate mouse button and click New Domain.

Enter the name of the new subdomain in the dialog box and click OK. If multiple levels of subdomains are needed, create each successive subdomain by clicking the immediate parent with the alternate mouse button, clicking New Domain, and entering the name of the new subdomain.

This process can also be used for adding new host or resource records at any domain location within the DNS hierarchy.

There are three main parts of the Unix E-mail system:

The MTA is the most important one of these. It is responsible for doing all the "intelligent" work of e-mail transfer. While it does not actually perform any of the delivery itself, it is the part which tells the other parts how to interact and what to do. In a sense, the MTA is the glue which holds the whole process together.

Email messages are compose of two parts:

1. Headers (lines of the form "field: value" which contain information about the message, such as "To:", "From:", "Date:", and "Message-ID:")
2. Body (the text of the message)

Example:

What does the configuration file do?

• General configuration options, such as queue directory and timeout values
• Definitions for each MDA, including pathnames and options
• Rulesets for header processing/rewriting, and the "routing table" which determines which MDAs get used for which messages

This information can actually be quite complex, especially for a large mail hub.