 |  |
| |
As we showed you in the previous section, it is possible to use the MTools utilities to access a DOS-formatted hard disk partition, and you can even mount a DOS-formatted disk onto the Linux file system with mmount. These methods can be used on a dual-boot system containing a MS-DOS partition, but there's a better way.
As we've explained in section Section 6.1.2 in Chapter 6, partitions on local hard disks are accessed by mounting them onto a directory in the Linux file system. In order to be able to read and write to a specific filesystem, the Linux kernel needs to have support for it.
Linux has filesystem drivers that can read and write files on the traditional FAT filesystem and the newer VFAT filesystem, which was introduced with Windows 95 and supports long filenames. It also can read (and with some caveats) write to the NTFS filesystem of Windows NT/2000/XP.
In Section 7.4 in Chapter 7, you learned how to build your own kernel. In order to be able to access DOS (used by MS-DOS and Windows 3.x) and VFAT (used by Windows 95/98/ME) partitions, you need to enable DOS FAT fs support in the File systems section during kernel configuration. After you say yes to that option, you can choose MSDOS fs support and VFAT (Windows-95) fs support. The first lets you mount FAT partitions and the second lets you mount FAT32 partitions.
If you want to access files on a Windows NT partition that carries an NTFS filesystem, you need another driver. Activate the option NTFS filesystem support during the kernel configuration. This lets you mount NTFS partitions by specifying the file system type ntfs. Note, however, that the current NTFS driver supports just read-only access. There is a version of this driver available that supports writing as well, but at the time of this writing, it was still under development, and not guaranteed to work reliably when writing to the NTFS partition. Read the documentation carefully before installing and using it!
While Linux is running, you can mount a Windows partition like any other type of partition. For example, if the third partition on your first IDE hard disk contains your Windows 98 installation, you can make the files in it accessible with the following command, which must be executed as root:
# mount -t vfat /dev/hda3 /mnt/windows98
The /dev/hda3 argument specifies the disk drive corresponding to the Windows 98 disk, while the /mnt/windows98 argument can be changed to any directory you've created for the purpose of accessing the files. But how do you know that you need — in this case — /dev/hda3 ? If you're familiar with the naming conventions for Linux filesystems, you'll know that hda3 is the third partition on the hard disk that is the master on the primary IDE port. You'll find life easier if you write down the partitions while you are creating them with fdisk, but if you neglected to do that, you can run fdisk again to view the partition table.
The filesystem drivers support a number of options that can be specified with the -o option of the mount command. The mount(8) manual page documents the options that can be used, with sections that explain options specific to the fat and ntfs filesystem types. The section for fat applies to both the msdos and vfat filesystems, and there are two options listed there that are of special interest.
The check option determines whether the kernel should accept filenames that are not permissible on MS-DOS and what it should do with them. This applies only to creating and renaming files. You can specify three values for check: relaxed lets you do just about everything with the filename. If it doesn't fit into the 8.3 convention of MS-DOS files, the filename will be truncated accordingly. normal, the default, will also truncate the filenames as needed, and also removes special characters like * and ? that are not allowed in MS-DOS filenames. Finally, strict forbids both long filenames and the special characters. In order to make Linux more restrictive with respect to filenames on the partition mounted above, the mount command could be used as follows:
# mount -o check=strict -t msdos /dev/sda5 /mnt/dos
This option is used with msdos filesystems only; the restrictions on filename length do not apply to vfat filesystems.
The conv option can be useful, but not as commonly as you might at first think. Windows and Unix systems have different conventions for how a line ending is marked in text files. Windows uses both a carriage return and a linefeed character, while Unix only uses a linefeed. While this does not make the files completely illegible on the other system, it can still be a bother. To tell the kernel to perform the conversion between Windows and Unix text file styles automatically, pass the mount command the option conv, which has three possible values: binary, the default, does not perform any conversion; text converts every file; and auto tries to guess whether the file in question is a text file or a binary file. Auto does this by looking at the filename extension. If this extension is included in the list of "known binary extensions," it is not converted, otherwise it will be converted.
It is not generally advisable to use text, because this will invariable damage any binary files, including graphics files and files written by word processors, spreadsheets, and other programs. Likewise, auto can be dangerous, because the extension-based detection mechanism is not very sophisticated. So we suggest you don't use the conv option, unless you are sure the partition contains only text files. Stick with binary (the default) and convert your files manually on an as-needed basis. See Section 12.2.3 later in this chapter for directions on how to do this.
As with other filesystem types, you can mount MS-DOS and NTFS filesystems automatically at system bootup by placing an entry in your /etc/fstab file. For example, the following line in /etc/fstab mounts a Windows 98 partition onto /win:
/dev/hda1 /win vfat defaults,umask=002,uid=500,gid=500 0 0
When accessing any of the msdos, vfat or ntfs filesystems from Linux, the system must somehow assign Unix permissions and ownerships to the files. By default, ownerships and permissions are determined using the UID and GID, and umasking of the calling process. This works acceptably well when using the mount command from the shell, but when run from the boot scripts, it will assign file ownerships to root, which may not be desired. In the above example, we use the umask option to specify the file and directory creation mask the system will use when creating files and directories in the filesystem. The uid option specifies the owner (as a numeric UID, rather than a text name), and the gid option specifies the group (as a numeric GID). All files in the filesystem will appear on the Linux system as having this owner and group. Since dual-boot systems are generally used as workstations by a single user, you will probably want to set the uid and gid options to the UID and GID of that user's account.
When you have Linux and Windows running on separate computers that are networked, you can share files between the two. The built-in networking support in Windows uses Microsoft's Server Message Block (SMB) protocol, which is also known as Common Internet File System (CIFS) protocol. Linux has support for SMB protocol by way of Samba and the Linux smbfs filesystem.
In this section, we cover sharing in one direction: how to access files on Windows systems from Linux. The next section will show you how to do the reverse, to make selected files on your Linux system available to Windows clients.
The utilities smbmount and smbmnt from the Samba distribution work along with the smbfs filesystem drivers to handle the communication between Linux and Windows, and mount the directory shared by the Windows system onto the Linux file system. In some ways, it is similar to mounting Windows partitions, which we covered in the previous section, and in other ways similar to mounting an NFS filesystem.
This is all done without adding any additional software to Windows, because your Linux system will be accessing the Windows system the same way other Windows systems would. However, it's important that you run only TCP/IP protocol on Windows, and not NetBEUI or Novell (IPX/SPX) protocols. Although it is possible for things to work if NetBEUI and/or IPX/SPX are in use, it is much better to avoid them if possible. There can be name resolution conflicts and other similar problems when more than TCP/IP is in use.
TCP/IP protocol on your Windows system should be configured properly, with an IP address and netmask. Also, the workgroup (or domain) and computer name of the system should be set. A simple test is to try pinging the Windows system from Linux, using its computer name (hostname), in a matter, such as:
$ ping maya PING maya.metran.cx (172.16.1.6) from 172.16.1.3 : 56(84) bytes of data. 64 bytes from maya.metran.cx (172.16.1.6): icmp_seq=2 ttl=128 time=362 usec 64 bytes from maya.metran.cx (172.16.1.6): icmp_seq=3 ttl=128 time=368 usec --- maya.metran.cx ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.344/0.376/0.432/0.038 ms
This shows that Linux is able to contact maya, the Windows server, and that name resolution and basic TCP/IP communication are working.
For now, we will assume that a TCP/IP connection can be established between your Linux and Windows computers, and that there is a directory on the Windows system that is being shared. Detailed instructions on how to configure networking and file sharing on Windows 95/98/Me and Windows NT/2000/XP can be found in Using Samba by Robert Eckstein and David Collier-Brown (O'Reilly).
On the Linux side, the following three steps are required:
Compile support for the smbfs filesystem into your kernel.
Install the Samba utility programs smbmount and smbmnt, and create at least a minimal Samba configuration file.
Mount the shared directory with the mount or smbmount command.
Your Linux distribution may come with smbfs and Samba already installed, but in case it doesn't, let's go through the above steps one at a time. The first one is easy: In the filesystems/Network File Systems section during kernel configuration, select SMB file system support (to mount WfW shares etc.). Compile and install your kernel, or install and load the module.
Next, you will need to install the smbmount and smbmnt utilities from Samba package. You can install Samba according directions in the next section, or if you already have Samba installed on a Linux system, you can simply copy the commands from there. You also may want to copy over some of the other Samba utilities, such as smbclient and testparm.
The smbmount program is meant to be run from the command line, or by mount when used with the -t smbfs option. Either way, smbmount calls smbmnt, which performs the actual mounting operation. While the shared directory is mounted, the smbmount process continues to run, and if you do a ps ax listing, you will see one smbmount process for each mounted share.
The smbmount program reads the Samba configuration file, although it doesn't need to gather much information from it. In fact, you may be able to get by with a configuration file that is completely empty! The important thing is to make sure the configuration file exists in the correct location, or you will get error messages. To find the location of the configuration file, run the testparm program. (If you copied the two utilities from another Linux system, run testparm on that system.) The first line of output identifies the location of the configuration file, as in this example:
$ testparm Load smb config files from /usr/local/samba/lib/smb.conf ... deleted ...
You will learn more about writing the configuration file in the next section, but for our purposes here, it suffices to have the following content:
[global] workgroup = NAME
Simply replace NAME with the name of your workgroup, as it is configured on the Windows systems on your network.
The last thing to do is to mount the shared directory. Using smbmount can be quite easy. The command synopsis is:
smbmount share_name mount_point options
where mount_point specifies a directory just as in the mount command. servicename follows the Windows Universal Naming Convention (UNC) format, except that it replaces the backslashes with slashes. For example, if you want to mount a SMB share from the computer called maya that is exported under the name mydocs onto the directory /windocs, you could use the following command:
# smbmount //maya/mydocs/ /windocs
If a username and/or password is needed to access the share, smbmount will prompt you for them. Now let's consider a more complex example of an smbmount command:
# smbmount //maya/d /maya-d/ \ -o credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700
In this example, we are using the -o option to specify options for mounting the share. Reading from left to right through the option string, we first specify a credentials file, which contains the username and password needed to access the share. This avoids having to enter them at an interactive prompt each time. The format of the credentials file is very simple:
username=USERNAME password=PASSWORD
where USERNAME and PASSWORD are replaced by the username and password needed for authentication with the Windows workgroup server or domain. The uid and gid options specify the owner and group to apply to the files in the share, just as we did when mounting a MS-DOS partition in the previous section. The difference is that here, we are allowed to use either the username and group names or the numeric UID and GID. The fmask and dmask options allow permission masks to be logically ANDed with whatever permissions are allowed by the system serving the share. For further explanation of these options and how to use them, see the smbmount(8) manual page.
One problem with smbmount is that when the attempt to mount a shared directory fails, it does not really tell you what went wrong. To diagnose the problem, try accessing the share with smbclient, which also comes from the Samba package. smbclient lets you list the contents of a shared directory and copy files to and from it, and has the advantage of providing a little more detailed error messages. See the manual page for smbclient(1) for further details.
Once you have succeeded in mounting a shared directory using smbmount, you may want to add an entry in your /etc/fstab file to have the share mounted automatically during system boot. It is a simple matter to reuse the arguments from the above smbmount command to create an /etc/fstab entry such as the following:
//maya/d /maya-d smbfs/ credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700 0 0
Now that you can mount shared Windows directories on your Linux system, we will discuss networking in the other direction — serving files stored on Linux to Windows clients on the network. This also is done using Samba.
Samba can be used in many ways, and is very scalable. You might want to use it just to make files on your Linux system available to a single Windows client (such as when running Windows in a virtual machine environment on a Linux laptop). Or, you can use Samba to implement a reliable and high-performance file and print server for a network containing thousands of Windows clients.
A warning before you plunge into the wonderful world of Samba: the SMB protocol is quite complex, and because Samba has to deal with all those complexities, it provides a huge number of configuration options. In this section, we will show you a simple Samba setup, using as many of the default settings as we can. If you are really serious about supporting a large number of users that use multiple versions of Windows, or using more than Samba's most basic features, you are well advised to read the Samba documentation thoroughly and perhaps even read a good book about Samba, such as O'Reilly's Using Samba.
Setting up Samba involves the following steps:
Compiling and installing Samba, if it is not already present on your system.
Writing the Samba configuration file smb.conf and checking it for correctness.
Starting the two Samba daemons smbd and nmbd.
If you successfully set up your Samba server, it and the directories you share will appear in the browse lists of the Windows clients on your local network — normally accessed by clicking on the Network Neighborhood or My Network Places icon on the Windows desktop. The users on the Windows client systems will be able to read and write files according to your security settings just as they do on their local systems or a Windows server. The Samba server will appear to them as another Windows system on the network, and act almost identically.
There are two ways in which Samba may be installed on a Linux system:
From a binary package, such as Red Hat's RPM (also used with SuSE and some other distributions), or Debian's .deb package formats
By compiling the Samba source distribution
Most Linux distributions include Samba, allowing you to install it simply by choosing an option when installing Linux. If Samba wasn't installed along with the operating system, it's usually a fairly simple matter to install the package later. Either way, the files in the Samba package will usually be installed as follows:
Daemons in /usr/sbin
Command-line utilities in /usr/bin
Configuration files in /etc/samba
Log files in /var/log/samba
There are some variations on this. For example, in older releases, you may find log files in /var/log, and the Samba configuration file in /etc.
If your distribution doesn't have Samba, you can download the source code, and compile and install it yourself. In this case, all of the files that are part of Samba are installed into subdirectories of /usr/local/samba.
Either way, you can take a quick look in the directories just mentioned to see if Samba already exists on your system, and if so, how it was installed.
TIP: If you are not the only system administrator of your Linux system, be careful. Another administrator might have used a source code release to upgrade an earlier version that was installed from a binary package, or vice-versa. In this case, you will find files in both locations, and it may take you a while to determine which installation is active.
If you need to install Samba, you can either use one of the packages created for your distribution, or install from source. Installing a binary release may be convenient, but Samba binary packages available from Linux distributors are usually significantly behind the most recent developments. Even if your Linux system already has Samba installed and running, you might want to upgrade to the latest stable source code release.
To install from source, go to the Samba web site at http://www.samba.org, and click on one of the links for a download site nearest you. This will take you to one of the mirror sites for FTP downloads. The most recent stable source release is contained in the file samba-latest.tar.gz. After downloading this file, unpack it and then read the file docs/htmldocs/UNIX_INSTALL.html from the distribution. This file will give you detailed instructions on how to compile and install Samba. Briefly, you will use the following commands:
$ tar xvfz samba-latest.tar.gz $ cd samba-VERSION $ su Password: # ./configure # make # make install
Make sure to become superuser before running the configure script. Samba is a bit more demanding in this regard than most other Open Source packages you may have installed. After running the above commands, Samba files can be found in the following locations:
Executables in /usr/local/samba/bin
Configuration file in /usr/local/samba/lib
Log files in /usr/local/samba/log
smbpasswd file in /usr/local/samba/private
Manual pages in /usr/local/samba/man
You will need to add the /usr/local/samba/bin directory to your PATH environment variable to be able to run the Samba utility commands without providing a full path. Also, you will need to add the following two lines to your /etc/man.config file to get the man command to find the Samba manual pages:
MANPATH /usr/local/samba/man MANPATH_MAP /usr/local/samba/bin /usr/local/samba/man
The next step is to create a Samba configuration file for your system. Many of the programs in the Samba distribution read the configuration file, and although some of them can get by with minimal information from it (even an empty file), the daemons used for file sharing require that the configuration file be specified in full.
The name and location of the Samba configuration file depends on how Samba was compiled and installed. An easy way to find it is to use the testparm command, as we showed you in the section on mounting shared directories earlier in this chapter. Usually, the file is called smb.conf, and we'll use that name for it from now on.
The format of the smb.conf file is like that of the .ini files used by Windows 3.x: there are entries of the type:
key = value
When working with Samba, you will almost always see the keys referred to as parameters or options. Parameters are put into sections, which are introduced by labels made of the name of the section in square brackets. This section name goes by itself on a line, like this:
[section-name]
Each directory or printer you share is called a share or service in Windows networking terminology. You can specify each service individually using a separate section name, but we'll show you some ways to simplify the configuration file and support many services using just a few sections. One special section called [global] contains parameters that apply as defaults to all services, and parameters that apply to the server in general. While Samba understands literally hundreds of parameters, it is very likely that you will need to use only a few of them, because most have reasonable defaults. If you are curious which parameters are available, or you are looking for a specific parameter, read the manual page for smb.conf(5). But for now, let's get started with the following smb.conf file:
[global] workgroup = METRAN encrypt passwords = yes wins support = yes local master = yes [homes] browsable = no read only = no map archive = no [printers] printable = yes printing = BSD path = /var/tmp [data] path = /export/data read only = no map archive = no
Although this is a very simple configuration, you may find it satisfactory for most purposes. We'll now explain each section in the file in order of appearance, so you can understand what's going on, and make the changes necessary for it to fit your own system. The parts you most likely need to change are emphasized in boldface.
In the [global] section, we are setting parameters that configure Samba on the particular host system. The workgroup parameter defines the workgroup to which the server belongs. You will need to replace METRAN with the name of your workgroup. If your Windows systems already have a workgroup defined, use that workgroup. Or if not, create a new workgroup name here and configure your Windows systems to belong to it. Use a workgroup name other than the Windows default of WORKGROUP, to avoid conflicts with misconfigured or unconfigured systems.
For our server's computer name (also called NetBIOS name), we are taking advantage of Samba's default behavior of using the system's hostname. That is, if the system's fully-qualified domain name is dolphin.example.com, it will be seen from Windows as dolphin. Make sure your system's hostname is set appropriately.
The encrypt passwords parameter tells Samba to expect clients to send passwords in "encrypted" form, rather than plaintext. This is necessary in order for Samba to work with Windows 98, Windows NT Service Pack 3, and later versions. If you are using Samba version 3.0 or later, this line is optional, because newer versions of Samba default to using encrypted passwords.
The wins support parameter tells Samba to function as a WINS server, for resolving computer names into IP addresses. This is optional, but helps to keep your network running efficiently.
The local master parameter is also optional. It enables Samba to function as the master browser on the subnet, keeping the master list of computers acting as SMB servers, and their shared resources. Usually, it is best to let Samba accept this role, rather than let it go to a Windows system.
The rest of the sections in our example smb.conf are all optional, and define the resources Samba offers to the network.
The [homes] share tells Samba to automatically share home directories. When clients connect to the Samba server, Samba looks up the username of the client in the Linux /etc/passwd file, to see if the user has an account on the system. If the account exists, and has a home directory, the home directory is offered to the client as a shared directory. The username will be used as the name of the share (which appears as a folder on a Windows client). For example, if a user diane, who has an account on the Samba host, connects to the Samba server, she will see that it offers her home directory on the Linux system as a shared folder named diane.
The parameters in the [homes] section define how the home directories will be shared. It is necessary to set browsable = no to keep a shared folder named homes from appearing in the browse list. By default, Samba offers shared folders with read-only permissions. Setting read only = no causes the folder and its contents to be offered read/write to the client. Setting permissions like this in a share definition does not change any permissions on the files in the Linux filesystem, but rather acts to apply additional restrictions. A file that has read-only permissions on the server will not become writable from across the network as a result of read only being set to no. Similarly, if a file has read/write permissions on the Linux system, Samba's default of sharing the file read-only applies only to access by Samba's network clients.
Samba has the sometimes difficult job of making a Unix filesystem appear like a Windows filesystem to Windows clients. One of the differences between Windows and Unix filesystems is that Windows uses the archive attribute to tell backup software whether a file has been modified since the previous backup. If the backup software is performing an incremental backup, it backs up only files that have their archive bit set. On Unix, this information is usually inferred from the file's modification timestamp, and there is no direct analog to the archive attribute. Samba mimics the archive attribute using the Unix file's execute bit for owner. This allows Windows backup software to function correctly when used on Samba shares, but has the unfortunate side-effect of making data files look like executables on your Linux system. We set the map archive parameter to no because we expect that you are more interested in having things work right on your Linux system than being able to perform backups using Windows applications.
The [printers] section tells Samba to make printers connected to the Linux system available to network clients. Each section in smb.conf, including this one, that defines a shared printer must have the parameter printable = yes. In order for a printer to be made available, it must have an entry in the Linux system's /etc/printcap file. As explained in Section 8.4 in Chapter 8, the printcap file lists all the printers on your system and how they are accessed. The printer will be visible to users on network clients with the name it is listed by in the printcap file.
If you have already configured a printer for use, it may not work properly when shared over the network. Usually, when configuring a printer on Linux, the print queue is associated with a printer driver that translates data it receives from applications into codes that make sense to the specific printer in use. However, Windows clients have their own printer drivers, and expect the printer on the remote system to accept raw data files that are intended to be used directly by the printer, without any kind of intermediate processing. The solution is to add an additional print queue for your printer (or create one, if you don't already have the printer configured) that passes data directly to the printer. This is sometimes called "raw mode".
The first time the printer is accessed from each Windows client, you will need to install the Windows printer driver on that client. The procedure is the same as when setting up a printer attached directly to the client system. When a document is printed on a Windows client, it is processed by the printer driver, and then sent to Samba. Samba simply adds the file to the printer's print queue, and the Linux system's printing system handles the rest. Historically, most Linux distributions have used BSD-style printing systems, and so we have set printing = BSD to notify Samba that the BSD system is in use. Samba then acts accordingly, issuing the appropriate commands that tell the printing system what to do. More recently, some Linux distributions have used the LPRng printing system or CUPS. If your distribution uses LPRng, set printing = LPRNG. If it uses CUPS, then set printing = CUPS, and also set printcap name = CUPS.
We have set the path parameter to /var/tmp to tell Samba where to temporarily put the binary files it receives from the network client, before they are added to the print system's queue. You may use another directory if you like. The directory must be made world-writable, to allow all clients to access the printer.
The [data] share in our example shows how to share a directory. You can follow this example to add as many shared directories as you want, by using a different section name and value for pat h for each share. The section name is used as the name of the share, which will show up on Windows clients as a folder with that name. As in previous sections, we have used read only = no to allow read/write access to the share, and map archive = no to prevent files from having their execute bits set. The path parameter tells Samba what directory on the Linux system is to be shared. You can share any directory, but make sure it exists and has permissions that correspond to its intended use. For our [data] share, the directory /export/data has read, write and execute permissions set for all of user, group and other, since it is intended as a general-purpose shared directory for everyone to use.
After you are done creating your smb.conf file, run the testparm program, which checks your smb.conf for errors and inconsistencies. If your smb.conf file is correct, testparm should report satisfactory messages, as follows:
$ testparm Load smb config files from /usr/local/samba/lib/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[data]" Loaded services file OK. Press enter to see a dump of your service definitions
If you have made any major errors creating the smb.conf file, you will get error messages mixed in with the output shown. You don't need to see the dump of service definitions at this point, so just type CTRL-C to exit testparm.
Network clients must be authenticated by Samba before they can access shares. The configuration we are using in this example uses Samba's "user-level" security, in which client users are required to provide a username and password that must match those of an account on the Linux host system. The first step in adding a new Samba user is to make sure that the user has a Linux account, and if you have a [homes] share in your smb.conf, that the account has an existing home directory.
In addition, Samba keeps its own password file, which it uses to validate the encrypted passwords that are received from clients. For each Samba user, you must run the smbpasswd command to add a Samba account for that user:
# smbpasswd -a username New SMB password: Retype new SMB password:
Make sure that the username and password you give to smbpasswd are both be the same as those of the user's Linux account. We suggest you start off by adding your own account, which you can use a bit later to test your installation.
The Samba distribution includes two daemon programs, smbd and nmbd, that must both be running in order for Samba to function. Starting the daemons is simple:
# smbd # nmbd
Assuming your smb.conf file is error-free, it is rare for the daemons to fail to run. Still, you might want to run a ps ax command and check that they are in the list of active processes. If not, take a look at the Samba log files, log.smbd and log.nmbd, for error messages. To stop the daemons, you can use the killall command to send them the SIGTERM signal:
# killall -TERM smbd nmbd
Once you feel confident that your configuration is correct, you will probably want the Samba daemons to start up during system boot, along with other system daemons. If you are using a binary release of Samba, there is probably a script provided in the /etc/init.d directory that will start and stop Samba. For example, on Red Hat and SuSE Linux, Samba can be started with the following command:
# /etc/init.d/smb start
The smb script can also be used to stop or restart Samba, by replacing the start argument with stop or restart. The name and location of the script may be different on other distributions. On Debian 3.0, the script is named samba, and on older versions of Red Hat, it is located in /etc/rc.d/init.d.
If you installed from a source code distribution, you will have to write and install your own script that can perform the start and stop functions. (Or maybe you can copy the script from a Samba binary package for your distribution.) When started from a script, smbd and nmbd must be started with the -D option, so that they will detach themselves and run as daemons.
After you have tested the script and you are sure it works, create the appropriate symbolic links in your /etc/rcN.d directories to start Samba in the runlevel you normally run in, and stop Samba when changing to other runlevels.
Now that you have Samba installed, configured, and running, try using the smbclient command to access one of the shared directories:
$ smbclient //localhost/data added interface ip=172.16.1.3 bcast=172.16.1.255 nmask=255.255.255.0 Password: Domain=[METRAN] OS=[Unix] Server=[Samba 2.2.5] smb: \>
At the smb: \> prompt, you can enter any smbclient command. Try the ls command, to list the contents of the directory. Then try the help command, which will show you all of the commands that are available. The smbclient program works very much like ftp, so if you are used to ftp, you will feel right at home. Now exit smbclient (using the quit or exit command), and try some variations. First, use your server's hostname instead of localhost, to check that name resolution is functioning properly. Then try accessing your home directory by using your username instead of data.
And now for the really fun part: go to a Windows system, and log on using your Samba account username and password. (On Windows NT/2000/XP, you will need to add a new user account, using the Samba account's username and password.) Double-click on the Network Neighborhood or My Network Places icon on the desktop. Browse through the network to find your workgroup, and double-click on its icon. You should see an icon for your Samba server in the window that opens. By double-clicking on that icon, you will open a window that shows your home directory, printer, and data shares. Now you can drag and drop files to and from your home directory and data shares, and after installing a printer driver for the shared printer and send Windows print jobs to your Linux printer!
We have only touched the surface of what Samba can do, but this should already give you an impression why Samba — despite not being developed just for Linux — is one of the software packages that have made Linux famous.
One of the most prominent problems when it comes to sharing files between Linux and Windows is that the two systems have different conventions for the line endings in text files. Luckily, there are a few ways to solve this problem:
If you access files on a mounted partition on the same machine, let the kernel convert the files automatically, as described in Section 12.2 earlier in this chapter. Use this with care!
When creating or modifying files on Linux, common editors like Emacs and vi can handle the conversion automatically for you.
There are a number of tools that convert files from one line-ending convention to the other. Some of these tools can also handle other conversion tasks as well.
Use your favorite programming language to write your own conversion utility.
If all you are interested in is converting newline characters, writing programs to perform the conversions is surprisingly simple. To convert from DOS format to Unix format, replace every occurrence of CRLF (\r\f or \r\n) in the file to a newline (\n). To go the other way, convert every newline to a CRLF. For example, we will show you two Perl programs that do the job. The first, which we call d2u, converts from DOS format to Unix format:
#!/usr/bin/perl
while (<STDIN>) { s/\r$//; print }And the following program (which we call u2d) converts from Unix format to DOS format:
#!/usr/bin/perl
while (<STDIN>) { s/$/\r/; print }Both commands read the input file from the standard input, and write the output file to standard output. You can easily modify our examples to accept the input and output file names on the command line. If you are too lazy to write the utilities yourself, you can see if your Linux installation contains the programs dos2unix and unix2dos, which work similarly to our simple d2u and u2d utilities, and also accept filenames on the command line. Another similar pair of utilities is fromdos and todos. If you cannot find any of these, then try the flip command, which is able to translate in both directions.
If you find these simple utilities underpowered, you may want to try recode, a program that can convert just about any text-file standard to any other.
The most simple way to use recode is to specify both the old and the new character sets (encodings of text file conventions) and the file to convert. recode will overwrite the old file with the converted one; it will have the same file name. For example, in order to convert a text file from Windows to Unix, you would enter:
recode ibmpc:latin1 textfile
textfile is then replaced by the converted version. You can probably guess that to convert the same file back to Windows conventions, you would use:
recode latin1:ibmpc textfile
In addition to ibmpc (as used on Windows) and latin1 (as used on Unix), there are other possibilities available, such as latex for the LaTeX style of encoding diacritics (see Chapter 9) and texte for encoding French email messages. You can get the full list by issuing:
recode -l
If you do not like recode 's habit of overwriting your old file with the new one, you can make use of the fact that recode can also read from standard input and write to standard output. To convert dostextfile to unixtextfile without deleting dostextfile, you could do:
recode ibmpc:latin1 < dostextfile > unixtextfile
With the tools just described, you can handle text files quite comfortably, but this is only the beginning. For example, pixel graphics on Windows are usually saved as bmp files. Fortunately, there are a number of tools available that can convert bmp files to graphics file formats, such as png or xpm that are more common on Unix. Among these are the Gimp, which is probably included with your distribution.
Things are less easy when it comes to other file formats like those saved by office productivity programs. While the various incarnations of the doc file format used by Microsoft Word have become a de facto lingua franca for word processor files on Windows, it was until recently almost impossible to read those files on Linux. Fortunately, a number of software packages have appeared that can read (and sometimes even write) .doc files. Among them are the office productivity suite KOffice, the freely available OpenOffice, and the commercial StarOffice 6.0, a close relative to OpenOffice. Be aware, though, that these conversions will never be perfect; it is very likely that you will have to manually edit the files afterwards. Even on Windows, conversions can never be 100% correct; if you try importing a Microsoft Word file into WordPerfect (or vice versa), you will see what we mean.
In general, the more common a file format is on Windows, the more likely it is that Linux developers will provide a means to read or even write it. Another approach might be to switch to open file formats, such as Rich Text Format (RTF) or Extensible Markup Language (XML), when creating documents on Windows. In the age of the Internet, where information is supposed to float freely, closed, undocumented file formats are an anachronism.
|  | |
| 12. Windows Compatibility and Samba |  | 12.3. Running MS-DOS and Windows Applications on Linux |
Copyright © 2003 O'Reilly & Associates. All rights reserved.