Build your own Linux server

Why build your own Linux server? It's a good question. The answer is simple: to save money. Instead of forking out for appliances such as the D-Link DFL-700, you can build one that does exactly what you want, and gain useful experience in the process. Given the learning curve involved, what it won’t save you is time -- especially if you have little or no experience of Linux. If you need a quick solution, frankly, rolling your own Linux server to look after your home/small office network won't be top of your priorities. On the other hand, Linux expertise is both expensive and hard to come by (the two are not unrelated) so, if you plan to move any of your IT systems to Linux any time in the near future, this may be a relatively simple and -- in the longer term -- worthwhile project to undertake.

Hardware requirements
Modern PCs shrug off the kinds of loads generated by a small business network, so the same machine can perform a number of features such as file serving for Windows clients, Web caching and firewalling. We decided to adopt a typical strategy and redeploy a redundant PC -- it is, in fact, our original, 950MHz Athlon-based 'quiet PC', first seen here.

We removedunnecessary adapters, including the graphics card, which was replaced by the oldest (and therefore coolest-running) equivalent we could find in the parts bin. We swapped the 10/100Mbps network card for a gigabit (1,000Mbps) Ethernet device, providing a performance advantage that no off-the-shelf appliance at this level will deliver. We also removed an older and potentially suspect 128MB DIMM with the aim of pre-empting hardware faults -- the remaining 512GB is plenty in a moderately loaded Linux server, and reliability is paramount.

OS installation
Two disks provide storage, one 40GB the other 10GB. We used Partition Magic 8 to repartition the 10GB disk into three: 4GB bootable for the OS; a 700MB swap partition, which is a bit bigger than the memory size and should be sufficient; and the remainder as a share for administrative purposes. The larger disk we left as a single partition, with the aim of opening it up for user sharing. However, 40GB looks a little meagre these days, so it's first in line for a future upgrade -- probably to 160GB. Selecting the right Linux distribution is the first major task. We don't need big enterprise features, but we do want high reliability, driver availability and online support from forums and newsgroups. Eliminate distros aimed more at desktop use, and you're left with Novell's SuSE Linux and Red Hat Linux (RHL), both of which have plenty of open source drivers and other software support. So with some prior experience of Red Hat Linux 9 running on the 2.4.20-30.9 kernel, we downloaded the entire 2.24GB of ISO images and burned them onto CDs -- clearly, you'll need a broadband connection for this.

Installation itself went fairly smoothly with only a couple of glitches. We could not persuade it to install from another machine on the network over a tested and working FTP connection, and we also at times had problems persuading it that one of the install CDs was readable, even though we re-burned it and swapped in another CD drive. Eventually though, Red Hat Linux 9 with the KDE 3.2 desktop environment was up and running, with all hardware recognised first time.

Initial configuration
Usually, you would operate a Linux machine with a user account rather than the super-user root account, which provides privileges that allow you to render the OS inoperable. When setting things up for the first time, though, overall privileges are appropriate. Just be careful. The first job was to select the services that could safely be switched off, using the principle that only software whose purpose you know -- or at least have an idea ought to be running -- should be left live. The first candidate for switch-off was telnet -- there are few justifications these days for telnetting into a server, since it's very insecure and there are better alternatives such as the cross-platform VNC. We switched off cups and other print serving services, since we shan't be using those, along with NFS, Unix's native but insecure file sharing system. Other services disabled included SNMP, PCMCIA and, for the moment, httpd -- the Apache Web server. Items we ensured were running included Squid, the Web caching service; FTP, so we could access files from elsewhere on the network; and of course SMB, the Samba server that shares files for Windows networks. Once it looked more like a server, we switched on the required features. First we created user accounts with RHL's user manager and assigned their home directories to folders on the 40GB disk. On this occasion, there was no need to rummage around in Linux's text-based configuration files. With that basic task done, it was time to turn to start building the server proper.

Talkback

> /etc/squid/squid.conf -- recognised as a
> configuration file by Linux via its .conf extension

Huh???
What does that mean. I never heard that "Linux" (which part - the kernel?) recognize anything via
its file extension. Actually there's no concept like
file extension. 'been using too much Win/DOS...

via Facebook 23 April, 2004 13:10

Why doesn't the author tell us exactly what he's running when he runs Samba's "graphical configuration" or the ipchains "security applet"? The article is useless without any details.

via Facebook 23 April, 2004 21:01

RE Why doesn't the author tell us exactly what he's running when he runs Samba's "graphical configuration" or the ipchains "security applet"? The article is useless without any details."

The author can't because samba (smd/nmd) dont have GUI's.

I also note that the shares were not part oif the build because it was easier to backup? what the ?

via Facebook 24 April, 2004 15:26

he suggests turning off the insecure telnet, yet uses ftp.... which is just as insecure as telnet. Not smart. Your using smb mostly, so ssh and scp should be acceptable for administration.

VNC isn't exactly secure either, but the only option for people who don't grok commandline I suppose.

via Facebook 25 April, 2004 02:49

It's good that ZDNet is running articles on this type of topic, but it has to be said that the article isn't as great as some hardware reviews here - it's more of a damp and fluffy how-to, and to be honest the topic is covered much better elsewhere.

An interesting article might be a comparison of a Red Hat based server (ie command line and standard-ish linux graphical tools if you use them) with something that is designed solely for the purpose of being a server - like SME Server from www.contribs.org. I've just set one of these up, and it was simple, and leaves me with a great web based management utility, although customising from the command line is more complex.

How about it?

via Facebook 26 April, 2004 02:16

Not bad for someone starting out in Linux but rather glosses over the problems with certain types of operations such as file systems and samba with firewall's. You shouldn't need to run Partition Magic - you should use fdisk - the debian version and then you can assign any one of 30-odd types of file systems, depending upon the kernal. Then use mkfs to put the filing system on it. Debian is a better choice for Linux if you are from a UNIX background as the commands are closer, but you can't do anything meaningful with LINUX unless you have access to a good manual or handbook. SSH is a better and more secure shell to use rather than Telnet and if you use PuTTY, this is easy.

This articles needs more research I think.

via Facebook 28 April, 2004 15:34

Don't what planet this author is on but there are other distro's out there that are just as good as SUSE and Red Hat. The latter is the Fedora project anyway!!

I use Mandrake 9.2 Linux on a self-built PC as a internet gateway without X and it works fine. They also haven't sold out like Red Hat.

Whats all this about IPCHAINS? They are obsolete in current kernels replaced by the more powerful IPTABLES suite. Useful not just for firewalling but when used in conjunction with internal kernel QDISCs for quality of service traffic shapping (which I do on my box).

In my experience Samba was a nightmare to get to work and I gave up on that in the end. So saying its easy to use is questionable...

Squid (the web proxy) is an totally independent project from the Linux released under the GPL.

Good article but should be split up with each article going into depth on one topic/article to cover common problems and spread the good word!!

via Facebook 29 April, 2004 21:49

Redhat 9 seems a questionable choice given that updates are no longer available. A good alternative now are the various free rebuilds of Redhat Enterprise Linux e.g. ...

http://taolinux.org/
http://www.caosity.org/
http://www.whiteboxlinux.org/index.html
http://www-oss.fnal.gov/projects/fermilinux/

All of these project aim to track RHEL and thus should be good for updates for the next 4-5 years.

For anything mission critical it is worth taking the hit and paying for RHEL itself of course, but for second tier systems I have found Tao an excellent choice.

via Facebook 4 May, 2004 10:15

I thought telnet was turned off by default in RH9

On my RH 9 machine i had to enable it... So who's wrong!?

via Facebook 11 May, 2004 13:40

Well well, about time we had some more of this sort of artical.

via Facebook 14 May, 2004 08:59

smeserver is a 1-CD distribution aimed at exactly what you've done, and requires little to no expertise. check it out at www.contribs.org

via Facebook 24 May, 2004 15:01

Take a look at NASLite (www.naslite.com). It is a pretty neat and simple to set up file server OS. In fact it's so simple that even an abcolute novice can do it.

Anyway, just thought you may find it interesting.

via Facebook 26 January, 2005 03:14