probing: pc0 com0 com1 apm mem[636k 190M a20=on] disk: fd0 hd0+ >> OpenBSD/i386 BOOT 3.26 boot> boot -s
# fsck -p / && mount -uw / # fsck -p /usr && mount /usr
"Wait. That looked too easy! That isn't very secure!" If an attacker has physical access to your system, they win, regardless of the OS on the computer. There are ways to force the use of a password on single-user mode, see ttys(5), or eliminate the pause on i386/amd64, see boot.conf(8). Getting around those tricks is also pretty easy. One way would be to boot from a CD or USB drive and edit (or replace) the password file. You can try to prevent that, but then someone will pull the hard disk out of your computer. Making your computer difficult to manage properly isn't real security, and if you don't have the physical machine secured, you have no real security.
Note: many "remote management" systems give most of the functionality of physical access to the computer, and that needs to be considered. Don't tell yourself the system is secure if there is a way for an attacker to grab console, insert a virtual floppy and force a reboot of the machine. They might as well have physical access to the system. The console management system is likely not as secure as OpenBSD.
This will boot the kernel named bsd from the a partition of the first BIOS recognized hard disk.boot> boot hd0a:/bsd
The following options are available.
The OpenNTPD daemon is enabled by default at install time, which results in your computer's clock slowly moving into synchronization with the pool.ntp.org time servers. Once your clock is accurately set, ntpd will hold it at a high degree of accuracy. However, if your clock is more than a few minutes off, it is recommended that you bring it close to accurate initially, as it may take days or weeks to bring a very-off clock to sync. You can do this using the -s option of ntpd(8) or any other way to accurately set your system clock.
When you have ntpd(8) listening, it may happen that other machines still can't synchronize to it! A freshly started ntpd(8) daemon (for example, if you just restarted it after modifying ntpd.conf) refuses to serve time information to other clients until it adjusts its own clock to a reasonable level of stability first. When ntpd(8) considers its own time information stable, it announces it by a "clock now synced" message in /var/log/daemon. Even if the system clock is pretty accurate in the beginning, it can take up to 10 minutes to get in sync, and hours or days if the clock is not accurately set at the start.
This is caused by a difference between UTC (Coordinated Universal Time, based on astronomical observations) and TAI (International Atomic Time, based on atomic clocks). To compensate for variations in the earth's rotation, "leap seconds" are inserted into UTC, but TAI is unadjusted. These leap seconds are the cause of this discrepancy. For a more detailed description, search the web for leap seconds UTC TAI.
Addressing the problem is fairly simple. In most countries you will get the correct time if you use the -c parameter to rdate(8) and use a time zone out of the directory /usr/share/zoneinfo/right. For example, if you are located in Germany, you could use these commands:
# cd /etc && ln -sf /usr/share/zoneinfo/right/CET localtime # rdate -ncv ptbtime1.ptb.deIn other countries, the rules may differ.
Many other operating systems can be configured to do the same, which avoids this problem altogether.
If having the hardware clock set to UTC is a problem, you can change the default behavior of OpenBSD using config(8). For example, to configure OpenBSD to use a hardware clock set to US/Eastern (5 hours behind UTC, so 300 minutes):
See options(4) and search for option "TIMEZONE=value" for more information.# config -ef /bsd [...] Enter 'help' for information ukc> timezone 300 timezone = 300, dst = 0 ukc> quit Saving modified kernel.
Normally, the time zone is set during install. If you have need to change the time zone, you can create a new symbolic link to the appropriate time zone file in /usr/share/zoneinfo. For example, to set the machine to use EST5EDT as the new local time zone:
See also the date(1) manual and the section on OpenNTPD above.# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
The level of UTF-8 support and the default encoding configuration vary greatly with the program or library. For example, xterm(1) has full UTF-8 support enabled by default, while the regular expression library does not have any UTF-8 support yet.
To use the Unicode character set in UTF-8 encoding whereever supported, set the LC_CTYPE environment variable to the value en_US.UTF-8:
The OpenBSD base system completely ignores all locale-related environment variables except LC_CTYPE; even LC_ALL and LANG only affect the character encoding. Some ports may respect other LC_* variables, but using them or setting LC_CTYPE to any value other than C, POSIX or en_US.UTF-8 is not recommended.
This is almost always due to a reverse-DNS problem. DNS is the Domain Name Service, the system the Internet uses to convert a name, such as "www.openbsd.org", into a numeric IP address. Another task of DNS is the ability to take a numeric address and convert it back to a name. This is known as a Reverse DNS entry.
In order to provide better logging, OpenBSD performs a reverse DNS lookup on any machine that attaches to it in many different ways, including ssh(1), ftp(1), ftp-proxy(8). Unfortunately, in some cases, the machine that is making the connection does not have a proper reverse DNS entry.
This can be quite annoying. Fortunately, it is an easy thing to fix.
Your /etc/hosts file will look something like this:
Your /etc/resolv.conf file will look something like this:::1 localhost.in.example.org localhost 127.0.0.1 localhost.in.example.org localhost 192.168.1.1 gw.in.example.org gw 192.168.1.20 scrappy.in.example.org scrappy 192.168.1.35 shadow.in.example.org shadow
A common objection to this is "But, I use DHCP for my internal network! How can I configure my /etc/hosts?" Rather easily, actually. Just enter lines for all the addresses your DHCP server is going to give out, plus any static devices:search in.example.org nameserver 18.104.22.168 nameserver 22.214.171.124 lookup file bind
This case assumes you have the DHCP range set to 192.168.1.100 through 192.168.1.199, plus the three static definitions as listed at the top of the file.::1 localhost.in.example.org localhost 127.0.0.1 localhost.in.example.org localhost 192.168.1.1 gw.in.example.org gw 192.168.1.20 scrappy.in.example.org scrappy 192.168.1.35 shadow.in.example.org shadow 192.168.1.100 d100.in.example.org d100 192.168.1.101 d101.in.example.org d101 192.168.1.102 d102.in.example.org d102 [... snip ...] 192.168.1.198 d198.in.example.org d198 192.168.1.199 d199.in.example.org d199
If your gateway must use DHCP for configuration, you may well find you have a problem -- dhclient(8) will overwrite your /etc/resolv.conf every time the lease is renewed, which will remove the lookup file bind line. This can be solved by putting the line lookup file bind in the file /etc/resolv.conf.tail.
PCI and many other types of devices offer identifying information so that the OS can properly recognize and support devices. Adding recognition is easy, adding support is often not. Here are two examples of "not configured" devices:
The first one (a network adapter) had its vendor code identified and the general type of card was determined, but not the precise model of the card. The second example is another network adapter, this one a developer had seen and entered into the identification file that is used to identify the card. In both cases, however, the cards will be non-functional, as both are shown as not configured, meaning no driver has attached to the card.[...] vendor "Intel", unknown product 0x5201 (class network subclass ethernet, rev 0x03) at pci2 dev 9 function 1 not configured [...] "Intel EE Pro 100" rev 0x03 at pci2 dev 10 function 0 not configured [...]
For example, many early wireless network adapters were based on the Prism2 chipset, using the wi(4) driver, but later, when lower-cost chips became available, many manufacturers changed their product to use chips for which no open source drivers exist, but never changed their model numbers. Wireless network adapters, unfortunately, are far from the only example of this.