Home  
  CompTIA  
  Practice Exams  
  TechNotes  
  - A+ Core -  
  - A+ OS -  
  - Network+ -  
  - Security+ -  
  - Linux+ -  
  Links  
  Forums  
  Blogs  
  Topsites  
  Search the Web  
  Watch free videos online  
     
  Subnet Calculator  
  Online Degrees  
  Exam Vouchers  
  Free Magazines  

   
Linux+ TechNotes
Network Services

Index
DNS
FTP
Apache
Sendmail
SAMBA
DHCP

DNS

To allow clients and servers to resolve hostnames to IP addresses, you should use the Domain Name Service (DNS) . In Linux this is implemented with BIND, the Berkeley Internet Name Domain software. Configuration steps must be taken on both the client and server computers. The server side runs a daemon process called named, while the client side simply runs a resolver that sends requests to the server called queries.

Configuring Client DNS: The Resolver

The client resolver is configured through the /etc/resolv.conf file. Linux reads this file every time it needs to resolve an address, so any changes made to it take effect immediately without having to restart any services. One note to keep in mind, however, is that if the client is using DHCP to obtain an IP address it will overwrite any changes made to the resolv.conf file by default and replace it with the DHCP supplied information. DHCP will be covered later on in these TechNotes.

The resolv.conf file contains information about what name servers to use, domain names, and a search order list of domains to use for resolution. A sample resolv.conf file might look something like this:

[mark@solomon etc]$ more resolv.conf

nameserver 192.168.3.1
domain somedomain.com

Another file used to resolve names to ip addresses is the /etc/hosts file. This is simply a text file that contains host name-to-ip address mappings, one per line. This file can also be edited using a simple text editor like gedit or vi. A simple hosts file could look like this:

[mark@solomon etc]$ more hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 solomon localhost.localdomain localhost
192.168.3.2 jerusalem
192.168.3.5 elijah

The next piece to the puzzle is how Linux knows what to check. Does it check the hosts file, the resolv.conf file or query the name server first? The answer is in the /etc/nsswitch.conf file. This file contains information regarding many types of lookups, including DNS resolution. The portion of the nsswitch.conf file that relates to DNS is a line called hosts, which is shown below:

#hosts: db files nisplus nis dns
hosts: files dns

The line with the # symbol is a comment line. The next line shows that when name resolution is necessary, Linux will first check the /etc/hosts file and then DNS will be used, querying the /etc/resolv.conf file.

Obviously, in a large environment the use of a hosts file might be difficult to maintain. Using DHCP to update client resolv.conf files which point to local DNS servers is the best option in most cases.

Configuring DNS Servers

Linux supports three types of name server configurations:

  • Primary (or authoritative) – is the main server for a DNS domain.
  • Secondary (also considered authoritative) – shares the workload and provides backup for the primary server.
  • Caching (non-authoritative) – does not contain configuration files for any particular domain, but remembers answers to previous queries and supplies that information to requests by clients.

In this document we will provide the steps necessary to set up a Primary DNS server. The first step is to make sure BIND is installed. This can be done on Red Hat and Fedora systems with the following command:

[mark@solomon etc]$ rpm -q bind (or use dpkg –l bind on Debian based distros)
bind-9.2.3-13

This tells you BIND version 9.2.3-13 is indeed installed. If it is not installed you need to insert your installation CD (or download BIND) and run the following command as root:

rpm –ivh bind-9.2.3-13.i386.rpm (or dpkg –i bind-9.2.3-13.i386.deb on Debian based distros)

Once you know you have BIND installed, you will need to make sure it is running when you are ready. You can check to see if the process named is running:

[mark@solomon etc]$ ps -A | grep named

If the command returns any output it is already running. If not, you can start it with the following command when you are ready:

[mark@solomon etc]$ cd /etc/rc.d/init.d
[mark@solomon init.d]$ ./named start

The next thing you need to do is configure a basic /etc/named.conf file. This is a somewhat complicated looking file that defines basic parameters and points to the sources of domain database information. The two main configuration statements used in this file are options and zone. It should be edited to look something like this:

options { directory “/var/named”; };
zone “.” in {type hint; file “named.ca”;};

The options statement here defines the working directory for the server. The zone statement defines the zone(s) serviced by the name server, the type of name server for the zone, and the source of the domain information for the zone. In the example above we can see that for the “.” (or root) zone this server gets it’s information from the file named.ca, which lists all the top level domain servers. Now let’s add a line to configure this server to be a primary for the domain somedomain.com:

options { directory “/var/named”; };
zone “.” in {type hint; file “named.ca”;};
zone “somedomain.com” {type master; file “somedomain.hosts”;};

Since we told the /etc/named.conf file that we are a primary server for somedomain.com and also told it that there is a file called somedomain.hosts where information about that zone is stored, we need to go ahead and create the somedomain.hosts file. If this were a secondary server we were setting up, the zone file would be automatically created by named. To create this file we can fire up our favorite text editor and get started. Our file could look like this (I have commented the file liberally to explain the functions of each section):

$TTL 1d

; semicolons are comment characters
; the $TTL above sets the default time-to-live for the entire zone file to 1 day, which is standard

@ IN SOA solomon.somedomain.com. mark.solomon.somedomain.com. 20050921 (21600 1800 4w 1h )

; the @ symbol is a variable representing the domain
; this file is for
; SOA is the Start of Authority
; solomon is the name of the master server for this zone
; note that the above entry required a trailing period “.”
; mark is the email of the responsible person for
; administering the zone
; the @ symbol in the email must be replaced with a “dot”
; 20050921 is a serial number which must be
; incremented whenever the zone file changes
; this tells secondary servers to update their
; zone file, a date format is standard
; the parenthesis character tells the file to continue
; reading information until it encounters the next
; parenthesis as if it was all one line.

; 21600 is the refresh
; 1800 is the retry interval
; 4w is the expiration
; 1h is the negative cache ttl

; listed name servers
IN NS solomon.somedomain.com.
IN NS moses.somedomain.com.

; listed the mail server (mail exchange record)
IN MX elijah.somedomain.com.

; listed host records
angel IN A 192.168.3.50
matthew IN A 192.168.3.51
mark IN A 192.168.3.52
luke IN A 192.168.3.53
john IN A 192.168.3.54

This was a simple zone file record. We could also have included alias records if we needed to. These would have used the CNAME type.

The last thing we really should do is to create a reverse zone file. This file would map ip addresses to host names, rather than host names to ip addresses. Like a standard zone file, the reverse zone file begins with an SOA and some name server (NS) records. The rest of the zone file will normally be taken up by PTR records. These records start with a number, which references the last portion of the octet in its ip address. Following are some examples of PTR records in a reverse zone file:

50 IN PTR angel.somedomain.com.
51 IN PTR matthew.somedomain.com
52 IN PTR mark.somedomain.com

The list would continue to include as many hosts as you wanted to provide reverse lookups. The zone itself would have to be added to the /etc/named.conf file as follows:

zone “3.168.192.in-addr.arpa” { type master; file “192.168.3.rev.zone”;};

After completing the steps above you should have successfully configured both your client and server for DNS.

Creating DNS Forwarders

In many cases it is useful to set up DNS “forwarders” which are used when your local DNS server does not know the answer to a client query. In normal circumstances this would cause the DNS server in question to use it’s root hints to query all the way to the TLD (Top Level Domain or root server) for a request, which then would submit recursive queries down through the system until the request could be resolved. This could take a long time (in computer time that is) and unnecessarily bog down a small server The answer then would be to point to another DNS server upstream that could handle the query on behalf of the local DNS server. An upstream server (such as your ISP’s DNS server) may actually already have that information cached and could quickly return an answer.

In order to set up a forwarder, we need to go back into our named.conf file. As we have previously stated, this is a file that defines basic parameters and points to the sources of domain database information. Here is a snippet of our /etc/named.conf file we worked with earlier:

options { directory “/var/named”; };
zone “.” in {type hint; file “named.ca”;};
zone “somedomain.com” {type master; file “somedomain.hosts”;};

Now we need to edit the file to include information about the forwarder we want to use. Let’s say that we want to add otherdomain.net name servers located at 192.168.33.5 and 192.168.33.6 as forwarders. Using a text editor we need to add the following:

forwarders { 192.168.33.5; 192.168.33.6;};

Now when a client performs a query, if the DNS server knows the ip address (or domain name if it was a reverse lookup) it will return that information to the client. If it does not know the answer, however, rather than performing a recursive query to the root server it will simply forward the request to one of the forwarders listed. That server will in turn provide the answer either from it’s own cache, another forwarder, or by recursion.

FTP Server

The File Transfer Protocol is one of the most widely used protocols in use today. It is used to transfer files from one computer to another across a LAN or WAN. Red Hat and Fedora use vsftp (Very Secure FTP) by default rather than the more common wu-ftp (Washington University FTP). In this section we will walk through the process of setting up a working FTP server on a Fedora system.

Installing FTP Server

Many Linux systems ship with FTP installed by default. There are a couple of ways you can check to see if FTP is currently installed and running on your system. One way is to try the following command:

ftp localhost

If FTP is running you should be prompted to enter a user name to log on. If it is not running you will probably see a “connection refused” message. Simply typing bye will return you to a command prompt. You could also use the command:

rpm –qa | grep ftp (or use dpkg –l ftp on Debian based distros)

If this returns vsftp followed by a version number then you already have it installed. You will also probably see a couple of FTP client programs installed such as gftp and ftp. If vsftp is not installed, you can either download it or insert your Fedora Core installation CD and type:

rpm –ivh vsftp*.rpm (or dpkg –I vsftp*.deb on a Debian based distro)

To start the vsftp server we use the service command, as follows:

service vsftpd start

This is different from wu-ftp which uses the /etc/xinitd.conf file managed by the xinitd “super server”. This is the process that normally listens for connections and controls network services such as telnet, ftp, and others. Previous versions of Red Hat also required you to edit a file /etc/xinitd.d/vsftpd. Most other FTP servers also use xinitd as well. However, with Fedora you can simply use the service command.

Configuring FTP Server

The main configuration file for vsftpd is /etc/vsftpd.conf. The format of the vsftpd.conf file is very simple. Each line is either a comment or a directive. Comment lines start with a # and are ignored. A directive line has the format:

option=value

Note that there should not be a space between the option=value directive. Each setting has a default value, which may be modified, in the configuration file. Most of the values can be left in their default state, but in our case we will make a couple of modifications. Anonymous access is enabled by default, and we will leave that as-is. One nice thing about the default state of vsftp is that although anonymous access is enabled, it is read only access and users cannot upload files, create new directories, rename or delete files.

By default local users with legitimate accounts on the server are not allowed to log in and access their home directories. While we do want to enable users to log in, we don’t want them to use their normal accounts for this purpose because of the inherent security risks involved – that is passing user names and passwords in clear text. We should make sure this is disabled (which is suppposed to be the default setting) by checking to make sure the line in the /etc/vsftpd.conf file exists that reads:

local_enable=no

Now since we have denied access by local users to FTP to their home directories, we can instead create a list of users that are allowed access. This list is by default called /etc/vsftfd.chroot_list. Once we have created this list, we need to edit the appropriate line in the /etc/vsftpd.conf file as follows:

chroot_list_enable=yes

After making these changes we simply stop and restart our vsftpd process:

service vsftpd stop
service vsftpd start

This concludes a basic setup of the Very Secure FTP server. We have learned how to check to see if it was installed, install it if necessary, and start the server. We then found out that many of the default settings were already configured to match our needs. Those that weren’t can be changed by editing the /etc/vsftpd.conf file. We then were able to restart the vsftpd using the service command. More information can easily be obtained from the http://vsftpd.beasts.org website.

Apache

In this section we will discuss how to set up the Apache web server on our Linux system. Apache is the world’s most popular web server today and is included by default in almost all Linux and Unix distributions. In fact, there is even a version of Apache available for Windows.

Installing Apache

The first thing we need to do is see if we currently have Apache installed on our system. We can check in several ways, one possibility is as follows:

rpm –q apache (as stated in other cases use dpkg –l apache on a Debian system)

If it returns apache followed by a version number, you are good to go. Otherwise we need to either download it or install from the Fedora installation CD:

rpm –ivh apache*.i386.rpm (or dpkg –I apache*.i386.deb for Debian distros)

Next we want to start Apache, which is actually httpd. We can start and stop it using the scripts in /etc/rc.d/init.d like this:
/etc/rc.d/init.d/httpd start

Or by using the service command: service httpd start

Configuring Apache

Apache configuration is done through a set of configuration files, which are located in different directories depending on the system. On our Fedora Core 2 system they are located in the /etc/httpd/conf directory, which is fairly typical on other systems as well. The main configuration file is the httpd.conf file. While the file is too large (with all the comments) to list here, some of the more important lines contain the following information:

DocumentRoot “/var/www/html/somedomain”
ServerName www.somedomain.com

This is what tells Apache where the web pages are stored and what domain the server is hosting. In our case, we are hosting the www.somedomain.com domain, and it’s web pages will be stored in the /var/www/html/somedomain directory. We simply need to place all of our web pages in that directory and they will then be available to display. Most of the other defaults in the http.conf file work just fine as-is.

IP Virtual Host

Although Apache does support name based virtual hosting, and it is a simple matter of editing the /etc/httpd/conf/httpd.conf file and using the NameVirtualHost line to enter the appropriate information, we are going to set up an IP based virtual host for this exercise. The first thing we should do is add an additional ip address to our server. The Apache server can be configured with a virtual IP address by creating an ifcfg-eth0:1 file. We also need to add a new DNS zone that will resolve our additional website to this ip address. If you recall from our previous section on DNS we would need to edit the /etc/named.conf file. Let’s look at how it should look to add the otherdomain.net zone, so we can host a www.otherdomain.net web site:

options { directory “/var/named”; };
zone “.” in {type hint; file “named.ca”;};
zone “somedomain.com” {type master; file “somedomain.hosts”;};
zone “otherdomain.net” {type master; file “otherdomain.hosts”;};

And of course we then create our otherdomain.hosts file with the necessary information to resolve www.otherdomain.net to the newly assigned ip address of our Apache server. All that’s left to do is to modify our /etc/httpd/conf/httpd.conf file as necessary to include:

NameVirtualHost 192.168.33.3
<VirtualHost 192.168.33.3>
ServerName www.otherdomain.net
DocumentRoot /var/www/html/otherdomain

This should conclude the basic information necessary to run our web sites using Apache. One final note, Fedora Core includes a very simple graphical utility to set up a basic web server on your system. It is called system-config-httpd. While we will not discuss its usage (which is very simple and intuitive), a screenshot appears here for the curious:

Sendmail

Now that we have set up DNS, FTP, and Apache, let’s see how we can round out our server to also act as a Mail Server. Sendmail is a very popular open source mail server and is in use by large and small organizations across the globe. It is included by default in most Linux and Unix distributions. Sendmail is a mail transfer agent (MTA) and uses the Simple Mail Transfer protocol (SMTP) to deliver mail. We already have an MX record created for elijah.somedomain.com so let’s use that in our example.

Installing Sendmail

More than likely, sendmail is already installed on your system, but to find out for sure type:

rpm –q sendmail (dpkg –l sendmail for Debian)

And if for some reason it is not installed, we will of course download or use our installation CD to install it:

rpm –ivh sendmail*.i386.rpm (and dpkg –i sendmail*.i386.deb for Debian)

In addition, if we want this system to receive mail (a likely scenario) we need to verify that IMAP4 or POP3 is installed. We can use something similar to this:

rpm –qa | grep pop3
rpm –qa | grep imap

Substitute the appropriate dpkg command if you are using a Debian based distribution. Installation would be the same as in previous examples.

To start (or stop) the sendmail daemon use either of the following commands:
/etc/rc.d/init.d/sendmail start
/etc/rc.d/init.d/sendmail stop

Configuring Sendmail

Since we have already covered the DNS MX record in a previous exercise, let’s move right into the actual Sendmail configuration. Sendmail uses a file called /etc/sendmail.cf that is notoriously cryptic to read let alone edit. Instead, we will do our configuration settings in /etc/mail/sendmail.mc and then run it through the “m4” processor which will create a new sendmail.cf file for us. The lines we need to edit in order to get our mail server running the way we want are as follows:

OSTYPE (`linux’)
MAILER (`smtp’)
MASQUERADE_AS (`somedomain.com’)
FEATURE (`always_add_domain’)

We can leave the rest of the file in its default state for now. Once we have made our changes, we need to run it through the m4 processor:

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

Now restart the Sendmail daemon for the changes to take effect:

/etc/rc.d/init.d/sendmail restart

Aliases

The next item on our list is setting up aliases. This allows us to create several different email addresses for the same mailbox, and is also how we create mailing lists. We simply enter the alias followed by a colon, then the address. The address can be a user, alias, file, or list of users. Let’s create a few:

joes: joe
joe.schmoe: joe
sallys: sally
sally.schmoe: sally
suzys: suzy
suzy.schmoe: suzy
moes: moe
moe.schmoe: moe
schmoe: joe, sally, suzy, moe
theschmoes: schmoe

Now that we have created our email aliases, we need to tell Sendmail about it. This is done with the following command:

newaliases

Okay, so far we have installed and started Sendmail. We have configured Sendmail. We have even created our aliases and a mailing list. What next? Now we have to tell Sendmail who can use it to relay mail to external addresses. By default it will only send mail (relay) for someone sitting at the server. We want it to send mail for anyone in our organization that has an account on the mail server, whether they are on the server or their own workstation. To do this we need to edit a file /etc/mail/access. This file can contain domain names, host names, and ip addresses. Since we are on the 192.168.3.0 network and our domain is somedomain.com, our file will look like this:

192.168.3 RELAY
somedomain.com RELAY

If we wanted to explicitly block or reject email from certain domains or hosts we could use this file to do so. Instead of “RELAY” we would simply use a “REJECT” or more likely “DISCARD” for the action.

Finally, save your changes and issue the following commands:

make
/etc/rc.d/init.d/sendmail restart

SAMBA

In order for Linux to be as flexible as possible in any environment, it must be able to inter-operate with other operating systems. Microsoft is, of course, the big player in this field. Microsoft uses a protocol known as Server Message Block, or SMB, to communicate across networks. Linux has a protocol called SAMBA that allows it to act as either a client or server among Microsoft computers. Although SAMBA is very complex (the man pages alone are over 7000 lines long) we will look at a couple of simple “cookbook” setups.

Installing Samba

Most versions of Linux come with SAMBA already installed and ready to use. If it isn’t, or if you prefer to download the most recent version, you can install it with rpm. As stated in previous notes, on Debian you would use “dpkg” and slightly different switches in place of “rpm”.

rpm –Uvh samba*.i386.rpm

Notice we used the –U as opposed to the –i we used in other examples. This is because SAMBA is more than likely already installed on your system and the –U option tells rpm you want to either install or upgrade SAMBA.

Once we know SAMBA is installed, we can start it as follows:

/etc/rc.d/init.d/smb start

Or optionally:

service smbd start

To check the status of your SAMBA connections, you can use the smbstatus command:

/usr/bin/smbstatus –d

Now that we know SAMBA is up and running, let’s see how to configure it.

Configuring SAMBA

To manually configure SAMBA we edit the /etc/samba/smb.conf file. This file is broken into sections, each of which is a description of the resource shared. For example, the section [global] establishes configuration settings, [homes] lists users home directories that are shared and [printers] defines shared printers. Within each section are certain parameters that can be set defining the properties of that share. Let’s set one up as an example:

[open]
path = /fileshare/open
writeable = false
browseable = true

[finance]
path = /fileshare/finance
writeable = true
valid users = Romulus Remus
browseable = false

This created two file shares under the /fileshare directory, /open and /finance. The /open share is read accessible to everyone, but cannot be edited or written to. The /finance share is only accessible by the two users Romulus and Remus. They have full access to the files contained inside.

A simple alternative to manually configuring the smb.conf file is to use the Red Hat/Fedora system-config-samba GUI tool pictured below:


Dynamic Host Configuration Protocol (DHCP)

The Dynamic Host Configuration Protocol is used to automate the assignment of IP addresses and other related information (such as network mask, default gateways and DNS servers) to network hosts and devices. Linux systems can be easily configured as DHCP servers. While we won’t go into a long explanation of the protocol itself and how it works, a few comments will be helpful.

In order to obtain an IP Address automatically, a client (usually a computer) needs to be configured to automatically obtain an IP Address rather than use a statically assigned address. When a client is set up to automatically obtain an IP Address, it will, upon boot up, send out a broadcast message asking for a local DHCP server on UDP port 67. Since this is a broadcast, special considerations must be made, such as a DHCP Relay Agent, if your network encompasses multiple subnets separated by routers or VLANS. If a DHCP server is available, and it has available addresses, it will offer the client an IP Address from its address pool. The client then accepts the address along with any other information the DHCP server was configured to assign. The dynamic IP Address also comes with a certain “lease time”, which could range from hours to days or weeks depending on how the administrator set up the DHCP server. At the half way point of the lease duration, the client will request a renewal. If, by the end of the lease duration, the client has not been able to renew its lease, it will have to start over and request a new address or it will not be able to communicate on the network. For more detailed information on the DHCP protocol see RFC 2131 on the IETF.org website at http://www.ietf.org/rfc/rfc2131.txt.

Installing DHCP

As usual, the first step is to see if DHCP is already installed on your system. The easiest way to find out on a Red Hat/Fedora (and even Mandrake or SUSE) system is by typing:

rpm –q dhcp

If it is not installed you can install it with the following command:

rpm –ivh dhcp*.i386.rpm

If you happen to favor a Debian based distribution, use the “dpkg” command instead of “rpm”. To see dpkg options, check the man pages (man dpkg) or type dpkg --help. Now normally, as soon as we install a service we can fire it right up and then proceed to configure it. Not so with DHCP. Before starting it, we must configure two files or DHCP will not start. These two files are /etc/dhcpd.conf and /var/lib/dhcp/dhcpd.leases. We will look at configuring those files in the next section. However, once they are ready you can start your DHCP server by typing:

/etc/rc.d/init.d/dhcpd start

Or optionally: service dhcpd start

However, if you want dhcpd to start automatically after a reboot, you should run the following command:

/sbin/chkconfig dhcpd on

Configuring DHCP

So far , we are primarily discussing the server-side setup and configuration. However, it is worth briefly mentioning the files used by a DHCP client, which are:

  • dhclient.conf - Stores information about network devices attached to the computer.
  • dhclient.leases - Records leases obtained in the past in order to request them again after a restart.
  • dhcpd.options - This file lists options requested by the client.

There are also 3 files associated with the DHCP server. They include dhcpd.conf, dhcpd.leases, and an additional dhcpd configuration file located at /etc/sysconfig/dhcpd. Let’s start by taking a look at the /etc/dhcpd.conf file, as it is the main one you will be using. You can open it with your favorite text editor. You will notice that by default there is nothing there except a reference to a sample dhcpd.conf.sample file in /usr/share/doc/dhcp*. That file makes a good reference point and helps you get a feel for what goes where. You will also see lines starting with a “#” character. These are comment lines and are ignored. Blank lines are also ignored when the file is read. Additionally, you may see some long lines ending in a backslash (\) followed by a new line. This causes the line to be read as a single long line, but it makes it more easily read by us humans. One last item to keep in mind when editing the dhcpd.conf file is that you need to end a line with a semi colon (;).

Following is a simple configuration example.

# Our first line should define the DNS update scheme, such as

ddns-update-style interim;

# Next we should use the “authoritative” statement to
# indicate that our server should send DHCPNAK messages
# to misconfigured clients. By default, the server
# is “not authoritative” so a clueless admin who
# installs a DHCP server without correctly configuring
# it will not send DHCPNAK messages to legitimate clients.

authoritative;

# Next we can define our subnet and options.
# The routers and domain-name-servers options
# can accept multiple entries separated by commas.

subnet 192.168.100.0 netmask 255.255.255.0 {

option routers 192.168.100.1;
option subnet-mask 255.255.255.0;
option domain-name “somedomain.com”;
option domain-name-servers 192.168.100.2,192.168.100.3;
range dynamic-bootp 192.168.100.10 192.168.100.254;
default-lease-time 28800;
max-lease-time 43200;

# Let’s create a reservation, or static assignment,
# for an important computer
host gameserver {
hardware ethernet 00:12:34:56:78:9a;
fixed-address 192.168.100.5;
}
}

That completes a workable, yet simple, dhcpd.conf file. For more information (than you really ever wanted) you can see the man page by typing “man dhcpd.conf”.

The next file we are interested in is the /var/lib/dhcpd/dhcpd.leases file. You don’t really need to do anything with this file. The system uses it to keep track of client leases. Newer leases are appended to the end of the file, and the server will hand out leases starting at the lower end of the range. Periodically the server removes old or invalid data from this file and rewrites it, but it does not delete the old file. It renames it to “dhcpd.leases~”. You can view the dhcpd.leases file to see information about what addresses are issued to various clients.

The last file we want to examine is /etc/sysconfig/dhcpd. This file is optional, and it lists various dhcpd options. You could specify a different listening port for dhcp for example, or specify a different configuration file than the default /etc/dhcpd.conf to be used. You may need to specify a different interface for dhcp to run on, since by default it uses the lowest numbered interface which may not be what you want. Another useful option you can specify is to run the dhcpd daemon as a foreground process rather than a background process in order to trouble shoot start up problems.

This has been just a brief look at installing DHCP on your linux computer. You can find more information by consulting the various man pages:

  • man dhcpd
  • man dhcpd.conf
  • man dhcpd.leases


 

Current related exam topics for the Linux+ exam:

DOMAIN 3.0 Configuration

3.2 Configure basic server network services (for example: DNS, DHCP, SAMBA, Apache)

3.6 Implement DNS and describe how it works (for example: edit /etc/hosts, edit /etc/host.conf, edit /etc/resolv.conf, dig, host, named)




Click here for the complete list of exam objectives.

Discuss this TechNote here Author: Mark Fuchs




 

Featured Sponsors

TrainSignal - “Hands On” computer training for IT professionals. Network+ Training, MCSE, Cisco & more! Visit Train Signal’s free training site to get loads of Free Computer Training, videos, articles and practice exams.

 

All images and text are copyright protected, violations of these rights will be prosecuted to the full extent of the law.
2002-2011 TechExams.Net | Advertise | Disclaimer

TechExams.Net is not sponsored by, endorsed by or affiliated with CompTIA. CompTIA A+, Network+, Security+, Linux+, Server+, CTT+. , the CompTIA logo and trademarks or registered trademarks of CompTIA in the United States and certain other countries. All other trademarks, including those of Microsoft, Cisco, and CWNP are trademarks of their respective owners.