File: [local] / www / faq / faq10.html (download) (as text)
Revision 1.302, Sat Apr 20 21:41:42 2024 UTC (5 weeks, 2 days ago) by bentley
Branch: MAIN
CVS Tags: HEAD
Changes since 1.301: +1 -2 lines
Fix unintentional rendering errors, caught with the validator.
|
<!doctype html>
<html lang=en id=faq>
<!-- If you make edits to any FAQ documents, please start each sentence
on a new line, and try to keep the general formatting consistent
with the rest of the pages -->
<title>OpenBSD FAQ: System Management</title>
<meta charset=utf-8>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="../openbsd.css">
<link rel="canonical" href="https://www.openbsd.org/faq/faq10.html">
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
FAQ - System Management
<small>
<a href="index.html">[FAQ Index]</a>
</small>
</h2>
<hr>
<ul>
<li><a href="#Patches" >Security Updates</a>
<li><a href="#rc" >System Daemons</a>
<li><a href="#doas" >Executing Commands as Another User</a>
<li><a href="#vipw" >Editing the Password File</a>
<li><a href="#LostPW" >Resetting the Root Password</a>
<li><a href="#OpenNTPD" >Clock Syncing</a>
<li><a href="#TimeZone" >Time Zones</a>
<li><a href="#locales" >Character Sets and Localization</a>
<li><a href="#SMT" >Symmetric Multithreading, or "Why are only half of my CPUs used?"</a>
<li><a href="#SKey" >Using S/Key</a>
<li><a href="#Dir" >Directory Services</a>
<ul>
<li><a href="#YP_secure" >YP Security Considerations</a>
<li><a href="#YP_server" >Setting Up a YP Server</a>
<li><a href="#YP_client" >Setting Up a YP Client</a>
</ul>
</ul>
<hr>
<h2 id="Patches">Security Updates</h2>
When a critical bug is found, the fix will be committed to the -current tree
(and made available in <a href="faq5.html#Flavors">snapshot builds</a>)
as soon as possible.
It will then be backported to the two most recent OpenBSD releases in the
form of <a href="../errata.html">errata</a> and details will be sent to the
<a href="https://lists.openbsd.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=announce">announce</a>
mailing list.
<p>
Getting these fixes can be done in a few different ways:
<ul>
<li><b>Apply binary patches</b> (available on amd64, arm64, i386)
<br>
The <a href="https://man.openbsd.org/syspatch">syspatch(8)</a> utility
can be used to upgrade any files in need of security or reliability fixes
on a supported OpenBSD release.
This is the quickest and easiest method to get the base system up to date.
<p>
<li><b>Update the system to -stable</b>
<br>
Fetch (or update) your source tree with <a href="../anoncvs.html">CVS</a>,
then <a href="../stable.html">recompile</a> the kernel and userland.
<p>
<li><b>Patch the affected files individually</b>
<br>
While applying fixes from the errata page typically requires less time
than a CVS checkout/update and rebuild, there is no universal set of
instructions to follow.
Sometimes you must patch and recompile one application, sometimes more.
<p>
<li><b>Upgrade the system to -current</b>
<br>
As all fixes are applied to the -current codebase, updating the system
to the latest <a href="faq5.html#Snapshots">snapshot</a> is a good way
to get all the fixes at once.
However, running -current is not for everyone.
</ul>
Security fixes for third party software installed via
<a href="faq15.html">packages</a> are normally only backported to the most
recent release.
To obtain them, do one of the following:
<ul>
<li><b>Use binary packages</b> (available on amd64, arm64, i386, sparc64)
<br>
Updated binary packages for releases and -stable systems are provided
to address security issues or for other major fixes.
Simply call <a href="https://man.openbsd.org/pkg_add">pkg_add(1)</a> with
the <code>-u</code> flag to get the new files.
<p>
<li><b>Use the -stable ports tree</b>
<br>
Fetch (or update) your <a href="ports/ports.html">ports tree</a>,
run the <code>/usr/ports/infrastructure/bin/pkg_outdated</code> script to
list any packages in need of rebuilding, and issue <code>make update</code>
in the affected port directory.
In some cases, existing ports will need to be uninstalled before
rebuilding.
<p>
<li><b>Upgrade the system to -current</b>
<br>
Binary packages for -current are rebuilt on a regular basis, and these
new packages will include any security fixes.
</ul>
To be alerted of port updates, consider following the
<a href="https://lists.openbsd.org/cgi-bin/mj_wwwusr?func=lists-long-full&extra=ports-changes">ports-changes</a>
mailing list.
<h2 id="rc">System Daemons</h2>
System daemons (or "services") are started, stopped and controlled by
the <a href="https://man.openbsd.org/rc">rc(8)</a> script via
<a href="https://man.openbsd.org/rc.d">rc.d(8)</a>.
<p>
Most daemons and services that come with OpenBSD are controlled on boot
by variables defined in
<a href="https://cvsweb.openbsd.org/src/etc/rc.conf?rev=HEAD">/etc/rc.conf</a>.
You'll see lines similar to this:
<pre class="cmdbox">
httpd_flags=NO
</pre>
This shows that <a href="https://man.openbsd.org/httpd">httpd(8)</a> is not to
be started from <a href="https://man.openbsd.org/rc">rc(8)</a> at boot time.
Each line has a comment showing you the flags for common usage of that daemon
or service.
<p>
Do not alter <a href="https://man.openbsd.org/rc.conf">rc.conf(8)</a> directly.
Instead, use the <a href="https://man.openbsd.org/rcctl">rcctl(8)</a> utility
to maintain the <code>/etc/rc.conf.local</code> file.
This makes future upgrades easier as all the changes are in the one file that
isn't touched during upgrade.
<p>
For example, to start the <a href="https://man.openbsd.org/apmd">apmd(8)</a>
daemon for CPU scaling, one might do:
<pre class="cmdbox">
# <b>rcctl enable apmd</b>
# <b>rcctl set apmd flags -A</b>
# <b>rcctl start apmd</b>
</pre>
<h2 id="doas">Executing Commands as Another User</h2>
The <a href="https://man.openbsd.org/doas">doas(1)</a> tool lets a system
administrator permit certain users to run specific commands as another user.
Regular users can run administrative commands, only being required to
authenticate as themselves, without the need for the root password.
<p>
For example, if appropriately configured, the following command would display
root's <a href="https://man.openbsd.org/crontab.5">crontab(5)</a> file:
<pre class="cmdbox">
$ <b>doas -u root crontab -l</b>
</pre>
Commands invoked by <a href="https://man.openbsd.org/doas">doas(1)</a>
are logged to <code>/var/log/secure</code> by default.
Check the <a href="https://man.openbsd.org/doas.conf">doas.conf(5)</a> manual
for configuration examples.
<h2 id="vipw">Editing the Password File</h2>
OpenBSD's main password file is located at <code>/etc/master.passwd</code> and
is only readable by root.
The <a href="https://man.openbsd.org/pwd_mkdb">pwd_mkdb(8)</a> tool generates
the world-readable <code>/etc/passwd</code> and the password databases
(<code>/etc/pwd.db</code> and <code>/etc/spwd.db</code>) from the main file.
The format is described in
<a href="https://man.openbsd.org/passwd.5">passwd(5)</a>.
<p>
Always use <a href="https://man.openbsd.org/vipw">vipw(8)</a> to edit the
password file.
After you are done editing, it will first sanity check the changes, then
recreate <code>/etc/passwd</code> and the password databases, and finally
install the copy in place of the original <code>/etc/master.passwd</code> file.
<h2 id="LostPW">Resetting the Root Password</h2>
If the root password was forgotten, the basic process to regain access is
to boot into single user mode, mount the <code>/</code> and <code>/usr</code>
partitions, and run <a href="https://man.openbsd.org/passwd">passwd(1)</a>
to change the root password.
<ul>
<li><b>Boot into single user mode.</b>
This part of the process varies depending on the
<a href="../plat.html">platform</a> in use.
For amd64 and i386, the
<a href="faq14.html#BootAmd64">second stage boot loader</a>
pauses for a few seconds to give you a chance to provide parameters
to the kernel.
Here the <code>-s</code> flag can be passed to
<a href="https://man.openbsd.org/OpenBSD-current/i386/boot">boot(8)</a>:
<pre class="cmdbox">
probing: pc0 com0 com1 mem[638K 1918M a20=on]
disk: hd0+ hd1+
>> OpenBSD/amd64 BOOT 3.33
boot> <b>boot -s</b>
</pre>
<li><b>Mount the partitions.</b>
Both <code>/</code> and <code>/usr</code> will need to be mounted
read-write.
<pre class="cmdbox">
# <b>fsck -p / && mount -uw /</b>
# <b>fsck -p /usr && mount /usr</b>
</pre>
<li><b>Change the root password.</b>
You already have root privileges from being in single user mode,
so you will not be prompted to provide the current password.
<pre class="cmdbox">
# <b>passwd</b>
</pre>
<li><b>Boot into multiuser mode.</b>
This can be done by either pressing CTRL-D to resume the normal boot
process or by entering <code>reboot</code>.
</ul>
<h2 id="OpenNTPD">Clock Syncing</h2>
<a href="https://www.openntpd.org">OpenNTPD</a> is a safe and simple
NTP-compatible way to have accurate time on your computer.
The <a href="https://man.openbsd.org/ntpd">ntpd(8)</a> daemon is enabled
by default and will set the clock based on data received from NTP peers.
Once the clock is accurately set, it will be held at a high degree of
accuracy using the configured time servers specified in
<a href="https://man.openbsd.org/ntpd.conf">ntpd.conf(5)</a>.
At boot, <code>ntpd</code> will only jump the clock forward.
If your clock has to be moved backward, manually set the clock using
<a href="https://man.openbsd.org/date">date(1)</a>.
<p>
To use OpenNTPD as a server, add a <code>listen on *</code> line to
<a href="https://man.openbsd.org/ntpd.conf">ntpd.conf(5)</a> file and restart
the daemon.
You can also instruct it to only listen on a specific address or interface.
<p>
When you have <a href="https://man.openbsd.org/ntpd">ntpd(8)</a> listening,
other machines may not be able to synchronize their clocks right away.
This is because time information won't be served until the local clock
is synced with a reasonable level of stability.
Once this level is reached, a "clock is now synced" message will appear in
<code>/var/log/daemon</code>.
<h2 id="TimeZone">Time Zones</h2>
By default OpenBSD assumes your hardware clock is set to Coordinated
Universal Time (UTC) rather than local time.
This can cause problems when <a href="faq4.html#Multibooting">multibooting</a>.
Many other operating systems can be configured to do the same, which avoids
this problem altogether.
<p>
If having the hardware clock set to UTC is a problem, you can change the
default behavior of OpenBSD via
<a href="https://man.openbsd.org/sysctl.conf">sysctl.conf(5)</a>.
For example, put the following in <code>/etc/sysctl.conf</code> to
configure OpenBSD to use a hardware clock set to US Eastern Standard
Time (5 hours behind UTC, so minus 300 minutes):
<pre class="cmdbox">
kern.utc_offset=-300
</pre>
See <a href="https://man.openbsd.org/sysctl.2#KERN_UTC_OFFSET~2">sysctl(2)</a>
for more information.
<p>
Note that the hardware clock must already be running at the desired
offset before booting OpenBSD with the above configuration or the
system time will be incorrectly adjusted at boot.
<p>
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 <code>/usr/share/zoneinfo</code>.
For example, to set the machine to use EST5EDT as the new local time zone:
<pre class="cmdbox">
# <b>ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime</b>
</pre>
Also see the <a href="https://man.openbsd.org/date">date(1)</a> manual.
<h2 id="locales">Character Sets and Localization</h2>
The OpenBSD base system fully supports the ASCII character set and encoding,
and partially supports the UTF-8 encoding of the Unicode character set.
No other encodings or character sets are supported by the base system, but
ports can be used to handle them.
The level of UTF-8 support and the default encoding configuration vary greatly
with the program or library.
<p>
To use the Unicode character set in UTF-8 encoding wherever supported, set the
<code>LC_CTYPE</code> environment variable to the value
<code>en_US.UTF-8</code>:
<ul>
<li>
If logging in via <a href="https://man.openbsd.org/xenodm">xenodm(1)</a>,
add <code>export LC_CTYPE="en_US.UTF-8"</code> to your
<code>~/.xsession</code>
before starting the window manager.
See <a href="faq11.html#CustomizingX">customizing X</a> for more details.
<li>
If logging in via the text console, add
<code>export LC_CTYPE="en_US.UTF-8"</code> to your <code>~/.profile</code>.
The text console's UTF-8 support is a work in progress, and some non-ASCII
characters may not display properly.
</ul>
When logging into remote systems with
<a href="https://man.openbsd.org/ssh">ssh(1)</a>, the <code>LC_CTYPE</code>
environment variable is not propagated, and you have to make sure that the
local terminal is set to the character encoding used by the remote server
before connecting.
If that encoding is unknown or unsupported by OpenBSD, make sure you use the
default <a href="https://man.openbsd.org/xterm">xterm(1)</a> configuration and
set <code>LC_CTYPE=en_US.UTF-8</code> in the remote shell after connecting.
<p>
The OpenBSD base system completely ignores all locale-related environment
variables except <code>LC_CTYPE</code>; even <code>LC_ALL</code> and
<code>LANG</code> only affect the character encoding.
Some ports may respect other <code>LC_*</code> variables,
but using them or setting <code>LC_CTYPE</code> to any value other than
<code>C</code>, <code>POSIX</code> or <code>en_US.UTF-8</code>
is not recommended.
<h2 id="SMT">Symmetric Multithreading, or "Why are only half of my CPUs used?"</h2>
Some CPUs use Symmetric Multithreading (SMT; Intel's implementation is
known as "Hyper-Threading").
In this case, one physical processor presents an extra logical
processor to the OS - shown as a separate CPU in
<a href="https://man.openbsd.org/dmesg">dmesg(8)</a> and tools like
<a href="https://man.openbsd.org/top">top(1)</a>.
These do not have full CPU resources but are there to allow sharing part
of a single core's resources with more than one concurrent process.
<p>
This feature can improve performance for some workloads but reduces
it for others.
<p>
SMT has been involved in various CPU vulnerabilities, in particular
relating to speculative execution.
This can result in processes learning information about other
processes which they should not have access to.
To mitigate this, OpenBSD disables running code on detected SMT
"virtual" cores by default.
<p>
They can be reenabled by setting the sysctl <code>hw.smt</code> to
<code>1</code>, however doing so is generally not recommended.
<h2 id="SKey">Using S/Key</h2>
S/Key is a "one-time password" authentication system.
It generates a sequence of one-time (single use) passwords from a user's
secret passphrase along with a challenge received from the server, by means of a
hash function:
<a href="https://man.openbsd.org/md5">md5</a>,
<a href="https://man.openbsd.org/sha1">sha1</a> or
<a href="https://man.openbsd.org/rmd160">rmd160</a>.
<blockquote>
<b>WARNING:</b>
One-time password systems only protect authentication information.
They do not prevent network eavesdroppers from gaining access to private
information.
Furthermore, if you are accessing a secure system A, it is recommended that
you do this from another trusted system B, to ensure nobody is gaining access
to system A by logging your keystrokes or by capturing and/or forging input
and output on your terminal devices.
</blockquote>
<h3>Setting Up S/Key</h3>
To start off, the directory <code>/etc/skey</code> must exist.
If this directory doesn't exist, have the superuser create it by doing:
<pre class="cmdbox">
# <b>skeyinit -E</b>
</pre>
Then use
<a href="https://man.openbsd.org/skeyinit">skeyinit(1)</a>
to initialize your S/Key.
You will first be prompted for your login password, then you will be asked for
your S/Key secret passphrase, which must be at least 10 characters long:
<pre class="cmdbox">
$ <b>skeyinit</b>
Password:
[Adding ericj with md5]
Enter new secret passphrase:
Again secret passphrase:
ID ericj skey is otp-md5 100 oshi45820
Next login password: HAUL BUS JAKE DING HOT HOG
</pre>
Notice the information in the last two lines.
The program used to create your S/Key password is
<a href="https://man.openbsd.org/otp-md5">otp-md5(1)</a>,
the sequence number is <code>100</code> and the secret key is
<code>oshi45820</code>.
The six small words <code>HAUL BUS JAKE DING HOT HOG</code> constitute the S/Key
password with sequence number <code>100</code>.
<h3>Generating S/Key Passwords</h3>
To generate the S/Key password for the next login, use
<a href="https://man.openbsd.org/skeyinfo">skeyinfo(1)</a>
to find out what command to run:
<pre class="cmdbox">
$ <b>skeyinfo -v</b>
otp-md5 95 oshi45820
$ <b>otp-md5 95 oshi45820</b>
Enter secret passphrase:
NOOK CHUB HOYT SAC DOLE FUME
</pre>
In order to generate a list of S/Key passwords, do:
<pre class="cmdbox">
$ <b>otp-md5 -n 5 95 oshi45820</b>
Enter secret passphrase:
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
</pre>
<h3>Using S/Key to Log In</h3>
Here is an example session using S/Key to log in to an ftp server on
<code>localhost</code>.
To perform an S/Key login, you append <code>:skey</code> to your login name.
<pre class="cmdbox">
$ <b>ftp localhost</b>
Connected to localhost.
220 oshibana.shin.ms FTP server (Version 6.5/OpenBSD) ready.
Name (localhost:ericj): <b>ericj:skey</b>
331- otp-md5 93 oshi45820
331 S/Key Password: <b>JOEY SOOT PHI KYLE CURT REEK</b>
[...]
230 User ericj logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> <b>quit</b>
221 Goodbye.
</pre>
Similarly, for <a href="https://man.openbsd.org/ssh">ssh(1)</a>:
<pre class="cmdbox">
$ <b>ssh -l ericj:skey localhost</b>
otp-md5 91 oshi45821
S/Key Password: <b>SHIM SET LEST HANS SMUG BOOT</b>
Last login: Thu Apr 7 12:21:48 on ttyp1 from 156.63.248.77
$
</pre>
<h2 id="Dir">Directory Services</h2>
OpenBSD can be used for both servers and clients of databases containing
user credentials, group information and other network-related data.
<p>
Of course, you could use various directory services on OpenBSD.
But YP is the only one that can be accessed directly using standard
C-library functions like
<a href="https://man.openbsd.org/getpwent">getpwent(3)</a>,
<a href="https://man.openbsd.org/getgrent">getgrent(3)</a>,
<a href="https://man.openbsd.org/gethostbyname">gethostbyname(3)</a>
and so on.
Thus, if you keep your data in a YP database, you do not need to copy it to
local configuration files like
<a href="https://man.openbsd.org/master.passwd">master.passwd(5)</a> before you
can use it, for example to authenticate system users.
<p>
YP is a directory service compatible with Sun Microsystems NIS
(Network Information System).
See <a href="https://man.openbsd.org/yp">yp(8)</a> 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+.
<p>
To use directory services other than 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 <code>sysutils/login_ldap</code> port when you
choose the former,
while the <a href="https://man.openbsd.org/ypldap">ypldap(8)</a>
daemon provides the latter.
<p>
For some applications, simply synchronizing a small number of configuration
files among a group of machines using tools like
<a href="https://man.openbsd.org/rdist">rdist(1)</a>,
<a href="https://man.openbsd.org/cron">cron(8)</a>,
<a href="https://man.openbsd.org/scp">scp(1)</a> or
<code>rsync</code> (available from ports) constitutes an easy and robust
alternative to a full-blown directory service.
<h3 id="YP_secure">YP Security Considerations</h3>
For compatibility reasons, all security features built into the OpenBSD
implementation of YP are switched <i>off</i> by default.
Even when they are all switched on, the NIS protocol is still inherently
insecure for two reasons:
All data, including sensitive data like password hashes, is transmitted
unencrypted across the network, and neither the client nor the server can
reliably verify each other's identity.
<p>
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.
<h3 id="YP_server">Setting Up a YP Server</h3>
A YP server serves a group of clients called a "domain."
You should first select a domain name; it can be an arbitrary string and
need not be related in any way to DNS domain names.
Choosing a random name like "Eepoo5vi" can marginally improve security,
though the effect is mostly in security by obscurity.
In case you need to maintain several distinct YP domains, it's probably
better to choose descriptive names like "sales," "marketing" and "research"
in order to forestall system administration errors caused by obscurity.
Also note that some versions of SunOS require using the host's DNS domain
name, so your choice might be restricted in a network including such hosts.
<p>
Use the <a href="https://man.openbsd.org/domainname">domainname(1)</a>
utility to set the domain name, and put it into the
<a href="https://man.openbsd.org/defaultdomain">defaultdomain(5)</a>
file to have it automatically set at system startup time.
<pre class="cmdbox">
# <b>echo "puffynet" > /etc/defaultdomain</b>
# <b>domainname `cat /etc/defaultdomain`</b>
</pre>
Initialize the YP server using the interactive command:
<pre class="cmdbox">
# <b>ypinit -m</b>
</pre>
At this point, it is not necessary to specify slave servers yet.
To add slave servers, you can rerun
<a href="https://man.openbsd.org/ypinit">ypinit(8)</a>
later, using the <code>-u</code> option.
Setting up at least one slave server for each domain is useful to avoid
service interruptions.
For example, should the master server ever go down or lose network
connectivity, client processes trying to access YP maps block indefinitely
until they receive the requested information.
Thus, YP service interruptions typically render the client hosts completely
unusable until YP is back to service.
<p>
Decide where to store the source files to generate your YP maps from.
Keeping the server configuration separate from the served configuration
helps to control which information will be served and which won't, so the
default <code>/etc</code> often isn't the best choice.
<p>
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
<a href="https://man.openbsd.org/user">user(8)</a> and
<a href="https://man.openbsd.org/group">group(8)</a>.
Instead, you will have to edit the configuration files with a text editor.
<p>
To define the source directory, edit the file
<code>/var/yp/`domainname`/Makefile</code>
and change the <code>DIR</code> variable, e.g.
<pre class="cmdbox">
DIR=/etc/yp/src/puffynet
</pre>
Consider customizing other variables in
<code>/var/yp/`domainname`/Makefile</code>.
See <a href="https://man.openbsd.org/Makefile.yp">Makefile.yp(8)</a>
for details.
<p>
For example, even in case you use the default source directory
<code>/etc</code>, 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 <code>MINUID</code>, <code>MAXUID</code>,
<code>MINGID</code> and <code>MAXGID</code> and adjust them to you needs.
<p>
If all your YP clients run OpenBSD or FreeBSD, exclude the encrypted
passwords from the <code>passwd</code> maps by setting <code>UNSECURE=""</code>
in <code>/var/yp/`domainname`/Makefile</code>.
<p>
The former practice of editing the template file
<code>/var/yp/Makefile.yp</code> 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.
<p>
Create the source directory and populate it with the configuration files
you need.
See <a href="https://man.openbsd.org/Makefile.yp">Makefile.yp(8)</a>
to learn which YP maps require which source files.
For the format of the individual configuration files, refer to
<a href="https://man.openbsd.org/passwd.5">passwd(5)</a>,
<a href="https://man.openbsd.org/group.5">group(5)</a>,
<a href="https://man.openbsd.org/hosts">hosts(5)</a>
and so on, and look at the examples in <code>/etc</code>.
<p>
Create the initial version of your YP maps using the commands
<pre class="cmdbox">
# <b>cd /var/yp</b>
# <b>make</b>
</pre>
Do not worry about error messages from
<a href="https://man.openbsd.org/yppush">yppush(8)</a> right now.
The YP server is not yet running.
<p>
YP uses <a href="https://man.openbsd.org/rpc">rpc(3)</a>
(remote procedure calls) to communicate with clients, so it is necessary
to enable <a href="https://man.openbsd.org/portmap">portmap(8)</a>.
To do so, use <a href="https://man.openbsd.org/rcctl">rcctl(8)</a>.
<pre class="cmdbox">
# <b>rcctl enable portmap</b>
# <b>rcctl start portmap</b>
</pre>
Consider using either the
<a href="https://man.openbsd.org/securenet">securenet(5)</a> or the
<a href="https://man.openbsd.org/ypserv.acl">ypserv.acl(5)</a>
security feature of the YP server daemon.
But be aware that both of these only provide IP based access control.
Thus, they only help as long as potential attackers have neither physical
access to the hardware of the network segments carrying your YP traffic
nor root access to any host connected to those network segments.
<p>
Finally, start the YP server daemon:
<pre class="cmdbox">
# <b>rcctl enable ypserv</b>
# <b>rcctl start ypserv</b>
</pre>
To test the new server, consider making it its own client,
following the instructions in the first part of the next section.
In case you don't want the server to use its own maps, you can
disable the client part after the test with the following commands:
<pre class="cmdbox">
# <b>rcctl stop ypbind</b>
# <b>rcctl disable ypbind</b>
</pre>
Remember that each time you change a file sourced by a YP map,
you must regenerate your YP maps.
<pre class="cmdbox">
# <b>cd /var/yp</b>
# <b>make</b>
</pre>
This updates all database files in <code>/var/yp/`domainname`</code>, with
one exception: The file <code>ypservers.db</code>, listing all YP master
and slave servers associated with the domain, is created directly
from <code>ypinit -m</code> and modified exclusively by <code>ypinit -u</code>.
In case you accidentally delete it, run <code>ypinit -u</code> to recreate
it from scratch.
<h3 id="YP_client">Setting Up a YP Client</h3>
Setting up a YP client involves two distinct parts.
First, you must get the YP client daemon running,
binding your client host to a YP server.
Completing the following steps will allow you to retrieve data
from the YP server, but that data will not yet be used by the system:
<p>
Like on the server, you must set the domain name and enable the portmapper:
<pre class="cmdbox">
# <b>echo "puffynet" > /etc/defaultdomain</b>
# <b>domainname `cat /etc/defaultdomain`</b>
# <b>rcctl enable portmap</b>
# <b>rcctl start portmap</b>
</pre>
It is recommended to provide a list of YP servers in the configuration
file <code>/etc/yp/`domainname`</code>.
Otherwise, the YP client daemon will use network broadcasts to find
YP servers for its domain.
Explicitly specifying the servers is both more robust and marginally
less open to attack.
If you have not set up any slave servers, just put the host name
of the master server into <code>/etc/yp/`domainname`</code>.
<p>
Enable and start the YP client daemon,
<a href="https://man.openbsd.org/ypbind">ypbind(8)</a>.
<pre class="cmdbox">
# <b>rcctl enable ypbind</b>
# <b>rcctl start ypbind</b>
</pre>
If all went well you should be able to query the YP server using
<a href="https://man.openbsd.org/ypcat">ypcat(1)</a>
and see your passwd map returned.
<pre class="cmdbox">
# <b>ypcat passwd</b>
bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh
...
</pre>
Another useful tool for debugging your YP setup is
<a href="https://man.openbsd.org/ypmatch">ypmatch(1)</a>.
<p>
The second part of configuring a YP client involves editing local configuration
files such that certain YP maps get used by various system facilities.
Not all servers serve all standard maps supported by the operating system, some
servers serve additional non-standard maps, and you are by no means compelled to
use all those maps.
Which of the available maps shall or shall not be used, and for which purposes
they shall be used, is fully at the discretion of the client host's system
administrator.
<p>
For a list of standard YP maps and their standard usage, see
<a href="https://man.openbsd.org/Makefile.yp">Makefile.yp(8)</a>.
<p>
If you want to include all user accounts from the YP domain, append the
default YP marker to the master password file and rebuild the password
database:
<pre class="cmdbox">
# <b>echo '+:*::::::::' >> /etc/master.passwd</b>
# <b>pwd_mkdb -p /etc/master.passwd</b>
</pre>
For details on selective inclusion and exclusion of user accounts, see
<a href="https://man.openbsd.org/passwd.5">passwd(5)</a>.
To test whether inclusion actually works, use the
<a href="https://man.openbsd.org/id">id(1)</a> utility.
<p>
If you want to include all groups from the YP domain, append the default YP
marker to the group file:
<pre class="cmdbox">
# <b>echo '+:*::' >> /etc/group</b>
</pre>
For details on selective group inclusion, see
<a href="https://man.openbsd.org/group.5">group(5)</a>.
![[BACK]](/icons/back.gif){kind=icon}
Return to faq10.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq