Training Project Linux

8/6/2019 Training Project Linux

1/21

LINUX TRAINING - HP

Study of Domain Name System (DNS)

& Yellowdog Updater Modified(YUM)

Servers

Submitted to:

Dr. Anil Kumar Singh


2/21

2

ACKNOWLEDGEMENT

I am highly indebted to Dr. Anil Kumar Singh (Faculty- Linux Administrationwith 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.


3/21

3

TABLEOFCONTENTS

SRNo TOPIC PAGENO

1 Domain name system-introduction 4

2 Domain name space 5

3 International Domain Names and Name servers 7

4 Authoritative Name Servers 8

5 DNS resolvers 9

6 Circular dependencies and glue records 10

7 Reverse and Client records 11

8 DNS resource records 12

9 Security issues 13

10 Configuring DNS 14

11 Configuring YUM Server 17

12 Using YUM 18

13 References and Bibliography 21


4/21

4

DOMAINNAME SYSTEM

Introduction

The Domain Name System (DNS) is a hierarchical naming system built on a distributeddatabase 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.


5/21

5

The Internet maintains two principal namespaces, the domain name hierarchyand 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 DomainName 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.

APortion ofInternet DomainName 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.


6/21

6

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).


7/21

7

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 DomainNames

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 client-

server 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.


8/21

8

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 masterserver or aslave 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 aprimary name server and at least

onesecondary 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 theAuthoritative 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 authorit y forthe

domain name in question.

Recursive and CachingName ServerIn 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.


9/21

9

To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-

user 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 cachingDNS 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 ofDNS 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


10/21

10

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 forwhich 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 forcachingof 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.


11/21

11

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 reverselookup 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 ofDNS

Hostnames and IP addresses do not necessarily match on a one-to-one basis. Multiplehostnames 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, Mailtransfer 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 IPaddresses 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,


12/21

12

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 tostore 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, weredesigned 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 IPaddress changes, as it does, for example, when moving between ISPs or mobile hot spots.

DNS Resource RecordsA 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)

NAME Name of the node to which this record pertains (variable)

TYPE Type of RR in numeric form (e.g. 15 for MX RRs) 2

CLASS Class code 2


13/21

13

TTL Count of seconds that the RR stays valid (The maximum is 231-1,

which is about 68 years.)

4

RDLENGTH Length of RDATA field 2

RDATA Additional RR-specific data (variable)

NAMEis 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.

TYPEis the record type. It indicates the format of the data and it gives a hint of its intended use.

For example, theA record is used to translate from a domain name to an IPv4 address,theNSrecord lists which name servers can answer lookups on a DNS zone, and theMXrecord

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 CLASSof a record is set to IN (forInternet) 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


14/21

14

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 theuser's typeface (font) does not clearly differentiate the letter1 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


15/21


16/21

16

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 upgraderequest 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.

y Command-line and graphical version:The command-line version can be run on asystem with a minimal number of software packages. The graphical versions offer ease-

of-use and a user-friendly graphical interface to software management.

y Multiple software locations at one time:YUM can be configured to look forsoftware packages in more than one location at a time.

y Ability to specify particular software versions or architecture:Software locationsaccessible 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.


17/21

17

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 thecommand

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/VTmv /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 stringxml:base="media://1170972069.396645#1" .....

This string is present in repmod.xml as well as primary.xml.gz. This thing creates problem withusing DVD/CD sources with yum. So we need to do the following

rm -rf /dvd/rhel5/Server/repodata

rm -rf /dvd/rhel5/VT/repodatarm -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.conffor our local repository. Note that we can also create separate repo files in /etc/yum.repos.d/

directory. So do the following


18/21

18

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=Serverbaseurl=file:///dvd/rhel5/Server/

enabled=1[VT]

name=Virtualizationbaseurl=file:///dvd/rhel5/VT/

enabled=1[Cluster]

name=Clusterbaseurl=file:///dvd/rhel5/Cluster/

enabled=1[ClusterStorage]

name=Cluster Storagebaseurl=file:///dvd/rhel5/ClusterStorage/

enabled=1

We can also use GPG key signing. For that write on top of the above lines

gpgenabled=1gpgkey=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-betafile:///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:


19/21

19

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

2. Listing the softwares :

The following command lists all the softwares installed as well as available software onrepository.

[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.


20/21

20

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


21/21

21

References

DNS Cache Snooping or Snooping the Cache for Fun and Profit, Version 1.1 / February2004 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-Modified-YUM

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

Training Project Linux

Documents

Transcript of Training Project Linux