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.
The OpenBSD boot loader is documented in the architecture-specific boot(8) man page.boot>
If no commands are issued, the boot loader will automatically try to boot /bsd. If that fails, it will try /obsd, and if that fails, it will try /bsd.old. You can specify a kernel by typing:
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.
# chown username ~username/.profile
Under xterm(1), argv for ksh(1) is not prepended with a dash. Prepending a dash to argv will cause csh(1) and ksh(1) to know they should interpret their login files. For csh(1) that's .login, with a separate .cshrc that is always run when csh(1) starts up. With ksh(1), this is more noticeable because there is only one startup script, .profile. This file is ignored unless the shell is a login shell.
To fix this, add the line XTerm*loginShell: true to the file .Xdefaults in your home directory. Note, this file does not exist by default, you may have to create it.
You may not have had to do this on other systems, as some installations of the X Window System come with this setting as default. OpenBSD has chosen to follow the X.org behavior.$ echo "XTerm*loginShell: true" >> ~/.Xdefaults
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:# 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.