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:

· 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 .