This section describes how to change the configuration settings that are displayed on the page in the Samba management plug-in for iManager (see Section 7.2.2, Viewing General Information about the Samba Server).
The workgroup name specifies the Windows workgroup that the Samba server either joins (if it exists) or creates (if the name is new). In OES 2, the default workgroup name is modified from TUX-NET (the default for SLES 10) to WORKGROUP.
When users browse the network from Windows workstations, they can typically see only the Windows workstations and servers in the same workgroup. Because WORKGROUP is the default workgroup name for all Windows 2000 and Windows XP workstations, the WORKGROUP workgroup can contain hundreds of workstations and servers, rendering it nearly unusable.
To change the workgroup name for your Samba server, use a text editor such as gedit or vi to open the /etc/samba/smb.conf file and locate the workgroup name setting in the [global] section:
[global]
workgroup=workgroup
Replace the value with a name for the workgroup that you want users to see when they browse in Network Neighborhood. For example, you could change the entry to read:
[global]
workgroup=wg001
After saving the smb.conf file, you must restart the Samba server for the change to take effect.
A SID is a security identifier that is used by Windows networking operations to identify an object. A unique SID is generated every time a Samba server with a new combination of machine name (hostname) and domain name (workgroup) is started. The format of a SID is as follows:
S-1-5-21-7623811015-3361044348-030300820
S means the string is a SID. 1 is the revision level. 5 is the identifier authority value. The remainder of the string is the domain or local computer identifier.
It should not be necessary to change the SID for an OES Samba server.
The NetBios name is the name that a Samba server is known and advertised as. When Samba is installed on an OES 2 server, Novell appends “-W” to the DNS hostname for this entry. This is necessary to prevent a conflict with the name of an NCP server on Linux, which uses the hostname. In addition, although NetBIOS uses a completely independent naming convention from DNS, using a NetBios name that corresponds to the DNS hostname makes administration easier.
You should not need to change the default NetBios name for your Samba server. However, if you entered a DNS hostname that is longer than 13 characters when you installed OES 2, the NetBios name is truncated and iManager won’t be able to find the associated server and group objects.
The NetBios name can be changed by editing the "netbios name =" entry in the [global] section of the /etc/samba/smb.conf file. After editing and saving the smb.conf file, you must restart the Samba server for the change to take effect.
You must also delete the Samba-related eDirectory objects and regenerate them by rerunning the Novell Samba configuration in YaST.
The LDAP suffix specifies the eDirectory context where the following Samba-related objects are created:
Samba domain object (hostname-W)
Default Samba group (hostname-W-SambaUserGroup)
Samba proxy user (servername-sambaProxy)
UNIX Configuration object
NOTE:The UNIX Workstation object that represents the Samba server is created as part of the LUM configuration and therefore can be located elsewhere in the tree.
The LDAP suffix is also the base context that Samba uses to search for User objects in eDirectory. A search from this context down through the tree must be able to find the Samba users. If the Base Context is set incorrectly, you see the “sambaDomain Object Error” message, because an eDirectory search cannot find the Samba user objects.
The default setting is specified during the OES installation as the . To change this setting, you must rerun the OES configuration in YaST. Doing so creates new Samba-related objects in the new context. To avoid confusion, you should delete the old Samba objects. Be sure to make all of your existing Samba users members of the new default Samba users group before you delete the old one. If you want to keep the same proxy user, make sure the proxy user has correct rights to the new base context.