Silencer wrote:
> Ok as it stands I'm not upto date with the various Linux distrobutions,
> though I'm no new comer to linux itself my time away from the OS has led
> to me not having a clue which distros best suit my needs.

[Small and unexceptional list of server packages, and details of somewhat
trailing-edge hardware, snipped]

It would be difficult to find a Linux distribution that _could not_ fill
that set of roles reasonably well. To a large extent, the choice comes
down to personal prefernce, and that's difficult to advise people about.
My friend Karsten Self is working on a guide to current distros; for a
while, he'll have it at this URL:
http://linuxmafia.com/~karsten/Linux/linux-new.html

> I need to build a server that will allow both Windows and pre MacOS X
> systems to connect to it locally and via dialup. This is not intended as
> a gaming system, but as a sturdy reasonably responsive server.

Expect to spend a fair amount of time configuring and tweaking the
configuration, regardless of your choice of distribution. You're going
to have to get acquainted with the configuration choices and conf-file
formats of the PPP daemon, Samba, and NetATalk, among other things.

If possible, make contact with one or more Linux user groups, preferably
including one with a physical presence in your area. They can give you
lots of help (along with, inevitably, irrelevant and annoying gratuitous
opinions, etc.)

Rick Moen wrote:
> Silencer wrote:
>
>>Ok as it stands I'm not upto date with the various Linux distrobutions,
>>though I'm no new comer to linux itself my time away from the OS has led
>>to me not having a clue which distros best suit my needs.
>
>
> [Small and unexceptional list of server packages, and details of somewhat
> trailing-edge hardware, snipped]

Play nice, the server doesn't need to be heavy metal to handle it's
vital tasks.

> It would be difficult to find a Linux distribution that _could not_ fill
> that set of roles reasonably well. To a large extent, the choice comes
> down to personal prefernce, and that's difficult to advise people about.
> My friend Karsten Self is working on a guide to current distros; for a
> while, he'll have it at this URL:
> http://linuxmafia.com/~karsten/Linux/linux-new.html

Thanks, I've looked into it. Looks like for now Debian is my best choice
until I reacquaint myself with Linux.

>>I need to build a server that will allow both Windows and pre MacOS X
>>systems to connect to it locally and via dialup. This is not intended as
>>a gaming system, but as a sturdy reasonably responsive server.
>
>
> Expect to spend a fair amount of time configuring and tweaking the
> configuration, regardless of your choice of distribution. You're going
> to have to get acquainted with the configuration choices and conf-file
> formats of the PPP daemon, Samba, and NetATalk, among other things.

I'm passingly familiar with Samba and PPP daemon, but then I helped
configure such an annoying network before.

> If possible, make contact with one or more Linux user groups, preferably
> including one with a physical presence in your area. They can give you
> lots of help (along with, inevitably, irrelevant and annoying gratuitous
> opinions, etc.)

As far it goes there isn't one, the sum total of the linux users
mentality around here equates to "Windows sucks Linux is better". While
I sometimes agree wholeheartedly, it's not exactly useful when trying to
migrate with a minimum of fuss.

Silencer wrote:
> Rick Moen wrote:

>> [Small and unexceptional list of server packages, and details of somewhat
>> trailing-edge hardware, snipped]
>
> Play nice, the server doesn't need to be heavy metal to handle it's
> vital tasks.

No, indeed. I'm passing fond of selected trailing-edge hardware,
myself, and didn't mean to diss the beloved ol' critter.

My Linux installfest server has these (somewhat similar) specs:

K6/233
128MB SDRAM
FIC PA-2007 AT-type motherboard, in a hulking old server case
PC Power & Cooling 350W PSU
Matrox G200
2 x SCSI-2 IBM HDs
Adaptec AHA-2940UW
Adaptec AHA-2940
Plextor 4x SCSI CDR
Northgate Ultra keyboard
2 x 3Com 3C509B ISA NICs

That's a tad more antique than yours, and yet highly serviceable.

> Thanks, I've looked into it. Looks like for now Debian is my best choice
> until I reacquaint myself with Linux.

I tend to be a Debianista -- but getting used to it is fraught with
issues in several categories, starting with installers and moving on
from there. Long story. List of installers:

"Installers" on http://linuxmafia.com/kb/Debian/

That same index page (http://linuxmafia.com/kb/Debian/) has other links
that might prove useful.

Suffice it to say that there are some distinctive, and somewhat
different, Debian-style ways of doing things, and that getting used to
them can take a bit of doing.

> I'm passingly familiar with Samba and PPP daemon, but then I helped
> configure such an annoying network before.

I'm glad you wrote back, because I realised after sending my post that I
was talking through my hat about needing to use NetATalk: For modern
(OS X-based) Macs, you absolutely do _not_ need NetATalk, and can make
either Samba or NFS support them beautififully. Sorry about that.

Silencer wrote:

> Having met Jigdo already I can believe that, presently got the isos
> downloading. When I get the money I really need to beef up the
> connection.

Ja, Jigdo's a real trip, and generates one heck of a lot of disk
activity doing its job, but you'd immediately appreciate it if you ever
wanted to, say, upgrade your current Official Debian 3.0r4 ISOs to the
eventual 3.0r5 contents. It's the least-network-traffic method of doing
that, which is Jigdo's design aim.

> I don't think the installer will give me too many hassles.
> *knocks on wood* But we'll see in a few weeks when I've got the discs.

Among the Official Debian 3.0/woody installer quirks/misfeatures:

1. Path of least resistance is a 2.2 kernel, but you can pick a
2.4 kernel if you pay attention: At the initial screen, hitting
(IIRC) F3 shows you "alternate boot flavours", one of which is the
"bf2.4" one. Selecting that will cause the installer to run
under a 2.4 installation kernel instead of a 2.2 one. Most
people should probably do that.

2. Path of least resistance gives you _no installed package_ of a
binary kernel image. What I mean is: You are, in a bit of
careless misdesign, _not_ prompted to pick a kernel package
suitable for your architecture (486, 586, P6, PII, K7, etc.),
your processor count (uniproc vs. SMP), etc. For lack of having
picked such a package, you instead get a copy of the installer's
kernel. This is bad for a number of reasons: (a) It's not
registered in the package database, so you never get updates.
(b) At any given time, it usually has some unfixed local
security holes. (c) And of course it's suboptimaal for your
system in others ways.

The Debian-testing (3.1/sarge) server I'm sending this from has:

[rick@linuxmafia]
~ $ COLUMNS=120 dpkg -l | grep kernel-image
ii kernel-image-2.4-686 101 Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/P4
ii kernel-image-2.4.27-2-686 2.4.27-8 Linux kernel image for version 2.4.27 on PPro/Celeron/PII/PIII/P
[rick@linuxmafia]
~ $

In other words, because the machine is a single-proc PIII, I picked
package name "kernel-image-2.4-686" -- which is a virtual package that
will thereafter cause the maintenance system fetch you whatever is the
latest "kernel-image-2.4.*-686 package at that time.

3. You are put into a screen listing all available optional kernel
modules by category, and most people have no clue what to do there.

The idea of that installer screen -- not well explained -- is that
autodetection may well not have picked up some of your hardware,
so you can highlight the driver for some listed piece of hardware
you think you have in the machine and thereby induce the installer
to attempt "modprobe" on it. If modprobe fails, you'll be told
that, and 99% of the time there's nothing lost but a bit of time.
If it succeeds, not only will that module be loaded from that
point forward during the installer's run, but also it'll get
appended to /etc/modules on the built system.

For each module you attempt to modprobe, you have the option to
specify load options/parameters. Usually, you don't want to
specify those: The module is usually smarter than you are, in
such matters.

In general, the Official Debian "woody" installer eschews most
automatic hardware detection. (There are advantages.) I keep a
list of _optionally installable_ hardware autodetection packages
in the Debian category of my knowledgebase:
http://linuxmafia.com/kb/Debian/

4. Near the end of the installer, you're asked whether you want
simple or not-simple (paraphrased) package selection. Picking
the latter runs you through a program loved by a few and loathed
by many, called dselect. Abandon all hope, etc.


I vaguely recall that many if not all of these quirks are mitigated in
the beta Official Debian installer for 3.1/sarge. Debianistas seldom
remember the installer very well because, well, one of the points of
Debian is that you only install once and then (in the general case)
never need to again. No kidding.

Rick Moen wrote:
> Silencer wrote:
>
>
>>Having met Jigdo already I can believe that, presently got the isos
>>downloading. When I get the money I really need to beef up the
>>connection.
>
>
> Ja, Jigdo's a real trip, and generates one heck of a lot of disk
> activity doing its job, but you'd immediately appreciate it if you ever
> wanted to, say, upgrade your current Official Debian 3.0r4 ISOs to the
> eventual 3.0r5 contents. It's the least-network-traffic method of doing
> that, which is Jigdo's design aim.
>
>
>>I don't think the installer will give me too many hassles.
>>*knocks on wood* But we'll see in a few weeks when I've got the discs.
>
>
> Among the Official Debian 3.0/woody installer quirks/misfeatures:
>
> 1. Path of least resistance is a 2.2 kernel, but you can pick a
> 2.4 kernel if you pay attention: At the initial screen, hitting
> (IIRC) F3 shows you "alternate boot flavours", one of which is the
> "bf2.4" one. Selecting that will cause the installer to run
> under a 2.4 installation kernel instead of a 2.2 one. Most
> people should probably do that.
>
> 2. Path of least resistance gives you _no installed package_ of a
> binary kernel image. What I mean is: You are, in a bit of
> careless misdesign, _not_ prompted to pick a kernel package
> suitable for your architecture (486, 586, P6, PII, K7, etc.),
> your processor count (uniproc vs. SMP), etc. For lack of having
> picked such a package, you instead get a copy of the installer's
> kernel. This is bad for a number of reasons: (a) It's not
> registered in the package database, so you never get updates.
> (b) At any given time, it usually has some unfixed local
> security holes. (c) And of course it's suboptimaal for your
> system in others ways.
>
> The Debian-testing (3.1/sarge) server I'm sending this from has:
>
> [rick@linuxmafia]
> ~ $ COLUMNS=120 dpkg -l | grep kernel-image
> ii kernel-image-2.4-686 101 Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/P4
> ii kernel-image-2.4.27-2-686 2.4.27-8 Linux kernel image for version 2.4.27 on PPro/Celeron/PII/PIII/P
> [rick@linuxmafia]
> ~ $
>
> In other words, because the machine is a single-proc PIII, I picked
> package name "kernel-image-2.4-686" -- which is a virtual package that
> will thereafter cause the maintenance system fetch you whatever is the
> latest "kernel-image-2.4.*-686 package at that time.
>
> 3. You are put into a screen listing all available optional kernel
> modules by category, and most people have no clue what to do there.
>
> The idea of that installer screen -- not well explained -- is that
> autodetection may well not have picked up some of your hardware,
> so you can highlight the driver for some listed piece of hardware
> you think you have in the machine and thereby induce the installer
> to attempt "modprobe" on it. If modprobe fails, you'll be told
> that, and 99% of the time there's nothing lost but a bit of time.
> If it succeeds, not only will that module be loaded from that
> point forward during the installer's run, but also it'll get
> appended to /etc/modules on the built system.
>
> For each module you attempt to modprobe, you have the option to
> specify load options/parameters. Usually, you don't want to
> specify those: The module is usually smarter than you are, in
> such matters.
>
> In general, the Official Debian "woody" installer eschews most
> automatic hardware detection. (There are advantages.) I keep a
> list of _optionally installable_ hardware autodetection packages
> in the Debian category of my knowledgebase:
> http://linuxmafia.com/kb/Debian/
>
> 4. Near the end of the installer, you're asked whether you want
> simple or not-simple (paraphrased) package selection. Picking
> the latter runs you through a program loved by a few and loathed
> by many, called dselect. Abandon all hope, etc.
>
>
> I vaguely recall that many if not all of these quirks are mitigated in
> the beta Official Debian installer for 3.1/sarge. Debianistas seldom
> remember the installer very well because, well, one of the points of
> Debian is that you only install once and then (in the general case)
> never need to again. No kidding.

Considering how long I've been away I figured I'd better stick with the
stable release for now. And that description you made of the installer
reminds me of SuSE's about 6 years ago. Because I built this machine
piece by piece (and rebuild occasionally) I have a better knowledge of
the exact hardware in use, and all it's quirks, I've never been a big
fan of auto detection, partially because 9 times out of 10 I've found it
to be wrong. If you've ever spent 3 days hunting for the right driver
for a particular onboard video in windows, and then found out the
autodetect was wrong by using another option you realise why I haven't
got along with it ever.