Software: Apache/2.0.54 (Fedora). PHP/5.0.4 uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 uid=48(apache) gid=48(apache) groups=48(apache) Safe-mode: OFF (not secure) /usr/share/doc/samba-3.0.23a/htmldocs/using_samba/ drwxr-xr-x |
Viewing file: Select action/file-type: ![]() Chapter 11. Additional Samba InformationThis 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 SynchronizationIn 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:
Time-Synchronization OptionsTo 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
time serverSamba always operates as an SMB time server, matching the behavior of Windows systems. However, Samba's default is not to advertise itself as a time server to the network. When this option is set to yes, Samba advertises itself as an SMB time server: [global] time service = yes time offsetTo deal with clients that don't properly process daylight savings time, Samba provides the time offset option. If set, it adds the specified number of minutes to the current time. This is handy if you're in Newfoundland and Windows doesn't know about the 30-minute time difference there: [global] time offset = 30 dos filetimesTraditionally, only the root user and the owner of a file can change its last-modified date on a Unix system. The share-level dos filetimes option allows the Samba server to mimic the characteristics of a DOS or Windows system: any user can change the last-modified date on a file in that share if she has write permission to it. To do this, Samba uses its root privileges to modify the timestamp on the file. By default, this option is disabled. Setting this option to yes is often necessary to allow PC make programs to work properly. Without it, they cannot change the last-modified date themselves. This often results in the program thinking all files need recompiling when they really don't. dos filetime resolutionThe dos filetime resolution parameter is a share-level option. If set to yes, Samba rounds file times to the closest 2-second boundary. This option exists primarily to satisfy a quirk in Windows that prevents Visual C++ from correctly recognizing that a file has not changed. You can enable it as follows: [data] dos filetime resolution = yes We recommend using this option only if you are using Microsoft Visual C++ on a Samba share that supports opportunistic locking. fake directory create timesThe fake directory create times option exists to keep PC make programs sane. VFAT and NTFS filesystems record the creation date of a specific directory, while Unix does not. Without this option, Samba takes the earliest recorded date it has for the directory (often the last-modified date of a file) and returns it to the client. If this is not sufficient, set the following option under a share definition: [data] fake directory create times = yes If set, Samba will adjust the directory create time it reports to the hardcoded value January 1, 1980. This is primarily used to convince the Visual C++ nmake program that any object files in its build directories are indeed younger than the creation date of the directory itself and need to be recompiled. Magic ScriptsMagic 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 OptionsTable 11-2 lists the options that deal with magic scripts on the Samba server. Table 11-2. Magic script options
magic scriptIf the magic script option is set to a filename and the client creates a file by that name in that share, Samba will run the file as soon as the user has opened and closed it. For example, let's assume that the following option was created in the share [accounting]: [accounting] magic script = tally.sh Samba continually monitors the files in that share. If one by the name of tally.sh is closed (after being opened) by a user, Samba will execute the contents of that file locally. The file will be passed to the shell to execute; it must therefore be a legal Unix shell script. This means that it must have newline characters as line endings instead of Windows CRLFs. In addition, you need to use the #! directive at the beginning of the file to indicate under which shell or interpreter the script should run, unless the script is for the default shell on your system. magic outputThis option specifies an output file to which the script specified by the magic script option will send output. You must specify a filename in a writable directory: [accounting] magic script = tally.sh magic output = /var/log/magicoutput If this option is omitted, the default output file is the name of the script (as stated in the magic script option) with the extension .out appended onto it. InternationalizationStarting 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 OptionsSamba 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
client code pageThe character sets on Windows platforms hark back to the original concept of a code page. These code pages are used by DOS and Windows clients to determine rules for mapping lowercase letters to uppercase letters. Samba can be instructed to use a variety of code pages through the use of the global client code page option to match the corresponding code page in use on the client. This option loads a code page definition file and can take the values specified in Table 11-4. Table 11-4. Valid code pages with Samba 2.0
You can set the client code page as follows: [global] client code page = 852 The default value of this option is 850, for MS-DOS Latin 1. You can use the make_smbcodepage tool that comes with Samba (by default in /usr/local/samba/bin ) to create your own SMB code pages, in the event that those listed earlier are not sufficient. character setThe 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
Normally, the character set option is disabled completely. coding systemThe 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
valid charsThe valid chars option can be used to add individual characters to a code page. You can use this option as follows: valid chars = Î valid chars = 0450:0420 0x0A20:0x0A00 valid chars = A:a Each character in the list specified should be separated by spaces. If there is a colon between two characters or a numerical equivalent, the data to the left of the colon is considered an uppercase character, while the data to the right is considered the lowercase character. You can represent characters both by literals (if you can type them) and by octal, hexadecimal, or decimal Unicode equivalents. If you use this option, it must be listed after the client code page to which you wish to add the character. Windows Messenger ServiceOne 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 systemTo 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 OptionSamba 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
message commandSamba's message command option defines the command that will run on the server when a Windows Messenger Service message arrives. The command will be executed as the guest account user. What to do with messages is questionable because most Samba hosts run as unattended servers. One solution is to mail the messages to root like this: [global] message command = /bin/mail -s "SMB Message From %f on %m" root <%s; rm %s Note the use of variables here. The %s variable will be replaced by the name of the file in which the message resides. This file should be deleted when the command is finished with it; otherwise, a buildup of message files will collect on the Samba server. In addition, the command must either exit quickly or fork its own process (using an & after the command); otherwise, the client might suspend and wait for notification that the command was sent successfully before continuing. In addition to the standard variables, Table 11-8 shows the three unique variables that you can use in a message command. Table 11-8. message command variables
Miscellaneous OptionsMany 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
deadtimeThis 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. dfree commandThis global option is used on systems that incorrectly determine the free space left on the disk. So far, the only confirmed system that needs this option set is Ultrix. There is no default value for this option, which means that Samba already knows how to compute the free disk space on its own and the results are considered reliable. You can override it as follows: [global] dfree command = /usr/local/bin/dfree This option should point to a script that returns the total disk space in a block and the number of available blocks. The Samba documentation recommends the following as a usable script: #!/bin/sh df $1 | tail -1 | awk '{print $2" "$4}' On System V machines, the following will work: #!/bin/sh /usr/bin/df $1 | tail -1 | awk '{print $3" "$5}' fstypeThis share-level option sets the type of filesystem that Samba reports when queried by the client. Three strings can be used as a value to this configuration option, as listed in Table 11-10. Table 11-10. Filesystem types
The default value for this option is NTFS, which represents a Windows NT filesystem. There probably isn't a need to specify any other type of filesystem. However, if you need to, you can override the default value per share as follows: [data] fstype = FAT keepaliveThis global option specifies the number of seconds that Samba waits between sending NetBIOS keepalive packets. These packets are used to ping a client to detect whether it is still alive and on the network. The default value for this option is 300 (5 minutes), which you can override as follows: [global] keepalive = 600 The value of 600 (10 minutes) is good for networks populated by reliable clients. If your network contains relatively unreliable clients, you might prefer to set keepalive to a lower value, such as 30. If keepalive is set to 0, no NetBIOS keepalive packets will be sent. See also the deadtime parameter. max disk sizeThis global option specifies an illusory limit, in megabytes, for each share that Samba is offering. It only affects how much disk space Samba reports the share as having and does not prevent more disk space from actually being available for use. You would typically set this option to prevent clients with older operating systems—or running buggy applications—from being confused by large disk spaces. For example, some older Windows applications become confused when they encounter a share larger than 1 gigabyte. To work around this problem, max disk size can be set as follows: [global] max disk size = 1000 The default value for this option is 0, which means there is no upper limit. max muxThis global option specifies the maximum number of concurrent SMB operations Samba allows. The default value for this option is 50. You can override it as follows: [global] max mux = 100 max open filesThis global option specifies the maximum number of open files that Samba should allow at any given time for all processes. This value must be equal to or less than the amount allowed by the operating system, which varies from system to system. The default value for this option is 10000. You can override it as follows: [global] max open files = 8000 max xmitThis global option sets the maximum size of packets that Samba exchanges with a client. In rare cases, setting a smaller maximum packet size can increase performance, especially with Windows for Workgroups. In Samba versions up to 2.2.5, the default value for this option is 65535. In 2.2.7 and later versions, the default was changed to 16644 to match the behavior of Windows 2000 and improve support for Windows NT 4.0. You can override the default as follows: [global] max xmit = 4096 nt pipe supportThis global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default: [global] nt pipe support = yes nt smb supportThis global option is used by developers to negotiate NT-specific SMB options with Windows NT/2000/XP clients. The Samba Team has discovered that slightly better performance comes from setting this value to no. However, as a user, you should probably not override the default: [global] nt smb support = yes ole locking compatibilityThis global option turns off Samba's internal byte-range locking manipulation in files, which gives compatibility with Object Linking and Embedding (OLE) applications that use high byte-range locks as a method of interprocess communication. The default value for this option is yes. If you trust your Unix locking mechanisms, you can override it as follows: [global] ole locking compatibility = no panic actionThis global option specifies a command to execute in the event that Samba encounters a fatal error when loading or running. There is no default value for this option. You can specify an action as follows: [global] panic action = /bin/csh -c 'xedit <<: "Samba has shutdown unexpectedly";:' set directoryThis Boolean share-level option allows Digital Pathworks clients to use the setdir command to change directories on the server. If you are not using the Digital Pathworks client, you should not need to alter this option. The default value for this option is no. You can override it per share as follows: [data] set directory = yes statusThis global option indicates whether Samba should log all active connections to a status file. This file is used only by the smbstatus command. If you have no intentions of using this command, you can set this option to no, which can result in a small increase of speed on the server. The default value for this option is yes. You can override it as follows: [global] status = no strict syncThis share-level option determines whether Samba honors all requests to perform a disk sync when requested to do so by a client. Many Windows clients request a disk sync when they are really just trying to flush data to their own open files. In this case, a disk sync is generally unnecessary on Unix due to its high reliability, and it mostly has the effect of substantially reducing the performance of the Samba host system. The default value for this option is no, which allows the superfluous disk sync requests to be ignored. You can override the default as follows: [data] strict sync = yes sync alwaysThis share-level option decides whether every write to disk should be followed by a disk synchronization before the write call returns control to the client. Even if the value of this option is no, clients can request a disk synchronization; see the earlier strict sync option. The default value for this option is no. You can override it per share as follows: [data] sync always = yes strip dotThis global option determines whether to remove the trailing dot from Unix filenames that are formatted with a dot at the end. The default value for this option is no. You can override it per share as follows: [global] strip dot = yes change notify timeoutThe change notify timeout global option emulates a Windows NT/2000 SMB feature called change notification. This allows a client to request that a Windows NT/2000 server periodically monitor a specific directory on a share for any changes. If changes occur, the server will notify the client. Samba performs this function for its clients at an interval that defaults to 1 minute (60 seconds). Performing these checks too often can slow down the server considerably; however, you can use this option to specify an alternate time that Samba should wait between performing checks: [global] change notify timeout = 30 TOC |
:: Command execute :: | |
--[ c99shell v. 1.0 pre-release build #16 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.0038 ]-- |