LINUX TRAINING - HP

Study of Domain Name System (DNS) & Yellowdog Updater Modified(YUM) Servers

Submitted to: Dr. Anil Kumar Singh

ACKNOWLEDGEMENT

I am highly indebted to Dr. Anil Kumar Singh (Faculty- Linux Administration with Scripting) and HPES Trainers and Management for their guidance and constant supervision as well as for providing necessary information regarding the project & also for their support in completing the project. It has been a learning experience for the team members.

TABLE OF CONTENTS

SR No TOPIC 1 2 3 4 5 6 7 8 9 10 11 12 13 Domain name system-introduction Domain name space

PAGE NO 4 5

International Domain Names and Name servers 7 Authoritative Name Servers DNS resolvers Circular dependencies and glue records Reverse and Client records DNS resource records Security issues Configuring DNS Configuring YUM Server Using YUM References and Bibliography 8 9 10 11 12 13 14 17 18 21

DOMAIN NAME SYSTEM

Introduction
The Domain Name System (DNS) is a hierarchical naming system built on a distributed database for computers, services, or any resource connected to the Internet or a private network. Most importantly, it translates domain names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.32.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8(IPv6). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed and fault tolerant and has helped avoid the need for a single central register to be continually consulted and updated. In general, the Domain Name System also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet. Other identifiers such as RFID tags, UPCs, International characters in email addresses and host names, and a variety of other identifiers could all potentially use DNS. The Domain Name System also specifies the technical functionality of this database service. It defines the DNS protocol, a detailed definition of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite.
4

The Internet maintains two principal namespaces, the domain name hierarchy and the Internet Protocol (IP) address system. The Domain Name System maintains the domain namespace and provides translation services between these two namespaces. Internet name servers and a communication protocol implement the Domain Name System. A DNS name server is a server that stores the DNS records for a domain name, such as address (A) records, name server (NS) records, and mail exchanger (MX) records. A DNS name server responds with answers to queries against its database.

The Domain Name Space

Managing a large and constantly changing set of names is a nontrivial problem. In the postal system, name management is done by requiring letters to specify (implicitly or explicitly) the country, state or province, city, and street address of the addressee. By using this kind of hierarchical addressing, there is no confusion between the Marvin Anderson on Main St. in White Plains, N.Y. and the Marvin Anderson on Main St. in Austin, Texas. DNS works the same way. Conceptually, the Internet is divided into over 200 top-level domains, where each domain covers many hosts. Each domain is partitioned into subdomains, and these are further partitioned, and so on. All these domains can be represented by a tree, as shown in figure. The leaves of the tree represent domains that have no subdomains (but do contain machines, of course). A leaf domain may contain a single host, or it may represent a company and contain thousands of hosts. A Portion of Internet Domain Name Space

The top-level domains come in two flavors: generic and countries. The original generic domains were com (commercial), edu (educational institutions), gov (the U.S. Federal Government), int (certain international organizations), mil (the U.S. armed forces), net (network providers), and org (nonprofit organizations). The country domains include one entry for every country, as defined in ISO 3166.
5

In November 2000, ICANN approved four new, general-purpose, top-level domains, namely, biz (businesses), info (information), name (people's names), and pro (professions, such as doctors and lawyers). In addition, three more specialized top-level domains were introduced at the request of certain industries. These are aero (aerospace industry), coop (co-operatives), and museum (museums). Other top-level domains will be added in the future. As an aside, as the Internet becomes more commercial, it also becomes more contentious. Take pro, for example. It was intended for certified professionals. But who is a professional? And certified by whom? Doctors and lawyers clearly are professionals. But what about freelance photographers, piano teachers, magicians, plumbers, barbers, exterminators, tattoo artists, and mercenaries? Are these occupations professional and thus eligible for pro domains? And if so, who certifies the individual practitioners? In general, getting a second-level domain, such as name-of-company.com, is easy. It merely requires going to a registrar for the corresponding top-level domain (com in this case) to check if the desired name is available and not somebody else's trademark. If there are no problems, the requester pays a small annual fee and gets the name. By now, virtually every common (English) word has been taken in the com domain. Try household articles, animals, plants, body parts, etc. Nearly all are taken. Each domain is named by the path upward from it to the (unnamed) root. The components are separated by periods (pronounced ''dot''). Thus, the engineering department at Sun Microsystems might be eng.sun.com., rather than a UNIX-style name such as /com/sun/eng. Notice that this hierarchical naming means that eng.sun.com does not conflict with a potential use of eng in eng.yale.edu., which might be used by the Yale English department. Domain names can be either absolute or relative. An absolute domain name always ends with a period (e.g., eng.sun.com.), whereas a relative one does not. Relative names have to be interpreted in some context to uniquely determine their true meaning. In both cases, a named domain refers to a specific node in the tree and all the nodes under it. Domain names are case insensitive, so edu, Edu, and EDU mean the same thing. Component names can be up to 63 characters long, and full path names must not exceed 255 characters. In principle, domains can be inserted into the tree in two different ways. For example, cs.yale.edu could equally well be listed under the US country domain as cs.yale.ct.us. In practice, however, most organizations in the United States are under a generic domain, and most outside the United States are under the domain of their country. There is no rule against registering under two top-level domains, but few organizations except multinationals do it (e.g., sony.com and sony.nl).

Each domain controls how it allocates the domains under it. For example, Japan has domains ac.jp and co.jp that mirror edu and com. The Netherlands does not make this distinction and puts all organizations directly under nl. Thus, all three of the following are university computer science departments: 1. cs.yale.edu (Yale University, in the United States) 2. cs.vu.nl (Vrije Universiteit, in The Netherlands) 3. cs.keio.ac.jp (Keio University, in Japan) To create a new domain, permission is required of the domain in which it will be included. For example, if a VLSI group is started at Yale and wants to be known as vlsi.cs.yale.edu, it has to get permission from whoever manages cs.yale.edu. Similarly, if a new university is chartered, say, the University of Northern South Dakota, it must ask the manager of the edu domain to assign it unsd.edu. In this way, name conflicts are avoided and each domain can keep track of all its subdomains. Once a new domain has been created and registered, it can create subdomains, such as cs.unsd.edu, without getting permission from anybody higher up the tree. Naming follows organizational boundaries, not physical networks. For example, if the computer science and electrical engineering departments are located in the same building and share the same LAN, they can nevertheless have distinct domains. Similarly, even if computer science is split over Babbage Hall and Turing Hall, the hosts in both buildings will normally belong to the same domain.

Internationalized Domain Names

The permitted character set of the DNS prevented the representation of names and words of many languages in their native alphabets or scripts. ICANN has approved the Internationalizing Domain Names in Applications (IDNA) system, which maps Unicode strings into the valid DNS character set using Punycode. In 2009 ICANN approved the installation of IDN country code top-level domains. In addition, many registries of the existing top-level domain names (TLD)s have adopted IDNA.

Name Servers
The Domain Name System is maintained by a distributed database system, which uses the clientserver model. The nodes of this database are the name servers. Each domain has at least one authoritative DNS server that publishes information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers, the servers to query when looking up (resolving) a TLD.

Authoritative Name Server

An authoritative name server is a name server that gives answers that have been configured by an original source, for example, the domain administrator or by dynamic DNS methods, in contrast to answers that were obtained via a regular DNS query to another name server. An authoritative-only name server only returns answers to queries about domain names that have been specifically configured by the administrator. An authoritative name server can either be a master server or a slave server. A master server is a server that stores the original (master) copies of all zone records. A slave server uses an automatic updating mechanism of the DNS protocol in communication with its master to maintain an identical copy of the master records. Every DNS zone must be assigned a set of authoritative name servers that are installed in NS records in the parent zone. When domain names are registered with a domain name registrar their installation at the domain registry of a top level domain requires the assignment of a primary name server and at least one secondary name server. The requirement of multiple name servers aims to make the domain still functional even if one name server becomes inaccessible or inoperable. The designation of a primary name server is solely determined by the priority given to the domain name registrar. For this purpose generally only the fully qualified domain name of the name server is required, unless the servers are contained in the registered domain, in which case the corresponding IP address is needed as well. Primary name servers are often master name servers, while secondary name server may be implemented as slave servers. An authoritative server indicates its status of supplying definitive answers, deemed authoritative, by setting a software flag (a protocol structure bit), and called the Authoritative Answer (AA) bit in its responses. This flag is usually reproduced prominently in the output of DNS administration query tools (such as dig) to indicate that the responding name server is an authority for the domain name in question.

Recursive and Caching Name Server

In principle, authoritative name servers are sufficient for the operation of the Internet. However, with only authoritative name servers operating, every DNS query must start with recursive queries at the root zone of the Domain Name System and each user system must implement resolver software capable of recursive operation.

To improve efficiency, reduce DNS traffic across the Internet, and increase performance in enduser applications, the Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in the configuration (time-to-live) of the domain name record in question. Typically, such caching DNS servers, also called DNS caches, also implement the recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers of the queried domain. With this function implemented in the name server, user applications gain efficiency in design and operation. The combination of DNS caching and recursive functions in a name server is not mandatory; the functions can be implemented independently in servers for special purposes. Internet service providers typically provide recursive and caching name servers for their customers. In addition, many home networking routers implement DNS caches and recursors to improve efficiency in the local network.

DNS Resolvers

Working of DNS Resolver Let us suppose the local name server has never had a query for this domain before and knows nothing about it. It may ask a few other nearby name servers, but if none of them know, it sends a UDP packet to the server for edu given in its database, edu-server.net. It is unlikely that this server knows the address of linda.cs.yale.edu, and probably does not know cs.yale.edu either, but it must know all of its own children, so it forwards the request to the name server for yale.edu (step 3). In turn, this one forwards the request to cs.yale.edu (step 4), which must have the authoritative resource records. Since each request is from a client to a server, the resource record requested works its way back in steps 5 through 8. Once these records get back to the cs.vu.nl name server, they will be entered into a cache there, in case they are needed later. However, this information is not authoritative, since changes made at cs.yale.edu will not be propagated to all the caches in the world that may know about it. For this reason, cache entries should not live too long. This is the reason that the Time_to_live field is included in each resource record. It tells remote name servers how long to cache records. If a certain machine has had the same IP address for years, it may be safe to cache that information

for 1 day. For more volatile information, it might be safer to purge the records after a few seconds or a minute. It is worth mentioning that the query method described here is known as a recursive query, since each server that does not have the requested information goes and finds it somewhere, then reports back. An alternative form is also possible. In this form, when a query cannot be satisfied locally, the query fails, but the name of the next server along the line to try is returned. Some servers do not implement recursive queries and always return the name of the next server to try. It is also worth pointing out that when a DNS client fails to get a response before its timer goes off, it normally will try another server next time. The assumption here is that the server is probably down, rather than that the request or reply got lost. While DNS is extremely important to the correct functioning of the Internet, all it really does is map symbolic names for machines onto their IP addresses. It does not help locate people, resources, services, or objects in general. For locating these things, another directory service has been defined, called LDAP (Lightweight Directory Access Protocol). It is a simplified version of the OSI X.500 directory service and is described in RFC 2251. It organizes information as a tree and allows searches on different components. It can be regarded as a ''white pages'' telephone book.

Circular Dependencies and Glue Records

Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. If the name given in the delegation is a subdomain of the domain for which the delegation is being provided, there is a circular dependency. In this case the nameserver providing the delegation must also provide one or more IP addresses for the authoritative nameserver mentioned in the delegation. This information is called glue. The delegating name server provides this glue in the form of records in the additional section of the DNS response, and provides the delegation in the answer section of the response.

Record Caching
Because of the large volume of DNS requests generated for the public Internet, the designers wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for caching of records for a period of time after an answer. This entails the local recording and subsequent consultation of the copy instead of initiating a new request upstream. The time for which a resolver caches a DNS response is determined by a value called the time to live (TTL) associated with every record. The TTL is set by the administrator of the DNS server handing out the authoritative response. The period of validity may vary from just seconds to days or even weeks.

10

Reverse lookup
A reverse lookup is a query of the DNS for domain names when the IP address is known. Multiple domain names may be associated with an IP address. The DNS stores IP addresses in the form of domain names as specially formatted names in pointer (PTR) records within the infrastructure top-level domain arpa. For IPv4, the domain is in-addr.arpa. For IPv6, the reverse lookup domain is ip6.arpa. The IP address is represented as a name in reverse-ordered octet representation for IPv4, and reverse-ordered nibble representation for IPv6.

Client Lookup
Users generally do not communicate directly with a DNS resolver. Instead DNS resolution takes place transparently in applications programs such as web browsers, e-mail clients, and other Internet applications. When an application makes a request that requires a domain name lookup, such programs send a resolution request to the DNS resolver in the local operating system, which in turn handles the communications required.

Applications of DNS


Hostnames and IP addresses do not necessarily match on a one-to-one basis. Multiple hostnames may correspond to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites. Alternatively a single hostname may correspond to many IP addresses: this can facilitate fault tolerance and load distribution, and also allows a site to move physical location seamlessly. There are many uses of DNS besides translating names to IP addresses. For instance, Mail transfer agents use DNS to find out where to deliver e-mail for a particular address. The domain to mail exchanger mapping provided by MX records accommodates another layer of fault tolerance and load distribution on top of the name to IP address mapping. E-mail Blacklists: The DNS system is used for efficient storage and distribution of IP addresses of blacklisted e-mail hosts. The usual method is putting the IP address of the subject host into the sub-domain of a higher level domain name, and resolves that name to different records to indicate a positive or a negative. A hypothetical example using blacklist.example
  

102.3.4.5 is blacklisted => Creates 5.4.3.102.blacklist.example and resolves to 127.0.0.1 102.3.4.6 is not => 6.4.3.102.blacklist.example is not found, or default to 127.0.0.2 E-mail servers can then query blacklist.example through the DNS mechanism to find out if a specific host connecting to them is in the blacklist. Today many of such blacklists,

11

either free or subscription-based, are available mainly for use by email administrators and anti-spam software.


Software Updates: many anti-virus and commercial software now use the DNS system to store version numbers of the latest software updates so client computers do not need to connect to the update servers every time. For these types of applications, the cache time of the DNS records are usually shorter. Sender Policy Framework and DomainKeys, instead of creating their own record types, were designed to take advantage of another DNS record type, the TXT record. To provide resilience in the event of computer failure, multiple DNS servers are usually provided for coverage of each domain, and at the top level, thirteen very powerful root servers exist, with additional "copies" of several of them distributed worldwide via Anycast. Dynamic DNS (sometimes called DDNS) allows clients to update their DNS entry as their IP address changes, as it does, for example, when moving between ISPs or mobile hot spots.

DNS Resource Records

A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource records of the same type define a resource record set. The order of resource records in a set, returned by a resolver to an application, is undefined, but often servers implement round-robin ordering to achieve load balancing.DNSSEC, however, works on complete resource record sets in a canonical order. When sent over an IP network, all records use the common format specified in RFC 1035: RR (Resource record) Fields Field Description Length (octets) (variable) 2 2

NAME TYPE CLASS

Name of the node to which this record pertains Type of RR in numeric form (e.g. 15 for MX RRs) Class code

12

TTL

Count of seconds that the RR stays valid (The maximum is 231-1, 4 which is about 68 years.) 2 (variable)

RDLENGTH Length of RDATA field RDATA Additional RR-specific data

NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name. TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MXrecord specifies the mail server used to handle mail for a domain specified in an e-mail address. RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types must not (RFC 3597). The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition, the classes Chaos (CN) and Hesiod (HS) exist. Each class is an independent name space with potentially different delegations of DNS zones. In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only in communication with other DNS nodes (on the wire), such as when performing zone transfers (AXFR/IXFR) or for EDNS (OPT).

Security Issues
DNS was not originally designed with security in mind, and thus has a number of security issues. One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not. DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; the Domain Name System Security Extensions (DNSSEC) modifies DNS to add support for cryptographically signed responses. There are various extensions to support securing zone transfer information as well. Even with encryption, a DNS server could become compromised by a virus (or for that matter a disgruntled employee) that would cause IP addresses of that server to be redirected to a
13

malicious address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches as required by the long TTL (up to 68 years). Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the difference when the user's typeface (font) does not clearly differentiate the letter 1 and the numeral 1. This problem is more serious in systems that support internationalized domain names, since many character codes in ISO 10646, may appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing. Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.

Configuring the DNS Server

Required Packages: bind-chroot-9.2.4-2.i386.rpm bind-devel-9.2.4-2.i386.rpm bind-libs-9.2.4-2.i386.rpm bind-utils-9.2.4-2.i386.rpm bind-9.2.4-2.i386.rpm caching-nameserver-7.3.3.noarch.rpm system-config-bind Port Number: 53-DNS Service/Daemon: named Step1: Install bind #yum install bind* or rpm ivh bind* #yum install caching* #yum install system-config-bind* Step2: Copy the file: #cp /usr/share/doc/bind*/sample/var/named/named.root /var/named/chroot/var/named Step3: Now on the graphical terminal(Check that in the network tab there must be your IP address in the DNS tab) #system-config-bind
14

Now a window comes there-right click on the DNS server-add-zone-internet-ok-forward lookup zoneok-rahul.com (give the domain name) (ok) Now right click on domain name (rahul.com)-add-IPv4 address (A) - www.rahul.com (full domain name) - then IPv4 address (192.168.1.) Step4: #service named restart Step5: For reverse loopup zone- 255- R.C- Internet Reverse IPv4 zone- R.C.- add- NS (name server) Server domain name: www.rahul.com (save) Step6: #service named restart Step7: To check whether the DNS is working: #host www.rahul.com (forward lookup zone) #host 192.168.1.1 (reverse lookup zone) #dig www.rahul.com/192.168.1.1 #nslookup www.rahul.com/192.168.1.1 Step8: On client PC add your IP in DNS tab in TCP/IP settings and ping the domain name, if it completes successfully, means your forward lookup zone is working and ping a<ipaddress>, if it gives domain name it means reserve lookup zone is working (on windows).

15

YUM SERVER
Yum is an automatic updater and package installer/remover for rpm systems. It automatically computes dependencies and figures out what things should occur to install packages. It makes it easier to maintain groups of machines without having to manually update each one using rpm. There are several features of yum over rpm. It is to be noted that yum is not a replacement tool for RPM. It simply makes the process of installation / update easier. Multiple Repositories Simple config file Correct dependency calculation & Fast operation Rpm-consistent behavior Simple interface Below is brief syntax of the command: yum [option] packagename

Advantages of Yum Server:

y Automatic resolution of software dependencies: If a package installation or upgrade request is made and requires the installation or upgrade of additional packages, YUM can list these dependencies and prompt the user to install or upgrade them. Command-line and graphical version: The command-line version can be run on a system with a minimal number of software packages. The graphical versions offer easeof-use and a user-friendly graphical interface to software management. Multiple software locations at one time: YUM can be configured to look for software packages in more than one location at a time. Ability to specify particular software versions or architecture: Software locations accessible by YUM can contain multiple versions of the same RPM package and different builds for different architectures such as one for i686 and one for x86_64. Yum can easily check the appropriate version and download it.

y y

16

Configuring Yum Server:

First of all you have to put in the media CD/DVD into your CD/DVD ROM/Writer. Then you need to mount it manually if you are login via root user in a GUI. To do so mount dev/dvd /media/cdrom After mounting the DVD we need to copy the content of the DVD onto a directory. This is the command cp -r /media/cdrom/* /dvd/rhel5/ After copying the contents it's time to do some modifications. First of all we need to bring the xml files defining the groups to directory one level higher. mv /dvd/rhel5/Server/repodata/comps-rhel5-server-core.xml /dvd/rhel5/Server mv /dvd/rhel5/VT/repodata/comps-rhel5-vt.xml /dvd/rhel5/VT mv /dvd/rhel5/Cluster/repodata/comps-rhel5-cluster.xml /dvd/rhel5/Cluster mv /dvd/rhel5/ClusterStorage/repodata/comps-rhel5-cluster.xml /dvd/rhel5/ClusterStorage Now we need to delete the repodata/ directories which comes with the default install tree. The reason behind this is that in their xml files we have a string xml:base="media://1170972069.396645#1" ..... This string is present in repmod.xml as well as primary.xml.gz. This thing creates problem with using DVD/CD sources with yum. So we need to do the following rm -rf /dvd/rhel5/Server/repodata rm -rf /dvd/rhel5/VT/repodata rm -rf /dvd/rhel5/Cluster/repodata rm -rf /dvd/rhel5/ClusterStorage/repodata After we have deleted the default repodata/ directories it's time to re-create them using the "createrepo" command. rpm -ivh /dvd/rhel5/Server/createrepo-0.4.4-2.fc6.noarch.rpm Next step is to run this command. Before running this command we need to switch to the /dvd/ directory. Then run the commands listed below createrepo -g comps-rhel5-server-core.xml dvd/Server/ createrepo -g comps-rhel5-vt.xml dvd/VT/ createrepo -g comps-rhel5-cluster.xml dvd/Cluster/ createrepo -g comps-rhel5-cluster-st.xml dvd/ClusterStorage/ The above commands will do most part of the job. Now it's time to configure the /etc/yum.conf for our local repository. Note that we can also create separate repo files in /etc/yum.repos.d/ directory. So do the following
17

vi /etc/yum.conf In this file type in the following: # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d [Server] name=Server baseurl=file:///dvd/rhel5/Server/ enabled=1 [VT] name=Virtualization baseurl=file:///dvd/rhel5/VT/ enabled=1 [Cluster] name=Cluster baseurl=file:///dvd/rhel5/Cluster/ enabled=1 [ClusterStorage] name=Cluster Storage baseurl=file:///dvd/rhel5/ClusterStorage/ enabled=1 We can also use GPG key signing. For that write on top of the above lines gpgenabled=1 gpgkey=file:///dvd/rhel5/RPM-GPG-KEY-fedora file:///dvd/rhel5/RPM-GPG-KEY-fedora-test file:///dvd/rhel5/RPM-GPG-KEY-redhat-auxiliary file:///dvd/rhel5/RPM-GPG-KEY-redhat-beta file:///dvd/rhel5/RPM-GPG-KEY-redhat-former file:///dvd/rhel5/RPM-GPG-KEY-redhat-release Let's create the yum cache now. yum clean all yum update Finally, to check the services of yum server, we give the following command: #yum list all

Using Yum Server:

Using yum command we can do following. 1. Clean the old cache data:

18

Before you start using yum command, it is best practice to clean the old caching data. This can be achieved by following command.

2. Listing the softwares : The following command lists all the softwares installed as well as available software on repository. [root@server1 ~]# yum list You can list any specific software as below. [root@server1 ~]# yum list httpd 3. Getting information of the software : You can get small information of the software whether it is installed or not installed.

19

4. Removing the installed package: You can use remove option as below. Say let us remove zsh software. The command is # yum remove zsh

5. Installing software: The option install is used as below to installed the software. [root@server1 ~]# yum install zsh 6. Updating software: To update installed software with new one. [root@server1 ~]# yum update zsh 7. Getting file list of software before or after installation: [root@server1 ~]#yum whatprovides httpd This is particularly useful when one want to locate the path of configuration files, binaries etc. For more complete information you can refer [root@server1 ~]#man yum
20

References
 DNS Cache Snooping or Snooping the Cache for Fun and Profit, Version 1.1 / February 2004 by Luis Grangeia  http://www.freeonlineresearchpapers.com/dns-poisoning  http://www.123helpme.com/search.asp?text=server  A Quantitative Profile of a Community of Open Source Linux Developers by Bert Dempsey, Debra Weiss, Paul Jones, and Jane Greenberg  http://searchenterpriselinux.techtarget.com/definition/Yellowdog-Updater-ModifiedYUM  Red Hat Enterprise Linux Administration by Tammy Fox

Bibliography
 en.wikipedia.org  http://linuxtechsupport.blogspot.com/2008/06/configuring-yum-in-rhel5.html  Computer Networks 4th Ed - Andrew S. Tanenbaum  Data Communication and Networking- Behrouz A. Forouzan  www.linux.com

21