Date: Fri, 22 Nov 1996 12:44:27 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: richards@herald.net (Richard Stanford) Cc: 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: <199611221844.MAA11034@brasil.moneng.mei.com> In-Reply-To: <Pine.A32.3.91.961122091120.129003A-100000@future.dsc.dalsys.com> from "Richard Stanford" at Nov 22, 96 09:23:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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. > On Fri, 22 Nov 1996, Steve wrote: > > In srm.conf you put > > > > UserDir public_html > > Or alternatively, set up a dedicated (slow/dumb) machine for users to login > to, specifically one that they can crash without bringing down any of your > essential services. Next, create a place on the webserver for users to put > their pages (ie: /www/users/ ) and create their directories underneath it. The > users must be in the /etc/passwd file for the webserver, but their password may > be * or something else so that they can never log in. Note you will want to prevent mail delivery, etc., as well. > Oh, almost forgot -- on the webserver, you can set UserDir to /www/users/ which > tells the engine to look here for user webpages. Even on a non-dedicated box, > this would allow you to put all webpages onto a seperate drive, rather than > having them intermingled with user's home directories. 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) > 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.. :-) A word to the wise: Potential ISP's really need to plan for future growth. Now. A tale of one local ISP... we will call them mumble.com. Started small. Had a single UNIX box. Told customers.. "Yeah, set your DNS server, your SMTP mail host, your POP mail host, everything to be mumble.com. When you need to get to your shell account, telnet to mumble.com. When you need FTP, it's mumble.com. Your mail address is user@mumble.com. Your Web address is http://mumble.com/~user." Every single one of those backfired on them. Their mail system swamped the machine, first. They moved mail services to another machine, NFS mounting the mail spool from the new machine, and NFS mounting the user directories from the old machine for .forward files. This caused endless problems, because people tried to break into the mail machine via forward file tricks, etc. Many people ignored the instructions to switch to "pop.mumble.com" for POP mail, and continued to use "mumble.com". Eventually Mumble Co. also decided to provide a "mailhost.mumble.com" for outbound mail, because of load problems. Their refusal to re-engineer things so that forward files would not have to be mounted off their primary (original, "mumble.com") machine has caused endless stress and irritation. Their lack of foresight in providing CNAME's for POP mail and outbound mail means that even today, "mumble.com" does lots of unnecessary mail work. They are terrified to disable those services on "mumble.com" due to the sheer volume of support calls they would get. Their DNS servers were not too hard to split off. Still, they had real problems maintaining the discipline to nail down an IP address for people to use. Web services are another mess. Even when they got a clue and set up "www.mumble.com" as a CNAME for "mumble.com", they botched it by telling dial-up users to FTP into "www.mumble.com" to update their Web content. The use of "ftp.mumble.com" for both shell and general FTP has also essentially locked this into being located on "mumble.com" as well. Uuuuugggggh. Then, when they did manage to separate "www.mumble.com" onto a separate machine, they insisted on NFS mounting "mumble.com"'s drives, so that they would not need to re-educate their users about where the Web home page data was supposed to go. This was accomplished with Solaris and its nifty CacheFS, and was a whole lot more effort than it should have been. Of course, they got a boatload of calls when people tried to ftp to www.mumble.com to upload their content - and couldn't, because they did not have an account. Their internal networking architecture is based on Ethernet switches, because no one realistically paid any attention to network architecture issues. They don't really have a clue about how to fix it, now. Their excuses are good enough that even I can't see a good way to do it without causing quite a bit of havoc. That wasn't true two years ago when I first started yelling at them about their (at that time, small, and still bad) network architecture. 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! If you do not PLAN to grow, when you DO grow, you will be in pain! 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 if you fail to consider all this now... well, there are many folks (myself included) who can repair your problems for you, but the cost is MUCH more expensive than doing it right to begin with would have been. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611221844.MAA11034>