On Sun, Feb 22, 2004 at 11:58:10AM -0500, Marty Landman wrote:
> At 11:12 AM 2/22/2004, Matthew Seaman wrote:
> 
> >A proxy listens to all of your request, and then opens up a second 
> >connection to the real server (or another
> >proxy) for you and replays your request to it -- so all of the traffic is 
> >relayed through the proxy.
> 
> Newbie here Matthew. Could you please explain how a proxy differs from a 
> router? Or are they in many ways intersecting in their functionality? e.g. 
> I've got a class c network in my office and recently learned how to use 
> apache to reverse proxy a request so that http://my-ip-adr/fbsd becomes the 
> same as http://fbsd, where the latter is mapped to the ip addr for my fbsd 
> box on the lan by apache. (which btw is kind of cool)

Sure.  A router deals with network traffic at the IP level --
sometimes described as Layer 3 on the OSI 7 layer model.  In plain
English, the router doesn't care what's inside the packets: it just
looks at the IP numbers in the headers and relays the packets
appropriately.  A router will work for all sorts of traffic -- HTTP,
FTP, SSH, SMTP, whatever (unless you've deliberately added a packet
filter) -- unlike a proxy, which works at the protocol level: thus
you'll get an HTTP proxy or a FTP proxy or a SMTP relay or a DNS
recursive server -- the names vary, but they all do proxy service.
It's also common for proxies to cache previous traffic and reply out
of cache instead of going all the way back to the originating server,
but that's not a requirement.  Sometimes the software used to
implement a proxy is actually identical to the software you'ld use to
implement the originating server -- as commonly seen with most MTAs
and BIND and occasionally Apache HTTPD as you've done -- although
specialised proxying software is more generally used for HTTP and FTP
and the like.
 
> >The point of having inetd(8) is that it provides is a mechanism so that 
> >you don't have to have umpty-dozen different small servers running all of 
> >the time and taking up your process space.
> 
> I notice that mingetty runs ~ half a dozen instances on my box, waiting for 
> console users that will never come since as a rule I do everything thru ssh 
> on my windows workstation. And httpd, though I've cut the child process 
> spec down on the apache conf since it's not needed. Of course the saved 
> cycles aren't needed either in my current environment. :)

getty(8) is pretty light weight, and it doesn't take much extra memory
to run multiple copies of it.  It's also the case that while you may
not need to log in via the console during normal usage, when you do
need console access then you generally need it very badly.  
 
> Could httpd be set up to run via inetd instead of on its own? If so, is it 
> not typically done this way because it is usually the biggie app on 
> servers? Following that reasoning, if a server were primarily used for ftp 
> would it make sense to remove ftpd from inetd's conf file and instead start 
> it as a service, assuming that were possible?

You can run apache 1.3.x through inetd -- see the 'ServerType'
directive in httpd.conf:

    http://httpd.apache.org/docs/mod/core.html#servertype

As it says in bright red letters: "Inetd mode is no longer recommended
and does not always work properly. Avoid it if at all possible."
ServerType no longer exists in apache 2.0.x.

If you are running a busy FTP site, then yes, running a standalone FTP
daemon would be a good idea.  However, the server side configuration
for most FTP daemons is a lot simpler than for Apache, so it's
feasible to run ftpd out of inetd for much higher traffic than it
would be for apache.  Another common server where there's an option of
running under inetd is Samba -- however I think the trend nowadays is
to assume that the Samba daemons will run standalone.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to