Académique Documents
Professionnel Documents
Culture Documents
Samba is an open source software package often used with Linux distributions. Replacing
Windows file and print servers with Samba results in a more stable server environment and
reduces costs because no client licenses are needed. This paper describes considerations
and issues when migrating Microsoft Windows servers to Samba running on Linux. Simple
file serving function with Samba is relatively straightforward. However, duplicating some of the
more advanced function available on Windows servers can be difficult to set up or is simply
not supported with Samba. This paper describes file and print serving function from a
Windows point of view.
When Samba and Linux are running on IBM zSeries (mainframe) hardware, there are some
unique aspects of the solution which are described also. However, the majority of this paper
applies to Linux running on any hardware platform.
Browse lists grew out of peer-to-peer networking. They started as lists of computers and
resources created via network broadcasts and were thus restricted to the local LAN. To
address the issue of combining groups of browse lists, Microsoft introduced the Windows
In order to create and maintain browse lists, one computer in the local area network becomes
the master browser (sometimes called local master browser or browse master). This
computer maintains the list of all computers, domains and workgroups.
When Windows NT/2000 domains are used, there is also a domain master browser which is
the master browser for the domain. With just Windows servers in play, only an NT/2000/XP
domain controller can function as a domain master browser.
The process by which computers become browsers is via elections. This function is beyond
the scope of this paper, but to read more on it see the article Name Resolution and Browsing
in Samba, Parts 1 and 2, on the Web at:
http://www.onlamp.com/pub/a/onlamp/excerpt/samba_chap7/index.html
http://www.onlamp.com/pub/a/onlamp/excerpt/samba_chap7/index2.html
On PC servers, the most affordable disks, or “hard drives” are EIDE (Extended Integrated
Drive Electronics), while the more expensive and better performing disks are SCSI (Small
Computer System Interface). A server can support more SCSI disks than EIDE, the
throughput is faster for SCSI (typically a maximum of 160MB/s for SCSI vs. 66MB/s for EIDE),
and the SCSI protocol is more sophisticated than EIDE. SCSI disks have a higher reliability
and can be connected with longer cables (although the Serial ATA, SATA effort is trying to
change this). Still, EIDE disks can be relatively reliable and are the lowest cost option.
More sophisticated servers will use hardware RAID. Typically RAID-5 or RAID-6 is used which
will allow one or two disks to fail, without losing any data. After a disk fails, the array can be
rebuilt while still online. A RAID controller, additional software and firmware is needed to
maintain these systems. Each RAID array looks like a larger single physical disk to Windows.
Microsoft servers can also do RAID in software, but the performance of hardware RAID is
superior, so software RAID is not as common.
Two more sophisticated and modular storage systems are becoming popular. The two
systems are Storage Area Networks (SANs) and Network Attached Storage (NAS). Both
systems have the advantage of off-loading processor requirements from the server to the
specialized hardware.
Network Attached Storage (NAS) is hardware that has a concept similar to SANs however it
does not use a physically separate network. Rather, it uses the existing TCP/IP network and
assigns a TCP/IP address to each of the NAS devices. NAS hardware has a small operating
system running that is usually either Windows or Linux based. Generally they run well,
however upgrading the OS for possible security exposures can be an issue.
Any of these options can offer large disk sizes by today’s standards. 72GB, 144GB or larger
disks are not uncommon, and SANs are often measured in terabytes.
Once the drive is mapped, it appears to the user to be a local drive if adequate bandwidth is
available. With a small network bandwidth, drives can still be mapped, however, poor
performance can prevent the solution from being usable.
One of the main benefits of Dfs is location transparency. The users don't have to know the
final server that holds their files. File servers can be relocated without requiring the user to
reconfigure.
Additionally, fault tolerance is added when Active Directory is used in conjunction with Dfs. So
if there are Active Directory replicas, the users don’t even need to know the location of the Dfs
root.
By default, this function is not enabled, though it is easy to do. Any file, or more typically, any
folder that is normally accessed via the network can be enabled. When you are working
off-line, only those folders and files that are marked as off-line will appear.
To make a folder available offline, right click it and choose Make Available Offline. The folder
will synchronize, by copying it to the folder named offlineFolders in your profile.
When the network drive that contains the folder is not available, the folder will still be
available. If changes are made while it is being accessed offline, it will have to be
While this encrypts data between the operating system and the physical device, the data
does not appear encrypted to users who have the proper key. Therefore, EFS does not
address encryption over the network.
This built-in software addresses basic backup and restore needs. However, maintaining tape
libraries, which becomes necessary as the volume of data to be backed up increases, is not
included, so this is a basic backup and restore system by enterprise standards.
1.2.8 Quotas
Windows NT 4 added the ability to set quotas, for the amount of disk space a user was
allowed to use. A usability restriction is that quotas cannot be set on folders, rather, they must
be set up on volumes (or partitions) for all users. Therefore, all users sharing the same
volume must have the same quota.
Also on Windows NT it was agreed that quota management was difficult. Windows 2000
added simple quota management tools which made maintaining quotas more usable.
Windows servers can easily share printers. It should be noted that a “printer” in Windows
terminology is software. The physical printer itself is referred to as a “print device”.
For these reasons, print servers are usually used. It is easy to make a Windows server a print
server. Printers are simply added, with the additional step of adding drivers for download, and
the Windows server is a print server.
Alternatively, you can add a printer via the Add Printer Wizard from the Printers dialog.
When you add a printer directly, that is there is no print server in between, you will be
prompted for the printer drivers. They may exist on your Windows system or CD, or you may
provided them via various media. But using a print server enables you to bypass this step as
is described in the next section.
Figure 1-6 Windows XP automatic download of printer drivers slightly ominous question
Answering Yes to either question will add the printer without any further interaction. It should
then be immediately available for use.
Printer pools can be set up on Windows servers. This is done by checking the Printer
Pooling check box on the Ports tab of the Printer’s Properties dialog. Then select all ports for
all printers that will be in the pool.
A requirement for Windows servers is that all printers in the pool must be identical.
1.3.5 Accounting
A function that is often requested for print servers is keeping track of how many pages each
user has printed and making nice reports from the data. This function is often used to
“charge-back” users for print services. Windows servers do not have a print server accounting
function. This is an area where there are many vendor products available.
In a sense, there are very few time servers. Rather, most “time servers” are actually time
clients of another time server which is a reliable source. The most accurate time servers are
called stratum 1. When a client sets it’s clock against a certain stratum time server, the client
becomes a stratum n+1 client. It is common practice for a single server in an organization to
set its clock against a stratum 1 or 2 time server, thus becoming a stratum 2 or 3 time server.
Then many clients in the enterprise can set their clocks against this local time server.
The time of day clock can be set accurately on a Windows server using the w32tm DOS
command (try w32tm /?) and via the W32Time registry entries in:
HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
There are many considerations to this function as it pertains to Active Directory that are
beyond the scope of this paper. For more details see:
http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/security/wintimeserv.asp
When PCs and LANs were first moving into the enterprise, authentication was not a big issue
as a small number of trusted users were physically attached to the LAN. The concept of
workgroups were added, but this was more to address the size of browse lists than for
security. As TCP/IP became a worldwide networking standard, increased authentication and
authorization became a necessity. There have been two major progressions of the security
infrastructure on Windows operating systems - NT Domains and Active Directory.
Real security began with Windows NT and domains. Windows NT 4 has the concept of
Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). A domain could
only reasonable manage about 5000 users. Novell Directory Services (NDS), based on the
emerging Lightweight Directory Access Protocol (LDAP), was the first leader in directory
service software. NDS was considered superior to NT domains in terms of architecture
To catch up to Novell NDS, Microsoft came out with Active Directory in Windows 2000. Active
Directory still has domains, however they are different from NT domains. The Active Directory
namespace is hierarchical, with names separated by periods the same as DNS. An Active
Directory domain can manage 1,500,000 users or more.
1.5.1 NT Domains
When all of the users in an organization could fit into a single NT 4 PDC, the system was
usable, but when multiple domains were required for political or size reasons, NT domains
became more complex. Also, Windows NT 4 was prone to crashing. The fact that “BSOD”
became a recognized acronym for Blue Screen Of Death lends credence to this. The
instability of Windows NT hurt it as a central authentication and authorization solution. The
stability of Windows 2000 and Windows XP has increased.
To address these issues, Microsoft will be introducing a new version of Active Directory called
Active Directory Application Mode (ADAM) in Windows Server 2003 which is effectively an
LDAP-only version of Active Directory. See:
http://www.microsoft.com/windowsserver2003/techinfo/overview/adam.mspx
Active Directory has moved away from the basically flat namespace of NetBIOS and WINS,
and moved to the hierarchical, Internet standard, DNS. The concept of PDCs and BDCs was
removed in favor of Active Directory Domain Controllers (DCs) which can be trees and
forests.
Each Active Directory domain, one per DC, is a domain tree. Multiple Active Directory
domains can be joined to form a domain forest. The data for each domain tree on the domain
controller is read-write. A read-only copy of the domain forest called the global catalog can be
made available to each domain controller. With Windows 2000 and later, user logons, DNS,
Exchange e-mail and SQL Server directory data all must be stored in Active Directory if those
services are to be used.
When Active Directory is set up on Windows 2000, it must run in one of two modes:
Native Mode - only Windows 2000 (or later) Domain Controllers can participate in the
Active Directory tree
Mixed mode - Windows NT 4 PDCs and BDCs can also participate
DOS attributes
There are four DOS attributes which can be assigned to files and folders.
Read Only File cannot be written to
Archive File has been touched since the last backup
System File is used by the operating system
Hidden File is relatively invisible to the user
NTFS security
There are 13 basic permissions which are rolled up into six permission groups. These apply
only to the NTFS file system, not FAT nor FAT32. The six permission groups are:
Full Control Allow all 13 basic permissions
The 13 basic permissions are the following; some of them differ depending on whether they
apply to folders or files:
Traverse folders (for folders only)/Execute file (for files only)
List folder/Read data
Read attributes
Read extended attributes
Create files/Append data
Write attributes
Write extended attributes
Delete subfolders and files
Delete
Read permissions
Change permissions
Take ownership
To access the permission groups, right-click on any file or folder in Windows explorer, choose
the Properties menu item and then choose the Security tab as shown in Figure 1-8.
To see the 13 basic permissions, click the Advanced button at the bottom of the Security tab,
then click Effective Permissions.
Inherited permissions
With Windows 2000, files and folders can be set to inherit permissions. By default, all files
and directories in NTFS file systems have inherited permissions set. When a file or folder
inherits permissions from the directory it is in, the permissions attributes check boxes are
grayed out. You can remove the inherited permissions from a file or folder and will be
presented with the question shown in Figure 1-9, “Removing inherited permission bits” on
page 16.
When you remove the permission inheritance from a file or folder, you have to start with a new
set of specific permissions. You can start with none (by selecting Remove) or you can start
with the set which were previously inherited (by selecting Copy).
Group Policies enable desktop lockdown, rights management, roaming users and other
security-oriented features. Group policies are complex and encompass many aspects of
Windows management beyond the scope of this paper. Windows 2000 has about 400 group
policies and Windows XP has about 600. However, some of the more commonly used
function that are under the Group Policy umbrella are addressed in the next sections.
Windows NT did not have group policies, but had two system policy editors - one for NT
clients and one for Windows 95/98 clients. They performed similar function, but did so by
making registry changes on clients that added restrictions to the Windows Explorer user
interface. The policy editor did not have to run locally on each of the clients, rather, policy files
(CONFIG.POL for 9x clients and NTCONFIG.POL for NT clients) were put in the NETLOGON share
and when the clients did a network logon the policies were applied. Once these policies were
applied, they could not easily be removed, even by the Administrator on the local machine,
User profiles can consume a lot of network bandwidth to synchronize, so there may be
performance issues with logging on and off.
Logon scripts are files that get executed, usually batch (.bat) or command (.cmd) files,
immediately after a user logs on.
This feature is convenient for users who frequently log in from different computers. Think of
folder redirection as an extension to roaming user profiles. However, network and disk
resources can be comsumed quickly with folder redirection as more data is stored in these
folders.
There have been two main lines of Windows Operating systems. The 9x line usually refers to
Windows 95, Windows 98 and Windows Millennium Edition (ME). This is often shortened to
95/98/ME, or just 9x. This line died when Windows XP became available in 2002.
The NT line usually refers to Windows NT 4, 2000 and XP. Probably due to the instability of
the 9x line, Windows 2000was much more widely adopted in the enterprise.
There are some differences between the two lines addressed in the next two sections.
Additionally, non-Microsoft desktop operating systems are addressed.
Another difference is that network logons are different than with NT/2000/XP clients. Joining
these clients is different because the networking interfaces are different than on Windows
NT/2000/XP clients. The Windows 2000 server CD has an executable in the Clients directory
which installs the Directory Services for Windows. This allows older clients to “see” Active
Directory resources.
There are two Windows XP client operating systems: Professional and Home. The Home
version cannot join or access a domain-based network. Therefore only XP Professional
XP Professional has additional security protocols not present in any of the older Windows
operating systems - specifically the sign or seal function.
Linux
Linux desktops can mount SMB file systems with the mount -t smb command. While this is
not done in a pure Linux world, it can be done when the shared data resides on Windows or
Samba servers. For example, from a Linux machine, a share named data on a Windows 2000
server at IP address 9.117.73.54 can be mounted on Linux with the following command:
# mount -t smbfs -o username=mikem //9.117.73.54/data /mnt
...
Password: ********
# ls /mnt
foo.txt* newDocFromMyOffice.txt*
Samba version 3 (or simply Samba-3) will address many of the shortcomings of the current
Samba version 2. For more details, see 2.7, “Samba-3” on page 40.
When you are considering a Samba solution, you should follow two rules regarding Windows
clients:
Rule 1: Windows clients should not have to be modified in any way.
Rule 2: When changes are needed to Windows clients, see Rule 1.
The fact that Samba is running on the server should be transparent to the users. Samba
behaves like a Windows NT 4 file and print server, but cannot behave completely as a
Windows 2000 or XP server, especially with regards to Active Directory. Another area of
difference is that Samba does not support Kerberos authentication the way Active Directory
does (while Kerberos originated on UNIX, Microsoft has embraced and extended the
standard such that the Microsoft implementation is not compatible with UNIX/Linux).
Usually this file is in the /etc/samba/ directory, but sometimes it is found in /etc/ or
/usr/local/samba/lib/. The latter case exists when Samba is built from source code - the
default location for all Samba executables, configuration files and log files is under the
directory /usr/local/samba/.
Samba services are started, stopped and queried from the service scripts, in the directory
/etc/init.d/. In Red Hat 7.2 and SuSE SLES-7 there is a single script, smb, which starts
both Samba daemons, smbd and nmbd. The new daemon winbindd is only needed when using
it for authentication. It is probably for this reason that SuSE split out each Samba daemon into
its own service script in the latest distribution, SLES-8. Now there are three scripts nmb, smb
and winbind.
The chkconfig command is also supplied in SLES-8 and Red Hat 7.2 (SLES-7 includes a
chkconfig command that performs no operation). It is used to check and set whether a
process will start at boot time. For example, the following shows that nmb is not set up to start
at boot time, but this is changed by including the on parameter:
# chkconfig nmb
nmb off
# chkconfig nmb on
# chkconfig nmb
nmb on
In addition to the many types of system administration that Webmin can do, it also has a
Samba module, and thus allows Samba management through a browser. An interesting
feature of webmin is that communications can be encrypted with a secure socket layer while
swat cannot.
The browse list determines which computers and resources are seen in the Windows
Network Neighborhood or My Network Places.
zSeries specific: There is an issue with Samba servers running on zSeries not showing
up in the browse lists. Often the primary network interface is a point-to-point connection
such as virtual channel-to-channel (ctc) or IUCV. Even if a broadcast could be done on
these connections, it would only be to the other side, z/VM. Therefore the Samba server
will not show up in browse lists. There are a couple of workarounds to this - use an LCS or
OSA connection where broadcasting will work as expected, or, if WINS servers are in
place, point Samba to a WINS server with the “wins server = <server>” parameter.
An example of setting up basic file serving function is shown in 3.1, “Setting up basic file
serving” on page 43.
There are several volume management systems available for Linux today, notably:
Logical Volume Manager (LVM) - commonly used on SuSE distributions
RAID tools, sometimes called mdtools - commonly used on Red Hat distributions
Enterprise Volume Management System (EVMS) - a new system with multiple interfaces
and allowing “plug-ins” of other systems.
SLES-8 commonly uses LVM which has its own terminology that is briefly described here:
A hard drive or zSeries DASD volume is called a physical volume (PV), because that’s the
volume where the data is physically stored.
The PV is divided into several physical extents (PE) of the same size. The PEs are like
blocks on the PV.
Several PVs make up a volume group (VG), which becomes a pool of PEs available for the
logical volume (LV).
The LVs appear as normal devices in /dev/ directory. You can add or delete PVs to/from a
VG, and increase/decrease your LVs.
See Figure 2-2, “LVM block diagram” on page 24 for a conceptual view of these pieces.
23
Volume group - /dev/lvmdata
A scenario for setting up a striped logical volume is described in 3.2, “Setting up a logical
volume” on page 46.
zSeries specific: zSeries recently added support of the Fibre Channel Protocol (FCP).
This allows attachment of devices that support Fibre Channel, such as the Enterprise
Storage Server (ESS). See the redpaper Getting Started with zSeries Fibre Channel
Protocol on the Web at:
http://www.redbooks.ibm.com/abstracts/redp0205.html
One possible downsize to FCP disks is that z/OS cannot vary them online. Therefore, an
existing Disaster Recovery solution from z/OS to Linux cannot be used.
All of these have different attributes and probably all are now considered stable and
production ready. In SLES-8, Reiser and ext3 are the two built-in journalled file systems. The
ext3 file system may have a small advantage over Reiser in terms of recoverability under
extreme conditions, so it may be the best choice.
Other necessary attributes for a file system that Samba will utilize are POSIX ACLs and quota
support. Without these, NTFS ACLs and NTFS quotas, respectively, will not work for
Windows clients. In SuSE SLES-8, both ext3 and reiserfs support POSIX ACLs and quotas. If
the Linux distribution you are working with does not have POSIX ACLs and quota support,
you may have to rebuild the Linux kernel yourself. However, it is recommended to leave this
job to the Linux distributor and to get support.
Also for Samba to utilize ACLs and quotas, it must be built with the configure parameters,
--with-quotas and --with-acl-support. With SLES-8 these two features are compiled into
Samba. Again, it is recommended that the Linux distributor do this work for you.
One area of difference is with Access Control Lists (ACLs). The Windows NT File System
(NTFS) allows for individual attributes to be assigned to files and folders authorizing specific
users, groups or a combination of both. See 2.5.4, “Permissions and Access Control Lists” on
page 36 for details.
Samba can become a Dfs server by setting the global host msdfs parameter. A share
becomes a Dfs root via the share level msdfs root parameter. A Dfs root directory on Samba
hosts Dfs links in the form of symbolic links that point to other servers. See 3.11, “Setting up a
Dfs root on Samba” on page 70” for a scenario of setting up Samba as a Dfs root.
Similarly, Samba shares can be linked into a Dfs root on a Windows server.
25
A description of setting up an EFS is beyond the scope of this paper. For a good reference,
see Cryptographic Filesystems, Part One: Design and Implementation, by Ido Dubrawsky, on
the Web at:
http://securityfocus.com/printable/infocus/1673
The rsync package is not a true backup system, but it has many interesting attributes. If the
world of backup and restore can be divided into two halves - Disaster recovery and
incremental backup, rsync can address the incremental backup half while a more specific
system should be used for disaster recovery.
For an example of setting up rsync to do nightly backups of a Samba file system, see 3.10,
“Setting up rsync for backup” on page 69. For more details on rsync see:
http://rsync.samba.org/
From the Windows side, see the vendor solutions listed in 1.2.7, “Anti-virus software” on
page 8. From the Linux side, there is one open source package shipped with SuSE SLES-8. It
is samba-vscan and should be installed on your system:
# rpm -qa | grep vscan
samba-vscan-0.2.5d-58
2.2.8 Quotas
Samba’s quota function is still considered experimental as of version 2.2.8a, however, many
in the Samba community are using it, and it seems to work fine. Soft limits (resulting in
warnings) and hard limits (which enforce the quotas) can be set both on the disk space used
and on the number of files (inodes) by Linux user or group.
27
To enable Samba quotas, the majority of the work is done on Linux. It makes sense to use
user quotas with “personal” Samba shares ([homes] for example) and to use group quotas
with teams sharing files.
The quota and quotad services are not enabled when SLES-8 is installed, but turning them on
is fairly easy. Once quotas are enabled on Linux, there is nothing special that Samba has to
do to support them. For a scenario of setting up quotas on Linux and seeing them enforced
via Samba see 3.14, “Setting up quotas on Linux then Samba” on page 75.
It appears that CUPS is becoming the de-facto industry standard. One advantage that CUPS
seems to have over LPRng is that it supports the new IETF Internet Printing Protocol (IPP).
SuSE SLES-7 and SLES-8 come with CUPS installed and enabled. Red Hat switched from
LPRng to CUPS. This section was found in the eWeek article Red Hat Shows a More Limber
Linux by Jason Brooks:
“LPRng print spooler software is among the software left out of Limbo or otherwise slated
for removal from the next version of Red Hat Linux. LPRng has been scrapped in favor of
CUPS (Common Unix Printing System). We've had good experiences with CUPS, and the
preference for this single printing system should resolve confusion for users previously
presented with a choice between the two mutually exclusive packages.”
In addition to the CUPS open source software package, there is an vendor product, ESP Print
Pro, by Easy Software products that is a complete cross-platform printing system with over
3500 printer drivers for Linux and other UNIX operating systems. See:
http://www.easysw.com/printpro/
CUPS and Samba on SuSE SLES-8 offers most SMB printing function, but not the following:
Print pools (CUPS classes) - There appears to be some support in Samba 2.2.8a
combined with CUPS 1.1.19. These levels are not available currently in SLES-8, but may
be available in SLES-8 “SP2”, slated to be available in July 2003.
Banner or separator pages - Adding separator pages could be done from Linux with
CUPS, but could not be done from Windows clients. Details on the crux of the issue need
to be investigated.
CUPS can be manipulated via the Linux command line or via various GUIs. The most obvious
graphical interface is the CUPS daemon itself. It is a mini-Web server similar to the SWAT
architecture. It listens on well known IPP port 631:
In addition Webmin and YaST2 both have interfaces to CUPS. There is no replacement for
knowing the CUPS commands, configuration files and data files.
29
The following user commands related to CUPS are in /usr/bin/:
cups-config query various CUPS configuration values
cancel Cancel jobs
disable Symbolic link to accept
enable Symbolic link to accept
lp Print files
lpoptions Display or set printer options and defaults
lppasswd Add, change, or delete digest passwords
lpstat Print cups status information
lpq Show printer queue status
lpr Print files
lprm Cancel print jobs
For an example of using CUPS, see 3.6, “Setting up basic print serving with CUPS” on
page 60 for a basic CUPS setup scenario.
Setting up Samba
Once printers are defined to Linux, it is relatively easy to add them to Samba. The following
smb.conf parameters are important.
[global]
...
printcap name = CUPS
printing = CUPS
printer admin = @ntadmin
...
[printers]
comment = All Printers
path = /var/samba/printers
printable = yes
create mask = 0600
browseable = no
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin root
force group = ntadmin
create mask = 0664
directory mask = 0775
The printcap name and printing global parameters specify that CUPS is the print server.
The default values are for lpd. The printer admin global parameter specifies the list of users
that can administer printers via the MS-RPC interface.
The [printers] section is a special section analogous to the [homes] section for file serving.
While the [homes] section makes a share out of all user’s home directories, the presence of
the [printers] section in the smb.conf file causes all printers defined to the print server to be
shared.
The [print$] section is another special section used to store printer drivers. As described in
3.8, “Enable automatic downloading of printer drivers” on page 64, one of the appealing
features of Windows print servers is the ability to automatically download printer drivers.
Beneath the directory specified by the path = parameter, the following directories must exist
for each Windows client architecture that is to be supported:
W32X86 Windows NT/2000/XP x86
WIN40 Windows 95/98/ME
W32ALPHA Windows NT Alpha_AXP
All of these directories have been created on a SLES-8 distribution, though it is not common
to see the last three architectures used.
There is an issue regarding the proper initialization of the printers. After drivers (DLLs) are
uploaded to Samba no action takes place: Linux is not able to load a Windows DLL. So the
driver is not given the opportunity to initialize the PrinterDriverData keys. Because the
installation is not complete when a test page is printed, it fails. A workaround is to open the
printer properties from a Windows client and set the page orientation. This will always
initialize the driver. Then the page orientation can be changed back to the original value.
Setting up printer drivers can also be done on the Linux side. There is an executable named
cupsaddsmb that is part of the CUPS package. It exports printers to Samba for use with
Windows clients. There have been some quality concerns with this function, though it has
worked fine for many.
2.3.5 Accounting
CUPS accounting is rudimentary. CUPS does write to the file /var/log/cups/page_log, but
the value of the data will be dependent on the backend filter. The following was found on the
Internet at:
http://printing.kde.org/faq/cups.phtml
“CUPS passes nearly every job through the pstops filter; pstops does, amongst other
things, the page counting. Output of this filter then may be piped into other filters or even a
chain of filters (like "pstoraster --> rastertopcl") or sent to the printer directly (if it is a
PostScript printer).
In any case, this works for network, parallel, serial or USB printers the same. For pstops to
work, it needs DSC, Document Structuring Convention compliant PostScript (or
near-equivalent) as input. This way it calculates the pages during filtering on the print
server and writes info about every single page (what time, which user, which job-ID and
-name, which printer, how many copies of which pages of the document, how many
31
kilo-bytes?) into /var/log/cups/page_log. However, it is *not* giving correct results in the
following cases:
• the printer jams and maybe therefor throw away the job (real life experience with
real-life printers; or maybe throws away the job because of problems with the data
format)
• jobs printed as “raw” are always counted as size of 1 page (and maybe multiple
copies).
Therefore page accounting of CUPS is “only” an approximation (in many cases an
excellent + good one, in others a quite poor one).”
Setting the smb.conf parameter time server = yes will cause Samba to advertise itself as a
time server in the browse list through nmbd. Regardless of this setting, clients can still set their
time with the net time command.
For a scenario see 3.9, “Setting up Samba as a time server” on page 68.
This option is good for small teams, but is often not viable for large consolidations of Windows
servers. The user names and passwords are often already maintained on a domain controller,
be it NT 4 or Active Directory. As such, it would be necessary to maintain three sets of
4 share/error
nsswitch->winbind:
2
Is USER1 valid?
Windows NT/2K/XP
Domain controller 3
for DOMAIN1 yes/no
Figure 2-4 Authentication flow using password server parameter and winbind
As you can see, the password is not actually stored on Linux. If you are using the [homes]
section the user’s home directory is obtained from the /etc/passwd file. To automatically add
an entry to the /etc/passwd file, the add user script parameter in the smb.conf file is often
set to point to a script that will add an entry if it does not exist. Note that this happens before
authentication is attempted, so the combination of these settings allow for a “self managing
Samba”, in terms of users and passwords.
The password server = * parameter tells Samba to locate the Domain Controller that will be
doing the authentication. Often it is found by tying together the domain name specified in the
workgroup parameter and the IP address in the file /etc/samba/lmhosts.
Winbind requires modification to the Linux Name Service Switch (NSS) - a function that
allows easy modification of the type and number of authentication mechanisms. NSS is
normally configured by editing the file /etc/nsswitch.conf. Additionally, winbind can be used
to allow logins and other types of connections to be authenticated via the Pluggable
Authentication Module (PAM), via configuration files in the directory /etc/pam.d/. Details on
PAM are beyond the scope of this paper.
33
Authentication via a Samba PDC
Samba can be configured to run as an NT4 PDC. See 3.12, “Setting up a Samba PDC” on
page 71. Many IT shops use Samba as a PDC with success. When Samba is acting as an NT
4 PDC, Windows clients can do network logons and therefore can utilize some of the more
advanced Windows function such as startup scripts, roaming profiles and folder redirection.
There can be an issue with finding the Samba PDC. The following reference to XP clients is
on the Web at:
http://www.microsoft.com/windows2000/dns/tshoot/
“Microsoft Windows XP Professional-based and Microsoft Windows 2000-based
computers that are joining or operating in a Windows 2000 Active Directory domain search
for a domain controller using a process known as the Domain Controller Locator. This
process depends on locating certain DNS Resource Records (RRs) for domain controllers
in the Active Directory domain namespace.
Pointing domain members to the right DNS servers and ensuring that the DNS server
contains the necessary records are critical aspects of troubleshooting domain operations.”
Using an LDAP server is recommended because it is the most open solution. Any of the
following LDAP servers can being used. The first three are vendor products and include nice
administration tools. The last one is a free, open source package, but is perhaps lacking in
administration tools.
IBM Directory Server
Sun ONE - Open Network Environment (formerly iPlanet, Netscape Directory Server)
Novell eDirectory (formerly NDS) - has been ported from NetWare to Linux. This is a good
candidate for NetWare to Samba migrations
OpenLDAP - open source software standard with most Linux distributions
LDAP architecture can get very complex. Consider the architecture shown in Figure 2-5, “A
complex LDAP architecture” on page 35. Such architecture is beyond the scope of this paper.
However, relatively simple scenarios are described in 3.4, “Setting up OpenLDAP” on
page 52 and 3.5, “Setting up Samba to use OpenLDAP” on page 57.
Another option not described is to use the Perl module Net::LDAPapi rather than TCP/IP for
LDAP communications. It makes authentication much easier as you just need to set the
permissions on the UNIX domain socket therefore you don't need to store an LDAP
administrator password anywhere. It requires the Samba and LDAP servers to be on the
same machine.
2.5.1 NT Domains
Samba can act as an NT 4 PDC. See 3.12, “Setting up a Samba PDC” on page 71 for a
description of how to do this.
Samba can emulate a BDC. Though this is not commonly done, it is described in chapter 10
of the Samba HOWTO collection.
Samba servers that have winbind set up and point to Windows domain controllers for
authentication, can inherit the Windows server trusts via winbind (e.g. if there are two domain
controllers trusting each other, winbind pointing at either one can authenticate users in either
domain).
35
2.5.3 Active Directory
Samba2 can join a domain, but not as Samba can join an Active Directory domain as a
member server. It cannot participate in an Active Directory domain as a domain server - that
function will be available with Samba V3. For details see 2.7, “Samba-3” on page 40.
DOS attributes
Samba can map all of the four DOS attributes. Because the three Linux execute bits are not
specifically needed, the DOS attributes can be mapped to them. By default, the DOS read
only bit is always mapped via the user read and write permission bits. The DOS archive
attribute is mapped to the Linux user execute permission bit. The system and hidden
attributes are not mapped, but can be. DOS attribute mapping is controlled with the following
smb.conf parameters:
map archive Map DOS archive attribute to owner execute bit (default = Yes)
map system Map DOS system attribute to group execute bit (default = No)
map hidden Map DOS hidden attribute to other execute bit (default = No)
See Figure 2-6, “Mapping DOS attributes to Linux permission bits” on page 36 to understand
the mapping.
r w x r w x r w x
NTFS security
The function to allow Windows clients to use their native security settings dialog box was
added in Samba 2.0.4. At this time the default value for the smb.conf parameter nt acl
support was changed from false to true. In order to correctly implement ACLs, they must be
built into the Linux kernel and underlying file system. Even when they are built into a file
system, they are not implemented by default. They can be implemented by changing the
defaults keyword to acl (or adding ,acl to existing parameters) for each file system they are
to be used with in the /etc/fstab file.
Even when ACLs are implemented, there are the following limitations with respect to the
function of NTFS file systems and the Microsoft security model:
Samba cannot have multiple owners or groups
Samba does not allow the Take ownership function
Samba does not support all thirteen NT permissions
For example, consider a Samba setup using winbind to a Windows 2000 DC (domain name
KGNLCC). A new file foo has the following permissions on Linux:
# ls -l foo
-rw-r--r-- 1 KGNLCC+mikem KGNLCC+Domain Users 30 Jun 11 11:05 foo
To look at the permissions from a Windows client, map the drive, traverse to the file with
Windows Explorer and click the Security Tab. If you wanted to give the world full control, you
would select Everyone in the “Group or user names” section, click Full Control and then
choose Apply:
Figure 2-7 Setting permission bits from Windows to Linux via Samba
37
This will change the other (world) triplet to rwx:
# ls -l foo
-rw-r--rwx 1 KGNLCC+mikem KGNLCC+Domain Users 30 Jun 11 11:05 foo*
Samba supports:
Roaming profiles and folder redirection
Logon scripts
NT 4 System policies
Samba-3 will support many more group policies. See 2.7, “Samba-3” on page 40.
The logon path parameter specifies where the roaming profiles are to be kept for Windows
NT/2000/XP clients. The logon home parameter is used with the net use /home DOS
command.
The [netlogon] section is administrative tool used primarily for globally updating client
machines with items like registry patches, anti-virus updates, program updates, etc. Anything
you want to “push” out to the client, can be done via netlogon. In addition, you can use the
share to enforce a system policy on a client or clients or perhaps backup a select group of
files every time the user logs on. Any time a user logs onto the PDC and the logon script =
option and [netlogon] share are present, Samba goes to the indicated path and executes the
file referenced by logon script.
A mandatory profile can be created on Windows and moved to Linux. Users do not have the
ability to modify these settings. For Windows NT/2000/XP clients, renaming the profile from
NTUser.DAT to NTUser.MAN makes it mandatory. For Windows 95/98/ME clients, renaming the
profile from User.DAT to USER.MAN makes it a mandatory profile.
When Samba is acting as a PDC, the [netlogon] share must be present for Windows
95/98/ME clients to do network logons.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
However, this violates Rule 1(see Section 2., “Equivalent Samba function” on page 21)
39
2.6.3 Other clients
Linux
On Linux there is an smbclient command which is ftp-like command to interact with an SMB
server, and there is the ability to mount SMB shares via the mount -t smb command. In
general SMB is not the recommended protocol for file sharing, but it can be convenient in an
environment with heterogeneous client operating systems.
2.7 Samba-3
Samba version 3 will add much new function. Following is an overview:
Active Directory Services support. Samba-3 is able to join an Active Directory realm as a
member server and authenticate users using LDAP/kerberos. It cannot be an Active
Directory forest or tree.
UNICODE and multi-byte character set support
Full NT4 PDC support - will include two SAM solutions that will store the extended security
information needed to implement a true replacement for MS Windows NT
– tdbsam - stores all information stored in the smbpasswd file plus the extended Windows
NT/2000/XP SAM information. It is recommended for sites with fewer than 250 users
– ldapsam - works with OpenLDAP and the new Samba schema format.
Better printing support including publishing printer attributes in Active Directory
New net command modelled after the DOS command
NT 4 style domain trust relationships
Ability to map Windows groups to Linux groups using the net groupmap command.
Net RPC vampire - will be able to obtain NT4 SAM accounts into it's own tdbsam or into an
ldapsam database. Here are some scripts to get an idea of how it can be used:
vampire.sh
#!/bin/bash
smbpasswd -a root
/etc/samba/initGrps.sh
net getsid -S pdcmachine -w sargon -U Administrator%secret
net rpc join -S pdcmachine -w sargon -U Administrator%secret
net rpc vampire -S pdcmachine -U Administrator%secret
pdbedit -l
smbgroupedit -v
initGrps.sh
#!/bin/bash
net getlocalsid SARGON > /tmp/food
domsid=`cat /tmp/food | grep SID | cut -d: -f2`
echo $domsid
smbgroupedit -c $domsid-512 -u ntadmin
smbgroupedit -c $domsid-513 -u users
smbgroupedit -c $domsid-514 -u nobody
smbgroupedit -c S-1-5-32-544 -u root
smbgroupedit -c S-1-5-32-545 -u users
smbgroupedit -c S-1-5-32-546 -u nobody
smbgroupedit -c S-1-5-32-547 -u root
smbgroupedit -c S-1-5-32-548 -u sys
41
42 Migrating Windows servers to Samba
Section 3. Samba scenarios
This section goes into detail by describing various scenarios that set up and implement many
different Samba functions.
All of the examples were done on a Linux SuSE SLES-8 distribution running under z/VM on a
zSeries z900 (2064). You should be able to recreate the following scenarios:
Section 3.1, “Setting up basic file serving” on page 43
Section 3.2, “Setting up a logical volume” on page 46
Section 3.3, “Setting up winbind to use DCs for authentication” on page 50
Section 3.4, “Setting up OpenLDAP” on page 52
Section 3.5, “Setting up Samba to use OpenLDAP” on page 57 (builds on previous
scenarios)
Section 3.6, “Setting up basic print serving with CUPS” on page 60
Section 3.7, “Setting up Samba to use CUPS” on page 63 (builds on previous scenario)
Section 3.8, “Enable automatic downloading of printer drivers” on page 64 (builds on
previous two scenarios)
Section 3.9, “Setting up Samba as a time server” on page 68
Section 3.10, “Setting up rsync for backup” on page 69
Section 3.11, “Setting up a Dfs root on Samba” on page 70
Section 3.12, “Setting up a Samba PDC” on page 71
Section 3.13, “Setting up roaming profiles” on page 75 (builds on previous scenario)
Section 3.14, “Setting up quotas on Linux then Samba” on page 75
Section 3.15, “Setting up a z/VM VDISK swap space” on page 78
Section 3.16, “Complete enterprise scenario” on page 78
In the default /etc/inetd.conf file with SLES-8, all lines are comments. Uncomment the swat
line and start inetd:
# vi inetd.conf # uncomment the swat line:
# swat is the Samba Web Administration Tool
swat stream tcp nowait.400 root /usr/sbin/swat swat
# rcinetd start
Starting inetd done
You will be prompted for a user ID and password. Use root and the root password. Figure
2-1, “SWAT screen shot” on page 22 shows an example.
The passwd command creates a UNIX hash in the /etc/shadow file. To use Samba an “NT
hash” is needed in the /etc/samba/smbpasswd file which is maintained with the command of
the same name, smbpasswd:
# cd /etc/samba
# cat smbpasswd
# This file is the authentication source for samba. You add password
# information with the smbpasswd or smbadduser command.
#
# Cf. section 'encrypt passwords' in the manual page of smb.conf for
# more information.
# smbpasswd -a mikem
New SMB password:
Retype new SMB password:
Added user mikem.
# cat smbpasswd
# This file is the authentication source for samba. You add password
# information with the smbpasswd or smbadduser command.
#
# Cf. section 'encrypt passwords' in the manual page of smb.conf for
# more information.
mikem:500:F3265269D0AC8A0E944E2DF489A880E4:DF43D568E4C68049E43A6B09EBB041A6:[UX
]:LCT-3EA7D25B:
You should now have your user ID and password synchronized in three places:
Start Samba
On past distributions “Samba” was started from a single script /etc/init.d/smb. With
SLES-8, SuSE has split out the nmbd and smbd deamons to two scripts nmb and smb, and a
third script winbind, if necessary. Verify that Samba is not running and then start it:
# rcnmb status
Checking for Samba classic NMB daemon unused
# rcsmb status
Checking for Samba classic SMB daemon unused
# rcnmb start
Starting Samba classic NMB daemon done
# rcsmb start
Starting Samba classic SMB daemon done
45
3.2 Setting up a logical volume
zSeries specific: Many of the commands and files are zSeries specific in this scenario.
Linux running as a guest under z/VM is assumed.
The Logical Volume Manger (LVM) allows you to make large volumes out of smaller 3390-3s.
This scenario shows how an 11.5GB volume is made from five 3390-3s. The first two steps of
this scenario assumes Linux running under z/VM which uses the USER DIRECT file to
maintain user IDs. The overall steps for setting up a logical volume are as follows:
Get DASD defined to the VM user ID
Add the DASD in Linux
Format and partition each DASD
Initialize LVM then create and verify physical volumes
Create the volume group and verify
Create a striped logical volume using most of the volume group
Create a journalled file system and mount the logical volume
Make a Samba share of the directory
Set the LVM to come up at IPL (boot) time
With this script, the DASD added dynamically. The new DASD are assigned sequentially from
/dev/dasdc to /dev/dasdg:
# dasd add 200-204
# dasd list
0100(ECKD) at ( 94: 0) is dasda : active at blksz: 4096, 2347 MB
0101(ECKD) at ( 94: 4) is dasdb : active at blksz: 4096, 70 MB
0200(ECKD) at ( 94: 8) is dasdc : active n/f
0201(ECKD) at ( 94: 12) is dasdd : active n/f
0202(ECKD) at ( 94: 16) is dasde : active n/f
0203(ECKD) at ( 94: 20) is dasdf : active n/f
0204(ECKD) at ( 94: 24) is dasdg : active n/f
Create physical volumes for each DASD with the pvcreate command. The shell regular
expression /dev/dasd[cdefg]1 can be used as a shortcut to address all five DASD:
# pvcreate /dev/dasd[cdefg]1
pvcreate -- physical volume "dasdc1" successfully created
pvcreate -- physical volume "dasdd1" successfully created
47
pvcreate -- physical volume "dasde1" successfully created
pvcreate -- physical volume "dasdf1" successfully created
pvcreate -- physical volume "dasdg1" successfully created
If you need a logical volume greater than 256GB, you need to raise the default PE size of
4MB.
Now the DASD at addresses 200-204 will be recognized at boot time and assigned to the files
/dev/dasdc to /dev/dasdg. Modify the /etc/fstab file to mount the logical volume over the
directory /data at boot time:
# cp fstab fstab.orig
# vi /etc/fstab # and add a line
# cat /etc/fstab
/dev/dasda1 / reiserfs defaults 1 1
/dev/datavg/lv1 /data reiserfs acl 0 2
/dev/dasdb1 swap swap pri=42 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
49
Test a reboot with the shutdown command. The logical volume reiser file system should come
up mounted over the directory /data/.
# shutdown -r now
More details on LVM can be found on the SuSE Web site in the paper LVM - Logical Volume
Manager at:
http://www.suse.de/us/whitepapers/lvm/
Make a back up copy of the smb.conf file and modify the following parameters:
# cd /etc/samba
# cp smb.conf smb.conf.orig
# vi smb.conf --> make the following changes:
workgroup = POKLCC // the NT/AD domain name
netbios name = PBC99241 // the Linux DNS name (by convention)
security = DOMAIN
encrypt passwords = Yes
password server = *
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind separator = +
Create an lmhosts file that associates the Windows 2000 server name (LCCWIN2K) and domain
name (POKLCC) with its IP address.
# cd /etc/samba
# vi lmhosts --> add two lines
9.117.73.54 LCCWIN2K
9.117.73.54 POKLCC
Backup and modify the /etc/nsswitch.conf file to use the shared library.
# cd /etc
# cp nsswitch.conf nsswitch.conf.orig
# vi nsswitch.conf --> and add "winbind" to the passwd and group lines:
passwd: files winbind
group: files winbind
There has to be a machine (computer) trust created on the Windows server to allow the
Samba server to join the domain. You can also create one on the fly with the -U
administrator parameter to the smbpasswd command, but you must have the administrator
password.
Join the POKLCC domain via the smbpasswd command with the -j and -r flags. Watch for the
message “Joined domain POKLCC” (it is important to get this message. If you cannot join the
domain, the computer may need to be reset on the Windows 2000 server)
# smbpasswd -j POKLCC -r LCCWIN2K
2002/07/30 09:55:56 : change_trust_account_password: Changed password for domain POKLCC.
Joined domain POKLCC.
List the users and groups in the POKLCC domain with the command wbinfo:
# wbinfo -u
POKLCC+Administrator
POKLCC+Guest
...
# wbinfo -g
POKLCC+Domain Admins
POKLCC+Domain Users
...
Verify your trust with the Windows using the command wbinfo -t.
# wbinfo -t
Secret is good
Winbind should now be working. You should be able to get a file share using the credentials of
a user in the domain POKLCC.
51
3.4 Setting up OpenLDAP
This scenario shows how to do authentication with OpenLDAP that comes built in SuSE
SLES-8. Integrating Samba with OpenLDAP is discussed in “Authentication via an LDAP
server” on page 34 The overall steps are:
Configure OpenLDAP
Start OpenLDAP
Create a Directory Information Tree (DIT)
View the DIT via an LDAP browser
Configure PAM to use LDAP for login and ssh
Configure NSS to use LDAP
Set up some LDAP wrapper scripts
Use some LDAP client GUI tools to view the LDAP data
Configure the OpenLDAP server configuration file. First the file is backed up and (optionally)
comments are removed via the egrep command:
# cd /etc/openldap
# cp slapd.conf slapd.conf.orig
# egrep -v '^$|^#' slapd.conf.orig > slapd.conf
# vi slapd.conf --> add schemas, set suffix, rootdn and rootpw
# cat slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
database bdb
suffix "dc=poklcc,dc=ibm,dc=com"
rootdn "cn=Manager,dc=poklcc,dc=ibm,dc=com"
rootpw linux123
directory /var/lib/ldap
index objectClass eq
Start OpenLDAP
Start the OpenLDAP service. Note the files that get created in the directory /var/lib/ldap/:
# rcldap status
Checking for service ldap: unused
# ls /var/lib/ldap
# rcldap start
Starting ldap-server done
# ls /var/lib/ldap
__db.001 __db.003 __db.005 id2entry.bdb
__db.002 __db.004 dn2id.bdb log.0000000001
dn: ou=People,dc=poklcc,dc=ibm,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
dn: ou=Group,dc=poklcc,dc=ibm,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
dn: ou=Users,dc=poklcc,dc=ibm,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
dn: uid=ldapuser1,ou=People,dc=poklcc,dc=ibm,dc=com
uid: ldapuser1
cn: ldapuser1
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 100
homeDirectory: /home/ldapuser1
53
# ldapadd -x -h localhost -D "cn=Manager,dc=poklcc,dc=ibm,dc=com" -f initial.ldif -W
Enter LDAP Password:
adding new entry "dc=poklcc,dc=ibm,dc=com"
# numResponses: 7
# numEntries: 6
Look at the entries via the GUI LDAP browser named gq:
If you have a Windows desktop, start an X server (e.g Hummingbird eXceed).
Set the DISPLAY environment variable and start gq which comes standard with SLES-8.
# export DISPLAY=<your.IP.address>:0
# gq &
Enable telnet:
# cd /etc
# vi inetd.conf --> uncomment the telnet line
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
# rcinetd restart
Shutting down inetd done
Starting inetd done
Configure PAM so both local and LDAP users can telnet in:
# cd /etc/pam.d
# cp login login.orig
# vi login --> make the following changes
# cat login
#%PAM-1.0
auth required pam_securetty.so
auth required pam_nologin.so
auth required pam_env.so
auth required pam_mail.so
auth sufficient pam_ldap.so
auth required pam_unix2.so nullok use_first_pass
account required pam_unix2.so
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
session required pam_unix2.so none # debug or trace
session required pam_limits.so
55
Before proceeding, test telnet to local users with no password, bad password and good
password. Then test telnet to LDAP users with no password, bad password and good
password.
Configure PAM so both local and LDAP users can ssh in:
# cp sshd sshd.orig
# vi sshd --> make similar changes
# cat sshd
#%PAM-1.0
auth required pam_nologin.so
auth required pam_env.so
auth sufficient pam_ldap.so
auth required pam_unix2.so nullok use_first_pass
account required pam_unix2.so
account required pam_nologin.so
password required pam_pwcheck.so
password required pam_unix2.so use_first_pass use_authtok
session required pam_unix2.so none # trace or debug
session required pam_limits.so
Test ssh local users with no password, bad password and good password and then LDAP
users with no password, bad password and good password.
Use the id command to query the one LDAP user that was added:
# id ldapuser1
uid=1000(ldapuser1) gid=100(users) groups=100(users)
# ldapsearch -x uid=ldapuser1
...
userPassword:: e1NNRDV9QTJrbVg0NC9xaVdDUWp4RVdlVGVWdTVJZnJFPQ==
...
Restart LDAP:
# rcldap restart
Shutting down ldap-server done
Starting ldap-server done
57
SAMBA_SAM="ldap"
The next two lines will change depending on whether you are using TLS security or not. If you
are not using TLS, use the lines:
ldap port = 389
ldap ssl = no
Stop the two Samba daemons if they are running and restart them:
# rcnmb status
Checking for Samba classic NMB daemon running
# rcsmb status
Checking for Samba classic SMB daemon running
# rcsmb stop
Shutting down Samba classic SMB daemon done
# rcnmb stop
Shutting down Samba classic NMB daemon done
# rcnmb start
Starting Samba ldap NMB daemon done
# rcsmb start
Starting Samba ldap SMB daemon done
Using the smbpasswd command to create new users. Because the LDAP libraries are being
used, the smbpasswd command sets the passwords in LDAP, not in the smbpasswd file.
Add two Samba users, smbuser1 and smbuser2 with the useradd command and create home
directories (Note: to automate this, the global add user script parameter can be set in the
smb.conf file and pointed to a script to add the user):
# useradd smbuser1
Get a share from a Windows desktop. You can use the Connect using a Different User
Name dialog as shown in to specify the smbuser1 user.
59
Figure 3-2 Mapping a drive and Connect using a different user name
By default, CUPS is not started with the system. Set it to start at boot time with the chkconfig
command:
# chkconfig cups
cups off
# chkconfig cups on
# chkconfig cups
If you want to be able to access the CUPS Web server from any client, comment out the Deny
From All lines. If you want better security, just allow those hosts from which you will be
accessing the CUPS Web server:
# vi cupsd.conf -->> comment out the “Deny from all” lines
# cat cupsd.conf
DocumentRoot /usr/share/cups/doc/
LogLevel info
Port 631
<Location />
Order Deny,Allow
#Deny From All
Allow From 127.0.0.1
Allow From 127.0.0.2
</Location>
<Location /admin>
AuthType Basic
AuthClass System
Order Deny,Allow
#Deny From All
Allow From 127.0.0.1
</Location>
Start CUPS:
# rccups status
Checking for cupsd: unused
# rccups start
Starting cupsd done
# rccups status
Checking for cupsd: running
This example will use the CUPS commands. To add a printer, the lpadmin command is used.
Before you do this, you need the following information:
The printer’s TCP/IP address
The LPD queue name
The Printer PostScript Definition (PPD) file under the directory /usr/share/cups/model
The TCP/IP address can be obtained from the printer itself or from an administrator. The LPD
queue name can often be obtained from the printer’s documentation. In this example the
queue name for an IBM InfoPrint 40 printer is PASS which was obtained from the manual
61
Ethernet and Token Ring Configuration Guide for the InfoPrint 40. This manual was found on
the IBM printing Web site:
http://www.printers.ibm.com/
The PPD file was also found on the IBM printing Web site after the driver package was
downloaded and unzipped to disk. Before invoking the lpadmin command, the PPD file was
copied and then compressed:
# cp IBM43322.PPD /usr/share/cups/model/IBM
# gzip /usr/share/cups/model/IBM/IBM43322.PPD
The file /etc/cups/ppds.dat must be rebuilt to pick up the new PPD file. This can be done by
simply restart cups:
# rccups restart
Shutting down cupsd done
Starting cupsd done
After the command completes, the /etc/cups/printers.conf file should be modified and a
PPD file should be created in the directory /etc/cups/ppd:
# cat printers.conf
# Printer configuration file for CUPS v1.1.15
# Written by cupsd on Wed Apr 23 12:49:41 2003
<DefaultPrinter f58bydoor>
Info f58bydoor
DeviceURI lpd://9.56.41.237
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>
# ls /etc/cups/ppd
In this scenario, the PPD file was not created, so even though the printer was added, it will not
have the proper attributes because it will not have a PPD file (this could be considered a bug
that lpadmin does not report not copying a PPD file).
The problem was that CUPS was not restarted and thus the existence of the PPD file was not
added to the small database in the file /etc/cups/ppds.dat. Note the file grows after CUPS is
restarted:
# wc ppds.dat
38 8698 1140784 ppds.dat
# rccups restart
Shutting down cupsd done
Starting cupsd done
Deleted the printer with the lpadmin -x flag and add it back again:
# lpadmin -x f58bydoor
# lpq
no entries
# lpadmin -p f58bydoor -E -v lpd://9.56.41.237 -m IBM/IBM43322.PPD.gz
# lpq
f58bydoor is ready
no entries
Again check that the PPD file was added to the ppd/ directory:
# ls /etc/cups/ppd
f58bydoor.ppd
This time it has been added. Note the file name corresponds to the printer name because
each printer requires a PPD file to be associated with it.
Add a cover sheet attribute. This will cause a cover sheet to be printed at the start of your
print job:
# lpadmin -p pok72far -o job-sheets-default=standard
If you are having problems with CUPS, the following command monitors the CUPS error log:
# tail --follow /var/log/cups/error_log
Now your printer should be set up on Linux. Print a file from Linux and verify it is working.
So by default, printing with CUPS is set up on SLES-8. All printers defined to CUPS should
now be visible as resources through Samba. Type \\<your.server.IP.address> in a
Windows Explorer dialog and click on Printers.
63
# rcsmb start
Samba SMB: Waiting for cupsd to get ready done
Starting Samba classic SMB daemon done
It is possible to set up the printer drivers from the Linux side. However, the scenario illustrates
how to set up the drivers on Linux/Samba from the Windows side as this may have a better
chance of getting the drivers set up correctly. Start by finding the resources that your Samba
server has made available. Choose Printers.
Choose Printers
Assuming you have the special [printers] section, all printers defined in CUPS should be
seen. Right-click the printer that you want to make drivers available for. Windows should
detect that there are no drivers available for it. If you choose Yes to the question “Do you want
install the driver now?”, the drivers will be installed on the local client. By choosing No, you
start the Add Printer Driver Wizard.
Choose No
Choose Have Disk which will give you a file chooser so you can select the printer drivers
Windows will be looking for a .inf file with the printer model information.
65
.inf file - file name will vary
When you supply the correct .inf file, you should get a choice of your printer model(s).
Respecify NTPRINT.INF
When you select the printer model, you may get a complaint about a digital signature not
being found. Select Yes. You should see the drivers being uploaded to the Linux server.
Now from any Windows client, you should be able to select the Linux/CUPS/Samba printer
and get the following dialog. Choosing Yes to the question “Do you want Windows to set up
the printer and continue this operation?” starts the process of automatically downloading
printer drivers.
67
3.9 Setting up Samba as a time server
The Network Time Protocol (NTP) is commonly used to set the software clocks of operating
systems very accurately. To be a time server, you only must set your clock accurately. When
your server sets its time against a stratum 1 or stratum 2 time server, your server can become
a stratum 2 or stratum 3 time server for clients. You will need access to the Internet on the
well-known ntp port 123 to set the software clock. The SMB protocol allows clients to set the
time, via the net time command, against an SMB server, such as Linux running Samba.
Choose two stratum 1 or stratum 2 time servers near you. For reference, see:
http://www.eecis.udel.edu/~mills/ntp/clock1a.html
Back up the original NTP configuration file, /etc/ntp.conf, then set up a new one with two of
the time servers. For example:
# mv ntp.conf ntp.conf.orig
# vi ntp.conf --> add the following lines
cat ntp.conf
server clock.llnl.gov
server tock.usno.navy.mil
driftfile /etc/ntp.drift # path for drift file
logfile /var/log/ntp # alternate log file
Wait at least 64 seconds and check that your system is talking to the time servers with the
ntpq command, peers subcommand:
# ntpq
ntpq> peers
remote refid st t when poll delay offset jitter
======================================================================
*ntp1.usno.navy. .USNO. 1 u 36 64 21.098 -4.321 2.270
+clock.via.net .GPS. 1 u 32 64 79.086 -5.215 0.785
+dns.cit.cornell ntp0.usno.navy. 2 u 43 64 19.957 -7.438 1.823
ntpq> q
A * in the first column indicates the time server that is being used
a + indicates a good fall-back connection.
You should always have one *, and one or two + entries. Check the state of your new time
server:
# ntptrace localhost
localhost: stratum 2, offset 0.000040, synch distance 0.02551
Now your server’s software clock should be very accurate. If Samba is running, Windows
clients can set their time via the net time command. This command can be put in a startup
script or can be run from a DOS prompt:
C:\>net time \\9.12.9.5 /set /yes
Current time at \\9.12.9.5 is 4/28/2003 2:07 PM
Additionally, Samba can advertise itself as a time server in browse lists via the time server =
Yes parameter in the smb.conf file.
[zntc]
path = /zntc/
comment = zNTC Linux team shared files
auth users = mikem
secrets file = /etc/rsyncd.secrets
# cat rsyncd.secrets
# user:passwd
mikem:secret
69
Every night the Samba share will be backed up. Only the changes made each day are moved
across the network and even those are compressed. This solution is especially useful
because an exact copy of the previous day’s file system is accessible. If you accidentally
delete or corrupt a file, you can ssh or ftp over to the backup server and restore the file.
Start Samba
Samba is started again with the rc scripts.
# rcnmb start
Starting Samba classic NMB daemon done
# rcsmb start
Samba SMB: Waiting for cupsd to get ready done
Starting Samba classic SMB daemon done
When winbind is authenticating to a native mode AD DC, it does not see new users
correctly. The following was appended to the Samba mailing list by a Samba team
developer in June 2003:
“Winbind in 2.2 doesn't obtain the sequence number in a native mode AD domain
correctly. You must use an LDAP query to get the date. See the --with-*-ldap-hack in
the configure options to enable the LDAP lookup (or wait for 3.0).”
71
zSeries specific: This scenario does not appear to work with a clean SLES-8 build which
has a Samba RPM of samba-2.2.5-60. Trying to change the client’s domain fails with the
error “A domain controller for the domain SMBLCC could not be contacted”.
Upgrading to samba-2.2.5-78 seems to be required, as the error is not encountered. To
upgrade, the SLES-8 SP2 CD was mounted:
# rpm -qa | grep samba
samba-client-2.2.5-60
samba-2.2.5-60
# mount 9.117.99.3:/mnt/sles8sp2cd1 /mnt
# cd /mnt/suse/s390
# rpm -Uvh samba-2.2.5-78.s390.rpm
samba ##################################################
The new domain will be named SMBLCC as specified in the workgroup parameter. The
netbios name is the name of the server in the browse list. The domain logons = Yes
parameter is the key to Samba acting as a PDC. It tells Samba to answer network logon
requests. Setting the oslevel = 64, preferred master = True and domain master = true
parameters ensure that Samba will become the domain master browser.
The [netlogon] section is a special section that creates a netlogon share. This is a share that
Windows 95/98/ME clients must see in order to do a network logon.
Start Samba
Start Samba with the rcnmb and rcsmb commands:
# rcnmb start
Starting Samba classic NMB daemon done
# rcsmb start
Starting Samba classic SMB daemon done
Machine trust accounts must be added for each client. This is known as a Computer Account
on NT. This can be done manually or automatically.
Create a Samba password for the user with the smbpasswd -a command:
# smbpasswd -a mikem
New SMB password:
Retype new SMB password:
Added user mikem.
You will probably want to write a more sophisticated script, but this one has the basics. Before
adding the trusts, the Samba user root user must exist in the smbpasswd file. Add the Samba
user root via the smbpasswd -a command:
# smbpasswd -a root
New SMB password:
Retype new SMB password:
Added user root.
If the Samba system administrator will be adding each client, the real root password can be
used. However, the step of joining the domain might be delegated to individual users or to
another administrator, in which case a different root password should be used.
If neither of these options are available, the LMHOSTS file can be used. The LMHOSTS file
maps IP addresses to NetBIOS names, and also allows for a domain name. The LMHOSTS
file is in the directory C:\WINNT\System32\drivers\etc on Windows NT and 2000, or in
C:\WINDOW\system32\drivers\etc on Windows XP.
C:\>cd WINDOWS\system32\drivers\etc
C:\WINDOWS\system32\drivers\etc>type lmhosts
9.12.9.5 linux4 #PRE #DOM:smblcc
The first time you join the domain, you have to specify a user ID with permission to let you
join. Use root with the password in the smbpasswd file set earlier. To change the domain, open
the Control Panel, open System then select the Network Identification (on Windows 2000)
73
or the Computer Name (on Windows XP) tab. Then select the Change button and type in the
name of the domain (the Network ID wizard will also accomplish the same):
Then the root password is entered and the domain is joined (remember, the root password
can be the same as the Linux root password, or it can be a special Samba root password just
for joining domains).
Now let’s look at what happened in the background on Linux. The add user script is run and
the return codes from useradd and smbpasswd show success. The machine trusts are added
to the /etc/passwd and /etc/samba/smbpasswd files.
# cat /tmp/foo
rc from useradd = 0
rc from smbpasswd = 0
# tail -1 /etc/passwd
mikest30$:x:504:100::/dev/null:/bin/false
# tail -1 /etc/samba/smbpasswd
mikest30$:504:3007C3F6F74DCB0B478086620BEB4D1D:62C3580C1E684930F524F72C5C4392AB:[W
]:LCT-3EC297A6:
The logon path parameter determines where the user’s profile is stored as viewed by the
local Windows system. The logon drive and logon home parameters determine which what
happens when a DOS net use /home command is performed. The logon script parameter
allows you to specify a script that is run when a user logs on.
The special section [profiles] determines where the user profiles are stored in the Linux file
system and which permission bits new files and directories will be assigned.
This is all that is needed to set up roaming profiles. Now when clients do network logons, their
logon data is read from the profiles directory and when they log off, any changes are written
to it.
For example, after a network logon with user ID mikem to the new SMBLCC domain, a new
Windows desktop was shown. A DOS (Command) prompt and a calculator were dragged
from the Start menu to the desktop. After a logout the following files were written to the
profiles file system path (Windows Media Player was mysteriously added to the list):
# cd /var/lib/samba/profiles
# ls
mikem/
# ls mikem
Application Data/ Favorites/ NTUSER.DAT.LOG Recent/ Templates/
Cookies/ My Documents/ NetHood/ SendTo/ ntuser.ini
Desktop/ NTUSER.DAT PrintHood/ Start Menu/
# ls mikem/Desktop
Calculator.lnk Command Prompt.lnk Windows Media Player.lnk desktop.ini
75
# cd /mnt
# find . -name "*quota*"
./suse/s390/quota-3.03-84.s390.rpm
# rpm -ivh suse/s390/quota-3.03-84.s390.rpm
quota ##################################################
Because quotad is for NFS, it is not set to start on reboot. The quota script is not designed to
be started interactively, rather, only at boot time:
# chkconfig | grep quota
boot.quota on
quota off
quotad off
# chkconfig quota on
# chkconfig | grep quota
boot.quota on
quota on
quotad off
To enable user and group quotas, the parameters usrquota and grpquota are set,
respectively, in the /etc/fstab file. In this example, user quotas are set up for the file system
mounted over /home/:
# cd /etc
# cat fstab
/dev/dasdb1 / ext3 defaults 1 1
/dev/dasda1 /home ext3 defaults 1 2
/dev/dasdc1 swap swap pri=42 0 0
...
# cp fstab fstab.orig
# vi fstab --> replace “defaults” with “usrquota”
# cat fstab
/dev/dasdb1 / ext3 defaults 1 1
/dev/dasda1 /home ext3 usrquota 1 2
/dev/dasdc1 swap swap pri=42 0 0
Rebooting the system will both start the quota and quotad services:
# shutdown -r now
...
After the system comes up see the usrquota parameter on the mounted file home system and
initialize the quota system with the quotacheck command.
# rcquota status
Checking for quota: running
# mount | grep home
/dev/dasda1 on /home type ext3 (rw,usrquota)
A quota for an individual user can be changed with the edquota -u command:
# edquota -u mikem
Disk quotas for user mikem (uid 500):
Filesystem blocks soft hard inodes soft hard
/dev/dasda1 0 0 0 0 0 0
Once one user’s quota is set, it can be copied to all users with the edquota -p command. In
this example an awk command is used to get users with a UID of 500 or higher from the
/etc/passwd file:
# edquota -p mikem `awk -F: '$3 > 499 {print $1}' /etc/passwd`
Now that quotas are enabled on Linux, they need to be tested. The quota for the user mikem is
10MB. A 3MB file can be copied two times, but a warning is issued after the third as the soft
limit is reached. The fourth copy fails as the hard limit is reached:
$ ls -l foo*
-rw-r--r-- 1 mikem users 3008507 2003-05-20 11:11 foo
$ cp foo foo1
$ cp foo foo2
$ cp foo foo3
dasd(94,1): warning, user block quota exceeded.
$ cp foo foo4
dasd(94,1): write failed, user block limit reached.
cp: writing `foo4': Disk quota exceeded
$ ls -l foo*
-rw-r--r-- 1 mikem users 3008507 May 20 11:11 foo
-rw-r--r-- 1 mikem users 3008507 May 20 11:27 foo1
-rw-r--r-- 1 mikem users 3008507 May 20 11:27 foo2
-rw-r--r-- 1 mikem users 3008507 May 20 11:27 foo3
-rw-r--r-- 1 mikem users 122880 May 20 11:27 foo4
After the fourth copy fails, the du command shows that exactly 12MB (OK, 12000KB) are
being used:
$ du -sk
12000 .
The next step is to test with Samba. First foo3 and foo4 are removed with the rm foo3 foo4
command. Then Samba is started and the home share mikem is obtained from a Windows
client. As from the shell, an attempt is made to make two more copies of the file foo. The first
one succeeds without a warning about the soft limit. However, the next one fails as expected
with the following error dialog:
77
3.15 Setting up a z/VM VDISK swap space
Unfortunately, the meatier scenarios of migrating data at the enterprise level has not yet been
documented. Both an LDAP and an Active Directory scenario need to be documented.
One of the first questions to answer is what the architecture of authentication and
authorization will be, for the short term and for the long term. The simplest type of Samba
authentication is to use the smbpasswd file. To simply test Samba function, the smbpasswd file
can be used, but this should only be for testing, or perhaps for very small teams using Samba.
Usually, the first phase leaves authentication on Windows domain controllers. Setting up
winbind can be tricky, but when it is set up correctly, it works fine. An interim step can then be
to set up Samba to act as a PDC. With Samba-3, additional function is being added to bring it
more in line with Active Directory. The long term goal should be to use LDAP services for a
centralized, highly available authentication and authorization system. Using LDAP will not
lock you into a single vendor’s solution.
Another issue is how to architect a proper backup and restore. Typically a vendor product is
already in place in a large enterprise. The issue then becomes how to fit the Samba
architecture into the existing backup and restore solution.
Another issue to address is how to deal with centralized vs. distributed data. Often there is a
requirement for file and print services in locations remote from the data center. Often the
network bandwidth is small. Mapping a network drives is possible, but not usable due to the
limited bandwidth. Usually, remote file and print servers on Intel PCs is the solution. What
then needs to be addressed, is how these remote servers fit in with the authentication and
backup and restore architecture that is agreed upon.
Once an overall architecture is agreed upon, pilot migrations can be started. Depending on
the architecture, one rough order of steps required is:
Set up Linux and Samba as decided upon.
Extract user, group, share information from Windows (pwdump2, Samba-3 net rpc vampire
command, etc.)
Transfer the user, group, share information to Linux Samba (usually just FTPing one or
more files)
Recreate the user, group and share environment on Linux using scripts if necessary
Copy user data from Windows servers to Linux. Copy ACLs associated with files and
folders is an issue, as they are not always copied (robocopy from the Windows Resource
Kit, or the freeware/product named xxcopy are often used)
Test the pilot setup for integrity and performance.
81
Section 5. Migration from Novell NetWare
In general there is less experience in migrating NetWare data than in migrating Windows
data. However, the question of migrating from NetWare is often asked. There are two general
approaches: convert the NetWare metadata to Linux or use NetWare 6.5 to move the data to
Linux while keeping the NetWare directory and data intact.
In addition, some more details on creating the four files using NetWare commands were
found on the Web:
Samba can also be implemented as just part of the infrastructure, Enabling Samba services
on Linux images that have a function other than file and print serving can aid Linux users. For
example Web developers and programmers can move data to the Linux environment in ways
that are already familiar to them and access them from a Windows environment.
83
Reference scripts
Following are the LDAP scripts used in 3.4, “Setting up OpenLDAP” on page 52. The ldap
commands (ldapadd, ldappasswd, etc) require many parameters that are difficult to remember
and also commonly require the same parameters. Simple wrappers are written around the
ldap commands so a man page does not have to be referenced each time you want to use
them.
The file lvars contains variables common to the scripts such as the LDAP host, suffix,
manger, etc:
# cat lvars
LDAP_HOST=localhost
LDAP_SUFFIX=dc=poklcc,dc=ibm,dc=com
LDAP_MANAGER=cn=Manager,$LDAP_SUFFIX
LDAP_USERS=ou=People,$LDAP_SUFFIX
The script lpasswd invokes ldappasswd to change LDAP passwords:
# cat lpasswd
# lpasswd - a wrapper around ldappasswd to make it easier to use
# variables are set in the file ./lvars
# Hard code the parameters:
# -x - use simple authentication instead of SASL
# -h $LDAP_HOST - LDAP server IP@ or DNS name
# -D $LDAP_MANAGER - rootdn set in lvars
# -W - prompt for root pw
# -S - prompt for new pw
scriptName=`basename $0`
if [ $# != 1 ]; then
# usage
echo; echo "Usage: $scriptName <user_name>"; echo
echo "Change the password on the LDAP server"
echo "See this script, the file lvars and /etc/openldap/ldap.conf"
else
# do it!
. /usr/local/sbin/lvars
ldappasswd -x -h $LDAP_HOST -D $LDAP_MANAGER -W -S uid=$1,$LDAP_USERS
fi
The script ldifadd invokes ldapadd to add the contents of an ldif file:
# cat ldifadd
# ldiffadd - wrapper around ldapadd to make it add LDAP entries in .ldif files
# Common variables are set in the file ./lvars
# Hard coded parameters:
# -x - use simple authentication instead of SASL
# -D $LDAP_MANAGER - rootdn set in lvars
# -h $LDAP_HOST - LDAP server IP@ or DNS name
# -W - prompt for root pw
# -S - prompt for new pw
scriptName=`basename $0`
if [ $# != 1 ]; then
The script ldifmod invokes ldapmodify to modify an entry based on an ldif file:
# cat ldifmod
# ldifmod - wrapper around ldapmodiy to save typing
# Common variables are set in the file ./lvars
# Hard coded parameters:
# -x - use simple authentication instead of SASL
# -D $LDAP_MANAGER - rootdn set in lvars
# -h $LDAP_HOST - LDAP server IP@ or DNS name
# -W - prompt for root pw
scriptName=`basename $0`
if [ $# != 1 ]; then
# usage
echo; echo "Usage: $scriptName <ldif_file>"; echo
echo "Modify LDAP entries based on the contents of an ldif file"
echo "See this script, the file lvars and /etc/openldap/ldap.conf"
else
# do it!
. /usr/local/sbin/lvars
ldapmodify -x -h $LDAP_HOST -D $LDAP_MANAGER -W -f $1
fi
85
# cat ldelete
# ldel - a wrapper around ldapdelete to make it easier to use
# variables are set in the file ./lvars
# Hard code the parameters:
# -x - use simple authentication instead of SASL
# -h $LDAP_HOST - LDAP server IP@ or DNS name
# -D $LDAP_MANAGER - rootdn set in lvars
# -W - prompt for root pw
scriptName=`basename $0`
if [ $# != 1 ]; then
# usage
echo; echo "Usage: $scriptName <dn>"; echo
echo "Delete the <dn> from the LDAP server"
echo "See this script, the file lvars and /etc/openldap/ldap.conf"
else
# do it!
. /usr/local/sbin/lvars
ldapdelete -x -h $LDAP_HOST -D $LDAP_MANAGER -W $1
fi
Web sites
Network Time Protocol home page:
http://www.ntp.org/index.html
Samba home page:
http://www.samba.org
Linuxvm.org - the Linux on zSeries portal:
http://linuxvm.org
DeveloperWorks - Linux s390 code patches from IBM Boeblingen
http://www10.software.ibm.com/developerworks/opensource/linux390/index.shtml
Vendor applications for Linux on zSeries:
http://www.ibm.com/servers/eserver/zseries/solutions/s390da/linuxproduct.html
z/VM and Linux:
http://www.vm.ibm.com/linux
linux-390 archives:
http://www.marist.edu/htbin/wlvindex?linux-390
z/VM publications:
http://www.vm.ibm.com/pubs/
87
Mailing lists
linux-390 mailing list (subscribe at bottom of page)
http://www.marist.edu/htbin/wlvindex?linux-390
Samba mailing list (this host or other mirror)
http://us2.samba.org/samba/archives.html