Further Forming The New System

Enable One-Time Passwords
ls -ld /etc/ske*

The /etc/skey/ directory probably does not exist yet. (The /etc/skel/ probably does, so it will match the wildcard shown above.) The fact that /etc/skey/ doesn't exist yet is okay, but let's change that.

sudo skeyinit -E

Perhaps what this really ends up doing is nothing other than creating /etc/skey/ with drwx-wx--T permissions?

See impact of what has been done:

ls -ld /etc/ske*

It is rather unknown why this directory ends up going in /etc/ rather than /var/ since the data feels more like a “database” that gets updated, rather than a configuration file that will be largely untouched after initial initialization/configuration.

What's coming up

Note: Using one-time passwords may or might currently not be a part of this guide. However, for them to work as intended, they should be using a database that is unique per host. Otherwise, a password may be re-used on multiple systems. That means that an attacker who captures a password on one system may have a chance to use the captured password on another system. That is undesirable, so further actions related to OTP are not done until after child images are made. (This might, or might not, currently be addressed further at a later time, after a “firewall” child gets made... It wouldn't be bad to do then.) So, this is really just part of the process.

What this portion of the process does is creates a place where “one time password” data can be stored. Completing this step requires superuser (“root”) access, and indicates some interest in having “one time password” technology to be easily enabled.

Support using editor of choice

Follow this section: visudo: specifying editor preferences.

Preserve wheel's environment

Try this:

echo ${VISUAL}
sudo ${SHELL}
echo ${VISUAL}

Were you expecting that variable to lose its value?

That test can be reduced a bit, down to this single command line:

sudo ${SHELL} -c "echo \${VISUAL}"

There are some different approaches to let that variable have it's value.

Environment preserving

Use the -E command line parameter for sudo to keep the environment variable's value:

echo ${VISUAL}
sudo -E ${SHELL}
echo ${VISUAL}
sudo -E ${SHELL} -c "echo \${VISUAL}"
Initial login emulation

After becoming the superuser, re-initialize the popular variables by performing a normal login process.

echo ${VISUAL}
sudo -i ${SHELL}
echo ${VISUAL}

(Basically, the way this works is that the ~root/.profile command gets run.)

Alter the /etc/sudoers file

By altering this configuration file, the -E parameter can become unnecessary for some users.

Recommended actions: edit the /etc/sudoers file.

cpytobak /etc/sudoers
cpytobak /etc/sudoers
echo ${VISUAL}
sudo -E visudo

Find these lines:

# Uncomment to preserve the environment for users in group wheel
#Defaults:%wheel !env_reset

Remove the second “hash mark” from that text.

# Uncomment to preserve the environment for users in group wheel
#Defaults:%wheel !env_reset

Save the file, and then re-test.

sudo ${SHELL} -c "echo \${VISUAL}"
Checking for unsupported hardware
Check for devices needing additional support
Process for OpenBSD

Check for devices that don't have all of their firmware loaded:

fw_update -nv
Sample session
$ fw_update -nv
Path to firmware: http://firmware.openbsd.org/firmware/##/
No devices found which need firmware files to be downloaded.
$ echo ${?} $
Check for other devices that may not be working yet
dmesg | grep "not configured"

Got any?

  • At the time of this writing, this did not happen with any “virtual machine” software that this guide officially supported, when run under any “operating system” that this guide officially supported. (That only includes: Qemu under OpenBSD.)
  • The “detecting hardware” section is not part of this guide. So, if you choose to check that out further, realize that isn't part of this guide, and remember to return to this guide if you wish to complete it.
    • Taking care of the problem is recommended. This guide just doesn't provide details on how to do that, except for the section on: detecting hardware.

Enable hardware error reporting

Checking for disk errors might be less critical on a virtual machine, because actual hardware problems may be able to be detected by software running on a physical machine. However, if you would like to have this feature enabled, it is an available option.

Details are available at: disk error reporting.

Enabling firewall protection per host
Add support for shutdown script
support user database re-creation

OpenBSD stores its primary user information in /etc/master.passwd

OpenBSD (current versions)

(For now, these instructions are recommended to be done manually. Conversion to echo statements may be made later.)

Place the following at the bottom of /etc/useiffil.sh

[ -f /tmp/redousrs ]&&pwd_mkdb -p /etc/master.passwd
[ -f /tmp/redousrs ]&&rm /tmp/redousrs
[ ! -e /etc/spwd.db ]&&pwd_mkdb -p /etc/master.passwd
Historical note

The OpenBSD man page for pwd_mkdb refers to prior versions using mkpasswd.

OpenBSD 2.2 changes notes improvement being made to pwd_mkdb so it is unclear when that change took place. OpenBSD development reached version 2.0 quite quickly.

some disk-related adjustments
Second hard drive

As a standard, this guide recommends having two “primary”/“long term” storage devices on the virtual machines. This allows one hard drive to be a rather standard image, while custom data can be on a second image. Then, an upgrade can be performed on one disk image, possibly without even requiring any updates to the second disk image.

Make the second virtual machine use a second hard drive

Format it. This way other machines can use this base image (formatted drive) as a conveniently ready/available child image.

Then, here is one more task that is related to the topic of where data is getting stored...

Mount option optimization

There may be some benefits to adjusting the options that are used when the operating system mounts some of the “mount points”.


There can be some benefits from using the options. (After all, that is why the options even exist.) Optimization of these “mount point”-related options is a task that is widely charished.

In practice, some of these changes may cause problems, and this is generally not required. The benefits may be minimal, and related problems can be surprising. So there may be a good reason to avoid doing this.

This guide is going to provide instructions to proceed with this process, largely for educational purposes. Know that the guidelines provided here are NOT universally recognized to be the best approach in all circumstances. In fact, some decisions might work rather poorly with certain operating systems. One reason for that may be simply that different operating systems have frequently been known to use different layouts regarding the exact location/path where specific files have been placed (by default, and those locations are also where programs tend to look for specific files).


Opinions vary. At this time, this guide will make the recommendation (that not everyone will agree with) to simply use the defaults provided by the makers of the operating system.

However, if you are performing this task as part of a project, do also check if your project documentation has additional information about this topic.

Additional information is being provided here for reference (not necessarily as a strong recommendation).

Related text

Adjusting drive mounting

  • /usr should be set to “rw,nodev” or “ro,nodev”.
  • /home should be set to rw,nodev,nosuid
  • /var should be set to rw,nodev,nosuid
  • /tmp should be set to rw,nodev,nosuid,noexec

The recommendations are meant to apply to sub-directory mount locations. So, since /usr should be set to rw,nodev then other mount points like /usr/X11R6 and /usr/local and /usr/src and /usr/obj (if these additional sub-locations do exist as separate mount points) should also have the nodev flag.

Even more aggressive: /usr as read-only, or perhaps even / as read-only. (Make them say “ro” instead of “rw”.)

Note that if you make a “mount point” read-only, that can be changed to read/write access. Making such a change, even just temporarily so that a single file can be updated, is generally rather painless. The mount command may be required to change an option, but that probably won't be too big of an inconvenience if such changes are relatively rare (such as when correcting a mistake, since mistakes will hopefully happen relatively uncommonly).

These are based on some documented defaults from OpenBSD. It is believed that there are some various educated opinions, so consider these to be a basic recommendation and not something that is universally agreed upon.