The perfect network server

Serving small networks with free software

Download the whole article as PDF

Short URL: http://fsmsh.com/1774

Write a full post in response to this!


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
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. You can also go, if you like, for hosting dedicated servers, which will give you more choice and bandwidth. But it’s totally up to you.

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.

Designed to serve

What might such a server be expected to—er—serve? Here is a suggestion: files (Samba); printers (CUPS); Dynamic Host Configuration Protocol (DHCP); mail (Exim/Procmail/Qmail/Sendmail) and intranet (Apache) internal websites.

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.

  1. Build it yourself from a typical distribution
  2. 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
Figure 2: the Debian installer showing package collections
Don't miss out on the other pages!
123next ›last »

Write a full post in response to this!

0

Do you like this post?
Vote for it!

Copyright information

This article is made available under the "Attribution-NonCommercial-Sharealike" Creative Commons License 3.0 available from http://creativecommons.org/licenses/by-nc-sa/3.0/.

Biography

Ryan Cartwright: 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.

kenthomson799's picture

comment

Submitted by kenthomson799 on Sun, 2007-04-08 06:23.

Vote!
0

Namaste!

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

Ryan Cartwright's picture

if only there was room

Submitted by Ryan Cartwright on Thu, 2007-04-12 11:41.

Vote!
0

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?

Post your comments here.

Ryan

Seraphim_72's picture

Well if you would like ideas

Submitted by Seraphim_72 (not verified) on Thu, 2007-04-26 20:35.

Vote!
0

Well if you would like ideas I would love to see an article about setting up single sign and a domain for your home using a debian based distro.

Stella Roy's picture

well written

Submitted by Stella Roy (not verified) on Sat, 2007-04-21 15:00.

Vote!
0

hey this is one of well written article I read after many days. keep it up

-Stella Roy
http://rahul-stella.blogspot.com

clievers's picture

Debian, hmmm...

Submitted by clievers on Mon, 2007-04-09 20:48.

Vote!
0

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.

Ryan Cartwright's picture

Other distro's

Submitted by Ryan Cartwright on Thu, 2007-04-12 11:57.

Vote!
0

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.

cheers
Ryan

George Miller's picture

More detailed how-to would be great

Submitted by George Miller (not verified) on Fri, 2007-04-13 19:14.

Vote!
0

Nice article!
I would be very interested in a more detailed how to setup article, if possible.

I am new to Linux and wish to learn as much as possible.

thanks,
George

GaryS's picture

FreeBSD

Submitted by GaryS (not verified) on Fri, 2007-04-20 04:36.

Vote!
0

FreeBSD is way better for a server like this :)

Ryan Cartwright's picture

...because?

Submitted by Ryan Cartwright on Fri, 2007-04-20 13:05.

Vote!
0

FreeBSD is way better for a server like this :)

because?

Appreciate the presence of the smiley but you can't make a statement like that and leave it at that. I've never used FreeBSD - generate some discussion - convince me.

GaryS's picture

FreeBSD

Submitted by GaryS (not verified) on Fri, 2007-04-20 21:24.

Vote!
0

FreeBSD is about a 15 minute install. It uses sysinstall which is one of the easiest to work with. Once setup, the following commands as root and the server you have listed here is online.

pkg_add -r samba
echo smbd_enabled="YES" >> /etc/rc.conf
echo nmbd_enabled="YES" >> /etc/rc.conf
nmdb -D
smdb -D

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.

JeanNarH's picture

Server

Submitted by JeanNarH (not verified) on Fri, 2007-04-20 17:28.

Vote!
0

U want an all purpose server? Cheap as, reliable and multi-puropse for mid ranged company?

Go with a Sun Fire X2200 M2. Cheap, and with Gentoo (or whatever), you can do whatever you want with it, add raid 0 (unfortunately soft). It's a perfect DNS srv, DHCP, Postfix, web (clusterized or not), mysql standalone or whatever else, for like 2.5K US for dual core dual cpu.

I love that thing :)

JNH

Mike Dub's picture

I was surprised to see you

Submitted by Mike Dub (not verified) on Fri, 2007-04-20 20:11.

Vote!
0

I was surprised to see you had suggested installing Debian. Kudos to you for picking the "best" distro!

Chris Hawkins's picture

The perfect network server

Submitted by Chris Hawkins (not verified) on Sat, 2007-04-21 15:06.

Vote!
0

I'm chuckling because I was asked to exactly excute the scenario you outlined above two week ago for a small business client.

I set up ubuntu 6.04 LTS server on a surplus AMD 1200 MHZ with 750 MB RAM. Topped it off with a coating of Xbuntu so those that were "Terminally" challenged could still access it!

Grabbed a Dynamic-assigned domain from DYNDns and set up Apache.

Set up Samba to allow the rest of the XP challenged office to access file shares.

Worked perfectly the fisrt time. Took about 5 hours but as it was the first time I had set up a server was very pleased with the result, as was the client.

patrics's picture

File Server Efficiency (Disks and RAM)

Submitted by patrics (not verified) on Sat, 2007-04-21 15:13.

Vote!
0

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.

John Dean's picture

VMWare Server

Submitted by John Dean (not verified) on Mon, 2007-04-23 02:19.

Vote!
0

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.

Running the server on a dual pentium 4 2.8Ghz, with 1 gig of ram.

bswitzer's picture

GUIs always needed.

Submitted by bswitzer on Thu, 2007-04-26 18:54.

Vote!
0

"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.

Ryan Cartwright's picture

I stand by what I said

Submitted by Ryan Cartwright on Thu, 2007-05-03 13:59.

Vote!
0

BS!

I assure you it is not. :o)

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.

cheers
Ryan

bswitzer's picture

As do I. (I stand by what I said)

Submitted by bswitzer on Thu, 2007-05-03 14:50.

Vote!
0

> I assure you it is not. :o)

I disagree. I assure you it is.

> I run servers without GUIs all the time

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.

You'll be glad you did. This time. Maybe not the next.

Ryan Cartwright's picture

Why I have presented two options

Submitted by Ryan Cartwright on Wed, 2007-05-09 15:48.

Vote!
0

I have deliberately presented two options here.

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.

bswitzer's picture

I hear you.

Submitted by bswitzer on Wed, 2007-05-09 18:28.

Vote!
0

OK. I hear you.

But - I would bet money that people are far more likely to install Ubuntu (non-server), Kubuntu (non-server) even more likely, play, and add services, than load a server distro.

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

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.

Your points are all valid - just not for, IMO, the target audience of the article.

Ryan Cartwright's picture

okay then...

Submitted by Ryan Cartwright on Thu, 2007-05-10 12:58.

Vote!
0

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.

Cheers
Ryan

Anonymous visitor's picture

Tool used for network diagram

Submitted by Anonymous visitor (not verified) on Mon, 2007-05-07 18:37.

Vote!
0

Could you please tell me which tool you used for the network diagram on the first page (http://www.freesoftwaremagazine.com/files/www.freesoftwaremagazine.com/nodes/1774/ss/figure1.jpg)?

I liked the network icons and would be glad if you could share them.

Thanks!

Ryan Cartwright's picture

free software of course :o)

Submitted by Ryan Cartwright on Wed, 2007-05-09 16:12.

Vote!
0

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)

cheers
Ryan



CariNet: Cloud computing is a reality.