A Samba server actually consists of two server programs: smbd and nmbd. smbd is the core of Samba. It establishes sessions, authenticates clients and provides access to the file system and printers. nmbd implements the “network browser”. Its role is to advertise the services that the Samba server has to offer. nmbd causes the Samba server to appear in the “Network Neighborhood” of Windows NT and Windows 95 machines and allows users to browse the list of available resources. It would be possible to run a Samba server without nmbd, but users would need to know ahead of time the NetBIOS name of the server and the resource on it they wish to access. nmbd implements the Microsoft network browser protocol, which means it participates in browser elections (sometimes called “browser wars”), and can act as a master or back-up browser. nmbd can also function as a WINS (Windows Internet Name Service) server, which is necessary if your network spans more than one TCP/IP subnet.
Samba also includes a collection of other tools. smbclient is an SMB client with a shell-based user interface, similar to FTP, that allows you to copy files to and from other SMB servers, as well as allowing you to access SMB printer resources and send WinPopup messages. For users of Linux, there is also an SMB file system that allows you to attach a directory shared from a Windows machine into your Linux file system. smbtar is a shell script that uses smbclient to store a remote Windows file share to, or restore a Windows file share from a standard UNIX tar file.
The testparm command, which parses and describes the contents of your smb.conf file, is particularly useful since it provides an easy way to detect configuration mistakes. Other commands are used to administer Samba's encrypted password file, configure alternate character sets for international use and diagnose problems.
As usual, the best way to explain what a program can do is to show some examples. For two reasons, these examples assume that you already have Samba installed. First, explaining how to build and install Samba would be enough material for an article of its own. Second, since Samba is available as Red Hat and Debian packages shortly after each new stable release is announced, installation under Linux is a snap. Further, most “base” installations of popular distributions already automatically install Samba.
Before Samba version 1.9.18 it was necessary to compile Samba yourself if you wished to use encrypted password authentication. This was true because Samba used a DES library to implement encryption, making it technically classified as a munition by the U.S. government. Binary versions of Samba with encrypted password support could not be legally exported from the United States, which led mirror sites to avoid distributing pre-compiled copies of Samba with encryption enabled. Starting with version 1.9.18, Samba uses a modified DES algorithm not subject to export restrictions. Now the only reason to build Samba yourself is if you like to test the latest alpha releases or you wish to build Samba with non-standard features.
Since SMB is a large and complex protocol, configuring Samba can be daunting. Over 170 different configuration options can appear in the smb.conf file, Samba's configuration file. In spite of this, have no fear. Like nearly all aspects of UNIX, it is pretty easy to get a simple configuration up and running. You can then refine this configuration over time as you learn the function of each parameter. Last, the latest version of Samba, when this article was written in late January, was 1.9.18p1. It is possible that the behavior of some of these options will have changed by the time this is printed. As usual, the documentation included with the Samba distribution (especially the README file) is the definitive source of information.
The smb.conf file is stored by the Red Hat and Debian distributions in the /etc directory. If you have built Samba yourself and haven't modified any of the installation paths, it is probably stored in /usr/local/samba/lib/smb.conf. All of the programs in the Samba suite read this one file, which is structured like a Windows *.INI file, for configuration information. Each section in the file begins with a name surrounded by square brackets and either the name of a service or one of the special sections: [global], [homes] or [printers].
Each configuration parameter is either a global parameter, which means it controls something that affects the entire server, or a service parameter, which means it controls something specific to each service. The [global] section is used to set all the global configuration options, as well as the default service settings. The [homes] section is a special service section dynamically mapped to each user's home directory. The [printers] section provides an easy way to share every printer defined in the system's printcap file.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide