Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Advanced.Linux.Networking..Roderick.Smith [Electronic resources] - نسخه متنی

Roderick W. Smith

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








General Samba
Configuration


There are two aspects to Samba configuration:
general configuration options and configurations for specific Samba shares (directories or printers that Samba serves to clients).
Configuring the global options correctly is particularly important, because
problems in these settings can cause the server to be completely inaccessible. The
global settings also affect Samba features that aren't directly related to file
and printer sharing, such as how Samba locates other systems on a NetBIOS
network.

The Samba Configuration File


Samba uses a file called smb.conf for
its configuration. Most Linux distributions place this file in /etc , /etc/samba , or
/etc/samba.d . Like many Linux configuration files, this file uses a pound sign ( # ) as a
comment character. Uncommented lines are broken into separate share
definitions, which are identified by a name in square brackets:

[ share-name ]
Lines following the share name control that
share's settingsthe directory Samba associates with the share, how filenames
are handled, and so on. Global configuration options appear in a section that
looks like a share definition, but it's not. This is the [global] section of the smb.conf file. Settings in this section may be defaults that carry over to
other shares if they're not overridden, or they may be settings that are
meaningful only in the [global] section itself.

Individual settings are controlled through parameters, which in Samba are lines that take the
following form:

parameter = Value
Samba is very flexible in whether parameters
and values are in upper- or lowercase, but by convention I list most parameters
in all lowercase and most values with initial capitalization. A few values
(such as those that refer to Linux filenames) are case-sensitive. Some values
set binary features; for these, Yes , True , and 1 are
synonymous, as are No , False , and 0 .

Setting Server Identification


NetBIOS networks use names for computers and
groups of computers that are independent of the computers' TCP/IP hostnames. For
instance, harding.threeroomco.com could also be known by the NetBIOS name BILLY in the USPRES domain.
To avoid confusion, I use all-uppercase NetBIOS names to distinguish these from
TCP/IP names. The NetBIOS name space has just two levels: computer names and workgroup or domain
names. (NetBIOS domains are unrelated to TCP/IP domains.) For this reason,
Samba needs some way to specify both a NetBIOS name and a NetBIOS workgroup or
domain name.

NOTE

style='width:90.0%'>





align=left border=0>


NetBIOS workgroups and domains are very
similar. A workgroup is a collection of computers with a common workgroup
name. A domain is a workgroup that features a computer (the domain controller ) that provides centralized
authentication and other services. Domains can also be spread across multiple
network segments, which is more difficult to accomplish with workgroups. Samba
can take on the role of a domain controller, as described shortly in " href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch07lev1sec2&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch07lev2sec6#ch07lev2sec6"> Becoming a Domain Controller ."


You specify the workgroup or domain name with
the workgroup parameter, thus:

workgroup = USPRES
This tells the computer that it's a member of
the USPRES workgroup. The system can still communicate with members of other
workgroups, but some functions, such as browsing a network in Windows, rely
upon the workgroup name. Therefore, if you set the workgroup name incorrectly,
your Samba server won't show up in Windows' Network Neighborhood or My Network
Places browsers. This is a common problem with initial Samba configuration.

By default, Samba uses the first component of
the computer's TCP/IP hostname as its NetBIOS name. For instance, on harding.threeroomco.com , Samba uses the NetBIOS name HARDING . You can override
this setting with the netbios
name
parameter. You can also use the netbios aliases parameter to set the computer to respond to multiple NetBIOS names.
For instance, the following parameters tell the computer to respond to both BILLY and WILLIAM :

netbios name = BILLY netbios aliases = WILLIAM
TIP

style='width:90.0%'>





align=left border=0>


It's usually best to use the same TCP/IP
and NetBIOS names for a computer. This will avoid confusion over what the
computer is called. If your computer's TCP/IP hostname is set strangely or
incorrectly, though, the NetBIOS name will inherit this peculiarity. Therefore,
it's a good idea to use netbios
name
to set the name explicitly to whatever the
TCP/IP hostname should be.


Setting Security Options


Early SMB/CIFS implementations sent passwords in cleartext, meaning that they weren't encrypted. This
made the passwords vulnerable to detection by other computers on some types of
local networks, or if SMB/CIFS sessions were passed through routers. Subsequent
versions of SMB/CIFS therefore added password encryption technologies. The
problem is that the encryption methods used by SMB/CIFS are incompatible with
those generally used on Linux systems for managing local users' passwords. It's
impossible to take an encrypted SMB/CIFS password and verify the user against the
normal Linux user database. Therefore, Samba must implement its own password
database to handle encrypted passwords. This database is called smbpasswd , and it's controlled through a
utility of the same name.

Versions of Windows since Windows 95 OSR2 and Windows NT 4.0
SP3 use encrypted passwords by default. These systems cannot connect to a Samba
server that's configured using its default cleartext passwords; one or the
other must be reconfigured. In the long term, it's generally easier and safer
to reconfigure Samba to accept encrypted passwords than it is to reconfigure
the Windows clients to send cleartext passwords.

To enable Samba to use encrypted passwords, you use the encrypt passwords parameter, which is a
binary parameter that tells the system to accept encrypted passwords. Set this
parameter to Yes and Samba will
begin checking for encrypted passwords in its smbpasswd
file. This file must contain encrypted passwords to do any good, though. To add
an encrypted password for a user, issue the following command:

# smbpasswd -a username
This adds the user username
to the smbpasswd file. The
utility will ask for the password (twice, to be sure you don't mistype it). The
computer must already have a valid user called username , or smbpasswd
won't add the name. The first time you run the command, it will complain that
the smbpasswd file doesn't
exist; but it will create the file automatically, so you can ignore this
complaint.

Another important security feature is provided by the hosts allow and hosts deny parameters. These work much
like the /etc/hosts.allow and /etc/hosts.deny files of TCP Wrappers
(discussed in Chapter 4 ): They provide lists of hosts that
are explicitly allowed to connect to the server, or that are explicitly not
allowed to connect, respectively. For instance, the following parameter allows
computers in the 192.168.7.0/24 network to connect, as well as the system algernon.pangaea.edu , but no
others:

hosts allow = 192.168.7. algernon.pangaea.edu
NOTE

style='width:90.0%'>





align=left border=0>


For most configurations, you can skip ahead to the section
entitled "href="http:// /?xmlid=0-201-77423-2/ch07lev1sec3#ch07lev1sec3"> Serving Files with Samba ." The
intervening sections are of interest only if you want your Samba server to
function as a NetBIOS name server, a master browser, or a domain controller.
The default settings work fine on most existing networks.


Becoming a NetBIOS Name
Server


NetBIOS networks require some means of name resolution.
Traditionally, NetBIOS name resolution has used methods separate from TCP/IP
name resolution, but today one option is to use TCP/IP name resolution. In
total, four methods are available:

TCP/IP names It's possible to
use TCP/IP names for name resolution, and in fact Windows 2000, Windows XP, and
Samba all default to this method, despite the fact that it's not strictly a
NetBIOS solution.

An lmhosts file Systems can record mappings of names to IP addresses in a file,
typically called lmhosts , which
works much like the Linux /etc/hosts
file.

Broadcasts Whenever a computer
needs the address of another, the first system can send out a broadcast asking
for the second computer's address. This approach is easy to configure and works
well on small networks, but produces a lot of extraneous chatter on larger
networks. Broadcasts also don't work if your network is split up into multiple
segments separated by routers, unless the routers are configured to echo broadcast
traffic.

A WINS
server A NetBIOS Name Service (NBNS) server, also called a Windows
Internet Name Service (WINS) server, works much like a TCP/IP Domain Name
System (DNS) server in that it translates between machine names and IP
addresses for other systems.

To configure a Samba system to function as a WINS server, you
must set one parameter in the [global]
section of smb.conf :

wins support = Yes
WINS servers require no extra configurationat least not on
the server side. When NetBIOS clients and servers come online, they register
themselves with the WINS server, which maintains information on the systems.
You need to tell all your systems to use the designated WINS server. In
Windows, you do this from the TCP/IP Properties dialog box, as shown in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch07lev1sec2&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch07fig01#ch07fig01"> Figure 7.1 . If you click Use DHCP for WINS
Resolution, you can have Windows obtain this information from a DHCP server. (href="http:// /?xmlid=0-201-77423-2/ch05#ch05"> Chapter 5 includes a discussion of how to
include this information in a Linux DHCP server's configuration.)

Figure 7.1. Windows' TCP/IP
Properties dialog box lets you specify a WINS server address.


width=356 height=437 src="/image/library/english/10035_image003.gif" > To configure a Samba server to use a WINS server for NetBIOS
name resolution, you need to set two smb.conf
parameters: wins server and name resolve order . Give the IP address of
a WINS server as the first parameter's value and one to four names for the four
types of name resolution as the second parameter's value. Samba will attempt to
use each of the name resolution methods specified in the order you list them.
(The options host and bcast stand for normal TCP/IP resolution
methods and NetBIOS broadcasts, respectively.) For instance, you might include
the following parameters:

wins server = 192.168.1.1 name resolve order = wins lmhosts host bcast
It's important that only one system be configured as a WINS server.
If you have multiple WINS servers, it's possible that name resolution will
become unreliable because some systems will register with one server and others
with the other server. (NetBIOS does provide for a secondary name server to
improve reliability without running into this problem, but Samba doesn't
support working as a secondary name server.)

Becoming
a Master Browser


Earlier, I alluded to the Windows Network Neighborhood or My
Network Places browsers. These are not the same as Web browsers, although
Microsoft has blurred the lines in its user interfaces. Rather, these browsers
allow you to browse to SMB/CIFS servers on a NetBIOS network, as shown in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch07lev1sec2&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch07fig02#ch07fig02"> Figure 7.2 . You can double-click on a computer
name to see the SMB/CIFS shares it's defined. File shares show up as folders
and printer shares as printer icons. You can double-click a file share to
access its files much as you do files on the local hard disk.

Figure 7.2. Windows lets you browse
computers within your domain or workgroup, or on other domains or workgroups
with a presence on your local network segment.


width=500 height=377 src="/image/library/english/10035_image004.gif" > This is all well and good from a user's point of view, but it
doesn't happen without effort from the software side. Think of the situation
from the point of view of the Windows network browser: How does it know what
computers on the local network have shares available? NetBIOS answers this
question by designating one computer on a network segment as a local master browser. This computer maintains a list
of the SMB/CIFS servers on its network segment, and delivers this information,
upon request, to SMB/CIFS clients. The result is that the clients need only
locate the master browser, which they do by sending a broadcast message when
they boot, asking for the master browser's address. When a server does this, it
also registers itself with the master browser, thus keeping the master
browser's list up to date.

NetBIOS domains include a second type of master browser, known
as the domain master browser. This master
browser communicates with local master browsers on other subnets that are part
of the same domain. The master browsers exchange browse lists, thus keeping the
systems coordinated, albeit with a bit of a time delay.

Domain master browsers are normally associated with domain
controllers (discussed shortly). A computer must be explicitly configured to
take on this role. Local master browsers, though, are designated through an election process, in which all the computers on a
network segment present their credentials and the one with the highest score
wins the election and becomes the local master browser. It's important that all
master browsers be reliable systems; if the computers frequently crash or
reboot, there'll be frequent periods during which browsing won't work on the
network. It's also important that a Samba system not be too insistent about
winning browser elections; certain parameters can cause Samba to repeatedly
call for elections, which can cause browsing blackouts.

To configure a Samba system to become the local master
browser, you must set it to participate in and win elections. To do this, you
should create [global]
parameters similar to the following:

browse list = Yes local master = Yes preferred master = Yes os level = 65
The browse list
parameter causes Samba to compile a browse list, which it may then share with
other systems. This parameter's default is Yes ,
so it can usually be omitted. The local
master = Yes
parameter is also the default. It causes Samba to
participate in elections, but doesn't guarantee victory. The preferred master parameter defaults to No . When set to Yes , it causes the system to call an
election when it starts up, and periodically thereafter if it doesn't win an
election. If you have multiple Samba servers, you should set this parameter to Yes on at most
one of the servers, otherwise your network will be disrupted by frequent master
browser elections. Finally, the os level
parameter sets the primary criterion used in master browser elections. The
higher the value, the more likely the system is to win. Setting os level = 65 should win against all
Windows systems through at least Windows Me and Windows 2000, but could lose
against a Samba system configured with a higher value. If you don't want a
Samba system to ever win the master browser election, set this parameter's
value to 0 .

Domain master browser configuration requires you to set the
local master browser options to win and to set the domain master = Yes parameter. You should also configure
the system as the primary domain controller, as described shortly in "href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch07lev1sec2&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch07lev2sec6#ch07lev2sec6"> Becoming a Domain Controller ." As with
local master browser configuration, you shouldn't configure more than one
system (Samba or Windows) to become the domain master browser. If your network
uses a workgroup configuration rather than a domain configuration, there's no
need to set this option.

Becoming
a Domain Controller


NetBIOS computers are organized into either workgroups or
domains. These structures are very similar to each other, but a domain is more
centralized; it uses a computer known as a domain
controller to authenticate users. Rather than have every server decide
whether or not to allow users access to shares, the domain controller does this
job. This can greatly simplify administration of a network with several
servers, particularly if users are constantly coming and going. It does,
however, require additional effort to set up initially. Domains also offer
additional features, such as the ability to provide network logon scripts to
clients whenever users log on, and the ability to store Windows profiles, which are individualized desktop
customization settings, so that these settings can move with users from one
client to another. In fact, domain configuration is complex enough that I can
only touch upon its broad outlines in this section.

There are two types of NetBIOS domain controllers:

primary domain controllers (PDCs) and backup domain controllers (BDCs). The BDC takes over
PDC functions if the PDC system crashes or becomes inaccessible. Samba handles
PDC operations well, but Samba can't be used as a BDC.

To configure Samba to work as a PDC, you should add the
following parameters to the [global]
section of your smb.conf file:

security = User encrypt passwords = Yes domain logons = Yes
The security
parameter sets Samba to process its own share-access requests by using Linux's
usernames and passwords. (This is the default for Samba 2.0.0 and later.) The encrypt passwords parameter controls
Samba's use of encrypted passwords, as described earlier. Domains must use
encrypted passwords. The domain logons
parameter is key to PDC operation; it tells Samba to accept domain logon
requests and process them according to the contents of the smbpasswd file. Windows PDCs also function
as domain master browsers and WINS servers, so it's best if you configure your
Samba server to do the same (this was described earlier).

NOTE

style='width:90.0%'>





align=left border=0>


You set the domain name through the workgroup parameter in smb.conf .


If your network includes Windows NT, 2000, or XP systems, you
must take some additional configuration steps. First, Samba versions prior to
2.0.5 don't support Windows NT domain clients, versions prior to 2.2.0 don't
support Windows 2000 domain clients, and versions prior to 2.2.1a don't support
Windows XP or Windows 2000 Service Pack 2 (SP2) clients, so you must upgrade if
you have an earlier version of Samba. Versions 2.2.0 and later add many new
features to NT/2000 domain client support, even for Windows NT 4.0 users. Next,
you need to create what's known as a trust account
on Linux for each NT/2000/XP client. You can do this by issuing the following
commands:

# groupadd -r trust # useradd -r -g trust -d /dev/null -s /dev/null client $ # smbpasswd -a -m client
You only need to issue the groupadd
command once; it creates a special group for the trust accounts. (In fact, you could use an existing group, but it's best to create
a special group for this purpose.) The useradd
command creates a special account for the NetBIOS computer CLIENT . The dollar sign ( $ ) at the end of the username is required.
Finally, the smbpasswd command
adds client to the smbpasswd file. You should not include the dollar sign for the username in this
command. When your Windows NT/2000/XP client next tries to access the domain,
it will log on using its trust account and use Samba's password database for
authenticating its own users.

Domain configuration also requires changes to
the way the clients are configured. This can be handled in the TCP/IP Control
Panel in Windows 9 x /Me. Select the Client for
Microsoft Networks item and click Properties. Windows displays the Client for
Microsoft Networks Properties dialog box shown in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch07lev1sec2&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch07fig03#ch07fig03"> Figure 7.3 . Check
the Log On to Windows NT Domain item and enter the domain name. In Windows
2000, open the System Properties dialog box by right-clicking My Computer on
the desktop and choosing Properties from the resulting pop-up menu. Click the
Network Identification tab, then the Properties button. When you activate the
domain configuration, you'll be asked for an administrative username and
password. Enter an ordinary username and password.

Figure 7.3. Changing to a
domain configuration involves checking a box and entering the domain name on
the Windows client.


width=344 height=400 src="/image/library/english/10035_image005.gif" >

/ 201