minor report on samba
TRANSCRIPT
“SAMBA SERVER”
MINOR PROJECT
SUBMITTED IN PARTIAL FULFILLMENT
REQUIREMENT OF
BACHELOR OF TECHNOLOGY
(INFORMATION TECHNOLOGY)
BY
PRATEEKSUHAG (1705139)
MANPREET KAUR (1705136)
UNDER THE GUIDANCE OF
ER. MUKESH RANA
Lect. Deptt. of IT
(SESSION AUG-DEC 2008)
HARYANA COLLEGE OF TECNOLOGY & MANAGEMENT, KAITHALKURUKSHETRA UNIVERSITY, KURUKSHETRA
CONTENTS
Particulars Page No.
Candidate Declaration 7
Certificate 8
Acknowledgement 9
Abstract of Project 10
Chapter 1: INTRODUCTION 11
1.1 WHAT SAMBA IS ALL ABOUT 11
1.2 HISTORY - THE (HOPEFULLY) UNTEDIOUS
VERSION 12
1.3 MEANWHILE, ON THE OTHER SIDE OF THE
PLANET… 13
1.4 WHAT SAMBA DOES 14
1.5 OTHER STUFF 16
1.5.1 smbclient 17
1.5.2 nmblookup 17
1.5.3 swat 17
1.6 SMB FILESYSTEM FOR LINUX 17
1.7 SETUP AND MANAGEMENT 18
1.8 THE PRESENT 18
1.9 THE FUTURE 19
1.9.1 CIFS WITHOUT NetBIOS 19
1.9.2 DYNAMIC DNS 19
1.9.3 KERBEROS V 20
1.9.4 ACTIVE DIRECTORY 202
1.9.5 HIERARCHICAL NT DOMAINS 20
Chapter 2: YUM SERVER 21
2.1 WHAT IS YUM 21
2.2 WHAT YUM CAN DO 22
2.3 HOW YUM WORKS 22
2.4 YUM, RPM, AND RED HAT 29
2.5 RPM REPOSITORY 29
2.6 BUILDING YUM 32
Chapter 3: YUM SERVER ON RED HAT ENTERPRISE LINUX
5.0 34
3.1 BASICS OF CONFIGURING YUM IN RHEL 5.0 34
Chapter 4: SAMBA SERVER 41
4.1 WHAT IS SAMBA 41
4.2 FEATURES AND BENEFITS 41
4.3 BASICS OF CONFIGURING SAMBA 42
4.3.1 THE smb.conf FILE IS DIVIDED INTO
TWO MAIN SECTIONS 42
4.3.1.1 THE SHARE SECTION 43
4.3.1.1.1 The Home Section 43
4.3.1.2 THE GLOBAL SECTION 44
4.4 SECURITY PARAMETERS 45
4.4.1 SAMBA SECURITY MODES 46
4.4.1.1 USER LEVEL SECURITY 46
4.4.1.2 SHARE-LEVEL SECURITY 47
4.4.1.3 DOMAIN SECURITY MODE
(USER-LEVEL SECURITY) 48
4.4.1.4 ADS SECURITY MODE (USER-
LEVEL SECURITY) 50
4.4.1.5 SERVER SECURITY (USER-
LEVEL SECURITY) 51
3
4.5 BASICS OFCONFIGURING SAMBA SERVER ON
RED HAT ENTERPRISE LINUX 5.0 52
4.5.1 STEP 1: ENABLE NETWORK
CONNECTIVITY TO THE
SAMBA SERVER 52
4.5.2 STEP 2: UPDATE FIREWALL SETTINGS 53
4.5.3 STEP 3: ENABLE SMB SERVICES 54
4.5.4 STEP 4: CREATE SERVER USERS AND
DIRECTORIES 54
4.5.5 STEP 5: CONFIGURE THE SAMBA SERVER 55
4.5.5.1 A. BEGIN BY MAKING
CHANGES TO THE SERVER
SETTINGS 56
4.5.5.2 B. SELECT SAMBA USERS 56
4.5.5.3 C. ADDING A SHARED FOLDER 57
4.5.5.4 D. ADDING USERS 57
4.5.6 STEP 6: RESTART THE SAMBA SERVICES 57
4.5.7 STEP 7: ACCESS THE SAMBA SERVER
FROM WINDOWS 62
4.5.8 STEP 8: CONNECTING TO THE
SHARES FROM WINDOWS TO LINUX
AND VICE-VERSA 59
4.5.8.1 A. CREATING SHARES 59
4.5.8.2 B. LIST SHARES AVAILABLE ON
THE SERVER 60
4.5.8.3 C. MAPPING SHARES FROM
THE COMMAND LINE 60
4.5.8.4 D. CHECKING SHARES 61
4.5.8.5 E. SHARE PERMISSIONS 62
4
4.5.8.6 F. CREATING SHARES FOR
HOME DIRECTORIES 63
4.5.8.7 G. CREATING A PRINTER
SHARE 63
Chapter 5: PLATFORM DESCRIPTION 65
5.1 LINUX 65
5.1.1 HISTORY 65
5.1.1.1 UNIX 65
5.1.2 PROPERTIES OF LINUX 66
5.1.2.1 LINUX PROS 66
5.1.2.2 LINUX IS FREE 66
5.1.2.3 LINUX IS PORTABLE TO ANY
HARDWARE PLATFORM 67
5.1.2.4 LINUX WAS MADE TO KEEP
ON RUNNING 67
5.1.2.5 LINUX IS SECURE AND
VERSATILE 67
5.1.2.6 LINUX IS SCALABLE 68
5.1.2.7 THE LINUX OS AND MOST
LINUX APPLICATIONS HAVE
VERY SHORT DEBUG-TIMES 68
5.1.2.8 LINUX IS NOT VERY USER
FRIENDLY AND CONFUSING
FOR BEGINNERS 69
5.1.2.9 IS AN OPEN SOURCE
PRODUCT TRUSTWORTHY? 69
Chapter 6: LITRETURE REVIEW 70
6.1 BASIC IDEA 70
Chapter 7: METHOD OF IMPLEMENTATION 71
7.1 SERVER END 71
7.1.1 YUM SERVER 715
7.1.2 SAMBA SERVER 71
7.2 CLIENT END 72
Chapter 8: CONCLUSION 73
Chapter 9: REFRENCES 74
6
List of Figures
Fig. NO. Fig. Description Page No.
1.1 What Samba Is All
About
12
3.1.1 Pirut 43
7
CANDIDATE DECLARATION
We hereby certify that the work which is being presented by “Prateek Suhag (1705139) & Man-
preet Kaur (1705136)” in partial fulfillment of requirements for the award of degree of B.Tech.
In INFORMATION TECHNOLOGY submitted at HARYANA COLLEGE OF TECHNOL-
OGY AND MANAGEMENT, KAITHAL under KURUKSHETRA UNIVERSITY, KU-
RUKSHETRA is an authentic record of our own work carried out under the supervision of ER.
MUKESH RANA.
The matter presented in this report has not been submitted by us in any other University / Insti-
tute for the award of B.Tech Degree.
Signature of the Student
PRATEEK SUHAG (1705139)
Signature of the Student
MANPREET KAUR (1705136)
8
CERTIFICATE
This is to certify that Project Associates PRATEEK SUHAG (1705139) & MANPREET KAUR (1705136) of B.Tech. VIIth Semester,
INFORMATION TECHNOLOGY have successfully completed the MINOR PROJECT “SAMBA SERVER” in the partial fulfillment for the
award of Bachelor of Technology Degree from Kurukshetra University, Kurukshetra during academic year 2007-2008.
We wish him a prosperous, happy & bright future with all the great silvery success in him career.
(ER SAURABH MITTAL) (ER. MUKESH RANA)
HEAD Project Guide
Department of IT
ACKNOWLEDGEMENT
WE are highly grateful to the Dr. D.P. Gupta, Principal, Haryana College of Technology &
Management (HCTM), Kaithal, for providing this opportunity to carry out the project.
WE are highly grateful to the Er. SAURABH MITTAL, HEAD OF DEPARTMENT,
Haryana College of Technology & Management (HCTM), Kaithal, for providing this
opportunity to carry out the project.
The constant guidance and encouragement received from ER. MUKESH RANA, Department of
INFORMATION TECHNOLOGY, HCTM, Kaithal has been of great help in carrying our
work and is acknowledged with reverential thanks. Without the wise counsel and able guidance,
it would have been impossible to complete the project in this manner.
WE express gratitude to other faculty members of Information Technology Department, HCTM,
Kaithal for their intellectual support throughout the course of this work.
Signature of the Student
PRATEEK SUHAG (1705139)
Signature of the Student
MANPREET KAUR (1705136)
ABSTRACT
Samba software delivers an outstanding level of transparent interoperability between Microsoft
Windows and the non-Microsoft information technology world such a Linux. Samba speaks to
Windows users like a native while allowing Linux systems to move into a Windows "Network"
without causing a stir.
Open source and Linux® may be an unfamiliar subject, and just because Linux has a close
association with UNIX®, does not mean that it is hard. In fact, this guide will show how easy it
is to install a Samba fi le and print server on any server platform. Furthermore, your customers
will see great value in the fact that Samba is included with any one- or three-year subscription of
Red Hat® Enterprise Linux®. Samba is an ambitious and exciting project that delivers a
remarkable level of transparent interoperability between Microsoft Windows® and the non-
Microsoft information technology world such as Linux. Samba uses the TCP/IP protocol that is
installed on the host server, which allows the host to interact with a Microsoft Win dows client or
server as if it is a Windows fi le and print server. In other words, Samba speaks to Windows
clients like a native. It allows a Linux system to move into a Windows “Network Neighborhood”
without causing a stir. Windows users can happily access fi le and print services without
knowing or caring that those services are being off ered by a UNIX host. Cancel
PC Magazine published a comparison of Samba and Windows showing that Samba software
surpasses the performance of Windows 2000 by about 100% under benchmark tests, and found
that Linux and Samba can handle four times as many client systems as Windows 2000 before
performance begins to drop off .
According to IDC, in 2006, fi le and print workloads will account for approximately$270M in
revenue or as many as 73 billion servers using fi le and print software. Given that Red Hat is the
worldwide leader in Linux server shipments and Samba is included with any one- or three-year
Red Hat Enterprise Linux subscription, your revenue opportunity is unparalleled
11
CHAPTER 1: INTRODUCTION
The story goes something like this:
Linus Torvalds, the creator of the Linux Kernel, was visiting his friend Andrew Tridgell, the cre -
ator of the Samba suite. They were walking through the Zoo in Canberra when, without warning,
a huge flock of vampire attack penguins dove out of the sky and tried to carry Linus away. Fortu-
nately, Andrew had an umbrella. Still, one of the birds was able to nip Linus' hand with its
fanged beak. Rumor has it that on moonlit nights Linus still runs out into the darkness and
jumps, stark naked, into icy water. Of course, he's Finnish and may always have done this. In any
case, this is why the Penguin is the Linux Mascot.
Andrew says that the story has changed a bit since the actual event.
1.1 WHAT SAMBA IS ALL ABOUT
The commercialization of the Internet over the past few years has created something of a modern
melting pot. It has brought business-folk and technologists closer together than was previously
thought possible, helping to raise the popularity of the Dilbert® comic strip to dizzying levels. As
a side effect, Windows and Unix systems have been invading each others' turf, and people expect
that they will not only play together nicely, but that they will share.
A lot of emphasis has been placed on peaceful coexistence between Unix and Windows. The
Usenix Association has even created an annual conference (LISA/NT--July 14-17, 1999) around
this theme. Unfortunately, the two systems come from very different cultures and they have diffi-
culty getting along without mediation. ...and that, of course, is Samba's job. Samba runs on Unix
platforms, but speaks to Windows clients like a native. It allows a Unix system to move into a
Windows "Network Neighborhood" without causing a stir. Windows users can happily access
file and print services without knowing or caring that those services are being offered by a Unix
host.
12
All of this is managed through a protocol suite which is currently known as the "Common
Internet File System", or CIFS. This name was introduced by Microsoft, and provides some in-
sight into their hopes for the future. At the heart of CIFS is the latest incarnation of the Server
Message Block (SMB) protocol, which has a long and tedious history. Samba is an open source
CIFS implementation, and is available for free from the http://samba.org/ mirror sites.
Fig.: 1.1 “What Samba Is All About”
Samba and Windows are not the only ones to provide CIFS networking. OS/2 supports SMB file
and print sharing, and there are commercial CIFS products for Macintosh and other platforms
(including several others for Unix). Samba has been ported to a variety of non-Unix operating
systems, including VMS, AmigaOS, & NetWare. CIFS is also supported on dedicated file server
platforms from a variety of vendors. In other words, this stuff is all over the place.
1.2 HISTORY - THE (HOPEFULLY) UNTEDIOUS VERSION
It started a long time ago, in the early days of the PC, when IBM and Sytec co-developed a
simple networking system designed for building small LANs. The system included something
13
called NetBIOS, or Network Basic Input Output System. NetBIOS was a chunk of software that
was loaded into memory to provide an interface between programs and the network hardware. It
included an addressing scheme that used 16-byte names to identify workstations and network-
enabled applications. Next, Microsoft added features to DOS that allowed disk I/O to be
redirected to the NetBIOS interface, which made disk space sharable over the LAN. The file-
sharing protocol that they used eventually became known as SMB, and now CIFS.
Lots of other software was also written to use the NetBIOS API (Application Programmer's In-
terface), which meant that it would never, ever, ever go away. Instead, the workings beneath the
API were cleverly gutted and replaced. NetBEUI (NetBIOS Enhanced User Interface), intro-
duced by IBM, provided a mechanism for passing NetBIOS packets over Token Ring and Ether-
net. Others developed NetBIOS LAN emulation over higher-level protocols including DECnet,
IPX/SPX and, of course, TCP/IP.
NetBIOS and TCP/IP made an interesting team. The latter could be routed between intercon-
nected networks (internetworks), but NetBIOS was designed for isolated LANs. The trick was to
map the 16-byte NetBIOS names to IP addresses so that messages could actually find their way
through a routed IP network. A mechanism for doing just that was described in the Internet
RFC1001 and RFC1002 documents. As Windows evolved, Microsoft added two additional
pieces to the SMB package. These were service announcement, which is called "browsing", and
a central authentication and authorization service known as Windows NT Domain Control.
1.3 MEANWHILE, ON THE OTHER SIDE OF THE PLANET…
Andrew Tridgell, who is both tall and Australian, had a bit of a problem. He needed to mount
disk space from a Unix server on his DOS PC. Actually, this wasn't the problem at all because he
had an NFS (Network File System) client for DOS and it worked just fine. Unfortunately, he also
had an application that required the NetBIOS interface. Anyone who has ever tried to run multi-
ple protocols under DOS knows that it can be...er...quirky.
So Andrew chose the obvious solution. He wrote a packet sniffer, reverse engineered the SMB
protocol, and implemented it on the Unix box. Thus, he made the Unix system appear to be a PC 14
file server, which allowed him to mount shared filesystems from the Unix server while concur-
rently running NetBIOS applications. Andrew published his code in early 1992. There was a
quick, but short succession of bug-fix releases, and then he put the project aside. Occasionally he
would get E'mail about it, but he otherwise ignored it. Then one day, almost two years later, he
decided to link his wife's Windows PC with his own Linux system. Lacking any better options,
he used his own server code. He was actually surprised when it worked.
Through his E'mail contacts, Andrew discovered that NetBIOS and SMB were actually (though
nominally) documented. With this new information at his fingertips he set to work again, but
soon ran into another problem. He was contacted by a company claiming trademark on the name
that he had chosen for his server software. Rather than cause a fuss, Andrew did a quick scan
against a spell-checker dictionary, looking for words containing the letters "smb". "Samba" was
in the list. Curiously, that same word is not in the dictionary file that he uses today. (Perhaps they
know it's been taken.)
The Samba project has grown mightily since then. Andrew now has a whole team of program-
mers, scattered around the world, to help with Samba development. When a new release is an-
nounced, thousands of copies are downloaded within days. Commercial systems vendors, includ-
ing Silicon Graphics, bundle Samba with their products. There are even Samba T-shirts avail-
able. Perhaps one of the best measures of the success of Samba is that it was listed in the "Hal-
loween Documents", a pair of internal Microsoft memos that were leaked to the Open Source
community. These memos list Open Source products which Microsoft considers to be competi-
tive threats. The absolutely best measure of success, though, is that Andrew can still share the
printer with his wife.
1.4 WHAT SAMBA DOES
Samba consists of two key programs, plus a bunch of other stuff that we'll get to later. The two
key programs are smbd and nmbd. Their job is to implement the four basic modern-day CIFS
services, which are:
File & print services
Authentication and Authorization
15
Name resolution
Service announcement (browsing)
File and print services are, of course, the cornerstone of the CIFS suite. These are provided by
smbd, the SMB Daemon. Smbd also handles "share mode" and "user mode" authentication and
authorization. That is, you can protect shared file and print services by requiring passwords. In
share mode, the simplest and least recommended scheme, a password can be assigned to a shared
directory or printer (simply called a "share"). This single password is then given to everyone who
is allowed to use the share. With user mode authentication, each user has their own username and
password and the System Administrator can grant or deny access on an individual basis.
The Windows NT Domain system provides a further level of authentication refinement for CIFS.
The basic idea is that a user should only have to log in once to have access to all of the autho-
rized services on the network. The NT Domain system handles this with an authentication server,
called a Domain Controller. An NT Domain (which should not be confused with a Domain
Name System (DNS) Domain) is basically a group of machines which share the same Domain
Controller.
The NT Domain system deserves special mention because, until the release of Samba version 2,
only Microsoft owned code to implement the NT Domain authentication protocols. With version
2, Samba introduced the first non-Microsoft-derived NT Domain authentication code. The even-
tual goal, of course, it to completely mimic a Windows NT Domain Controller.
The other two CIFS pieces, name resolution and browsing, are handled by nmbd. These two ser-
vices basically involve the management and distribution of lists of NetBIOS names.
Name resolution takes two forms: broadcast and point-to-point. A machine may use either or
both of these methods, depending upon its configuration. Broadcast resolution is the closest to
the original NetBIOS mechanism. Basically, a client looking for a service named Trillian will call
out "Yo! Trillian! Where are you?", and wait for the machine with that name to answer with an IP ad-
dress. This can generate a bit of broadcast traffic (a lot of shouting in the streets), but it is re-
stricted to the local LAN so it doesn't cause too much trouble.
The other type of name resolution involves the use of an NBNS (NetBIOS Name Service) server.
(Microsoft called their NBNS implementation WINS, for Windows Internet Name Service, and
16
that acronym is more commonly used today.) The NBNS works something like the wall of an old
fashioned telephone booth. (Remember those?) Machines can leave their name and number (IP
address) for others to see.
Hi, I'm node Voomba. Call me for a good time! 192.168.100.101
It works like this: The clients send their NetBIOS names & IP addresses to the NBNS server,
which keeps the information in a simple database. When a client wants to talk to another client, it
sends the other client's name to the NBNS server. If the name is on the list, the NBNS hands
back an IP address. You've got the name, look up the number.
Clients on different subnets can all share the same NBNS server so, unlike broadcast, the point-
to-point mechanism is not limited to the local LAN. In many ways the NBNS is similar to the
DNS, but the NBNS name list is almost completely dynamic and there are few controls to ensure
that only authorized clients can register names. Conflicts can, and do, occur fairly easily.
Finally, there's browsing. This is a whole 'nother kettle of worms, but Samba's nmbd handles it
anyway. This is not the web browsing we know and love, but a browsable list of services (file
and print shares) offered by the computers on a network.
On a LAN, the participating computers hold an election to decide which of them will become the
Local Master Browser (LMB). The "winner" then identifies itself by claiming a special NetBIOS
name (in addition to any other names it may have). The LMBs job is to keep a list of available
services, and it is this list that appears when you click on the Windows "Network Neighborhood"
icon.
In addition to LMBs, there are Domain Master Browsers (DMBs). DMBs coordinate browse lists
across NT Domains, even on routed networks. Using the NBNS, an LMB will locate its DMB to
exchange and combine browse lists. Thus, the browse list is propagated to all hosts in the NT
Domain. Unfortunately, the synchronization times are spread apart a bit. It can take more than an
hour for a change on a remote subnet to appear in the Network Neighborhood.
1.5 OTHER STUFF
Samba comes with a variety of utilities. The most commonly used are:
17
1.5.1 smbclient
A simple SMB client, with an interface similar to that of the FTP utility. It can be used from a
Unix system to connect to a remote SMB share, transfer files, and send files to remote print
shares (printers).
1.5.2 nmblookup
A NetBIOS name service client. Nmblookup can be used to find NetBIOS names on a network,
lookup their IP addresses, and query a remote machine for the list of names the machine believes
it ownes.
1.5.3 swat
The Samba Web Administration Tool. Swat allows you to configure Samba remotely, using a
web browser.
There are more, of course, but describing them would require explaining even more bits and
pieces of CIFS, SMB, and Samba. That's where things really get tedious, so we'll leave it alone
for now.
1.6 SMB FILESYSTEM FOR LINUX
One of the cool things that you can do with a Windows box is use an SMB file share as if it were
a hard disk on your own machine. The N: drive can look, smell, feel, and act like your own disk
space, but it's really disk space on some other computer somewhere else on the network.
Linux systems can do this too, using the smbfs filesystem. Built from Samba code, smbfs (which
stands for SMB Filesystem) allows Linux to map a remote SMB share into its directory struc-
ture. So, for example, the /mnt/zarquon directory might actually be an SMB share, yet you can
read, write, edit, delete, and copy the files in that directory just as you would local files. The
smbfs is nifty, but it only works with Linux. In fact, it's not even part of the Samba suite. It is
18
distributed with Samba as a courtesy and convenience. A more general solution is the new smbsh
(SMB shell, which is still under development at the time of this writing). This is a cool gadget. It
is run like a Unix shell, but it does some funky fiddling with calls to Unix libraries. By intercept-
ing these calls, smbsh can make it look as though SMB shares are mounted. All of the read, write,
etc. operations are available to the smbsh user. Another feature of smbsh is that it works on a per-
user, per shell basis, while mounting a filesystem is a system-wide operation. This allows for
much finer-grained access controls.
1.7 SETUP AND MANAGEMENT
Samba is configured using the smb.conf file. This is a simple text file designed to look a lot like
those *.ini files used in Windows. The goal, of course, is to give network administrators familiar
with Windows something comfortable to play with. Over time, though, the number of things that
can be configured in Samba has grown, and the percentage of Network Admins willing to edit a
Windows *.ini file has shrunk. For some people, that makes managing the smb.conf file a bit
daunting.
Still, learning the ins and outs of smb.conf is a worth-while penance. Each of the smb.conf variables
has a purpose, and a lot of fine tuning can be accomplished. The file structure contents are fully
documented, so as to give administrators a running head start, and smb.conf can be manipulated
using swat, which at least makes it nicer to look at.
1.8 THE PRESENT
Samba 2.0 was released in January 1999. One of the most significant and cool features of the 2.0
release was improved speed. Ziff-Davis Publishing used their Netbench software to benchmark
Samba 2.0 on Linux against Windows NT4. They ran all of their tests on the same PC hardware,
and their results showed Samba's throughput under load to be at least twice that of NT. Samba is
shipped with all major Linux distributions, and Ziff-Davis tested three of those.
Another milestone was reached when Silicon Graphics (SGI) became the first commercial Unix
vendor to support Samba. In their December 1998 press release, they claimed that their Origin
19
series servers running Samba 2.0 were the most powerful line of file servers for Windows clients
available. SGI now offers commercial support for Samba as do several other providers, many of
which are listed on the Samba web site (see http://samba.org/). Traditional Internet support is, of
course, still available via the comp.protocols.smb newsgroup and the [email protected] mailing list.
The Samba Team continues to work on new goodies. Current interests include NT ACLs (Access
Control Lists), support for LDAP (the Lightweight Directory Access Protocol), NT Domain
Control, and Microsoft's DFS (Distributed File System).
1.9 THE FUTURE
Windows 2000 looms on the horizon like a lazy animal peeking its head over the edge of its
burrow while trying to decide whether or not to come out. No one is exactly sure about the kind
of animal it will be when it does appear, but folks are fairly certain that it will have teeth.
Because of their dominance on the desktop, Microsoft gets to decide how CIFS will grow. Win-
dows 2000, like previous major operating system releases, will give us a whole new critter to
study. Based on the beta copies and the things that Microsoft has said, here are some things to
watch for:
1.9.1 CIFS WITHOUT NetBIOS
Microsoft will attempt to decouple CIFS and NetBIOS. NetBIOS won't go away, mind you, but
it won't be required for CIFS networking either. Instead, the SMB protocol will be carried
natively over TCP/IP. Name lookups will occur via the DNS.
1.9.2 DYNAMIC DNS
Microsoft will implement Dynamic DNS, a still-evolving system designed by the IETF (Internet
Engineering Task Force). Dynamic DNS allows names to be added to a DNS server on-the-fly.
20
1.9.3 KERBEROS V
Microsoft has plans to use Kerberos V. The Microsoft K5 tickets are supposed to contain a
Privilege Attribute Certificate (PAC), which will include user and group ID information from the
Active Directory. Servers will be looking for this PAC when they grant access to the services
that they provide. Thus, Kerberos may be used for both authentication and authorization.
1.9.4 ACTIVE DIRECTORY
The Active Directory appears to be at the heart of Windows 2000 networking. It is likely that
legacy NetBIOS services will register their names in the Active Directory.
1.9.5 HIERARCHICAL NT DOMAINS
Instead of isolated Domain Controllers, the NT Domain system will become hierarchical. The
naming system will change to one that is remarkably similar to that of the DNS.
One certainty is that W2K (as it is often called) is, and will be, under close scrutiny. Windows
has already attracted the attention of some of the Internet Wonderland's more curious inhabitants,
including security analysts, standards groups, crackers dens, and general all-purpose geeks. The
business world, which has finally gotten a taste of the freedom of Open Source Software, may be
reluctant to return to the world of proprietary, single-vendor solutions. Having the code in your
hands is both reassuring and empowering.
Whatever the next Windows animal looks like, it will be Samba's job to help it get along with its
peers in the diverse world of the Internet. The Samba Team, a microcosm of the Internet commu-
nity, are among those watching W2K to see how it develops. Watching does not go hand-in-hand
with waiting, though, and Samba is an on-going and open effort. Visit the Samba web site, join
the mailing lists, and see what's going on. Participate
in the future.
21
CHAPTER 2: YUM SERVER
2.1 WHAT IS YUM
Yum is a tool for automating package maintenance for a network of workstations running any
operating system that use the Red Hat Package Management (RPM) system for distributing
packaged tools and applications. It is derived from yup, an automated package updater originally
developed for Yellowdog Linux, hence its name: yum is "Yellowdog Updater, Modified".
Yup was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and
Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Apple
Macintoshes of various generations). Yum was written and is currently being maintained by Seth
Vidal and Michael Stenner, both of Duke University, although as an open source GPL project
many others have contributed code, ideas, and bug fixes (not to mention documentation :-). The
yum link above acknowledges the (mostly) complete list of contributors, as does the AUTHORS
file in distribution tarball.
Yum is a Gnu Public License (GPL) tool; it is freely available and can be used, modified, or
redistributed without any fee or royalty provided that the terms of its associated license are
followed.
YUM is more scalable and tolerant than other Linux updating programs, such as Red Hat-based
up2date and Debian-based APT-RPM (now managed by Conectiva), which makes it more
suitable for enterprise environments.
YUM handles dependencies more gracefully than the others, supports multiple Repositories,
groups and failover, and simplifies the management of multiple centralized And decentralized
machines.
YUM, like up2date, is written in Python, while APT-RPM is written in C++; the Difference is
33,000 lines of code, meaning YUM and up2date are faster and less complex. On the other hand,
up2date and APT-RPM have native GUIs, while YUM is command-line only (third-party GUIs
are available). Also, up2date has a rollback feature absent in YUM, which is important in case of
incorrect or incomplete updates. YUM may be used in other popular distributions such as
Novell's SuSE Linux or Mandrake, but there are less likely to be issues with Red Hat and Fedora.
SuSE and Mandrake users may want to consider their native updaters, YaST and urpmi.
22
2.2 WHAT YUM CAN DO
Yum (currently) consists of two tools; yum-arch, which is used to construct an (ftp or http)
repository on a suitable server, and yum, the general-purpose client. Once a yum repository is
prepared (a simple process detailed below) any client permitted to access the repository can
install, update, or remove one or more rpm-based packages from the repository. Yum's
"intelligence" in performing updates goes far beyond that of most related tools;
yum has been used successfully on numerous occasions to perform a "running upgrade"of e.g. a
Red Hat 7.1 system directly to 7.3 (where the probability of success naturally depends on how
"customized" the target system is and how much critical configuration file formats have "drifted"
between the initial and final revisions – YMMV).
In addition, the yum client encapsulates various informational tools, and can list rpm's both
installed and available for installation, extract and publish information from the rpm headers
based on keywords or globs, find packages that provide particular files. Yum is therefore of great
use to users of a workstation, either private or on a LAN; with yum they can look over the list of
available packages to see if there is anything "interesting",
search for packages that contain a particular tool or apply to a particular task, and more.
Yum is designed to be a client-pull tool, permitting package management to be "centralized" to
the extent required to ensure security and interoperability even across a broad, decentralized
administrative domain. No root privileges are required on yum
clients -- yum requires at most anonymous access (restricted or unrestricted) from the clients to a
repository server (often one that is maintained by a central -- and competent -- authority). This
makes yum an especially attractive tool for providing "centralized" scalable administration of
Linux systems in a decentralized network management network managers naturally occur (such
as a University).
One of yum's most common uses in any LAN environment is to be run from a nightly cron script
on each yum-maintained system to update every rpm package on the system safely to the latest
versions available on the repository, including all security or operationally patched updates. If
yum is itself installed from an rpm custom-preconfigured to perform this nightly update, an
23
entire campus that installs its systems from a common repository base can achieve near complete
consistency with respect to distribution, revision, and security. Security and other updates will
typically appear on all net-connected clients no more than 24 hours after the an updated rpm is
placed on the repository by its (trusted) administrator who requires no root-level privileges on
any of the clients.
Consequently with yum a single trusted administrator can maintain a trusted rpm repository (set)
for an entire University campus, an entire corporation, an entire government laboratory or
institution. Alternatively, responsibility for different parts of a distribution can be split up safely
between several trusted administrators on distinct repositories, or a local administrator can add a
local trusted repository to overlay or augment the offerings of the campus level repositories. All
systems at a common revision level will be consistent and interoperable to the extent that their
installed packages (plus any overlays by local administrators) allow. Yum is hence an amazingly
powerful tool for creating a customized repository-based package delivery and maintenance
system that can scale the work of a single individual to cover thousands of machines.
And it's free. It just doesn't get any better than that....
2.3 HOW YUM WORKS
To understand how yum works it helps to define a few terms:
server: The term server generally refers to the physical system that provides
access one or more ways to a repository. However when yum was first developed
there was generally only one server per repository and server was often used as
more or less of a synonym for repository. We will use it below only in the former
sense -- as a reference to a particular web, ftp, nfs server that provides access to a
repository, not as the repository itself.
repository: A repository is a collection of rpms under some sort of file system
tree. For most purposes associated with yum, the repository will have two more
important characteristics. It has had the command yum-arch run on the tree,
creating a "headers" directory containing header and path information to all the
24
rpm's under the tree, and is accessible by URL (which means as one or more of
http://my.web.server.ext/path, ftp://my.ftp.server.ext/path, file://full/file/path to he
repository tree).
Server id: As noted above, there used to be a more or less one to one
correspondence between servers and repositories in early versions of yum.
However, this correspondence is not many to many. A single repository can be
mirrored on many servers, and a single server can hold many repositories. When
organizing "robust" access to repositories (which means providing URL's to the
same repository on fallback servers in case the primary server of a repository is
down) it is now necessary to label the repository with some sort of unique id that
obviously cannot be the server or repository alone. The serve rid is thus the
unique label used in yum.conf to indicate that all the repositories given under a
single baseurl are (presumably) mirrors of one another.
RPM: This stands for "Red Hat Package Manager", the toolset developed by Red
Hat for distributing and maintaining "packages" of tools, libraries, binaries, and
data for their Linux distribution. It is fully open source and is currently the basis
for many Linux distributions other than Red Hat. When the documentation below
speaks of "an rpm" it refers to a single package, usually named packagename-
version.rpm. To understand how yum functions, it is necessary to understand a bit
about the structuring of rpm's. An rpm consists of basically three parts: a header, a
signature, and the (generally compressed) archive itself. The header contains a
complete file list, a description of the package, a list of the features and libraries it
provides, a list of tools it requires (from other packages) in order to function, what
(known) other packages it conflicts with, and more. The basic rpm tool needs
information in the header to permit a package to be installed (or uninstalled!) in
such a way that Installing the package breaks none of the already installed
packages (recursively, as they may need packages of their own to be installed).
All the packages that the package requires for correct operation are also (or
already) installed along with the selected package, recursively. A later version of
the package does not (accidentally) replace an earlier version of the package.
Note that a similar list applies to uninstallation: removing a package must not break any 25
packages left behind, for example.
This process is generically known as "resolving package dependencies" and is one of the most
difficult parts of package management. It is quite possible to want to install a packaged tool that
requires two or three libraries and a tool. The libraries in turn may require other libraries, the tool
other tools. By the time you're done, installing the package may require that you install six or
eight other packages, none of which are permitted to conflict or break any of the packages that
are already there or will remain behind.
If you have ever attempted to manage rpm's by hand, you know that tracking down all of the
headers and dependencies and resolving all conflicts is not easy and that it actually becomes
more difficult in time as a system manager updates this on one system, that on another, rebuilds a
package here, installs something locally into /usr/local there.
Eventually (sometimes out of sheer frustration) an rpm is --force installed, and thereafter the rpm
database itself on the system itself is basically inconsistent and any rpm install is likely to fail
and require --force-ing in turn. Entropy creeps into the network, and with it security risks and
dysfunction.
Yet not updating packages is also a losing situation. If you leave a distribution based install
untouched it remains clean. However, parts of it were likely broken at the time of install -- there
are always bugs even in the most careful of major distributions. Some of those bugs are security
bugs, and as crackers discover them and exploits are developed it rapidly becomes a case of
"patch your system or lay out the welcome mat for vermin".
This is a global problem with all operating systems; even Windows-based systems (notorious for
their vulnerability to viruses and crackers) can be made reasonably secure if they are rigorously
kept up to date. Finally, users come along and demand THIS package or THAT package which
are crucial to their work -- but not in the original, clean, consistent installation.
In balance, any professional LAN manager (or even humble standalone Linux workstation
owner) has little choice; they must have some sort of mechanism for updating the packages
already installed on their system(s) to the latest, patched, secure, debugged versions and for
adding more packages, including ones that may not have been in the distribution they relied upon
for their original base install. The only questions are: what mechanism should they use and what
will it cost them (in time, hassle, learning curve, and reliability as well as in money). Let us
26
consider the problem:
In a typical repository, there are a lot of packages (order of 1000), with a lot of headers. About
700 packages are actually installed on the system I'm currently working on. However, the archive
component of each package, which contains the actual binaries and libraries and documentation
installed, is much larger -- the complete rpm is thus generally two to four orders of magnitude
larger than the header. For example, the header for Open Office (a fairly large package) total
about 100 kilobytes in size. The rpm itself, on the other hand, is about 30 megabytes in size. The
header can be reliably delivered in a tiny fraction of a second over most networks; the rpm itself
requires seconds to be delivered over 100BT, and minutes to be delivered over e.g. DSL, cable,
or any relatively slow network. One occupies the physical server of a repository for a tiny
interval; the other creates a meaningful, sustained load on the server. All of these are important
considerations when designing or selecting an update mechanism intended to scale to perhaps
thousands of clients and several distinct repositories per physical server.
Early automated update tools either required a locally mounted repository directory in order to be
able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM
drive, being fast enough to deliver the rpm's in a timely way so that their headers could be
extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an
updating client from the repository just so it could read the header. One was locally fast but
required a large commitment of local disk resources (in addition to creating a new problem, that
of keeping all the local copies of a master repository synchronized). The other was very slow.
Both were also network resource intensive.
This is the fundamental problem that yum solves for you. Yum splits off the headers on the
repository side (which is the job of its only repository-side tool, yum-arch). The headers
themselves are thus available to be downloaded separately, and quickly, to the yum client, where
they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid
(recall that serverid is a label for a single repository that might be mirrored on several servers
and available on a fallback basis from several URL's). Yum clients also cache (space permitting
or according to the requirements and invocation schema selected by the system's administrator)
rpm's when they are downloaded for an actual install or update, giving a yum client the best of
both the options above -- a local disk image of (just the relevant part of) the repository that is
27
automatically and transparently managed and rapid access to just the headers.
An actual download of all the headers associated with packages found on your system occurs the
first time a yum client is invoked and thereafter it adds to or updates the cached headers (and
downloads and caches the required rpm's) only if the repository has more recent versions or if
the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's
dependency resolution then proceeds from these cached header files, and if for any reason the
install or update requires an rpm already in the cache to be reinstalled, it is immediately
available.
As a parenthetical note, the author has used yum's caches in a trick to create a "virtual" update
repository on his homogeneous, DSL-connected home LAN. By NFS exporting and mounting
(rw,no_root_squash) /var/cache/yum to all the LAN clients, once normal updates have caused a
header or rpm to be retrieved for any local host, they are available to all the local hosts over a
(much faster than DSL) 100BT NFS mount. This saves tremendously on bandwidth and
(campus) server load, using instead the undersubscribed server capacity of a tiny but powerful
LAN. Best of all, there "is no setup"; what I just described is the works. A single export and a
mount on all the clients and yum itself transparently does all of the work.
However, it is probably better in many cases to use rsync or other tools to provide a faithful
mirror of the repository in question and use yum's fallback capability to accomplish the same
thing (single use of a limited DSL channel) by design. This gives one a much better capability of
standing alone should update access go away on the "server" of the yum cache NFS exported
across a LAN.
With the header information (only) handy on high-speed local media, the standard tools used to
maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies,
determine if it is safe to proceed, what additional packages need to be installed, and so forth.
Note well that yum is designed (by highly experienced systems administrator, Seth Vidal, with
the help of all the other highly experienced systems administrators on the yum list) to be safe. It
will generally not proceed if it encounters a dependency loop, a package conflict, or a revision
number conflict.
If yum finds that everything is good and the package can be safely installed, removed, or
updated, it can either be invoked in such a way that it does so automatically with no further
28
prompts so it can run automatically from cron, or (the general default when invoked from a
command line) it can issue a user a single prompt indicating what it is about to do and requesting
permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as
informative an error message as it can generate, permitting the system's administrator to attempt
to resolve the situation by hand before proceeding (which may, for example, involve removing
certain conflicting packages from the client system or fixing the repository itself).
From the overview given above, it should be apparent that yum is potentially a powerful tool
indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular
degree of efficiency. One can immediately imagine all sorts of ways to exploit the information
now so readily available to a client and wrap them all up in a single interface to eliminate the
incredibly arcane and complex commands otherwise required to learn anything about the
installed package base on a system and what is still available. The yum developers have been
doing just that on the yum list - dreaming up features and literally overnight implementing the
most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need
to manage packages on any rpm based system once it has gotten past its original, distribution
vendor based, install. Indeed, it is now so powerful that it risks losing some of its appealing
simplicity. This HOWTO is intended to document yum's capabilities so even a novice can learn
to use it client-side effectively in a very short time, and so that LAN administrators can have
Guidance in the necessarily more complex tasks associated with building and maintaining the
repositories from which the yum clients retrieve headers and rpm's.
Yum's development is far from over. Volunteers are working on a GUI (to encapsulate many of
yum's features for tty-averse users). Some of yum's functionality may be split off so that instead
of a single client command there are two, or perhaps three (each with a simpler set of
subcommand options and a clear differentiation of functionality). The idea of making yum's
configuration file XML (to facilitate GUI maintenance and extensibility) is being kicked around.
And of course, new features are constantly being requested and discussed and implemented or
rejected. Individuals with dreams of their own (and some mad python or other programming
skills:-) are invited to join the yum list and participate in the grand process of open source
development.
29
2.4 YUM, RPM, AND RED HAT
Because yum invokes the same tools and python bindings used by e.g. Red Hat to actually
resolve dependencies and perform installations (functioning as basically a super smart shell for
rpm and anaconda that can run directly from the local header cache) it has proven remarkably
robust over several changes to the rpm toolset that have occurred since its inception, some of
them fairly major. It is at least difficult for yum to "break" without Red Hat's own rpm
installation toolset breaking as well, and after each recent major change yum has functioned
again after a very brief period of tune-up.
It is important to emphasize, however, that yum is not a tool for administering Red Hat (only)
repositories. Red Hat will be prominently mentioned in this HOWTO largely because we (Duke)
currently use a Red Hat base for our campus wide Linux distribution, maintain a primary (yum-
enabled) Red Hat mirror, and are literally down the road a few miles from Red Hat itself. Still, if
anything, yum is in (a friendly, open source) competition with Red Hat's own up2date
mechanism and related mechanisms utilized by other distribution vendors.
So Note Well: Yum itself is designed for, and has been successfully used to support, rpm
repositories of any operating system or distribution that relies on rpm's for package management
and contains or can be augmented with the requisite rpm- python tools. Yum has been tested on
or is in production on just about all the major rpm-based linuxes, as well as at least one Solaris
repository. Its direct conceptual predecessor (with which it shares many design features and
ideas, although very little remaining actual code) is Yellowdog Linux's updater tool yup, which
had nothing whatsoever to do with Red Hat per se. Yum truly is free like the air, and distrbution-
diagnostic by deliberate design.
2.5 RPM REPOSITORY
A moment or two of meditation upon dependency resolution should suffice to convince one that
Great Evil is possible in a large rpm repository. You have hundreds, perhaps thousands of rpm
packages. Some are commercial, some are from some major distribution(s), others are local
30
homebrew. What if, in all of these packages built at different times and by different people, you
ever find that there exist rpm's such that (e.g.) rpm A requires rpm B, which conflicts with rpm C
(already installed)? What if rpm A requires rpm B (revision 1.1.1) but rpm B (revision 1.2.1) is
already installed and is required in that revision by rpm C (also already installed)? It is entirely
possible to assemble an "rpm repository from hell" such that nearly any attempt to install a
package will break something or require something that breaks something.
(As yet another parenthetical note, this was the thing that made many rpm-based distribution
users look at Debian with a certain degree of longing. Apt untangles all of this for you and works
entirely transparently from a single distribution "guaranteed to be consistent", and provides some
lovely tools (some of which are functionally cloned in um) for package management and
dependency resolution. However, as is made clear on the yum site, yum is a better solution in
many ways than apt or, for that matter, Current or up2date. I believe that the designers are
working fairly aggressively to make sure it stays that way.)
A cynical (but correct) person would note that this was why rpmfind and other rpm "supertools"
ultimately failed. Yes, rpmfind could locate any rpm on the planet in its super repository a matter
of a few seconds, BUT (big but) resolving dependencies was just about impossible. If one was
lucky, installing an e.g. Mandrake rpm on a Red Hat system that used SuSE libraries rpm's
would work. Sometimes one required luck to install the Red Hat rpm's it would find on a Red
Hat system, as they were old or built with non-updated libraries. Sometimes things would "kind
of work". Other times installing an rpm would break things like all hell, more or less irreversibly.
Untangling and avoiding this mess is what earns the major (rpm-based or not) Linux distribution
providers their money. They provide an entire set of rpm's (or other packages) "all at once" that
are guaranteed to be consistent in the distribution snapshot on the CD's or ISO images or primary
website. All rpm's required by any rpm in the set are in the set. No rpm's in the provided set
conflict with other rpm's in the set. Consequently any rpm in the set can be selected to be
installed on any system built from the distribution with the confidence that, once all the rpm
dependencies are resolved, the rpm (along with its missing dependencies) can be successfully
installed. The set provided is at least approximately complete, so that one supposedly has little
incentive or need to install packages not already in the distribution (except where so doing
requires the customer to "buy" a more expensive distribution from the vendor)
In the real world this ideal of consistency and completeness is basically never achieved. All the
31
distributions I've ever tried or know about have bugs, often aren't totally consistent, and certainly
are not complete. A "good" distribution can serve as a base for a repository and support e.g.
network installs as well as disk or CD local installs, but one must be able to add, delete, update
packages new and old to the repository and distribute them to all the systems that rely on the
repository for update management both automatically and on demand.
Alas, rpm itself is a terrible tool to use for this purpose, a fact that has driven managers of rpm-
based systems to regularly tear their hair for years now. Using rpm directly to manage rpm
installs, the most one can do is look one step ahead to try to resolve dependencies. Since
dependency loops are not at all uncommon on real-world repositories where things are added and
taken away (and far from unknown even in box- et Linux distributions that are supposed to be
dependency-loop free) one can literally chase rpm's around in loops or up a tree trying to figure
out what has to be installed before finally succeeding in installing the one lonely application you
selected originally. rpm doesn't permit one to tell it to "install package X and anything else that it
needs, after you figure out what that might be". Yum, of course, does.
Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering
schemes or dependency specifications that appear in all the rpm's one might find and rebuild or
develop locally for inclusion in a central repository. When one is encountered, a Real Human has
to apply a considerable amount of systems expertise to resolve the problem. This suggests that
building rpm's from sources in such a way that they "play nice" in a distribution repository, while
a critical component of said repository, is not a trivial process. So much so that many rpm
developers simply do not succeed.
Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation
is permitted on all the systems using yum to keep up to date. Installing locally built software into
/usr/local becomes Evil and must be prohibited as impossible to keep up to date and maintained.
Commercial packages have to have their cute (but often dumb) installation mechanisms
circumvented and be repackaged into some sort of rpm for controlled distribution.
Consequently, repository maintainers must willy-nilly become rpm builders to at least some
extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat
based repository, of course you would like to rebuild it and add it. If your University has a site
license for e.g. Mathematics and you would like to install it via the (properly secured and license
controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to
32
repackage yum itself for client installations so that its configuration files point to your
repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.
For all of these reasons an entire section of this HOWTO is devoted to a guide for repository
maintainers and rpm builders, including some practices which (if followed) would make
dependency and revision numbering problems far less common and life consequently good.
In the next few sections we will see where to get yum, how to install it on the server side, and
then how to set up and test a yum client. Following that there will be a few sections on advanced
topics and design issues; how to set up a repository in a complex environment, how to build
rpm's that are relatively unlikely to create dependency and revision problems in a joint
repository, how to package third party (e.g. site licensed) software so it can be distributed,
updated, and maintained via yum (Linux software distributors take note!) and more.
2.6 BUILDING YUM
Before proceeding further, we need to have yum itself handy, specifically the yum-arch
command and its current documentation. If you are working from the rpm's, you've probably
already installed them on your repository (I mean actually installed the program, not necessarily
inserted the rpm's into a server on the repository) and one or two test clients. If not, please do,
and skip ahead to the sections on installing yum or setting up a server with yum-arch and
creating a suitable /etc/yum.conf.
However, if you get the sources via tarball or from the CVS repository, you will have to locally
build yum. If you plan to repackage it (basically required if you are setting up a repository ) so
that yum clients automatically use the yum-based repositories you set up in their /etc/yum.conf,
you will need the tarball (yum-*.tgz) anyway. The steps required to transform the provided
tarball into an rpm are given below.
Note that many of these steps are not yet fully documented in the source README or INSTALL
files and are a major reason a HOWTO is sorely needed by the project. Most of yum's current
systems manager users are already sufficiently expert to be able to build rpm's without additional
instructions, but of course many who would like to use yum are not, and in any event it never
33
hurts to document a moderately complicated process even for the experts.
Experts can also disagree. The steps below are ONE way of proceeding, but there are many
others. Some managers will be working in monolithic (top down) management models where
they have root control of all clients and will prefer to push /etc/yum.conf out to the clients
directly, not de facto pull it onto clients during an install from a repository where it is available,
preconfigured for the site in rpm form. Tools exist to make this simple enough (cfengine, rsync,
more). Different people also have different ways of building rpms. Some always proceed as root,
for example, using /usr/src/redhat (which exist for that purpose, after all).
However, in my own mind working as root is something to be avoided as much as possible
because of the risk of unintended consequences when one makes a mistake. Some of you reading
this HOWTO may be very uncomfortable working as root for this very reason.
I therefore provide step by step instructions on how to turn the yum tarball into an rpm as either a
ser or as root. Naturally, the rpm will have to be installed as root either way Or at least, I'll
provide them later. For the moment, I'm all tapped out and have to go anyway. I may not even
return to this project for a few days. Told you it was a work in progress....
34
CHAPTER 3: YUM SERVER ON RED HAT ENTERPRISE
LINUX 5.0
3.1 BASICS OF CONFIGURING YUM IN RHEL 5.0
In this article we are going to discuss how we can configure Yum for DVD sources in RHEL5.
Yum is the package management tool used these days. It has replaced the old "up2date"
command which use to come with RHEL4. This command used to get updates from the RHN
Red Hat Network) for the installed operating system, if the user using that command had bought
a support/update entitlement from Red Hat. But with the new version of Red Hat and then it's
free clone Centos5 "up2date" has been dropped out and instead of it "yum" as been included.
"yum" was there in Fedora core for a long time and was use to update packages via 3rd party
repositories. It started becoming mature with Fedora and now finally when Red Hat thought it to
be matured enough to make it's way into RHEL it's here.
The major problem one face with Yum is to configure it for DVD/CD sources. Yum by default
doesn't come enabled for these sources and we need to explicitly enable it. I don't know what is
the reason behind not enabling Yum for these sources by default but, whatever it is we can still
hack "yum" on our own and can configure it to use DVD/CD install sources.
Before starting I would like to mention that I am using a DVD source in this article which is
represented by "/dev/dvd" and mounted on "/media/cdrom". The steps I tell here can be easily
extended for CD sources as well. Later in this article I will tell how we can configure a local yum
repository and use it for package management in our LAN clients.
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. For example I have a directory /dvd/rhel5/. I will copy the whole contents
of /media/cdrom into /rhel5.
This is the command
35
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-ore.xml /dvd/rhel5/
mv /dvd/rhel5/VT/repodata/comps-rhel5-vt.xml /dvd/rhel5/
mv /dvd/rhel5/Cluster/repodata/comps-rhel5-cluster.xml /dvd/rhel5/
mv /dvd/rhel5/ClusterStorage/repodata/comps-rhel5-cluster.xml /dvd/rhel5/
Now we need to delete the repodata/ directories which come with the default install tree.
The reason behind this is that in their xml files we have a string
<location> xml:base="media://1170972069.396645#1" ..... </location>
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. Now this command doesn't comes by default I guess so we need to
install it's rpm
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 but I have tried it without any luck. So do the following vi /etc/yum.conf
36
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-
PG-EY-redhat-beta file:///dvd/rhel5/RPM-GPG-KEY-redhat-former
file:///dvd/rhel5/RPM-
PG-KEY-redhat-release
This will be sufficient for now. Let's create the yum cache now.
37
yum clean all
yum update
It's all done now. We can now use "yum" command to install/remove/query packages and now
yum will be using the local yum repository. Well I am mentioning some of the basic "yum"
commands which will do the job for you for more options to the "yum" command see the man
page of "yum".
yum install package_name Description: Installs the given package
yum list Description: List's all available package in the yum database
yum search package_name Description: Search for a particular package in the
database and if found print's a brief info about it.
yum remove package_name Description: Remove's a package.
Now we can also use the GUI based "yum" client named "pirut".
This is a screenshot of "pirut" after we have configured local yum repository.
Fig.: 3.1.1 “Pirut”
When you install package for the first time either by using pirut or yum it ask you to sign
the gpg-key's if you don't do so it will not install the package and the installation will fail.
38
Signing the gpg's is necessary for the first time and later not needed at all.
Now we will mention the steps you can use to extend this local repository to become a local http
based repository so that LAN clients can use it for package management. I will be using Apache
to configure this repository as it's the best available software for this job.
Do configure the repository for http access via LAN clients we need to make it available
to them. For that I am declaring a virtual host entry in apache's configuration file. This is
how it looks for us
<VirtualHost 192.168.1.5:80>
ServerAdmin [email protected]
ServerName server.example.com
DocumentRoot "/dvd/rhel5/"
ErrorLog logs/server.example.com-error_log
CustomLog logs/server.example.com-access_log common
</Virtualhost>
After this
service httpd start
chkconfig httpd on
Now it's time to make a yum.conf file that we will use at the client end. I am writing my
yum.conf for clients. You can use it and modify according to your setup.
[main]
cachedir=/var/cache/yum=
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
39
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
plugins=1
metadata_expire=1800
gpgcheck=1
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
[Server]
name=Server
baseurl=http://192.168.1.5/Server/
enabled=1
[VT]
name=Virtualization\\
baseurl=http://192.168.1.5/VT/
enabled=1
[Cluster]
name=Cluster
baseurl=http://192.168.1.5/Cluster/
enabled=1
[ClusterStorage]
name=Cluster Storage
baseurl=http://192.168.1.5/ClusterStorage/
enabled=1
40
Copy this file to /etc/ directory of the client end and replace it with the original file there.
After copying is done it's time to do this
yum clean all
yum update
rpm --import /etc/pki/rpm-gpg/*
Now you can use yum on the client end to just install any package and it will
communicate with the local repo server to get the package for you. You can also use pirut
in the same way to get things done.
So this is how we can configure Yum for RHEL5 Server and can also use it to create our
own local repo server for the LAN.
41
Chapter 4: SAMBA SERVER
4.1 WHAT IS SAMBA
Samba is a software package that gives network administrators flexibility and freedom in terms
of setup, configuration, and choice of systems and equipment. Because of all that it offers,
Samba has grown in popularity, and continues to do so, every year since its release in
1992.Samba is an implementation of a Server Message Block (SMB) protocol server that can be
run on almost every variant of UNIX in existence. Samba is an open source project, just like
Linux. The entire code is written in C so it is easily portable to all flavors of UNIX Sambas a
tool for the peaceful coexistence of UNIX and Windows on the same network on the level of File
and Print sharing over the NetBIOS protocol. It allows UNIX systems to move into a Windows
“Network Neighborhood” without causing a mess. With Samba, UNIX servers are acting as any
other Windows server, offering its resources to the SMB clients. Recently SMB was renamed by
Microsoft to Common Internet File System (CIFS). Samba is software that can be run on a
platform other than Microsoft Windows, for example, UNIX, Linux, IBM System 390,
OpenVMS, and other operating systems. Samba uses the TCP/IP protocol that is installed on the
host server. When correctly configured, it allows that host to interact with a Microsoft Windows
client or server as if it is a Windows file and print server. Linux distributions now supply their
own tools for configuring Samba in a simple way, and these are mentioned below. Samba itself
also includes a basic Web-based configuration system called SWAT, which is often provided in
a separate package to the Samba server and client software. Once installed, it listens on port 901,
so you can access it by typing the URI in your Web browser.
4.2 FEATURES AND BENEFITS
Samba can replace an MS Windows NT4 domain controller.
Samba offers excellent interoperability with MS Windows NT4-style domains
as well as natively with Microsoft Active Directory domains.
Samba permits full NT4-style interdomain trusts.
42
Samba has security modes that permit more flexible authentication than is
possible with MS Windows NT4 domain controllers.
Samba permits use of multiple concurrent account database backend.
(Encrypted passwords that are stored in the account database are in formats
that are unique to Windows networking).
The account database backend can be distributed and replicated using multiple methods.
This gives Samba greater flexibility than MS Windows NT4 and in many cases a significantly
higher utility than Active Directory domains with MS Windows 200x.
With Samba, a Linux server can act as a file/print server for Windows networks. It can replace
expensive Windows NT file/print servers in this role, a less expensive solution.
Samba can act as a NetBIOS name server (NBNS) in a Windows world referred to as WINS -
Windows Internet Name Service.Samba can participate in NetBIOS browsing and master
browser elections.
Samba can act as a NetBIOS name server (NBNS) in a Windows world referred to as WINS -
Windows Internet Name Service.Samba can provide a gateway for synchronization of UNIX and
Windows NT passwords.
With Samba client software you can access any shared directory or printer on Windows NT
servers or Samba servers and allow UNIX machines to access Windows NT files.
Using the Samba File System (SMBFS) you can mount any share from a Windows NT server or
a Samba server in your directory.
4.3 BASICS OF CONFIGURING SAMBA
In this section we will explain how to configure Samba so it can participate as a file and print
server in an existing Windows network or be a stand-alone file and print server for Windows and
Linux clients. Before you can start using Samba, you will need to configure the smb.conf file.
This file is the heart of the Samba server. When the Samba package is installed, a default
configuration file is installed in: /etc/smb.conf.
4.3.1 THE smb.conf FILE IS DIVIDED INTO TWO MAIN SECTIONS
1. Share Definitions - here you define shares. A share is a directory on the
43
server that is accessible over the network and shared among users. This
section has three subsections.
Homes - in this subsection you define the user’s home directories.
Printers - in this subsection you define the available printers.
Shares - this subsection you can have an entry for each share you
would like to define.
2. Global Settings - Used to define connection parameters.
4.3.1.1 THE SHARE SECTION
The default configuration file (/etc/samba/smb.conf) allows users to view their Red Hat Linux
home directories as a Samba share. It also shares any printers configured for the Red Hat Linux
system as Samba shared printers. In other words, you can attach a printer to your Red Hat Linux
system and print to it from the Windows machines on your network. Samba uses
/etc/samba/smb.conf as its configuration file. If you change this configuration file, the changes
will not take effect until you restart the Samba daemon with the command service smb restart
Samba's configuration is stored in the smb.conf file, which usually resides in
/etc/samba/smb.conf or /usr/local/samba/lib/smb.conf. You can either edit this file yourself or do
it using one of the many graphical tools that are available, such as the Web-based interface
SWAT that is included with Samba.
The default configuration file (smb.conf) in Red Hat Linux 7.3 allows users to view their Linux
home directories as a Samba share on the Windows machine after they log in using the same
username and password. It also shares any printers configured for the Red Hat Linux system as
Samba shared printers. In other words, you can attach a printer to your Red Hat Linux system
and print to it from the Windows machines on your network.
4.3.1.1.1 The Home Section
Upon connecting to the server, each user may get a [home] share.
[home]
Just a description
comment = Home Directories Set browseable to yes if you want the share to show up with
44
tools like net view or smbclient.
browseable = no
read only = no
The smb.conf file uses the same syntax as the various old .ini files in Windows 3.1: Each file
consists of various sections, which are started by putting the section name between brackets ([])
on a new line. Each contains zero or more key/value pairs separated by an equality sign (=). The
file is just a plaintext file, so you can open and edit it with your favorite editing tool. Each
section in the smb.conf file represents either a share or a meta-service on the Samba server. The
section [global] is special, since it contains settings that apply to the whole Samba server. Samba
supports a number of meta-services, each of which serves its own purpose. For example, the
[homes] share is a meta-service that causes Samba to provide a personal home share for each
user. The [printers] share is a meta-service that establishes print queue support and that specifies
the location of the intermediate spool directory into which print jobs are received from Windows
clients prior to being dispatched to the UNIX/Linux print spooler. The printers meta-service will
cause every printer that is either specified in a printcap file, via the lpstat, or via the CUPS API,
to be published as a shared print queue. The printer’s stanza in the smb.conf file can be set as not
browseable. If it is set to be browseable, then it will be visible as if it is a share. That makes no
sense given that this meta-service is responsible only for making UNIX system printers available
as Windows print queues. If a comment parameter is specified, the value of it will be displayed
as part of the printer name in Windows Explorer browse lists. Each section of the smb.conf file
that specifies a share, or a meta-service, is called a stanza. The global stanza specifies settings
that affect all the other stanzas in the smb.conf file. Configuration parameters are documented in
the smb.conf man page.
4.3.1.2 THE GLOBAL SECTION
This section describes how access should be given to each of the shares, what workgroup the
server is a part of, etc.
[global];
This must be in the same workgroup as the computers trying to access the share. This is the
default and should be kept. It gets past many nasty annoyances Windows machines may provide.
encrypt passwords = yes;
45
Keeping security = user is highly recommended!
It means that each user MUST provide a username/password to access the shares (unless
overridden in a particular share). However, each user must be a user on the server. You can
easily add users with the adduser command.
security = user;
Another way to provide access, but much less secure and not recommended.
security = share;
You now need to supply it with a password backend (a place to store usernames/passwords).It is
recommended that you use smbpasswd, though larger networks may require tbdsam.
Smbpasswd works similarly to passwd, you may add
usernames, passwords, etc.Remember, however, using security = user means you must have
UNIX accounts for each user!
passwd backend = smbpasswd
passwd backend = tbdsam
passwd backend = smbpasswd guest
This last option lets you have a guest account that may access the shares.
4.4 SECURITY PARAMETERS
We will briefly explain each security mode:
1. User - user/password validation is done on the server that is offering the resource.
This mode is the most widely used.
2. Share - for this security mode, clients need to supply only the password for the
resource. This mode of security is the default for the Windows 95 file and print
servers. It is not recommended for use in a UNIX environment as it violates the
UNIX security model.
3. Domain - this security level is basically the same as server security, with the
exception that the Samba server becomes a member of a Windows NT domain. In
this case, the Samba server can also participate in such things as trust
relationships.
4. Server - the user/password validation is done on the specified authentication
server. This server can be a Windows NT server or another Samba server.
46
4.4.1 SAMBA SECURITY MODES
In this section, the function and purpose of Samba's security modes are described. An accurate
understanding of how Samba implements each security mode as well as how to configure MS
Windows clients for each mode will significantly reduce user complaints and administrator
heartache. Microsoft Windows networking uses a protocol that was originally called the Server
Message Block (SMB) protocol. Since some time around 1996 the protocol has been better
known as the Common Internet File system (CIFS) protocol.
In the SMB/CIFS networking world, there are only two types of security: user-level and share
level. We refer to these collectively as security levels. In implementing these two security levels,
Samba provides flexibilities that are not available with MS Windows NT4/200x servers. In fact,
Samba implements share-level security only one way, but have four ways of implementing user-
level security. Collectively, we call the Samba implementations of the security levels security
modes. They are known as share, user, domain, ADS, and server modes. They are documented in
this chapter.
An SMB server informs the client, at the time of a session setup, the security level the server is
running. There are two options: share-level and user-level. This of these two the client receives
affects the way the client then tries to authenticate itself. It does not directly affect (to any great
extent) the way the Samba server does security. This may sound strange, but it fits in with the
client/server approach of SMB. In SMB everything is initiated and controlled by the client, and
the server can only tell the client what is available and whether an action is allowed.
The term client refers to all agents whether it is a Windows workstation, a Windows server,
another Samba server, or any vanilla SMB or CIFS client application (e.g., smbclient) that makes
use of services provided by an SMB/CIFS server.
4.4.1.1 USER LEVEL SECURITY
We describe user-level security first because its simpler. In user-level security, the client sends a
session setup request directly following protocol negotiation. This request provides a username
and password. The server can either accept or reject that username/password combination. At
this stage the server has no idea what share the client will eventually try to connect to, so it can't
base the accept/rejection anything other than the username/password the name of the client
47
machine.
If the server accepts the username/password credentials, the client expects to be able to mount
shares (using a tree connection) without further specifying a password. It expects that all access
rights will be as the username/password credentials set that was specified in the initial session
setup.
It is also possible for a client to send multiple session setup requests. When the server responds,
it gives the client a uid to use as an authentication tag for that username/password. The client can
maintain multiple authentication contexts in this way (WinDD is an example of an application
that does this).
Windows networking user account names are case-insensitive, meaning that upper-case and
lower-case characters in the account name are considered equivalent. They are said to be case-
preserving, but not case significant. Windows and LAN Manager systems previous to Windows
NT version 3.10 have case-insensitive passwords that were not necessarily case-preserving. All
Windows NT family systems treat passwords as case-
reserving and case-sensitive.
EXAMPLE CONFIGURATION
The smb.conf parameter that sets user-level security is:
security = user
This is the default setting since Samba-2.2.x.
4.4.1.2 SHARE-LEVEL SECURITY
In share-level security, the client authenticates itself separately for each share. It sends a
password along with each tree connection request (share mount), but it does not explicitly send a
username with this operation. The client expects a password to be associated with each share,
independent of the user. This means that Samba has to work out what username the client
probably wants to use, because the username is not explicitly sent to the SMB server. Some
commercial SMB servers such as NT actually associate passwords directly with shares in share-
level security, but Samba always uses the UNIX authentication scheme where it is a
48
username/password pair that is authenticated, not a share/password pair.
To understand the MS Windows networking parallels, think in terms of MS Windows 9x/Me
where you can create a shared folder that provides read-only or full access, with or without a
password.
Many clients send a session setup request even if the server is in share-level security. They
normally send a valid username but no password. Samba records this username in a list of
possible usernames. When the client then issues a tree connection request, it also adds to this list
the name of the share they try to connect to (useful for home directories) and any users listed in
the user parameter in the smb.conf file. The password is then checked in turn against these
possible usernames. If a match is found, then the client is authenticated as that user.
Where the list of possible user names is not provided, Samba makes a UNIX system call to find
the user account that has a password that matches the one provided from the standard account
database. On a system that has no name service switch (NSS) facility, such lookups will be from
the /etc/passwd database. On NSS enabled systems, the lookup ill go to the libraries that have
been specified in the nsswitch.conf file. The entries in that file in which the libraries are specified
are:
passwd: files nis ldap
shadow: files nis ldap
group: files nis ldap
In the example shown here (not likely to be used in practice) the lookup will check /etc/passwd
and /etc/group, if not found it will check NIS, then LDAP.
EXAMPLE CONFIGURATION
The smb.conf parameter that sets share-level security is:
Security = share
4.4.1.3 DOMAIN SECURITY MODE (USER-LEVEL SECURITY)
Domain security provides a mechanism for storing all user and group accounts in a central,
shared, account repository. The centralized account repository is shared between domain
(security) controllers. Servers that act as domain controllers provide authentication and
validation services to all machines that participate in the security context for the domain. A
primary domain controller (PDC) is a server that is responsible for maintaining the integrity of
49
the security account database. Backup domain controllers (BDCs) provide only domain logon
and authentication services. Usually, BDCs will answer network logon requests more
responsively than will a PDC.
When Samba is operating in security = domain mode, the Samba server has a domain security
trust account (a machine account) and causes all authentication requests to be passed through to
the domain controllers. In other words, this configuration makes the Samba server a domain
member server, even when it is in fact acting as a domain controller. All machines that
participate in domain security must have a machine account in the security database.
Within the domain security environment, the underlying security architecture uses user-level
security. Even machines that are domain members must authenticate on startup. The machine
account consists of an account entry in the accounts database, the name of which is the NetBIOS
name of the machine and of which the password is randomly generated and known to both the
domain controllers and the member machine. If the machine account cannot be validated during
startup, users will not be able to log on to the domain using this machine because it cannot be
trusted. The machine account is referred to as a machine trust account.
There are three possible domain member configurations:
Primary domain controller (PDC) - of which there is one per domain.
Backup domain controller (BDC) - of which there can be any number per domain.
Domain member server (DMS) - of which there can be any number per domain.
We will discuss each of these in separate chapters. For now, we are most interested in
basic DMS configuration.
EXAMPLE CONFIGURATION
Samba as a Domain Member Server
This method involves addition of the following parameters in the smb.conf file:
Security = domain
Workgroup = MIDEARTH
In order for this method to work, the Samba server needs to join the MS Windows NT security
domain.
50
This is done as follows:
On the MS Windows NT domain controller, using the Server Manager, add a machine account
for the Samba server.
On the UNIX/Linux system executes:
root# net rpc join -U administrator% password
4.4.1.4 ADS SECURITY MODE (USER-LEVEL SECURITY)
Both Samba-2.2, and Samba-3 can join an Active Directory domain using NT4 style RPC based
security. This is possible if the domain is run in native mode. Active Directory in native mode
perfectly allows NT4-style domain members. This is contrary to popular belief.
If you are using Active Directory, starting with Samba-3 you can join as a native AD member.
Why would you want to do that? Your security policy might prohibit the use of NT-compatible
authentication protocols. All your machines are running Windows 2000 and above and all use
Kerberos. In this case, Samba, as an NT4-style domain, would still require NT-compatible
authentication data. Samba in AD-member mode can accept Kerberos tickets.
Sites that use Microsoft Windows active directory services (ADS) should be aware of the
significance of the terms: native mode and mixed mode ADS operation. The term realm is used
to describe Kerberos-based security architecture (such as is used by Microsoft ADS).
EXAMPLE CONFIGURATION
realm = your.kerberos.REALM
securitu = ADS
The following parameter may be required:
password server = your.kerberos.server
51
4.4.1.5 SERVER SECURITY (USER-LEVEL SECURITY)
Server security mode is left over from the time when Samba was not capable of acting as a
domain member server. It is highly recommended not to use this feature. Server security mode
has many drawbacks that include:
Potential account lockout on MS Windows NT4/200x password servers.
Lack of assurance that the password server is the one specified.
Does not work with Winbind, which is particularly needed when storing profiles remotely.
This mode may open connections to the password server and keep them open for extended
periods.
Security on the Samba server breaks badly when the remote password server suddenly shuts
down.
With this mode there is NO security account in the domain that the password server belongs to
for the Samba server.
In server security mode the Samba server reports to the client that it is in user-level security. The
client then does a session setup as described earlier. The Samba server takes the
username/password that the client sends and attempts to log into the password server by sending
exactly the same username/password that it got from the client. If that server is in user-level
security and accepts the password, then Samba accepts the client's connection. This parameter
allows the Samba server to use another SMB server as the server password.
You should also note that at the start of all this, when the server tells the client what security
level it is in, it also tells the client if it supports encryption. If it does, it supplies the client with a
random crypt key. The client will then send all passwords in encrypted form. Samba supports
this type of encryption by default.
The parameter security = server means that Samba reports to clients that it is running in user
mode but actually passes off all authentication requests to another user mode server. This
requires an additional parameter password server that points to the real authentication server. The
real authentication server can be another Samba server, or it can be a Windows NT server, the
latter being natively capable of encrypted password support.
EXAMPLE CONFIGURATION
52
Using MS Windows NT as an Authentication Server
This method involves the additions of the following parameters in the smb.conf file:
Encrypt passwords = yes
Security = server
password server = "NetBIOS_name_of_a_DC"
There are two ways of identifying whether or not a username and password pair is valid.
One uses the reply information provided as part of the authentication messaging process, the
other uses just an error code.
The downside of this mode of configuration is that for security reasons Samba will send the
password server a bogus username and a bogus password, and if the remote server fails to reject
the bogus username and password pair, then an alternative mode of identification or validation is
used. Where a site uses password lockout, after a certain number of failed authentication
attempts, this will result in user lockouts.
Use of this mode of authentication requires a standard UNIX account for the user. This account
can be blocked to prevent logons by non-SMB/CIFS clients.
4.5 BASICS OFCONFIGURING SAMBA SERVER ON RED HAT
ENTERPRISE LINUX 5.0
4.5.1 STEP 1: ENABLE NETWORK CONNECTIVITY TO THE
SAMBA SERVER
Using the Fedora Network Configuration tool you will need to ensure that the Ethernet card is
enabled and properly functioning. Get quick access to the tool through this command: system-
config-network.
Once in the Network Configuration tool, you should ensure that your Ethernet device is
enabled. If it is not, select the eth device and then click on the Edit button. This will allow you to
53
input the
vital network adapter settings including: statically set IP address, subnet mask, and gateway. You
should also select the top checkbox labeled Activate device when computer starts.
Close and save any changes you've made. The main goal is to ensure you have an ACTIVE and
functioning network card on the SAMBA server. Restart the network services or simply reboot
your SAMBA server. Now try a ping to the server from another PC on the same subnet. At a
command prompt, for example, type:
ping 10.2.2.3
The ping should come back good validating your network connection.
4.5.2 STEP 2: UPDATE FIREWALL SETTINGS
In most cases the default Firewall setting on the SAMBA server locks out any inbound network
requests. I've had a great many people come running to me about this issue. If you're setting up a
basic SAMBA server within your business intranet, allow your Ethernet connection to be a
trusted device so others can get to your SAMBA server and not be bounced by the server's
Firewall.
NOTICE: if you plan to use the SAMBA server outside of your business firewall/intranet, you
should NOT follow the next step. Instead you allow your local server to receive packets by
making changes to your IPTABLES, such as:
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
The following step is for those using an intranet business server configuration. Okay, now to
allow your intranet based SAMBA server to properly accept incoming requests, from your Main
menu choose System Settings, then Security Level. You can access this also by typing the
command:
system-config-securitylevel
54
Please select the box next to the Ethernet card you are using for intranet connectivity so that it
becomes a TRUSTED DEVICE. Otherwise you have a super secure server that bounces inbound
requests. Notice, this selection effects all the items in the Services listing above it, so please be
careful in what context you allow a trusted device!
Press OK when finished.
4.5.3 STEP 3: ENABLE SMB SERVICES
Ironically, the SMB daemon and other core services are usually NOT started by default.
You will need to change this so that your SMB daemon is now started.
Using the GUI from the main menu, go to System Settings, then Server Settings, then choose
Services. You can also get to this using the command: system-config-services
While you're looking over this long list of services, please DISABLE things you know for sure
you do not need to run on this SAMBA server. For instance apmd, isdn, etc. But also ensure that
key services such as SMB are selected and RUNNING. Select SMB and press the Start button. If
it is supposedly already running you can press the Restart button to be sure it is indeed running
correctly now.
Now press the Save button to make sure the configuration changes have been saved for future
restarts.
Sometimes using the GUI just does not properly restart the SMB daemon. In such odd cases, I
want to suggest you force a manual restart from the command line with this command:
/etc/rc.d/init.d/smb restart
If you keep having startup failures, where for every reboot you need to perform Step 3, you may
need to manually configure your start up processes so that SMB will always be in the init.d boot
up.
4.5.4 STEP 4: CREATE SERVER USERS AND DIRECTORIES
55
You will need to ensure that people also have a login to the SAMBA server to do their work.
Logins should be provided on an as needed basis. Obviously, in most cases the users accessing
the SAMBA server will be a subset of the total users on the Windows business network.Create
user logins with the Gnome User Manager tool in Fedora. You can find this from the main menu
by choosing System Settings, then Users & Groups. The command for this is: system-config-
users
Notice this is the first step in creating SAMBA users, which comes later.
Add as many users as you need and then move on to the next part, which is creating directories
(aka. folders) for use.
This is such an obvious step most people usually forget to think about it before hand.
However, it is very helpful to think ahead what directories you will allow access to on the
SAMBA Server for business use. In my case the people needing SAMBA server access will be
updating WebPages. Therefore, I do not need to add any other folders for file sharing or group
interaction. Be sure you add any folders in a reasonable and ordered fashion.
4.5.5 STEP 5: CONFIGURE THE SAMBA SERVER
It's time to configure your SAMBA server to allow others on the intranet to login and use the
server from Windows or Linux PCs. From the main Fedora menu, choose System Settings, then
Server Settings, then Samba. You can also get to this tool by typing the command: system-
config-samba
You are about to make changes to the SAMBA Configuration file called smb.conf. This file is
found under /etc/samba. If you encounter issues you may want to first start by using my example
smb.conf file and then make the changes below. I also want you to be aware that you can edit
56
configuration files with the web interface tool called Samba Web Administration Tool(SWAT)
and several others. Now lets move ahead using the Configuration tool using the preloaded
Fedora tools. NOTICE that many people begin by tinkering with their .conf file... this is NOT a
good idea. First ensure that the basic samba connectivity works and THEN you can tinker with
the smb.conf! (see troubleshooting below)
4.5.5.1 A. BEGIN BY MAKING CHANGES TO THE SERVER SETTINGS
Under the Preference menu item choose Server Settings...
Be sure to include the Windows workgroup name. In the example above the workgroup has been
changed to net. Your situation may be different. In many cases naming the workgroup simply
workgroup is fine, so long as your Windows PCs connect to this same name.
Under this same window, click on the Security tab. It comes by default with the appropriate
settings for a basic SAMBA Server. The Authentication mode should be User. You would need
to change this only if you plan to allow logins based on the Microsoft ADS.
Press OK to finish making basic changes to the server.
4.5.5.2 B. SELECT SAMBA USERS
Under the Preference menu item choose Samba Users
In this window you must Add at least one user who will have access to the SAMBA Server.
Notice that only user accounts you created in step 4 should be added to this listing.
Press the Add User button, then from the pull down select a user. Fill out the additional
information needed for this SAMBA user. Press OK when finished.
57
4.5.5.3 C. ADDING A SHARED FOLDER
Under the SAMBA Server Configuration window, you must create at least one SAMBA share
directory.
Press the Add button and then the Browse button. Now choose a folder you wish to make
available to SAMBA users. Be careful, some folders have permissions settings that do not allow
sharing. Now be sure to select the Read/Write option to allow people full access. Don't press OK
yet!
You should see your shared folder appear under the listing as shown in the example above.
4.5.5.4 D. ADDING USERS
In the same window, select the second tab labeled Access. From here choose the first option
labeled Only allow access to specific users and select the users you wish to give access to this
specific SAMBA shared folder. Press OK when finished.
You can repeat steps C and D for each new shared folder.
Once completed, please choose File from the menu then choose Quit.
Hopefully this saved all of your settings properly. If you encounter issues with the graphic
SAMBA configuration tool, such as it failing to accept your changes, then
4.5.6 STEP 6: RESTART THE SAMBA SERVICES
58
Now you need to restart all SAMBA services. You can use the process found in Step 3, except
press the Restart button or use the word restart instead of the word start.
I mentioned earlier that sometimes your changes do not get properly picked up. I've installed so
many different Fedora SAMBA configurations that I can't recall every reason. This may be a
very good time to simply reboot the LINUX/SAMBA Server.
Rebooting will ensure everything gets properly started up and all of the configuration changes
are included. More importantly, this is likely the last time you will ever restart your SAMBA
server again. Some of my FEDORA servers haven't been restarted in years.
4.5.7 STEP 7: ACCESS THE SAMBA SERVER FROM WINDOWS
You're now ready to fully utilize your new intranet SAMBA Server for work. On any Windows
PC you can access the server by simply going to the main Start menu, choosing Run and typing
in the hostname of your SAMBA server. For example: \\linuxserver Please notice that in the
Windows environment you use different slashes and you need to ensure this syntax.
If this does not work, perhaps if the server is not yet included in your DNS, try accessing the
SAMBA Server through its IP address: \\10.2.2.3
Obviously you need to use an actual hostname or IP address and not my example.
If all works well you should instantly see a SERVER LOGIN window. Now login using a
SAMBA created username.
You should then instantly see the shared folder as well as the individual user's personal folder
that exist on the SAMBA Server.
59
4.5.8 STEP 8: CONNECTING TO THE SHARES FROM WINDOWS TO
LINUX AND VICE-VERSA
4.5.8.1 A. CREATING SHARES
A simple share can be defined in the smb.conf file as follows:
[redbook]
comment = Redbook files
path = /redbook
browseable = yes
printable = no
writable = yes
write list = @users
Parameter Description
name resolve order With this parameter you specify how the Samba server will resolve NetBIOS
names into IP addresses. The preferred value is wins lmhosts bcast.Refer to the manual page of
smb.conf for more information.
wins support: If this option is enabled the Samba server will also act as a WINS server.
ins server: With this parameter, you tell Samba which WINS server to use.
Use the same filename you specified for creating the Samba password file in the smb.conf
60
configuration to tell the Samba server where the password file is.
You have to be logged in as root if you want to manage other users.
4.5.8.2 B. LIST SHARES AVAILABLE ON THE SERVER
To list shares that are available from the configured Samba server, execute the following
command:
$ smbclient -L yourhostname
You should see a list of shares available on your server. If you do not, then something is
incorrectly configured. This method can also be used to see what shares are available on other
SMB servers, such as Windows 2000.
If you choose user-level security, you may find that Samba requests a password before it will list
the shares. See the smbclient man page for details. You can force it to list the shares without a
password by adding the option -N to the command line.
4.5.8.3 C. MAPPING SHARES FROM THE COMMAND LINE
Here's an example how to connect to a Samba disk share from Windows. This batch script works
with Windows 98/2000/XP. Simply open up notepad, paste this text into the file, and save it as
something like, "connect.bat." Be sure not to forget the ".bat" or the script will not work. After
that, replace "\\yourServer\share /user:username" with the appropriate names. It will reconnect
the share upon startup each time.
@echo off
echo Connection Script....
61
echo ------------------------------------------
echo .
echo Disconnecting network share...(Z:)
net use /delete z:
echo Reconnecting network share...(Z:)
echo Please enter password if prompted
echo .
net use z: \\yourServer\share /user:username
echo .
echo Script completed...
pause
Here's a second script, this one written in VBScript, so it will only work on Windows
98SE/2000/XP. It is, however, much more reliable, a bit of fault tolerance built in to it.
Once again, just change the appropriate names.
dim wshNetwork
on error resume next
set wshNetwork = CreateObject("WScript.Network")
wshNetwork.MapNetworkDrive "Z:", ""
if Err.number <> 0 then
wscript.echo "Couldn't connect, sorry " & wshNetwork.userName
end if
62
4.5.8.4 D. CHECKING SHARES
An easy way to check if your Samba shares are working properly is to use the smbclient tool in
Linux and the net command in Windows (to install smbclient in debian, simply type "apt-get
installs smbclient"). For instance, to view all of the available share information in Linux, simply
type:
smbclient -L hostname
This is analogous to the following command on a Windows machine:
net view \\hostname
Where hostname can be any host on the network, even local host. You can also provide a
username to smbclient, like so:
smbclient -L hostname -U username
It will then prompt you for a password, you can enter none for anonymous access.
4.5.8.5 E. SHARE PERMISSIONS
Although you can control the share permissions with share parameters, UNIX permissions are
applied before share permissions. Make sure the UNIX permissions let the users access the share
directory in the UNIX environment.
When a user creates a new file on the shared directory, the default create mask used is 0744. For
directory creation, the default create mask is 0755. Create mask parameters Description comment
This describes the function of a share.admin users This parameter is used to specify the users
who have administrative privileges for he share. When they access the share, they perform all
operations as root. path Defines the full path to the directory you are sharing, browseable If this
parameter is set to yes, you can see the share when you are browsing the resources on the Samba
server. The value can be yes or no. printable This parameter is used to specify if the share is a
63
print share. The value can be yes or no. write list Users specified in this list have write access to
the share. If the name begins with @ it indicates a group name. writable This parameter specifies
if the share is writable. The value can be yes or no. read list Users specified in this list has read
access to the share. If the name begins with @ it indicates a group name. read only If this is set to
yes, the share is read only.
4.5.8.6 F. CREATING SHARES FOR HOMW DIRECTORIES
For handling home directories smb.conf has a special share section called [homes]. This share
definition is used for all home directories, so we don’t need to create separate shares for each
user.
When a client requests a connection to a share, existing shares are scanned. If a match is found,
that share is used. If no match is found, the requested share is treated as the username and
validated by security. If the name exists and the password is correct, a share with that name is
created by cloning the [homes] section. Home share definitions use the same parameters as
normal shares. The following is an example of a [homes] share definition in the smb.conf file:
[homes]
comment = Home Directories
path = %H
valid users = %S
browseable = no
writable = yes
create mode = 0700
directory mode = 0700
In this example we used creation masks for files and directories so that all new files and
directories are accessible only by the owner of that home directory.
64
4.5.8.7 G. CREATING A PRINTER SHARE
A Samba server uses the same procedure for [printer] shares as for [home] shares. The share
definitions and user names are tested against the requested share name. If a match is found in the
[printers] share section, a share with that name is cloned with the name of the requested service.
The following is an example of a [printers] definition in the smb.conf file:
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
# Set public = yes to allow user ’guest account’ to print
guest ok = no
writable = no
printable = yes
create mask = 0700
The [printers] section is just like the other share definitions. When a user prints, Samba copies
the data into the spool directory, after which it is handled by the Parameter Description
%H: This variable represents the home directory of the user.
%S: The name of the current service, which is in the case of [home] shares equal to username.
65
CHAPTER 5: PLATFORM DESCRIPTION
5.1 LINUX
Many people still believe that learning Linux is difficult, or that only experts can understand how
a Linux system works. Though there is a lot of free documentation available, the documentation
is widely scattered on the Web, and often confusing, since it is usually oriented toward
experienced UNIX or Linux users. Today, thanks to the advancements in development, Linux
has grown in popularity both at home and at work.
5.1.1 HISTORY
5.1.1.1 UNIX
In order to understand the popularity of Linux, we need to travel back in time, about 30
years ago... Imagine computers as big as houses, even stadiums. While the sizes of those
computers posed substantial problems, there was one thing that made this even worse: every
computer had a different operating system. Software was always customized to serve a specific
purpose, and software for one given system didn't run on another system. Being able to work
with one system didn't automatically mean that you could work with another. It was difficult,
both for the users and the system administrators. Computers were extremely expensive then, and
sacrifices had to be made even after the original purchase just to get the users to understand how
they worked. The total cost per unit of computing power was enormous. Technologically the
world was not quite that advanced, so they had to live with the size for another decade. In 1969,
a team of developers in the Bell Labs laboratories started working on a solution for the software
66
problem, to address these compatibility issues. They developed a new operating system, which
was Simple and elegant.
The Bell Labs developers named their project "UNIX." The code recycling features were very
important. Until then, all commercially available computer systems were written in a code
specifically developed for one system. UNIX on the other hand needed only a small piece of that
special code, which is now commonly named the kernel. This kernel is the only piece of code
that needs to be adapted for every specific system and forms the base of the UNIX system. The
operating system and all other functions were built around this kernel and written in a higher
programming language, C.
This language was especially developed for creating the UNIX system. Using this new
technique, it was much easier to develop an operating system that could run on many different
types of hardware. The software vendors were quick to adapt, since they could sell ten times
more software almost effortlessly.
Weird new situations came in existence: imagine for instance computers from different vendors
communicating in the same network, or users working on different systems without the need for
extra education to use another computer. UNIX did a great deal to help users become compatible
with different systems.
Throughout the next couple of decades the development of UNIX continued. More things
became possible to do and more hardware and software vendors added support for UNIX to their
products. UNIX was initially found only in very large environments with mainframes and
minicomputers (note that a PC is a "micro" computer). You had to work at a university, for the
government or for large financial corporations in order to get your hands on a UNIX system.
But smaller computers were being developed, and by the end of the 80's, many people had home
computers. By that time, there were several versions of UNIX available for the PC architecture,
but none of them were truly free and more important: they were all terribly slow, so most people
ran MS DOS or Windows 3.1 on their home PCs.
5.1.2 PROPERTIES OF LINUX
5.1.2.1 LINUX PROS
A lot of the advantages of Linux are a consequence of Linux' origins, deeply rooted in UNIX,
67
except for the first advantage, of course.
5.1.2.2 LINUX IS FREE
As in free beer, they say. If you want to spend absolutely nothing, you don't even have to pay the
price of a CD. Linux can be downloaded in its entirety from the Internet completely for free. No
registration fees, no costs per user, free updates, and freely available source code in case you
want to change the behavior of your system. Most of all, Linux is free as in free speech.
The license commonly used is the GNU Public License (GPL). The license says that anybody
who may want to do so, has the right to change Linux and eventually to redistribute a changed
version, on the one condition that the code is still available after redistribution. In practice, you
are free to grab a kernel image, for instance to add support for teletransportation machines or
time travel and sell your new code, as long as your customers can still have a copy of that code.
5.1.2.3 LINUX IS PORTABLE TO ANY HARDWARE PLATFORM
A vendor who wants to sell a new type of computer and who doesn't know what kind of OS his
new machine will run (say the CPU in your car or washing machine), can take a Linux kernel
and make it work on his hardware, because documentation related to this activity is freely
available.
5.1.2.4 LINUX WAS MADE TO KEEP ON RUNNING
As with UNIX, a Linux system expects to run without rebooting all the time. That is why a lot of
tasks are being executed at night or scheduled automatically for other calm moments, resulting in
higher availability during busier periods and a more balanced use of the hardware. This property
allows for Linux to be applicable also in environments where people don't have the time or the
possibility to control their systems night and day.
5.1.2.5 LINUX IS SECURE AND VERSATILE
68
The security model used in Linux is based on the UNIX idea of security, which is known to be
robust and of proven quality. But Linux is not only fit for use as a fort against enemy attacks
from the Internet: it will adapt equally to other situations, utilizing the same high standards for
security. Your development machine or control station will be as secure as your firewall.
5.1.2.6 LINUX IS SCALABLE
From a Palmtop with 2 MB of memory to a petabyte storage cluster with hundreds of nodes: add
or remove the appropriate packages and Linux fits all. You don't need a supercomputer anymore,
because you can use Linux to do big things using the building blocks provided with the system.
If you want to do little things, such as making an operating system for an embedded processor or
just recycling your old 486, Linux will do that as well.
5.1.2.7 THE LINUX OS AND MOST LINUX APPLICATIONS HAVE VERY
SHORT DEBUG-TIMES
Because Linux has been developed and tested by thousands of people, both errors and people to
fix them are usually found rather quickly. It sometimes happens that there are only a couple of
hours between discovery and fixing of a bug. There are far too many different distributions.
"Quot capites, tot rationes", as the Romans already said: the more people, the more opinions. At
first glance, the amount of Linux distributions can be frightening, or ridiculous, depending on
your point of view. But it also means that everyone will find what he or she needs. You don't
need to be an expert to find a suitable release. When asked, generally every Linux user will say
that the best distribution is the specific version he is using. So which one should you choose?
Don't worry too much about that: all releases contain more or less the same set of basic packages.
On top of the basics, special third party software is added making, for example, Turbo Linux
more suitable for the small and medium enterprise, Red Hat for servers and SuSE for
workstations. However, the differences are likely to be very superficial. The best strategy is to
test a couple of distributions; unfortunately not everybody has the time for this. Luckily, there is
plenty of advice on the subject of choosing your Linux. A quick search on Google, using the
69
keywords "choosing your distribution" brings up tens of links to good advise. The Installation
HOWTO also discusses choosing your distribution.
5.1.2.8 LINUX IS NOT VERY USER FRIENDLY AND CONFUSING FOR
BEGINNERS
It must be said that Linux, at least the core system, is less userfriendly to use than MS Windows
and certainly more difficult than MacOS, but... In light of its popularity, considerable effort has
been made to make Linux even easier to use, especially for new users. More information is being
released daily, such as this guide, to help fill the gap for documentation available to users at all
levels.
5.1.2.9 IS AN OPEN SOURCE PRODUCT TRUSTWORTHY?
How can something that is free also be reliable? Linux users have the choice whether to
use Linux or not, which gives them an enormous advantage compared to users of proprietary
software, who don't have that kind of freedom. After long periods of testing, most Linux users
come to the conclusion that Linux is not only as good, but in many cases better and faster that the
traditional solutions. If Linux were not trustworthy, it would have been long gone, never
knowing the popularity it has now, with millions of users. Now users can influence their systems
and share their remarks with the community, so the system gets better and better every day. It is
a project that is never finished, that is true, but in an ever changing environment, Linux is also a
project that continues to strive for perfection.
70
CHAPTER 6: LITRETURE REVIEW
6.1 BASIC IDEA
Basic idea for this project is to fulfill the need of interfacing the different operating systems i.e
Microsoft windows and linux. With the help of this project, this idea has been practically
implemented.
Yum server and samba server are the two modules of this project.
With the help of this project, we take a closure look on the scope of linux.
71
CHAPTER 7: METHOD OF IMPLEMENTATION
7.1 SERVER END
7.1.1 YUM SERVER
mkdir cdrom
mount /dev/hda /cdrom
cd cdrom
cd Server
rpm -ivh vsftpd*
mkdir /var/ftp/pub/myserver
cp -r * /var/ftp/pub/myserver
cp /etc/yum.repose.d/rhel(press tab) /etc/yum.repose.d/myserver.repo
edit the copied file
[yum server]
name=red hat enterprise Linux releasever - $basearch - Debug
#baseurl=http://127.0.0.1/pub/myserver
enabled=1
gpgcheck=0
:wq! (save and quit)
Createrepo -v /var/ftp/pub/myserver
cd /
72
service vsftpd restart
yum update
7.1.2 SAMBA SERVER
yum install smb*
cd /
mkdir /share
chmod 777 /share (changing file permissions)
vi /etc/samba/smb.conf (configuration file of samba)
vi /etc/samba/smbusers (to view samba users, nothing should be edited)
copy last seven lines of this file and paste them below them in the same file. Then edit those lines
as per prefrences of the server.
[home]
path = /share (similarly, all fields be edited as per needs)
.
.
.
:wq! (save and quit)
cd /
service network restart
service vsftpd restart
service smb restart
samba server is configured.
7.2 CLIENT END
PRESS START
CLICK ON RUN
ENTER //IP OF SERVER
Shared files can be accessed now.
73
CHAPTER 8: CONCLUSION
Conclusion of this project is that the interfacing of Microsoft windows with Red Hat Enterprise
Linux 5.0(RHEL 5.0) is successfully achieved. The project solves the purpose of sharing the data
present on different operating systems, i.e windows and linux successfully.
74
CHAPTER 9:
REFRENCES
1. redhat.com
2. linuxtutorials.info
3. Linux Complete Reference
4. www.google.com
4.1 www.nixcraft.com
75