Date: Fri, 22 Nov 1996 14:16:39 -0800 From: Richard Stanford <richards@herald.net> To: Joe Greco <jgreco@brasil.moneng.mei.com> 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: <32962647.781A@herald.net> References: <199611221844.MAA11034@brasil.moneng.mei.com>
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. > > 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. 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. 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 :) 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? > > 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) 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 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. > > 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. > A word to the wise: > > Potential ISP's really need to plan for future growth. Now. Very true. > 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. [good examples clipped] A good first step would be to have CNAMES for mail, www, etc pointing to the same box, if needed. 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 :) 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. > 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? > 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. -Richard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32962647.781A>