[ Site Index] [ Linux Index] [ Feedback ]
Why build a server, anyway?
If you work with a computer, the odds are that you work with a computer in a small office. The majority of businesses in the UK have fewer than 20 employees, and if you work for one of them your computing experience will be very different from being in an office with an IT support department.
In a business large enough to have an IT department, you don't have to worry about your computer at all; someone else keeps it running, sees to backups, and ensures that you never run out of disk space on the office file server.
Contrast with the situation in a small business. Where there's only a single computer, things are cut and dried: you plug the printer into your PC, stick a modem in it, and away you go. But businesses experience growing pains as they expand -- and one of the first pinch points is office IT equipment. Small businesses tend to run a mixture of systems. Some small businesses still run Windows 3.11 on their 486's; if it works, why replace it? Others have specific requirements for Macintoshes -- this is common in the print and pre-press business. And there's a chance that if you're reading this article you've already sneaked a Linux system in through the back door.
The big IT question that a small business with a mess of computers faces is: how do I glue everything together?
If you have three or four people in the office who need to send or receive email, you can put a modem in every computer and give everyone a dialup account, but that's a major waste of phone bills and time: a better solution is to set up a gateway machine that sends and receives mail for the whole company while providing a POP3 service over your local area network.
You don't want your uses fighting over the parallel printer cable whenever they have a letter to post, either, but you don't want to buy everyone a separate printer.
Backup is a major risk factor. Something like 70% of small businesses that lose their accounts due to a hard disk failure without backup go bust. You probably also want to make sure that your business stationary and core applications are accessible to everyone via a shared drive (instead of having duplicated, out of date copies floating around on different machines).
The answer to all these problems is to set up a server that provides access to all these services -- file sharing, printer sharing, internet dial-up, backup, and so on. It needs a big hard disk that's visible to everyone else in the office via Windows filesharing, and preferably via NFS (UNIX filesharing) and AppleTalk as well. It needs to be plugged into a printer and configured to feed incoming print jobs to it, and able to accept print jobs from UNIX, Windows, and Macintosh clients. It needs a tape drive so you can keep those critical files backed up, and you need a backup policy to keep everything running safely.
Think it's going to cost you an arm and a leg? Think again -- for well under a thousand pounds you can buy a PC to use as a server, and the software to make it hum is all free. You can even save money by converting an old desktop machine. If you start with a Pentium 166 or higher, with about 64Mb of RAM -- in other words, a vanilla office PC of three years' age -- you can turn it into an office server by spending a little on a new hard disk for it (20Gb disks are down to about 90 pounds now if you shop around), splashing out 200 pounds on a 30Gb tape drive and some tapes, and adding a modem and ethernet card (for 25 pounds each). This isn't going to run a mission-critical e-commerce web site; if all you want to do is serve files, printers, and email out to a couple of dozen PCs you don't need the latest hardware.
In this article, I'll discuss how we set up a server and configure it for the basics -- installing the software, setting up the local area network, adding internet dialup to the server, providing network address translation for a bunch of other machines, providing DNS service for an office, and configuring the server as an email hub and automatic dialup gateway.
Next month, we'll add Windows and Macintosh printer and file sharing capabilities, set up a local web server as an intranet, and discuss ways of automating management of an office full of PCs and Macintoshes.
Requirements for the Server
The main features that distinguish a server from a client PC are storage (servers need a lot more), backup (running an office server without a backup device is like stock car racing without a seat-belt), lack of graphics/video support, and the software.
If you've already got a handful of PC's in a small office, the first prerequisite -- before you install a server -- is to make sure they're all networked. Network cards are a commodity item these days; you can buy a starter kit (containing a hub, a bunch of 10BaseT ethernet cards, and a set of cables), or buy the items separately and plug everything together. Unless you're going to do a lot of video editing work, you can get by with 10 mb/sec cards; a 10mb network only begins to show the strain when you load it down with more than a dozen users or throw lots of huge files about, and for a small business a 100BaseT network is probably overkill.
One important thing to note is that you're going to have to plan a couple of different types of network. There are two levels to the network; the hardware (which cables go where), and the software. The hardware for our small office is simple -- you put a card in every machine, install the drivers (on Windows or MacOS), then run a wire from each card to the hub. In addition, you install a modem in the server (if it's providing dialup internet connectivity).
The software configuration is a bit more complex: you're going to be running NetBEUI services (for Windows), AppleTalk DDP/IP (AppleTalk over TCP/IP) for the Macintoshes, and TCP/IP (for Linux, Internet access, as a carrier layer for AppleTalk, and just about everything else).
We're going to assume that the server is the master computer for the office network. It will act as a router for machines on the network trying to talk to other hosts on the internet.
Your office machines need to connect to the internet from time to time, but you don't want everyone running their own modem-based dialup connection. To make this work, we will configure the server as an IP masquerading proxy. Your workstations will forward all their internet connections to the server. When it's online, it will carry out Network Address Translation and forward their connections to the outside world, (so that the client machines are invisible to the internet at large, but can see out).
Server software
Everything we've listed above can be done with an off-the-shelf copy of Red Hat Linux 6.2 (or 7.0). You can also do it with another distribution, but as Red Hat is very popular and reasonably standard, I'm going to assume you're installing Red Hat Linux on your server (using a copy obtained either direct from Red Hat or on CD from a low-cost UK-based vendor like Cheep Linux).
When you install Red Hat on your server-to-be, the installer will offer you a choice of typical system configurations (with an option to install everything). The main gotcha with the Red Hat 6.2 "typical server" configuration is that it assumes the server will be running without a monitor, and leaves out all the X11 windowing tools and desktops. In a small office, the odds are that the server will need a head: someone may well be using it as their workstation at the same time. This isn't an endorsement of the practice, but it's realism: small businesses often cannot afford to have a spare PC that isn't obviously doing something useful, and usefulness is judged in terms of mouse-clicks. My inclination is therefore to pick the "install everything" option, then customise the installed packages, slicing away those that definitely aren't needed. This list includes (but isn't limited to) games, the Inn news server (not in a small office!), graphics and multimedia tools, PCMCIA support (unless your chosen server is a laptop), office and typesetting tools (unless you are going to use the server as a workstation), and most any workstation tools (if you're confident you can keep the server purely for use as a server).
A Red Hat system is usually configured via the control-panel graphical application. You fire up the control panel by starting a graphical login session as root and typing 'control-panel' at a shell window (or by otherwise running control-panel as root -- there are other ways of doing this). Red Hat began developing this in 1994, but around 1998 incorporated the open source LinuxConf project's configuration management tool; this is the last button on the control panel. Alternatively you can start LinuxConf by typing "linuxconf" at a root shell prompt; it will run in character mode (on the console) or with a graphical front end if you're using X. (You can also get at LinuxConf using a web browser, if you specifically decide to enable remote access -- this is risky, and not recommended.)
Most of what LinuxConf does amounts to editing configuration files, stored under /etc, which configure specific services. Most of the time we'll edit these files directly, but where it's appropriate we'll discuss using LinuxConf.
Before you hook your server up to the network, you need to do a number of things:
Set up networking Your ethernet card should be recognized by Linux automatically; while not all cards are recognized, it's hard to go wrong with a generic NE-2000 clone like a D-Link card, or with anything from 3Com.
We're going to use the IANA reserved 192.168 network for TCP/IP. Specifically, we're going to set the server up with IP address 192.168.1.1 and netmask 255.255.255.0, bound to the ethernet device eth0. the server isn't going to use a gateway: it *is* the gateway for other hosts on the LAN. (We will later set up the office client machines to grab IP addresses in the range 192.168.1.2 - 192.168.1.254.)
You should be prompted for these network details during installation, but if not, you can enter the details by editing two files:
In /etc/sysconfig/network-scripts/ifcfg-eth0, enter:
DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.1.255 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yesAnd in /etc/sysconfig/network, enter:NETWORKING=yes FORWARD_IPV4=yes HOSTNAME=These two files control your ethernet setup so that the eth0 interface will automatically come up when you boot, and be assigned the static IP address 192.168.1.1.Alternatively, in LinuxConf, go to Networking->Client Tasks->Basic host information, and fill out the form; on the hostname tab enter "server", then on the tab for "Adaptor 1" enter the apropriate information. (You can probably leave blank the fields for "primary name + domain", "aliases", "I/O port" and "Irq".)
Edit /etc/inetd.conf This file controls inetd -- the internet service daemon, which starts up a services when someone tries to connect to the server. For example, when you connect using FTP, inetd recognizes the port you are connecting on and spawns an ftp server to cope with your session.
By default, Red Hat's inetd configuration includes a lot of stuff that you do not want to make publicly accessible. In particular, you should disable rcmd, rlogin, rexec, finger, talk (and variants), and nntp (unless you want to run a news server based on Inn).
Alternatively, in LinuxConf go to Networking->Basic Services->Servers; this will alow you to inspect the services currently set up in /etc/inetd.conf, enabling, editing, or disabling them.
Delete links under /etc/rc.d/rc3.d and /etc/rc.d/rc5.d When Linux starts up, it launches a program called init, the parent of all other processes on the system. Init runs in one of several run levels, numbered 1 (single user mode, no networking) through 5 (full networking, multi-user, automatic graphical login). On entering a run level
, init looks in a directory /etc/rc.d/rc .d. This directory can contain shell scripts to start up system services (with a name beginning with a capital-S followed by a priority number: for example, S80sendmail to start sendmail). It can also contain scripts to kill services (with names starting with a K). In general, the scripts are symbolic links (aliases) pointing to a master copy stored in /etc/rc.d/init.d. Your server will run in run level 3 (or level 5 if you are using it as a workstation). You therefore need to look in /etc/rc.d/rc3.d or /etc/rc.d/rc5.d and remove start scripts (with names beginning with an "S") for services you don't want to run. For example, you may want to disable httpd (the Apache web server) or the Linuxconf remote administration system.
(If deleting links to the rc files by hand is a bit daunting, you can use the Red Hat control panel -- log in as root, start a graphical desktop, and type "control-panel", then click on the icon "Runlevel Editor".)
Configure the server for internet dialup via PPP Assuming you're going to use your server to talk to an ISP and send/receive email for people on your local network, you need to set it up for dialup networking. This is a task in its own right; you can find pointers to how to do it in the HOWTOs -- the most recent copies are on the web at Linux.org, or they may also be installed under /usr/doc if you installed the documentation. Red Hat makes it a bit easier by providing the "Network Configuration" control under their Control Panel; run it, click on the "Interfaces" button, then click "Add" (to add a new network interface), and select "PPP". A dialog box will then prompt you for the phone number, login name and password, and whether to use PAP authentication -- a good bet for modem dialup. If you use the "Customize" button you get some more choices (including the ability to let any user start up or shut down the network connection using the "usernet" utility).
As an extra-confusing point, you can configure PPP dialup via LinuxConf, and if you're running KDE you can also configure it via the Kppp dialup networking control tool!
You should test the modem connection to your ISP at this stage, before you've plugged the server into any machines storing confidential information.
Configure the server to reject incoming connections from the outside world over PPP. You don't want the world and his dog to go rooting through your confidential accounts! We're going to use tcpd (the TCP/IP server filtering rules) to ban connections to the server's internet services from non-local machines. Then we're going to use ipchains (the Linux 2.2 network filtering rules) to ban forwarding of incoming connections, and to perform masquerading (Network Address Translation) only for connections from hosts with IP addresses starting with 192.168.1 (i.e. local machines).
Create a file called /etc/hosts.deny containing a single line:
ALL: ALLNow create a file called /etc/hosts.allow containing the following:ALL: LOCAL 192.168.1.These files tell tcpd (launched by inetd as a wrapper around most of the internet daemons listed in /etc/inetd.conf) to reject all connections except those from hosts listed in /etc/hosts.allow -- namely localhost and anything on the 192.168.1 network.(You can find full details of what tcpd does in the manual page for tcpd, and the rule file format is in the man page for hosts_access -- type "man 5 hosts_access" to read it.)
The IPChains configuration is somewhat more confusing. I use a shell script that does the following:
echo -n "Turning on packet filtering:" echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains-restore < /etc/ipchains.rules || exit 1The echo command prints a "1" to /proc/sys/net/ipv4/ip_forward -- this tells a Linux 2.2 kernel to turn on IP packet forwarding. The command ipchains-restore then reads a list of chain rules from the file /etc/ipchains.rules and installs them in the kernel. TCP/IP packets will be filtered through these rules and either rejected or forwarded accordingly. Here's a rudimentary ruleset for masquerading::input ACCEPT :forward DENY :output ACCEPT -A forward -s 192.168.1.0/255.255.255.0 -d 0.0.0.0/0.0.0.0 -j MASQThe "-A" option appends a forwarding rule, for source (-s) address/netmask and destination (-d) address/netmask; packets matching this filter (i.e. originating from the 192.168.1 network and going anywhere) jump (-j) to the MASQ (masquerading) terminal rule, meaning that they will be masqueraded. The default rules specify that input packets are accepted, output packets are accepted, but forwarding packets are denied -- unless they match the special appended forwarding rule for masquerading.(You can find out more about masquerading and IPchains in the man page for ipchains, or in the IPChains HOWTO. IPChains is your first line of defense against hostile packet-based attacks; it's a good idea to read this!) Once your server is hardened (a little) against external attack, by dropping uneccessary services, refusing incoming forwarding requests, and so on, it's time to put it on your network and install the necessary local services -- starting with DNS (so your clients can resolve domain names), and then setting up Samba (Windows filesharing), Netatalk (Appletalk filesharing), and remote backup services.
Setting up the network
The first job facing you as network administrator is to ensure that all the machines on your network can talk to the server via TCP/IP; you'll need this for email and internet access at the least. Your second job is to set up Samba, the Windows file server glue for Linux - and then Netatalk, so the Macs can talk.
Firstly, we need to assign an IP address and name to all machines on the network. To assign names, we'll use the BIND name server (a standard component of Red Hat and all other Linux distributions). You need to go round your office, setting each machine up to use TCP/IP over ethernet. Assign each machine a unique IP address (static, i.e. unchanging); this starts with 192.168.1.2, then 192.168.1.3, and so on. Make a note of the machine that gets each address -- you'll need it when configuring BIND to resolve names in the local domain. Each machine needs a netmask of 255.255.255.0, and should be set up to use 192.168.1.1 (the server) as a gateway.
On Windows 95/98, you do this via the network control panel by adding a new network service to the ethernet card (which should already be configured if you installed its drivers correctly). On MacOS, use the TCP/IP control panel, and remember to use the Networking control panel to specify that you're connecting via ethernet rather than AppleTalk. Linux machines can be configured manually or using the Red Hat control panel - the main issue is that they should have a default route added to their routing table that points to 192.168.1.1.
Setting up DNS and BIND
BIND, the Berkeley Internet Name Daemon, is the standard DNS server. It's a bit of a beast, but Red Hat comes with a pre-canned set of configuration files that set up BIND as a cacheing name server -- all your clients should be set up to use '192.168.1.1' as their default name server, and you should ensure that you've installed the RPM package caching-nameserver-6.2-2 (for Red Hat 6.2 -- similar for Red Hat 7.0) on your server. (You tell a Windows or Mac system what name server to use by entering an IP address in the "name server" field of the network or TCP/IP control panel; you tell a Linux box about it's name server either via the Red Hat control panel or by adding a line to the file /etc/resolv.conf -- type "man 5 resolver" for details).
BIND configuration is a big field -- if you're serious about it, you probably want to buy a copy of "DNS and BIND" (3rd edition, Paul Albitz & Cricket Liu, pub. O'Reilly & Associates, ISBN 1-56592-512-2) which is the definitive book on the topic. Some basic BIND configuration is supported via the LinuxConf control system, but LinuxConf assumes that you already understand what BIND is and how it is configured; all it does is provide forms for editing the underlying configuration file. In this example we'll do the job by hand.
Let's suppose our office has four client machines; three windows boxes (with IP addresses 192.168.1.2 - 192.168.1.4 inclusive) and a Mac (with IP address 192.168.1.5). We want to call these machines win1, win2, win3, and mac1 respectively. We want them to be able to resolve hostnames over the internet, too. To do this, we need to a two BIND configuration files in /var/named; this provides a SOA (Source Of Authority) record for our local domain (call it "office"), and maps IP addresses to names. We then need to edit /etc/named.conf to add a zone entry for "office" so that domain queries for the domain "office" are handled by looking in the file /var/named/office.zone.
In /etc/named.conf, we add a section like this:
zone "office" { type master; file "office.zone"; };This tells BIND to search the file /var/named/office.zone for authoritative details of this domain.We then create the /var/named/office.zone file, looking like this:
office. IN SOA server.office. postmaster.office. ( 2000080300 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; add a record for our name server (NS) IN NS server.office. ; add a record for our mail exchanger (MX) IN MX 1 server.office ; add Address (A) records for our systems server IN A 192.168.1.1 win1 IN A 192.168.1.2 win2 IN A 192.168.1.3 win3 IN A 192.168.1.4 mac1 IN A 192.168.1.5 ; and now some aliases charlie IN CNAME server joe IN CNAME win1 eric IN CNAME win2 feorag IN CNAME mac1This isn't enough to do the job on its own; we need a reverse database so we can do IP-address-to-hostname lookups. This file, called /var/named/192.168.1.zone, maps IP addresses to hostnames by reversing the whole thing:
192.168.1.in-addr.arpa. IN SOA server.office. postmaster.office. ( 2000080300 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; add a record for our name server (NS) 1.168.192.in-addr.arpa. IN NS server.office. ; addresses point to canonical names 1.1.168.192-in-addr.arpa. IN PTR server.office. 2.1.168.192-in-addr.arpa. IN PTR win1.office. 3.1.168.192-in-addr.arpa. IN PTR win2.office. 4.1.168.192-in-addr.arpa. IN PTR win3.office. 5.1.168.192-in-addr.arpa. IN PTR mac1.office.Once we've created these files, it's time to restart the local DNS server. We usually do this via the rc script -- type:/etc/rc.d/init.d/named restartAlternatively, you can bring the system down to run level 1, then back up to run level 3 or 5:/sbin/telinit 1(wait a bit)/sbin/telinit 3HEADING: Setting up a mail server
Red Hat (and indeed most Linux distributions) comes with a preconfigured copy of sendmail, the most commonly used heavy-duty mail server on the internet. The default /etc/sendmail.cf configuration file makes certain assumptions: notably that your Red Hat system has a continuous connection to the internet, and that you're only accepting incoming mail for hosts named in the file /etc/sendmail.cw.
If you plan to use sendmail with a dialup connection, you need to make some minor adjustments to sendmail's configuration. This is almost certainly best done using the LinuxConf administration tool; sendmail's configuration files are notoriously arcane. (If you need to mess with them by hand, you can find a load of documentation in /usr/doc/sendmail-8.9.3; or you can find a detailed explanation in "Sendmail", by Bryan Costales and Eric Allman, pub. O'Reilly and Associates, ISBN 1-56592-222-0).
LinuxConf gives you access to sendmail's most commonly used configuration options. Go to Networking->Server tasks->Mail delivery system. Note that the online help on the "Configure basic information" form tells you most of what you need! In general, if you are connecting via dial-up to an ISP, you will want to fill in the "Mail Gateway" field with the name of your ISP's mail server. You should check the "Enable relay control" to prevent spammers abusing your system, and you should check the "Manual" button under "Process queue every (minutes)" -- otherwise if we have configured automatic dialup via DialD, sendmail will persistently bring up your dialup connection in order to check the mail queue.
Having set sendmail up to queue mail, it's a good idea to ensure that the queue of outgoing mail is flushed whenever you dial in to your internet service provider. Whenever the PPP connection is brought up, the contents of the script /etc/ppp/ip-up.local are executed. So edit this file, and at the end of it add the following line:
/usr/sbin/sendmail -qThis forces sendmail to process its queue and deliver any pending messages, and it will be executed whenever the PPP connection comes up.
Automating dialup to an ISP
If you're using a modem-based dialup for an office, and your server is acting as a router for the other office machines, you may want to configure it to bring up the link automatically whenever there's any traffic. You can do this using DialD, an on-demand network management tool (see http://diald.sourcefourge.net/). Diald creates a proxy network interface. You set up the routing table on your server to forward outgoing packets to the proxy interface; when diald sees packets arriving, it brings up the PPP interface and forwards packets to it. When the link is idle for a set period, diald shuts it down.
This mechanism has some problems; notably, you've got to ensure that daemons running on the Linux box (notably sendmail and bind) don't regularly try to poll other sites for data. (For example, bind has a nasty habit of initiating zone transfers -- pulling in the DNS configuration of other domains that it knows about -- whenever it decides an existing zone is out of date.) DialD is not part of the standard Red Hat system, but can be obtained from their contrib archive (http://contrib.redhat.com/) or the Powertools CD (if you bought the Red Hat Deluxe set). In general, you will need to install Diald itself (typically from the RPM file iald-0.99.1-2.i386.rpm or a more recent version), then the sample diald configuration files in diald-config-0.16.5a-1.i386.rpm. At this point you need to edit /etc/diald/connect; this is the shell script used to bring up the diald connection and connect to your ISP. Finally, diald is started up and shut down by an rc script (/etc/rc.d/init.d/diald); you may want to add a crontab entry to ensure that diald is switched off outside working hours!
Unfortunately there's no fully automated way of configuring and driving diald; to get it working you will need to edit these configuration files. If on-demand dialing isn't essential to your work, you may find it easier to simply use the control panel's networking control, which allows you to bring up or down the line at a mouse-click.
Going further
Next month, we'll add Windows and Macintosh printer and file sharing capabilities, set up a local web server as an intranet, and discuss ways of automating management of an office full of machines. These services use networking protocols other than TCP/IP (the building blocks of the internet), but luckily Linux gives us some good tools for this job -- notably Samba and Netatalk.
[ Site Index] [ Linux Index] [ Feedback ]