File: [local] / www / faq / faq6.html (download) (as text)
Revision 1.468, Fri Oct 28 20:19:04 2022 UTC (19 months, 1 week ago) by stsp
Branch: MAIN
CVS Tags: HEAD
Changes since 1.467: +19 -0 lines
explain how ifconfig nwid can be used to override ifconfig join
ok tj@ kmos@
|
<!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: Networking</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/faq6.html">
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
FAQ - Networking
<small>
<a href="index.html">[FAQ Index]</a>
</small>
</h2>
<hr>
<ul>
<li><a href="#Setup" >Network Configuration</a>
<ul>
<li><a href="#Setup.if" >Identifying and Setting Up
Network Interfaces</a>
<li><a href="#Setup.gateway" >Default Hostname and Gateway</a>
<li><a href="#Setup.resolver">DNS Resolution</a>
<li><a href="#Setup.activate">Activating the Changes</a>
<li><a href="#Setup.chkroute">Checking Routes</a>
<li><a href="#Setup.aliases" >Setting Up Aliases on Interfaces</a>
</ul>
<li><a href="#DHCP" >Dynamic Host Configuration Protocol</a>
<li><a href="#Wireless" >Wireless Networking</a>
<li><a href="#Bridge" >Setting Up a Network Bridge</a>
<li><a href="#Multipath" >Equal-Cost Multipath Routing</a>
<li><a href="#NFS" >Using NFS</a>
</ul>
<hr>
<h2 id="Setup">Network Configuration</h2>
Network configuration in OpenBSD is done with text files in <code>/etc</code>.
Typically, these settings are initially configured during the
<a href="faq4.html">installation process</a>.
<h3 id="Setup.if">Identifying and Setting Up Network Interfaces</h3>
Interfaces are named by the type of card, not the type of connection.
For example, here's a <a href="https://man.openbsd.org/dmesg">dmesg(8)</a>
snippet for an Intel Fast Ethernet network card:
<pre class="cmdbox">
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
</pre>
This device uses the <a href="https://man.openbsd.org/fxp">fxp(4)</a> driver
and is assigned the number 0 here.
<p>
The <a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> utility
will show what network interfaces have been identified on a system.
<pre class="cmdbox">
$ <b>ifconfig</b>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
index 3 priority 0 llprio 3
groups: lo
inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:02:b3:2b:10:f7
index 1 priority 0 llprio 3
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
index 4 priority 0 llprio 3
groups: pflog
</pre>
This sample shows only one physical Ethernet interface: <code>fxp0</code>.
An IP is configured on it, hence the values
<code>inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255</code>.
The <code>UP</code> and <code>RUNNING</code> flags are also set on it.
<p>
The <a href="https://man.openbsd.org/netstart">netstart(8)</a> script configures
network interfaces at boot time using
<a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a> files, where
"if" is replaced by the full name of each interface.
The example above would use the file <code>/etc/hostname.fxp0</code>, containing
the following options:
<pre class="cmdbox">
inet 10.0.0.38 255.255.255.0
</pre>
This <code>hostname.fxp0</code> file also has an interactive equivalent:
<pre class="cmdbox">
# <b>ifconfig fxp0 10.0.0.38 255.255.255.0</b>
</pre>
Several other interfaces come enabled by default.
These are virtual interfaces that serve various functions.
The following manual pages describe them:
<ul>
<li><a href="https://man.openbsd.org/enc">enc(4)</a>
- Encapsulating interface
<li><a href="https://man.openbsd.org/lo">lo(4)</a>
- Loopback interface
<li><a href="https://man.openbsd.org/pflog">pflog(4)</a>
- Packet Filter logging interface
</ul>
Other virtual interfaces can be added with
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a>'s <code>create</code>
subcommand.
<h3 id="Setup.gateway">Default Hostname and Gateway</h3>
The <code>/etc/myname</code> and <code>/etc/mygate</code> files are read by the
<a href="https://man.openbsd.org/netstart">netstart(8)</a> script.
Both of these files consist of a single line, specifying the fully qualified
domain name of the system and the address of the gateway host, respectively.
The <code>/etc/mygate</code> file need not exist on all systems.
See <a href="https://man.openbsd.org/myname">myname(5)</a> for more details.
<h3 id="Setup.resolver">DNS Resolution</h3>
DNS resolution is controlled by the
<a href="https://man.openbsd.org/resolv.conf">resolv.conf(5)</a> file,
which is managed by <a href="https://man.openbsd.org/resolvd">resolvd(8)</a>.
<pre class="cmdbox">
$ <b>cat /etc/resolv.conf</b>
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
</pre>
Here the default domain name will be <code>example.com</code>, there will
be two name servers (<code>125.2.3.4</code> and <code>125.2.3.5</code>)
and the <a href="https://man.openbsd.org/hosts">hosts(5)</a> file will be
consulted before the name servers.
<h3 id="Setup.activate">Activating the Changes</h3>
From here, either reboot or run the
<a href="https://man.openbsd.org/netstart">netstart(8)</a> script:
<pre class="cmdbox">
# <b>sh /etc/netstart</b>
</pre>
A few warnings may be produced when running this script if the interfaces
have already been configured.
Use <a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> to make sure
the interfaces were set up correctly.
<p>
Even though it's possible to completely reconfigure networking on a running
OpenBSD system, a reboot is recommended after any significant changes.
<h3 id="Setup.chkroute">Checking Routes</h3>
Routes can be checked via
<a href="https://man.openbsd.org/netstat">netstat(1)</a> or
<a href="https://man.openbsd.org/route">route(8)</a>.
<pre class="cmdbox">
$ <b>netstat -rn</b>
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 10.0.0.1 UGS 4 16 - 12 fxp0
224/4 127.0.0.1 URS 0 0 32768 8 lo0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UH 2 15 32768 1 lo0
10.0.0/24 link#1 UC 1 4 - 4 fxp0
10.0.0.1 aa:0:4:0:81:d UHL 1 11 - 1 fxp0
10.0.0.38 127.0.0.1 UGHS 0 0 - 1 lo0
$ <b>route show</b>
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 10.0.0.1 UGS 4 16 - 12 fxp0
base-address.mcast localhost URS 0 0 32768 8 lo0
loopback localhost UGRS 0 0 32768 8 lo0
localhost localhost UH 2 15 32768 1 lo0
10.0.0/24 link#1 UC 1 4 - 4 fxp0
10.0.0.1 aa:0:4:0:81:d UHL 1 11 - 1 fxp0
10.0.0.38 localhost UGHS 0 0 - 1 lo0
</pre>
<h3 id="Setup.aliases">Setting Up Aliases on an Interface</h3>
To set up an IP alias on an interface, simply edit its
<a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a> file.
<p>
In this example, two aliases are added to the interface <code>dc0</code>,
which was configured as <code>192.168.0.2</code> with a netmask of
<code>255.255.255.0</code>.
<pre class="cmdbox">
$ <b>cat /etc/hostname.dc0</b>
inet 192.168.0.2 255.255.255.0
inet alias 192.168.0.3 255.255.255.255
inet alias 192.168.0.4 255.255.255.255
</pre>
Once this file has been created, <a href="#Setup.activate">run netstart</a>
or reboot.
To view all aliases, use <code>ifconfig -A</code>.
<h2 id="DHCP">Dynamic Host Configuration Protocol</h2>
The Dynamic Host Configuration Protocol (DHCP) is a way to configure network
interfaces automatically.
OpenBSD can be a DHCP server that configures other machines or a DHCP client
that is configured by a DHCP server.
<h3 id="DHCPclient">DHCP Client</h3>
To use <a href="https://man.openbsd.org/dhcpleased">dhcpleased(8)</a>,
edit the <a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a>
file of the network interface.
The <a href="#Wireless">wireless networking</a> section explains how to
set up wireless interfaces.
For ethernet interfaces, one line is enough:
<pre class="cmdbox">
inet autoconf
</pre>
OpenBSD will gather its IP address, default gateway, and DNS servers from
the DHCP server at startup time.
Other options can be specified in
<a href="https://man.openbsd.org/dhcpleased.conf">dhcpleased.conf(5)</a>.
<p>
To get an IP via DHCP from the command line, run:
<pre class="cmdbox">
# <b>ifconfig xl0 inet autoconf</b>
</pre>
Replace <code>xl0</code> with the interface name.
<h3 id="DHCPserver">DHCP Server</h3>
To use OpenBSD as a DHCP server, enable the
<a href="https://man.openbsd.org/dhcpd">dhcpd(8)</a> daemon at startup:
<pre class="cmdbox">
# <b>rcctl enable dhcpd</b>
</pre>
On the next boot, dhcpd will run and attach to all NICs that have valid
configurations in
<a href="https://man.openbsd.org/dhcpd.conf">dhcpd.conf(5)</a>.
Individual interfaces may be specified instead by naming them explicitly:
<pre class="cmdbox">
# <b>rcctl set dhcpd flags em1 em2</b>
</pre>
An example <code>/etc/dhcpd.conf</code> file might look like this:
<pre class="cmdbox">
# Home
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.2;
option routers 192.168.1.1;
range 192.168.1.3 192.168.1.50;
}
# Guests
subnet 172.16.0.0 netmask 255.255.255.0 {
option domain-name-servers 1.2.3.4, 5.6.7.8;
option routers 172.16.0.1;
range 172.16.0.2 172.16.0.254;
}
</pre>
There are two subnets in this example: a home network and a guest network.
Clients will automatically be given an IP address and pointed to the gateway
and DNS servers specified in their respective sections of the config file.
See <a href="https://man.openbsd.org/dhcp-options">dhcp-options(5)</a> for more
options.
<h3 id="PXE">PXE Booting (i386, amd64)</h3>
The Preboot Execution Environment (PXE) is a standard method of booting systems
using only the network.
A client's PXE-capable NIC broadcasts a DHCP request at the start of the
<a href="faq14.html#BootAmd64">boot process</a> and, rather than only receiving
basic IP/DNS information, is also given a file to boot from.
On OpenBSD, this file is known as
<a href="https://man.openbsd.org/pxeboot">pxeboot(8)</a>, and is typically
served by <a href="https://man.openbsd.org/tftpd">tftpd(8)</a>.
<h2 id="Wireless">Wireless Networking</h2>
OpenBSD has support for
<a href="https://man.openbsd.org/?query=wireless&apropos=1">a number of
wireless chipsets</a>.
Further supported devices can be found in
<a href="https://man.openbsd.org/usb">usb(4)</a> and
<a href="https://man.openbsd.org/pci">pci(4)</a>.
The precise extent of their support is described in the driver man pages.
<p>
The following cards support Host-based Access Point (HostAP) mode, permitting
them to be used as a <a href="pf/example1.html">wireless access point</a>:
<!-- XXXrelease - current list? grep -lRI IEEE80211_C_HOSTAP src/sys/dev -->
<ul>
<li><a href="https://man.openbsd.org/acx">acx(4)</a>
- TI ACX100/ACX111
<li><a href="https://man.openbsd.org/ath">ath(4)</a>
- Atheros 802.11a/b/g
<li><a href="https://man.openbsd.org/athn">athn(4)</a>
- Atheros 802.11/a/g/n devices
<li><a href="https://man.openbsd.org/bwfm">bwfm(4)</a>
- Broadcom and Cypress IEEE 802.11a/ac/b/g/n wireless network device
<li><a href="https://man.openbsd.org/pgt">pgt(4)</a>
- Conexant/Intersil Prism GT Full-MAC 802.11a/b/g
<li><a href="https://man.openbsd.org/ral">ral(4)</a>
and <a href="https://man.openbsd.org/ural">ural(4)</a>
- Ralink Technology RT25x0 802.11a/b/g
<li><a href="https://man.openbsd.org/rtw">rtw(4)</a>
- Realtek 8180 802.11b
<li><a href="https://man.openbsd.org/rum">rum(4)</a>
- Ralink Technology RT2501USB
<li><a href="https://man.openbsd.org/wi">wi(4)</a>
- Prism2/2.5/3
</ul>
The <a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a>
<code>media</code> subcommand shows media capabilities of network interfaces.
For wireless devices, it displays supported 802.11a/b/g/n media modes and the
supported operating modes (<code>hostap</code>, <code>ibss</code>,
<code>monitor</code>).
For example, to see media capabilities of interface <code>ath0</code>, run:
<pre class="cmdbox">
$ <b>ifconfig ath0 media</b>
</pre>
Firmware files acquired with
<a href="https://man.openbsd.org/fw_update">fw_update(8)</a> may be needed
in order to use certain wireless cards.
Some manufacturers refuse to allow <a href="faq1.html#ReallyFree">free</a>
distribution of their firmware, so it can't be included with OpenBSD.
<p>
Another option to consider: use a conventional NIC and an external bridging
wireless access point for the OpenBSD-based firewall.
<h3>Configuring a Wireless Adapter</h3>
Adapters based on supported chips can be used like any other network interface.
To connect an OpenBSD system to an existing wireless network, use the
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> utility.
<p>
An example of a <a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a>
file for a wireless client might be:
<pre class="cmdbox">
nwid puffyuberalles wpakey passwordhere
inet autoconf
</pre>
Or, for multiple access points:
<pre class="cmdbox">
join home-net wpakey passwordhere
join work-net wpakey passwordhere
join cafe-wifi
inet autoconf
</pre>
Note that <code>inet autoconf</code> should be after the other configuration
lines, as the network adapter will not be able to send a DHCP request until
it is configured.
<p>
At runtime, automatic access point selection can be temporarily overridden
with the ifconfig <code>nwid</code> command:
<pre class="cmdbox">
ifconfig ath0 nwid home-net
</pre>
If the given network already exists on the join list, its WPA password will
be used automatically, if required.
The ifconfig <code>-nwid</code> command moves the interface back into
automatic access point selection mode:
<pre class="cmdbox">
ifconfig ath0 -nwid
</pre>
<h3>Trunking a Wireless Adapter</h3>
Trunks are virtual interfaces consisting of one or more network interfaces.
In this section, our example will be a laptop with a wired
<a href="https://man.openbsd.org/bge">bge0</a> interface and a wireless
<a href="https://man.openbsd.org/iwn">iwn0</a> interface.
We will build a <a href="https://man.openbsd.org/trunk">trunk(4)</a> interface
using both of them.
The wired and wireless interfaces must be connected to the same layer two
network.
<p>
To do this, we first activate the two physical ports, then assign them to
<code>trunk0</code>.
<pre class="cmdbox">
# <b>echo up > /etc/hostname.bge0</b>
</pre>
The wireless interface, however, needs a bit more configuration.
It will need to attach to our wireless WPA-protected network:
<pre class="cmdbox">
$ <b>cat /etc/hostname.iwn0</b>
nwid puffynet wpakey mysecretkey
up
</pre>
Now, our trunk interface is defined like this:
<pre class="cmdbox">
$ <b>cat /etc/hostname.trunk0</b>
trunkproto failover trunkport bge0
trunkport iwn0
inet autoconf
</pre>
The trunk is set up in <code>failover</code> mode,
so either interface can be used.
If both are available, it will prefer the <code>bge0</code> port,
since that is the first one added to the trunk device.
<h2 id="Bridge">Setting Up a Network Bridge</h2>
A <a href="https://man.openbsd.org/bridge">bridge(4)</a> is a link between two
or more separate networks.
Unlike a router, packets go through the bridge transparently: the two network
segments appear as one to nodes on either side.
Bridges will only forward packets that have to pass from one segment to the
other and, as a result, an interface in a bridge may or may not have an IP
address of its own.
If it does, the interface has effectively two modes of operation: one as part
of a bridge, the other as a stand-alone NIC.
If neither interface has an IP address, the bridge will pass network data,
but will not be externally maintainable (which can be a feature).
<h3>A Bridge Acting as a DHCP Server</h3>
Let's say we have a system which has four
<a href="https://man.openbsd.org/vr">vr(4)</a> interfaces,
<code>vr0</code> through <code>vr3</code>.
We want to bridge <code>vr1</code>, <code>vr2</code> and <code>vr3</code>
together, leaving out <code>vr0</code> for the uplink.
We also want to serve IP addresses through DHCP over the bridged interfaces.
Being a DHCP server and an uplink router, the box needs to have an IP address
on the bridged network.
<p>
It is not possible to assign an IP address directly to a bridge interface.
The IP address should be added to one of the member interfaces, but we cannot
use a physical interface as the link might be down, in which case the address
would not be reachable.
Fortunately, there is the <a href="https://man.openbsd.org/vether">vether(4)</a>
(virtual Ethernet) driver that can be used for this purpose.
We will add it to the bridge, assign the IP address to it and make
<a href="https://man.openbsd.org/dhcpd">dhcpd(8)</a> listen there.
<ul>
<li>The <a href="#DHCPserver">DHCP server configuration</a> is not described
yet again in this section, but the addressing scheme used here is the
same.
<li>This will also be the uplink router for the bridged network, so we will
use IP address 192.168.1.1 to match the DHCP server configuration.
<li>We will not cover the uplink, routing or firewalling configuration here.
</ul>
First, mark the <code>vr1</code>, <code>vr2</code> and <code>vr3</code>
interfaces as up:
<pre class="cmdbox">
# <b>echo up > /etc/hostname.vr1</b>
# <b>echo up > /etc/hostname.vr2</b>
# <b>echo up > /etc/hostname.vr3</b>
</pre>
Then create the <code>vether0</code> configuration:
<pre class="cmdbox">
# <b>echo 'inet 192.168.1.1 255.255.255.0 192.168.1.255' > /etc/hostname.vether0</b>
</pre>
Configure the bridge interface to contain all the above interfaces:
<pre class="cmdbox">
$ <b>cat /etc/hostname.bridge0</b>
add vether0
add vr1
add vr2
add vr3
up
</pre>
And finally we make the DHCP daemon listen on the <code>vether0</code>
interface:
<pre class="cmdbox">
# <b>rcctl set dhcpd flags vether0</b>
</pre>
And finally, reboot the system.
<h3>Filtering on a Bridge</h3>
<a href="pf/index.html">PF</a> can be used to restrict what traffic goes
through a bridge.
Keep in mind, by the nature of a bridge, the same data flows through both
interfaces, so filtering is only needed on one interface.
<h3>Tips on Bridging</h3>
<ul>
<li>By using the <code>blocknonip</code> option of
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> or in
<a href="https://man.openbsd.org/hostname.if">hostname.bridge0</a>,
non-IP traffic (such as IPX or NETBEUI) can be prevented from slipping
around the filters.
This may be important in some situations, but be aware that
bridges work for all kinds of traffic, not just IP.
<li>Bridging requires that the NICs be in a promiscuous mode.
They listen to <b>all</b> network traffic, not just that directed at
the interface.
This will put a higher load on the processor and bus than one might
expect.
</ul>
<h2 id="Multipath">Equal-Cost Multipath Routing</h2>
Equal-cost multipath routing refers to having multiple routes in the routing
table for the same network, such as the default route, <code>0.0.0.0/0</code>.
When the kernel is doing a route lookup to determine where to send packets
destined to that network, it can choose from any of the equal-cost routes.
In most scenarios, multipath routing is used to provide redundant uplink
connections, e.g., redundant connections to the internet.
<p>
The <a href="https://man.openbsd.org/route">route(8)</a> command is used to
add/change/delete routes in the routing table.
The <code>-mpath</code> argument is used when adding multipath routes.
<pre class="cmdbox">
# <b>route add -mpath default 10.130.128.1</b>
# <b>route add -mpath default 10.132.0.1</b>
</pre>
Verify the routes:
<pre class="cmdbox">
# <b>netstat -rnf inet | grep default</b>
default 10.130.128.1 UGS 2 134 - fxp1
default 10.132.0.1 UGS 0 172 - fxp2
</pre>
In this example we can see that one default route points to
<code>10.130.128.1</code>, which is accessible via the <code>fxp1</code>
interface, and the other points to <code>10.132.0.1</code>, which is accessible
via <code>fxp2</code>.
<p>
Since the <a href="https://man.openbsd.org/mygate">mygate(5)</a> file does not
yet support multipath default routes, the above commands should be added to the
bottom of the <a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a>
files for the <code>fxp1</code> and <code>fxp2</code> interfaces.
The <code>/etc/mygate</code> file should then be deleted.
<pre class="cmdbox">
$ <b>tail -1 /etc/hostname.fxp1</b>
!route add -mpath default 10.130.128.1
$ <b>tail -1 /etc/hostname.fxp2</b>
!route add -mpath default 10.132.0.1
</pre>
Lastly, don't forget to activate the use of multipath routes by enabling the
proper <a href="https://man.openbsd.org/sysctl.8">sysctl(8)</a> variable.
<pre class="cmdbox">
# <b>sysctl net.inet.ip.multipath=1</b>
# <b>sysctl net.inet6.ip6.multipath=1</b>
</pre>
Be sure to edit <a href="https://man.openbsd.org/sysctl.conf">sysctl.conf(5)</a>
to make the changes permanent.
<p>
Now try a traceroute to different destinations.
The kernel will load balance the traffic over each multipath route.
<pre class="cmdbox">
# <b>traceroute -n 154.11.0.4</b>
traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets
1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms
2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms
3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms
4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms
# <b>traceroute -n 154.11.0.5</b>
traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets
1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms
2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms
3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms
4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms
</pre>
For more information about how the route is chosen, please refer to
<a href="https://www.ietf.org/rfc/rfc2992.txt">RFC2992</a>, "Analysis of an
Equal-Cost Multi-Path Algorithm".
<p>
It's worth noting that if an interface used by a multipath route goes down
(i.e., loses carrier), the kernel will still try to forward packets using the
route that points to that interface.
This traffic will of course be blackholed and end up going nowhere.
It's highly recommended to use
<a href="https://man.openbsd.org/ifstated">ifstated(8)</a> to check for
unavailable interfaces and adjust the routing table accordingly.
<h2 id="NFS">Using NFS</h2>
The Network File System, NFS, is used to share a filesystem over the network.
<p>
This section will go through the steps for a simple NFS setup.
The example details a server on a LAN, with clients accessing NFS on the LAN.
It does not cover securing NFS.
<h3>Setting Up an NFS Server</h3>
First, enable the <a href="https://man.openbsd.org/portmap">portmap(8)</a>,
<a href="https://man.openbsd.org/mountd">mountd(8)</a> and
<a href="https://man.openbsd.org/nfsd">nfsd(8)</a> services on the server:
<pre class="cmdbox">
# <b>rcctl enable portmap mountd nfsd</b>
</pre>
Then configure the list of filesystems that will be made available.
<p>
In this example, we have a server with the IP address <code>10.0.0.1</code>.
This server will be serving NFS only to clients within its own subnet.
This is configured in the following
<a href="https://man.openbsd.org/exports">exports(5)</a> file:
<pre class="cmdbox">
$ <b>cat /etc/exports</b>
/docs -alldirs -ro -network=10.0.0 -mask=255.255.255.0
</pre>
The local filesystem <code>/docs</code> will be made available via NFS.
The <code>-alldirs</code> option specifies that clients will be able to mount at
any point under <code>/docs</code> as well as <code>/docs</code> itself.
The <code>-ro</code> option specifies that clients will only be granted
read-only access.
The last two arguments specify that only clients within the
<code>10.0.0.0</code>
network using a netmask of <code>255.255.255.0</code>
will be authorized to mount this filesystem.
<p>
Now start the server-related services:
<pre class="cmdbox">
# <b>rcctl start portmap mountd nfsd</b>
</pre>
If changes are made to <code>/etc/exports</code> while NFS is already running,
mountd must be made aware of this.
<pre class="cmdbox">
# <b>rcctl reload mountd</b>
</pre>
<h3>Mounting NFS Filesystems</h3>
NFS filesystems should be mounted via
<a href="https://man.openbsd.org/mount_nfs">mount(8)</a>, or more specifically,
<a href="https://man.openbsd.org/mount_nfs">mount_nfs(8)</a>.
<p>
To mount the <code>/docs</code> filesystem on host <code>10.0.0.1</code>
to local filesystem <code>/mnt</code>, run:
<pre class="cmdbox">
# <b>mount -t nfs 10.0.0.1:/docs /mnt</b>
</pre>
To have that filesystem mounted at boot, append a line to
<a href="https://man.openbsd.org/fstab">fstab(5)</a> like so:
<pre class="cmdbox">
# <b>echo '10.0.0.1:/docs /mnt nfs ro,nodev,nosuid 0 0' >> /etc/fstab</b>
</pre>
It is important to use <code>0 0</code> at the end of this line so that
the computer does not try to <a href="https://man.openbsd.org/fsck">fsck(8)</a>
the NFS filesystem on boot.
<p>
When accessing an NFS mount as the root user, the server automatically maps
root's access to username <code>nobody</code> and group <code>nobody</code>.
This is important to know when considering file permissions.
For example, take a file with these permissions:
<pre class="cmdbox">
-rw------- 1 root wheel 0 Dec 31 03:00 _daily.B20143
</pre>
If this file was on an NFS share and the root user tried to access this file
from the NFS client, access would be denied.
<p>
The user and group that root are mapped to are configurable via the
<a href="https://man.openbsd.org/exports">exports(5)</a> file on the NFS server.
<h3>Checking Stats on NFS</h3>
One thing to check to ensure NFS is operating properly is that all the daemons
have properly registered with RPC.
To do this, use <a href="https://man.openbsd.org/rpcinfo">rpcinfo(8)</a>.
<pre class="cmdbox">
$ <b>rpcinfo -p 10.0.0.1</b>
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 633 mountd
100005 3 udp 633 mountd
100005 1 tcp 916 mountd
100005 3 tcp 916 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
</pre>
There are a few utilities that allow an administrator to see what is
happening with NFS, such as
<a href="https://man.openbsd.org/showmount">showmount(8)</a>
and <a href="https://man.openbsd.org/nfsstat">nfsstat(1)</a>.
![[BACK]](/icons/back.gif){kind=icon}
Return to faq6.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq