Re: Debian 6.0 'Squeeze' home server - Installation guide
On Wed, Oct 20, 2010 at 07:50:04PM +0000, Pinguim.ribeiro wrote:
> lee <lee <at> yun.yagibdah.de> writes:
> My envision for this tutorial is a guy like me, a bit curious and very
> enthusiast about Linux, but not an expert at all ;-) This guy and his
> wife both have a desktop PC, a laptop, a few email accounts and lots
> of files and they want to have everything in one centralized place.
Under those circumstances, assuming that the email accounts are at
different domains, I´d suggest to use a MUA that deals nicely with
having a number of email accounts at different domains. Seamonkey, for
example, might do nicely. Setting up your own mailserver to handle
some email accounts at different domains and using fetchmail to
retrieve the mails isn´t impossible, but I would advise against it: It
doesn´t make much sense to go to such lengths, using fetchmail can be
rather tricky, and you remain subject to all the restrictions and
unreliabilites your email providers may impose on you. (I´ve seen
mails being lost from the a providers server while fetching them with
fetchmail, and I´ve had more than enough bad experiences with the
incompetence of such providers --- not to mention that the limits they
impose are usually unacceptable.)
Setting up your own mailserver makes a lot more sense when your goal
is to make yourself independent from ESPs. That involves getting your
own domain(s), preferably a static IP address (or using the mailserver
of some ESP you sufficiently trust as a smarthost) and the required
DNS entries. This will allow you to have as many email accounts as you
like, but more importantly, you can receive and, if you get a static
IP, send your email directly.
Before you set up your own mailserver, no matter in which way, set up
> I know, a NAS would be enought, bu did I mention I'm a curious and very
> enthusiast guy about Linux ;-) ?
For file storage? Yes, that might be the better way to go in your
case. I don´t know how much electricity costs where you live, but
using a NAS device might save on that while running a server can add
quite some to the utility bill. And it (hopefully, I have never used
one) is easier to administrate.
But then, before spending money on a NAS device, you might as well get
a used computer and put the disks into that rather than into the NAS
device: because it offers more options and because you´re enthusiastic
> My model is the previous 'Debian lenny server' site at
> http://servidorlenny.wikidot.com/servidor-debian-lenny. It's in Portuguese but
> you can check out the toc on the right side.
Yeah, there´s some more on that site :) Unfortunately, I don´t speak
> > There´s no mentioning about setting up RAID and reasonably
> This guide is just for newbies ( like me ;-) ). The idea is to keep it very
> simple. But maybe in the near future I'll write a tutorial about-it.
It´s one of the basics to think about, before starting to install. You
can later switch over to RAID, but it makes things a lot easier to
decide about using RAID or not before installing. The decision is not
so much about wheather to use it or not but about what kind of RAID:
hardware, software and what kind of RAID (1? 5? ...?).
You also get invovled with LVM if you want to boot from a RAID
partition: The Debian installer is unable to install on software RAID
when you don´t use LVM :(
> > recommend not to use DHCP but --- if provided by some router --- to
> > turn it off in the router and to do all network configuration in the
> > LAN manually.
> That will be the next section: 'Network Configuration' with static IP address,
> DNS and DHCP server, etc.
Well, why would you use DHCP? Doesn´t that make the whole thing quite
a lot more complicated?
> > you might want to consider to use the server as a firewall and
> > router. This would be a topic that could be discussed in the "before
> For the moment, I'll rely on the router/DSL/Cable modem for that. Most of them
> have some sort of firewall set up.
They do, but they are also very limited. They don´t support setting up
transparent proxies, they can lead to problems with NAT; the traffic
shaping, if they provide it at all, is very poor, they have buggy
firmware, they lack good network monitoring tools ...
> > There doesn´t seem to be a section planned about compiling the
> > kernel. Though it´s possible to use a kernel out of the box, the
> Yes, for the moment I have no plans for a kernel compilation tutorial.
Well, that´s one of the first things to do after installing a minimal
> My hope is that this guide will make (at least) a few people to try
> and became more curious about the Linux world and eager to learn more
> about it.
Shouldn´t the guide follow this experience and introduce them somewhat
systematically and thoroughly into setting up their server? A guide
that´s like "whoosh, install this and that and there you go" is
precisely what can make ppl think they could do everything at once
easily and won´t need to learn.
Such a guide doesn´t need to re-invent the wheel. There is a lot of
documentation available each piece of which covers some detail ---
like kernel compilation or setting up a firewall --- to which the
guide could point. The guide could adapt what can be learned from such
documentation and give actual examples, like configuration files for
shorewall, and explain what they do and why they are going to be used
for the server that is to be set up. Since everyone has different
needs, ppl can adjust the examples to what they need.
> > Any guide giving even the slightest suggestion that they could easily
> > and reasonably set up and administrate a server as complex as you
> > envision would mislead them. Trying to give them an idea of what they
> > are eventually about to get into and that they need to make one very
> > small step after another rather than demanding that everything has to
> > work right now is something I´d tell them even before the "before you
> > begin" section.
> Again I agree with you. This guide is a step by step guide but it must be
> clarified at the beginning. Do you have any suggestions on how to do that
Well, you could quote from my previous posting :) I don´t really know
how to make it more clear. The very problem itself that ppl demand
everything at once also seems to prevent them from understanding that
they can´t have it.
Perhaps just tell them that they can´t have it but that they will get
there when they follow the guide and take their time to learn. Tell
them that´s what the guide is for but that the guide can´t do anything
for them because they need to do the learning all by themselfes the
same way they learned to read. Tell them that it doesn´t matter if
something works or not. But what matters is that they keep at one
thing at a time and experiment and learn on it until they finally get
it to work (unless they find out that they need to learn another thing
first to get the thing they are working on to work). They also need to
learn to figure out when they´ve reached the point at which any
further trying is useless. At that point, they should go to sleep (or
do something else) and try again the next day.
I took a look at . Along with telling the readers that they can´t
have what they want, I´d tell them what to expect from the guide and
let them decide for themselfes if they are willing to take it as one
:) They can always browse the table of contents to figure that out.
What they can expect from the guide depends on how much work you´re
willing to put into it, and maybe on how much others are going to
"And bear in mind: maintain a server is a never ending task and,
definitively, not the easiest job in the world!"
I´m afraid the point is to make it so that it doesn´t require never
ending maintenance :) For example, once your mail server is working,
you might need to change something once a year or less often. You may
have to re-learn how to do it because it´s so long ago that you set it
up that you forgot the details. That also involves keeping things as
simple as possible. The same is with other services.
This doesn´t mean you shouldn´t monitor the services. You need to know
what´s going on, so you are (hopefully) able to prevent possible
problems (which you haven´t foreseen when setting things up) before
they actually become problems.