Learn Linux, 302 (Mixed environments)

Concepts

Learn the concepts behind file and print sharing in a mixed environment

Content series: This content is part # of # in the series: Learn Linux, 302 (Mixed environments) Stay tuned for additional content in this series. This content is part of the series: Learn Linux, 302 (Mixed environments) Stay tuned for additional content in this series.

About this series This series of articles helps you learn Linux system administration tasks. You can also use the material in these articles to prepare for the Linux Professional Institute Certification level 3 (LPIC-3) exams. See our developerWorks roadmap for LPIC-3 for a description of and link to each article in this series. The roadmap is in progress and reflects the current objectives (November 2010) for the LPIC-3 exams. As each article is completed, it is added to the roadmap.

Overview

In this article, learn about these concepts:

Server Message Block (SMB)/Common Internet File System (CIFS)

File sharing

Print service

This article helps you prepare for Objective 310.1 in Topic 310 of the LPI's Mixed Environment speciality exam (302). The objective has a weight of 1.

Prerequisites

To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test file and print access.

File and print sharing

About the elective LPI-302 exam Linux Professional Institute Certification (LPIC) is like many other certifications in that different levels are offered, with each level requiring more knowledge and experience than the previous one. The LPI-302 exam is an elective specialty exam in the third level of the LPIC hierarchy and requires an advanced level of Linux system administration knowledge. To get your LPIC level 3 (LPIC-3) certification, you must pass the two first-level exams (101 and 102), the two second-level exams (201 and 202), and the LPIC-3 core exam (301). After you have achieved this level, you can take the elective specialty exams, such as LPI-302.

The goal of file and print sharing is to let computers use disks and printers on other computers as if they were locally attached. This functionality allows more people to use the same expensive resources and to access those resources from anywhere. As central resources, files and printers can be more tightly controlled and audited, should that be required.

Desirable attributes of a file and print sharing solution are:

The solution should be network agnostic—that is, indifferent to the type of network (Ethernet, token ring) on which it is run.

Applications should not need to know whether they are accessing a file on a local disk or a remote one or whether they are printing to an attached or remote printer.

There should be some way to mediate simultaneous requests for the same resource, such as two people trying to print to a printer at the same time.

The solution should implement some type of authentication system to understand who is asking for a resource and an authorization system to decide whether the access should be granted.

Build your own feed You can build a custom RSS, Atom, or HTML feed so you will be notified as we add new articles or update content. Go to developerWorks RSS feeds. Select Linux for the zone and Articles for the type, and type Linux Professional Institute for the keywords. Then choose your preferred feed type.

There are several different ways to share files and printers. Many UNIX utilities, such as the Berkeley printing system, have been network aware since the early 1980s. Sun Microsystems introduced the Network File System (NFS) in 1984, which let UNIX computers mount file systems over the network. IBM and Microsoft came up with the SMB protocol to perform many network-sharing tasks, including sharing files and printers. File and print sharing can be performed by dedicated servers, by individual workstations, or by a combination of both.

File sharing

Even if a file is being shared from a workstation, the device that has the disk resource to share is called the server, and the devices accessing the disk are called clients. The server is said to either export the file system (in UNIX terms) or to share the disk or directory (in Windows terms). Clients then mount the file system as a local disk or connect to the share.

The nature of the sharing relationship can be temporary or long term. A client can connect to the server to get a few files and then disconnect, or a client can have the connection open until it reboots. The client can treat the remote file system as a local disk or part of the local file system, or it can choose to access the resource at the application layer, much like a File Transfer Protocol (FTP) client does.

Another feature related to file sharing is the concept of browsing. Browsing allows a client to find a server on the network, usually from a dynamically populated list.

Print sharing

A printer may not be attached directly to a server, so multiple levels of sharing could be occurring. When multiple clients have the same printer configured, they generally do so through a service called a spooler. The job of the spooler is to manage the list of print jobs, otherwise known as the print queue. As multiple people submit print jobs, the spooler stores the job to disk. Once the printer is unused, the spooler can send the job to the printer without fear of contention from other print jobs.

Even though printers can be attached to the network, a server is usually used as the spooler, which in turn prints to the printer over the network. This is done for three reasons: first, the server is likely to have a more robust and larger spooling area than the printer. Second, the server can take care of access control. And third, the server can distribute printer drivers, should they be needed.

SMB and CIFS

SMB is a protocol, not an implementation. The protocol has been implemented in many different operating systems, from Windows to UNIX and even to mainframe environments.

History

SMB got its start with IBM and was implemented by Microsoft as the company began to network its products in the early 1990s. At that time, SMB needed a separate product, such as LAN Manager or Windows for Workgroups, but file sharing was eventually made a part of the regular operating system with Microsoft Windows NT.

Microsoft continued to adapt SMB for the new features being introduced in its operating systems and eventually came out with a version it called CIFS, which it proposed for standardization with the Internet Engineering Task Force.

Around the same time, a Ph.D. student from Australia, Andrew Tridgell, started reverse-engineering a mainframe implementation of SMB and began work on what would eventually be an open source implementation of SMB and Microsoft protocols called Samba. The project started as a way to move files and has blossomed into a full client and server implementation, including the ability to act as a Windows domain controller and soon, an Active Directory server.

SMB vs. CIFS

CIFS is technically a dialect of SMB. The SMB protocol has been modified over the years, so it is necessary for a client and a server to negotiate the dialect of the protocol to be spoken. CIFS refers to the NT LAN Manager (NTLM) series of extensions. Strangely, the protocol does not use the string CIFS to identify itself; instead, NT LM 0.12 is used.

For all practical purposes, you can use the terms SMB and CIFS interchangeably, as the CIFS dialect of SMB is the one now in use. Incidentally, CIFS is pronounced "siffs" rather than being spelled out like SMB.

SMB protocol overview

As a client-server protocol, the client makes contact with the server. SMB started out requiring an application programming interface (API) layer called Network Basic Input/Output System (NetBIOS). This API provided several services that SMB used as well as several services relating to name resolution and network browsing. When used in conjunction with NetBIOS, SMB could run on top of:

Raw Ethernet, in which case SMB used NetBIOS Frames, often called NetBEUI

Novell Internetwork Packet Exchange (IPX)/Sequenced Packet Exchange(SPX), in which case SMB used NetBIOS over IPX/SPX (NBX)

TCP/IP, in which case SMB used NetBIOS over TCP/IP (NBT)

NetBIOS provides three key services to a Microsoft network:

Name services for finding hosts on the network

for finding hosts on the network Session services for the reliable communication and transfers between a client and a server

for the reliable communication and transfers between a client and a server Datagram distribution services for small messages and network broadcasts

SMB therefore made the most use of session services but would rely on the other two services for support, such as using name services to find the address of the server.

Eventually, TCP/IP's dominance and Microsoft's move to rely on Domain Name System (DNS) for name resolution led to SMB being run directly on top of TCP/IP in a manner called direct hosting. Whereas NBT ran on TCP and User Datagram Protocol (UDP) ports 137-139, direct hosting uses TCP and UDP port 445.

SMB in the OSI stack

Figure 1 shows the Open Systems Interconnection (OSI) model, which is used to explain the interactions between network protocols. The OSI model describes the features necessary to have an application work over a network and breaks down the features into a series of layers. Each layer uses the services provided by the layers below it and provides services to the layers above it.

Figure 1. The OSI model

Layers 1 and 2 are the physical and data link layers, respectively, fulfilled by the Ethernet network. These two layers get small pieces of information from one network hop to another. TCP and IP take up the next two layers and are the transport and network layer, respectively. The network layer is responsible for end-to-end connectivity, while the transport layer allows for larger messages to be built out of smaller messages and multiple services to exist on the same server. Each layer uses the layers beneath it, so the network layer does not need to worry about how each hop on the network uses the physical and data link layers and so forth.

On a network using NetBIOS, the session layer is used. The session layer provides the session services described earlier. SMB operates at the application layer (the presentation layer is not used here), which means that it takes advantage of all the features that the lower layers provide.

On a network not using NetBIOS, the session layer is simply left out. TCP is already capable of handling most of the session services, and the name services are handled by DNS.

Uniform Naming Convention

On the Internet, you are familiar with universal resource identifiers (URIs) such as http://ibm.com/developerworks . A URI identifies where you can find a particular document or other content. In the example URI, the http refers to the scheme—in this case, the document is to be retrieved using HTTP. The name of the host to ask for the content is ibm.com, and /developerworks refers to the resource on that host to ask for.

Similarly, Uniform Naming Convention (UNC) paths identify Windows network resources. A UNC path looks like \\shorty\documents\public\photo.jpg . The UNC path starts with two backslashes ( \\ ) followed by the name of the server, another backslash, and the name of the shared folder. After that is a path relative to the shared folder that specifies a path to the resource.

UNC paths differ from URIs in a few ways:

There is no need for a scheme. SMB is used.

Backslashes are used instead of forward slashes ( / ); although in some cases, forward slashes can be used.

); although in some cases, forward slashes can be used. The shared folder looks like part of the resource name but refers to the name of the file share on the server and need not exist on the server's file system.

Samba

Samba bills itself as the "standard Windows interoperability suite of programs for Linux and UNIX." Although Linux and other UNIX flavors have come up with other ways of mounting SMB file shares, none comes close to matching Samba's functionality as both a client and a server and further, as an integration point into a Windows network.

Samba consists of several daemons meant to run in the background and provide services as well as several command-line tools used to interact with Windows or Samba services. Both the daemons and the tools will be thoroughly investigated over the course of this article series, but some of the more notable binaries are:

smbd. This daemon acts as the SMB file and print server.

This daemon acts as the SMB file and print server. nmbd. This daemon provides the NetBIOS naming services.

This daemon provides the NetBIOS naming services. mount.cifs. This utility mounts a remote SMB file system onto the local UNIX file system, much like a local disk or NFS share.

This utility mounts a remote SMB file system onto the local UNIX file system, much like a local disk or NFS share. smblient. This utility provides command-line access to SMB resources, much like an FTP client. It can also list shares on a remote server and browse the network.

This utility provides command-line access to SMB resources, much like an FTP client. It can also list shares on a remote server and browse the network. smb.conf. This is not a utility but rather the configuration file for all the tools and therefore worth mentioning in the same context as the other binaries.

Samba, like other open source software, can be compiled from the source code or downloaded as part of your distribution. It is managed through system-initialization scripts and configuration files.

Moving forward

The next exam objective, 310.2, discusses the roles that the different Samba daemons play and the different security modes under which these daemons operate.

Downloadable resources

Related topics