(2½ hours)

[Total Marks: 75

N. B.: (1) All questions are compulsory.

(2) Makesuitable assumptions wherever necessary and state the assumptions made.
(3) Answers to the same question must be written together.
(4) Numbers to the right indicate marks.
(5) Draw neat labeled diagrams wherever necessary.
(6) Use of Non-programmable calculators is allowed.

1. Attempt any two of the following: 10

a. Explain the duty of Linux system administrator in monitoring and tuning
performance.
The default installation of Red Hat Enterprise Linux goes a long way toward capitalizing on
existing system resources. There is no “one size fits all” configuration, however. Linux is
infinitely configurable, or close to it. On a modern standalone system, Linux runs pretty quickly.
If it doesn’t, there’s something wrong — something the system administrator can fix. Still,
you might want to squeeze one last little bit of performance out of your hardware— or a number
of people might be using the same file server, mail server, or other shared machine, in which case
seemingly small improvements in system performance add up.
System tuning is an ongoing process aided by a variety of diagnostic and monitoring tools. Some
performance decisions are made at installation time, while others are added or tweaked later. A
good example is the use of the hdparm utility, which can increase throughput in IDE drives
considerably, but for some high-speed modes a check of system logs shows that faulty or
inexpensive cables can, in combination with hdparm, produce an enormity of nondestructive
but system-slowing errors.
Proper monitoring allows you to detect a misbehaving application that consumes more resources
than it should or fails to exit completely upon closing. Through the use of system performance
tools, you can determine when hardware— such as memory, added storage, or even something as
elaborate as a hardware RAID — should be upgraded for more cost-effective use of a
machine in the enterprise or for complicated computational tasks such as three-dimensional
rendering. Possibly most important, careful system monitoring and diagnostic practices
give you a heads-up when a system component is showing early signs of failure, so that you can
minimize any potential downtime. Combined with the resources for determining which
components are best supported by Fedora Core and Red Hat Enterprise Linux, performance
monitoring can result in replacement components that are far more robust and efficient in some
cases. In any case, careful system monitoring plus wise use of the built-in configurability
of Linux allows you to squeeze the best possible performance from your existing equipment,
from customizing video drivers to applying special kernel patches or simply turning off unneeded
services to free memory and processor cycles.
b. What are different Linux distributions? Explain any three in brief.
Ubuntu
Debian
Fedora
Red Hat Enterprise Linux
SUSE Linux Enterprise
Mandriva
Arch Linux
Puppy Linux
Etc…

c. Explain the stages of Linux boot process.

BIOS - Basic input /output System executes MBR
MBR - Master Boot Record Executes GRUB
 GRUB - Grand Unified Boot Loader executes Kernel
Kernel - Kernel executes /sbin/init
Init - init executes runlevel programs
Runlevel - Runlevel Programs are executed from /etc/rc.d/rc*.d/

d. Explain the Linux directory structure.

Red Hat has follow the standards outlined in the Filesystem Hierarchy Standard (FHS)
The FHS provides specific requirements for the placement of files in the directory structure.
Placement is based on the type of information contained in the file. Two categories of file
information exist: shareable or unshareable, and variable or static. Shareable files are files that
can be accessed by other hosts, and unshareable files can be accessed only by the local system.
Variable files contain information that can change at any time on their own, without anyone
actually changing the file. A log file is an example of such a file. A static file contains
information that does not change unless a user changes it. Program documentation and binary
files are examples of static files.
The file system is organized in a flat, hierarchical file system. Linux’s method of mounting its file
systems in a flat, logical, hierarchical method has advantages over the file system mounting
method used by Windows. Linux references everything relative to the root file system
point /, whereas Windows has a different root mount point for every drive. If you have a /
partition that fills up in Linux, you can create another file system called /usr/local and move
your data from /usr/local in the original file system to the new file system definition. This
practice frees up space on the / partition, and is an easy way to bring your system back up to a
fully functional state.
The / directory is called the root directory and is at the top of the file system structure. In many
systems, the / directory is the only partition on the system, and all other directories are mounted
under it. Figure 7-1 shows a file system with the / directory mounted as the only partition, with all
other directories contained within it. The primary purpose of the / directory is booting the system
and correcting any problems that might be preventing the system from booting. According to the
FHS, the / directory must contain, or have links to, the following directories:
bin — This directory contains command files for use by the system
administrator or other users. The bin directory cannot contain subdirectories.
boot— On Red Hat systems, this is the directory containing the kernel, the core of the operating
system. Also in this directory are files related to booting the system, such as the boot loader and
the initial ramdisk.
dev — This directory contains device nodes through which the operating system can access
hardware and software devices on the system.
etc — This directory and its subdirectories contain most of the system configuration files. If you
have the X Window System installed on your system, the X11 subdirectory is located here.
Networking and systemrelated files are in the subdirectory sysconfig. Another subdirectory
of etc is the skel directory, which holds files used as templates used to create files in users’ home
directories when the users are created.
home— This directory contains the directories of users on the system Subdirectories of home
will be named for the user to whom they belong.
initrd — This directory is used as a mount point when the system is booting. It doesn’t contain
any data, but it is very important that it be there. This directory is not part of the FHS.
lib — The shared system files and kernel modules are contained in this directory and its
subdirectories.
media — This directory contains the mount points for removable media such as floppy drives,
CD-ROM drives, and USB devices such as flash memory sticks, which are typically automounted
by the system.
mnt — This directory is the location of the mount point for temporary file systems, such as those
on floppies or CDs, which traditionally have been manually mounted.
opt — This directory and its subdirectories are often used to hold applications installed on the
system.
proc— This directory is a mount point for virtual information about currently running system
processes. This directory is empty until the proc file system is mounted.
root— This is the home directory of the root user. Don’t confuse this with the / directory, which
has the same name.
 sbin— Contained in this directory are system binaries used by the system administrator or the
root user.
selinux — This directory is similar to the /proc directory in that it contains information about the
selinux stored in the memory of the running kernel.
srv — This directory is intended to hold site-specific data for system provided services.
sys — This directory is the mount point for a virtual file system of type sysfs that is used to hold
information about the system and devices.
tmp — This directory contains temporary files used by the system.
usr — This directory is often mounted on its own partition. It contains shareable, read-only data.
Subdirectories can be used for applications, typically under /usr/local.
var — Subdirectories and files under var contain variable information, such as system logs and
print queues.

2. Attempt any two of the following: 10

a. State and explain any five files that deal with system environmental settings.
/etc/motd issue issue.net
aliases fstab grub.conf
cron files syslog.conf ld.so.conf
logrotate.conf

b. What are the network files to be changed when we setup or move the system?
Explain each in brief.
In addition to configuring the network cards on each of the computers in the network, three files
on each computer need to be modified. These files are all located in the /etc directory:
■■ /etc/nsswitch.conf

■■ /etc/hosts

■■ /etc/resolv.conf

■■ /etc/sysconfig/network

The /etc/nsswitch.conf file contains configuration information for the name resolver and should
contain the following line:hosts: files dns
This configuration tells the name resolver to check the /etc/hosts file before attempting to query
a name server and to return all valid addresses for a host found in the /etc/hosts file instead of
just the first. The /etc/hosts file could contain the names of all the computers on the local
network, or an outside network. For a small network, maintaining this file is not difficult, but for
a large network, like the Internet, keeping the file up to date is often impractical.
The /etc/resolv.conf file provides information about name servers employed to resolve
hostnames.
The /etc/sysconfig/network file contains two lines, as follows:
NETWORKING=yes
HOSTNAME=(host and domain name of your system)
The first line enables networking for your system. The second line displays the hostname of your
system and the name of the domain to which it belongs.

/etc/sysconfig/network-scripts/ifcfg-eth0 - Set up the IP addresses of your network

interfaces.
/etc/sysconfig/network & /etc/hosts - Set up the hostname of your machine
/etc/resolv.conf - Set up the DNS servers to reference.
/etc/nsswitch.conf - Set up the device order from which hostnames are looked up.

c. What is DHCP server? How is it configured? How is DHCP client configured?

Configuring DHCP Server
The program that runs on the server is dhcpd and is included as an RPM on
the Fedora Core and Red Hat Enterprise Linux installation CDs. You can
install it using the Package Management tool by following these instructions.
1. On Enterprise Linux choose Applications ➪ System Settings ➪
Add/Remove Applications from the top panel. On Fedora Core 4
choose Desktop ➪ System Settings ➪ Add/Remove Applications. The
 screen shown in Figure 11-5 appears.
2. Scroll down the list until you see a listing for Network Servers.
3. Click the Details link for Network Servers. The screen shown in Figure
11-6 appears.
4. Click Close; then click Update, and finally click Continue.
5. Insert the requested numbered installation CD when prompted and
click OK.
6. After the package is installed, click Close to exit the Package Management
tool.
d. What is network file system? What are the features of NFS4? What are
advantages and disadvantages of NFS?
NFS follows standard client/server architectural principles. The server component of NFS
consists of the physical disks that contain the file systems you want to share and several daemons
that make these shared file systems visible to and available for use by client systems on the
network. When an NFS server is sharing a file system in this manner, it is said to be exporting a
file system. Similarly, the shared file system is referred to as an NFS export. The NFS server
daemons provide remote access to the exported file systems, enable file locking over the network,
and, optionally, allow the server administrator to set and enforce disk quotas on the NFS exports.
On the client side of the equation, an NFS client simply mounts the exported file systems locally,
just as local disks would be mounted. The mounted file system is known colloquially as an NFS
mount.
Features of NFS4 :
1. NFS4 offers significant security and performance enhancements over older versions of the NFS
protocol and adds features such as replication (the ability to duplicate a server’s exported file
systems on other servers) and migration (the capability to move file systems from one NFS server
to another without affecting NFS clients) that NFS has historically lacked
2. Another security feature added to NFSv4 is support for access control lists, or ACLs. ACLs
build on the traditional Linux UID- and GID-based file and directory access by giving users and
administrators the ability to set more finely grained restrictions on who can read, write, and/or
execute a given file.
3. NFSv4 client might not be able to mount an NFSv2 export
4. In terms of performance enhancements, NFSv4 makes fuller use of clientside caching, which
reduces the frequency with which clients must communicate with an NFS server. By decreasing
the number of server round trips, overall performance increases.
5. NFSv4 was specifically designed (or enhanced) to provide reasonable performance over the
Internet, even on slow, low-bandwidth connections or in high latency situations (such as when
someone on your LAN is downloading the entire Lord of the Rings trilogy).
6. NFSv4 also supports Unicode (UTF-8) filenames, making cross-platform and intercharacter
set file sharing more seamless and more international.
Advantages of NFS
1. the biggest advantage NFS provides is centralized control, maintenance, and administration.
2. NFS can also conserve disk space and prevent duplication of resources.
3. End users also benefit from NFS. When NFS is combined with NIS, users can log in from any
system, even remotely, and still have access to their home directories and see a uniform view of
shared data. Users can protect important or sensitive data or information that would be impossible
or time-consuming to re-create by storing it on an NFS mounted file system that is regularly
backed up.
Disadvantages of NFS
1. As a distributed, network-based file system, NFS is sensitive to network congestion. Heavy
network traffic slows down NFS performance. Similarly, heavy disk activity on the NFS server
adversely affects NFS’s performance. In the face of network congestion or extreme disk activity,
NFS clients run more slowly because file I/O takes longer. The performance enhancements
incorporated in NFSv4 have increased NFS’s stability and reliability on high latency and heavily
congested networks,
2. another disadvantage of NFS is that an exported file system represents a single point of failure.
If the disk or system exporting vital data or application becomes unavailable for any reason, such
as a disk crash or server failure, no one can access that resource.
 3. NFS suffers from potential security problems because its design assumes a trusted network, not
a hostile environment in which systems are constantly being probed and attacked. The

3. Attempt any two of the following: 10

a. How are samba users created? Explain.
If you are using security-server and have assigned a domain instead of a workgroup,
you don’t need to create Samba users since your users will be logging
into a Windows domain controller. In this example though, we will create a
Samba users’ password file. You can convert all of your system users to Samba
users by running the following command:
cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd
This utility creates only the users’ accounts, not their passwords. You need
to create passwords for your users by using the smbpasswd command and the
user’s name as shown here:
[root@terry terry]# smbpasswd terry
New SMB password:
Retype new SMB password:
Password changed for user terry
Password changed for user terry
b. What is server message block protocol? Explain smbclient and smbmount
commands.
Computers running Windows 95 or greater use a protocol called Server Message
Block (SMB) to communicate with each other and to share services such as file and
print sharing. With Samba, the Linux PC icon appears in the Windows Network
Places window, and the files on the Linux PC can be browsedusing Windows
Explorer. The Windows file system can be mounted on your
Linux system, and you can browse the Windows files from your Linux PC. Before
you can use Samba to connect to the Windows computers, it must first be installed on
the Linux PC. All current distributions of Fedora Core and Red Hat Enterprise Linux
include three Samba packages: Samba, Sambaclient, and Samba-common. They may
not have been installed during the system
installation. Even if they have been installed, you should always check for the latest
versions to find out if any problems have been fixed by the latest release and to install
it if necessary.
You can connect your system to any computer that is running the SMB protocol,
whether it is a Windows PC or another Linux system running Samba. The connection
can be made from the command line using two methods. The first uses a utility called
smbclient, and the command syntax is smbclient //computer name/sharename, as
shown in the following example. Be sure
to replace the computer name in the example with the name of your computer.
[root@terry terry]# smbclient //terrycollings/c
added interface ip=192.168.9.93 bcast=192.168.9.255 nmask=255.255.255.0
Got a positive name query response from 192.168.9.102 (192.168.9.102)
Password:
Domain=[Tardis] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
smb: \>
The preceding example shows me logging in to my Windows PC from my Red Hat
system. I was prompted for a password to log in and was given some information
about the Windows system and a command prompt. You can type help at the
command prompt to get a list of possible commands. The commands at the smb
prompt are very similar to command-line FTP commands.
To exit the connection, type exit.

The syntax for this command is smbmount //computer name/directory

/mysystem/mount/point, as shown in the following example:
 [root@terry terry]# smbmount //terrycollings/c /mnt/windows
Password:
Next, you can change to the directory on the system where you mounted the
Windows system by issuing the following command:
[root@terry terry]# cd /mnt/windows\

c. What are the tasks to be performed to setup Timeserver? Explain the steps to
configure NTP Server and NTP client.
Configuring the Time Server
Setting up your time server requires a small amount of preparation, implementation,
and verification. You’ll need to perform the following tasks:
1. Install the NTP software.
2. Locate suitable time servers to serve as reference clocks.
3. Configure your local time server.
4. Start the NTP daemon on the local time server.
5. Make sure that the NTP daemon responds to requests.
NTP Client
Configuring an NTP client requires fewer steps than configuring a server does. You select the
server to use as a reference clock, start the NTP daemon, ntpd, and you’re done. The GUI-
addicted can use the Date/Time Properties tool. Either start it from the menu (Red Hat ➪ System
Settings ➪ Date & Time) ortype system-config-date at a command prompt
d. What is caching proxy server? What are the steps in configuring squid? Explain
A caching proxy
server is software (and potentially hardware) that stores (caches) frequently requested Internet
objects such as Web pages, Java scripts, and downloaded files closer (in network terms) to the
clients that request those objects. When a new request is made for a cached object, the proxy
server provides the object from its cache instead of allowing the request to go to the source. That
is, the local cache serves the requested object as a proxy or substitute for the actual server. The
motivation for using a caching proxy server is two-fold: to provide accelerated Web browsing by
reducing access time for frequently requested objects and to reduce bandwidth consumption by
caching popular data locally, that is, on a server that exists between the requesting client and the
Internet. The HTTP acceleration feature speeds up Web browsing because cached pages need not
be re-retrieved unless the original page has been updated since it was last cached.

The Squid configuration file on Fedora Core and RHEL systems is /etc/squid/squid.conf. The
initialization script that controls Squid is /etc/rc.d/init.d/squid, which reads default values from
/etc /sysconfig/squid. For your initial experimentation with Squid, only modify the Squid
configuration file. It would easily consume several chapters to describe Squid’s configuration and
tuning adequately, so to get you up and running quickly, this section focuses on the bare
minimum. You definitely want to spend some quality time with the configuration file’s
comments, because they are complete, understandable, and do a fine job of telling you more than
you probably want to know about Squid’s care and feeding. Table lists the configuration settings
with which you concern yourself in the short term.
4. Attempt any two of the following: 10
a. Write a short note on SSH.
Secure Shell, also known as SSH, is a secure Telnet replacement that encrypts all traffic,
including passwords, using a public/private encryption key exchange protocol. It provides the
same functionality of Telnet, plus other useful functions, such as traffic tunneling.
This is what it looks like to SSH into a machine for the first time:
[vnavrat@buffy vnavrat$ ssh [email protected]
The authenticity of host ‘woolf.xena.edu (123.456.789.65)’
can’t be established.
RSA key fingerprint is
b2:60:c8:31:b7:6b:e3:58:3d:53:b9:af:bc:75:31:63.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘woolf.xena.edu,123.456.789.65’
(RSA) to the list of known hosts.
[email protected]’s password:
Welcome to woolf
Unauthorized usage prohibited. Please check your quotas.
vnavrat:~>
SSH asks you if you want to accept and trust the host key being sent to you as being the real key.
This question is asked only once when you log in to a machine for the first time. After this first
login, SSH behaves exactly like Telnet — you start SSH, it asks for your password, and then you
see a regular terminal screen.
In addition to providing terminal access, SSH tunnels almost any other protocol through it. So, it
is possible to tunnel POP, RCP, and other protocols through SSH to turn them into encrypted,
more secure protocols. With enough imagination and practice, you can make almost anything
more secure with SSH.
Following is an example of how to tunnel your mail through SSH to keep your password and mail
encrypted and secure during transit. In this example, you use POP3 to retrieve your mail from the
remote machine buffy.xena.edu. Normally you would tell your POP3 software to connect from
your localhost to port 110 (the POP port) of buffy.xena.edu. But in this example the first step is
to configure your POP mailer to connect to port 16510 of your own machine, and put in the
password for your account on buffy.xena.edu. The second step is to set up the SSH tunnel,
which encrypts and forwards the traffic over the network to terry.muhlenberg.edu’s
POP port. To set up the SSH tunnel, type the following at the command line:
ssh -N -L 16510:127.0.0.1:110 [email protected]
And voilà! You are now sending and receiving your mail through an encrypted SSH tunnel.

b. How is xinetd server configured? Explain.

xinetd is a replacement for inetd that adds more security and functionality. inetd is the old
workhorse of the Linux networking world, and xinetd is an improvement on an important
program that has been around for several years. It incorporates new features that have been
desired by system administrators for a few years now. xinetd starts at system boot time, and
waits and listens for connections to come in on the ports to which they are assigned in their conf
files. After a connection request is made, if the service requested requires that a new server be
spawned, then xinetd spawns a new server and keeps listening for new connectionrequests on the
service port. One of the most notable improvements of xinetd over inetd is that anyone
can start network services. With inetd, only root can start a network service, and that restriction
leads to a host of security problems. xinetd supports encrypting plain-text services such as the ftp
command channel by wrapping them in stunnel. xinetd also enables you to do access control on
all services based on different criteria, such as remote host address, access time, remote ostname,
and remote host domain. In the past this kind of access control could be accomplished
 only with tools like tcpwrappers, or firewall software. Even then, tcpwrappers could only
reliably control TCP traffic. xinetd also takes the extra security step of killing servers that aren’t
in the configuration file and those that violate the configuration’s access criteria. It can
help prevent denial of service (DOS) attacks by limiting normal functions that can cripple the
machine if there are too many of them occurring at the same time. For example, xinetd can limit
the number of incoming connections to the whole machine or from a single host to prevent
network overflow attacks. It can limit the number of processes that are forked by a network
service. To prevent the machine from being slowed to a crawl because of the incoming network
traffic, xinetd can also stop a service if it is driving the machine’s load up too high. Log
capabilities have also been improved in xinetd. For each service it runs, it can log the remote user
and host address, the length of time the service has been running, and failed access control
attempts. xinetd is flexible enough to enable you to utilize increased security measures
such as chrooted environments. You may notice that the xinetd.conf file (see Listing 19-4) is
much shorter than inetd.conf, making it easier to read through and customize. The last line says
that all the files in the /etc/xinetd.d directory are read into the xinetd.conf file as well. Each
service started by xinetd gets its own dedicated file in the /etc/xinetd.d directory. This way you
can tell, with a glance at the xinetd.d file listing, what services are being started by it. You can
easily enable or disable a service by setting the value of disable = to either yes or no.
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d

The last line of the xinetd.conf file shown in Listing 19-4 shows the directory location of the
individual configuration files for the services that use xinetd. Listing 19-5 shows the Krb5-telnet
configuration file that is located in the /etc/xinet.d directory.
# default: off
# description: The kerberized telnet server accepts normal telnet sessions, \
# but can also use Kerberos 5 authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
c. What is BIND? Explain the files required to configure BIND server.
The number of files you will use depends on the type of BIND server you want to use. You need
five files to set up the named server. Three files are required regardless of the configuration as a
master, slave, or caching-only server, and two additional configuration files are used on the
master server. There is also the script that is used to start the servers after they are configured, for
a total of six possible files. The three required files are:
■■ named.conf — Found in the /etc directory, this file contains global properties and sources of

configuration 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 localhost. 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.

The following script is used to start the BIND server:

■■ /etc/rc.d/init.d/named — This is the BIND server initialization file used to start BIND. A

sample file is installed with the RPM from the Installation CDs.
d. Explain zone files and reverse zone files.

Zone files contain resource records (RR) about IP addresses. Atypical zone file
is shown.
@ IN SOA localhost root (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS localhost
localhost IN A 127.0.0.1
A zone file can contain many types of RRs, which are listed in the order in
which they generally appear in the zone files.
SOA — Start of Authority
The start of authority (SOA) is the first line in the zone file. The SOA identifies the name server
as the authoritative source for information about that domain. Each zone file has only one SOA,
and it contains the following data:
@ IN SOA main.tactechnology.com. mail.tactechnology.com. (/
2000052101 ; Serial
8h ;Refresh
2h ;Retry
1w ;Expire
1d) ;Minimum TTL
The first character in the SOA line is a special symbol that means “to look at this domain.” IN
means Internet. SOA means Start of authority. In this example, the authoritative server for this
domain is main .tactechnology.com., and mail.tactechnology.com. is the e-mail
address of the administrator. Note the trailing period after the domain names. If these are not
included, the domain name is appended to the entry. The opening parenthesis enables the first line
to be extended so that anything between the opening and closing parenthesis is considered one
line. The information within the parenthesis is passed to other name servers, secondary masters
that use this information to update their records. The line containing 2000052101 ; Serial is the
serial number of the file. Secondary servers compare this number with their stored information. If
the numbers are the same, the information has not changed, and it is not necessary to download
this file. If the serial numbers are different, the file is downloaded to update the information in the
secondary server. The serial number can be any number desired as long as it can be incremented
to indicate a revision to the file. The semicolon indicates that what follows to the end of the line is
a comment.
■■ Refresh — The amount of time the server should wait before refreshing its data.

■■ Retry — The amount of time the server should wait before attempting to contact the primary

server if the previous attempt failed.

■■ Expire — Means that if the secondary master is unable to contact a primary master during the

specified period, the data expires and should be purged.

■■ TTL — Specifies the time to live for the data. This parameter is intended for caching name

servers and tells them how long to hold the data in their cache.
All of the information contained by the SOA may be placed on one line, but it is usually written
as shown previously. The order of the items is significant in the SOA header. Following the SOA
header information are lines containing additional server information. Two of these lines,
containing the abbreviations NS and A are shown in Listing 20-2. These abbreviations are
explained here:
■■ NS — Name servers in this domain.

■■ A— The IP address for the name server.

■■ PTR — Pointer for address name mapping.

■■ CNAME — Canonical name, the real name of the host.

■■ MX — The mail exchange record. The MX record specifies the mail servers for the domain. If

more than one MX server is present priority is determined by the address with the lowest number
receiving the highest priority.
■■ TXT — Text information. You can enter descriptive information here.

■■ WKS — Well-known service. You can enter descriptive information here.

■■ HINFO — Host Information usually shows type of hardware and software.

 The Reverse Zone File
In the previous example you looked at a sample zone file that uses the domain name. This method
is called forward address resolution, since it uses a name to find an IP number and is the most
common use of name resolution. You can also find a name from an IP number, and this is called
reverse address resolution. All you need to do is enter the IP address, and the server
returns the domain name. Reverse address resolution requires the use of a reverse zone file.
Listing 20-3 shows a sample reverse zone file.
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
5. Attempt any two of the following: 10
a. State and explain the components required for email delivery process.
■■ Programs:
■■ A mail user agent for users to be able to read and write email
■■ A mail transfer agent to deliver email messages between computers

across a network
■■ A mail delivery agent to deliver messages to users’ mailbox files

■■ A mail-notification program to tell users that they have new mail

(optional)
■■ The SMTP protocols for packaging email and transferring email messages

between MTAs

b. Explain SMTP, POP3 and IMAP4 protocols.

SMTP specifies message movement between MTAs by the path the message takes. It is
ometimes described as a store-and-forward protocol because messages transmitted via SMTP
don’t necessarily go directly from the sender’s MTA to the recipient’s MTA. Rather, network
conditions and other considerations (not relevant here) might cause email messages to pass
through other MTAs on other network computers. These intermediate MTAs briefly store the
message before forwarding it to another MTA or to a gateway that sends it to an MTA on another
network. The SMTP protocol can transfer only ASCII text. It can’t handle fonts, colors, graphics,
or attachments. If you want to be able to send these items, you need to add another protocol to
SMTP, MIME. MIME stands for Multipurpose Internet Mail Extensions. MIME is implemented
on top of the SMTP protocol and enables you to add colors, sounds, and graphics to your
messages and still deliver them via SMTP. For MIME to work, you must have a MIME- ompliant
MUA(most are). If it isn’t clear yet, SMTP (with or without MIME) has a major shortcoming: it
assumes that the sending and receiving MTAs are always connected to the Internet. What
happens when this assumption fails, say, for users who have dial-up Internet access? Enter POP,
the Post Office Protocol.
Two other protocols are part of the email process: Post Office Protocol version 3, known as
POP3, and Internet Message Access Protocol version 4, known as IMAP4. POP3 was developed
to solve the problem of what happens to messages when the recipient is not connected to the
network. POP3 runs on a server that is connected to a network and that continuously sends and
receives mail. The POP3 server stores any messages it receives until the message recipients
request them.
Without POP3 (or IMAP), and MUA and MTAcan’t communicate. That is, if you want to read
your mail, you need POP3 (or IMAP) to retrieve messages that arrive at your MTA while you’re
offline. POP3 uses the MTA’s storage to hold messages until they are requested. When users
want to check their email, they connect to the POP3 server and retrieve messages that were stored
by the server. After retrieval, the messages are stored locally (that is, locally to the MUA) and
you can use the MUA on your PC to read them at your leisure. Of course, your MUA has to
understand the POP3 to be able to communicate with the POP3 server, but most MUAs speak
fluent POP3 these days so this is rarely a problem. The messages you retrieve to your PC are then
typically removed from the server.
 The Internet Message Access Protocol version 4 (IMAP4) provides much more sophisticated
email-handling functionality than SMTP or POP3 do. IMAP4 has more features. IMAP4 enables
you to store email on a networked mail server, just as POP3 does. The difference is that POP3
requires you to download your email before your MUA reads it, whereas IMAP4 enables your
email to reside permanently on a remote server, from which you can access your mail. And
you can do so from your office, your home, your PDA, your cell phone, or anywhere else. Your
MUA must understand IMAP4 to retrieve messages from an IMAP4 server.

c. What is vsftpd? What are its features? Explain its configuration files.
The default FTP server daemon on Fedora Core and RHEL systems is vsftpd, the Very Secure
FTP Daemon.
Depending on the type of installation you selected, the installer, might or might not have installed
vsftpd. To find out, execute the command rpmquery vsftpd.
By far, the most important (and potentially the longest) vsftpd configuration file is
/etc/vsftpd/vsftpd.conf. The configuration directives in this file enable you to exercise finely
grained control over vsftpd’s behavior. The configuration file itself has a pleasantly simple
format. Each line is either a comment, which begins with #, or a directive. Directives have the
form option=value. Most of the configuration options are Boolean, so they are either on or off,
or, rather, YES or NO. Asecond group of configuration options take numeric values, and a third,
considerably smaller set of configuration options accept string values. To organize the discussion
of /etc/vsftpd/vsftpd.conf, we start with the default configuration file provided in Fedora Core
and RHEL. It is shown in the following listing, with most of the comments removed to preserve
space and to make it easier to read. Like many configuration files, lines that begin with the hash
sign (#) denote comments that the program ignores.
anonymous_enable=YES
local_enable=YES
write_enable=YES
local_umask=022
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
#chown_uploads=YES
#chown_username=whoever
#xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
#idle_session_timeout=600
#data_connection_timeout=120
#nopriv_user=ftpsecure
#async_abor_enable=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
#ftpd_banner=Welcome to blah FTP service.
#deny_email_enable=YES
#banned_email_file=/etc/vsftpd.banned_emails
#chroot_list_enable=YES
#chroot_list_file=/etc/vsftpd.chroot_list
#ls_recurse_enable=YES
pam_service_name=vsftpd
userlist_enable=YES
listen=YES
tcp_wrappers=YES
The first configuration option, anonymous_enable=YES, allows anonymous FTP access. You
can set this to NO if you do not want to enable anonymous FTP. The directive
local_enable=YES allows local users (users with accounts on the system on which vsftpd is
running) to access the system via FTP. Similarly, write_enable=YES enables all variations of
the FTP commands that allow FTP users to modify the file system, such as STOR (the FTP
put and mput commands for uploading files) and DELE (the FTP del command for deleting
files). As a rule, it is unwise to permit FTP users to modify the file system, so if security is a
concern, you might consider disabling write commands by setting write_enable to NO.
At first glance, it might seem reasonable to grant local users write access, or at least to be able to
log in. However, the reason local users should not be allowed to log in is that FTP is a clear-text
protocol; usernames and, more importantly, passwords, are transmitted in clear text. Anyone with
a packet sniffer monitoring IP traffic to and from your FTP server’s IP address can grab
 the authentication information and use it to compromise your system. Where FTP is concerned,
one can argue that anonymous access is actually less of a security risk than normal, authenticated
access because anonymous FTP does not require transmitting sensitive passwords over the wire.
In fact, for local users, sftp sftp, part of the OpenSSH suite of programs, is vastly superior to
plain vanilla FTP because it encapsulates FTP inside a secure, encrypted communication session
(see “Using SFTP” at the end of this chapter).
The directives anon_upload_enable=YES and anon_mkdir_write_ enable=YES control
whether or not anonymous FTP users can upload files and create directories, respectively. These
two directives are commented out, so anonymous uploads are disabled. Hopefully, it is obvious
that allowing anonymous uploads is potentially dangerous. That said, should you decide to
permit anonymous uploads, you will want to investigate additional vsftpd configuration directives
that restrict this type of access. The various xferlog directives xferlog_enable, xferlog_file, and
xferlog_std_format, control t he location of the transfer log and the formatof entries in this log
file. If xferlog_enable is set to YES, file uploads (if permitted) and downloads are recorded in a
log file, widely referred to using the shorthand expression xferlog. The xferlog_file directive
specifies the name of the xferlog file. The default log file is /var/log/vsftpd.log, which
should be suitable for most purposes. If you want to capture file transfers in a more mnemonically
named file, you might use xferlog_file=/var/log /xfer.log, but this is only a suggestion.
If you want to change the log entry format from the standard format, set
xferlog_std_format=NO and add the directive log_ftp_protocol=YES, which will cause all
FTP protocol requests to be dumped into the log file. Again, the standard format should be fine.
Logging FTP at the protocol level is mostly valuable when trying to isolate server or network
problems or debugging vsftpd itself.

d. How can anonymous uploads and guest user accounts be enabled vsftpd? Explain.
Enabling anonymous uploads is also like teaching a pig to sing, but we’re not going to beat that
simile into the ground (but we will mangle a metaphor if we can get away with it). Seriously,
anonymous uploads pose all sorts of security risks. The two that come to mind are someone
uploading a virus or trojan to your server and having your FTP server become a warez server, that
is, a transfer point for illegal or cracked copies of software, music, and/or movies. Becoming
a warez server isn’t so much a security risk as it is a freedom risk, as in, the authorities might put
you in jail if they discover you’re running a warez server.
1. Edit /etc/vsftpd/vsftp.conf and change or add the entries
shown in Table 22-2.
2. Create a directory for anonymous uploads:
# mkdir /var/ftp/incoming
3. Change the permissions of /var/ftp/incoming:
# chmod 770 /var/ftp/incoming
# chmod g+s /var/ftp/incoming
The first chmod command give the user and group full access to
/var/ftp/incoming. The second command turns on the set-group
ID (colloquially known as setgid or sgid) bit on the directory, causing
any file created in this directory to have its group ownership set to the
group that owns the directory.
4. Make the ftp user the group owner of /var/ftp/incoming:
# chgrp ftp /var/ftp/incoming
5. Restart vsftpd:
# service vsftpd restart
These steps create a directory, /var/ftp/incoming, to which anonymous FTP users can upload
files but from which no one can retrieve files. Nor can anyone see a directory listing of the upload
directory during an FTP session. What is a guest FTP user? Why would you want to use this
feature? A guest user, referred to in vsftpd’s documentation as a virtual user, describes any
nonanonymous login that uses a login name that does not exist as a real login account on the FTP
server. The purpose of guest user accounts is to provide broader privileges to FTP users than
anonymous FTP provides without giving local users FTP access. Recall the discussion of why
local user FTP access is a dodgy proposition: it exposes local user’s authentication information to
packet sniffers because FTP is a clear-text protocol. Guest users provide a measure of security
because if the guest account is somehow compromised, it has access to only the FTP server, not
to the system as a whole. Guest users also serve as an administrative convenience because you
can create a guest user that has access to certain files that are not available to anonymous users.
You can create multiple guest users each with their own specific access rights and FTP
environments, too, although the guest user configuration presented in this section describes only a
single guest account. To create a guest user account, use the following procedure.
1. Create a guest user account:
# useradd -d /var/ftp/rhlnsa3 -s /sbin/nologin authors
This command created the user authors with a home directory of /var/ftp/rhlnsa3 and a login
shell of /sbin/nologin, which disableslocal logins for that account.
2. Add some content to this directory:
# echo ‘This is a test file.’ > /var/ftp/rhlnsa3/test.file
# chown authors:authors /var/ftp/rhlnsa3/test.file
The first command creates simple text file named /var/ftp/rhlnsa3
/test.file. The second command chang es the user and group ownership to authors.
3. Decide who will be permitted to access the authors account and then create a text file that with
pairs of lines that specify the login name and password.
bubba
grits
marysue
greens
In this example, the users are named bubba and marysue and their
passwords are grits and greens, respectively. They are stored in a
file named virtusers.txt.
4. Create a Berkeley database file from the text file you created in Step 3.
Use the following command:
# db_load -T -t hash -f virtusers.txt /etc/vsftpd/vsftpd_login.db
This command creates a database file with the contents of virtusers .txt and stores it in
/etc/vsftpd/vsftpd_login.db. For additional security, change the permissions on the generated
file so that only root owns it:
# chmod 600 /etc/vsftpd/vsftpd_login.db
5. Create a PAM (Pluggable Authentication Module) file in /etc/pam.d that contains the
following entries:
auth required /lib/security/pam_userdb.so db=/etc/vsftpd/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd/vsftpd_
login
You can use the vsftpd.pam file in this chapter’s code directory on the included CD-ROM.
These directives tell the PAM user database module to use the vsftpd_login.db file (the .db
extension is assumed) for FTP logins.
6. Edit /etc/vsftpd/vsftpd.conf, adding the following entries or editing existing ones to match:
pam_service_name=ftp
guest_enable=YES
guest_username=authors
local_enable=YES
write_enable=NO
anon_world_readable_only=NO
chroot_local_users =YES
pam_service_name=ftp tells vsftpd to use the PAM file you created in Step 5.
guest_enable=YES enables guest user functionality. guest_username=authors maps all
guest logins to the authors account created in Step 1. local_enable=YES permits local users to
login, which is required for guest users. The anon_world_readable_ only=NO directive makes
the contents of the /var/ftp/rhlnsa3 directory readable by guest users. Finally,
chown_local_users=YES
causes vsftpd to chroot the authors user to /var/ftp/rhlnsa3.
7. Start, or restart, the vsftpd service:
# service vsftpd restart
8. Test it out, using one of the user/password combinations you created in
Step 3:
$ ftp localhost
Connected to localhost.localdomain.
220 (vsFTPd 2.0.1)
530 Please login with USER and PASS.
Name (localhost:bubba): marysue
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
 227 Entering Passive Mode (127,0,0,1,253,85)
150 Here comes the directory listing.
-rw-r--r-- 1 503 504 8192 Mar 20 15:44 ch22.doc
226 Directory send OK.
ftp> quit
The password typed at the prompt was greens. For the record, the
user marysue does not have a local login account; she only exists in
vsftpd’s guest user database (/etc/vsftpd/vsftpd_login.db).

6. Attempt any two of the following: 10

a. Explain the working and features of Apache web server. The Apache Web server’s origins
are the National Center for Supercomputing Applications (NCSA) HTTP server (referred to as
httpd in this chapter). NCSA’s httpd was the most popular of the early HTTP servers, and its source
code was in the public domain. After NCSA’s active development of their httpd effectively stopped
(late 1994 and early 1995), a small group of Web administrators who had modified the source code
to address their own sitespecific needs or to patch various bugs gathered together to coordinate their
activities and merge their code changes into a single code tree.
In April 1995, this loosely organized group of Web masters, the original Apache Group, released
the first official version of Apache intended for public consumption, Apache 0.6.2. Despite its
known warts, the Apache server was instantly popular. However, even as the development team
continued to stabilize the existing code base, add new features, and generate documentation,
other members undertook a fundamental redesign that rather quickly (August 1995) resulted in
Apache 0.8.8. This first (beta) release based on the redesigned architecture still bears a strong
resemblance to the Apache available today. Another round of code base stabilization, bug fixes,
feature enhancements, and documentation updates concluded on November 30, 1995. The next
day, December 1, 1995, the Apache Group released Apache 1.0, the version that
cemented Apache’s status as the Internet’s number 1 HTTP server. Although the actual numbers
fluctuate and overall growth of Apache’s usage (and of the Web servers in general) has begun to
flatten out, periodic Internetwide surveys conducted by Netcraft (www.netcraft.com/survey)
consistently demonstrate that even 10 years after its first releases, Apache continues to
be the most widely used Web server, surpassing all other Web servers combined.
Apache Features
The complete list of Apache’s features easily runs to three or four pages, far too many and far too
tedious to recite here. In fact, many of its “features” are downright mundane because it performs
the same function as any other Web server: sending some data down the wire in response to a
properly formatted request from a Web client. These features are more properly called
“functionality” because Apache is a standards-driven program providing mandated
functionality. That is, many of its capabilities are the result of its full compliance with version 1.1
of the HTTP protocol. Apache implements all the required functionality described in RFC2616,
the document that defines the current Web server protocol, HTTP/1.1 (HyperText Transfer
Protocol version 1.1). Of course, the manner in which Apache implements mandated features is
anything but mundane.
Apache’s standout qualities are its speed, configurability, stability, and rich feature set. Most
benchmark studies have shown Apache to be faster than many other Web servers, including
commercial servers. Apache is also both easy to configure and easy to reconfigure. Its
configuration information resides in plain-text files and uses simple English-language directives.
Reconfiguring a running server is a simple matter of changing the appropriate configuration
directive and reloading the configuration file. Few seriously question Apache’s stability, even
among its competitors. Sites receiving millions of hits each day report no problems. Moreover,
while no software product of any complexity can be considered bug-free, Apache is
beset with fewer (known) bugs than other Web servers, particularly closed source servers. Many
factors contribute to Apache’s stability, but the two most important are eyeballs and axle grease.

b. How is virtual server configured? Explain virtual server configuration directives.

Apache has a notion of a default or primary server, which refers to the httpd server that responds
to any HTTP requests not handled by virtual hosts, also known as virtual servers. Without going
into detail yet, a virtual server or virtual host is an httpd process running on the same machine as
the default server,which is distinguished from the primary server by the hostname or IP address
 assigned to the virtual host. Despite the distinction between primary and virtual servers,
configuration directives defined for the primary server also apply to virtual servers unless
specifically overridden.
Virtual servers (also referred to as virtual hosts) are primarily used to run Web servers for
multiple domains on a single physical system. Virtual servers can also be used to allow multiple
workgroups or departments that share the same network or subnet to maintain independent Web
pages without requiring individual dedicated departmental servers. Virtual hosts fall into two
categories: IP-based virtual hosts and name-based virtual hosts.
IP-based virtual hosts refer to Web servers that have different IP addresses. In some cases, the
different IP addresses correspond to different Ethernet interfaces, such as eth0 and eth1
(machines that have multiple Ethernet interfaces are called multihomed hosts). In other cases, a
single Ethernet interface is assigned multiple IP addresses using aliases. In this configuration, a
system
might have a single Ethernet interface, say, eth0, and a single primary IP
addresses, for example, 192.168.0.1. The aliases have IP addresses of the form
192.168.0.1:n, where n is a digit such as 1, 2, or 3. Regardless of the method you
use to implement virtual hosts, end users will not realize that the Web sites
they are viewing reside on the same physical server. Table 23-3 shows the
Apache configuration directives that control the configuration and behavior of
virtual servers.
A bare-bones set of name-based virtual server definitions might resemble
the following:
Listen 80
[...]
NameVirtualHost *:80
<VirtualHost *:80>
ServerName webbeast.example.com
DocumentRoot /var/www/webbeast
# other directives
</VirtualHost>
<VirtualHost *:80>
ServerName www.mydomain.com
DocumentRoot /var/www/mydomain
# other directives
</VirtualHost>
<VirtualHost *:80>
ServerName www.yourdomain.org
DocumentRoot /var/www/yourdomain
# other directives
</VirtualHost>
This example shows three virtual hosts, webbeast.example.com, www
.mydomain.com, and www.yourdomain.org, all of which have the same IP address. For the
purpose of this example, the actual IP address doesn’t matter because the asterisks match all IP
addresses, but suppose that the address is 192.168.0.2. One of the side effects of using the asterisk
is that the main server won’t answer any requests. Apache will pass all requests to the appropriate
virtual host, depending on the name specified in the request. Furthermore, the virtual host
webbeast.example.com is the default or primary server because it is the first listed host. As a
result, it will answer any request that isn’t answered by one of the other virtual hosts.
As stated earlier in the chapter, configuration directives for the default
server also apply to virtual servers unless specifically overridden in a <VirtualHost> block.
Therefore, if your virtual hosts require special configuration needs not provided or explicitly
disabled or disallowed in the default server, you must specify these custom configuration
directives inside the appropriate <VirtualHost> block.
c. What are the advantages of shadow passwords over traditional password system?
Shadow passwords offer a number of distinct advantages over the traditional password system,
including:
◆ Improved system security by moving the encrypted passwords (normally
found in /etc/passwd) to /etc/shadow, which is readable only by root
◆ Information concerning password aging, how long it has been since a
password was last changed
◆ Control over how long a password can remain unchanged before the user
is required to change it
◆ Settings in /etc/login.defs, particularly concerning passwords to give
you the ability to set and enforce a security policy
d. Explain the command to binary packages be built from source rpm packages with
different valid build stages.

7. Attempt any three of the following: 15

a. Compare GRUB and LILO boot loaders.
b. An ISP is granted a block of addresses starting with 190.100.0.0/16 (65,536 addresses).
The ISP needs to distribute these addresses to three groups of customers as follows:
 The first group has 64 customers; each needs approximately 256 addresses.
 The second group has 128 customers; each needs approximately 128 addresses.
 The third group has 128 customers; each needs approximately 64 addresses.
Design the sub blocks and find the number of addresses still available after the above
allocations.
c. Explain the different sections of smb.conf file.
[global]
The first section of the smb.conf file is the [global] section. The [global] section contains
settings that apply to the entire server and default settings that may apply to the other shares. The
[global] section contains a list of options and values in the following format:
option = value You have hundreds of options and values at your disposal, and you look at
the most common ones here. For a complete listing of options, refer to the smb.conf man page.
Some of the more significant options are:
■■ workgroup = Tardis — This is the name of the workgroup shown in the identification tab of

the network properties box on the Windowscomputer.

■■ smb passwd file = /etc/samba/smbpasswd — This shows the path to the location of the

Samba password file. Be sure that you include this option/value pair in your smb.conf file.
■■ encryptpasswords = yes — Beginning with Windows NT service pack 3 and later, passwords

are encrypted. If you are connecting to any systems running these versions of Windows, you
should choose encrypted passwords.
■■ netbios name = RHL — This is the name by which the Samba server is known to the

Windows computer.
■■ server string = Samba Server — This is shown as a comment on the Windows PC in the

network browser.
■■ security = user — This is the level of security applied to server access. Other options are share,

domain, and server. Share is used to make it easier to create anonymous shares that do not require
authentication, and it is useful when the NetBIOS names of the Windows computers
are different from other names on the Linux computer. Server is used to specify the server to use
if the password file is on another server in the network. Domain is used if the clients are added to
a Windows NT domain using smbpasswd, and login requests are executed
by a Windows NT primary or backup domain controller.
■■ log file = /var/log/samba/log—This is the location of the log file.

■■ max log size = 50— This is the maximum size in kilobytes that the file can grow to.

■■ socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF= 8192 — This

enables the server to be tuned for better performance. TCP_NODELAY is a default value; the
BUF values set send andreceive buffers.
■■ dns proxy = No— This indicates that the NetBIOS name will not be treated like a DNS name

and that there is no DNS lookup.

[homes]
The next section of the smb.conf file, [homes], is used to enable the server to give users quick
access to their home directories. Refer to the smb.conf man page for a more complete
description of how the [homes] section works.
■■ comment = Home Directories — A comment line.

■■ browseable = yes — Means that the directory will appear in the Windows file browser.
■■ writeable = yes — Means that users can write to their directories.

■■ create mode = 0664—Sets the default file permissions for files created in the directory.

■■ directory mode = 0775 — Sets the default permissions for created directories.
 ■■max connections = 1 — The maximum number of simultaneous connections allowed. Setting
this number to 1 prevents a user from logging in to the server from more than one location.
Setting this number to 2 allows a user to log in from two locations and so on. Setting this number
to 0 allows an unlimited number of connections.
[printers]
This section sets the options for printing.
■■ path = /var/spool/samba — The location of the printer spool directory.

■■ printable = yes — Enables clients to send print jobs to the specified directory. This option

must be set, or printing does not work.

■■ browseable = yes—Means that the printer appears in the browse list.

d. What is scp? Explain with example.

scp
Secure Copy, also known as scp, is part of the SSH package. It is a secure alternative
to RCP and FTP, because, like SSH, the password is not sent over the network in plain text. You
can scp files to any machine that has an ssh daemon running.
The syntax of scp is
scp user@host:file1 user@host:file2

[terry@terry ~]$ scp camcontrol.doc terry@main:/home/terry

terry@main’s password:
camcontrol.doc 100% 117KB 117.0KB/s 00:00
And to copy a file named nasatoc.doc from remote host main to your current directory on local
host terry,
[terry@terry ~]$ scp main:/home/terry/nasatoc.doc .
terry@main’s password:
nasatoc.doc 100% 20KB 20.0KB/s 00
If you have KDE installed on your system, you can use the Konqueror browser and the fish
protocol to establish an SSH connection to a remote PC. Then you can drag and drop the files or
directories you want to copy between the remote and local machine. Follow the steps here:
1. Open the Konqueror browser, enter fish://<name or IP address
of remote PC> into the browser location field and press Enter. If this is the first time you are
connecting to the remote host, you will be prompted about the connection, as shown in Figure 19-
1. Click Enter to accept the information.
2. When prompted, enter the username and password and click OK to connect..
3. To copy or move files or directories from the remote PC to the local PC, select the files or
directories you want to copy or move, right-click the selected items and either copy to or move
the selected items from the pop-up menu, and browse to where you want to place them.

e. What are the features of Postfix Mail Server? Explain its primary configuration file.
Postfix’s primary configuration file is /etc/postfix/main.cf. You will need to check or edit at
least the following variables:
■■ The mydomain variable specifies your domain name:
mydomain = example.com
■■ The myhostname variable identifies the local machine’s fully qualified domain name:
myhostname = coondog.example.com
■■The myorigin variable identifies the domain name appended to unqualified addresses (that is,
usernames without the @example.com
goober attached):
myorigin = $mydomain
This causes all mail going out to have your domain name appended.
Thus, if the value of mydomain is possum_holler.com and your
username is bubba, then your outgoing mail will appear to come from
bubba@possum_holler.com.
■■ The mydestination variable tells Postfix what addresses it should

deliver locally. For a standalone workstation, which is a system that is

connected directly to the Internet and that has some sort of domain
name resolution running, you want mail to that machine and to
localhost (and/or localhost.$mydomain and/or localhost
.locadomain) delivered locally, so the following entry should suffice:
mydestination = $myhostname, localhost, localhost.$mydomain
Postfix supports a larger number of configuration variables than the four
 just listed, but these are the mandatory changes you have to make.
Create or modify /etc/aliases. At the very least, you need aliases for
Postfix, postmaster, and root in order for mail sent to those addresses to get to
a real person. Here are the contents of my initial /etc/aliases file:
postfix: root
postmaster: root
root: bubba
After creating or modifying the aliases file, regenerate the alias database
using Postfix’s newaliases command:
# /usr/sbin/newaliases
You are finally ready to start Postfix:
# service postfix start
Starting postfix: [ OK ]
Make sure that Postfix will start when you boot the system. This should be
taken care of by the MTA switching tool, but it never hurts to double-check.
You can use the chkconfig commands shown in the following example:
# chkconfig --levels 0123456 sendmail off
# chkconfig --levels 0123456 postfix off
# chkconfig --levels 2345 postfix on
Finally, modify your syslog configuration to handle Postfix log messages
appropriately. Many system administrators, including the authors, prefer that
mail log messages go to their own files to avoid cluttering up the primary system
log. So, we use the following entries in /etc/syslog.conf, which controls
the system log:
*.info;*.!warn;authpriv.none;cron.none;mail.none; -/var/log/messages
*.warn;authpriv.none;cron.none;mail.none; -/var/log/syslog
mail.*;mail.!err -/var/log/mail.log
mail.err -/var/log/mail.err
The first two lines keep any mail-related messages from being logged to
/var/log/messages and /var/log/syslog. The third line logs everything
but errors to /var/log/mail.log. The last line drops all error messages
from Postfix into /var/log/mail.err. The - character before each
filename tells the system logging daemon, syslogd, to use asynchronous
writes, which means that the logging daemon does not force log messages out
to the specified file before returning control to the system. This measure helps
Postfix run somewhat faster, especially on a heavily loaded system but can
lead to data loss if the machine crashes before buffered data is flushed to disk.
Naturally, you have to restart syslogd syslogd to cause these changes to
take effect:
# service syslog restart
At this point, you have a basic, functional Postfix installation. There is a
great deal more customization that you can do and might want to do, but what
has been covered here should get you started and offer some insight into the
simplicity of Postfix installation and configuration.

f. What is sudo? What are its features? How does sudoseesion work after the creation of
configuration file?
Considering root’s privileges, you can easily understand why root access on a Linux system is
carefully protected and the root password tightly guarded. Nevertheless, it is often desirable to
grant privileges to a nonroot user (humorously referred to as merely mortal user) that have
traditionally been solely root’s domain, such as printer management, user account administration,
system backups, or maintaining a particular Internet service. In other operating systems,
such users are often called wheel users or administrative users. Indeed, in many environments,
subdividing system administration responsibilities is a necessity because the responsibilities of
maintaining multiple servers in a large IT shop or ISP can quickly overwhelm a single individual.
The problem in such a situation is clear: How do you grant administrative privileges to
merely mortal users without providing unfettered root access? In many situations, Sudo, a
mnemonic for superuser do, is one solution. Sudo enables you to give specific users or groups of
users the ability to run some (or all) commands requiring root privileges. Sudo also logs all
commands executed, which allows you to maintain an audit trail of the commands executed, by
whom they were executed, when they were executed, and so on. As the README in the source
distribution states, Sudo’s “basic philosophy is to give as few privileges as
possible but still allow people to get their work done.” Sudo’s features include:
■■ Enabling the ability to restrict the commands a given user may run on a per-host basis.

■■ Maintaining a clear audit trail of who did what. The audit trail can use the system logger or

Sudo’s own log file. In fact, you can use Sudo in lieu of a root shell to take advantage of this
logging.
■■ Limiting root-equivalent activity to a short period of time using timestamp based “tickets,” thus

avoiding the potential of leaving an active root shell open in environments where others can
physically get to your keyboard.
■■ Allowing a single configuration file, /etc/sudoers, to be used on multiple machines, permitting

both centralized Sudo administration and the flexibility to define a user’s privileges on a per host
basis.
After the configuration file has been created, a typical Sudo session proceeds
as follows:
1. An authorized user prefixes the root command she wants to execute
with sudo followed by a space, for example:
$ sudo shutdown -h +5 “System shutting down for disk replacement”
2. Sudo prompts the user for her personal password (not the root password)
and then checks the configuration file (/etc/sudoers) to make
sure she has permission to run the given command on a given machine.
The password prompt can be overridden by specifying the NOPASSWD
flag in /etc/sudoers, but this poses as security risk, so we don’t
cover the NOPASSWD flag in this section.
3. If the user is permitted to use that command, Sudo runs the command
as root (or another user if specified), logs the details, and timestamps the Sudo session ticket.
many environments, subdividing system administration responsibilitie s is a necessity because the
responsibilities of maintaining multiple servers in a large IT shop or ISP can quickly overwhelm a
single individual. The problem in such a situation is clear: How do you grant administrative
privileges tomerely mortal users without providing unfettered root access? In many situations,
Sudo, a mnemonic for superuser do, is one solution. Sudo enables you to give specific users or
groups of users the ability to run some (or all) commands requiring root privileges. Sudo also logs
all commands executed, which allows you to maintain an audit trail of the commands executed,
by whom they were executed, when they were executed, and so on. As the README in the
source distribution states, Sudo’s “basic philosophy is to give as few privileges as
Possibl but still allow people to get their work done.” Sudo’s features include:
■■ Enabling the ability to restrict the commands a given user may run on a per-host basis.

■■ Maintaining a clear audit trail of who did what. The audit trail can use the system logger or

Sudo’s own log file. In fact, you can use Sudo in lieu of a root shell to take advantage of this
logging.
■■ Limiting root-equivalent activity to a short period of time using timestamp based “tickets,” thus

avoiding the potential of leaving an active root shell open in environments where others can
physically get to your keyboard.
■■ Allowing a single configuration file, /etc/sudoers, to be used on multiple machines, permitting

both centralized Sudo administration and the flexibility to define a user’s privileges on a per host
basis.
After the configuration file has been created, a typical Sudo session proceeds
as follows:
1. An authorized user prefixes the root command she wants to execute
with sudo followed by a space, for example:
$ sudo shutdown -h +5 “System shutting down for disk replacement”
2. Sudo prompts the user for her personal password (not the root password)
and then checks the configuration file (/etc/sudoers) to make
sure she has permission to run the given command on a given machine.
The password prompt can be overridden by specifying the NOPASSWD
flag in /etc/sudoers, but this poses as security risk, so we don’t
cover the NOPASSWD flag in this section.
3. If the user is permitted to use that command, Sudo runs the command
as root (or another user if specified), logs the details, and timestamps
the Sudo session ticket.