Date: Fri, 22 Nov 1996 15:09:37 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: richards@herald.net (Richard Stanford) Cc: jgreco@brasil.moneng.mei.com, shovey@buffnet.net, david@wvb.gomel.by, freebsd-isp@freebsd.org Subject: Re: The best way to allow users to access a WWW directory Message-ID: <199611222109.PAA11253@brasil.moneng.mei.com> In-Reply-To: <32962647.781A@herald.net> from "Richard Stanford" at Nov 22, 96 02:16:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [ Note : Non FreeBSD specific thread below - delete if feeling
> incenedary ]
>
> Joe Greco wrote:
>
> > Well, I was not going to start discussing Web servers that had better
> > planning and engineering... :-) But that is not an inappropriate topic,
> > I guess.
>
> Never an inappropriate topic, I'd say.
I guess that depends :-) It is certainly OK for the ISP list though.
> > Note you will want to prevent mail delivery, etc., as well.
>
> Agreed -- one of the points here is that the webserver would do one
> thing: serve HTTP requests. That's it. You could double up with
> something like FTP, but there'd have to be a good reason, IMO. The box
> wouldn't even have to run most of the inetd services -- I'd leave
> telnetd, but not a lot else.
Good point, Richard. Actually that leads into one of my favorite things
to bash people over the head with... separate the concept of services as
much as possible onto independent machines.
> And telnetd could be moved off of port 23 for security reasons -- just
> have something sitting on port 23 displaying a happy little: "Please
> telnet to telnet.example.com for telnet access" or whatever :)
That's only a mild precaution. You can use a banner message for that,
or you can simply toss up a nastygram like I do...
% telnet smyrno.sol.net.
Trying 206.55.64.117...
Connected to smyrno.sol.net.
Escape character is '^]'.
sol.net Network Services - Milwaukee, WI
This is a restricted access system. Unauthorized access is prohibited.
For technical support or problems, please contact <service@ns.sol.net>.
FreeBSD 2.0.5R UNIX (smyrno.sol.net)
(ttyp2) login:
> Now if you're doing a box strictly for virtual servers, you may want to
> have each box handle SMTP, FTP and HTTP traffic for the domains it hosts
> -- (assume approx. 254) -- I'm of two minds about this. Opinions,
> anyone?
My opinion? I do handle all three on the box. FTP and HTTP clearly
both belong on the box. SMTP is less obvious: it is simply easier to
administer. Since my virtual box does not allow local mail delivery,
and simply rewrites/forwards all mail (mainly intended to handle mail
sent to "Webmaster@www.xyz.com") I did not consider it enough of an
issue to be more complex and set up the aliasing on my mail hubs.
A bigger operation, maybe afraid of a mail bomb, would definitely
want to do SMTP on a different box. A rare example of how I do not
always follow my own advice. :-) However, I will point this out:
IT IS TRIVIAL TO CHANGE THE BEHAVIOUR WITHOUT DISRUPTION IN THE FUTURE.
In those cases - and those cases alone - are compromises sometimes
acceptable.
> > DOH! Can you really do that? I suppose it makes sense... I usually did
> > that the hard way :-) (Ok, ok, I am not an Apache god)
>
> The hard way? I'm curious. But yes, you can. Assuming it's a
> dedicated webserver, you can even have it look in /www/u/s/username/
> without any hacks to the code -- simply define /www/u/s/username as the
Code hacks... guess it dates back to the days before Apache. :-)
I sometimes have a bad habit of perpetuating old sins.
> user's home directory, and have apache serve ~username files from
> there. Not a good idea usually, but since the only reason the user's
> even IN /etc/passwd for the webserver is to allow permission setting and
> they'll never log in ... not a problem.
As long as you take appropriate precautions this is probably fine.
> > > Don't bother -- just help the next person. It all evens out, everyone is
> > > happy, and we can all pretend that this is the internet of a few years ago.
> >
> > Is that why I spend so much time writing people messages... hhmmm.. :-)
>
> Maybe so. You (JG) certainly help a lot of folk -- and we appreciate
> it.
Sorry, possibly a too-cryptic reference to the fact that I think in many
ways this still _is_ the Internet of a few years ago :-) ...
For all the commercialization, etc., that has gone on, there is still a
lot of good will and projects such as FreeBSD seem to have drawn some of
the best and brightest people I know of.
> [good examples clipped]
>
> A good first step would be to have CNAMES for mail, www, etc pointing to
> the same box, if needed.
No, not "if needed". "Just Do It".
I forgot {,to mention} that the same ISP I described used to use their
upstream connection's NNTP server... well when they had to run a sed
script on 10,000 home directories looking for all references to the
news server in question.. ugh. Not to mention all the grief that they
went through getting people to switch.
A simple CNAME "news.mumble.com" would have saved them a day's worth of
effort.
> Some people are too smart for their own good
> though -- they use the IP address. Not a problem -- alias several IPs
> to your single UNIX box and have one for mail, one for www, etc ... when
> you get seperate boxes, move them to that real IP. Nobody will ever
> know :)
Actually I do that :-) Mostly because some software (mostly DOS/Novell
stuff) is too dumb to know how to resolve the name of a forwarding mail
host, etc.
Or you can be a mean, cruel, sadistic BOFH and move the IP number from
time to time, I have been known to do that too and take very little pity
on people who use IP's for things like Web server addresses.
Both are good policies for various reasons. :-)
> Another useful thing to do is to assign (through IP aliasing) RFC1918
> addresses (such as 192.1.1.x) to all of your internal services as
> above. Remember, your router should be configured never to send these
> to the outside net anyway.
>
> Then, you tell your customers, for instance:
>
> Gateway - 192.1.1.1
> DNS - 192.1.1.2
> Secondary DNS - 192.1.1.3
> Mail - mail.example.com (resolves locally to 192.1.1.4)
> News - news.example.com (resolves locally to 192.1.1.5
> or someother ISPs news server)
> Shell acct - telnet.example.com
>
> ... you get the idea.
>
> This way, renumbering your internal networks should be transparant to
> all end users without dedicated external IP addresses. Your virtual
> domain customers won't like it, but most of your customers will never
> notice.
>
> Just my US$0.02 -- YMMV.
Now that is a trick I had not heard of - or thought of! I do not like
for one simple reason: it means that your customers break if they
connect through some off-site ISP (or if you contract with some other
ISP to provide remote Point-Of-Presence services for you)
Other than that, it is a pretty interesting suggestion.
> > Lessons?
> >
> > People, service names such as "www.*" and "ftp.*" are MAGIC names. Once
> > you give them up to users, they are extremely hard to reclaim!
>
> I'm not really sure what you're getting at here ... can you explain?
Sure. This is much more subtle, and is more a matter of preference.
You have three basic kinds of non-virtual Web service typically provided
by a host: 1) Your own corporate web pages 2) Business customer web
pages and 3) Personal web pages.
Typically personal Web pages are distinguished by tilde... the other two
can, for most intents and purposes, be considered to be the same thing.
There will (!) come a time when even the load on a dedicated Web server
becomes too much. This is the basis for yet one further division that
allows you to separate out business Web services (generally lucrative)
from personal Web services (generally freebies accompanying a shell
account).
You do NOT want the business Web services to suffer when (!) some idiot
decides to post nudie pix on his Web page. You may also want to provide
for redundant servers, etc., for business Web services while not wasting
the resources on your personal Web pages.
I also believe that there is "prime real estate" in domain names, and
"www.*" is "prime real estate". Once you give someone a Web page at
"http://www.mumble.com/~user", they are camped there forever. You will
never be able to get them off of that address.
I generally recommend that business Web pages be published as
"http://www.mumble.com/company" and personal Web pages be published as
"http://web.mumble.com/~user" (or s/web/users/, etc). This allows the
two to be completely separate, and easily separated at a future date
onto two machines. (It's also probably a bit more secure.) Users will
gripe about "web" instead of "www", but they will accept it if it is
the option you provide from Day #1. You can install an intercept on
http://www.mumble.com to catch URL's starting with a tilde to point them
to the "Web" box and a little scolding message.
Now you have two separate operations, which are easier to manage and
maintain. The business customers get a P166 with 128MB RAM, the personal
customers get a 386DX/40 with 4MB RAM :-)
(Is that all clear, why I suggest doing that?)
The same thing is true of ftp.. if your users are used to being able
to put things on "ftp://ftp.mumble.com/pub/users/{username}", and that
changes, they will be irate. Yet you may wish to have a separate, secure
machine for your "main" FTP site...
Basically: It is particularly hard to break these services off from
your shell machine if people are used to them being tied to the machine.
Cut the strings now, not later.
Make sure your users never get used to doing something that you can not
support in the long term. That is really the basic principle.
> > If you do not PLAN to grow, when you DO grow, you will be in pain!
>
> [Nod] Very true. Plan to hit 100,000 accounts, and do everything you
> can to fit that model without sabotaging your current setup.
>
> It's an oldie, but: "If you fail to plan, plan to fail."
>
> > If you refuse to inconvenience your users a bit in order to re-engineer
> > your systems when you DO mess up, you will pay the price, forever.
>
> And it would be better to do it when small than large.
And failing that, if you have to do it when large, FOR CRYING OUT LOUD,
DO IT IMMEDIATELY. If you sit and wait six months, you will be twice
the size and it will be even harder to do.
Of course by that time they all think they know better and don't need
to follow that advice... and then six months later they are sorry.
THAT I have seen too many times.
... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611222109.PAA11253>