If you are creating new users with adduser(8), you can add them to the wheel group by answering wheel at the Invite user into other groups: prompt. Existing users must be added to the wheel group by hand. Here is an example of a /etc/group entry which has had the user ericj added to the wheel group:
If you want to give access to superuser privileges without adding users to the wheel group, you can use doas(1).wheel:*:0:root,ericj
dump(8) is designed to give you plenty of backup capabilities, and it may be an overkill if you just want to duplicate part of a (or an entire) filesystem. The command tar(1) may be faster for this operation. The format looks very similar:# cd /SRC && dump 0f - . | (cd /DST && restore -rf - )
# cd /SRC && tar cf - . | (cd /DST && tar xpf - )
After the kernel is booted, /etc/rc is started:
A line like this shows that ftpd(8) is not to start up with the system (at least not as a daemon via rc(8); ftpd is often run out of inetd(8)). Each line has a comment showing you the flags for common usage of that daemon or service. This doesn't mean that you must run that daemon or service with those flags. Read the relevant man page to see how you can have that daemon or service start up in any way you like.ftpd_flags=NO # set to NO if ftpd is running out of inetd
We strongly suggest you do not alter /etc/rc.conf directly. Instead, use the rcctl(8) utility to maintain the /etc/rc.conf.local file or create and edit it by hand. This makes future upgrades easier -- all the changes are in the one file that isn't touched during upgrade.
For example, to start the apmd(8) daemon for CPU scaling, you might do:
The syntax is very straightforward.# rcctl enable apmd # rcctl set apmd flags -A # rcctl start apmd
If you want to do it by hand, copy just the lines you need to change from /etc/rc.conf and adjust them as you like.
For example, here is the default line pertaining to httpd(8).
Here you can see that starting up httpd normally requires no flags, so a line like httpd_flags="" added to /etc/rc.conf.local will do the job. But to start httpd with options such as -v, you would need a line like httpd_flags="-v" instead.httpd_flags=NO
If the daemon does not automatically detach on startup, remember to add "&" at the end of the command-line.if [ -x /usr/local/sbin/daemonx ]; then echo 'Starting daemonx' && /usr/local/sbin/daemonx fi
From now on, this daemon will be started at boot. You will be able to see any errors on boot. A normal boot with no errors would show a line like this:
Starting daemonx
These scripts, one per daemon, are invoked by rc. The order for system daemons is coded into rc, and the order for add-in packages is managed by the pkg_scripts environment variable, which would be set in /etc/rc.conf.local. Note that simply placing a script in this directory does not cause it to be run on boot; the name of the script must be specified in the pkg_scripts variable to start on boot.
The starting of system scripts is determined by entries in the /etc/rc.conf.local file. For example, /etc/rc.d/httpd does not start httpd(8) unless /etc/rc.conf or /etc/rc.conf.local contains a line defining the "httpd_flags" variable. To help make sure your system will come up as expected on the next boot, the rc.d scripts will not run their daemon if the appropriate variable is not defined. You can, of course, manually invoke /usr/sbin/httpd directly with whatever options you wish, if you wish to run the program manually.
Note that rather than having each script in rc.d managing the entire startup, shutdown, reload, restart, and check operations, most rc.d scripts can be reduced to specifying very few variables, and invoking the rc.subr(8) script, which manages most of the standard way of doing these tasks.
For example, our above daemonx application could be started with a /etc/rc.d/daemonx file consisting of:
and adding the daemon name to the pkg_scripts variable in /etc/rc.conf.local.#!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1
allows you to run the command fdisk(8) as if you were root. Key words there are "appropriately configured" of course. You don't want average users to be able to get root privileges for any command they wish to run! Typically, though certainly not required, users in the "wheel" group are given permission to run commands with doas.$ doas fdisk sd1
An added advantage of "doas" is all activity is logged. It is possible to find out who ran an application.
Using a properly configured doas(1) on OpenBSD, one can completely disable the root account, eliminating all root password management issues.
It is also considered good practice by many to use doas when absolutely necessary to run a command as root, rather than sitting at a root console prompt. This way, an erroneously typed command is less likely to have catastrophic results. However, this is subject to some debate. It is possible to cause as much chaos and havoc with a "finger-memory" (or just incorrect command) invocation of doas as it is when logged in as root. For this reason, we do not blindly side with those that chant "always use doas, never use root!" or spend hours making things happen without root. Notably, if you set doas to not require confirmation of your password, any script or application running as you can invoke doas(1) to make any changes to your system as root. For this reason, for personal systems, it is probably better to either just use su(1) to elevate oneself to root status, or use doas(1) with the password option.
The complexity of sudo had prevented the importing of the most current versions, and the complexity of the sudoers config file has discouraged many users from doing anything other than uncomment one line in the conf file. In short, sudo's code is too complicated for the way most users use it, and its configuration is too difficult for more advanced uses.
doas(1) is intended to have a simpler, and thus hopefully more secure, code base and configuration file. From a user standpoint, the two are very similar.
For those needing the functionality of sudo, it's available as a package.
permit keepenv { PKG_PATH ENV PS1 SSH_AUTH_SOCK } :wheel
A more sophisticated doas.conf(5) file which would permit you to build OpenBSD from source using doas(1) without entering your password every time might be:
permit nopass keepenv { PKG_PATH ENV PS1 SSH_AUTH_SOCK } :wheel
permit nopass keepenv { \
FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \
DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF \
MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_DBDIR \
PKG_DESTDIR PKG_TMPDIR PORTSDIR RELEASEDIR SHARED_ONLY \
SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 } :wsrc
If you don't like the idea of any script or program you run being able to silently invoke doas(1) to run something as root, but you find typing your password over and over annoying, you may want to create a user for administrative tasks, such as "admin," and have a configuration file like this:
Now, anyone who is in the wheel group can become "admin" with just one entry of their password, and then admin can run the commands they wish without a password until they drop back to their normal user.permit :wheel as admin permit nopass admin
FILES
/etc/master.passwd current password file
/etc/passwd a 6th Edition-style password file
/etc/pwd.db insecure password database file
/etc/pwd.db.tmp temporary file
/etc/spwd.db secure password database file
/etc/spwd.db.tmp temporary file
OpenBSD does come with a tool with which you should edit your password file. It is called vipw(8). vipw will use vi (or your favorite editor defined per $EDITOR) to edit /etc/master.passwd. After you are done editing, it will re-create /etc/passwd, /etc/pwd.db and /etc/spwd.db as per your changes. vipw also takes care of locking these files, so that if anyone else attempts to change them at the same time, they will be denied access.
The easiest way to add a user in OpenBSD is to use the adduser(8) script. You can configure adduser(8) by editing /etc/adduser.conf. adduser(8) allows for consistency checks on /etc/passwd, /etc/group and shell databases. It will create the entries and $HOME directories for you. It can even send a message to the user welcoming them. Here is an example user, testuser, being added to a system. They will be given the $HOME directory /home/testuser, made a member of the group guest, and given the shell /bin/ksh.
To delete users you should use the rmuser(8) utility. This will remove all existence of a user. It will remove any crontab(1) entries, their $HOME dir (if it is owned by the user), and their mail. Of course it will also remove their /etc/passwd and /etc/group entries. Next is an example of removing the user that was added above. Notice you are prompted for the name, and whether or not to remove the user's home directory.# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: testuser Enter full name []: Test FAQ User Enter shell csh ksh nologin sh [ksh]: ksh Uid [1002]: Login group testuser [testuser]: guest Login group is ``guest''. Invite testuser into other groups: guest no [no]: no Login class authpf daemon default staff [default]: Enter password []: Enter password again []: Name: testuser Password: **** Fullname: Test FAQ User Uid: 1002 Gid: 31 (guest) Groups: guest Login Class: default HOME: /home/testuser Shell: /bin/ksh OK? (y/n) [y]: y Added user ``testuser'' Copy files from /etc/skel to /home/testuser Add another user? (y/n) [y]: n Goodbye!
# rmuser Enter login name for user to remove: testuser Matching password entry: testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002 :31::0:0:Test FAQ User:/home/testuser:/bin/ksh Is this the entry you wish to remove? y Remove user's home directory (/home/testuser)? y Updating password file, updating databases, done. Updating group file: done. Removing user's home directory (/home/testuser): done.
The full set of tools is:
useradd(8) is less daunting to use if you know the default settings beforehand. These settings are located in usermgmt.conf(5) and can be viewed by doing:
These defaults will be used unless you specify alternatives with the command-line options. For example, we want the user to be added to the group guest, not users. One more little hurdle with adding users is that passwords must be specified on the command-line. Importantly, the passwords must be encrypted, so you need to use the encrypt(1) utility. For example: OpenBSD's passwords use the Blowfish algorithm with 8 rounds by default. Here is an example to create an encrypted password to give to useradd(8).$ user add -D group users base_dir /home skel_dir /etc/skel shell /bin/csh inactive 0 expire Null (unset) range 1000..60000
Now that we have an encrypted password, we are ready to add the user. We will add the same user with the same specifications as the user we added above, via adduser(8).$ encrypt -p -b 8 Enter string: $2b$08$pvin31BFNxR.qiPTAfizFeeCxrlmBhsZLsAajCwAB1rgFFvl8PRXq
Note: Make sure to use ' ' (single quotes) around the password string, not " " (double quotes) as the shell will interpret these before sending it to user(8). In addition to that, make sure you specify the -m option if you want the user's home directory created and the files from /etc/skel copied over.# user add -p '$2b$08$pvin31BFNxR.qiPTAfizFeeCxrlmBhsZLsAajCwAB1rgFFvl8PRXq' \ > -u 1002 -s /bin/ksh -c "Test FAQ User" -m -g guest testuser
To see that the user was created correctly, we can use many different utilities. Below are a few commands you can use to quickly check that everything was created correctly.
In addition to these commands, user(8) provides its own utility to show user characteristics, called userinfo(8).$ ls -la /home total 14 drwxr-xr-x 5 root wheel 512 May 12 14:29 . drwxr-xr-x 15 root wheel 512 Apr 25 20:52 .. drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser $ id testuser uid=1002(testuser) gid=31(guest) groups=31(guest) $ finger testuser Login: testuser Name: Test FAQ User Directory: /home/testuser Shell: /bin/ksh Last login Sat Apr 22 16:05 (EDT) on ttyC2 No Mail. No Plan.
$ userinfo testuser login testuser passwd * uid 1002 groups guest change Wed Dec 31 19:00:00 1969 class gecos Test FAQ User dir /home/testuser shell /bin/ksh expire Wed Dec 31 19:00:00 1969
Notice the -r option, which must be specified if you want the users home directory to be deleted as well. Alternatively, you can specify -p rather than -r and this will lock the user's account, but not remove any information.# userdel -r testuser
This option is in the GENERIC kernel. After this, you need to mark in fstab(5) the filesystems which will have quotas enabled. The keywords userquota and groupquota should be used to mark each filesystem that you will be using quotas on. By default, the files quota.user and quota.group will be created at the root of that filesystem to hold the quota information. This default can be overridden by specifying the file name with the quota option in /etc/fstab, such as userquota=/var/quotas/quota.user. Here is an example /etc/fstab that has one filesystem with userquotas enabled, and the quota file in a non-standard location:
Now it's time to set the user's quotas. To do so, use edquota(8), which will invoke vi(1) or $EDITOR to edit the quotas. For example:/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
This will give you output similar to this:# edquota ericj
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 0, hard = 0)
inodes in use: 25, limits (soft = 0, hard = 0)
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 1000, hard = 1050)
inodes in use: 25, limits (soft = 0, hard = 0)
Now that the quotas are set, you need to turn the quotas on. To do this, use quotaon(8). For example:
This will go through /etc/fstab to turn on the filesystems with quota options. Now that quotas are up and running, you can view them using quota(1). Using a command of "quota <user>" will give that user's information. When called with no arguments, the quota(1) command will give your quota statistics. For example:# quotaon -a
Will result in output similar to this:# quota ericj
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
# quotaoff -a
Note, however, that patches aren't released for new features or additional hardware support for OpenBSD, and are only published for important reliability fixes or security problems that should be addressed right away on impacted systems (which is often NOT all systems, depending on their purpose).
There are three ways to update your system with patched code:
Whether you download and untar the source trees or fetch them from CVS, it's best to avoid using root where possible. Installing the new binaries will be the only step that requires it.
For our example here, we will look at patch 011 for OpenBSD 5.6, dealing with pppoe(4) connections. Each patch is cryptographically signed with the signify(1) tool and contains instructions on how to apply it properly. We will assume you have put this patch into your current working directory.
Note the "Hunk #1 succeeded" message above. This indicates the patch was applied successfully. Many patches are more complex than this one, and will involve multiple hunks and multiple files, in which case you should verify that all hunks succeeded on all files. If they did not, it normally means your source tree was different in some way from the release source tree the patch was created from, or you didn't follow instructions carefully, or your patch was mangled. Patches are very sensitive to "white space" -- copying and pasting from your browser will often change tab characters into spaces or otherwise alter the white space of a file, making it not apply.$ signify -Vep /etc/signify/openbsd-56-base.pub -x 011_pppoe.patch.sig \ -m - | (cd /usr/src && patch -p0) Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- | |OpenBSD 5.6 errata 11, Dec 5, 2014: | |An incorrect memcpy call would result in corrupted MAC addresses when |using PPPOE. | |Apply patch using: | | signify -Vep /etc/signify/openbsd-56-base.pub -x 011_pppoe.patch.sig \ | -m - | (cd /usr/src && patch -p0) | |Then build and install a new kernel. | |Index: sys/net/if_ethersubr.c |=================================================================== |RCS file: /cvs/src/sys/net/if_ethersubr.c,v |retrieving revision 1.174 |diff -u -p -r1.174 if_ethersubr.c |--- sys/net/if_ethersubr.c 12 Jul 2014 18:44:22 -0000 1.174 |+++ sys/net/if_ethersubr.c 1 Dec 2014 17:48:55 -0000 -------------------------- Patching file sys/net/if_ethersubr.c using Plan A... Hunk #1 succeeded at 673. <-- Look for this message! done
At this point, you can build and install the new kernel, then reboot the system as normal.
Not all patches are for the kernel. In some cases, you will have to rebuild individual utilities. At other times, will require recompiling all utilities statically linked to a patched library.
YP is a directory service compatible with Sun Microsystems NIS (Network Information System). See yp(8) for an overview of the available manual pages. Be careful, some operating systems contain directory services bearing similar names but all the same being incompatible, for example NIS+.
To use other directory services except YP, you either need to populate local configuration files from the directory, or you need a YP frontend to the directory. For example, you can use the sysutils/login_ldap port when you choose the former, while the ypldap(8) daemon provides the latter.
For some applications, simply synchronizing a small number of configuration files among a group of machines using tools like cron(8), scp(1) or rsync (available from ports) constitutes an easy and robust alternative to a full-blown directory service.
Thus, before setting up any YP server, you should consider whether these inherent security flaws are acceptable in your context. In particular, YP is inadequate if potential attackers have physical access to your network. Anybody gaining root access to any computer connected to your network segments carrying YP traffic can bind your YP domain and retrieve its data. In some cases, passing YP traffic through SSL or IPSec tunnels might be an option.
Use the domainname(1) utility to set the domain name, and put it into the defaultdomain(5) file to have it automatically set at system startup time.
# echo "puffynet" > /etc/defaultdomain
# domainname `cat /etc/defaultdomain`
# ypinit -m
The only inconvenience caused by changing the source directory is that you will not be able to add, remove and modify users and groups in the YP domain using utilities like user(8) and group(8). Instead, you will have to edit the configuration files with a text editor.
To define the source directory, edit the file /var/yp/`domainname`/Makefile and change the DIR variable, e.g.
DIR=/etc/yp/src/puffynet
For example, even in case you use the default source directory /etc, you do not usually need all accounts and groups existing on the server on all your client hosts. In particular, not serving the root account and thus keeping root's password hash confidential is often beneficial to security. Review the values of MINUID, MAXUID, MINGID and MAXGID and adjust them to you needs.
If all your YP clients run OpenBSD or FreeBSD, exclude the encrypted passwords from the passwd maps by setting UNSECURE="" in /var/yp/`domainname`/Makefile.
The former practice of editing the template file /var/yp/Makefile.yp is no longer recommended. Changes to that file affect all domains initialized after the change, but do not affect domains initialized before the change, so this is error-prone either way: You both risk that the intended changes do not take effect, and you risk to forget about them and have them affect other domains later which they were never intended for.
# cd /var/yp
# make
# echo 'portmap_flags=""' >> /etc/rc.conf.local
# portmap
# ypserv
# pkill ypbind
# rm -rf /var/yp/binding
# echo 'yppasswdd_flags="-d /etc/yp/src/puffynet"' >> /etc/rc.conf.local
# rpc.yppasswdd
# cd /var/yp
# make
# echo "puffynet" > /etc/defaultdomain
# domainname `cat /etc/defaultdomain`
# echo 'portmap_flags=""' >> /etc/rc.conf.local
# portmap
# ypbind
# ypcat passwd
bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh
...
For a list of standard YP maps and their standard usage, see Makefile.yp(8). The most common use cases include:
# echo '+:*::::::::' >> /etc/master.passwd
# pwd_mkdb -p /etc/master.passwd
# echo '+:*::' >> /etc/group
The list of supported locales can be obtained by running the command:
The LC_CTYPE environment variable can be set in one of the following ways:$ locale -a
to your ~/.xsession before starting the window manager. See the section on customizing X for more details. This enables the UTF-8 character set and will also cause applications such as xterm(1) to enable UTF-8 mode by default.export LC_CTYPE="en_US.UTF-8"
to your ~/.profile. Note that the text console's UTF-8 support is a work in progress, and some non-ASCII characters may not display properly.export LC_CTYPE="en_US.UTF-8"
A growing number of utilities in the base system support UTF-8. Those that don't will use ASCII in the UTF-8 locale.
When logging into remote systems with ssh(1), the LC_CTYPE environment variable is not propagated and will need to be manually set to the same value used by the local terminal.
Few utilities in the base system support languages other than English at this time. However, many programs from the ports collection support localized messages in various languages. They will fall back to English if the desired language is not available.