Graphical Clients

Graphical Clients

In addition to the basic command line tools, there are also a number of graphical interfaces to the Samba client tools. They all provide similar functionality: the ability to browse a network, browse the computers in a domain, browse the shares on a computer, and browse the files within a share. All of the graphical clients mentioned here use the smbclient program underneath, parse the output, and present it in a easy-to-use manner.

TkSMB ( Figure 5-1 ) is written by Ivan Volosuk, and is available at http://www.rt.mipt.ru/frtk/ivan/TkSmb/ . As the name indicates, it is a Tk-based application.

Figure 5-1. TkSMB.

XSMBrowser ( Figure 5-2 ) is another Tk-based Samba network browser with a number of contributors. It is available at Chad Spencer's Web page at Iowa State University, http://www.public.iastate.edu/~chadspen/ .

Figure 5-2. xSMBrowser.

Finally, SMB2WWW ( Figure 5-3 ) is a Web-based interface for browsing a Windows network. It is distributed as a set of CGI scripts that access smbclient on the back end. It is available from http://samba.anu.edu.au/samba/smb2www/ .

Figure 5-3. SMB2WWW.

In addition, KDE 2.0 and higher has native support for Windows shares in Konqueror, their advanced file/Web browser. You can browse the network, shares, and mount SMB file systems, if the kernel supports it and the user account has appropriate privileges.

 

Replacing Those Workstations

Given all these options, how would you go about replacing your workstation with a Linux box but still be able to get to all your files? Well, a simple answer would be to install KDE 2.0 or higher and use its integrated features. Of course, this answer only shows my bias toward the KDE environment. You can choose whatever desktop environment you like, and use the following Linux analogs of Windows networking operations.

All drives that should be mapped on start-up are placed in /etc/fstab. If you want the user to feel really comfortable, you can mount the SMB shares as if they were drive letters :

# /etc/fstab: static file system information.

#

# <file system> <mount point> <type> <options> <dump> <pass>

/dev/hda1 / ext2 defaults,errors=remount-ro 0 1

//HOME/PCURTIS /F: smbfs username=pcurtis,uid=pcurtis, gid=admin 0 1

//HOME/SHARED /G: smbfs username=pcurtis,uid=pcurtis, gid=admin 0 1

Make sure to create the /F: and /G: directories before you reboot.

Drives can be manually mapped and unmapped by mounting and unmounting an SMB file system. These two scripts will do the trick nicely , but they need to be run as root. If you want to give unprivileged users the ability to run them, you'll have to set up user mount capabilities and change mapped_root to a directory that's writable by the user.

#!/bin/sh

# maps a drive letter

# usage: map F: //HOME/PCURTIS

mapped_root="/mnt/"

drive_dir="$mapped_root";

share=

# Check if this mount point is already used.

if [ "$(mount  grep -c $drive_dir)" -ne 0 ]; then

echo "Drive  is already mapped."

exit

fi

# Make sure the mount point exists!

mkdir -p $drive_dir

# Mount the file system, using the current username from the environment.

mount $share $drive_dir -t smbfs -o username=$USER,uid=$USER, gid=admin  \

echo "Unable to map drive!"

_____________________________________________________________________________________

#!/bin/sh

# unmaps a drive letter

# usage: unmap F:

mapped_root="/mnt/"

drive_dir="$mapped_root";

share=

# Check if the drive is mapped

if [ "$(mount  grep -c $drive_dir)" -eq 0 ]; then

echo "Drive  is not currently mapped."

exit

fi

# Try a simple unmount. This will fail if some process has open files on the share.

umount $drive_dir

if [ $? -ne 0 ]; then

# Prompt the user. This is a "dialog box" of sorts.

echo -n "Someone may be using this drive. Continue (Y/N)? "

read ok

# If the user says Y, try to force the unmount.

if [ "$ok" = "y" -o "$ok" = "Y" ]; then

umount -f $drive_dir

fi

fi

# Finally, verify the mount is really gone

if [ "$(mount  grep -c $drive_dir)" -ne 0 ]; then

echo "Unable to unmap drive , giving up."

exit

fi

# before removing the directory

rmdir $drive_dir

Printers are set up by adding entries to the /etc/printcap file (unless you're using a different print architecture, of course.) The output filter for each printer should be a script like the one shown earlier, but customized to output the right kind of printer-control language. The script doesn't have to use GhostScript; in fact, it can call a vendor-supplied driver instead. This is just what I do with my Lexmark printer.

Then to print a file, you just use this command:

$ lp -d SALESPRINTER sales_report.ps

Simple, eh? But it belies a complex chain of events going on in the background.

I'll quickly summarize this process:

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

·                 lp spools the input file, which is picked up by lpd .

·                 lpd checks the printcap entry for SALESPRINTER and pipes the file to your custom script.

·                 Your script calls GhostScript to do the dirty work of conversion.

·                 Then your script pipes the PCL output to smbprint .

·                 smbprint uses the Samba libraries to send the print job over the network.

·                 Your pages come flying out the laser printer in the sales department.

Problems with any one of these steps can keep things from working. If you do encounter problems, the best way to avoid frustration is to be methodical and verify each step in turn .

 

Similar products