Re: Splitting client-server packages

[Bear Giles <bear@coyotesong.com>]

> On Thu, 4 Feb 1999, Dave Swegen wrote:
>
> > [...] I
> > thought it might be a good idea if packages such as this were split up into
> > two parts - client and server.
> 
> OTOH, is there a particular reason you don't want sshd running?  It gets
> swapped out if you don't use it and it a good deal more secure than
> telnetd and rlogind

I think it makes a lot of sense to split *all* client/server packages
into at least two pieces.  (Kerberos and other third-party systems need 
to be split *three* ways.)

My rationale is simple: the postinst scripts for the servers should
modify /etc/[x]inetd.conf and start up the servers, but that may violate 
the security policy of the site.  This means that a site admin may 
legitimately ban mixed client/server packages, while clients-only may
be acceptable.

You may think SSHD is still a good idea, but I can think of several
reaons why a site may ban it.  SSH is only free for personal or 
educational use; installing the *server* on a business computer may
be construed as commercial use even if it's never used.  The site may
have strict policies against running unauthorized servers.  The
site may have strict policies regarding the type of servers run.
(E.g., only kerberized ones.)  You may only have the SSH 1.2.25 
package.

On a more abstract level, the "commodity" services are *not* bundled.
Ignoring netstd for the moment, the SMTP client and server are
unbundled.  The FTP client and server are unbundled.  The HTTP
client and server are unbundled.  SSH is bundled solely because
it is a commercial product which provides both... but it's on the
standards track and independent implementations are in the pipe.
(Notably 'psst'.)

Bear Giles
bgiles@coyotesong.com