Known as Samba, the SMB service ships free with RHL and with most Linux distributions. Firing it up using the services module then allows you to get stuck into configuring the system. The first task is to create users in Samba, which then can then be mapped onto Linux users -- there must be an equivalent Linux user account for each Samba account. You can then create Samba-specific access permissions on top of the Linux privileges.
It's convenient for each user to have a private area and a public share for all. If you're having problems creating the right access privileges in the file system, use the chmod command. This lucid description provides a good handholding guide. Note that our shares were created on a separate mechanism from the OS, which simplifies backing up.
Once that's done, Samba's graphical interface makes configuration pretty straightforward. If you want to fine-tune your access permissions though, you're best advised to edit the smb.conf file (/etc/samba/smb.conf). For instance, you can restrict access to IP addresses in your local subnet and, better still, ensure that the shares for those in one department are completely invisible to those in another. Separating out the accounts workers' shares would be a typical example.
You can also fine-tune your password strategy -- whether or not to use encryption for example, since Windows 98 machines and below don't encrypt:
encrypt passwords = yes
You can also set password complexity:
password level = 8
decide whether the machine should be the browser master:
local master = yes
and select which machine (if any) stores passwords for security purposes:
password server = betelgeuse [password server] yes
Samba is fairly simple to set up and, once up and running, can usually be left to its own devices except when users change.
Firewall
Although you can scour the Internet, or even download packages such as Smoothwall that will convert your machine into a dedicated high-security firewall (dedicated means it will wipe any data already present), the built-in firewall, ipchains, is plenty good enough for our purposes. Unfortunately, it can also be hard to get to grips with.
Help is at hand. There's plenty of good documentation on the Web but, essentially, the ipchains tool tell the kernel what packets to filter by inserting and deleting rules from the Linux kernel's packet filtering section.
The way it works is that packets fall through a list or chain of rules, each of which can affect its fate depending on what type of packet it is. There are three lists -- input, output and forward. When a packet comes in, the kernel uses the input chain to decide its fate. If it survives, the kernel decides where to send the packet next. If it's destined for another machine, it consults the forward chain. Finally, just before a packet is to go out, the kernel consults the output chain. If a packet falls through all the filters and has not yet been passed on or rejected, a well-configured firewall will block or reject it.
So the first task is to work out which traffic you plan to allow, and which to block. A simple firewall will allow access to external Web sites (http), to email servers (smtp), and to domain name servers (DNS) and not much else.
You can set up the system to allow only certain types of traffic through the system. For example, we used the security level applet to allow ftp (for file access), ssh (for remote control) and DHCP (for automatic IP addressing) traffic but no others. The command ipchains -list will show the rules that are currently configured and, with a little study of the output, you'll be able to see what task each rule or chain is doing.
A detailed description of how to create a firewall and set it up in the dual-homed configuration described would, on its own, double the size of this feature. Although the task is not particularly difficult, explanations and caveats take time so, instead, we suggest you read the Linux ipchain how-to and this firewall and proxy server how-to instead.
Summary
Although it's not the latest version of the OS, once all the available updates have been installed, the combination of Red Hat and the KDE 3.2 desktop has proved very stable. We found setting up a server to perform basic tasks to be fairly simple, although you have to be prepared to read a lot of online documentation. As ever, common sense and a willingness to google for answers always yields results.
Linux is ideal for the kinds of tasks we've described, and the experience you gain will reap dividends in the future. What's more, the availability and enthusiasm of the open source community for answering questions, plus the fact that the software is free, neatly blend the economic and personal justification for the task.
Just a quick correction - if you're using a 2.4.x kernel (as in this article), you'll be using 'iptables' for firewall config rather than the older 'ipchains'. Hence I suggest you read the iptables howto rather than the ipchains one, as that won't get you far :)