Don't you just hate finding out that there's a new file server in the building by being asked what you're going to do to fix it?

This is not an unusual experience if your company has a lot of staff using Windows machines. Either a machine crashes, a departmental PC administrator goes out sick, or some local expert leaves for greener pastures. The system administrtor is left with supporting another machine in another office on yet another floor.

Samba to the Rescue

If you run Samba on one of your Unix machines, however, you can make the failed Windows machine reappear by creating a virtual server on your existing Samba machine.

Samba can create multiple servers, each with its own NetBIOS name and separate configuration file. This means that you can create an exact copy of the failed machine on a server you control, without having to roam the halls to do remote administration.

Let's consider a common case: creating a Samba server to replace the Windows server that a former marketing manager ran on his desktop workstation.

We received a report that "marketing had disappeared." We suspected this might be a machine-name, as the department was still there when we came in this morning. Sure enough, the marketing manager had just changed jobs. The departmental secretary had shut down his Windows 98 machine and called the PC team to have it picked up and refurbished for the new manager.

Salvaging the Data

The former manager's machine was simply called "Marketing," so the first thing we did was to power it up, connect to it with a nearby PC, and look at how it was organized. See Figure 1.

Figure 1. The Network Neighborhood
Figure 1. The Network Neighborhood

Oh dear, we have lots of Windows servers we didn't know about ... but let's concentrate on just the marketing machine. See Figure 2.

Figure 2. The Marketing server
Figure 2. The Marketing server

This looks manageable: two directories containing a small number of templates and proposals, and a printer.

The first thing to do was to protect the data and copy it to our Samba server. We changed the permissions (actually passwords) on the Windows server so that only we could read from it, and created a directory tree on our Samba server for the data.

From the new /usr/local/samba/marketing directory on Elsbeth, the Samba server, we started copying using smbclient:

   elsbeth> cd /usr/local/samba/marketing/proposals
   elsbeth> smbclient //marketing/proposals
   added interface ip=10.0.1.39 bcast=10.0.1.255 \ 
   nmask=255.255.255.0 
   Got a positive name query response from 10.0.1.39
   Password:
   smb: \> prompt
   smb: \> mget *
   smb: \> quit
   elsbeth> ls
   proposal_1 proposal_12
   proposal_2 proposal_3
   proposal_5 proposal_7
   proposal_9

Smbclient is an ftp-like program that's handy for jobs like this. Its commands are shown in Appendix D of Using Samba (also on page 62 of the Samba Pocket Reference).


Interested in learning more about how Samba can help Unix and Windows machines coexist peacefully together? For more insight into the power of Samba read An Interview with the Authors of Using Samba.

This isn't the only way to get the files. We could have used smbsh to copy the //marketing/templates directory.

   elsbeth> smbsh
   Username: davecb
   Password:
   smbsh$ cd /smb/marketing/templates
   smbsh$ ls
   enquiry information old presales
   smbsh$ cp * /usr/local/samba/marketing/templates
   cp: old: is a directory
   smbsh$ cp -r * /usr/local/samba/marketing/template
   smbsh$ pwd
   /smb/marketing/templates
   smbsh$ exit

Smbsh is an SMB shell for Unix systems using ELF libraries, which allows us to use ordinary Unix commands to copy files to and from SMB servers mounted on your system. It's described in Appendix D of Using Samba (also on page 71 of the Samba Pocket Reference).

We could also have used smbmount if we were on a Linux machine:

   elsbeth> mount -t smbfs -o 
	workgroup=EastCoast,username=davecb 
        //marketing/proposals /mnt
   Password:
   elsbeth> cp -a /mnt/templates* \ 
   /usr/local/samba/marketing/templates
   elsbeth> umount /mnt

[Editor's note: Line 1 was extended to two lines to accommodate our Web site's formatting. Throughout this article, whenever a line of code or data has been broken up into two lines, the second line is indented.]

Smbmount is an SMB client that uses the standard Unix "mount" mechanism, similar to NFS. At the time of writing, smbmount is only available on Linux.

Creating the Virtual Server

Next we set up a master smb.conf file and two smb.sh files, one per virtual server. The smb.conf file says:

   [global]
        workgroup = EastCoast
        netbios aliases = elsbeth mktg
        include = /usr/local/samba/lib/smb.conf.%L

The %L at the end of the include line will be replaced by whichever NetBIOS name the client tries to use. Clients connecting to Elsbeth will get the usual configuration file, which was copied to smb.conf.elsbeth. Clients connecting to Mktg, the temporary name for the new marketing server, get:

   # Global parameters
   [global]
        wins support = yes
        local master = no
        log level = 1
        debug timestamp = yes

   [proposals]
        browseable = yes
        read only = no
        path = /usr/local/samba/marketing/proposals
 
   [templates]
        browseable = yes
        read only = no
        path = /usr/local/samba/marketing/templates

This is the Samba declaration for the two former Windows shares, plus a few settings that apply to all shares on that server.

If we connect from a Windows client, we'll see the image in Figure 3.

Figure 3. Our first try at a replacement
Figure 3. Our first try at a replacement

Additional Wrinkles

After asking the departmental secretary in Marketing to connect to the new server, we found we had the files and directory permissions right, but hadn't given "administrative" access to the secretary. We resolved that by adding:

   admin users = mktg_sec

to the [globals] section of smb.conf.mktg. This gave mktg_sec the equivalent of root permission in the /usr/local/samba/marketing file tree, but nowhere else.

The second wrinkle was that everything in the proposals directory had to be editable by the group. This meant we had to add:

   force create mode = 0660

so that all files that were created or edited from Windows would be writable by the group. Windows editors create new copies of the files they edit. If we didn't force the permissions to include writable-by-group, the proposal files would be read-only to everyone except the last person to edit them.

Next we had to make the templates read-only, which we did by changing the line under [templates] to:

   read only = yes

Finally, a local printer on the marketing manager's machine had been shared as Printer E12. This printer was promptly claimed by the departmental secretary. We therefore set up a printer share on Mktg called Printer E12, pointing to the Windows printer which now resided on the secretary's machine. The process is discussed in Chapter 7 of Using Samba (also on page 65 of the Samba Pocket Reference).

Once we finished, we were ready to let the department get its data back. We renamed the virtual server from Mktg to Marketing, and emailed users that it was working. The user community started connecting, as shown in Figure 4.

Figure 4. The final replacement server
Figure 4. The final replacement server

The old marketing machine was retained for a few days under a different name with its files set as read-only, so that anything we missed would be available. After a week of no complaints, we shut it down and handed it over for refurbishing and re-installation of a new copy of Windows.

We made almost everyone happy. The department had a server now that was backed up nightly (the Windows machine had never been), the secretary had the printer, and the new marketing manager had a Windows machine that wasn't slowed down by other people in his department using it as a file server.

Making Migration a Practice

When we first looked for the Marketing machine, we found a plethora of Windows SMB servers: 19 to be precise. Exactly three of these were official NT or Samba servers. This did not please our management, since they were paying for the servers, but didn't even know they existed. The old servers also were not on our backup system.

If your management is as cost-sensitive as ours, you might propose replacing large numbers of Windows servers with a single Unix or Linux server, to reduce both costs and business risk.

There are a number of places where Samba will save money over Windows servers, even planned and supported ones. These include client access licensing (CAL), server licenses, hardware reusability, increased uptime, and decreased third-party software licensing costs.

If we had replaced the unofficial Marketing server with an official Windows 2000 PDC, our first cost would be buying a license upgrade and client licenses for the other windows machines in the department:

Software Licensing Costs Windows 2000 server Server Licenses (upgrade) $599 each, includes 10 CALs Client Access Licences (CALs)
  (must be renewed yearly) $399 for 20
($19.95 per client)

If we consider Windows licensing costs for a 20-client department or a 2000-client company, the upgrade and re-licensing costs are non-trivial.

  20 clients, 2 servers 2000 clients, 20 servers Server Licenses (upgrade) $1,198.00 $11,980 CAL Costs $ 0 for the first year,
$ 399/yr. subsequently $35,910 in the first year
$39,900/yr. subsequently

We can also gain savings in hardware costs. Samba runs on Linux, and Linux will run effectively on hardware which Windows considers obsolete. For instance, the minimum requirements to run Windows 2000 are a Pentium 166 with 64MB of RAM. Linux, however, can run on as little as a 386 with 8MB of RAM. Many businesses can reuse former low-speed Pentium-class desktop computers as Samba servers.

However, our greatest savings is in increased system reliability. Because we are able to do most system maintenance and software upgrades "live," without rebooting, we are able to keep systems up during most maintenance windows. With Windows NT 4, companies generally allow four hours per month for offline maintenance, which is about 99.45 percent uptime.

Getting this up to 99.99 percent uptime, typical of Unix and Windows 2000 systems, gives us 3.5 additional hours of uptime per month, without the cost of upgrading to Windows 2000. With system administration costs running around $125 per hour, even 3.5 hours per month (due to the 0.5 percent improvement in uptime) equates to more than $425 per server [in budget savings.] which won't have to spent.

Caveats and Avenues of Error

If you plan to retire the redundant Windows servers in your company, you need to consider a few additional issues.

One of the obvious ones is to make sure you have enough disk space and memory to support the additional user community. In several cases we've removed disk drives from inactive Windows 9x servers and reused them in Samba servers for subsequent server migrations. Appendix B of Using Samba includes the rules of thumb we've used to size Samba for larger groups of users.

We found out very quickly that managing user accounts on individual Unix servers was difficult. Unless the Linux machines used a centralized database of users and groups, they could start to become an administrative nuisance. To eliminate this, we use NIS which allows us to centrally manage user logins, and groups.

In migrating a group of users from a Windows NT PDC, however, we found NIS alone wasn't enough. In larger organizations, administrators would change user information in the Windows NT domain, but forget to modify the Linux user information. To ease administration, we used a program called AutoSync. It automatically synchronizes Windows NT user and group changes into NIS.

We also recommend LPRng and LPRngTool for managing printers, as they are easier to use then most other printing subsystems, and work well with Samba.

Conclusions

There are significant financial and administrative advantages in using Samba. Multiple virtual Samba instances on one server reduce the amount of hardware required, the licensing costs, and the amount of time spent administering those servers. From both a business and systems point of view, it's a big win, and with the money saved, we just might be able to convince upper management to buy us some new hardware.


David Collier-Brown is a former system administrator from a multinational corporation, and is now a Staff Engineer at Sun's Customer Engineering site in Toronto. He does system and application tuning for customers on Solaris and tries to find time to write about Samba and Linux. David is coauthor of Using Samba and Samba Pocket Reference.

Geoff Silver is a Senior Systems Administrator at Scoreboard, Inc., is married, and runs a Linux professional services company at US Linux Networks, LLC. He is a graduate of the University of Maryland, Baltimore County, and has been working with Unix since 1995 and Linux since 1998.


O'Reilly & Associates will soon release (April 2001) Samba Pocket Reference, based on the best-selling Using Samba (November 1999).