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 your DNS. > 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 Portugese. > > 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 system. > 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 > section? 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 [1]. 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 contribute. "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. [1]: http://debianserver.wikidot.com/squeeze:before-start -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101021230131.gb13...@yun.yagibdah.de
