Windows LAN server HOW-TO

1.3

2004-10-06

Revision History
Revision 1.32004-10-06RC
Minor spelling & grammatical errors corrected. Minor text changes.
Revision 1.22003-03-19RC
Authors contact details amended, spelling errors corrected. Minor text changes. Further Comments section added. Version amended to suit CVS.
Revision 0.12000-09-21RC
Original document submission.

Abstract

This document is intended to assist those who wish to consider Linux as a server within an office environment which has PC's primarily running Microsoft Windows 9x.


Table of Contents

Dedication
Introduction
The Scenario
The Options
The Linux Option
Research is the key
The tools
Convincing the boss
Which distribution?
Installation
RedHat
Samba
E-mail
Faxing
Is that it?
Conclusion
References
Further Comments to v.1.2+

This document is dedicated firstly to Jesus Christ, my Lord and Saviour, thanks to Him I have the ability to do this. It is secondarily dedicated to the authors of the various utilities and documents referred to here. Thanks to them I have the tools to do it.

Linux (or more accurately GNU/Linux) is gaining increasing popularity within the workplace. Primarily it is deployed within the Internet marketplace at server level but it is beginning to make in roads into other areas such as internal network servers and desktop workstations. With this in mind and for reasons given below, my company decided to deploy a Linux based LAN server into our Windows9x based network. I started this project with basic knowledge of Linux and some knowledge of Unix. During the course of the project it occurred to me that some sort of document describing the tasks involved would be helpful. I could not find such a document and hence wrote this one.

What you will not find here is a repeat of installation and configuration documentation for the various tools and utilities used. I see no reason to repeat that but have instead opted to include problems encountered whilst installing or configuring these and workarounds/solutions for those situations.

It will probably be helpful to give a short background of the environment in which the new server will be deployed.

Some 35 PC's are linked in an Ethernet LAN across a sprawling site. Like many offices this one started with a single PC and grew bit by bit into the current environment. For reasons of speed, convenience and cost a peer-to-peer network was employed. Users share directories and printers across the network using share level access.

One of the PC's became designated as a "server" ( from here on I shall refer to this as the "serverPC"). Peer-to-peer networks have no server as such and thus this PC was identical to the others except that it had no consistent user. It was used to store common files (templates, small database files etc.) for use by all users and also contained the Microsoft Mail postoffice directories for the internal mail system. Networking faxing was also routed through this PC by means of Microsoft Fax and more recently, internet e-mail distribution was added by means of a mailserver utility which connected periodically to an external mailserver and redistributes the mail accordingly. It also shares a printer for use by the majority of users in the vicinity. The client side of the mail and fax systems was handled by Microsoft Outlook.

Increase of traffic through the serverPC especially internet mail increased to the point where file access slowed and users could not always log onto the internet mailserver. At first the internet mailserver program was suspected but further tests proved this to be untrue. Users were becoming increasingly frustrated and subsequently handing these emotions onto the IT support people.

There was also a secondary issue to consider. Having a designated serverPC meant from the management viewpoint a perfectly good PC was "doing nothing" because nobody was sitting at it. A decision was made to allow occasional users to use this PC as a workstation. The PC would sometimes lock during these occasional uses as a workstation meaning the loss of access to important files to all users while it was rebooted and subsequently database and file locks would need to be cleared to allow users to get back to their data.

Linux is, to all intents and purposes, a Unix clone (for a more accurate description I suggest you look elsewhere as it's not relevant to this document) and as such the incorporates the excellent networking abilities of the latter. It is this trait (among others) which has lead to its' increasing deployment in the Internet server market. It could provide a low cost replacement strategy for the problem at hand and yet allow for the expected network growth at little or no extra cost.

That Linux was an effective and cost-effective server solution was not in question but we need to know whether it could provide a specific solution in this case. Could Linux fulfil all the roles provided by the current serverPC, including file-serving, internal mail, network faxing and Internet mail redistribution. Initial enquiries showed that it could and so the question became less of "can Linux do it?" and more "can I make Linux do it?".

Before presenting any argument for deployment to management it seemed prudent to research said argument. This would serve the additional purpose of educating myself in the finer details of Linux Administration. My Linux experience stemmed from a few months use at home and as Linux was not in use within the company I was to all intents and purposes the Linux expert.

I started my research lurking at newsgroups, particularly uk.comp.os.linux (u.c.o.l.).Although lurking can be frowned upon in some circles it is something I recommend in early stages of a project like this. Reading other peoples questions and answers gives valuable insight into your approach to future projects you may encounter. They say it is a fool who does not learn from others mistakes. In addition I had a copy of the book "Learning RedHat Linux" published by O'Reilly (http://www.ora.com). This book was used when installing my home version of Linux and is excellent for this purpose. It also contains a very significant chapter on Samba - a networking application which allows Linux to act as a fileserver for Windows9x PCs. I also made extensive use of the Linux Documentation Project (tLDP - http://www.tldp.org) especially the Linux Users Guide, the System Administrators Guide and the Network Administrators Guide.

I assembled a PC from bits lying around the IT stores - a fun exercise in itself - and ended up with a test system of P133, 32MB Ram and 540MB HD. I was planning on replacing the HD with a much larger one but wanted to test the installation on the rest of the system first.

Having installed RH6 before a few times I *knew* this would be a breeze...I believe "famous last words" is the phrase I am looking for here! Installation seemed fine but on 1st boot (and subsequent ones) I encountered "invalid compressed format" errors as the system tried to Uncompress Linux. This evolved into a system that hung at boot with a "LI" prompt and a few questions on UCOL highlighted this problem as being a drive geometry problem. The system could boot from an MSDos bootdisk launching Linux from LOADLIN but this was far from acceptable. A 1GB hard disk was used instead.

A secondary problem was the NIC. The one I first used was a Realtek8019 ISA card, this is an NE2000 compatible card and thus *should* use the ne2000 driver. After much trying and even a kernel recompile the card refused to work with said driver, so I swapped it with a D-Link DT-530 PCI card from another PC. This card was reported to work with the 'tulip' driver. However the RedHat install procedure could not detect it. A quick look on the D-Link website pointed to the latest via-rhine driver as a solution. This was downloaded and compiled and installed along with the pci-scan driver file from the same site (http://www.scyld.com/network/via-rhine.html). This site also contains excellent installation notes. With the new drivers in place the machine was up and running and a few ping tests proved the NIC was running fine.

Version 2.0.3 was installed as part of the RedHat installation and because this was a trial run I saw no reason to download the latest (at time writing this is 2.0.7). smbclient was not installed as there would be no reason for the Linux box to access shares on the Windows PC's. Configuration was a breeze thanks to the SWAT utility which is accessed by pointing a web browser at port 901 (ie: http://localhost:901). I was even able to access and configure this from one of the Windows boxes across the network (http://<ip address>:901).

qmail was chosen as the Mail Transport Agent (MTA) over sendmail which was supplied with RedHat. This is primarily because the former has a reputation for easier configuration and better security than the latter.

Fetchmail was used as a collection agent and installation and setup of this was a breeze, especially when I found out about fetchmailconf :o). We do not require mail collection at all times but prefer to collect at set intervals. To facilitate this fetchmail is called using the -d switch by a cron job everyday and stopped by another one.

We collect our mail from ten mailboxes on our webhosts server, one of these is a bulk redirect where anything addressed to our hostname but not to one of the other nine specific addresses is deposited. fetchmails multidrop facility was employed to allow us to download all the mail from this mailbox and then smtp it to qmail using the intended recipients address. One problem we encountered was sending mail from our new qmail server to our salespeople. They collect their mail direct from the webhosts yet their domain is the same as everyone else's. This meant that every time a local user tried to send a message to one of the salespeople, qmail tried to find a local username to pass the message to and, upon finding no matching user, bounced it to the postmaster. The solution was to use a secondary e-mail address for the salespeople. Our webhosts do not provide dial-up services so our salespeople each have their own free ISP account to get access to the web. This account provides them with an address on a different domain and so qmail was able to forward all mail for them to this address using the alias files.

Note: To make life easier for the salespeople our webhosts redirected all mail coming to their mailbox for these people to the free ISP mail address - this meant the salespeople weren't 'confused' by having to juggle multiple accounts and addresses on their notebooks - bless 'em :o).

The old serverPC used Microsoft's network faxing to share a fax service across the network. Users then used MS Word templates (which had VBA macros) to create and send faxes automatically, errors were mailed to the user. To provide and equal if not better service on the new server I chose mgetty+sendfax to provide the local faxing service. This installed easily and I was soon able to spool faxes from the Linux server. Spooling from Windows clients was to prove a much tougher nut to crack and resulted in a change from the original choice.

As mentioned, our users are accustomed to being able to hit one button to send a fax document from within MS Word97, it was important to keep this feature available with the new server. WHFC has OLE capabilities and thus we were able to write a new macro which allowed the user to send a fax from within Word without having to enter the fax details into a secondary popup box. The macro does two things - first it prints the current document to a file, then it uses WHFC's SendFax OLE function to send the printed file to HylaFAX. The printer driver we use is the Apple Laserwriter 16/600(ps) one as recommended in the WHFC setup notes.

Here is the macro code we use ...

Sub Spool_fax()
' Spool_fax Macro
' Macro created 09/08/00 by Ryan Cartwright

Dim givenfax, realnum As String
Dim whfc As Object
Dim OLE_Return As Long
Dim Box_Return As Integer

' First we print the document to a local file - note that Background must be false
' otherwise the function will return before the file is entirely written
' and thus HylaFAX will be unable to convert it properly.

Application.PrintOut FileName:="", Range:=wdPrintAllDocument, Item:= _ 
  wdPrintDocumentContent, Copies:=1, Pages:="", PageType:=wdPrintAllPages, _
  Collate:=True, Background:=False, PrintToFile:=True, _
  OutputFileName:="c:\faxtemp\printout.ps", Append:=False
  
' In our template the user is asked by an Autonew macro for the faxnumber etc.
' the field number for the faxnumber is 8, we need to retrieve this
' and add a 9 to the front of it
Set givenfax = ActiveDocument.Fields(8).Result realnum = "9" + givenfax

' Now we create the OLE object and call the Sendfax() routine
Set whfc = CreateObject("WHFC.OleSrv")
OLE_Return = whfc.SendFax("c:\faxtemp\faxoutput.ps", realnum, False)

' Finally we test the returned value and report accordingly
If OLE_Return &<= 0 Then
  Box_Return = MsgBox("Error sending file", 16, "FAX Not Spooled")
Else
  Box_Return = MsgBox("Fax Job ID:" & _
    OLE_Return & Chr(13) & _
    "You will be notified by email if it was successfully sent", _
    0, "Fax spooled")
End If

Set whfc =Nothing

End Sub

That pretty much covers the installation and configuration of all the tools and utilities required to get our new server up and running. Having said that there is more to a good server than just the tools to do the job required. I advise you read the afore-mentioned Linux System Administrators Guide especially chapter 10 - backups!

The Linux server was in place some two months after starting this project. I am sure this could have been days if I had known what I was doing but I would recommend to anyone considering a similar project to allow themselves a good time period. This is especially applicable if like me they have cut their support teeth in Windows. Linux is not difficult to use, just different and the transition from Windows takes time. Read the excellent documentation around before you start and also you may find it more beneficial to try this step by step on a secondary machine whilst your old one is still running elsewhere. Migrating is a better approach than a straight swap.

Since first writing this document I have gained a great deal more experience with Linux and some of the tools mentioned here. I now use Linux in a wide variaety of tasks at home and work. I have since moved from the company for which I set this particular server but to my knowledge they were still using it some three years later ( I think they replaced it with a newer Linux based sollution arouind this time). If you are considering using Linux as an alternative to another OS I would encourage you to look into it.

Not only have I moved on but the changing face of Linux has meant the necessity for this document has decreased somewhat. Many distributions (try looking here http://www.linux.org/dist/ ) have made using Linux as a Windows-LAN server even easier by pre-configuring the options needed. Often you can find a dedicated product specifcally for the purposes mentioned here.

However there will always be those who want to "get their hands dirty" or just want to do things for themselves and learn through that process. I can sympathise with this as the experiences shown here served to teach me far more about Linux than I first anticipated.

Also, as the world of Microsoft moves away from clients such as Windows9x, there has arisen a need for provision of things like shared calendars, address books etc. ( basically replacing Microsoft's Exhange Server ). Much of this functionailty are available under Linux through various applications and tools, some proprietary, but I decided against listing them here as I felt it best (and simpler) to keep this document within it's original purpose. If you require these things, have alook at some of the products available through various distributions which aim to provide all of the functionality listed in the document in one go.