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

In order to have a smooth working system administration process, the various system administrators somehow have to cooperate in a specific way.

Book keeping

Some bookkeeping helps in this process:

1. /root/MUTATIONS:
   A file where each atomic action of a sysadmin is documented. Preferable with date ordered entries.
2. /var/mail:
   Make use of the e-mail phenomenon to update your co-admins of the latest important changes!
3. /etc/motd:
   Update this file to inform your co-admins and users of important changes.
4. /dev/oral/communication:
   Use this device to communicate with your collegues before doing anything that could have/will have a rather large impact on the running system.

Other points of attention

Having some standard habits and procedures can be helpful too:

1. *-dist files:
   If a sysadmin is the first to alter a certain file, for example /etc/rc.conf, it is wise to make a backup to /etc/rc.conf-dist, in order to preserve the original file. Later on, you can review the differences between the original and the new version of that file.
   If a *-dist file already exists, it should NOT be over- written. When you’d feel safer to have a backup of the latest version, copy the file to something like *-old. The *-dist files are the original files of the original installation of the Operating System you’re using.
2. installations of third party sofware:
   If you need to install a program that’s both in the binary package collection and in the /usr/ports collection, choose for the former. No needless compiling and wasting diskspace, bandwidth and CPU cycles.
3. installation of already present software:
   Make use of the already present software on the system. OpenBSD for instance, comes with Apache out of the box. No use retrieving, compiling and installing it yourself. Installed software has been reviewed by the OpenBSD team, who patch it when necessary for security fixes.

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.

/var/www/htdocs/manual – HTML documentation for Apache

/usr/share/doc/html/bind – BIND9 HTML documentation

/usr/share/doc – Many docs for applications found on an OpenBSD install

Useful to beginners:

• help(1) – help for new users and administrators
• hier(7) – layout of the OpenBSD directory structure
• afterboot(8) – things to check after the first complete boot
• man(1) – display manual pages
• ls(1) – list directory contents
• less(1) – view text files
• kill(1) – terminate or signal a process
• ps(1) – show process status
• top(1) – display and refresh information about the (top) CPU processes
• ftp(1) – FTP program (client)
• lynx(1) – Text-based webbrowser

Useful to intermediates:

• afterboot(8) – things to check after the first complete boot
• netstat(1) – show network status
• dmesg(8) – display the system message buffer
• find(1) – walk a file hierarchy
• locate(1) – find filenames quickly
• sh(1) – public domain Bourne shell
• grep(1) – search for patterns in files
• mount(8) – mount file systems
• df(1) – display free disk space
• du(1) – display disk usage statistics

Useful to more advanced users:

• route(8) – manually manipulate the routing tables
• ifconfig(8) – configure network interface parameters
• fstab(5) – static information about the filesystems
• xargs(1) – construct argument list(s) and execute utility
• awk(1) – pattern-directed scanning and processing language
• dd(1) – convert and copy a file
• strings(1) – print the strings of printable characters in files
• options(4) – miscellaneous kernel configuration options

1. Download the PHP source package:

   wget 'http://www.php.net:8000/distributions/php-4.0.6.tar.gz'

2. Extract the sources:

   tar xvfz php-4.0.6.tar.gz

   And cd to the php-4.0.6 directory.

3. Configure PHP:

   ./configure --with-apxs --with-mysql=/usr/local \
--with-config-file-path=/var/www/conf --disable-xml \
--disable-pear --enable-bcmath --enable-magic-quotes

   Leave out the --with-mysql=/usr/local option if you don’t want MySQL support or MySQL is not installed.

4. Compile PHP:

   make > /dev/null

5. Stop Apache:

   /usr/sbin/apachectl stop

6. Install the PHP module:

   make install

   or copy the libphp4.so.0.0 in the .libs/ directly to/usr/lib/apache/modules/libphp4.so if you like that better (-:

7. Edit /var/www/conf/httpd.conf:

   Make sure that the following line is present and commented out:

   LoadModule php4_module /usr/lib/apache/modules/libphp4.so

   Search for “#AddType application/x-httpd-php .php” and remove the # in front of it, thereby telling Apache the line isn’t a comment anymore.

   I added also the .php3 extenstion to it, so files ending in .php3 are also processed by the PHP engine. The end result:

   AddType application/x-httpd-php .php .php3

8. Start Apache:

   /usr/sbin/apachectl start

Packages are the binary equivalent of the ports, prebuilt by the OpenBSD team for your convenience. Though there are far less prebuilt packages than there are ports available through the ports system in /usr/ports.

Installation of a package

If you don’t have them stored locally, packages can be found online in a directory on a FTP mirror site. Something like ftp-site/pub/OpenBSD/2.8/packages/i386/ for instance.

Installation from harddisk:

pkg_add tcsh-6.09.00.tgz

Of course, you could also install via the internet:

pkg_add ftp://ftp-site/url/tcsh-6.09.00-static.tgz

Ports are third party software which haven’t had the thorough security audit as the native OpenBSD programs have had. The ports collection is installed on your disk as a large tree of directories representing the various programs with in them a Makefile which specifies the information needed to install a particular port.

Installation of a program in /usr/ports:

1. Retrieve /pub/OpenBSD/2.8/ports.tar.gz from the nearest OpenBSD mirror.
2. Install with:
   cd /usr ; tar xvfz /tmp/ports.tar.gz
3. Then cd to the directory of port you’d like to install.
4. Run make as user root and the source tarball retrieval, unpacking, configuration and compilation processes start automagically
5. Run make install as user root to install the package.
6. Afterwards, a .tgz binary package of the software you just compiled and installed can be found in /usr/ports/packages/arch/ which you can use to speed up the installation process on other machines for instance.

Logcheck is a program that helps you in sorting out the relevant messages from the various (system) log files on Unix systems. It sifts through them on a regular basis (via crontab) and sends its findings to the system administrator by mail. That mail contains all the possibly important events, break-in attemts and other strange messages.

It was created by Psionic Software (now merged with Cisco) and is confirmed to run on many of the most popular Unix systems, including OpenBSD.

Download

Since www.psionic.com isn’t providing the package anymore (because of the merger with Cisco), you can download Logcheck from PureBSD.

You can also install the port (or package) called “logsentry”. LogSentry and Logcheck are the same thing, but since Psionics merger with Cisco it lives on with a different name.

The port is located in /usr/ports/security/logsentry. The binary package has a name equal or similar to “logsentry-1.1.1p1.tgz” and can be found on any FTP site carrying OpenBSD.

Installation

By source:
cd /tmp
tar xvfz /location/of/logcheck-1.1.1.tar.gz
cd logcheck-1.1.1
make generic

By port:
cd /usr/ports/security/logsentry
make
make install

By binary package:
pkg_add logsentry-1.1.1p1.tgz

Configuration

Make sure that /usr/local/etc/logcheck.sh is setup the way you prefer.

If you do not want to have root receive mail from Logcheck, but a local user or remote user, edit the SYSADMIN variable:

SYSADMIN=alexdehaas@puur.rookgordijn.nl

All “$LOGTAIL” lines should be commented out, except the ones for the OpenBSD log files:

# Generic and Linux Slackware 3.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$

# OpenBSD 3.4
$LOGTAIL /var/cron/log > $TMPDIR/check.$$
$LOGTAIL /var/log/authlog >> $TMPDIR/check.$$
$LOGTAIL /var/log/daemon >> $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
$LOGTAIL /var/log/messages >> $TMPDIR/check.$$
$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
$LOGTAIL /var/log/wlanlog >> $TMPDIR/check.$$

Running Logcheck

Edit root’s crontab:

crontab -e

And add the following two lines:

# Security: Check every 30 minutes logfiles
*/30 * * * * /usr/local/etc/logcheck.sh

Filtering log messages

If you do or do not wish to see certain log messages mailed to you, you can edit thelogcheck.[hacking,ignore,violations,violations.ignore] files located in/usr/local/etc. All lines in those files are patterns in the regular expression format used bygrep.

• logcheck.hacking:
  This file contains lines which consist of patterns indicating an active system attack. You can add your own patterns to it when deemed necessary.
• logcheck.violations:
  This file contains lines with patterns indicating some sort of negative system activity. You can add your own patterns to it when deemed necessary.
• logcheck.violations.ignore:
  Lines of patterns in this file are used to filter out log messages thatlogcheck.violations picks up as being negative system events. In other words: the more specific pattern lines in logcheck.violations.ignore override the more generic pattern lines in logcheck.violations.

  You can add your own exceptions to it. Examples:

  sendmail.*: .*: Authentication-Warning: .*: .* owned process doing -bs
sm-mta.*: ruleset=check_relay, .* reject=.* .*


• logcheck.ignore:
  This file contains lines with keywords indicating that a message should not be reported. Normally, all log messages are reported as “unusual system activity”, so you won’t miss anything not accounted for in the other logcheck files. So this is a catch-all file.

  You can add your own exceptions to it. Examples:

  dhcpd: DHCPDISCOVER from .* via xl0
dhcpd: DHCPREQUEST for 10.0.* from .* via xl0
dhcpd: DHCPOFFER on 10.0.* to .* via xl0
dhcpd: DHCPACK on 10.0.* to .* via xl0
wlanmon: WLAN bridge connection is just fine\.
syslogd: restart
spamd.*: .*\..*\..*\..*: connected \(.*\)
spamd.*: .*\..*\..*\..*: disconnected after .* seconds\.
spamd.*: .*\..*\..*\..*: \<.*\> -\> \<.*\>
spamd.*: .*\..*\..*\..*: From: .* To: .*
ftp-proxy.*: accepted connection from 10.0.0.*:.* to .*
cvs.*: connect from .*.intranet.atomicvoid.net

  Now log messages matching any of the above lines are being ignored by Logcheck.