since June 7, 2001
This is a supplemental documentation to that on the OpenBSD web site's Frequently Asked Questions page (http://www.openbsd.org/faq/index.html),
This is also focused to the new user in a home or small office environment. Experienced Unix System Administrators will disapprove of a lot that I say (esp. on topics like partitioning). HOWEVER, I contend many of the "standard rules" of administering a system which gives shell access to a hundred or thousands of people are not important to the single user system, or the firewall or low-traffic mail and web server with no regular shell users.
(note: book mark this page, not the following links. I've decided I don't like how large this page is getting, so I will probably be rearranging the following links at some point)
9/10/2001 News: Started to reorganize the page, moving some articles out to separate files, and probably broke a few things, too. Not entirely sure how things are going to end up -- part of me wants to put each article in a separate page, it might make things easier for me to maintain, but I'm not sure if that is easiest for you to read through. Decisions, decisions...your feedback on this is always welcome!
10/20/2001 News: So much for re-organizing the page.
I have started to merge some of my articles here into the official
OpenBSD FAQ. As having multiple potentially conflicting pieces of
documentation is not good for anyone, as things become "official", they
will be removed from these pages. Net effect here will be a serious
De-Organizing of this page, but I think over all, it will be an improvement
to all.
2/7/2002 Update: Fixed up this article a bit...it was also missing from the table of contents. Thanks to Lars Hansson for pointing this out.
6/14/2002 As my official job in the OpenBSD project is maintaining the FAQ, this page is probably going to be SHRINKING, not growing now, as I merge relevant parts into the FAQ.
11/18/2002 Cleaned up a few things that were just plain obsolete.
11/24/2006 Cleaned up a few more things that were just plain obsolete. Kinda forgot this page was here....
Also: Many thanks to those who have offered feedback and comments in
the past.
Starting Out
Where do I find OpenBSD documentation and
resources?
Where do I find ISO images?
Disk Layout (moved to separate page)
After Install and first reboot, I get "Using partition 3 id 0"
How do I handle a large hard disk?
How should I partition my disk?
How big should I make my swap?
How do I resize a partition?
How can I do RAID on OpenBSD?
Can I boot from a software RAID partition?
Will that Promise IDE RAID board work on OpenBSD?
Why is 'df' showing my disk more than 100% full?
Hardware
Can I use my Parallel Port device (Zip drive, tape
drive, etc.)?
Can I use my floppy-tape drive (DC2120, TR1,
TR3, etc.)?
My NE2000 card isn't working!
My 3c509 card isn't working!
Using 21143-based NICs
What hardware should I choose?
Philosophy
Why are the OpenBSD lists so "unfriendly"?
Why doesn't OpenBSD offer a journaling file system?
Why isn't IPF in OpenBSD any more?
I just nmap'ed my default install OpenBSD box,
and I was surprised to find [whatever] was active!
Why does OpenBSD include packages like
Sendmail and BIND when they are known insecure?
I have some suggestions! Why doesn't anyone
listen to me?
Problems
I'm having troubles rebuilding and upgrading my system!
How do I add an installation package I forgot
on initial install?
My Compaq has lots of memory, but OpenBSD is only
showing 16M!
Other resources:
http://erdelynet.com/category/openbsd/
http://www.undeadly.org/
-- OpenBSD newsletter.
http://www.dpsite.com/1OpenBSDwww.html
http://www.nomoa.com/bsd/index.html
Mailing List Archives:
http://marc.theaimsgroup.com/?w=2
http://www.geocrawler.com/lists/3/OpenBSD/
http://www.sigmasoft.com/~openbsd/
There are "third party made" ISO files available. However, they are clearly NOT from the OpenBSD project, and as one of the key reasons to go with OpenBSD is security, this should certainly give you reason to stop and think..
There is no reason to download a 600M .ISO file to install OpenBSD. If you have the bandwidth to suck down five or so times as much as you need to achieve your task, you can do an ftp install, which works VERY well. I am a regular buyer of OpenBSD CDs to support the project, but I do virtually all my installs via FTP from a local FTP server.
But, I need a CDROM, and don't wish/afford to pay, or I need it TODAY!
If you truly desire a CD-ROM to install from and truly don't wish to
"do it right" and purchase a CD, you can easily make your own -- bootable
even! -- just pull down the install files you need (the contents of the
platform directory -- i.e., i386 for the IBM compatible systems), and burn
'em to disk. Note that SOME of the files have names that violate
the ISO9660 standards, this is o.k., the ones that are needed are ISO9660
compatible. If you can't burn a Rock Ridge (Unix naming convention)
CDROM, use pure ISO9660 standards. If your burner supports making
a bootable CD using a boot image (i.e., "Nero Burning ROM" under Windows),
you can even make it bootable using the cdrom40.fs file. Note that
the OpenBSD boot floppies can crash Win9x, so Adaptec's EZCD Creator's
requirement of making the image from a floppy doesn't work for me, your
results may vary.
Here is a (crude) step-by-step for a (crude) OpenBSD 4.0 i386 CD, created from a purely MS Environment:
Steve Shockley has instructions on building a very nice OpenBSD install
CD here:
http://www.shockley.net/obsd-bootcd.asp
As the largest popular floppy-tape drive was the 1.6G TR-3 and 1.6G isn't much any more, I doubt most developers are going to be working hard on this.
See above...
PCI and PC-Card (PCMCIA) NICs that claim to be "NE2000 compatable" are so incompatable with the real NE2000, you really got to wonder what they are meaning. "NE2000 compatable" to me means you can pull an NE2000 out and stick one of these cards in and have it take off and run. This ain't gonna happen with PCI or PC-Card devices! It is much more like "If you coded an NE2000, you can code our card with only a little difficulty". These cards are not being considered here. In fact, they are usually so bad and so cranky, I recommend you don't consider them, either.
Same goes for PNP NE-2000 cards. The NE2000 was NOT a PNP device, so pretty much by definition a card running in PNP mode is not NE2000 compatable. Worse, there are several different makers of "PNP NE2000 compatables", and their PNP features are..incompatable! So, I highly recommend disabling PNP mode from any ISA cards you can do so with, and the NE2000 is no exception.
The original NE2000 also had no software provisions for detecting media type -- the choices were thick and thin coax, anyway, and there were jumpers on the board to select between 'em. As a result, the OpenBSD driver does not attempt to mess with the media type for NE2000 cards -- this will have to be set by the installer using whatever facilities the card uses (jumpers, DOS-based setting program, etc.)
The rest of this section will assume you have an ISA card and have disabled any PNP features of it.
The most common asking of this question goes something like this:
"My NE2000 isn't working! dmesg shows it properly:
ne1 at isa0 port 0x300/32 irq 10
ne1: NE2000 Ethernet
so what is wrong?"
First, never "snip" your dmesg output. It isn't the entry of a single device that counts, it is the INTERACTION between them. Second, in the case of the NE2000, what dmesg is telling you is often NOT what you might think.
What dmesg says here is it found an NE2000 at I/O port 0x300, and it just assumed that the card was set to IRQ 10, because that is where an NE2000 is supposed be if it is at port 300.. This was the assumption that it made, not a test or discovery -- and it reflects reality ONLY if you made it so. By the way, NE2000 cards typically default to 300/3, so if you didn't set the card, it is almost certainly wrong.
OpenBSD supports three settings for NE2000 cards:
ne0 240/9
ne1 300/10
ne2 280/9
You will note that as ne0 and ne2 share the same IRQ, you can not have an ne0 and ne2 card in the same OpenBSD box.
You may also note that these settings are the reason the "real" NE2000 can't be used with stock OpenBSD: The Real NE2000 supported only I/O 300, 320 340 and 360, and IRQs 2,3,4,5. None of the OpenBSD supported settings are therefore able to be implemented on a real NE2000.
Note that you can use other settings for NE2000 cards, by using the boot time User Kernel Configuration (man 8 boot_config for details), however I advise new users to set their card to OpenBSD defaults, if at all possible.
NE2000 card performance is all over the map. I did some testing a while back, to see how fast 486 with an IDE drive could FTP data from a moderately fast local FTP server, changing nothing but the NIC, with OpenBSD (probably 2.6). I found almost a 2:1 difference between the fastest and slowest NE2000 cards. Fastest were the cards based on the AT/LANtic and Aritisoft chips, slowest were based on the Realtek 8019 chip. Guess which cards are the most available? You got it! The Realtek based cards. The AT/LANtic and Artisoft cards would pump data as fast as ANY ISA card I have tested, the Realtek chips moved data at about half the rate. Worse, there may be problems with bus availability on the lower-performing cards, causing problems with installed in pairs in a system (i.e., like on a firewall).
On OpenBSD 2.7 and before, there was a problem with SOME NE2000 chipsets
when at the card was set to 300/10. In these cases, the probe of
the 3c505 card (eg) would "kill" the NE2000 in such a way that it locked
the entire ISA system bus, and thus, the computer. The solution was
to either disable the eg driver or use the ne0 or ne2 setting for the card.
This was apparently resolved in OpenBSD 2.8 and later.
There are two primary differences between the 3c509 and the 3c509B -- the 3c509B supports Plug and Play operation and has a larger FIFO buffer, permitting more efficient use of the processors time. This can be very significant in some cases, totally unimportant in others.
According to the OpenBSD documentation, the cards names (ep0, ep1, etc) are allocated by MAC address. This is usually true, but I have found exceptions, and I can not explain them (and no one else tried). I HIGHLY recommend you write the MAC address of the card on the spine of the card, so you can see which one is which by looking at the dmesg output.
The 3c509 driver under OpenBSD is very flexible -- it supports basically any I/O port and IRQ combination the board makes available, and that makes it a very easy card to work with.
The OpenBSD support of the 3c509B in PNP mode, however, is imperfect. On some hardware (that with non-PNP BIOSs, I believe -- and as this is an ISA card, it is most likely going to be plugged into a non-PNP machine, right?), the ep driver will detect the card, then the OpenBSD ISAPNP support will configure the card, and OpenBSD will then detect the PNP settings of the card, giving you an ep0 and ep1 which are both trying to point to the same card. ep1 may be operational, or both may be stone dead. I *HIGHLY* recommend disabling the PNP mode of the card and setting it to your desired and non-conflicting settings before installing OpenBSD. This is done with a DOS utility which comes with the card or can be downloaded from 3Com. Note that the whole ISA PNP concept is imperfect -- the ISA bus was NOT designed to do "Plug and Play" -- it was added after the fact, and it does not work all the time, regardless of OS. For home users, ISA PNP cards may be fine (when they work), but for serious business use, a human brain should be involved in the setting of the card.
Note: the numbers here are very old, but I suspect the general effect is
still going to happen under some circumstances.
As indicated earlier, there is a performance difference between the
3c509 and the 3c509B. A single 3c509 in a computer will have very
similar performance to a 3c509B, and when used on the Internet, will rarely
be the performance bottleneck. A pair of 3c509Bs on an uncached 486DX2/66
can pass over 500kB/s -- that's over three T1 lines of performance.
However, a pair of 3c509 (non-B)s on the same 486/66 can be seriously hurting.
The limited buffering of the cards causes them to "trip over" each other
badly, not leaving much time for the processor to move data between the
cards, and will result in horrid filtering performance -- doing less than
40kB/s, one tenth the performance of the 3c509B pair. For this reason,
I reserve my older 3c509 cards for non-firewall applications.
However, here are some general tips. Most of my experience is on the i386 platform, so that is what I am speaking to here.
Processor:
I prefer a Pentium 100 or above, though slower chips can still be very useful.
I have found the DSA Key generation process (done first time after an OpenBSD
install) takes a very annoyingly long time on a slower machine, though
it is a one-time event.
Obviously, your patience is more an issue than OpenBSD's ability to run.
OpenBSD will run just fine on a 486DX, and even an 80386 with 80387 FPU
and sufficient RAM (few 80386 systems came with, and some don't even support,
enough RAM to run OpenBSD), assuming "just fine" doesn't mean any kind of
performance or deadline requirements.
Beyond this, it is dependent upon your application. A 486DX/2
can provide sufficient processor to be a "home" firewall, if teamed up
with a decent network adapter.
Memory:
16M is the absolute "minimum" for the i386 platform,
though doing an install with less than 24M RAM is mostly for those who
are into self-punishment.
16M is not very useful -- the system will be using swap before you get
a command prompt, though it will run.
Memory should be of good quality. OpenBSD (esp. compiling the
kernel) will sometimes expose hardware problems you never knew you had.
NICs:
ISA:
ISA NICs are often required for older 486 systems, and often found
in many people's spare parts piles. If you have a choice between
ISA and PCI, you should generally choose the PCI. ISA cards have
configuration issues which many otherwise advanced users are totally ignorant
of these days.
PCI:
In general, PCI NICs will give better performance (usually measured
by lower processor utilization) than ISA NICs, along with considerably
easier installation.
IDE vs. SCSI:
IDE drives are cheap. SCSI drives are comparatively more efficient
for the processor. If you are doing disk intensive work, you want
SCSI drives. They leave much more time for the processor to process,
less time spent baby-sitting the disk system. On the other hand,
for lower demand systems, IDE drives have great bang-for-the-buck.
Some people will contend that IDE drives are less reliable than SCSI drives.
I do not agree with this, in the ten or so years I have been doing server
construction, I will say that IDE drives have, over all, been far less
trouble than SCSI systems, and I know what I am doing with SCSI.
There have been exceptions -- certain IDE drives have been very short-lived,
but then, any long-time Macintosh or Sun tech can tell you about bad SCSI
drives, too. Virtually every OS I have worked with has had near perfect
support of IDE drives, SCSI support has been problematic way too often.
If you need the performance, SCSI is worth the trouble. If your disk
is just for booting, IDE is very nice.
Other box considerations:
OpenBSD is a very efficient OS. I have benchmarked Celeron 300MHz
filtering over 500kB/s (a T1 is about 150kB/s), and with only 64M RAM.
Anything more is waste. It has been reported by people running big
systems that if your box is filtering huge quantities of very small packets,
you may just need all the processor you can get your hands on, my numbers
here are more represntitive of a home or small office, outbound surfing
application with a simple rule set.
Recycling good old hardware is great, however, don't create headaches
for yourself by using BAD old hardware. If the hardware was unreliable
before, it probably didn't get any better with OpenBSD.
As one person (Rich Kulawiec) put it,
"Some of the people working on OpenBSD are nit-picking, anal-retentive, pedantic, intolerant, fanatical, insistent, demanding and relentless: in other words, the perfect people to be crafting an operating system."If you are looking for an OS written by people who are warm and friendly to the most silly of questions...look elsewhere.
http://www.openbsd.org/faq/faq8.html#Journaling
However, the goals of OpenBSD include that it is "Open" in the sense that anyone can do anything they choose to do with it. If you want to make your own CD and sell the same product as "ClosedBSD" for $5000 and no source code, you can do so. If you want to "borrow" some of the code from OpenBSD for use in your own commercial or free product, again, go right ahead. Unfortunately, this was not possible with the tight incorporation of IPF into the OpenBSD kernel, for restrictions were placed on what could be done with the code.
Now, this does not mean IPF can't be run on OpenBSD. It simply means that it can not be a core part of OpenBSD, because of restrictions placed on the use of the IPF code. This is contrary to the OpenBSD project's stated goals, so IPF had to be removed.
After the removal of IPF, Mr. Reed has again "clairified" his license
to make it compatable with BSD. However, this was done AFTER IPF's
replacement with Packet Filter, PF, was announced.
This is NOT the OpenBSD philosophy.
If "turning things off" equaled security, the only secure box would be an unplugged box -- which obviously accomplishes nothing. The goal behind OpenBSD includes the ability to use a solid, secure OS. Rather than achieving security through shutdown, the idea is to fix the security problems, and use the programs!
If you have all but one service blocked or disabled on your box, and that one service is insecure, your box is at risk. "Security though shutdown" doesn't make sense. Kinda like putting big locks on all your doors and windows...except one, with a big sign saying "Enter Here".
People often ask "Oh, but [whatever] is a known insecure service, it
shouldn't be on by default!". Theo de Raadt has given a very simple
response: "Demonstrate a remote vulnerability. You'll be famous".
The fact that a particular program is vulnerable in Linux or Solaris or
whatever does not mean the concept is fatally flawed -- it means those
specific
implementations are flawed. OpenBSD was code-audited for the
purpose of permitting its USE, not its disconnection.
If you have an idea, first read the lists for several months, see how many other people have suggested the same idea. Closely check the archives. Turns out that Theo and crew are pretty sharp people, odds are, they have probably thought of your great idea in the past, and they have probably rejected it for good reason.
Reasons may include:
A general rule: If you are qualified to fully think out a project,
you are qualified to implement it. Don't talk, demonstrate results,
and your idea might well be incorporated into the OpenBSD project.
While it isn't impossible, the likelyhood that you can "think up" a great
new idea that you aren't able to implement is very close to zero.
Or, borrowing from a fortune file, "When all is said and done, much more
is usually said than done"
Case in point: The new Packet Filter code was not developed by the group
of people babbling on the lists about "We should do an OpenIPF".
Rather, it was developed by one person who quietly put together a replacement
for IPF, and demonstrated results. The babblers achived nothing.
One person quietly plinking away at his keyboard set the new standard for
Open Source Packet Filtering.
It is not usually necessary you to build a kernal or system. It is not usually necessary for you to keep your system to -current. It is even rarely necessisary to keep your system at even -stable. The point of OpenBSD is the Release software is GOOD. It works! You don't NEED to recompile things.
"Oh, but the errata
list!" you say!
Look at it closely. Do those things actually affect you?
Is there any impact on you? Sure, something may say "SECURITY FIX",
but really...does it affect programs you use? In a way you use 'em?
If so, well, you better move up to "Stable" or re-evaluate your use of
that program. If not...why invite problems? OpenBSD prides
itself on the quality of the product it ships.
When I first started working with Unix-like OSs, two friends gave me bits of advice that I didn't quite understand at first. One told me "When upgrading, just wipe out the system and reload". The other told me "Upgrading Unix systems is easy!". Turns out they were both saying the same thing -- wiping out and reloading a well managed Unix system is not difficult, and it is the best way to do an upgrade.
This is not a Unix-Like OS quirk. It seems to be true of most OSs. Ask yourself, "If my current system is so good that I don't want to wipe it out, why do I want to upgrade?" Odds are, if there are features in the new version of the OS that are better than the existing version, you may want to change more than the version number. This is the time to do it.
Anyway...
YOU MUST SPEND TIME READING THE FOLLOWING TWO LINKS!
http://www.openbsd.org/faq/upgrade-minifaq.html
-- This document details the gotchas you will encounter when upgrading
your release of OpenBSD. This is not a maybe you get lucky and won't
encounter these problems, these are typically problems you WILL encounter.
Things beyond simple source change from version to version, from build
to build. You DON'T just download the latest code, compile and it
works. Not at all.
http://www.openbsd.org/anoncvs.html
-- This documents how you aquire and keep your source tree up to date,
or up to "Stable", using CVS.
Now for the next question: yes, an advanced user can upgrade from any version of OpenBSD to -current using source...but if you are not that advanced user, you might wish to realize that this is NOT a trivial trick. Upgrading a system from source is NOT a birthright. You can update from pre-built binarys. Esp. if you want to update to -current or a whole version (say, 2.8 to 2.9), do yourself a favor -- update from binaries, either the release or snapshots first, and if you wish to further tweek the system, fine. Don't expect to go from 2.6 to 2.9 via source and not have problems. Can it be done? Yes. By a "normal user"? Probably not. If you are reading this, you probably should not even try. I'm WRITING this, and I won't try to jump that far!
O.k., if you are REALLY convinced you need to upgrade by source, start by building a GENERIC, release system. The idea here is to find out if your hardware can do the build -- some just plain won't, but will run reliably for non-build work anyway (This is typically a memory problem -- gcc is very abusive to memory and will expose memory problems that nothing else will). It also demonstrates the whole process to you, and makes sure you know what step of the way you broke something.
Next, fetch the updated source. And again, build GENERIC. Don't start hacking at the kernel until you prove to yourself that GENERIC builds. This way, when you do start hacking at the kernel, and break something, there will be no question in your mind that YOU broke it...it isn't a source problem, you didn't discover some new bug. Read the Upgrade Mini-FAQ very, very closely.
Note well that the upgrade process updates the base system, but NOT /etc, which has to be done separately. It also doesn't upgrade installed ports.
Have I mentioned that upgrading an installed system isn't trivial?
http://www.openbsd.org/faq/faq4.html#AddFileSet
From 'man boot.conf':
machine mem +0x2000000@0x1000000
would add 32M of memory right after the first 16M.
Back to Technical Guides
page
Holland Consulting home
page
Contact Holland Consulting
since June 7, 2001
(C)opyright 2000, Nick Holland, Holland Consulting
It appears you used an old link that is obsolete now. Very
possibly, you pulled this out of a mail list archive, in which case, you
are to be praised for using the archives! Unfortunately, this page
grew too large for my tastes, and I have moved some articles to separate
files.
My appologies for both the inconvienience and the lack of foresite on my part.
Please click here to be sent back to the "Table of Contents", hopefully your desired article will be fairly clear from that.
-Nick.