Non-UTF-8 Locale Support and Localization › Scalability Server Considerations

Scalability Server Considerations

The following list provides considerations of individual scalability server use cases:

• On a scalability server, when having a non-UTF-8 system and using Samba, it is vital that it is configured correctly (note that YaST2 in SuSE does not do this correctly). It is very important that the setting “unix charset” is set correctly (in the “global” section of smb.conf). A good value may be "iso8859–15" which works well on western locales. If you forget this setting, all the files are shown. However, if a directory name contains National Language Characters (NLCs), you are able to see it and go down into it, but you are not able to see any of the files that it contains. From the user perspective, the jobs will fail. After changing any such setting, make sure to reload Samba.
• By design, if a Linux scalability server is configured to use NFS and Samba, the agents will use Samba. On the scalability server, use the commands “sd_sscmd addshare” or “sd_sscmd removeshare” to set this up properly.
• Samba and NFS pose different problems when it comes to file and directory names. Samba has an internal mechanism that maps the file and directory names for us, if we tell Samba that we (as an agent) are using UTF-8 (or non UTF-8). The name mapping will be performed discretely. NFS, however, has no such mechanism, and this can cause problems when connecting for instance a non UTF-8 agent to a UTF-8 scalability server (or conversely) and trying to access file and directory names that contain NLCs. Unfortunately, there is no way around this (except to use Samba instead of NFS).
• On a scalability server, where Samba file share is used, it may be a good idea to set up the library access (sd_sscmd libraryaccess …) properly in order for access to the Samba file share to work for Linux agents using CIFS.

  This problem is related to the Samba security configuration setting. When the agents try to mount the share on the scalability server using CIFS, they only succeed in mounting it as guest user (which is the default when no library access has been provided), if the Samba scalability server is configured to use shared-level security.

  If however, the Samba scalability server is configured to use another security type, like user-level security, the mounting with CIFS as anonymous user will not work since it requires an explicit user, along with the correct password. Furthermore, the user must have been added to the Samba user file with the smbpasswd -a command.

  The reason to enforce the use of CIFS (mount -t cifs) if possible is that it handles NLCs in a much better way than the usual SMB (smbmount).

  We suggest that administrators configure their scalability servers as follows:

  • sd_sscmd libraryaccess …

    This sets up the credentials for software delivery that are used when sending jobs to agents.

  • smbpasswd -a …

    This sets up the credentials in Samba itself.

  • Open smb.conf using an editor and remove (or comment out) the line “guest ok = Yes” on the shares “sdlibrary” and “sdmsilib”. Also, for security reasons, the security setting (in the global section), should not be set to "share" (which is the default) but to “user” (or better) instead. Refer to the manl page of smb.conf for the exact meaning of all the Samba scalability server settings.
  • Reload Samba, as follows:

    /etc/init.d/smb reload

    The new settings are activated.

  Note: If this configuration step is not done, the jobs will likely function anyway since the fallback solution, the Internal NOS-less transport mechanism, steps in. Internal NOS-less may not be as efficient as using Internal NOS, but it will work.

  Linux systems that seem to work out-of-the-box include SuSE 9 ES; Linux systems that do not work out-of-the-box include RedHat 3 ES and RedHat 4 ES.