You are here

The perfect network server

So you need a server? Not a web server of course, you rent someone else’s for that. No, you need a file server, print server, intranet, mail server and more. Can free software provide the answer? Of course it can.

Well what kind of answer did you expect from Free Software Magazine?

Growing pains

Many office networks grow in an almost organic way. They start life as a single PC, then a second is added and before you know it there are five or ten. Sometimes these are standalone but more often they will be peer-to-peer networked. Eventually this becomes cumbersome and some kind of server solution is desirable. At this point the fledgling IT budget becomes hungrier. Proprietary servers are expensive to buy and licence. Free software has for some time offered a choice of alternatives in this field and this article aims to discuss those options and explain how you might deploy a free software LAN server, which will allow you to start small but which can grow with you with minimal extra outlay. So, if you are looking to deploy a server but are baulking at the expense and hardware needs of Microsoft Exchange, read on. Figure 1 shows a typical network layout for your server, for the purposes of this article I am talking about five to ten client PCs behind a single ADSL line.

If you are looking to deploy a server but are baulking at the expense and hardware needs of Microsoft Exchange, read on

Figure 1: typical network layout for our target system

Hardware choices

First, I’ll look at the hardware choice. Server hardware for this kind of project will not be particularly special. Bear in mind that it won’t be running a GUI, so you won’t need that 128MB 3D graphics card. Sound is also irrelevant beyond a system beep, so no sub-woofers are required either. CPU, RAM and hard disk will be crucial as will removable storage if you are implementing an on-site backup solution.

Exactly how fast or how big this all needs to be will vary. However, as a guide, I have recently installed two such servers. One serves five people in a small office and is a Pentium II 700/256 MB RAM/40GB IDE HDD. The other serves about 50 people and runs a lot of services. It is a Pentium 4 3GHz/1 GB RAM/2x160GB SCSI RAID array. The first has a USB DVD writer and the second an AIT-2 tape drive. The first was an old desktop PC which was no longer required and the second was custom-built and rack-mounted. Of course, neither have a (permanent) monitor, keyboard or mouse attached.

It’s unlikely you’ll have any hardware issues specific to running free software. Especially considering the advances made by GNU/Linux distributions and the BSD options. If anything, I would be careful of older network cards and devices mounted on motherboards as some of these can use peculiar chipsets. If you do have an issue then you can buy fairly cheap GNU/Linux compatible alternatives on-line.

The names in parentheses indicate typical free software packages you could use to provide such services. The resources section at the end of this article has links to most of their websites. The mail and intranet services could be provided elsewhere but there may well be situations where a standard ADSL account is used for connectivity and this includes a single catch-all email account. A server like this would give staff individual mail addresses. Similarly, a website may be available, but in a single office environment a local server would provide a more manageable and controllable intranet.

Free software options

Whilst there will be many ways to skin this particular cat, I shall look into two of the most popular ways of deploying a free software LAN server.

Build it yourself from a typical distribution

Download and install a customised made-for-purpose distribution

So how do you decide? My advice is to work out how much time, budget and skills you have available and go from there. If you have no time at all I would stop now. Installing a server will require some time (even—or especially—a proprietary one). If you have a couple of weeks, know how to use a command line and fancy a challenge then go for the first option. If you have a week and don’t know what a command line is then go with the second option.

Work out how much time you have available. If you have no time—stop now

I’ll be looking at one example of each. Of course, your preferences may differ from mine but that’s the beauty of free software—choice. Another one is scalability. Both these options will, given adequate hardware, scale to support much larger setups.

DIY servers

Building your own server from a standard distribution will involve more work, particularly in maintaining packages, installing updates, etc., but it will be your server. It will run the software you choose and will be as unique as you want it to be. You are unlikely to get a support contract for it but at this level you are unlikely to need one. This is the “fun” option. That’s in the same way that building your own house can be fun. I’m looking at a Debian GNU/Linux-based server.

Base install

You can download an install CD from the Debian website. I usually go for the NetInst CD. The Debian installer (at time of writing) has a familiar curses-based interface with fairly self-explanatory options (see figure 2). Follow the instructions and then reboot when requested.

Figure 2: the Debian installer showing package collections

Packages

Once your base system is installed you can install the specific packages you need. The installer has package collections aimed at particular tasks. Figure 2 shows this screen and, as an example, the web server collection will install apache2 and the file server collection will install Samba. Obviously you won’t be needing the Desktop Environment collection. This is a server and contrary to what certain software companies believe, running a GUI is a waste of resources. Any packages not included at this stage, such as dhcp, can be installed using apt-get at the command line. I installed the current stable distribution. You can of course install the testing distribution if you prefer. I would advise against using something like Debian’s unstable distribution on a mission centric server like this.

Contrary to what certain software companies believe, running a GUI is a waste of resources for a server

Note that you may have particular preferences for some services, Procmail instead of Exim, for example. Debian usually has packages for these but supplies certain ones by default. This is not the place for a debate on why they have made those choices. Feel free to join the Debian mailing lists if you want to enter that debate. ;o).

If selected, the installer helps you configure the mail server as shown in figure 3. It does a good job of helping you setup the basics with well laid out options.

Figure 3: Choosing packages is made easy by collections

There’s no GUI so configuration is with a console based text editor. Debian packages have config files under /etc in fairly obviously named files. What I don’t have room for here is detailed instructions for the exact setup for each package, so I’ll just layout the options I used for each package where it usually differs from the default installation.

Samba, installed as part of the file server collection, essentially mimics a Windows server with regard to providing shared directories and printers. The Windows clients (and generally their users) remain largely oblivious to the fact that the shared directories are not on a Windows server. Each user’s home directory and any CUPS printers are shared by default. In addition to these, I usually add a [public] share (mapped to /home/public) which is browse-able and has no user restrictions. You can setup default and specific permission masks for shares.

Apache is setup with a single site. The ADSL router/firewall is set to block inbound access to port 80 thus only the clients can access the web server. If you want a public facing website you might be better to host it across something more stable than a domestic ADSL line.

Maintenance

Keeping your server up-to-date is vital if you are to keep on top of security issues and package bugs. Debian provides a simple method for this via apt. It will update installed packages, and the operating system itself, on-the-fly and need a reboot only if you update the kernel or modules. This means that you should never need to reinstall your system and updating an application does not require server downtime. You can, of course, setup a cron job to update your system overnight but perhaps a safer strategy is to use the -d option for apt which will download the required updates ready for you to install them at your convenience.

You should never need reinstall your system and updating a package does not require server downtime

Let someone else do the hard bit

Sometimes you don’t have the time for a DIY server and this is where a custom distribution comes in. SME Server is based on the popular enterprise level Cent OS. The idea of a custom-made distribution is to provide everything you need on a single CD. The downside of this is that you have little choice in the packages used. Deviating from the standard install is possible but, of course, it makes it more difficult when it comes to upgrading later. Updating a custom distro will often require booting from a new CD. This requires server downtime and thus is best done outside of working hours.

Installation

The SME Server installer is another curses-based affair and walks you very easily through each step. Rebooting, as requested, then leads you to package installation and server setup. By the end you are left with a working server ready for you to setup the details, like users and shares. The whole process took around half an hour. Figure 4 shows one of the later options where you choose whether your server is a server only or a gateway as well and whether to enable the firewall.

Figure 4: The SME Server installer. Look familiar?

Configuration

Of the two options I’ve discussed, SME Server wins hands down for ease of configuration. It comes with an administration console, which can be accessed via a local web interface, a curses-based console at the server, or via ssh. Figure 5 shows a typical web-based screen. Pretty much everything can be configured from within here, which makes this a perfect choice if you are less comfortable on the command line. That said, you are limited to the configuration choices decided by the SME Server maintainers.

Figure 5: The SME Server web interface

Mail transport is handled by qmail. Fetchmail is also provided and it is easy to setup a maildrop from a single ISP account. The web interface provides a webmail client as well. SME Server uses the concept of i-bays which double as both folder shares and directories within the intranet. This makes it very easy for staff to make files available to each other via SMB or the intranet. Setting up a website is trivial using the administration console.

SME Server wins hands down for ease of configuration

Security

SSH access is available within SME Server although enabling remote access to the administration console also enables root logins. This particular hole can be closed but not through administration console so unless you are handy with the command line I would suggest you leave admin logins disabled. If you do make the required changes, then be prepared to keep a note/backup of them because when you upgrade they could well be overwritten.

Backups

For any machine a backup is vital. This is more so for a server where the data is not only more extensive but has more stakeholders in it. Most insurance and business continuity plans require backups be removed from the premises. On-line backup solutions exist which meet this but for a small server like this I would suggest it’s more cost-effective to use removable media such as tape or optical discs.

SME Server provides backup facilities to both tape (using flexbackup) and to a desktop client. There is a 2GB maximum limit on backup to desktop and if you are backing up to tape make sure you are using one of the supported tape drives. Flexbackup is also a Debian package so you can install it on the DIY server if you want. There are other solutions, like Amanda. SMEServer does not support optical devices so instead of using the built-in backup solution be prepared to write your own. Personally, I have a set of scripts using tar which I recycle from server to server.

Conclusion

Whether you choose a custom distribution or a do-it-yourself option, a server based on free software has tremendous advantages. Firstly, you can have complete control over each package used and how it is setup. Secondly, the server will grow with you but without additional licence hassles. And thirdly, the level of uptime for free software servers is, in my experience, a lot higher than proprietary alternatives.

Servers do not have the same needs (e.g. a GUI, music or video applications) as desktop machines and thus the traditional arguments for not using free software are, in my view, nullified. With greater control, arguably better security and no licence worries, using a free software server could end up being a better use of your time, resources and money.

Comments

i like the article;
but it flew over the entire scenario without going into the details like an expert would do!
i am not talking about dictating options like select-this and select-that but a general detailed overview of the various services/daemons, typical-scenarious is way better than a sweeping view of everything!
Keep up the good work

I'd have loved to include more detail on the daemon's etc. but it simply of a case of not enough room. The main purpose was to give a hint as to what is possible with free software. Also I wanted very much to compare the two ways of approaching it rather than explain how to specifically do either. Again this was mostly a space restriction.

FWIW I am currently updating my HOWTO for tldp which was written in 2000 and last update about four years ago. I'll be doing it based on the stuff I've written about here, with more detail on the Debian rather than the SME Server side of things.

But okay - let's throw this out then. A recent poll here suggested people wanted more HOWTO type articles. So how many people are interested in the idea of a more detailed "How to setup a LAN server using Debian" article? Assuming I use the setup described here as a basis what else would you want included?

As soon as I think of building this server, I think of other articles I've read online. Most of the articles mention the use of Suse or Ubuntu. My experience (very little) has been with Ubuntu, for the Server method. I like the looks of this Debian software selection, to specifically choose Web and/or Print and/or File Server, etc. Seems like any easy way to get things up and running. Setting up mail seems a little difficult, and perhaps the majority of people wouldn't need this option (maybe just me ?). For the backups, I'm currently using rsnapshot, it seems to work well. But nice intro article. Thanks.

I've used SuSE in the past but find the package update process in Debian much better. A particular tip is to install apt-listbugs ( apt-get install apt-listbugs) which retrieves and display brief details of bugs listed for the packages you want to install. Really useful if you are running testing (or unstable if not on a server).

I looked at Ubuntu for this but found it added little to the Debian way I was used to.

Setting up mail can be tricky regardless of how you do it and there is an argument which says that is for good reason. It is made easier by the install guide shown which really comes down to understanding the options shown. This is turn requires a little more understanding of MTAs in general - never a bad thing if you are deploying one. Of course if your server is not serving mail to anyone then you can probably install smail ( apt-get install smail ) which makes it trivial to just forward non-local mail to your SMTP relay of choice.

from there, you can connect to a GUI for samba that is very intuitive, you can create users and shares easily at the address 127.0.0.1:901 Also the samba pkg_add will automatically install all dependencies like CUPS or what not.

sendmail is installed by default, so no worry about that. frankly it comes down to this. FreeBSD packages and ports are updated within two days or less on the updates of the most popular applications. apt-get is nice, but I remember having to compile PHP by source because they weren't exactly planning on adding the updated package for it anytime soon. and unlike debian, ALL the packages are stored on the FreeBSD server, I never have to add repositories like I had to on Debian to install some applications. every application I've ever needed has been ported over from linux to FreeBSD, and it also has linux 2.6 binary compatibility in the -CURRENT release.

I use Fileserver for 5 clients. Disks are mounted to clients by nfs. Configuration is PentiumIII 1000MHz, 512MB RAM, two IDE/ATA hard disks, not RAID but working in some way parallel. I want to briefly share my experience. The processor is fast enough. Network have to be 1Gbit/s. Because of /home is shared by nfs it should be SCSI with very low access time. And as much RAM as possible (for disk cache). Of course too much RAM costs too much. However 2 - 16 GB I think is reasonable choice. Also you need to thing about how you place data on disks.

I'm currently using VMWare server to host SME and a web server using unbuntu as the host and guest (for the web server).

For a small site I find this very useful. Backups are easy, just zip the files for the virtual server. If the main machines goes down, then getting the virtual server up and running on another machine is easy, takes 5 minutes.

"Contrary to what certain software companies believe, running a GUI is a waste of resources for a server"

BS!

This presumes:
- the admin is 100% completely able to solve any problem, any time. Without the need to reference _any_ outside resources. Now and in the future. Forever.
- no outside connectivity is needed.

I'm not saying:
- it has to run all the time.
- it has to be significant. xfce?
- it has to be fast.

But it has to be there:
- when trouble happens you have to be able to use web resources and read documents, e.g. .pdf, to solve the problem. Especially if the machine has a problem particular to its configuration that you can't easily duplicate on a spare test machine.
- lynx just won't do it all the time.

Better to have it in and solid up front at install time, than in an emergency where (a) you may not have network connectivity to be able to install it, (b) you can never tell if installation is going to impact or change the situation of the current emergency problem.

You cannot presume up front that a GUI will never be needed, ever. To do so is just foolhardy. Better to have it there, up front, just in case, so you know when problems arise that it is not part of the problem.

Yes, Windows needs it, because not everything is configurable from the command line. But it's getting better. [Better, even now, to have a second partition with a minimal windows install, so you can boot into it and affect the production install, when you have to do so but can't due to files open, registry, or whatever, from the production OS partition.]

When you're in an emergency / down situation, that is not the time to have to think about how to get in place the resources you need to investigate and examine the problem, before you can actually get to the problem.

Particularly if, as the target audience of this article is, you're a new Linux admin.

This presumes:
- the admin is 100% completely able to solve any problem, any time. Without the need to reference _any_ outside resources. Now and in the future. Forever.

It does not presume that the admin must be 100% completely able to... - that would be foolish. I run servers without GUIs all the time - always, every day. Never needed a GUI yet.
What I do not presume is that the admin needs to be sitting in front of the server to administer it and I should have said this.
I do all my administration via ssh (Secure Shell) with RSA keys. Rarely do I need to sit in front of the server and rarely do I therefore need to access web pages from within it for configuration issues.
Should I need to access _any_ outside resources I do - on the same machine I am connecting from.

- no outside connectivity is needed.
Why would you need a GUI to connect to or from the outside? We run several remote servers sitting behind firewall devices which permit access via ssh. These servers do not have _any_ GUI installed and they never will have.

Again - running a GUI on an this kind of server is a waste of resources. Why use up RAM and processing power keeping a GUI loaded (regardless of it's footprint) when you don't need it. Even having one installed and starting it when required seems a waste when it can be done via command line or web front-end.

Better to have it in and solid up front at install time, than in an emergency where (a) you may not have network connectivity to be able to install it, (b) you can never tell if installation is going to impact or change the situation of the current emergency problem.

a) Why would I need to install it?
b) Installation of the GUI? Then don't install it. If you mean a package update or installation then I suggest you have not used Debian's apt system very much. You are told exactly what will be updated, what will be newly installed and what will be removed. You can even haev it report open bugs for you before you proceed. Not that I'd expect any significant ones in a Debian stable system. SME Server requires full server unavailability when updating the whole distribution by CD.

I have re-read what you say but I still cannot see how any of this is an argument for needing a GUI - honestly. So far you have not laid out a reason to have a GUI installed other than "it might come in handy". Handy for what? Configuration? Troubleshooting? I can do these by command line, remotely and quickly. Please explain what tasks on a server specifically require a GUI.

You cannot presume up front that a GUI will never be needed, ever. To do so is just foolhardy. Better to have it there, up front, just in case, so you know when problems arise that it is not part of the problem.

I can and do presume it. I do not presume it lightly, however. It is based upon years of doing this without a GUI. I have never ( repeat _never_ ) found myself needing or wanting a GUI when troubleshooting a server. Indeed when the problem is your graphics driver or mouse, becoming dependant upon a GUI will just create a bigger headache. A command-line interface is the lowest common denominator here.

Yes, Windows needs it, because not everything is configurable from the command line.

Of course Windows needs it - this was my point. A Windows based server will require a GUI and the associated resources to run it. A Free software based server ( running Debian, SME Server, FreeBSD whatever ) does NOT require a GUI. When I said "Contrary to what certain software companies believe, running a GUI is a waste of resources for a server", the software company was of course Microsoft. The argument I am making is that just because we are told by Microsoft that a GUI is needed does not mean ALL servers need one. Indeed beyond configuration I would doubt the GUI is needed for a Windows server (that is day to day serving files or mail does not a GUI). Which may explain why I have seen so many with a 17" monitor switched off and sitting above them. So therefore running a full GUI on a server when you only need it if something goes wrong is a waste of resources.

When you're in an emergency / down situation, that is not the time to have to think about how to get in place the resources you need to investigate and examine the problem, before you can actually get to the problem.

I agree but I fail to see what this has to do with a GUI. Troubleshooting via log files, command-line feedback etc. is all possible and often more informative than GUI flashing lights and dialog boxes. When a machine is down and I really need to be in front of it I can put a dusty old 14" CRT monitor on it if I want to and then I can use it. Using a GUI requires additional resources - some of them inside the server some of them plugged into it.

Particularly if, as the target audience of this article is, you're a new Linux admin.

Again I agree and again I see no reason for this to result in installing a GUI. SME Server as mentioned in the article has a remotely accessed web interface which enables you to administer your server without touching the command line. For new (by which I take it you mean beginner) Linux admins
I would recommend that but it still does not run a GUI. X is not installed at all.

OK. YOU do. But this article is intended for those who have no experience, and have never dealt with such servers. And YOU won't be around for every reader who goes and implements what the article suggests.

You are falling into a few traps that I see repeatedly. They are typical of vendors: _I_ know what I'm doing, and _my_ implementation will never change. This is not a shot, just my experience. Inevitably I have had to come along afterwards and blow up (expand) their nice, neat, tidy, installations, because the unexpected has happened, or is suddenly required, and what I'm familiar with, or think I need, to solve a problem, isn't there. From a long term maintenance perspective. Sometimes bringing that install up to 'my standards', including installing things I might not need now, but I sure want in place just in case, breaks things - because the original installer had tunnel vision.

Change _always_ happens, eventually, and, just as _eventually_ it will be done by someone else.

Throughout your response you say _I_ this and that. When you get hit by a bus, what about the next guy, who may know nothing?

> Should I need to access _any_ outside resources I do - on the same machine I am connecting from.

You presume you have access to outside resources, to get into the machine in the first place. You also presume that the next emergency problem solver has your level of competence to be able to solve the problem, and that solving the problem won't involve sucking up an external fixit utility to work directly on the problem machine, because that's how the newbie who has to fix it _right now_ knows, or can find, how to deal with it.

The article deals with new installations by new people. People who if not actually uncomfortable with the command line, certainly won't have a breadth of knowledge necessary to deal with the problem in the environment you suggest.

> These servers do not have _any_ GUI installed and they never will have.

Because the company has decided to implement things that way, and, more importantly, the company has decided to maintain a staff with the necessary expertise to maintain those installations. This is not whom the article is directed to. Such a company wouldn't even read this article. They are already well beyond it.

> It is based upon years of doing this without a GUI.

Hardware is cheaper than people. Peace of mind has a cost. I didn't say run X, merely make sure it is there. In a down situation, resource consumption is your last concern, having in place any possible resource you, the new guy, might need, is the first concern.

This article is an introduction for new people never having done this before. I don't disagree with your comments in the context of experienced admins., however, how was that experience gained? I would guess, given your comments, in an environment where you had similar machines already, to examine and as a basis of confidence as to how to go forward. I would also guess that you had people around you with expertise to draw upon as you worked to figure things out.

The point of the article is for those who have never done such, have nobody around, and have only the web to draw upon. No outside dollars for consultants. Typically, their test machine is their live environment. It has to be solved, _here_, _now_. The article reader doesn't know how - they will have to, at least, browse the web. From that machine.

I don't say the _next_ machine they do will need it. Only the first one. As their expertise and confidence grows, they will need less and less.

But for that first one - hardware is cheap, and software seldom really pushes it to the max. For, at most, a few MB of memory (in this age of GB memory), a few MB of disk space (in this age of TB disks), a few MHz of CPU (in this age of GHz CPU), save yourself some aggravation and irritation up front - put in a GUI. Maybe you'll never need it, for no big loss. But for you, the new user, even if only for a comfort pillow, put it in.

The first, Debian, one requires command-line knowledge and, shall we say, an enthusiasm for it would help as would a knowledge of what you are doing. So if you have no idea what BIND is I would suggest configuring it manually is going to take longer.
The second, SME-server does not require any[1] command-line work at all. Everything can be done via a web interface from a local machine OR from a text, curses-based console at the server itself.

Neither of these install X. It's also worth noting that the Ubuntu server does not include X by default and many custom server GNU/Linux distro's do not either. It would seem I am not alone not using GUIs on servers and on a small scale one (say 128MB RAM) I would still not recommend one.

If the admin has an allergic reaction to the command line (and what GUI user doesn't when they first encounter it) then I suggest SME-server or similar.

Ryan
[1] Okay - you have to be able to type an admin username and password when prompted to.

You have not addressed any of my points with respect to the audience to whom the article is addressed to.

I was going to then I realised my reply was far too long so I cut it down a little :o)
FWIW when I proposed/wrote this piece I had a particular set of users in mind - with two distinct subsets.

Firstly, they would not be absolute beginners. It is wise to have a certain understanding of network technologies (even if it's knowing that those technologies exist and what they do). This is why the article is the the Hacker's code section and labelled Intermediate. These people would have maybe used or fiddled with proprietary servers before - or deployed a peer-to-peer desktop PC as a "server". Bottom line: terms like POP, SMTP, DNS etc. would not be foreign to them.

Secondly, they would be looking to see if their server needs could be fulfilled by Free Software and what types of Free Software server solutions were out there.

That gives us our general set of users. Within that I was hoping to address two groups:
a) those who had installed GNU/Linux a few times and were familiar with the command line but just had never done a server because it seemed too complex.
b) those who had used GNU/LInux/Free Software at Desktop level and were happy with installing - say - Windows from a CD. They had not installed GNU/Linux from scratch before but understand what partitions, RAM and DNS etc. are.

The Debian option was aimed at group a), the SME-server at group b).

You still presume network connectivity to be able to run a web client (GUI) on another machine, to read pages from a machine that may not be able to communicate to you.
Yes I do but then so do you if you are expecting to browse the web from the server - as you mentioned. In addition many of the packages used within a server environment are unlikely to have desktop-based help pages. You are more likely to have to wade through.
Finally - have a look at the typical network diagram shown. The Internet connectivity is supplied via an ADSL Modem/Router and not the server. I would expect the server and PCs on the LAN to gain access to the web via that. Granted the server could provide gateway and DNS services but for simplicity in smaller environments I have tended to use router/modems.

While I am here, you have also said this...

You are falling into a few traps that I see repeatedly. They are typical of vendors: _I_ know what I'm doing, and _my_ implementation will never change. This is not a shot, just my experience. Inevitably I have had to come along afterwards and blow up (expand) their nice, neat, tidy, installations, because the unexpected has happened, or is suddenly required, and what I'm familiar with, or think I need, to solve a problem, isn't there.

Firstly, by placing expectations of a GUI on the system you are also saying "your" implementation is what is "required".

Secondly, there is a reason I use SME-server and Debian.

SME-server can be administered by people less confident/skilled/experienced than myself with a few simple instructions on how to access it. It really can. I usually deploy this where it is unlikely the organisation is going to be able to (or have the funds to) replace me if I go. Updates, configuration, administration are all done in the standard recommended way for SME-server. Anyone unfamiliar with it (but familiar with networking and server terminologies/technologies) can quite easily configure an SME-server. If they don't pick it up from the easy-to-follow web interface then they can browse the host of good documentation on the website. Yes this expects a web connection but so does a lot of documentation these days.

For the Debian installs I use standard Debian packages, configured in the standard Debian way and locations, If I install Exim4 it is done via apt and the config files are in /etc/exim4 . In this way not only can someone who has configured/administered Debian before carry on where I left off with minimal learning curve, they can also apply package updates knowing that I have done nothing out of the ordinary which the update might break.

Thirdly - when I install a server I make very sure the people there either, have the skills to carry on after me (that I will train people to add users via the SME web interface) or I make sure they are able to acquire the services of someone who can. It is on that basis that I decide which option to roll out.

I used OpenOffice Draw to create the diagram. The images came from the OpenClipart library. http://www.openclipart.org but the site was down for maintenance when I wrote this. I got it by installing the Debian package (openclipart_openoffice.org)

Author information

Biography

Ryan Cartwright heads up Equitas IT Solutions who offer fair, quality and free software based solutions to the voluntary and community (non-profit) and SME sectors in the UK. He is a long-term free software user, developer and advocate. You can find him on Twitter and Identi.ca.