Installing a small office server running Linux - part 2

[ Site Index] [ Linux Index] [ Feedback ]

Last month, we discussed Linux as a small office server, and took a brief look at how to configure a Linux system to provide dialup routing and internet services to a small office network. This month, we're going to see how a Linux server can provide Windows and Macintosh printer and file sharing capabilities, up a local web server as an intranet, and discuss ways of automating management of an office full of PCs and Macintoshes.


If you run a network of Windows machines, probably the most important Linux application in your repertoire is Samba.

Windows networking services are layered over a procol called NetBIOS, that, like TCP/IP (the core internet protocols) carries other services on top of it. (NetBIOS itself runs over ethernet, in the form of NetBEUI -- NetBIOS Extended User Interface.) Samba started life in 1991 when Andrew Tridgell, an Australian programmer, found himself needing to share files between a PC and a Sun workstation; he reverse-engineered the packet format for NetBIOS and SMB, the Windows file sharing protocol that runs over it, and a port to Linux followed in 1993. Since then, Samba (as his software is called) has become critically important to Linux in the workplace.

Samba provides a free SMB and CIFS client and server for UNIX and Linux. It includes:

Samba isn't the only tool available on Linux for talking to PCs -- an important extra is smbfs, a Linux-only filesystem that lets a Linux box mount remote SMB filesystems from PCs (This is supported as standard on Linux 2.0 and later kernels).

You can use Samba to make your office run more smoothly by sharing a single laser printer and by providing a shared file server for all your PCs to save office documents on. (We'll look at each of these in turn.)

Samba consists of server daemons configured from a single file called smb.conf. The daemons are smbd (provides file and print services to SMB clients), and nmbd (provides NetBIOS nameserving and browsing support).

In addition, a number of tools are provided: smbclient lets you use an ftp-like interface to poke at SMB shares on other servers, smbstatus lets you examine the state of your smbd server, nmblookup lets you make NetBIOS name queries, and testparm and testprns let you test the smb.conf for for correctness and test the printers defined in the /etc/printcap file. All of these are command-line programs, but if you've installed X11 on your Linux system you can administer Samba via a graphical setup tool called KSamba. This includes a wizard to make setup for a small office easier, and is undoubtedly the easiest way to configure Samba; if you're running a small office network it's probably worth getting X11 on your server just for this time-saver.

Samba can be configured via linuxconf; go to Networking -> Server Tasks -> Samba File Server and fill out the forms. Note that you should read the help screen here; most of the entries are straightforward but not self-explanatory. One point to note is that if you choose to synchronise user account names and passwords between SMB and Linux, a user's password change on their Windows machine will update their password on the Linux system. On the other hand, if you do this you should under no circumstances allow null passwords: if you do so, you compromise the security of the Linux fileserver.

If we're configuring a small office network on the 192.168.0 network, we should go to Linuxconf's Access pane and enter " 192.168.0." in the "Allow hosts" field (note the trailing period, but miss out the quotes!). This will restrict access to only machines on that local, private network (i.e. everyone is denied access unless their IP address begins with 192.168.1). It is also useful to check "Preferred Master", "Domain Master", and "Enable samba as a WINS server" in the "Network" pane on Linuxconf, telling the Samba server to act as the master browser and server for this workgroup. This defaults to "off" because nobody wants random badly configured Samba servers grabbing control of corporate networks, but it makes sense to switch it on for our office server.

Having created or modified the /etc/smb.conf file (via Linuxconf or Ksamba) you will need to restart the Samba servers:

   /etc/rc.d/init.d/smb restart
If you want to edit the /etc/smb.conf file by hand, you can do so: it's copiously commented, and the man page contains extensive details of its format:
   man 5 smb.conf
However, it should be noted that smb.conf was originally designed to be edited via a tool called swat, the Samba Web Administrator's Tool. Edit /etc/inetd.conf and add a line looking like this:
   swat      stream  tcp     nowait.400      root /usr/sbin/swat swat
Then restart inetd (via /etc/rc.d/init.d/inetd restart), and point your web browser at http://localhost:901/. This gets you into the standard view of swat's user interface; if you need to dink with the advanced tuning features of Samba, click on the "Globals" icon, then select "Advanced view". Alternatively, to see what Samba is doing, click on the "Printers" icon.


Samba can take print requests from a Windows client and forward them to a Linux printer queue. Linux is descended from UNIX, which had its origins in a typesetting/printing service at AT&T; as a result, before you can print from a Windows PC to a printer owned by your Linux server you need to set up Linux's print service. (Samba can then automatically pick this up and make these printers available to Windows clients -- click on the "Printers" icon and a popup list of printers known to the Linux print service will show up, flagged with an asterisk in front of their name, and you can choose to make them browsable or accept guest or other users.)

Linux uses a print spooler daemon called lpd (line printer daemon) to control printing. The lpd system is compatible with the original BSD UNIX print daemon; it reads configuration details from a file called /etc/printcap, then listens on a network socket for print requests. When a print request comes in it spools the file in a spooling area and enters the job in a queue. Jobs are despatched to their designated printers as the printer becomes available; lpd can cope with an arbitrary number of printers, accessed via serial or parallel ports and over a TCP/IP network. (It can also forward print jobs to an lpd daemon running on a different UNIX system.) You can do a number of things to lpd via the lpc (line printer control) command, including pausing queues; you can see what's in the print queue and remove files from it using lpq and lprm respectively, and add a file to a queue by piping it into lpr.

lpd was originally designed to work with big line printers -- machines that weren't very flexible in producing typeset output. Today, it has been adapted to work with printers that can produce bitmap images of typeset text. Behind the scenes, lpd invokes a little magic to ensure that your files are pre-processed into a format that your printer can put onto paper: for example, you can send postscript or plain text to a properly-configured lpd queue and the results will both be printed correctly: on a postscript printer the text will be postscriptified before printing, and on a non- postscript printer the Ghostscript postscript interpreter will be run locally to build an image of the page for printing.

On a Red Hat system, the easiest way to configure your printing system is via the control panel. Open up a window and become root, then type "control-panel". Click on the printer icon, then press "Add" to add a new printer queue to the lpd system. A printer queue spools up and sends files to a given printer; it is identified by name. If you use lpr to print a file without specifying a queue it defaults to the standard queue named "lp"; you can specify other queues by using the command line options -Pqueuename. For example, to send a file to a queue called "remote1", you'd do something like this on the command line:

  lpr -Premote1 
In the control panel, we can set up a queue called "remote1" by pressing
the "Add" button; this has options for local printers, remote UNIX queues,
a Windows printer connected via SMB, a NetWare printer, or to an ethernet-
connected printer (the "Direct to Port" option). We almost certainly
want to select "Local" printer. Once we get to the "Edit local printer
entry" dialogue the important item is "Input Filter" -- this brings up
a list of filters we can automatically apply to inputs to transform them
into something appropriate for this printer. (This replaces the printer
drivers commonly used on Windows or Macintosh systems.)

Once we've set up a new queue, it's a good idea to select "lpd -> Restart" from the menus, then go to the "Tests" menu and verify that the new printer works; this sends a test page through the lpd print queue and should (if all goes well) result in ink on paper.

Having configured the lpd print spooler, we can now go back to Samba and, via the web-based SWAT interface or Linuxconf, tell it about the printer we've just added. (NB: it's a good idea not to provide guest access to printers unless you're sure nobody is ever going to get into your network and have fun flooding your office with paper at the push of a button.)

File sharing

With Samba running, we can add file shares from the Linux box via linuxconf, SWAT, or by editing /etc/smb.conf. Here's an example block in /etc/smb.conf showing a share called tmp, that exports the /tmp (temporary file) directory of the server to just about everybody, and makes it writable:

      path = /tmp
      public = yes
      available = yes
      browseable = yes
      guest only = yes
      writable = yes
      only user = no
Before you can restart Samba, it helps to have added some users to /etc/smbpasswd, the password file on your server; for example, to add a user entry for "charlie", as root type:
   smbpasswd charlie
And enter the password twice. Once you've done this and restarted Samba, you can test that Samba is working and that the user can see this share by using smbclient to log in and look around using it's ftp-like interface:
  [root@clueless charlie]# smbclient //clueless/tmp  -U charlie
  added interface ip= bcast= nmask=
  Domain=[ANTIPOPE] OS=[Unix] Server=[Samba 2.0.6]
  smb: \> dir                              26596  Wed Aug 30 16:06:59 2000
    .gnome                             DH        0  Wed Aug 16 22:44:23 2000
    .gnome_private                     DH        0  Wed Aug 16 22:44:23 2000

		61766 blocks of size 131072. 36583 blocks available

  smb: \> ?
  ls             dir            du             lcd            cd             
  pwd            get            mget           put            mput           
  rename         more           mask           del            open           
  rm             mkdir          md             rmdir          rd             
  prompt         recurse        translate      lowercase      print          
  printmode      queue          cancel         quit           q              
  exit           newer          archive        tar            blocksize      
  tarmode        setmode        help           ?              !              
  smb: \>

(The machine name "clueless" should also be set up as the NetBIOS name of this machine: //clueless/tmp means 'mount the share "tmp" off the machine "clueless"'.)

If editing smb.conf by hand strikes you as painful, in Linuxconf go to "Samba File Server" -> "Disk Shares", click the "Add" button, and list the directory to export, users who can read/write it, and hosts from which they can connect.

(For the small office situation you probably want to set up individual shares for each user's own files, and a collective share on top of a directory called something like "/home/workgroup" where all their files will reside. You may also want a read-only share called something like "/home/stationary" where document templates and similar files can be placed.)

User accounts

If you've set up Samba to synchronize password changes with the Linux password system, users who change their password on their Windows client will automatically update their password on the Linux box. But how does that get set up in the first place?

If you're working in an office with a few other staff, you will want to set up accounts for them on the server. There's effectively two stages to this, at first: create a Linux user account, and add a password entry to the /etc/smbpasswd file.

To add a Linux user account, you can run Linuxconf (of course), or you can use the command-line program adduser:

  /usr/sbin/adduser -u 101 -g users -d /home/charlie -s /bin/bash charlie
This will create a user called "charlie" with User ID 101, membership of the Group "users", home directory /home/charlie, and login shell /bin/bash. The home directory will automatically be created with some skeleton configuration files in it.

Next, use passwd to set a password for the new user account:

  passwd charlie
(You'll need to type the password twice. Note that passwords should be at least eight characters long and contain a mixture of upper and lowercase characters, numbers and punctuation, and should not be dictionary words; break any of these rules and your system will be vulnerable to password cracking tools that effectively throw a dictionary at you.)

Now use smbpasswd to create a new user entry and password for the user in /etc/smbpasswd:

  smbpasswd -a charlie
If someone annoys you (or leaves the company) you can disable their SMB password:
  smbpasswd -d charlie
And remove their Linux user account:
  /usr/sbin/userdel -r charlie
(The -r flag tells userdel to also remove files in the home directory. Otherwise these will be left alone -- probably a good thing, in a corporate situation, until you're sure you won't need any of their files again.)

Disk quotas

One useful feature of Linux (that Windows 2000 has only recently acquired) is the ability to set a maximum quota of disk space that a given user or group of users can occupy. This can be specified with a soft limit and a hard limit, for both disk blocks and inodes (filenames) used. A soft limit indicates the maximum amount of disk usage a user has on a partition -- after crossing the soft limit, warning messages are automatically issued. A hard limit specifies an absolute limit on disk usage beyond which the user cannot go. A grace period can be specified; this is a time limit before the soft limit is enforced for a filesystem with quotas enabled. If you go over the soft limit but have a 24 hour grace period, you'll automatically see a warning, but the limit won't be enforced until you've been over the limit for a day.

You can switch on disk quotas on a per-filesystem basis: in Linuxconf, go to "File systems" -> "Access local drive", select the filesystem you want to set up quotas on, and under the "options" tab check "user quota enabled" and/or "group quota enabled". Alternatively, edit /etc/fstab and add the option "usrquota" (for per-user quotas; "grpquota" for per-group quotas) under the options for the designated filesystem. Switch on quotas using quotaon after mounting the filesystems:

  /sbin/quotaon -avug
(And switch it off using /sbin/quotaoff if you feel pinched.)

Before quotas will do much, create two files in the quota-controlled partition: quota.user and These should be owned by root and read/writable by root but nobody else.

To apply quotas, use setquota:

 /usr/sbin/setquota charlie /dev/hda3 500000 1000000 100000 500000
(User charlie has a soft quota on /dev/hda3 of 500,000 1Kb blocks, and a hard quota of 1M blocks; he also has a soft quota of 100,000 inodes and a hard quota of 0.5M.)

You can scan a partition for quota usage using quotacheck:

  /sbin/quotacheck -avug
This updates the quota record. You can then view a summary report of usage using repquota:
 # repquota -a
                                  Block limits               File limits
          User            used    soft    hard  grace    used  soft  hard  grace          root      --  175419       0       0          14679     0     0
          bin       --   18000       0       0            735     0     0
          uucp      --     729       0       0             23     0     0
          man       --      57       0       0             10     0     0
          user1     --   13046   15360   19200            806  1500  2250
          user2     --    2838    5120    6400            377  1000  1500
Setting disk quotas is probably not incredibly useful in this age of affordable 70Gb hard disks, except in one situation -- where you have some sort of automatic process that may generate huge logfiles or amounts of data, filling up a disk shared with some other (important) automatic process, like your company's stock inventory database.


Not everyone uses Windows in their office; many design shops are Mac- only houses. But a Mac-based advertising agency is just as good a bet for a Linux server as an office running Windows, thanks to Netatalk -- an implementation of the AppleTalk Protocol Suite containing support for EtherTalk Phase I and II, DDP, RTMP, NBP, ZIP, AEP, ATP, PAP, ASP, and AFP (phew!). The important bits to note here are EtherTalk, which tunnels AppleTalk packets over ethernet, ZIP and NBP (the AppleTalk zone information and name binding protocols, which let hosts find each other), and AFP (the AppleTalk Filing Protocol).

Using Netatalk you can make your Linux server act as a file server for Macintoshes (exporting volumes that show up on the client desktops), and as a print server.

First, the bad news: Netatalk doesn't come as standard with Red Hat (or indeed with most distributions), you can't configure it via Linuxconf or the control panel, and you'll need a kernel with support for AppleTalk compiled in. Now the good news: stock Red Hat kernels support AppleTalk -- if you're not sure, look in /lib/modules//ipv4/, and see if "appletalk.o" is present. (This is the kernel module that provides AppleTalk; load it by, as root, running insmod:

  /sbin/insmod /lib/modules/2.2.14-5.0/misc/appletalk.o
Insmod installs kernel modules -- drivers for interfaces or peripherals that are compiled separately from the main kernel but run as kernel threads when loaded. You can list your current loaded modules using lsmod:

  Module                  Size  Used by
  appletalk              17472   0  (unused)
  ppp                    19500   0  (autoclean) (unused)
  slhc                    4312   0  (autoclean) [ppp]
  autofs                  9092   1  (autoclean)
  lockd                  30344   1  (autoclean)
  sunrpc                 52132   1  (autoclean) [lockd]
  ne2k-pci                4684   1  (autoclean)
  8390                    6136   0  (autoclean) [ne2k-pci]
  es1371                 25092   2 
  soundcore               2628   4  [es1371]

Probably the best way to get Netatalk installed on your machine if you're using Red Hat is with rpmfind: type "rpmfind netatalk" in a root console while connected to the net. Failing that, you can find Netatalk's home page on the web.

Installation is described in a HOWTO. The main issues to remember are:

  • Netatalk defines some additional TCP services, which are listed in the services.atalk file distributed with Netatalk; these need to be appended to your /etc/services file.
  • Like Samba, Netatalk is started from a script -- /etc/rc.d/init.d/atalkd -- which fires up two daemons; papd and afpd. papd is the AppleTalk print server daemon, and afpd is the Appletalk Filing Protocol daemon (used for serving up files to Mac clients).
  • To configure your Linux server as an AppleTalk file server, you need to get the netatalk daemons installed, then create the apropriate /etc/atalk/AppleVolumes file. Mac users are offered volumes defined in /etc/atalk/AppleVolumes.system, and one of /etc/atalk/AppleVolumes.default, $HOME/AppleVolumes, or $HOME/.AppleVolumes. These files specify volumes to mount, and file system extension mappings. Macintoshes don't identify the type of a file by its suffix; they use a type/creator attribute mechanism, and unknown files will be seen by a mac client with type/creator "????/UNIX", which won't make them very useful.

The file sharing daemon is controlled by a file called /etc/atalk/afpd.conf; this is used for specifying various networking options, allows you to run a server on a non-standard port, and so on. The simplest case, however, is to ignore this file completely -- the standard RPM-ified distribution downloadable from Red Hat's Powertools archive should run happily on a local (192.168.1) network without fancy setup.

The same goes for papd, the printer sharing daemon; although an /etc/atalk/papd.conf file exists, it's not typically needed unless you specifically need to load a PPD (postscript printer description) file when printing. In this instance, an example skeleton papd.conf file is provided; it's main job is to tell papd to forward print jobs to an lpd printer queue (as described above), but to prepend a PPD file (which you need to plonk somewhere on your Linux server) and to print under a specified username. If you have lpd set up papd should work more or less transparently.

If you want to make a directory like /home/office accessible, the easiest way is to specify it in /etc/atalk/AppleVolumes.default:

/home/office	access=charlie
/home/office	access=@users
(@users is a group specified in the Linux systems' /etc/group file; any user with membership of this group can mount the specified AppleTalk volume.)

One warning about AppleVolumes.default; be careful if you edit it using the vi editor. vi's inimitable (if somewhat crude) display indicates the bottom of a text file by planting a tilde "~" character in the leftmost column. AppleVolumes.default plants a real tilde in the left column of the last line in the file! This is a default setting that ensures that users with no AppleVolumes file in their home directory get served their home directory by default if they log in. You may or may not want to enable this feature -- but you certainly don't want to switch it off unintentionally.

AppleVolumes.system contains a list of file suffix and type/creator mappings; this essentially tells the AppleTalk file server what type/creator to stick on a file with a given suffix (determining the icon the Mac desktop shows it with, and the application that opens it). The Netatalk distribution includes a MacPerl script that scans a file mapping list from a Macintosh and spits it out in a form suitable for appending to AppleVolumes.system.

Once Netatalk is installed (preferably using the RPM package!), and once you've added a volume for export to AppleVolumes.default, just start it up via the rc script:

  /etc/rc.d/init.d/atalkd start
Then, on a Mac, bring up the Chooser. Click on an Apple file share, and enter the TCP/IP address of your file server (or its name, if you've configured Open Transport to use the Linux system as a DNS server). A choice of volumes will show up, and once you've entered your username and password the selected one will show up on your desktop as a remote shared drive.


The final vital element of your Linux office server is backup support for the essential company data that's going to be saved on this machine. As something like 80% of small businesses that lose their accounting data due to a computer failure go bust, you ought to consider this a maximum priority -- don't be tempted to skimp on it unless you want to explain how you lost your job to the dole office!

Your best move is to fit a tape streamer, buy a box of tapes, and develop a disaster-recovery plan.

For a tape streamer, 20-30Gb units are fairly cheap these days; expect to pay around 100-200 pounds, plus another 10-20 pounds per tape. It's a good idea to buy a SCSI-II tape drive and fit a cheap SCSI controller such as an Adaptec 2940-UW to drive it; this will keep the tape fed without stealing an interrupt from your IDE hard drive, and it won't slow up disk access any. (If you use an ATAPI tape drive hanging off an IDE controller that's already talking to one or more disks, expect things to go a bit slower.) Assume that 50% of tapes will turn out to be defective when the bovine excrement intersects the ventilation device; while you can make do by rotating three tapes, it would be reckless to bet your business on it.

As far as disaster planning goes, it pays to be paranoid. For example, assume that when the worst happens, it won't be a simple software crash -- assume someone is going to physically steal or smash up the computer and any tapes they can get their hands on. That way, your plan should take into account the need to source an entire new PC (and backup tape drive!) before you can resume operations. Placing the computer on your business insurance is mandatory; so is having a spare tape drive and controller card sitting in bubble-wrap, preferably in another building (so that if your office is hit by a meteor or an earthquake you can rebuild your file server). Obviously there's no point taking it to extremes -- but if you don't anticipate common threats (like burglars) you're putting your business at risk.

Another element of your disaster recovery plan should be a checklist of how to duplicate your server's configuration -- a list of what software packages were installed and in what order, and the precise changes you made to configuration files that control them.

From here on, procedures are king. Data doesn't magically copy itself to tape; you need to set up a backup procedure. There's an extensive HOWTO document which rewards study, but in general the crown jewels are going to be the contents of the /etc (where most of the configuration files live), the contents of /var (where temporary files and logfiles reside), and any and all directories that are used as Windows or Mac shareable volumes -- typically everything under /home. If you don't have more data than will fit on a single tape, you can get away with running a full backup every night: use cron, the timed execution scheduler, to tell tar (the tape archiver) or cpio or another backup utility to dump these directories to tape at three in the morning. It'll take a couple of hours, but if nobody is using the system the files will be reasonably stable and nobody will notice the server's performance going slow.

(You can find details of the command line options for tar, the tape archiver, in the HOWTO referenced above; note that you don't normally use it interactively for backup, but via a backup script. You can find some examples of those in the HOWTO, as well.)

Each morning, have someone take the tape out, check the logfile (which you want to have mailed to them) to ensure that there were no write errors, write the date of the backup in a logbook, and move the tape to a secure store (such as a fireproof safe). They should then stick the next tape in the drive (you've numbered them so that they can be rotated in series, rather than simply reusing one tape until it delaminates or scrubs the tape drive heads clean).

In event that disaster strikes, your job is to acquire a new PC, fit the spare tape drive, then work your way through the disaster recovery plan as fast as possible -- installing the same packages, upgrading additional bits and pieces, applying the same edits to the configuration files, and restoring the data. Things will go a lot more smoothly if you have a copy of the vital configuration files from /etc on tape; and who knows? You might even avoid that interview with the dole office.

[ Site Index] [ Linux Index] [ Feedback ]