Date: Fri, 22 Nov 1996 16:53:35 -0800 From: Richard Stanford <richards@herald.net> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: freebsd-isp@freebsd.org Subject: Re: The best way to allow users to access a WWW directory Message-ID: <32964B0F.3C88@herald.net> References: <199611222109.PAA11253@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Non FreeBSD specific thread ]
Joe Greco wrote:
> 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.
Amen to that. Many small, even underpowered boxes are, IMO, superior.
And after all, how much CPU /does/ it take to run sendmail and pop3d
(for instance)? Not a lot, and if they're the only processes getting
time, so much the better.
> > 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...
I was thinking more along the lines of:
% telnet www.example.com
Trying 192.1.1.1
Connected to www.example.com.
Escape character is '^]'.
Thank you for choosing Example.
Please telnet to telnet.example.com for telnet access.
Connection closed%
%
% telnet www.example.com 3232
Trying 192.1.1.1
Connected to www.example.com.
Escape character is '^]'.
Welcome to Example Webserver (nala.example.com).
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.
I would tend to agree -- assuming that FTP is a minor load. These days,
it seems that most vanity-domain customers don't even care about it
anyway -- it's a service that you have to ask for to get.
> 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.
Good point -- it's mainly for ifwhen a central mail hub starts to become
congested.
Anyone know when this point is, btw? Assume PP200 with gobs of memory
and disk, not even sure what the bottlenecks would be. I'd be willing
to bet that it would run out of network-speed before anything else,
though.
> 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.
This is the real point. Seperating services allows some invulnerability
to attacks that exploit a particular service. For instance, if you run
a seperate FTP server (useful for mirrors, etc...) and someone finds a
way to exploit your ftpd, the /only/ machine affected is your FTP
server.
Beware: next point may induce disagreement.
One point this brings up, though. If you don't have services on a
particular machine, really disable them. For instance, if you have a
dedicated FTP server, none of your other boxen should even listen to
ports 20, 21, 47, 69, 115, 152 or 215 unless there's a darn good reason
for them to do so.
Yes, this makes file transfers from, say, your shell account box to your
DNS server more difficult for you (you /have/ disabled rcp/rlogin,
right?) But the extra steps (FTP to your FTP server, then telnet to the
target box and FTP from your FTP server, deleting the files afterward)
don't really happen all that often.
Security can be a real pain in the *** up until the point you or someone
you know gets hacked. Then it becomes real (IMpersonalO)
> > 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.
Well, since the users will NEVER log onto the webserver, the home
directory in /etc/passwd is more for convenience in this case.
> 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.
Yay FreeBSD!
> > 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".
Good point.
> > 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.
[Sigh] This does happen.
As a side benefit to the small ISP, you look bigger than you are to the
moderately-clueful.
> 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.
[Grin] That's just too much work :)
> > 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.
[Snip]
> > 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.
>
> 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)
No problem at all! These names only translate to RFC1918 addresses on
your INTERNAL DNS servers. What's an internal DNS server? Let me
explain...
You, as an ISP, generally provide two distinct forms of DNS, usually
from the same box without caring about the distinction (which is fine).
These are:
1) Resolve /any/ name into an IP address
This is used mainly by your internal staff and dialup customers.
It may also be used by people with broken DNS servers, unless you
restrict its use to internal machines only (good idea). And as
long as you've done that, why not throw it off on a subnet that
the outside world can't even get to?
When it's used only by people inside your network, the RFC1918 IPs
that it resolves will work and be correctly routed.
2) Resolve any of your internal machine names (and custom domains, et
cetera) to an IP address.
This is used by people outside your network (ie: the rest of us) to
retrieve information about domains you're authoratative for. The
number of times this happens will be a lot less than the number of
times internal people resolve external names (unless you're heavily
into content providing) and you can easily estimate the maximum
size
of this process and rightsize it on its own box (2 boxes rather).
Once these functions are seperated, as long as each machine (mail, dns,
whatever) for instance has a routable IP address and an internal one,
you can use both fearlessly. This way, should you ever change it, your
internal customers won't have to change a thing and people outside your
net will suffer for the TTL of your DNS records (which would happen
anyway).
> Other than that, it is a pretty interesting suggestion.
Does this answer your "other than that"?
> 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).
Agreed. We split webpages up into personal (no guarantees) and
commercial (full vanity names, etc). While this makes me wary of
renumbering and having to change all the InterNIC records for the vanity
domains (unless we keep say a /28 to put our DNS servers on from the
same people ... hmm ...) that's the only problem I see.
And one thing we're looking to put into place is a seperation of
connection and name -- for instance, setup screen/conversation will go
something like:
... Well, there are the phone numbers, IP addresses, and
username/password and you're connected up. Now, for email, how would
you like your email address and personal webspace listed? We can offer
you names under:
a) herald.net
b) coolname.com
c) othercoolname.com
...
This is just an idea right now, but it would allow us to offer addresses
to people as buffy@domain.com (I hear so many people bitch about
@computer.domain.com addresses, for some reason (Vanity?)) but keep the
names within limits. When one starts to get full (one domain per
nice-sized mailserver/webserver too) we just discontinue selling it.
> 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.
Agreed -- you do not want ANY service you offer to suffer when ANY other
service you offer gets hit - this includes mailbombing,
attention-flooding as above, hacker-exploited weaknesses ...
> 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.
Agreed -- if you serve a supply of domains (anti- nice-internet
-standards, I know, but...) that all mean you, this may not become a
problem. In fact, give each domain you serve its own access phonenumber
off of your hunt group, remove any identification from your login
scripts, and you can even advertise as competitive ISPs.
This could let you sell a cheapie service ($10-20 a month, whatever your
area standard is) AND a $25/30 (or whatever) a month premium service
using the same hardware. Few people might go for the $25/30 but it
doesn't cost you anything other than minor advertising to offer it, and
you make more money from it. People who won't pay that much would just
go to the cheap service (you also :)
Just a thought. You could also target advertising differently, ie: use
the pricey service to donate time/accounts to PBS stations, etc... use
the cheaper one if you decide to advertise at a tractor pull.
Hmm...
> 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.
Agreed -- just not applicable to our business accounts.
> 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 :-)
Er, well, whatever. They should be different, in all probability... the
pricier accounts tend to be less accepting of downtime, for instance. I
would suggest, once you host some high-dollar virtual-domain or business
accounts, to consider mirroring your server.
Round-robin DNS is one way to do this, and works well (see DNS docs for
instructions). Mirror the 2 machines however you like (nightly,
realtime, whatever). When one goes down (and it will) simply add an IP
alias to the other for the address of the first (assuming they're on the
same segment) and you're in business. You'll have to alias any virtual
domains over too. A pain, but relatively fast and it lets you repair
the down box in peace.
Note: Round robin DNS like this can cause problems for CGI scripts that
aren't stateless -- for these, you may want to consider a very robust
CGI server. But if you're in the position where you care enough about
this problem to need to fix it, you probably already have one :)
> (Is that all clear, why I suggest doing that?)
Yes.
> 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...
[Grins] This assumes you even offer ftp to your users. If you do, I'd
suggest a different box for sure, maybe even use the custom domains
talked about up above (I think I'll pull herald.net from that list, that
way the corporate stuff is fully seperate ... big links from
www.cooldomainname.com -> www.herald.net should work ... still working
this idea out :)
> 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.
Agreed. Ideally, your shell machine should do one thing only -- be a
shell machine. A shell machine is the easiest thing to crash or get
CPU-Maxed, and you don't want any of your other services impacted when
(not if) that happens. Get a cheap box (expensive and good if you can,
cheap if not) and let the users play there. Reboot it every night at
3am or something (make this plain) and nobody should have any problems
with it.
> 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.
So very true. This is why many sysadmins find themselves doing
maintenance work. The best one I ever worked with (at a previous job :(
) spent the whole day doing nothing, and the machines just worked. This
is the sign of a good admin.
-Richard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32964B0F.3C88>