Note: the text below is taken from Advocating OpenBSD. I only changed and added a few lines myself. I guess 95% remained original text.
Both OpenBSD and FreeBSD are my operating systems of choice. I want to have many people use it, if only because then it has a higher chance of surviving. Many people want the same thing, and some of them are actively telling about OpenBSD and FreeBSD to other people, often in public newsgroups. This is advocacy, and it’s one good way to spread the word on OpenBSD and FreeBSD.

Unfortunately, some of these people seem to suffer from what has been called the Amiga syndrome: whenever anyone discusses computers, the stereotypical Amiga user will always claim that the Amiga is a better, faster, cheaper, more user-friendly computer than any other, ever, and any opposing view is treated as treachery, oppression, and a declaration of nuclear war. Some *BSD users are using the same tactics. They make both themselves and their preferred BSD flavor look bad. I’d like to stop this by making a few suggestions for advocating your favorite BSD flavor better.

Stay calm. There’s no reason to get excited. If someone says something about your BSD flavor that you don’t like, so what? It’s just computers, it’s not important. Read again.

Don’t take it personally. Even if a BSD flavor is your dream system, there’s no reason to be offended if someone points out problems with it (even if you wrote that part of the BSD flavor, which you probably didn’t). It’s not a statement about you personally. If they flame *BSD users, they’re idiots and you should ignore them. They’re probably just trying to get some attention.

Ignore flame baits. Like I said, some people just want attention. They enjoy starting long flame wars by cross-posting something insulting to several unrelated groups (e.g., both to Linux and OpenBSD groups). Don’t respond to these posts. It isn’t productive. If you’re not convinced, see it this way: either they’re just trying to get people angry or they will stick to their standpoints and won’t ever be convinced by someone telling otherwise. In neither case it’s worth to react to those people.

Stick to facts. If someone says something wrong about your BSD flavor, reply with the correct facts. Make sure they’re facts, though, not just something you heard about. Facts, not opinions. Don’t spread lies or rumors. Check your facts. If you don’t know how to do that, then perhaps you shouldn’t take part in the discussion, except perhaps by making questions. Even better, give references so that other people can also check the facts.

your BSD flavor is not flawless. It has bugs, including design problems. If someone points out something that is wrong with your BSD flavor, acknowledge it and do something constructive, like forward it to the proper maintainer or fix it yourself. Find a workaround. Write a summary of the problem and make it publically available. Don’t just whine.

Don’t flame other systems. Perhaps Linux does crash more often than your BSD flavor (although I have no hard data on this, just anecdotes, so I don’t know if it is true; remember, facts only). That doesn’t mean you tell it to every Linux user. If you must say something about other systems, keep to facts (and make doubly sure they’re facts) and present them. Politely.

Don’t flame people because they use other systems. Ever.

Bill Gates is not Satan. Some people claim that Microsoft’s business practices are immoral (or at least overly predatory). I don’t know if this is true, but using such claims as arguments does not make the discussion productive. Conspiracy theories sound really, really silly (as long as they’re theories; feel free to provide verified facts).

We aren’t taking over the world. There’s no reason to get offended if someone claims many more people use Linux than your BSD flavor. It’s true. It doesn’t matter. No-one knows how many users your BSD flavor has. That doesn’t matter, either. Market share isn’t the goal. Solving problems is the goal. Having fun is the goal.

Your BSD flavor can’t replace Windows. Windows has applications that your BSD flavor lacks. There’s no reason to get excited about it. Windows can’t replace your BSD flavor, either. No system is perfect for all things. Don’t make yourself look ridiculous by claiming that LaTeX is a better wordprocessor for the masses than MS Word. If you want your BSD flavor to have better applications than Windows, write them or encourage others with something better than talk.

Avoid cross-posts. Many advocacy discussions live long because they’re cross-posted to many popular groups for specific systems. Whenever someone says something about one system, there’s a whole bunch of people who will jump on him, just because he’s supporting a system different from their’s. If you must cross-post advocacy discussions, only cross-post to advocacy groups (such as comp.os.OpenBSD.advocacy). Never, ever cross-post to other groups, it ruins them. If you respond to an advocacy thread that is cross-posted to a non-advocacy group, remove the non-advocacy group.

Keep to the groups of your BSD flavor. Don’t go to other groups to pick a fight. Each advocacy group exists for discussion about one particular system. Don’t try to invade other advocacy groups. That’s rude. No-one likes big-mouthed strangers.

See also:

• Advocating OpenBSD, which was ripped and slightly modified to be presented right here (-:
• What Byte wrote about Linux users in Februrary, 1996

Setup I use:

- CPU: Intel Pentium-I 233MHz
- RAM: 128MB
- HD: 10GB, 15GB
- FD: 1,44″
- NIC: Realtek 8139, 3Com 3c905 100Base-TX

A log file of the installation process of OpenBSD 2.9 is available here. It was retrieved from a FTP mirror, not created by me. It is meant to give an impression of how the installation process looks like. The installation of OpenBSD 3.4 is just slightly different.

The OpenBSD v3.4 installation process went as follows (mail me if I forget important steps and/or info):

1. Connect to the nearest OpenBSD FTP mirror.
2. Go to the /pub/OpenBSD/3.4/i386 directory. Use something other than i386 if you install on an other platform.
3. Retrieve the installation floppy image (floppy34.fs). This should be enough to start the install in most situations.
4. Burn the installation floppy to a floppy disk:
   Example: dd if=floppy34.fs of=/dev/fd0
5. Boot the system from the floppy disk.
6. When asked for /bin/sh just hit the enter key.
7. For installation hit «i», for a upgrade «u». Only the installation option is covered here. I like clean installs.
8. If you’d like to use the complete disk for OpenBSD enter «yes».
9. Now configure your OpenBSD disk slice. This is done by the label editor. Type «?» for help, «x» to exit without saving changes and «q» to exit and save changes. To add an partition type «a x» where «x» is the partition you’d like to add. Type «p» to see all partions. Partition «a» is often the / (root) partion, «b» is reserved for a potential swap partition, «c» is a sort of symbolic partition representing the whole disk, the rest of the letters are free to (ab)use.

   You would probably a separate partition for /, /tmp, /var, /usr and /home. My suggestion for a small (2G HD, 32MB RAM) home server/workstation system:

   /     : 128 MB
swap  : 128 MB
/tmp  : 128 MB
/var  : 256 MB
/usr  : 1048 MB
/home : the rest

   If you got the space, a 10G harddisk for instance and 64MB RAM, you could do it like this:

   /     : 128 MB
swap  : 128 MB
/tmp  : 512 MB
/var  : 1024 MB
/usr  : 2048 MB
/home : 1024 MB
/vol  : the rest

   With a real small server, say 1G HD and 16MB RAM, you could probably do best by using this kind of layout:

   /     : 64 MB
swap  : 96 MB
/usr  : the rest

   And symlink /var, /tmp and /home to respectively /usr/var, /usr/tmp and/usr/home.

   Above layouts are rough indications and can vary enormously from system to system. Database servers might/should want a bigger /var for instance. A lot of users wanting space for their files could warrant more space being allocated to /home.

   Hit «q» to exit and save your configuration when done.

10. The install process then presents a chance to initialize more disks (if found) via the same process explained a step earlier. If you’re satisfied with your disk(s), enter «done» and hit return. The install process shows all partitions and their respective mount points of all disks initialized for you to review. Hitting return will show the next partition and its moint point. This is an endless loop. When everything is okay, enter «done» and hit return, to escape the endless loop and continue.
11. The install formats your disks and partitions and continues by asking if you’d like to setup networking. Answer the simple questions and hit return at the default answer of no, when it asks if you’d like to escape to a shell environment.
12. The install mounts your partitions and asks for the root password. Type it carefully and remember it! (-;
13. Next, if you’d like to run the XFree86 X Window System, answer yes to the question prompted. If your setting up a server, answering no will be a good decision in most cases.
14. Now, you’re ready to download the base install files via FTP, HTTP and some other neat protocols. Select your favourite and select which packages it should install. To select or deselect a package simply type in the full name of it, including the ending «.tgz».
15. When you’re done installing those nice tarballs answer no to the «extract more sets» question. The install creates some files in /etc and lets you choose your timezone. Select a cool looking zone and hit the return key.
16. Finally, you’re almost done! You only have to reboot the system now! But wait until the install process tells you it’s save, before doing that.

After installation of MySQL, you should edit the file /usr/local/bin/safe_mysqld:
Look for the line with a #-sign in front of ulimit -n 256. Remove that comment token and MySQL has some room to breathe.

Explanation: by default, a user is permitted to open only 64 files at a time. When you are greedy and want more, you should execute a ulimit -n 256 for instance. The MySQL binary package in de OpenBSD packages directory does not raise its limit of 64 files by default, so it runs out of file descriptors rather fast, leading to strange, seamingly inconsistent, errors.

Configuration directory:
/var/www/conf

Most important configuration file:
/var/www/conf/httpd.conf

Setting the default e-mail address as seen on the 404 pages, edit the ServerAdmin directive inhttpd.conf:
ServerAdmin alex@purebsd.com

If you want users being able to have a homepage like http://purebsd.com/~alex enable and set the UserDir directive in httpd.conf:
UserDir public_html

If you’d like to have Apache see index.php too as a valid index file, edit and/or set theDirectoryIndex directive in httpd.conf:
DirectoryIndex index.php index.html

If you’d like Apache to resolve IP addresses, for usage in logfiles, the REMOTE_HOST variable,/server-status page, etcetera, set the HostnameLookups in httpd.conf to this:
HostnameLookups On

If you don’t like Apache to report its version number and the hostname in 404 error pages, set the ServerSignature directive to Off in httpd.conf:
ServerSignature Off

Virtual hosts/domains

If you’d like Apache to serve up name-based virtual hosts you first you need to define on which IP address(es) Apache will receive requests for them. Your name-based virtual host names usually resolve to this/these IP(s). So, edit httpd.conf to have something like this:
NameVirtualHost 192.168.0.1
NameVirtualHost 42.2.1.21

Now, adding the so called virtual hosts (names) to Apache is rather easy. An purely arbitrary example:

# (www.)purebsd.com
<VirtualHost 42.2.1.21>
ServerName www.purebsd.com
ServerAlias purebsd.com
ServerAdmin webmaster@purebsd.com
DocumentRoot /var/www/htdocs/www.purebsd.com
ErrorLog logs/www.purebsd.com-ERROR
CustomLog logs/www.purebsd.com-ACCESS combined
</VirtualHost>

ServerName is the name of the virtual host you’d like to have Apache serve pages for.

ServerAlias is an optional directive, indicating all possible aliases for the same content (set of pages).

The ServerAdmin sets the e-mail address (only) for this particular virtual host.

DocumentRoot is very important. It tells Apache where to grab the pages/content of the virtual host. More accurately, it betrays the location of the directory holding the pages for the virtual host. http://purebsd.com/hoeba.html is translated into/var/www/htdocs/www.purebsd.com/hoeba.html

The ErrorLog directive dictates to Apache to which file it should log occurring errors.

CustomLog tells Apache about the whereabouts of the file where it should write the non-error events off our virtual host.

Sidenote: as to where the root of the DocumentRoot should be is mostly personal taste. Some like to put websites in /var/www/htdocs/, some in /vol/www/, others in /home/httpd/. Others mix it with a previously mentioned place for their own sites/special sites and use/home/user/htdocs-www.example.org for 3rd party users.

But for people still using the FTP service:

1. Download the ProFTPD source package:

   wget ftp://ftp.proftpd.net/pub/proftpd/proftpd-1.2.0rc2.tar.gz

2. Extract the sources:

   tar xvfz proftpd-1.2.0rc2.tar.gz

   And cd to the proftpd-1.2.0rc2 directory.

3. Configure ProFTPD:

   ./configure

4. Compile ProFTPD:

   make > /dev/null

5. Install ProFTPD:

   make install > /dev/null

6. Edit /etc/inetd.conf so that ProFTPD can take over:

   ftp stream tcp nowait root /usr/libexec/tcpd /usr/local/sbin/in.proftpd

7. Edit /etc/hosts.allow so that users may actually use your new shiny FTP daemon:

   in.proftpd: 192.168.0.

Install CVSup:
pkg_add cvsup-16.1g-no_x11.tgz
The «no_x11″ means that the cvsup program will be text-only. That’s fine.

Create a directory where CVSup’s configuration files and its bookkeeping data directory will be placed:
mkdir -p /usr/local/etc/cvsup

Create /usr/local/etc/cvsup/stable-supfile. This file will be used to tell CVSup to download all OpenBSD source code for the stable release branch you’re interested in, except for the x11, xf4 (both XFree86 related), www files and ports. In other words: everything that is needed in order to rebuild OpenBSD from source (located in /usr/src. We’re not interested in XFree86 for a server system, so we will skip it.

Working example stable-supfile:

*default host=cvsup.ca.openbsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default release=cvs tag=OPENBSD_3_4
*default delete use-rel-suffix

*default compress

#OpenBSD-all
OpenBSD-src
#OpenBSD-www
#OpenBSD-ports
#OpenBSD-x11
#OpenBSD-xf4

Create /usr/local/etc/cvsup/ports-supfile. This file will be used to tell CVSup to download the complete OpenBSD ports collection for the stable release branch you’re interested in, except for the x11, xf4 (both XFree86 related), www files and OpenBSD source code. In other words: everything that is needed in order to use the ports system (located in /usr/ports).
Working example ports-supfile:

*default host=cvsup.ca.openbsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default release=cvs tag=OPENBSD_3_4
*default delete use-rel-suffix

*default compress

#OpenBSD-all
#OpenBSD-src
#OpenBSD-www
OpenBSD-ports
#OpenBSD-x11
#OpenBSD-xf4

You probably want to change the «default host» in stable-supfile and ports-supfile to some CVSup server nearest to you. Check out this list of CVSup servers to search for one.

For checking out releases newer than OpenBSD 3.4 you must edit the «tag» in stable-supfile to reflect the version you’re interested in. For updates to the ports collection for OpenBSD 3.4 you must do the same. In order to allways download the latest ports, you must set the «tag» to a single dot (.).