[95903] in RedHat Linux List
Re: Security for (SOHO) Newbies
daemon@ATHENA.MIT.EDU (Thomas Ribbrock \(Design/DEG\))
Thu Oct 22 05:32:45 1998
Date: Thu, 22 Oct 1998 10:33:35 +0100
From: "Thomas Ribbrock \(Design/DEG\)" <argathin@iname.com>
To: "redhat-list@redhat.com" <redhat-list@redhat.com>
Mail-Followup-To: "redhat-list@redhat.com" <redhat-list@redhat.com>
In-Reply-To: <362E5FD7.6D337870@mcmail.com>; from John Lewis on Wed, Oct 21, 1998 at 11:27:36PM +0100
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
John Lewis writes:
> Hi=20
>=20
[...]
> What, if anything, should be removed from the system to make it more secu=
re
> and what sort of modifications should be made to config files for service=
s,
> protocols etc. I am guessing that the standard installation loaded some f=
iles
> that are really only needed for networking. If netscape is the only inter=
face
> with the ISP do I need to keep sendmail, pine elm etc that are there by=
=20
> default.=20
>=20
> <comment>=20
>=20
> And yes! I really do prefer a grapical interface since for most of my=20
> computing
> life I have used one, having used OS/2 in all the desktop versions from
> ver2.0
> until my recent switch to RH5.0. I rarely need to use the command line in
> OS/2
> as it is easy to use dos/win progs in seamless mode. Suggesting I use com=
and
> line progs like sendmail is a backwards step as far as I am concerned.
Errm, I wonder if you mix up a few things here... "sendmail" is definitely
not a program you should use from the command line. It's rather a program
running in the background/as daemon/on demand whenever mail needs to be
transferred - not as an end user program. To my knowledge, even Netscape
uses sendmail to *send* mail (while it may be able to *receive* mail
directly via pop (don't know enough about imap to say anything about it),
and even if Netscape is able not to use sendmail, removing sendmail (without
replacing it with alternative MTA (Mail Transfer Agents) like e.g. qmail)
would leave you stranded with Netscape (or similar programs), as most other
MUA (Mail User Agents) rely on an MTA to be installed to send/receive their
mail.
In addition, I wouldn't regard using sendmail as a step backwards. The way
Linux works is far more divided into "layers" than e.g. Windoze (don't know
about OS/2), meaning that you have a working "service level" (for the lack
of a better word) which takes care of all the low level functions (e.g.
transferring mail, talking to your ISP, making network connections, etc.pp.)
and a "user interface level" - that way, you have full choice of options
when it comes to user interfaces (the lack of whitch is one of the biggest
drawbacks of 'doze, IMO).
A completely different story is the *configuration* of said programs. While
many people still prefer the CLI and a good text editor there, I can
understand the wish to have something that is easier to use. But that
problem is already being addressed by programs such as linuxconf and SuSE's
yast (to name just two) - this configuration part has got nothing to do with
the underlying programs as such, and I'd be the first to protest if somebody
wanted to change all configuration to GUI only - because *that* would just
give us a second Win NT.
BTW: The whole GUI/CLI thing is a very personal matter - I for one (and
there are many people like that out there) would regard being forced to use
a GUI all the time as a step backward, as I can do my tasks a hell of a lot
faster via CLI, especially when talking about pipes, scripts and the likes -
although I like a GUI for certain tasks as well.
As long as Linux gives the choice of both interfaces, I don't see a problem
here.
Just my =A30.02,
Thomas
--=20
"Look, ma, no obsolete quotes!"
Thomas Ribbrock | http://www.bigfoot.com/~kaytan | ICQ#: 15839919
"You have to live on the edge of reality - to make your dreams come true=
!"
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.