Unit 4 1 Write a short note on DNS and its hierarchy.

(NOV 2018)
2 Explain the DNS lookup process. (APR 2019)
3 what is DNS server? List and explain DNS server types. (NOV 2019)
4 What are the different types of DNS servers? With the help of an example, explain the DNS lookup
5 Write steps for Setting Up a Cache-Only Name Server. (NOV 2019)
6 Write a short note on cache-only nameserver. (NOV 2022)

Domain Name System (DNS) is the system that associates hostnames with IP addresses. Users and
administrators don’t have to remember the IP addresses of computers to which they want to connect
butcan do so just by entering a name, such as www.example.com.
DNS Hierarchy
DNS is a worldwide hierarchical system. In each DNS name, you can see the place of a server in the
hierarchy. In a name like www.example.com, three parts are involved. First, there is the top-level
domain (T LD) .com. This is one of the top-level domains that have been established by the Internet
Assigned Numbers Authority (IANA), the organization that is the ultimate authority responsible for
DNS naming.
Other common top-level domains are .org, .gov, .edu, .mil, and the many top-level domains that exist
for countries, such as .uk, .ca, .in, .cn, and .nl. Currently, the top-level domain system is changing, and
a proposal has been released to make many more top domains available.
Each of the top-level domains has a number of name servers. These are the servers that have
information on the hosts within the domain. The most important piece of information that the name
servers of the top-level domain have is that relating to the domains that exist within that domain (the
subdomain), such as redhat.com, example.com, and so forth. The name servers of the top-level
domains need to know how to find the name servers of these second-tier domains.
Within the second-tier domains, sub-domains can also exist, but often this is the level where
individual hosts exist. Think of hostnames like www.example.com, ftp.redhat.com, and so on. To find
these hosts, the second-tier domains normally have a name server that contains resource records for
hosts within the domain, which are consulted to find the specific IP address of a host. The root domain
is at the top of the DNS hierarchy. This is the domain that is not directly visible in DNS names but is
used to connect all of the top-level domains together. Within DNS, a name server can be configured to
administer just the servers within its domain. Often, a name server is also configured to administer the
information in sub-domains. The entire portion of DNS for which a name server is responsible is
referred to as a zone.
Part of a DNS hierarchy
DNS Server Types
1. Master: The master contains all the information about the domain and supplies this information
when requested. A master server is listed as -an authoritative server when it contains the information
you are seeking and it can provide that information.
2. Slave: The slave is intended as a backup in case the master server goes down or is not available. This
server contains the same information as the master and provides it when requested if the master
server cannot be contacted.
3. Caching: A caching server does not provide information to outside sources; it is used to provide
domain information to other servers and workstations on the local network. The caching server
remembers the domains that have been accessed. Use of a caching server speeds up searches since
the domain information is already stored in memory and the server knows exactly where to go rather
than having to send out a request for domain information. In DNS traffic, both primary and secondary
name servers are considered to be authoritative name servers. This means that if a client gets an
answer from the secondary name server about a resource
record within the zone of that name server, it is considered to be an authoritative reply. This is
because the answer comes from a name server that has direct knowledge of the resource records in
that zone. Apart from authoritative name servers, there are also recursive name servers. These are
name servers that are capable of giving an answer, but they don’t get the answer from their own
database. This is possible because, by default, every DNS name server caches its most recent request.
The DNS Lookup Process
To get information from a DNS server, a client computer is configured with a DNS resolver. This is
the configuration that tells the client which DNS server to use. If the client computer is a Linux
machine, the DNS resolver is in the configuration file /etc/resolv.conf. When a client needs to get
information from DNS, it will always contact the name server that is configured in the DNS resolver to
request that information. Because each DNS server is part of the
worldwide DNS hierarchy, each NS server should be able to handle client requests. In the DNS resolver,
more than one name server is often configured to handle cases where the first DNS server in the list is
not available. Let’s assume that a client is in the example.com domain and wants to get the resource
record for
www.sander.fr. The following will occur:
1. When the request arrives at the name server of example.com, this name server will check its cache.
If it has recently found the requested resource record, the name server will issue a recursive answer
from cache, and nothing else needs to be done.
2. If the name server cannot answer the request from cache, it will first check whether a forwarder has
been configured. A forwarder is a DNS name server to which requests are forwarded that cannot be
answered by the local DNS server. For example, this can be the name server of a provider that serves
many zones and that has a large DNS cache.
3. If no forwarder has been configured, the DNS server will resolve the name step-bystep. In the first
step, it will contact the name servers of the DNS root domain to find out how to reach the name
servers of the fr domain.
4. After finding out which name servers are responsible for the .fr domain, the local DNS server, which
still acts on behalf of the client that issued the original request, contacts a name server of the .fr
domain to find out which name server to contact to obtain information about the sander domain.
5. After finding the name server that is authoritative for the sander.fr domain, the name server can
then request the resource record it needs. It will cache this resource record and send the answer back
to the client.
DNS Zone Types
Most DNS servers are configured to service at least two zone types. First there is the regular zone
type that is used to find an IP address for a hostname. This is the most common use of DNS. In some
cases, however, it is needed to find the name for a specific IP address. This type of request is handled
by the in- addr.arpa zones.
In in-addr.arpa zones, PTR resource records are configured. The name of the in-addr.arpa zone is
the reversed network part of the IP address followed by in-addr.arpa. For example, if the IP address is
193.173.10.87, the in-addr.arpa zone would be 87.10.173 .in-addr.arpa. The name server for this zone
would be configured to know the names of all IP addresses within that zone.
Although in-addr.arpa zones are useful, they are not always configured. The main reason is that
DNS name resolving also works without in-addr.arpa zones; reverse name resolution is required in
specific cases only.
Setting Up a DNS Server
The Berkeley Internet Name Domain (BIND) service is used to offer DNS services on Red Hat
Enterprise Linux.
The three required files are:
named.conf: Found in the /etc directory, this file contains global properties and sources of
configurationration files.
named.ca: Found in /var/named, this file contains the names and addresses of root servers.
named.local: Found in /var/named, this file provides information for resolving the loopback address
for the local host.
The two additional files required for the master domain server are:
zone: This file contains the names and addresses of servers and workstations in the local domain and
maps names to IP addresses.
reverse zone: This file provides information to map IP addresses to names.
Setting Up a Cache-Only Name Server
Running a cache-only name server can be useful when optimizing DNS requests in your network. If
you run a BIND service on your server, it will do the recursion on behalf of all clients. Once the
resource record is found, it is stored in cache on the cache-only name server. This means that the next
time a client needs the same information, it can be provided much faster.
Configuring a cache-only name server isn’t difficult. You just need to install the BIND service and
make sure that it allows incoming traffic. For cache-only name servers, it also makes sense to
configure a forwarder.
Steps to follow
1. Open a terminal, log in as root, and run yum -y install bind-chroot on the host computer to install
the bind package.
2. With an editor, open the configuration file /etc/named.conf. You need to change some parameters
in the configuration file to have BIND offer its services to external hosts.
3. Change the file to include the following parameters: listen-on port 53 { any; }; and allow-query {
any; };. This opens your DNS server to accept queries on any network inter face from any client.
4. Still in /etc/named.conf, change the parameter dnssec-validation; to dnsserver- validation no;.
5. Finally, insert the line forwarders x.x.x.x in the same configuration file, and give it the value of the IP
address of the DNS server you normally use for your Internet connection. This ensures that the DNS
server of your Internet provider is used for DNS recursion and that requests are not sent directly to the
name servers of the root domain.
6. Use the service named restart command to restart the DNS server.
7. From the RHEL host, use dig redhat.com. You should get an answer, which is sent by your DNS
server.You can see this in the SERVER line in the dig response. Congratulations, your cache-only name
server is operational!
Configuring a Primary Master Server (Master)
To set up a primary name server, you’ll need to define a zone. This consists of two parts. First you’ll
need to tell the DNS server which zones it has to service, and next you’ll need to create a configuration
file for the zone in question. To tell the DNS server which zones it has to service, you need to include a
few lines in /etc/named.conf.
1. Make sure that the bind package is installed on your host computer.
2. Open the /etc/named.conf file, and make sure the following parameters are included:
• directory is set to /var/named
• listen-on port 53 is set to any
• allow-query is set to any
• forwarders contains the IP address of your Internet provider’s DNS name server
• dns-sec validation is set to no
3. Open the /etc/named.rfc1912.zones file, and create a definition for the example.com domain.
4. Create a file /var/named/example.com, and give it contents Change it to match the hostnames in
your environment.
5. Make sure that the DNS resolver in /etc/resolv.conf is set to your own DNS server.
6. Use dig yourhost.example.com, and verify that your DNS server gives the correct information from
your DNS database.
Setting Up a Secondary Name Server
After setting up a primary name server, you should add at least one secondary name server. A
secondary server is one that synchronizes with the primary. Thus, to enable this, you must first allow
the primary to transfer data. You do this by setting the allow-transfer parameter for the zone as you
previously defined it in the /etc/named.rfc1912.conf file. It’s also a good idea to set the notify yes
parameter in the definition of the master zone. This means that the master server automatically sends
an update to the slaves if something has changed.
Adding parameters for master-slave communication
zone "example.com" IN {
type master;
file "example.com";
notify yes;
allow-update { 192.168.1.70; };
};
Once you have allowed updates on the primary server, you need to configurationre the slave. This
means that in the /etc/named.rfc1912.conf file on the Red Hat server, which you’re going to use as
DNS slave, you also need to define the zone.
Creating a DNS slave configuration
zone "example.com" IN {
type slave;
masters {
192.168.1.220;
};
file "example.com.slave";
};
After creating the slave configuration, make sure to restart the named service to get it working.
Checking Your Configuration
2 1 What are different parameter used for dhcp.conf command? (NOV 2018)
2 Write short note on DHCP (Dynamic Host Configuration Protocol). (APR 2019)
3 Explain the DHCP server configuration. (NOV 2022)
4 What is DHCP? How is DHCP server setup? (Apr 2023)

The Dynamic Host Configuration Protocol (DHCP) is used to assign IP-related configuration to hosts
in your network. Using a DHCP server makes managing a network a lot easier, because it gives the
administrator the option to manage IP-related configuration on a single, central location on the
network, instead of on multiple different hosts.
Counter to common belief, DHCP offers much more than just the IP address to hosts that request
its information. A DHCP server can be configured to assign more than 80 different parameters to its
clients of which the most commonly used are IP addresses, default gateways, and the IP address of the
DNS name servers.
When a client comes up, it will send a DHCP request on the network. This DHCP request is sent as
a broadcast, and the DHCP server that receives the DHCP request will answer and assign an available
IP address. Because the DHCP request is sent as a broadcast, you can have just one DHCP server per
subnet. If multiple DHCP servers are available, there is no way to determine which DHCP server
assigns the IP addresses. In such cases, it is common to set up failover DHCP, which means that two
DHCP services together are servicing the same subnet, and one DHCP server completely takes over if
something goes wrong.
It is also good to know that each client, no matter which operating system is used on the client,
remembers by default the last IP address it has used. When sending out a DHCP request, it will always
request to use the last IP address again. If that IP address is no longer available, the DHCP server will
give another IP address from the pool of available IP addresses.
When configuring a DHCP server, it is a good idea to think about the default lease time. This is the
amount of time that the client can use an IP address it has received without contacting the DHCP
server again. In most cases, it’s a good idea to set the default lease time to a rather short amount of
time, which means it doesn’t take too long for an IP address to be given back to the DHCP server. This
makes sense especially in an environment where users connect for a short period of time, because
within the max- lease-time (two hours by default), the IP address is claimed and cannot be used by
another client

.
In many cases, it makes sense to set the max-lease-time to a period much shorter than 7,200 seconds
Setting Up a DHCP Server
to set up a DHCP server, after installing the dhcp package, you need to change common DHCP
settings in the main configuration file: /etc/dhcp/dhcpd.conf. After installing the dhcp package, the file
is empty, but there is a good annotated example file in /usr/share/doc/dhcp-
<version>/dhcpd.conf.sample.
Here are the most relevant parameters from the dhcpd.conf file and a short explanation of each:
• option domain-name Use this to set the DNS domain name for the DHCP clients.
• option domain-name-servers This specifies the DNS name servers that should be used.
• default-lease-time This is the default time in seconds that a client can use the IP address that it
has received from the DHCP server.
• max-lease-time This is the maximum time that a client can keep on using its assigned IP address. If
within the max-lease-time timeout it hasn’t been able to contact the DHCP server for renewal, the
IP address will expire, and the client can’t use it anymore.
• log-facility This specifies which syslog facility the DHCP server uses.
• subnet This is the essence of the work of a DHCP server. The subnet definition specifies the
network on which the DHCP server should assign IP addresses. A DHCP server can serve multiple
subnets, but it is common for the DHCP server to be directly connected to the subnet it serves.
• range This is the range of IP addresses within the subnet that the DHCP server can assign to
clients.
• option routers This is the router that should be set as the default gateway.
DHCP Server Set Up:
1. Start the virtual machine, and open a root shell. From the root shell, use the command yum -y dhcp
to install the DHCP server.
2. Open the file /etc/dhcp/dhcpd.conf with an editor, and give it the following contents. Make sure
that the names and IP addresses used in this example match your network:
option domain-name "example.com";
option domain-name-servers YOUR.DNS.SERVERNAME.HERE;
default-lease-time 600;
max-lease-time 1800;
subnet 192.168.100.0 netmask 255.255.255.0 {
range 192.168.100.10 192.168.100.20;
options routers 192.168.100.1;
}
3. Star t the DHCP server by using the command service dhcpd start, and enable it using chkconfig
dhcpd
on.
4. Start the second virtual machine. Make sure that the network card is set to get an IP address from a
DHCP server. After star ting it, verify that the DHCP server has indeed handed out an IP address.
3 1 Discuss MTA and MDA in detail. (NOV 2018)
2 Explain components play role in the process of Internet mail. (APR 2019)
3 Explain the components of email delivery process. (NOV 2019)
4 Discuss the role of MUA, MTA, and MDA in the email process. (NOV 2022)
5 Explain: Message Transfer Agent, Mail Delivery Agent, Mail User Agent with examples. (Apr 2023)

Using electronic mail, you can send messages to and receive messages from other computer users
anywhere in the world.
Before configuring an e-mail client or server, you need to understand how e-mail works and the
programs to use or make available to your users. Several key components are essential for e-mail to
work properly, and as a system administrator it is your responsibility to configure the following items.
Programs:
• A Mail User Agent (MUA) for users to be able to read and write e-mail
• A Mail Transfer Agent (MTA) to deliver the e-mail messages between computers across a network
• A Mail Delivery Agent (MDA) to deliver messages to users‘ mailbox files
• An mail notification program to tell users that they have new mail
• The TCP/IP protocols for storing e-mail messages and transferring e-mail between MTAs
Other communication and mail storage components:
• Ports
• Mail queues
• Mailbox files
Tracing the E-Mail Delivery Process
The usual email delivery process involves three components:
1. Mail User Agent
2. Mail Transfer Agent
3. Mail Delivery Agent
Mail User Agent (MUA)
To be able to send mail, you, or your users, need a program called a Mail User Agent (MUA) The
MUA, also called a mail client, enables users to write and read mail messages.
Two types of MUAs are available:
1. graphical user interface (GUI), such as Netscape Messenger
2. command-line interface, such as Pine.
Whether your MUA is a GUI or command-line interface, after the message is composed, the MUA
sends it to the mail transfer agent (MTA). The MTA is the program that sends the message out across
the network and does its work without any intervention by the user. In fact, most users are unaware
of the MTA, they just see their mail client.
Mail Transfer Agent (MTA)
Now that the MTA has received the message from the MUA, it can do its job. The MTA installed by
default on your Red Hat system is called Sendmail. The MTA reads the information in the To section of
the e-mail message and determines the IP address of the recipient‘s mail server. Then the MTA tries to
open a connection to the recipient‘s server through a communication port, typically port 25. If the
MTA on the sending machine can establish a connection, it sends the message to the MTA on the
recipient‘s server using the Simple Message
Transfer Protocol (SMTP).
The MTA on the receiving server adds header information to the message. The header contains
information that is used for tracking the message and ensuring that it is delivered. Next the receiving
MTA passes the message to another program to inform the receiver that new mail has arrived.
Mail Delivery Agent (MDA)
After the MDA receives the message from the MTA, it places the message in the receiver‘s mailbox
file that is identified by the username. On your Red Hat system this is a program called procmail. The
location of the user‘s mailbox file is
/usr/spool/mail/<user’s name>.
The final step in the process happens when the user who is the intended receiver of the message
reads the message. The user does this using the MUA on his or her PC. An optional program is a mail
notifier that periodically checks your mailbox file for new mail. If you have such a program installed, it
notifies you of the new mail.
The Red Hat Linux shell has a built-in mail notifier that looks at your mailbox file once a minute. If
new mail has arrived, the shell displays a message just before it displays the next system prompt. It
won‘t interrupt a program you‘re running. You can adjust how frequently the mail notifier checks and
even which mailbox files to watch. If you are using a GUI, there are mail notifiers available that play
sounds or display let you know that new mail has arrived

pictures to.
4 Explain following parameter for secure internet configuration: myhostname, mydomain , myorigin ,
inet_interfaces , mynetwork. (NOV 2018)
Explain different parameters used in the /etc/postfix/main.cf file. (APR 2019)
Explain different Secure Internet Configurations for Postfix. (NOV 2019)
Explain the various parameters for secure internet configuration of Postfix server. (NOV 2022)

There are a few more steps to take to configure a mail server, which is going to handle messages
from the Internet. Most of the additional tasks relate to security. You’ll need to make sure your mail
server has at least a minimum level of protection against spam and other email abuses. To make a
secure Internet configuration, you need to set some additional parameters. All of these will be set in
the /etc/postfix/main.cf file. The following are the relevant parameters:
• myhostname This parameter specifies the name of this host. If not specified, it is set to the full
DNS domain name (FQDN) of this host. This parameter is used as a variable in other parameters in
the main.cf file, so it is useful to set it.
• mydomain This parameter specif es the domain of this host. If not set, the domain name part of
the FQDN is used.
• myorigin This parameter determines the domain seen by the email recipient when receiving
messages. The default is to use the FQDN of this host. This means that if user linda on server
dfw.example.com sends a message, the recipient will see a message coming in from
[email protected]. This is often not what you want. To append the domain name only and
not the entire FQDN, use myorigin = $mydomain.
• inet_interfaces This parameter specifi es the IP addresses of the mail server to which it binds. By
default, it is set to localhost only, which means that your mail server cannot receive messages from
the Internet. This is fi ne if the mail server only has to send messages and another server is used
for email reception. However, you’ll normally want to enable all inet_interfaces using
inet_interfaces = all.
• mydestination This parameter contains a list of all domains for which this server will receive
messages. Messages that are addressed to users in other domains will be rejected. Make sure that
this parameter contains a list of all domains serviced by this server. Also notice that in the default
setting, message reception for $mydomain is off, so you’ll need to change this.
• mynetworks This parameter is optional. You can use it to specify the network address from which
your MTA accepts messages for relaying without further authentication. It’s a good idea to set this
to your trusted network.
• relayhost This parameter contains the name of a host that is used to relay all messages to. Use this
if, for example, you want the mail server of your ISP to take care of all message delivery
5 Write down the steps to configure Apache for basic website services. (NOV 2018)
Explain the httpd.conf file in detail. (APRIL 2023)
Write a short note on virtual host. (NOV 2018)
State the steps to setup virtual hosts in Apache. (NOV 2022)

Configuring an Apache server that services just one website is not hard to do—you just have to
install the Apache software and create some content in the Apache document root. The default
document root is set to /var/www/html on a Red Hat Enterprise Linux server. Just put a file in this
directory with the name index.html, and it will be served by your Apache server.
Creating a Basic Website
1. Use yum -y install httpd to install the Apache web server.
2. Use chkconfig httpd on to put the Apache web server in your server’s runlevels, and have it star t at
boot in your runlevels.
3. Open a root shell, and go to the directory /var/www/html. In this directory, create a file with the
name index.html. In this file, put the content “ welcome to my website” and then use service httpd
start to start the Apache web server.
4. Still from the root shell, use elinks http://localhost to access the website you just created. You’ll
notice that your web server is up and running!
Apache Configuration Files
Everything related to the configuration of your Apache server is in the /etc/httpd directory. In this
directory, you’ll find two subdirectories: conf and conf.d. In /etc/httpd /confd, you’ll find the main
Apache configuration file httpd.conf. From the httpd.conf file, many configuration files are included,
and by default, they are in /etc/httpd/conf.d. This httpd.conf file is designed to contain the entire
Apache configuration. However, because Apache can take advantage of many additional features,
parts of the configuration are stored in additional configuration files in Red Hat Enterprise Linux.
• Include conf.d/*. Conf -- Includes the contents of the files in conf.d/ whose names end in .conf
• KeepAliveOff -- If set to On, maintains an open connection to a remote client in the absence of
direct contact for the time specified by KeepAliveTimeout
• KeepAliveTimeout 15 -- Sets the number of seconds permitted to elapse between direct requests
from the same client on the same connection before the server will dose the connection (applies
if KeepAlive is On)
• Listen [ipaddress:] 80 -- Determines the combination of IP address and pod on which Apache
listens for connections; multiple Listen directives may be used.
• LoadModule modname filename -- Links the module or library filename into the server and adds
it to the list of active modules using the name modname
• MaxClients 256 -- Sets the maximum number of simultaneous connections_supported
• MaxKeepAliveRequests 100 -- Sets the number of requests permitted per connection
• MaxRequestsPerChild 4000 -- Sets the maximum number of requests each child server fills before
terminating
• MaxSpareServers 20-- Defines the maximum number of spare (idle) child servers the master
server spawns
• MinSpareServers 5 --Defines the minimum number of spare (idle) child servers permitted
• PidFile run/httpd.pid-- Defines the file containing the PID of the master server process, relative to
ServerRoot
• ServerLimit 256 -- Specifies the upper limit on the number of server processes or threads running
simultaneously
• ServerRoot /etc/httpd -- Defines the top-level directory for Apache‘s configuration files and log
files
• HostnameLookups off -- Controls whether Apache performs DNS lookups on connecting hosts in
order to log hostnames
• IndexIgnore filespec -- Defines one more filename patterns filespec that the directory indexer will
ignore
• IndexOptions opts -- Sets the options controlling the behavior of Apache‘s directory indexing
feature
• LanguagePriority spec -- Specifies a list of language codes in spec that indicates the order in which
languages codes will be applied during content negotiation
• LogFormat str name -- Defines a log file format str named name which Apache uses for messages
it logs in the access log
• LogLevel warn -- Controls the amount and detail of information Apache records in its error log
• ReadmeName README.html --Defines README html as the file whose contents will be appended
to the end of a directory listing.
• ScriptAlias urlpath dirpath -- Functions exactly like the Alias directive and also indicates that
dirpath contains executable CGI scripts
• ServerAdmin root@localhost -- Defines the email address included in error messages displayed to
client connections
• ServerName -- Specifies an alternative name for the server, such as www.mydornain.com, that is
different than the host‘s actual name (webbeast.mydomain.com)
• ServerSignature On -- Directs Apache to append the ServerName and version number as a footer
to generated documents, such as error message, FTP file listings, and so forth
• TypesConfig /etc/mime.types -- Sets the filename of the MIME types configuration file (relative to
ServerRoot if the filename does not begin with m), which maps filename extensions to content
types User
• [#] apache -- Specifies the user name or, if prefixed with #, the UID under which the child servers
execute
• UserDir public_html -- Defines the subdirectory in a user‘s home directory that is used when
clients request documents belonging to a specific user
Apache Log Files
To help you troubleshoot Apache issues, two log files are used by default. You can find these files
in the /var/log/httpd directory. The access_log file contains information about users who have
accessed your server. Note that it can grow very fast on busy web servers! The error_log file has error
messages that can be useful in troubleshooting your Apache web server.
Hosts Virtual --------One Apache installation can handle more than one Apache website. To handle
more than one site from an Apache server, you can create virtual hosts. A virtual host is a definition of
different websites to be served by the Apache web server. You can include this definition in the main
Apache confi guration file /etc/httpd/conf/httpd.conf or in separate files that you’ll create in the
/etc/httpd/conf.d/ directory. If you chose the latter solution, make sure the name of each of these files
ends in .conf. Before you can start working with virtual hosts, you’ll need to make sure that hostname
resolving works. That means you’ll need to make sure the virtual host can be reached by its name. This
means you’ll either have to create A records or CNAME records in DNS or have to create an entry in
the /etc/hosts file that tells the client computer which IP address to connect to in order to reach the
virtual host. In a test environment like the one you’re using in this book, it is a very common error to
forget to set up name resolving. When setting up virtual hosts, you’ll have to choose which type to
use. You can configure either a name-based virtual host, an IP-based virtual host, or both. Name-based
virtual hosts are the default and they are easier to set up because you can run multiple Apache sites
on one IP address
6 How is postfix setup as SMTP server? How is mail server opened for external mail? (APRIL 2023)

Setting up a Postfix mail server can be easy, depending on exactly what you want to do with it. If
you only want to enable Postfix for local email delivery, you just have to set a few security parameters
and be aware of a minimal number of administration commands. If you want to set up Postfix for mail
delivery to other domains on the Internet, that is a bit more involved.

In both cases, you will do most of the work in the /etc/postfix/main.cf file. This is the Postfix
configuration file in which you’ll tune some of the many parameters that are available in this file.
For troubleshooting the message delivery process, the /var/log/maillog file is an important source
of information. In this file, you’ll find status information about the message delivery process, and just
by reading it, you will often find out why you are experiencing problems.

Another common task you’ll use in both configuration scenarios is checking the mail queue. The
mail queue is the list of messages that haven’t been sent yet because there was some kind of problem.
As an administrator, you can use the mailq command to check the current contents of the mail queue
or use the postfix flush command to flush the entire mail queue. This means that you’ll tell Postfix to
process all messages that are currently in the mail queue and try to deliver them now.

Working with Mutt

The Mutt MUA is available in the default Red Hat Enterprise Linux repositories, but you’ll have to
install it. Steps to Install
1. Log in as root, and use yum -y install mutt to install Mutt.
2. Still as root, use the command mail -s hello linda <. This sends an empty message to user linda,
because it is useful if the test user has at least one message in their mailbox.
3. Use su - linda to become linda, and type mutt. If you get a message that the mail directory for linda
doesn’t exist, type y to create it. You’ll now see the Mutt inter face.
4. Press Enter to open the mail message. Because it doesn’t contain any content, you’ll just see the
message header.
5. Type q once you’ve finished reading the message.
6. To reply to the message, type r. Mutt will prompt you to choose which user you want to send the
message and which subject line you want to use. Press Enter twice to accept the default suggestions.
7. The message composition w indow opens next. This is a vi w indow, so use o to open a new line and
start writing the message. Once you are finished writing, use the vi command :wq! to close the
message- editing inter face.
8. Now you’ll see the message summary. From there, type y to send it to root. Next type q to quit
Mutt.
9. Exit linda’s su shell, and as root type mutt. You’ll see that linda’s message has been delivered to her
inbox.

Sending a Message to an External User

1. On the host computer, use virsh list. If you per formed all previous exercises, you’ll see a virtual
machine with the name testvm. Use virsh start testvm to star t this virtual machine.
2. On the host computer, star t the Virtual Machine Manager using the virt-manager command. Open
a console on the virtual machine, and note its IP address.
3. On both the host and the virtual machine, edit the /etc/hosts file and include a line for the host
computer and the virtual machine. The purpose for doing this is that these two computers can then
resolve one another.
4. On the virtual machine, use useradd lisa to create a user with the name lisa.
5. On the host computer, use su - linda to become linda and start Mutt. From the Mutt inter face, type
m to start composing a new mail message. Enter lisa@testvm example.com in the to field. In the
Subjectfield, enter test message 1. Enter some text in the mail message, and press y to send it
6. Open a shell on testvm, and as root, use yum -y install mutt to install Mutt. Next, use su - lisa to log
in as lisa and start Mutt. You’ll notice that lisa’s mailbox is empty, and the message that user linda sent
from the other machine has not yet been sent.
Opening Your Mail Server for External Mail
1. On the testvm virtual machine, open the /etc/postfix/main.cf file with an editor.
2. Find the parameter inet_interfaces = localhost, and put a hash sign in front of it.
3. Enable the parameter inet_interfaces = all by removing the pound sign in front of the line.
4. Still on testvm, use service postfix restart to restar t the Postfix process. If a firewall is active, make
sure that por t 25 is open on it.
5. On testvm, use su - lisa to become user lisa and star t Mutt. You’ll notice that lisa still hasn’t
received her message yet.
6. As root on the host computer, type mailq to type the current content of the mail queue. As with the
first attempt, the message couldn’t be sent; the message that linda tried to send to lisa is stuck in the
queue.
7. Type postfix flush to flush the mail queue. Postfix will now try to send the message again

7 What is Apache modules? How to add modules in Apache web server? (Nov 2019)

Among the features that make the Apache web server attractive is the fact that it is modular. By
including modules, functionality can be added to Apache. To include Apache modules, they first need
to be installed. By default, some of the most common modules are installed to the
/etc/httpd/modules directory. To tell Apache that it should load a specific module, you need to use the
LoadModule directive.
By default, this directive is used to include many modules.

If a module is loaded, it can also have a specific configuration. There are three ways to load additional
configurations for modules:

• Use the IfModule directive in httpd.conf. • Put it in an include file.

• If a module is common, its parameters can be entered in httpd.conf without further specification.

By default, some modules put their configuration in a separate configuration file and store that file in
the directory /etc/httpd/conf.d. The directive include conf.d/*.conf ensures that all configuration files
where the name ends in .conf are included by default when Apache starts. Later in this chapter, you’ll
read about the mod_ssl module, which creates its own configuration file in /etc/httpd/conf.d.

Another approach to include parameters that are relevant for specific modules is by using the
IfModule parameter in the httpd.conf file. This approach is more practical for modules that have a
limited number of specific directives. If a module is very common and almost always used, its
parameters can simply be entered in the
httpd.conf file. An example of this is the DirectoryIndex, this option is provided by the mod_dir
module, which is included in nearly all Apache configurations and therefore requires no further
specification.
8 What are modes of Apache? Explain some performance parameters for these modes. (APR 2019)
What are modes of Apache? Explain some performance parameters for these modes (NOV 2019)
Apache can be started in two different modes: 1. prefork mode 2. worker mode
The prefork mode is the default mode. In this mode, a master httpd process is started, and this master
process will start different httpd servers. As an alternative, the worker mode can be used. In this mode
one httpd process is active, and it uses different threads to serve client requests. Even if the worker
mode is a bit more efficient with regard to resource usage, some modules cannot handle it, and
therefore the prefork mode is used as default. However, if you need the best performance that httpd
can offer and you don’t use modules that are incompatible with worker mode, it’s a good idea to use
worker mode instead. Worker mode can be configured to serve more simultaneous processes. To
change the default mode that Apache uses, you can modify the HTTPD parameter in
/etc/sysconfig/httpd. To use the worker mode, you have to start the /usr/sbin/httpd. worker binary
instead of /usr/sbin/httpd. To accomplish this, just remove the pound sign in front of the example line
in /etc/sysconfig/httpd and restart the httpd process using service httpd restart.
For both modes, you can set some performance parameters:
StartServers: This is the number of server processes httpd should always start.
MinSpareServers: This is the minimum amount of spare server processes that are kept. It is good to
have a certain minimum because it allows httpd to serve client requests really fast. However, the
minimum shouldn’t be too high because each server uses system resources.
MinSpareThreads: In worker mode, this is the minimum amount of spare threads that httpd should
keep. You can see that it is set considerably higher than the MinSpare Servers parameter in prefork
mode.===MaxSpareServers and MaxSpareThreads: This is the maximum amount of spare servers or
threads that httpd should keep.===ServerLimit: This is the total amount of server processes that can
be started as a maximum. Note that the value of 256 is pretty high, and it should be sufficient for most
servers.===MaxClients: This is the maximum number of clients that can be connected. Note that in
worker mode, one client can have several concurrent requests, which are opened simultaneously.
MaxRequestPerChild : This is the number of requests that can be opened by a server process. In
prefork mode, the maximum is capped at 4,000; in worker mode, there is no maximum setting.
9 How configure an Apache server to use LDAP? (APR 2019)
You can also configure Apache to allow access only to specific users. To do this, you can configure
your server to use authentication. In this section, you’ll learn how to configure authentication based
on a flat file that contains usernames and hashed passwords and how to configure authentication for
user accounts that are stored in an LDAP directory server.==In both cases, you need to be aware that
authentication settings are related to a directory or web context that you want to protect. This means
that the settings placed in a block that opens with <Directory> and ends with </Directory>. This allows
you to set up authentication for specific directories on only the web server. If you want to set up
authentication for the entire website, you need to set it up for a directory as well. If this is the case,
just set it up for the root directory in that case.==To configure an Apache server to use LDAP, the
administrator needs to address two things. First the Apache server must be able to handle the LDAP
certificate, and the basic authentication provider must be set to LDAP. This section of the configuration
is in the generic part of httpd.conf so that it is available for all virtual servers’ services of your
==Apache instance. Next the (virtual) server itself must be configured to use LDAP for authentication.
To take care of this, you’ll need to include the following in your httpd.conf file: LDAPTrustedGlobalCert
CA_BASE64 /etc/httpd/your-ldap-server-certificate.crAuthBasicProvider ldap ====The important part
of the general segment of the configuration is the LDAPTrustedGlobalCert parameter that tells Apache
which LDAP certificate to use. This assumes that your LDAP server has its own certificate, which you
have already copied to the appropriate location.
10 Explain how the DirectoryIndex, Options, AllowOverride, and Orderdirectives in Apache. (NOV
2022)

DirectoryIndex :== The administrator can also set different directory options on an Apache web server.
These options are used to define how the contents of a directory on the httpd server should be
presented to users who access that directory. The default behavior is that the httpd processes
look in the document root to see whether there is a fi le whose name starts with
index. The DirectoryIndex directive can be used to specify that other fi les should also be
considered. If this is the case, it will show the contents of this fi le, and if not, a list of files
in the directory is shown.
To modify this behavior, the DirectoryIndex and Options directives can be used. By
default, the DirectoryIndex directive specifies that Apache should look for a file with the
name index.html or index.html.var.
Options: The Options directive within a directory definition(as you can see in the /var/www/icons
directory statement) can further fine-tune the options that are used to display the contents of a
directory. You can also use Options to determine which server features are available in a particular
directory. A useful argument for the Options directive is Indexes. If you use this option, you will see a
list of fi les in the directory if no index.html is available. Related to this option is Follow SymLinks. This
option will ensure that symbolic links are followed if they exist in the document directory. Don’t use
this because it is considered a security threat.
AllowOverride: In a directory served by Apache, some basic restrictions can be used. First, there is the
AllowOverride directive. This directive is related to the .htaccess fi le that an administrator
can use to restrict access to a given directory. If AllowOverride is set to none, the contents of
any .htaccess fi le that is found anywhere in a subdirectory of the current directory will be ignored. If
you don’t want the owners of subdirectories to restrict access to their directories, set AllowOverride
to none. If you want to allow users to restrict access to subdirectories, set it to All. In high-
performance environments, don’t use it at all because this will force Apache to recurse through the
entire directory tree on every request.
Order directive: Another basic way to handle access restrictions is by using the Order directive. With
this directive, you’ll specify the order in which allow and deny commands are used. The order is not
defi ned by how the rules appear in your configuration fi le but by how you’ve used the Order
directive. The default order is deny and then allow. This means that if a client is excluded by
deny, it will be excluded unless it matches allow. If neither is matched, the client gets access. As
you see, this is a rather open approach that doesn’t put many restrictions on a directory.