Setting up Web services
Most large Web hosting companies run multiprocessor PII and PIII machines to handle their high workload. Since we were just starting out and our old colocated P90 Linux server with 64MB RAM handled 50,000 hits a day without breaking a sweat, we figured that, until we got busy, our two existing AMD K6 systems would be perfect for our personal and client Web servers. Both K6 systems were basically the same, but we opted to use the K6/233 for fire and the more powerful K6/266 for wind.
fire.shn.nu
Fire was built first because we needed a machine to act as our testbed and production server for our corporate and project Web sites. All new configurations and software are tested on fire before going live on wind, and most interactive development packages from the ports tree are installed because fire is also used as the primary staff shell server.
All OpenBSD packages were installed via FTP from earth and all non-essential services were disabled in single user mode before bringing the system up on the Net. Because this was going to be a staff production system, quite a few services were left enabled and installed.
As with all of our systems, SSH was the first software to get installed to allow for secure remote access. Qmail was then installed and configured for virtual domain support with no relaying. With this configuration, qmail only allows inbound email or outbound email originating from localhost. Also, e-mail for each domain is handled by its own individual account and users have full configuration over aliases and forwarding without root intervention.
MySQL was then installed from the ports tree for all Web sites that need database interaction. A simple make; make install in the ports tree took care of everything and the MySQL server was up and running. The only additional change made to the default configuration was to create a mysql user, change the ownership of /var/db/mysql from root to mysql and make safe_mysqld launch as the user mysql user from rc.local.
A database is useless without a bridge to get data to and from the Web server, so PHP3 was installed. This required recompiling Apache from scratch in /usr/src/usr.sbin/httpd, so the Configuration file was modified to add in all the extra modules that we needed, ./Configure was run and then the PHP3 module was installed into the Apache source tree. Other various modules were added as well and then Apache was recompiled and dropped into /usr/sbin. Once compiled, suexec was also compiled and dropped into the Apache sbin directory to allow for secure execution of CGI binaries.
Once all of the servers were set up, niceties such as Emacs and Pine were installed from the ports tree. Deciding which applications get installed is simply a matter of user preference, so take a look through /usr/ports and do a make install for anything that looks interesting. Pre-built binaries are also available from ftp.openbsd.org. Smaller applications are just fine to run from precompiled binary packages, but larger applications that need tuning (Apache, MySQL, etc.) should be compiled from the ports tree on the system they will be running on.
wind.shn.nu
Wind is an exact mirror of fire and acts as the clients server. The only difference between wind and fire is that miscellaneous applications may get installed at each client's request (IRC scripts, etc.).
akasha.shn.nu
Akasha is the watchful eye that makes sure all is well out in the DMZ. It sits on a hub between the DMZ switch and the DMZ ethernet port on the router and constantly runs a sniffer and network analyzer to look out for "interesting" traffic. The main purpose for this is to keep track of per-MAC address accounting and to look for denial of service attacks or other nasty packets that may come across the fiber. Depending on the requirements at the moment, akasha may be the Team Internet 486dx2/66 running OpenBSD or a Macintosh IIcx running Mac OS 7.5.5.
پاسخ با نقل قول