Nick Holland's Quick Guide to OpenBSD

This is *NOT* in any way a comprehensive OpenBSD guide. Do NOT confuse
it for one! This is not to make you an OpenBSD master, but rather
to take someone who is very fluent with Operating System concepts, and
has experience with other systems, and knows the tasks they have to perform,
but are just trying to figure out where they go to perform them in OpenBSD

This is something I have tossed together to help my clients do day-to-day
administration of their newly installed OpenBSD systems. I will draw
comparisons to other OSs when I can, most often DOS/Windows and Novell
Netware. Much (but NOT ALL!) of what I say here is applicable to
most Unix-Like Operating Systems (ULOS), such as Linux, FreeBSD,
and of course, Unix. In these cases, I have used the phrase "Unix"
where I should probably have used "Unix-Like Operating Systems".

Virtually NOTHING of what I have listed here is anything close to comprehensive,
but rather, is stripped to the bone and concrete examples are given to
help you get to work, not make you a system administrator.

File Naming Conventions

Case Counts: In OpenBSD, as in all Unix-like systems, file
and directory names are case sensitive. Whereas Window9x will remember
the case you save a file name in, but access the file regardless of case,
you can have the files Nick, nick, NICK and
nIck
as four different and totally unrelated files under Unix. By convention,
most file names under Unix are in completely lower case, but that is just
convention, and there are plenty of violations. Be aware that a directory
search for files matching 'n*' would only display 'nick' and 'nIck',
but would not display 'Nick' and 'NICK'. Unix considers
the letters 'n' and 'N' every bit as different as 'a' and 'b'.

File Names: Ready for this? Virtually any character
you want is a valid character in a file name. The one hard exception
to this is the character '/', which is reserved as the directory separator.
A firm exception is the binary 0x0 character, apparently it is legal, but
likely to REALLY cause problems with many programs, not to mention being
hard to type. Spaces are quite legal, but again, really a pain to
deal with, and I'll advice you against them, although a Unix system administrator
will probably want to know how, as it will happen. I would avoid
backslashes, again they are a pain to deal with. I can see rare places
where a leading '-' characters could cause problems, but that should be
very rare. As for a limit to the number of characters you can have in a
file name, don't worry about the OSs limits. Long names will cause
the users far more trouble than it will the OS.

Extensions: DOS and Windows users are used to a three-letter
extenuation to indicate the type of a file, separated by a period from
the file name. Unix has NO concept of "extension" in the OS itself
-- it is just a one-part file name. Whereas the "." isn't actually
stored in DOS file names, it is a literal part of the file name in Unix,
and is precisely the same as any other valid character. Thus, there
are no separate limits to the length of the file extension (if any) in
Unix. Nor, is there any limit to the "number" of extensions, as there
is no such thing as an extension -- it is just something a user tacked
on to make it clear to the user what it is.

For example:
ports
may
be a directory.
ports.tar may be the
contents of the directory 'tar'ed into an archive using the tar program
ports.tar.gz may be the above tar file
compressed using gzip. But, maybe not. It could just be a file
called ports.tar.gz.

If you plan to untar the above ports.tar file, if you lived
in the DOS world, you might expect you could just specify the name 'ports'
minus the '.tar' extension. You would be wrong. In
virtually all Unix commands, you must spell out the entire file name, the
'.tar' won't be assumed, it is just there because someone thought
you might appreciate it. The programs are typically quite indifferent.
If you could remember that ports.tar was a tar file, you could always rename
it "fred".

Directory and file name separators: Directories and file names
are separated by forward slashes, not the back slashes that DOS uses.
So, for example while DOS might use:
C:\USER\BOB\WORK\TEXT\Unix would do something like:
/users/bob/work/text/It was pointed out to me that I should point out who screwed up.
The original DOS v1 didn't have subdirectories, so they used forward slashes
to indicate command options. When they put subdirectories in DOS
v2, the forward slash was already in "common" use as a command option indicator,
so MS in their incredible (lack of) foresight, chose to use back slashes,
something which has caused no end of trouble for programmers and users
ever since.

Disk Identifiers: DOS and Windows users are used to referencing
physical drives by letters, i.e.,. A: being a floppy, C: being your hard
disk, say E: being your CD-ROM, F: being your network server. Unix
does not do this.

Unix considers the whole "file system" as a tree. The "root" of
the tree is referred to as / and anchors the entire tree.
The root of the file system is normally the booting hard disk, but things
can get weird. All other physical or logical partitions are mounted
at some point on the tree. Philosophies on this vary greatly.
I believe in everything in one partition unless there is an overriding
reason to do otherwise -- and there is often an overriding reason.

An example:
/ Might be a small,
100M partition
/usr might be a bigger, 1G partition
/var might be a big 3G partition
but it all is hanging off the same root.

Before you can use anything like your CD-ROM or floppy drive, you must
deliberately mount the volume. This is very contrary to DOS convention,
but typical for any multi-user system. You don't change media without
verifying that no one else is using it!

Maneuvering around in the directory tree:

cd Change
Directory, just like DOS, well, sorta. cd entered without
a parameter returns you to your "home" directory.

mkdirMake Directory.
Just like DOS, except most of us got lazy and started using the DOS shorthand,
MD, which is NOT a Unix command.

rmdir Remove Directory, again
just like DOS, but again, Unix does not accept the DOS shorthand of RD

rm Remove
(delete) a file
USEFUL (but DANGEROUS!) VARIANT:rm
-r dirname This will recursively delete
all files within a directory, then remove the directory itself. Much
like the DOS DELTREE command, but it doesn't ask you to verify every subdirectory.
It assumes you told it to do what you wanted it to do. This is where
the danger comes from.

ls List
Directory contents, similar to the DOS DIR command, except by default,
less information is displayed. Other useful variations:
ls -l "long"
listing, including details like the access rights, the owner of the file,
size of the file and date of the file, etc.
ls -a list
"all" files and directories, including those that start with '.' (which
normally hides them)

mv Move
a file. DOS has two commands which attempt to duplicate this single
command: REN (to rename a file in place) and MOVE (to relocate a file to
another place in the file system).

VERY useful Unix commands, and typical syntax:

Keep in mind this is just an INTRODUCTION to these commands! Most
of these commands have MANY more options than this.

man The
Unix Manual command. As a friend of mine puts it, "man is your friend!".
Usage: man vi will bring up the man pages
on the vi program. man -k tcp
will bring up a list of command which relate to tcp (actually, it is searching
for the text 'tcp' in the man pages)

more
A "filter" program which pauses the output of another program at the end
of each screen, popping up a prompt to have you hit a key to continue.
Compared to the DOS MORE command, the OpenBSD more does, well, more.
Hitting ENTER will advance the screen one line. Hitting space will
advance an entire screen. Hitting 'B' will roll BACK a screen.
Up and down arrows will often do exactly what you would expect, as will
PGUP and PGDN under many circumstances. Typical use:
ls |moreOne can also use more as a file viewer, by entering the file name on
the command line:
more readme.txtOlder Unix manuals might suggest using the cat command to view files.
Use more instead. Much nicer command. Note that not all Unix-like
OSs have as full-featured a more command as OpenBSD.

vi A
full screen text editor. Also a chapter (book...) in and of itself.
Word 2000 it is not, but it is a very powerful, very capable editor, but
your preconceptions of what an editor is are best left behind. Before
condemning it as difficult and unusable, consider that most Unix OSs were
written in vi. Assume any "limitations" you identify in the program
are limits of your understanding, not design flaws of the program and you
will be happier.

su "Substitute
User" or sometimes "Superuser": Assume the abilities of another user.
If no user name is specified (a common use if not THE most common use),
the program will attempt to grant you the rights of the "superuser", root.
Obviously, the program doesn't just switch users for you, you have to have
the required password. Most modern Unix-like systems do not permit
you to log in directly as root from anywhere but the system console, so
to remotely administer a Unix system, you log in as a normal user and su
to root. It also has the advantage of letting you quickly jump in
and out of "administrator mode". A useful variation is to run
su -
which changes the user's ID, and also processes startup files, just
as if you had logged in as the root (or whatever) user.

adduser Interactive
program to add a new user to the system. Fairly self-explanatory
when run.

rmuser Removes
a user from the system.

vipw (OpenBSD
specific) Directly edit the user information database files. In old
Unix systems, this was the file /etc/passwd, but in OpenBSD, /etc/passwd
is actually just a shadow of the "real" user information database.
Many Unix applications require access to the passwd file to pull out important
user information. Unfortunately, in the standard /etc/passwd
your password is sitting right there, yes encrypted, but crackable.
This moves this information to a file that can be only accessed by root.
For this reason, do not directly edit /etc/passwd -- you will
find your changes being undone!

tar Tape Archive.
Very powerful Unix command. You need much more information than what
I give here, but here are a couple very useful command lines:
tar cvf dest source...
Creates an archive to the File dest consisting
of all the specified source files and directories, and
be Verbose about it. A SCSI tape drive on an OpenBSD is typically
/dev/st0, so to backup the /usr, /home, /etc directories to tape, you could
use:
tar cvf /dev/st0 /usr
/home /etc(It has been pointed out to me that having the leading slash on the
source paths is not a good idea on many ULOSs,
but this is not an issue under OpenBSD. Be forewarned.)

tar xvf sourceeXtracts
the contents of the tar File named source to the current directory,
again Verbosely naming all the files as it does its job. To extract
the contents of the tape to the current directory, you could use this command:
tar xvf /dev/st0

With tar, you will definitely want to RTFM.
But some starting command lines are really nice to have.

Important files in an OpenBSD system

There are many configuration files in an OpenBSD system, although I have
found them amazingly easy to work with.
/etc/myname
The system name.

/etc/passwd
The user-accessable user list. Don't edit this file,
it isn't the place where "real" information is stored!

/etc/adduser.conf Default
new user information

/etc/rc.conf:
Lots of system startup options.

/etc/motd
Message Of The Day. The contents of the file are
displayed when a user logs into the system.

Networking configuration/etc/mygate
The system default gateway

/etc/hostname.* The
configuration information for each interface card (i.e., hostname.ep0 would
describe the ep0 interface), including ip address.