Samba tutorial Part 1

Introduction

This is the SMB HOWTO. This document describes how to use the Server Message Block (SMB) protocol, also called the Session Message Block, NetBIOS or LanManager protocol, with Linux using Samba. Although this document is Linux-centric, Samba runs on most Unix-like operating systems.

This document is maintained by David Wood ( dwood@plugged.net.au). Additions, modifications or corrections may be mailed there for inclusion in the next release.

Much more Samba documentation is available at the Samba Web site, located at http://www.samba.org/. There is a tremendous amount of information there; please have a look before asking for help! You also might try the comp.protocols.smb newsgroup.

The SMB protocol is used by Microsoft Windows 3.11, NT and 95/98 to share disks and printers. Using the Samba suite of tools by Andrew Tridgell ( Andrew.Tridgell@anu.edu.au), UNIX (including Linux) machines can share disk and printers with Windows hosts. The smbfs tools by Paal-Kr. Engstad ( engstad@intermetrics.com) and Volker Lendecke ( lendecke@namu01.gwdg.de) enable Unix machines to mount SMB shares from Windows or Samba hosts.

There are four basic things that one can do with Samba:

1. Share a Linux drive with Windows machines.
2. Access an SMB share with Linux machines.
3. Share a Linux printer with Windows machines.
4. Share a Windows printer with Linux machines.

All of these are covered in this document, plus a few other odds and ends.

Disclaimer: The procedures and scripts either work for the author or have been reported to work by the people that provided them. Different configurations may not work with the information given here. If you encounter such a situation, please e-mail the author with suggestions for improvement in this document.

Please note that for Windows 3.x machines to access SMB shares, they must have a TCP/IP stack and the Win32s DLLs. Both of these are available on Microsoft's Web site ( http://www.microsoft.com). As of the writing of this version of the HOWTO, Microsoft are reportedly requiring a subscription to the Microsoft Software Developers Network (MSDN) to download the TCP/IP-32 stack for Windows 3.x from their Web site. Since this software used to be free, many older copies are in existance and may be acquired from friends and user group contacts.

Linux Networking Setup Required Information To enable networking, you must configure your network interface card or cards with an IP address and netmask. The kernel must have support for your cards compiled in, either as modular support or direct support. If you don't have kernel support read the sections about the kernel and how to compile it. To set your cards up, do the following. In my example my network is 192.168.1.0, IP=192.168.1.100, broadcast=192.168.1.255, netmask=255.255.255.0, gateway-192.168.1.1, nameserver=192.168.1.10. Determine your machines IP address from your network administrator Your network mask. This determines which portion of the IP address specifies the subnetwork number and which portion specifies the host. Class C (most networks) 255.255.255.0 Class B 255.255.0.0 Your network address which is your IP address bit wise anded with the network mask. Ex: IP: 192.168.1.100 Mask: 255.255.255.0 Net Addr:: 192.168.1.0 Your broadcast address. Used to broadcast packets to every machine on your subnet. Ex: IP: 192.168.1.100 Mask: 255.255.255.0 Net Addr: 192.168.1.255 Your gateway address. The address of the machine that is your gateway to the outside world. In many cases: Ex: IP: 192.168.1.100 Gateway: 192.168.1.1 Your nameserver address. Translates host names into IP addresses. 192.168.1.10

Configuration tools

There are many network configuration tools today. They are:

netconf		A GUI interactive interface available on Redhat 6.1
linuxconf		A GUI interactive interface available on Redhat 6.1 which includes netconf configuration.
netconfig		A GUI step by step interface
ifconfig		A text based program to configure the network interface. Type "man ifconfig" for info.

These programs will modify values in the following files:

• /etc/sysconfig/network - Defines your network and some of its characteristics.
• /etc/HOSTNAME - Shows the host name of this host. IF your name is "myhost" then that is exactly the text this file will contain.
• /etc/resolv.conf - Specifies the domain to be searched for host names to connect to, the nameserver address, and the search order for the nameservers.
• /etc/host.conf - Specifies the order nameservice looks to resolve names.
• /etc/hosts - Shows addresses and names of local hosts.
• /etc/networks - Provides a database of network names with network addresses similar to the /etc/hosts file. This file is not required for operation.
• /etc/sysconfig/network-scripts/ifcfg-eth* - There is a file for each network interface. This file contains the IP address of the interface and many other setup variables.

Analysis Tools

• netstat - Displays information about the systems network connections, including port connections, routing tables, and more. The command "netstar -r" will display the routing table.
• traceroute - This command can be used to determine the network route from your computer to some other computer on your network or the internet. To use it you can type "route IPaddress" of the computer you want to see the route to.
• nslookup - Used to query DNS servers for information about hosts.
• arp - This program lets the user read or modify their arp cache.
• tcpdump - This program allows the user to see TCP traffic on their network.
• dig(1) - Send domain name query packets to name servers for debugging or testing.

Manual Configuration

You can use one of the above tools or configure the network the old fashioned way as follows:

1. First to use networking on any permanent basis you should setup the file /etc/sysconfig/network similar to the example shown below.
2. Assign an ip address with "ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up".
3. Tell your machine that a hub is ready for information with the command "route add -net 192.168.0.0 netmask 255.255.255.0 eth0"
4. To contact hosts outside your network if a machine with IP address 192.168.1.1 is the gateway use the command "route add default gw 192.168.1.1 eth0"
5. If using a dialup connection use the command "route add default ppp0" The word default says if the packet is not for a machine on your local network, send it to the default device.
   

These settings are not permanent, but go away the next time you boot. They are normally set up in the directory /etc/sysconfig/network-scripts. Add the network interface to the file /etc/sysconfig/network-scripts/ifcfg-eth*. For example the file ifcfg-eth0 if for the first ethernet interface, ifcfg-eth1 for the second, ifcfg-lo is for the local interface. An example file from my system is:

DEVICE="eth0"
IPADDR="192.168.1.100"
NETMASK="255.255.0.0"
ONBOOT="yes"
BOOTPROTO="none"
IPXNETNUM_802_2=""
IPXPRIMARY_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="no"
IPXACTIVE_ETHERII="no"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="no"
IPXACTIVE_SNAP="no"

Unless you know what you're doing it is best to use a network configuration tool. I cannot guarantee the accurateness of how to set these files up on your system.

Configuring an interface for multiple IP addresses

If you want to configure your network card to act as more than one IP address, issue the following command:

ifconfig dummy 192.168.1.102 netmask 255.255.255.0

This uses the dummy system interface capability supported in the kernel to setup another virtual interface which operates at IP address 192.168.1.102. Substitute the IP address that you want your virtual interface to be with an appropriate netmask for your network. To disable this, issue the following command.

ifconfig dummy down

Another way to use multiple IP addresses on one ethernet card is to set up a new file in your /etc/sysconfig/network-scripts directory. Copy your ifcfg-eth0 role to ifcfg-eth0:0. Edit that file and rename the device to "eth0:0" and the IP address to the desired IP address. You may also want to modify BROADCAST, NETWORK, or NETMASK. You can continue adding IP addresses by using :1, :2, etc such as ifcfg-eth0:2.

To make it effective, you must reboot your system or issue the command "/etc/rc.d/init.d/network restart" as root.

Dynamically allocated IP addresses

To get the IP address of a dynamically allocated network interface in a script file enter the following:

dynip=`/sbin/ifconfig | grep -A 4 ppp0 | awk '/inet/ { print $2 } ' | sed -e s/addr://`

Substitute the correct interface that you get your dynamic IP address in for ppp0 in the example above. This script line gets your dynamic IP address for use in a masquerade script. You can use the variable $dynip as in any other configuration. The next time you make a new connection you will need to extract the dynip value again and re-run the masquerade script.

Networking file formats, examples and considerations

Below are listed some more in depth information about the networking files.

• /etc/sysconfig/network
  The /etc/inittab file contains the entry "si::sysinit:/etc/rc.d/rc.sysinit" which causes the system at startup to run the rc.sysinit script. The rc.sysinit file expects to find the file /etc/sysconfig/network if networking is to be enabled.
  The network file looks like this:

  NETWORKING=yes
  FORWARD_IPV4=false
  HOSTNAME=mymachine.mycompany.com
  DOMAINNAME=mycompany.com
  GATEWAY=192.168.1.1
  GATEWAYDEV=eth0

  Where GATEWAYDEV is the network interface card that is attached to the network the gateway machine is on. The GATEWAY is the actual IP address of the gateway machine.
  

• /etc/hosts - Defines local hosts.

  127.0.0.1 localhost localhost.localdomain
  192.168.1.100 mymachine.mycompany.com mymachine
  

• /etc/services - Internet network services list. It associates port numbers with names of services. The file contains three fields which are name, port/protocol, and aliases with an optional comment.
• /etc/protocols - Describes DARPA internet protocols available from the TCP/IP subsystem. Maps protocol ID numbers to protocol names. It includes protocol name, number, and aliases. The protocol file on my system:

  # /etc/protocols:
  # $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
  #
  # Internet (IP) protocols
  #
  # from: @(#)protocols 5.1 (Berkeley) 4/17/89
  #
  # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
  
  ip 0 IP  # internet protocol, pseudo protocol number
  icmp 1 ICMP  # internet control message protocol
  igmp 2 IGMP  # Internet Group Management
  ggp 3 GGP  # gateway-gateway protocol
  ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
  st 5 ST  # ST datagram mode
  tcp 6 TCP  # transmission control protocol
  egp 8 EGP  # exterior gateway protocol
  pup 12 PUP  # PARC universal packet protocol
  udp 17 UDP  # user datagram protocol
  hmp 20 HMP  # host monitoring protocol
  xns-idp 22 XNS-IDP  # Xerox NS IDP
  rdp 27 RDP  # "reliable datagram" protocol
  iso-tp4 29 ISO-TP4  # ISO Transport Protocol class 4
  xtp 36 XTP  # Xpress Tranfer Protocol
  ddp 37 DDP  # Datagram Delivery Protocol
  idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
  rspf 73 RSPF  #Radio Shortest Path First.
  vmtp 81 VMTP  # Versatile Message Transport
  ospf 89 OSPFIGP  # Open Shortest Path First IGP
  ipip 94 IPIP  # Yet Another IP encapsulation
  encap 98 ENCAP  # Yet Another IP encapsulation
  

• /etc/named.conf - Used for domain name service to configure named. Other files used are dependent on this file. This file is explained further in the DNS section
• /etc/resolv.conf - Specifies the domain to be searched for host names to connect to, the nameserver address, and the search order for the nameservers.

  domain mycompany.com
  search mycompany.com mynet.net
  nameserver 192.168.1.100
  nameserver 192.168.199.1
  nameserver 192.168.1.10
  

  The third line specifies that DNS should be tried on my machine first then use the normal nameserver on the fifth line. The fourth line specifies that my machine is running nameservices on another network which is using interface 192.168.199.1. This assumes the nameserver is set up on my machine which is explained in another section.

• /etc/host.conf - Specifies the order nameservice looks to resolve names. An example file:

   order hosts, bind
   multi on
   nospoof on
  

  The order specifies that when resolving names to first look in the /etc/host file, then use BIND8 (DNS) to resolve the name. The line "multi on" specifies that all valid addresses for a host found in the hosts file should be returned.

The files in /etc/sysconfig/network-scripts control your network interfaces. The network interface file is described above in the section "Manual Configuration". If you want or need more in depth knowledge about how these files are used, you will need to read the document "How Linux Works CTDP Guide" or "The CTDP Linux Startup Manual". Otherwise you will need to analyze the system startup scripts which is no small task.

Older X windows configuration

In Xwindows a working configuration is set up as follows:

NAMES:

hostname: mymachine.mycompany.com

Domain: mycompany.com

Nameservers: 192.168.1.10

HOSTS:

IP - 192.168.1.100

Name - mymachine.mycompany.com

INTERFACES:

Interface - eth0

IP- 192.168.1.100

proto - none

atboot - yes

Netmask: 255.255.255.0

Network: 192.168.1.0

Broadcast: 192.168.1.255

ROUTING:

Default gateway: 192.168.1.1

Default gateway device: eth0

Interface - 192.168.1.100

Network Address - 192.168.1.0

Network gateway 192.168.1.1

Netmask - 255.255.255.0

Routing

Routing table information is used to route incoming and outgoing network diagrams to other machines. On most simple configurations, there are three routes. One for sending packets to your own machine, one for sending packets to other machines on your network and one for sending packets to other machines outside your network through the gateway. Two programs (ifconfig and route) are used to configure these parameters. They are described in more detail in the routing section.

Hardware Load Balancers

Hardware Load Balancers

Hardware load balancers solve many of the problems faced by the round robin software solution through virtual IP addresses. The load balancer shows a single (virtual) IP address to the outside world, which maps to the addresses of each machine in the cluster. So, in a way, the load balancer exposes the IP address of the entire cluster to the world.

When a request comes to the load balancer, it rewrites the request's header to point to other machines in the cluster. If a machine is removed from the cluster, the request doesn't run the risk of hitting a dead server, since all of the machines in the cluster appear to have the same IP address. This address remains the same even if a node in the cluster is down. Moreover, cached DNS entries around the Internet aren't a problem. When a response is returned, the client sees it coming from the hardware load balancer machine. In other words, the client is dealing with a single machine, the hardware load balancer.

Advantages of Hardware Load Balancers

• Server affinity. The hardware load balancer reads the cookies or URL readings on each request made by the client. Based on this information, it can rewrite the header information and send the request to the appropriate node in the cluster, where its session is maintained.

  Hardware load balancers can provide server affinity in HTTP communication, but not through a secure channel, such as HTTPS. In a secure channel, the messages are SSL-encrypted, and this prevents the load balancer from reading the session information.

• High Availability Through Failover. Failover happens when one node in a cluster cannot process a request and redirects it to another. There are two types of failover:

  • Request Level Failover. When one node in a cluster cannot process a request (often because it's down), it passes it along to another node.
  • Transparent Session Failover. When an invocation fails, it's transparently routed to another node in the cluster to complete the execution.

  Hardware load balancers provide request-level failover; when the load balancer detects that a particular node has gone down, it redirects all subsequent requests to that dead node to another active node in the cluster. However, any session information on the dead node will be lost when requests are redirected to a new node.

  Transparent session failover requires execution knowledge for a single process in a node, since the hardware load balancer can only detect network-level problems, not errors. In the execution process of a single node, hardware load balancers do not provide transparent session failover. To achieve transparent session failover, the nodes in the cluster must collaborate among each other and have something like a shared memory area or a common database where all the session data is stored. Therefore, if a node in the cluster has a problem, a session can continue in another node.

• Metrics. Since all requests to a Web application must pass through the load-balancing system, the system can determine the number of active sessions, the number of active sessions connected in any instance, response times, peak load times, the number of sessions during peak load, the number of sessions during minimum load, and more. All this audit information is used to fine tune the entire system for optimal performance.

Disadvantages of Hardware Load Balancers

The drawbacks to the hardware route are the costs, the complexity of setting up, and the vulnerability to a single point of failure. Since all requests pass through a single hardware load balancer, the failure of that piece of hardware sinks the entire site.

Load Balancing HTTPS Requests

As mentioned above, it's difficult to load balance and maintain session information of requests that come in over HTTPS, as they're encrypted. The hardware load balancer cannot redirect requests based on the information in the header, cookies, or URL readings. There are two options to solve this problem:

• Web server proxies
• Hardware SSL decoders.

Implementing Web Server Proxies

A Web server proxy that sits in front of a cluster of Web servers takes all requests and decrypts them. Then it redirects them to the appropriate node, based on header information in the header, cookies, and URL readings.

The advantages of Web server proxies are that they offer a way to get server affinity for SSL-encrypted messages, without any extra hardware. But extensive SSL processing puts an extra load on the proxy.

Apache and Tomcat. In many serving systems, Apache and Tomcat servers work together to handle all HTTP requests. Apache handles the request for static pages (including HTML, JPEG, and GIF files), while Tomcat handles requests for dynamic pages (JSPs or servlets). Tomcat servers can also handle static pages, but in combined systems, they're usually set up to handle dynamic requests.

You can also configure Apache and Tomcat to handle HTTPS requests and to balance loads. To achieve this, you run multiple instances of Tomcat servers on one or more machines. If all of the Tomcat servers are running on one machine, they should be configured to listen on different ports. To implement load balancing, you create a special type of Tomcat instance, called a Tomcat Worker.

As shown in the illustration, the Apache Web server receives HTTP and HTTPS requests from clients. If the request is HTTPS, the Apache Web server decrypts the request and sends it to a Web server adapter, which in turn sends the request to the Tomcat Worker, which contains a load-balancing algorithm. Similar to the Web server proxy, this algorithm balances the load among Tomcat instances.

Hardware SSL Decoder

Finally, we should mention that there are hardware devices capable of decoding SSL requests. A complete description of them is beyond the scope of this article, but briefly, they sit in front of the hardware load balancer, allowing it to decrypt information in cookies, headers and URLs.

These hardware SSL decoders are faster than Web server proxies and are highly scalable. But as with most hardware solutions, they cost more and are complicated to set up and configure.