Mischa,
Hey, I've done this kind of thing before, so I've got some ideas and
suggestions for you. I've put them inline below, and erred on the side
of being too long than being too short.
Mischa Krilov wrote:
> The story so far:
>
> Hardware:
> I've acquired a IBM IntelliStation M Pro for this project. The system is
> a dual-proc board with a single P2-333, 3/8 GB of RAM, and an IBM 18.5GB
> SCSI drive. I'm hoping to snag an extra proc at some point, thought I
> don't know if that's something I can just drop in down the line, or if
> I'd have to do a reinstall or anything tricksy with my kernel. So, two
> new things for me to learn Linux-wise: SCSI and multiple procs.
That sounds beefy enough for a personal mail/web machine. Something you
haven't mentioned before is how much traffic you are expecting and how
many users you think you will have. But, since you said you were moving
it to a home Internet connection, I figure its for just a few users, and
a slashdotting is right out, right?
As far as SMP support goes, you just have to make sure that it is
compiled into your kernel. It's not catastrophic either way, though --
if you have a SMP kernel with one processor, it should work OK, and if
you have a non-SMP kernel with more than one processor, it'll just use
the first one. So, go ahead and set it up with the one proc, and then
whenever you install the second one, you may just have to compile a
kernel then.
Now, all of the dual processor I've done, though, has been where the
machine shipped with both processors. I remember hearing from somewhere
that you want to be careful about adding processors later because if the
two didn't come from the same batch/revision, that minute differences
could cause system instability. Now, this was back in the Pentium I
era, though, and I'm not really sure if it is a myth or not. In any
case, I don't think it should stop you from installing with the one proc
now.
As far as SCSI goes, it's not that huge a deal (usually). First of all,
you need to know what type of SCSI controller you have, and then you
have to make sure that support for that controller is compiled into your
kernel (NOT a module!). The reason for it not being a module, of
course, is that if you had it as a module, you'd have to load it from
your SCSI drive, which needs the SCSI support to load it... You can
sidestep that issue, by the way, by using an IDE boot drive (as you
mentioned below), or by using an initrd. But, I like to have supported
compiled in anyway... gives me warm fuzzies.
Beyond having support for the controller, it should mostly Just
Work(tm). Remember that they are named /dev/sd[a-z][0-9] instead of
/dev/hd[a-d][0-9].
[modem paragraph snipped]
>
> I think it also makes sense to drop in an medium-small IDE drive,
> leaving the SCSI drive for data. Thinking something like /, /boot, and
> swap on the IDE drive, /var on the SCSI. I expect that /var/logs,
> /var/mail, and /var/www will be where most of my disk space will go. I
> don't have tons of bays in this box, though.
This all sounds fine.
>
> Distros:
> Here's the first, possibly most important step. I'd like to use a
> well-maintained distro suited for server use, where I won't have to pull
> any teeth to patch it or admin it. Some of this is laziness, some is a
> hope to at least think about security. I also need to decide if I want
> the 2.4 or 2.6 kernel. Choices currently include the following:
>
> Debian (apt-get is lovely, install is a pain)
> RedHat (sorry, Joey, but it's familiar to me)
> Slackware (not a fan of its package management)
> SuSE (I can always bug Joey for help)
> Tinysofa (seems promising)
> Trustix (seems promising)
> WhiteBox (a little sketchy here)
>
> What have I missed? What distro doe everyone usually put on a server?
>
> I don't think I have the time to learn a *BSD, so that's out.
Personally, I'm a fan of Debian. Apt-get does rock, Debian is really
stable, and you only have to install once (generally). And, if you want
to go the testing route instead of installing stable, the installer is
quite a bit better.
Keep in mind, though, that if you do go with testing, you are testing
the upcoming release, so it's not quite as stable as stable and you'll
have do more of the security tracking yourself, I think. Also, testing
comes with a 2.4 kernel by default, FYI.
If you dislike Debian, it sounds like for a next choice you'd probably
want SuSE.
>
> MTA:
> Now the real debates can happen. AFAIK, the only real options here are
> to choose postfix, sendmail, or qmail. I know next to nothing about
> exim, but I think it may be a fourth option. It would make me happy if I
> could take the lean-back route and use a simple/pretty/web admin console
> thing, but I'm willing (and expecting) to get really under the hood
> here. O'Reilly, here I come.
>
> With this in mind, what is everyone using and why?
Debian by default comes with exim, and you configure it using a few
screens during the install. My own personal preference is postfix,
though. sendmail can be made to work, of course, but configuration is
simpler with the other alternatives. And qmail is different enough in
design, installation, configuration, and usage to make me just accept
the fact that DJB and I have radically divergent outlooks on mail system
design. If you use it and like it, more power to you, I suppose...
people are into all sorts of weird things.
> Web server:
> Er, Apache. I don't think there's any reason not to go with good ol'
> tried-and-true.
I agree. You have decide between apache 1.3 or apache 2, but that's not
a huge deal either way. I think apache2 is mature enough to go with,
and if you want subversion support (WebDAV, too), you pretty much have
to go with apache2.
> Behind the scenes:
> The old provider has given me a tarball of my old web stuff, as well as
> a list of all email accounts, aliases, and redirects- now I can plan the
> config on my end.
>
> My DNS is currently hosted with old provider. I believe between Xname,
> Rollernet (Thanks, Jeremy!), and a few other resources, I've got this
> covered. Can anyone point me to a good quick-and-dirty primer on DNS?
As Jeremy said, Xname is web-based, so that should be fairly easy. If
you want to run BIND, the Administrators Guide comes with the source and
is also available at:
http://www.csd.uwo.ca/staff/magi/doc/bind9/
I think there's a section in there describing DNS in general, too, in
case you want to know the theory behind the whole thing. Also, I've got
a copy of 'DNS & BIND' by O'Reilly if you want to borrow it for a while,
and of course, posting questions to the list should help too :-)
> I'm pretty sure this is the order I want to do my Indiana Jones swapping
> of services.
>
> 1. Current setup, aka "Throw me the idol":
> Dotster (registrar) -> Old DNS server -> Old web/mail server
>
> 2. Intermediate setup, aka "Now throw me the whip":
> Dotster (registrar) -> New DNS server -> Old web/mail server
>
> 3. Goal setup, aka "Watch out for the giant boulder":
> Dotster (registrar) -> New DNS server -> New web/mail server
The important thing here is to test each service (both new installs and
changes on old servers) before making it live. The above sequence looks
like it'll work. You'll have to reduce the TTL on your new DNS server,
in preparation for the move over between step 2 and step 3. Also,
you'll want to heavily test the new web/mail server before step 3.
Finally, you'll want to make sure that you step 3 properly, or you might
get squashed by that boulder.
> I think a significant part of my working this through is talking out
> what I'm going to do. Comments are extremely welcome. Thanks for being
> my sounding board, gang.
>
> MDK
Kevin
___________________
Nolug mailing list
nolug@nolug.org
Received on 11/06/04
This archive was generated by hypermail 2.2.0 : 12/19/08 EST