Наши партнеры








Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Chapter 11. Additional Samba Information

This chapter wraps up our coverage of the smb.conf configuration file with some miscellaneous options that can perform a variety of tasks. We talk briefly about options for time synchronization, internationalization, messages, and common Windows bugs. For the most part, you will use these options only in isolated circumstances.

Time Synchronization

In a network of computers, the systems on the network must agree on the current time and also on what time files have been modified. One example of the importance of synchronization is the roaming profiles we covered in Chapter 4. It is vital for all clients accessing a roaming profile to agree on what time it is and which client last modified the user's profile.

Time synchronization can also be very important to programmers. A useful group of settings consists of the following options:

[global]
    time server = yes
    dos filetimes = yes
    fake directory create times = yes
    dos filetime resolution = yes
    delete readonly = yes

If you set these options, Samba shares will provide compatibility of file-modification times that Visual C++, nmake, and other Microsoft programming tools require. Otherwise, PC make programs might think that all the files in a directory need to be recompiled every time. Obviously, this is not the behavior you want.

In Chapter 4, we showed you how to create a logon script that used the net time command to synchronize clients' clocks automatically when they log on to the domain. If your network is configured as a workgroup rather than a domain, you can still make use of net time by placing the command:

net time \\sambaserver /set /yes

in a startup script on each client that is run when the system boots. Samba always provides time service—regardless of whether it is running as a primary domain controller—or the time service configuration file parameter is set.

Assuming that domain users log on to the domain at least once per day and workgroup clients reboot frequently, the net time command can keep client systems' clocks fairly well synchronized. However, sometimes domain users stay logged on for longer periods, and workgroup clients can run for days between reboots. In the meantime, the systems' hardware clocks can wander enough to become a problem. It might be possible to work around this, depending on the version of Windows the client system is running. On Windows 98/Me, you can use the Task Scheduler to run the net time command at regular intervals. Likewise, on Windows 2000/XP you can use the MS-DOS at command. However, a better way to deal with this issue is to use Network Time Protocol, which we will discuss shortly.

Proper time synchronization is also important when operating in an Active Directory domain because Active Directory uses Kerberos authentication. When a Kerberos domain controller creates an authentication ticket for a client, the time is encoded into the challenge-and-response exchanges between the client and domain controller. If the client's clock disagrees with the server's clock, authentication can fail.

To provide proper time synchronization in Active Directory domains, Microsoft has adopted Network Time Protocol (NTP), using the name Windows Time Service for its implementation. For further information, the Microsoft white paper entitled The Windows Time Service can be downloaded from http://www.microsoft.com.

The nice thing about this is that NTP is the standard method for synchronizing Unix hosts on a network, so you can synchronize all your Unix systems (including the Samba server) and Windows systems with the following method:

  1. Run NTP on the Unix systems in your network. For more information on using NTP, refer to http://www.ntp.org.

  2. Use one of the Unix systems (such as the Samba host system) as an NTP server to serve Windows 2000/XP clients.

  3. For other Windows clients, you might have to download an update from Microsoft to add Windows Time Service client support or use a third-party application such as the free analogX Atomic TimeSync (http://www.analogx.com). Or you can use the net time command to update the client's clock periodically, as discussed previously.

Time-Synchronization Options

To support roaming profiles, programmers accessing your Samba server, and other time-sensitive functions on your network, you'll want to be aware of the options listed in Table 11-1.

Table 11-1. Time-synchronization options

Option

Parameters

Function

Default

Scope

time server

Boolean

If yes, announces nmbd as an SMB time service to Windows clients

no

Global

time offset

numeric

Adds a specified number of minutes to the reported time

0

Global

dos filetimes

Boolean

Allows non-owners of a file to change its time if they can write to it

no

Share

dos filetime

resolution

Boolean

Causes file times to be rounded to the next even second

no

Share

fake directory create times

Boolean

Sets directory times to avoid an MS nmake bug

no

Share

Magic Scripts

Magic scripts are a method of running programs on Unix and redirecting the output back to the SMB client. These are essentially an experimental hack. However, some users and their programs still rely on these two options for their programs to function correctly. Magic scripts are not widely trusted, and their use is highly discouraged by the Samba Team.

Magic Script Options

Table 11-2 lists the options that deal with magic scripts on the Samba server.

Table 11-2. Magic script options

Option

Parameters

Function

Default

Scope

magic script

string (filename)

File to be executed by Samba, as the logged-on user, when closed

None

Share

magic output

string (filename)

File to log output from the magic file

scriptname.out

Share

Internationalization

Starting with Samba 3.0, Samba supports Unicode "on the wire," requiring no additional effort on your part to support filenames and other text containing characters in international character sets.

Internationalization Options

Samba 2.2.x has a limited ability to speak foreign tongues: if you need to support filenames containing characters that aren't in standard ASCII, some options that can help you are shown in Table 11-3.

Table 11-3. Internationalization options

Option

Parameters

Function

Default

Scope

client code page

Described in this section

Sets a code page to expect from clients

850

Global

character set

Described in this section

Translates code pages into alternate Unix character sets

None

Global

coding system

Described in this section

Translates code page 932 into an Asian character set

None

Global

valid chars

string (set of characters)

Adds individual characters to a code page

None

Global

character set

The global character set option can be used to convert filenames offered through a DOS code page (see the previous section, Section 11.3.1.1) to equivalents that can be represented by Unix character sets other than those in the United States. For example, if you want to convert the Western European MS-DOS character set on the client to a Western European Unix character set on the server, you can use the following in your configuration file:

[global]
    client code page = 850
    character set = ISO8859-1

Note that you must include a client code page option to specify the character set from which you are converting. The valid character sets (and their matching code pages) that Samba accepts are listed in Table 11-5.

Table 11-5. Valid character sets

Character set

Matching code page

Definition

ISO8859-1

850

Western European Unix

ISO8859-2

852

Eastern European Unix

ISO8859-5

866

Russian Cyrillic Unix

ISO8859-7

737

Greek Unix

KOI8-R

866

Alternate Russian Cyrillic Unix

Normally, the character set option is disabled completely.

coding system

The coding system option is similar to the character set option. However, its purpose is to determine how to convert a Japanese Shift JIS code page into an appropriate Unix character set. To use this option, the client code page option described previously must be set to page 932. The valid coding systems that Samba accepts are listed in Table 11-6.

Table 11-6. Valid coding-system parameters

Character set

Definition

SJIS

Standard Shift JIS

JIS8

Eight-bit JIS codes

J8BB

Eight-bit JIS codes

J8BH

Eight-bit JIS codes

J8@B

Eight-bit JIS codes

J8@J

Eight-bit JIS codes

J8@H

Eight-bit JIS codes

JIS7

Seven-bit JIS codes

J7BB

Seven-bit JIS codes

J7BH

Seven-bit JIS codes

J7@B

Seven-bit JIS codes

J7@J

Seven-bit JIS codes

J7@H

Seven-bit JIS codes

JUNET

JUNET codes

JUBB

JUNET codes

JUBH

JUNET codes

JU@B

JUNET codes

JU@J

JUNET codes

JU@H

JUNET codes

EUC

EUC codes

HEX

Three-byte hexadecimal code

CAP

Three-byte hexadecimal code (Columbia AppleTalk Program)

Windows Messenger Service

One of the odd features of SMB protocol is its ability to send text messages between computers. Although both the name and functionality are similar to that of Windows Messenger, the two are not the same. Windows Messenger (also called MSN Messenger) is an Internet-oriented instant messenging service, while Windows Messenger Service is an older and simpler LAN-oriented service. Using the Windows Messenger Service, messages can be addressed to users, individual computers, or entire workgroups on the network.

The WinPopup tool (Winpopup.exe), shown in Figure 11-1, can be used on Windows 95/98/Me to send or receive messages. WinPopup is a handy tool for sending messages. However, to receive messages, it must already be running when the message is sent from the remote system.

Figure 11-1. Sending a message from a Windows 95/98/Me system (left); receiving a message (right)

On Windows NT/2000/XP, the messenger service lets you receive messages without having an application already running; messages will automatically appear in a small dialog box on the screen when received, as shown in Figure 11-2.

Figure 11-2. Receiving a message on a Windows 2000 system

To send messages, it is necessary to use the net send command from a command-prompt window, like this:

C:\> net send maya "Who's There?"
The message was successfully sent to MAYA.

Windows Messenger Service Configuration Option

Samba has a single option to handle Windows Messenger Service, message command, as shown in Table 11-7.

Table 11-7. Windows Messenger Service configuration option

Option

Parameter

Function

Default

Scope

message command

string (shell command)

Sets a command to run on Unix when a WinPopup message is received

None

Global

Miscellaneous Options

Many Samba options are available to deal with operating system issues on either Unix or Windows. In particular, some of these options are used for setting limits for clients' use of resources on the Unix server. The options shown in Table 11-9 deal with some of these issues.

Table 11-9. Miscellaneous options

Option

Parameters

Function

Default

Scope

deadtime

numeric (minutes)

Number of minutes of inactivity before a connection should be terminated.

0

Global

dfree command

string (command)

Used to specify a command that returns free disk space in a format recognized by Samba.

None

Global

fstype

NTFS, FAT, or Samba

Filesystem type reported by the server to the client.

NTFS

Global

keepalive

numeric (seconds)

Number of seconds between checks for an inoperative client.

300 (none)

Global

max disk size

numeric (MB)

Largest disk size to return to a client, some of which have limits. Does not affect actual operations on the disk.

0 (infinity)

Global

max mux

numeric

Maximum number of simultaneous SMB operations that clients can make.

50

Global

max open files

numeric

Limits number of open files to be below Unix limits.

10000

Global

max xmit

numeric

Specifies the maximum packet size that Samba will send.

65535 or 16644

Global

nt pipe support

Boolean

Turns off an NT/2000/XP support feature; for benchmarking or in case of an error.

yes

Global

nt smb support

Boolean

Turns off an NT/2000/XP support feature; for benchmarking or in case of an error.

yes

Global

ole locking compatibility

Boolean

Remaps out-of-range lock requests used on Windows to fit in allowable range on Unix. Turning it off causes Unix lock errors.

yes

Global

panic action

string

Command to run if Samba server fails; for debugging.

None

Global

set directory

Boolean

If yes, allows VMS clients to issue set dir commands.

no

Global

status

Boolean

If yes, allows Samba to monitor status for smbstatus command.

yes

Global

strict sync

Boolean

If no, ignores Windows application requests to perform a sync-to-disk.

no

Global

sync always

Boolean

If yes, forces all client writes to be committed to disk before returning from the call.

no

Global

strip dot

Boolean

If yes, strips trailing dots from Unix filenames.

no

Global

change notify timeout

numeric (seconds)

Interval between checks when a client asks to wait for a change in a specified directory.

60

Global

stat cache

Boolean

If yes, Samba will cache recent name mappings.

yes

Global

stat cache size

numeric

Number of entries in the stat cache.

50

Global

deadtime

This global option sets the number of minutes that Samba will wait for an inactive client before closing its session with the Samba server. A client is considered inactive when it has no open files and no data is being sent from it. The default value for this option is 0, which means that Samba never closes any connection, regardless of how long they have been inactive. This can lead to unnecessary consumption of the server's resources by inactive clients. We recommend that you override the default as follows:

[global]
    deadtime = 10

This tells Samba to terminate any inactive client sessions after 10 minutes. For most networks, setting this option as such will not inconvenience users because reconnections from the client are generally performed transparently to the user. See also the keepalive parameter.


TOC