![[back]](../images/back.gif){kind=small}
![[OpenBSD]](../images/smalltitle.gif){kind=small}
[FAQ Index] [To Section 7 - Keyboard and Display controls] [To Section 9 - Migrating from Linux]
A few steps to recovery
If you have X completely set up and you are using an XF86Config that you know works then the problem most likely lies in the machdep.allowaperture. You also need to make sure that:
option APERTURE
is in your kernel configuration. [It is already in the GENERIC kernel]
Then you need to edit /etc/sysctl.conf and set machdep.allowaperture=2. This will allow X to access the aperture driver. This would already be set if you said that you would be running X when asked during the install. OpenBSD requires for all X servers that the aperture driver be set, because it controls access to the I/O ports on video boards.
For other X problems on the i386, consult the XFree86 Online Documentation at http://www.xfree86.org/support.html.
CVS is the tool that OpenBSD project uses to control changes to the source code. CVS stands for Concurrent Versions System. You can read more about CVS at http://www.cvshome.org/. CVS can be used by the end user to keep up to date with source changes, and changes in the ports tree. CVS makes it extremely simple to download the source via one of the many CVS mirrors for the project.
You can retrieve the sources from one of the OpenBSD AnonCVS servers. These servers are listed on http://www.openbsd.org/anoncvs.html. Once you have chosen a server you need to choose which module you are going to retrieve. There are three main modules available for checkout from the CVS tree. These are:
Now that you have decided which module that you wish to retrieve, there is one more step left before you can retrieve it. You must decide which method to use. CVS by default retrieves files using ssh(1), but some AnonCVS servers allow for the use of rsh. For those of you behind a firewall there are also the options of pserver and some AnonCVS servers run ssh on port 2022. Be sure to check http://www.openbsd.org/anoncvs.html for which servers support what protocols. Next I will show how to do a simple source checkout. Here I will be using an AnonCVS server located in the U.S., but remember that if you are outside of the U.S you need to use a server that is located nearby. There are many AnonCVS servers located throughout the world, so choose one nearest you. I will also be using ssh to retrieve the files.
$ export CVSROOT=anoncvs@anoncvs.usa.openbsd.org:/cvs $ cvs get src Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. cvs checkout: in directory src: cvs checkout: cannot open CVS/Entries for reading: No such file or directory cvs server: Updating src U src/Makefile [snip]
Notice here also that I set the CVSROOT environment variable. This is the variable that tells cvs(1) which AnonCVS server to use. This can also be specified using the -d option. For example:
$ cvs -d anoncvs@anoncvs.usa.openbsd.org:/cvs get src
These commands should be run in /usr, which will then create the directories of /usr/src, /usr/ports, and /usr/www. Depending, of course, on which module you checkout. You can download these modules to anywhere, but if you wanted to do work with them (ie make build ), it is expected that they be at the place above.
Once you have your initial tree setup, keeping it up-to-date is the easy part. You can update your tree at any time you choose, some AnonCVS servers update more often then others, so again check http://www.openbsd.org/anoncvs.html. In this example I will be updating my www module from anoncvs.usa.openbsd.org. Notice the -q option that I use, this makes the output not so verbose coming from the server.
$ echo $CVSROOT anoncvs@anoncvs.usa.openbsd.org:/cvs $ cvs -q up -Pd www Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. U www/want.html M www/faq/faq8.html ericj@oshibana:~>
For some, bandwidth and time are serious problems when updating repositories such as these. So CVS has a -z[1-9] option which uses gzip to compress the data. To use it, do -z[compression-level], for instance, -z3 for a compression level of 3.
The ports tree is a set of Makefiles that download, patch, configure and install userland programs so you can run them in OpenBSD environment without having to do all that by hand. You can get the ports tree from any of the OpenBSD FTP servers in /pub/OpenBSD/3.4/ports.tar.gz. The most recent ports are available via the 'ports' cvs tree, or /pub/OpenBSD/snapshots/ports.tar.gz. For most of you however, packages will be a much better option. Packages are created from ports and are already compiled and ready to use. To read more on packages read FAQ 8, Packages.
OpenBSD has three "active" versions at any point in time:
If your system is Release, use the Release version of the ports tree. Don't try to use a -Current version of the Ports tree on a -Release or -Stable system. Not only is it not likely to work, you will irritate people when you ask for help about why "nothing seems to work!" Note that there is a -Stable branch of the Ports tree as well, where critical fixes to -Release ports will be made.
Yes, this really does mean a wonderful new port will not typically work on your "older" system -- even if that system was -current just a few weeks ago.
If you do not have the ports tree installed, you can download it via any of OpenBSD's FTP servers, or of course, from the CD-ROM. The file is ports.tar.gz, and you want to untar this in the /usr directory, which will create /usr/ports, and all the directories under it. For example:
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/3.4/ports.tar.gz
$ sudo cp ports.tar.gz /usr
$ cd /usr; sudo tar xzf ports.tar.gz
A snapshot of the ports tree is also created daily and can be downloaded from any of the OpenBSD FTP servers as /pub/OpenBSD/snapshots/ports.tar.gz. If you are installing a snapshot of OpenBSD, you should use a matching snapshot of ports. Again, make sure you keep your ports tree and your OpenBSD system in sync.
Use the ports tree to search for keywords. To do this use make search key="searchkey". Here is an example of a search for 'samba':
$ make search key="samba" [...snip...] Port: amanda-client-2.4.2.2 Path: misc/amanda,-client Info: network-capable tape backup (client only) Maint: Tom Schutter <t.schutter@att.net> Index: misc L-deps: B-deps: :devel/gmake gnuplot-*:math/gnuplot gtar-*:archivers/gtar samba-*:net/samba/stable R-deps: Archs: any Port: samba-2.2.8a Path: net/samba/stable Info: SMB and CIFS client and server for UNIX Maint: The OpenBSD ports mailing-list <ports@openbsd.org> Index: net L-deps: popt::devel/popt B-deps: :devel/autoconf/2.13 :devel/metaauto R-deps: Archs: any [...snip...]
Ports are set up to be EXTREMELY easy to make and install. Here is an example showing how to install the X11 program xfig. You'll notice the dependencies are automatically detected and completed.
First you need to cd to the dir of the program you want. If you are searching for a program, you can either update your locate database, or use the search function talked about above. Once you are in the dir of the program you want, you can just type make install. For example.
$ sudo make install ===> Checking files for xfig-3.2.4 >> xfig.3.2.4.full.tar.gz doesn't seem to exist on this system. >> Attempting to fetch /usr/ports/distfiles/xfig.3.2.4.full.tar.gz from http://w ww.xfig.org/xfigdist/. 100% |**************************************************| 5042 KB 00:31 >> Checksum OK for xfig.3.2.4.full.tar.gz. (sha1) ===> xfig-3.2.4 depends on: jpeg.62 - jpeg.62 missing... ===> Verifying install for jpeg.62 in graphics/jpeg ===> Checking files for jpeg-6b >> jpegsrc.v6b.tar.gz doesn't seem to exist on this system. >> Attempting to fetch /usr/ports/distfiles/jpegsrc.v6b.tar.gz from ftp://ftp.uu .net/graphics/jpeg/. 'EPSV': command not understood. 100% |**************************************************| 598 KB 00:06 >> Checksum OK for jpegsrc.v6b.tar.gz. (sha1) ===> Extracting for jpeg-6b ===> Patching for jpeg-6b ===> Configuring for jpeg-6b checking for gcc... cc checking whether the C compiler (cc -O2 ) works... yes checking whether the C compiler (cc -O2 ) is a cross-compiler... no checking whether we are using GNU C... yes [...snip...]
Many of the applications in the ports tree support different install options, called flavors. If a port comes in multiple flavors, you can use these options simply by setting an environment variable before you compile the port. If multiple features are needed, the FLAVOR variable can be set to a space-delimited list of the supported and desired flavors. Currently, many ports have flavors that include database support, support for systems without X, or network additions like SSL and IPv6.
$ pwd /usr/ports/net/mtr $ make show=FLAVORS no_x11 $ env FLAVOR="no_x11" make ===> mtr-0.49-no_x11 depends on: gmake-3.80 - not found ===> Verifying install for gmake-3.80 in devel/gmake ===> Checking files for gmake-3.80 >> make-3.80.tar.gz doesn't seem to exist on this system. >> Attempting to fetch /usr/ports/distfiles/make-3.80.tar.gz from ftp://ftp.gnu. org/gnu/make/. Unknown command. 100% |**************************************************| 1183 KB 00:07 >> Checksum OK for make-3.80.tar.gz. (sha1) [...snip...] $ sudo env FLAVOR="no_x11" make install ===> Faking installation for mtr-0.49-no_x11 [...snip...] ===> Building package for mtr-0.49-no_x11 Creating package /usr/ports/packages/i386/All/mtr-0.49-no_x11.tgz Using SrcDir value of /usr/ports/net/mtr/w-mtr-0.49-no_x11/fake-i386-no_x11/usr/ local Creating gzip'd tar ball in '/usr/ports/packages/i386/All/mtr-0.49-no_x11.tgz' ===> Installing mtr-0.49-no_x11 from /usr/ports/packages/i386/All/mtr-0.49-no_a x11.tgz
You can see a list of both ports and packages by using the pkg_info command.
$ /usr/sbin/pkg_info zsh-4.1.1 The Z shell. screen-3.9.15 A multi-screen window manager. emacs-21.3 GNU editing macros. tcsh-6.12.00 An extended C-shell with many useful features. bash-2.05b The GNU Borne Again Shell. zip-2.3 Create/update ZIP files compatible with pkzip. ircII-20030314 An enhanced version of ircII, the Internet Relay Chat client ispell-3.2.06 An interactive spelling checker. tin-1.6.1 TIN newsreader (termcap based) procmail-3.22 A local mail delivery agent. strobe-1.06 Fast scatter/gather TCP port scanner lsof-4.68 Lists information about open files. ntp-4.1.74 Network Time Protocol Implementation. ncftp-3.1.5p0 ftp replacement with advanced user interface nmh-1.0.4p1 The New MH mail handling program bzip2-1.0.2 A block-sorting file compressor
More information about the ports can be found in the ports(7) man page and on the Ports page.
Our ports tree is constantly being expanded, and if you would like to help please see: http://www.openbsd.org/porting.html.
Packages are the precompiled binaries of some of the most used programs. They are ready for use on an OpenBSD system. Again, like the ports, packages are very easy to maintain and update. Packages are constantly being added so be sure to check each release for additional packages.
Here is a list of tools used in managing packages.
If you are a smart user and bought an OpenBSD CD set, then packages can be found on one of the three CDs, depending on your architecture. If you don't have an OpenBSD CD in your possession you can download packages from any of the ftp mirrors. You can get a list of mirrors http://www.openbsd.org/ftp.html. Packages are located at /pub/OpenBSD/3.4/packages from there packages are broken down depending on architecture.
To install packages, the utility pkg_add(1) is used. pkg_add(1) is an extremely easy utility to use, in the following two examples pkg_add(1) will be used to install a package. The first example will show pkg_add(1) installing a package that resides on a local disk, the second example will show an installation of a package via ftp. In both examples screen-3.9.15 will be installed.
Installing via local disk
$ sudo pkg_add -v screen-3.9.15.tgz Requested space: 749864 bytes, free space: 2239117312 bytes in /var/tmp/instmp.cpsHA27596 Running install with PRE-INSTALL for `screen-3.9.15' extract: Package name is screen-3.9.15 extract: CWD to /usr/local extract: /usr/local/bin/screen-3.9.15 extract: execute 'ln -sf screen-3.9.15 /usr/local/bin/screen' extract: /usr/local/man/man1/screen.1 extract: /usr/local/info/screen.info extract: execute '[ -f /usr/local/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > /usr/local/info/dir' extract: execute 'install-info /usr/local/info/screen.info /usr/local/info/dir' extract: /usr/local/lib/screen/screencap extract: /usr/local/lib/screen/screenrc extract: CWD to . Running mtree for `screen-3.9.15' mtree -q -U -f +MTREE_DIRS -d -e -p /usr/local Running install with POST-INSTALL for `screen-3.9.15' +--------------- | The file /etc/screenrc has been created on your system. | You may want to verify/edit its contents | | The file /usr/local/lib/screen/screencap contains a | termcap like description of the screen virtual terminal. | You may use it to update your terminal database. | See termcap(5). +--------------- Attempting to record package into `/var/db/pkg/screen Package `screen-3.9.15' registered in `/var/db/pkg/screen-3.9.15'
In this example the -v flag was used to give a more verbose output. This option is not needed but is helpful for debugging and was used here to give a little more insight into what pkg_add(1) is actually doing. Notice however, that there are some valid messages given out mentioning /etc/screenrc. Messages like this will be given to you whether or not you use the -v flag.
Installing via ftp
$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/3.4/packages/i386/screen-3.9.15.tgz >>> ftp -o - ftp://ftp.openbsd.org/pub/OpenBSD/3.4/packages/i386/screen-3.9.15.tgz +--------------- | The file /etc/screenrc has been created on your system. | You may want to verify/edit its contents | | The file /usr/local/lib/screen/screencap contains a | termcap like description of the screen virtual terminal. | You may use it to update your terminal database. | See termcap(5). +---------------
In this example you can see that I installed the i386 package. You should substitute i386 (above) with your architecture. Notice: Not all architectures have the same packages. Some ports don't work on certain architectures. In this example the -v flag wasn't used, so only NEEDED messages are shown.
The utility pkg_info(1) is used to view a list of packages that are already installed on your system. This is usually needed to find out the correct name of a package before you remove that package. To see what packages are installed on your system simple use:
$ pkg_info mpg123-0.59rp1 mpeg audio 1/2 layer 1, 2 and 3 player nmap-3.00 port scanning large networks ircII-20030314 enhanced version of ircII (internet relay chat) screen-3.9.15 multi-screen window manager unzip-5.50r2 extract, list & test files in a ZIP archive ntp-4.1.74 Network Time Protocol implementation icb-5.0.9p1 Internet CB - mostly-defunct chat client
To delete a package, simple take the proper name of the package as shown by pkg_info(1) and use pkg_delete(1) to remove the package. In the below example, the screen package is being removed. Notice that on some occasions there are instructions of extra objects that need to be removed that pkg_delete(1) did not remove for you. As with the pkg_add(1) utility, you can use the -v flag to get more verbose output.
$ sudo pkg_delete screen-3.9.15 +--------------- | To completely deinstall the screen-3.9.15 package you need to perform | this step as root: | | rm -f /etc/screenrc | | Do not do this if you plan on re-installing screen-3.9.15 | at some future time. +---------------
Building a complex application from source is not trivial. Not only must the application be compiled, but the tools used to build it must be built. Unfortunately, OpenBSD, the tools, and the application are all evolving, and often, getting all the pieces working together is a challenge. Once everything works, a revision in any of the pieces the next day could render it broken. Every six months, as a new release of OpenBSD is made, an effort is made to test the building of every port on every platform, but during the development cycle it is likely that some ports will break.
In addition to having all the pieces work together, there is just the matter of time and resources required to compile some applications from source. A common example is CVSup, a tool commonly used to track the OpenBSD source tree. To install CVSup on a moderately fast system with a good Internet connection may take only about ten seconds -- the time required to download and unpack a single 511kB package file. In contrast, building CVSup on the same machine from source is a huge task, requiring many tools and bootstrapping a compiler, takes almost half an hour on the same machine. Other applications, such as Mozilla or KDE may take hours and huge amounts of disk space and RAM/swap to build. Why go through this much time and effort, when the programs are already compiled and sitting on your CD-ROM or FTP mirror, waiting to be used?
Of course, there are a few good reasons to use ports over packages in some cases:
Sure. You need to add "flags 0x20" at the end of the fd* entry and recompile your kernel. The line should be read:
fd* at fdc? drive ? flags 0x20
After that you would be able to use the floppy drive all the times. It doesn't matter if you plugged it in after boot.
When booting your OpenBSD system, you have probably noticed the boot prompt.
boot>
For most people, you won't have to do anything here. It will automatically boot if no commands are given. But sometimes problems arise, or special functions are needed. That's where these options will come in handy. To start off, you should read through the boot(8) man page. Here we will go over the most common used commands for the bootloader.
To start off, if no commands are issued, the bootloader 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 hand by typing:
orboot> boot hd0a:/bsd
boot> b /bsd
This will boot the kernel named bsd from the 'a' partition of the first BIOS recognized hard disk.
Here is a brief list of options you can use with the OpenBSD kernel.
These are entered in the format of: boot [ image [-acds]]
For further reading you can read boot_i386(8) man page
S/Key is a ``one-time password'' scheme. This allows for one-time passwords for use on un-secured channels. This can come in handy for those who don't have the ability to use ssh or any other encrypted channels. OpenBSD's S/Key implementation can use a variety of algorithms as the one-way hash. The following algorithms are available:
To start off the directory /etc/skey must exist. If this directory is not in existence, have the super-user create it. This can be done simply by doing:
# mkdir /etc/skey
Once that directory is in existence, you can initialize your S/Key. To do this you will have to use skeyinit(1). With skeyinit(1), you will first be prompted for your password to the system. This is the same password that you used to log into the system. Running skeyinit(1) over an insecure channel is completely not recommended, so this should be done over a secure channel (such as ssh) or the console. Once you have authorized yourself with your system password you will be asked for yet another password. This password is the S/Key secret password, and is NOT your system password. Your secret password must be at least 10 characters. We suggest using a memorable phrase containing several words as the secret password. Here is an example user being added.
$ skeyinit ericj [Adding ericj] Reminder - Only use this method if you are directly connected or have an encrypted channel. If you are using telnet or rlogin, exit with no password and use skeyinit -s. Enter secret password: Again secret password: ID ericj skey is otp-md5 99 oshi45820 Next login password: HAUL BUS JAKE DING HOT HOG
One line of particular importance in here is ID ericj skey is otp-md5 99 oshi45820. This gives a lot of information to the user. Here is a breakdown of the sections and their importance.
But of more immediate importance is your password. Your password consists of 6 small words, combined together this is your password, spaces and all.
By now your skey has been initialized, and you have your password. You're ready to login. Here is an example session using S/Key to login. Starting with OpenBSD 3.0, S/Key logins work differently. For OpenBSD 3.0 and above you append :skey to your login name. For versions of OpenBSD previous to 3.0 you use s/key for the password at which time you are prompted for your S/Key password (the exception to this is ftpd(8) which will always present an S/Key challenge for S/Key-enabled user prior to OpenBSD < 3.0). The examples below assume OpenBSD 3.0 or higher.
$ ftp localhost Connected to localhost. 220 oshibana.shin.ms FTP server (Version 6.5/OpenBSD) ready. Name (localhost:ericj): ericj:skey 331- otp-md5 96 oshi45820 331 S/Key Password: 230- OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003 230- 230- Welcome to OpenBSD: The proactively secure Unix-like operating system. 230- 230- Please use the sendbug(1) utility to report bugs in the system. 230- Before reporting a bug, please try to reproduce it with the latest 230- version of the code. With bug reports, please try to ensure that 230- enough information to reproduce the problem is enclosed, and if a 230- known fix for it exists, include that as well. 230- 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quit 221 Goodbye.
Note that I appended ":skey" to my username. This tells ftpd that I want to authenticate using S/Key. Some of you might have noticed that my sequence number has changed to otp-md5 96 oshi45820. This is because by now I have used S/Key to login several times. But how do you get your password after you've logged in once? Well to do this, you'll need to know what sequence number you're using and your key. As you're probably thinking, how can you remember which sequence number you're on? Well this is simple, use skeyinfo(1), and it will tell you what to use. For example here, I need to generate another password for a login that I might have to make in the future. (remember I'm doing this from a secure channel).
$ skeyinfo 95 oshi45820
An even better way is to use skeyinfo -v, which outputs a command suitable to be run in the shell. For instance:
$ skeyinfo -v otp-md5 95 oshi45820
Not only is otp-md5 a description of the hash used, it is also an alternate name for the skey(1) command. So, the simplest way to generate the next S/Key password is simply:
$ `skeyinfo -v` Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: NOOK CHUB HOYT SAC DOLE FUME
Note the backticks in the above example.
I'm sure many of you won't always have a secure connection to create these passwords, and creating them over an insecure connection isn't feasible, so how can you create multiple passwords at one time? Well you can supply skey(1) with a number of how many passwords you want created. This can then be printed out and taken with you wherever you go.
$ otp-md5 -n 5 95 oshi45820 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 91: SHIM SET LEST HANS SMUG BOOT 92: SUE ARTY YAW SEED KURD BAND 93: JOEY SOOT PHI KYLE CURT REEK 94: WIRE BOGY MESS JUDE RUNT ADD 95: NOOK CHUB HOYT SAC DOLE FUME
Notice here though, that the bottom password should be the first used, because we are counting down from 100.
Using S/Key with telnet(1), ssh(1), or rlogin(1) is done in pretty much the same fashion as with ftp--you simply tack ":skey" to the end of your username. Example:
$ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. OpenBSD/i386 (oshibana) (ttyp2) login: ericj:skey otp-md5 98 oshi45821 S/Key Password: SCAN OLGA BING PUB REEL COCA Last login: Thu Oct 7 12:21:48 on ttyp1 from 156.63.248.77 OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have mail. $
Not at this time. Work is on-going, there is an OpenBSD SMP project, though there is nothing usable yet, nor is there any time schedule for OpenBSD SMP support.
On most platforms, OpenBSD will run on an SMP system, but only utilizing one processor. The exception to this is the SPARC platform -- OpenBSD/sparc will sometimes require that extra MBus modules be removed for the system to boot. Multi-processor SPARC64 systems run as long as the base machine is supported.
How can I help?
You need to use /dev/cuaXX for connections initiated from the OpenBSD system, the /dev/ttyXX devices are intended only for terminal or dial-in usage. While it was possible to use the tty devices in the past, the OpenBSD kernel is no longer compatible with this usage.
From cua(4):
For hardware terminal ports, dial-out is supported through matching device nodes called calling units. For instance, the terminal called /dev/tty03 would have a matching calling unit called /dev/cua03. These two devices are normally differentiated by creating the calling unit device node with a minor number 128 greater than the dial-in device node. Whereas the dial-in device (the tty) normally requires a hardware signal to indicate to the system that it is active, the dial-out device (the cua) does not, and hence can communicate unimpeded with a device such as a modem. This means that a process like getty(8) will wait on a dial-in device until a connection is established. Meanwhile, a dial-out connection can be established on the dial-out device (for the very same hardware terminal port) without disturbing anything else on the system. The getty(8) process does not even notice that anything is happening on the terminal port. If a connecting call comes in after the dial-out connection has finished, the getty(8) process will deal with it properly, without having noticed the intervening dial-out action.
Lynx, a text-based browser, is in the base system, and has SSL support. Other browsers in the ports tree, include (in no particular order):
Graphical (X) Browsers
Console (Text mode) Browsers
You will find all these in the ports collection. All the above mentioned browsers are located in /usr/ports/www/ after the installation of the ports tree. Most are also available as pre-compiled packages, available on the FTP servers and on the CD-ROM. As most of the graphical browsers are very large and require quite some time to download and compile, one should seriously consider the use of packages where available.
Unfortunately, due to a bug in one of the libraries used by w3m, it does not work on 3.4-release on any platform.
Mg is a micro Emacs-style text editor included in OpenBSD. Micro means that it's small (Emacs is very large!) For the basics, read the mg(1) manual page and the tutorial, as included with the source code. For more interesting questions (such as, "I don't have a Meta key!") check out the Emacs FAQ.
Note that since mg is a small Emacs implementation, which is mostly similar to the text editor features of Emacs 17, it does not implement many of Emacs' other functionality. (Including mail and news functionality, as well as modes for Lisp, C++, Lex, Awk, Java, etc...)
There are two likely reasons for ksh(1) to seemingly ignore a user's .profile file.
# chown username ~username/.profile
Under xterm(1), argv[0] for ksh(1) is not prepended with a dash ("-"). Prepending a dash to argv[0] 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.
$ echo "XTerm*loginShell: true" >> ~/.Xdefaults
You may not have had to do this on other systems, as some installations of X Window System come with this setting as default. OpenBSD has chosen to follow the XFree86 behavior.
The /etc/motd file is edited upon every boot of the system, replacing everything up to, but not including, the first blank line with the system's kernel version information. When editing this file, make sure that you start after this blank line, to keep /etc/rc from deleting these lines when it edits /etc/motd upon boot.
Although none of the developers think it is particularly relevant, this question comes up frequently enough in the mailing lists that it is answered here. www.openbsd.org and the main OpenBSD ftp site are hosted at a SunSITE at the University of Alberta, Canada. These sites are hosted on a large Sun system, which has access to lots of storage space and Internet bandwidth. The presence of the SunSITE gives the OpenBSD group access to this bandwidth. This is why the main site runs here. Many of the OpenBSD mirror sites run OpenBSD, but since they do not have guaranteed access to this large amount of bandwidth, the group has chosen to run the main site at the University of Alberta SunSITE.
There exists a condition where some machines might not detect some PCI devices properly, or might freeze while detecting multiple NIC's in one machine. This is the fault of PCIBIOS, and involves a simple workaround to make it work properly. Simply enter the boot time configuration and disable PCIBIOS. An example is below:
boot> boot -c
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2002 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel Pentium III (Coppermine) ("GenuineIntel" 686-class, 128KB L2 cache)
1 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SYS,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXS
R,SIMD
real mem = 267956224 (261676K)
avail mem = 243347456 (237644K)
using 3296 buffers containing 13500416 bytes (13184K) of memory
User Kernel Config
UKC> disable pcibios
UKC> quit
[... snip ...]
|
Once this is done, you can follow the directions in FAQ 5, Building a Kernel to create a new kernel so that you don't have to worry about this in the future.
See this document.
No it doesn't. We use a different mechanism to achieve similar results that is called Soft Updates. Please read in FAQ 14 to get more details.
Many new users to OpenBSD experience a two minute login delay when using services such as ssh, ftp, or telnet. This can also be experienced when using a proxy, such as ftp-proxy, or when sending mail out from a workstation through sendmail.
This is almost always due to a reverse-DNS problem. DNS is Domain Name Services, 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 "Reverse DNS".
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, ftp, telnet, sendmail or ftp-proxy. 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:
::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 |
Your resolv.conf file will look something like this:
search in.example.org nameserver 24.2.68.33 nameserver 24.2.68.34 lookup file bind |
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:
::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
|
In this case, I am assuming 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.
If your gateway must use DHCP for configuration, you may well find you have a problem -- dhclient 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.
The present web pages have been carefully crafted to work on a wide variety of actual browsers going back to browser versions 4.0 and later. We do not want to make these older pages conform to HTML4 or XHTML until we're sure that they will also work with older browsers; it's just not a priority. We welcome new contributors, but suggest you work on writing code, or on documenting new aspects of the system, not on tweaking the existing web pages to conform to newer standards.
When using rdate(8) to synchronize your clock to a NTP server, you may find your clock is off by twenty-some seconds from your local definition of time.
This is caused by a difference between the UTC (Coordinated Universal Time, based on astronomical observations) time and TAI (International Atomic Time, based on atomic clocks) time. 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.de
In other countries, the rules may differ.
[FAQ Index] [To Section 7 - Keyboard and Display Controls] [To Section 9 - Migrating from Linux]
www@openbsd.org