Building an Office Network from Spare Parts
When we moved to Switzerland in 1998, we joined an English church. Being a computer person, I naturally got involved with the church's so-called computer system. The system consisted of a Power Macintosh 7200/90, an Apple LaserWriter 360 printer connected via AppleTalk and a PC with Windows 98. The only way to exchange data between the machines was a “carpet LAN”, and the Mac was the so-called internet machine (only e-mail for the pastor).
During 1999 the office started to expand, and these poor little systems could not cope with the sudden increase in demand. The Internet also started to become a factor as everybody was using e-mail, and a web presence for the church was wanted.
Being a church, there was not a lot of money available to go out and buy everything we needed. We sort of planned what we wanted, and then we called on the congregation for donations of their old computers systems. In this way we got enough desktop computers for each of the administrators and an additional computer that could be used as a server. By continuing to ask for unused computers, we slowly built the office network to where it is today:
1. A main office network with two servers (main and backup), two LAN printers, six workstations and an ADSL internet connection.
2. A dedicated internet network that manages the internet services: Web, e-mail and VPN gateways.
3. A third network for development and testing that also serves as a remote backup facility.
All three of these networks, being 40+ kilometers apart, are connected to each other via the Internet and a VPN network.
Nearly all the computers and printers have been donated (everybody's old junk). They range from 133MHz to 350MHz Pentium machines with a maximum of 64MB RAM and 2-6GB of disk space.
The office network, being the main network, consists of six machines. With the exception of the server, they are all Pentium-based machines. Because the office staff is used to Windows, it was decided to install Windows NT 4.0 on all of their machines. We chose NT 4.0 because it is more stable and secure than Windows 9x, and it is small enough to run on the hardware.
The server machine is an IBM Pentium 133MHz with 16MB RAM and a 10GB disk. Installed on this machine is Slackware 7.1 with a 2.2.14 Linux kernel. Believe it or not, this machine is managing quite fine even though it functions as the mail server, internal web server, and library and address database server. It is also the firewall/gateway to the Internet, originally via a dial-up modem and now via ADSL.
Because the office network never previously had a dedicated internet connection, a separate computer was placed at an ISP to give the church a web presence. It runs the web server software, mail system and VPN dial-up services. The office server periodically connects to this server to download any waiting e-mail and to deliver queued outgoing e-mail. This server is a 266MHz HP machine with 64MB RAM and 15GB disk space. Because of the VPN network, this computer is really redundant, but we decided to keep it so that the mail, Web and other network services are separate from the office server.
The third network is the development and testing network. This consists of a server with the same software setup as the office server. This server is mainly used to test new software components before they are installed in the office. It also serves as a backup server for all the office computers and for the internet computer. This is a 300MHz Siemens machine with 64MB RAM and a 160GB disk.
Not having thousands of Swiss Franks to buy Microsoft software for all the computers, we decided to go for open-source and free software as much as possible, with the exception of the operating systems on the workstations. As mentioned before this is Windows NT 4.0.
The workstations use Netscape 4.76 for web browsing and Netscape's built-in e-mail client. We use Netscape for quite a few reasons, the main ones being:
1. It is more flexible than Microsoft Explorer and Outlook Express.
2. It is not prone to e-mail and HTML viruses.
As an office suite, we started off with StarOffice 5.1 and then moved to StarOffice 5.2. StarOffice works quite well, but we've had the occasional problem with Word documents saved in newly released versions.
The standard Slackware 7.1 distribution is installed on the server, along with some additional software packages:
Samba as a file and print server
Postfix for sending and receiving e-mail
Apache as the internal web server
MySQL for the database server
PHP 4.0 for developing browser interfaces and a standalone PHP executable for the automatic generation of daily and monthly reports.
StarOffice calendar server for meeting and room scheduling.
ipchains for firewalling and NATing to the Internet.
CIPE Version 1.6 for the VPN network.
The internet machine, being the only interface to the World Wide Web, offers the necessary services:
Apache for the web server
sendmail for the mail server
ipchains for firewall capabilities
CIPE 1.6 for the VPN network.
PPTP for the VPN dial-in facility.
Sophos Anti-Virus software (only run on incoming mail)
Being the main development and test environment, it is a near duplicate of the office server. It also has some additional software for developing and testing new software and packages.
So how does all of this connect? All the important information is stored and managed inside the office network. This includes all documents created with StarOffice and the SQL databases on the server. The information inside the SQL databases is edited using Netscape and PHP (compiled as a shared object in Apache). Other than the mail, discussed next, no information ever leaves the office network (except when doing a remote backup).
Mail is received by the internet server at the ISP and then forwarded internally via the VPN to the office server. Here each person uses Netscape to read his/her e-mail. When sending mail out, the mail is first forced to the office server and then relayed via the server at the ISP. It was done this way, 1) because sometimes the ADSL IP address assigned is blacklisted and 2)the ADSL IP is never the same. Using the server at the ISP, with a fixed IP, solves this problem quite nicely.
The internet server also is responsible for accepting and authenticating VPN calls to the server from members of the council that need access to information inside the office network. Here we went for PPTP because it does not need any special software on the client side to work. We also have set up the PPTP in such a way that, depending on the login ID, we can further restrict restrict access using ipchains.
Having all these little network islands, they needed to be connected to each other somehow. Obviously, the Internet is too dangerous and open. At first we used SSH, but this proved to be too cumbersome. We needed a easier way to transfer data around.
We looked at IPSec and it looked great, but it wasn't appropriate because the office and backup networks are both behind intelligent ADSL modems. These modems did automatic NAT and blocking of certain ports from the internet side. In the end we decided for CIPE 1.6.
CIPE is quite small but fairly easy to install and configure. It also has no problem working from behind the automatic NAT ADSL modems.
First we set up the VPN in a star-like manner. The office server and backup server both created a VPN connection to the internet server, which has a fixed IP. When we started to do the backups via these VPN connections, we realized this star-like manner was a limiting factor in the throughput. The internet link to the internet server was doing double duty, first accepting packets from the office network and then sending the same packets out to the backup server.
This problem was solved by creating a third VPN connection directly between the office and the backup network, This resulted into another interesting problem, however, as both the office server and the backup network had dynamic IPs assigned by the ADSL network. This was solved by creating two domains within dyndns.org. In this way one machine has a way to find the IP address of the other server. We still had to write a small ping-like utility to detect IP changes and force CIPE to renegotiate the VPN connection with the new IP addresses.
We have used exclusively free and open-source software in the setup of these networks. This allowed us to configure the software as we wanted it and install it where we wanted it. The following is a list of all the free and/or open-source packages we have installed.
VPN (CIPE and PPTP)
We use CIPE (Linux) to connect together the different networks. To be able to allow users access to the VPN from the Internet, we installed PPTP server software on the Linux gateway. Using PPTP enables us to use standard Windows VPN adapters to control access.
Apache, PHP and MySQL
We have built a customized address and library database system using MySQL. To retrieve and edit the SQL data, we wrote GUIs with PHP to search and edit the data from standard browsers.
We also have built PHP as a standalone program that we use to automatically generate daily, weekly and monthly reports of all data in the database.
StarOffice 5.1 and 5.2
We installed StarOffice 5.1 on each of the PCs in the office network. The main reasons are it was free and it runs on all the platforms we require (Windows, Linux and Solaris). It also has JDBC capabilities that allow us, for example, to access the MySQL database and generate mail-merge type runs to print 500+ envelopes every month.
Samba and SMB
Samba on Linux is used as a file server and a printer server for the Windows machines in the office. Samba affords excellent possibilities to implement access control on shares, but the feature used the most is the ability to force user and access rights when users are connected to a share. This allows us to share files between different users without experiencing read or write access problems.
RSync and SSH
RSync and SSH are used mainly to create mirrored images of all the important data between the different networks, usually during the night. We make heavy use of the rsync protocol to transfer changes between the machines.
E-Fax for Faxing
We also implemented a faxing gateway for outgoing faxes. This gateway makes use of a Samba print queue to submit the job, and then with a browser interface the fax is finally sent to a list of fax numbers. This way of working was once described in Linux Gazette, and we adapted it for our purposes by using e-fax (very small footprint) instead of Hylafax (an overkill in our case).
sendmail and Postfix for Mailing
For our mailing system, we use both sendmail and Postfix. Sendmail is used as MTA on the internet connection, and Postfix is the mail gateway for the office network. We did it this way because sendmail is quite strict in refusing to relay or accept mail from domains outside the VPN network. Postfix, on the other hand, is quite flexible in configuring, and it was easier to set up and configure for the office mail network.
Sendmail is also easier to configure for implementing filter programs during mail reception, typical examples include virus scanners. We also have scripts to check for oversized incoming attachments, to change the resolution of incoming images to a smaller size and so on.
Sophos AntiVirus to Check for E-Mail Viruses
At the moment, we use Sophos AntiVirus software to check each piece of incoming mail for viruses. We have decided to use Sophos because it is available for different platforms like Linux, Windows and Solaris. On Sourceforge we found a package called sophie that uses the Sophos API to build a permanent running virus checker. This makes checking received mail for viruses nearly 100 times faster.
CVS for Tracking HTML Changes and WinCVS to Edit Web Pages
We also make use of CVS to keep track of changes made to the web pages on the internet web server. CVS allows more than one person to update pieces of the web site in a controlled manner, and the CVS comments make it easier to document changes to the web pages.
Since we have Windows users, the CVS command-line tools were a little daunting for them to use. To overcome this fear of the command line, we installed WinCVS on the Windows machines, which provides a GUI interface to CVS. Now users have an easy way to check out files from CVS, make changes and then commit them back when done.
So what have we learned from this exercise? We've learned that by using open-source, it is possible to build office solutions with a minimum investment in software and hardware.
It was interesting and challenging to make all these little open-source projects work together and, at the same time, solve everyday problems encountered by the office staff.
In addition, all the experience and knowledge we built up during the last two years, we could use again in our professional jobs solving customer problems.
We have to thank magazines like Linux Journal and Linux Gazette and sites like Linux Weekly News and SourceForge that always have articles about how people solved problems with open-source projects. From these articles we got quite a few ideas for solving problems and meeting requirements we encountered.
Jos Hartman has been using UNIX since 1989 and Linux since 1995. He is a software developer and writes message-handling software for use in meteorological and aviation areas. In his free time he is train watching, as his hobby is model trains. He currently lives and works in Switzerland with his wife, who is enjoying a permanent holiday.