Samba, first released in 1992, is a suite of programs that allow for interoperability between Unix/Linux servers and Windows clients. It uses the TCP/IP installed on the server, allowing the host to communicate with Windows clients attached to it (similarly to a Windows file and print sever). What do you need to know about running Samba in a heterogeneous production environment? What is different about running Samba in a large environment as opposed to a small organization? What are some best practices you should adopt? These are some of the topics we'll discuss here.
As the systems administrator in charge of your Samba system you should always be cognizant of the fact that you are not running Samba on your home/lab network. Many systems administrators that I work with tend to fool around with Samba in whatever sandbox environment they have, which is fine. But the rules change in a production environment, you need to do things right. Let's start with support. How do you get support with Samba? First you should try the Samba mail list. This is an important list to be a member of, as it should be one of your main sources of Samba information. If you're with a Fortune 500 company that really relies on Samba, having mailing-list support is probably not enough. Through the Samba web-site, you can actually view a whole slew of companies that offer commercial support, world-wide. In the USA alone, I pulled out a list of approximately 70 companies. These VARs can help you with design support and day-to-day production support.
The next question I have for you is what kind of environments do you have? If you have a glazed look on your face, that is not a good thing. If you are running Samba in a production environment, you should have a minimum of two other environments, including test and development. I also highly recommend a sandbox environment as well. So, why do you need these environments? The short answer is the same reason you need this environments for your other mission critical (we're assuming that Samba is critical for your company) systems like Oracle and LDAP systems. Would you touch your Oracle system in production prior to first rolling out your changes through your environments? I didn't think so. Then why would you even think of making a change in your smb.conf file unless you first validated these changes in test environments? As the system administrator, you need to stop thinking as the Linux guru and more about responsible systems administration: availability, change control and process all need to be integrated in your vocabulary.
Samba change control and process
Let's talk about change control and process. If you're running Samba in a production environment, there is no excuse for running eighteen versions behind. You should upgrade to a current version every so often so you'll have a version with all the current bug fixes. At a minimum, you should download whatever fixes are available for your current version. Note that there is currently a new version of Samba available, which should be running all current bug-fixes. Version 3.3.4 is the latest release available (April 29, 2009) for download.
Samba systems administration and configuration
Next up, routine systems administration and on-going configuration of your environment. Should you be configuring your files from the command line or using a GUI? This is one of those debates that go on endlessly, and probably started the first day after you were able to use GUI's on Unix and Linux servers. I configured a Samba environment recently on a version of SLES10, and while I normally use the command line, I will tell you that the GUI is unquestionably safer and easier to work with. One glance at both the GUI and the smb.conf file below should tell you which is simpler to configure
Click on image for larger version
Click on image for larger version
Samba config files are just not easy to work with and even easier to mess up. Further, while you may understand what you are looking at, you are in a large production environment where others may be working who are not as senior as you. The bottom line is that you could train someone to administer Samba using YAST in 200% less time than using the command line, any day of the week. Better yet, there is far less of a potential in messing things up. Do you remember when you first started using the vi editor? Did you ever mess up a file big time? I know I did, many times actually. What do you think the ramification might be to messing up your samba file with vi? Enough said.
While we're on the subject of messing up, what about backups? Are you backing up your Samba environment, or do you just think you are? At a minimum you should be backing up all of the /etc/samba files.
I would use this syntax :
# cp -av /etc/samba /path/to/backup
–av flag, archives your sub-directories. You will also need to backup your passwd and group files (/etc/passwd, /etc/shadow, and /etc/group files), so that the Unix users exist after a full recovery.
Finally, perhaps most importantly, bring over your database files of users, the Samba * .tdb files. The best way of backup up these files is using the
tdbbackup tool, which is part of the Samba suite. I highly recommend the tdbbackup utility, used for both backing up and validating the integrity of samba .tdb files. I like this utility because it can be run at any time, even during actually Samba operations. Some of the more important files include; secrets.tdb and passdb.tdb. These are usually in /usr/local/samba/private directory, /etc/samba or /var/lib/samba .
tdbackup – s *.tdb
tdbackup –v * .tdb
What I also like about the utility, is that if it finds file damage and it finds a prior backup, the backup file will be restored.
So, I will reiterate the importance of treating Samba in the same fashion that you would any mission-critical application – assuming that in your company, Samba has been deemed mission critical. Make sure you have a good support mechanism in place, and run your changes through your environments using proper change control. Also bring over recent bug-fixes, and most importantly, backup your systems.
ABOUT THE AUTHOR: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist.