On Mon, Jul 19, 2021 at 01:59:18PM +0200, Paul de Weerd wrote:
| So far, I've found NFS and syslogd to need configuration changes or
| /etc/hosts entries to ensure they start properly.
As I was asked about this off-list, I went back and re-read my
message. Apologies for not being more clear:
syslog:
If you configure a remote syslog server to receive messages from your
OpenBSD machine, there are two separate issues. First, a hostname
will not resolve to an IP address if the network is not up yet
(because dhcpleased/slaacd are still waiting for a response from the
local dhcpd(8) or rad(8)). This shows up as
syslogd[73481]: bad hostname "@udp4://tuna"
if your configuration has '@udp4://tuna' as a target. The solution is
to create an entry in /etc/hosts.
However, now when the system boots, syslog will have a target IP
address to communicate with, but it still doesn't have an IP address
for itself. So any traffic sent to the target is lost, until
dhcpleased configures an address on the autoconf interface. This
results in, for example, the dmesg from the freshly booting machine
not ending up on the remote syslog host.
nfs client:
If your /etc/fstab contains NFS mounts to a remote host, the fact that
dhcpleased doesn't wait for a lease will mean that NFS mounts cannot
happen until a lease has been configured. This shows up as "NFS
Portmap: RPC: Port mapper failure - RPC: Unable to send", and a delay
during boot that's significantly longer than the timeout from
dhclient.
For the record, my clients here are all vmm(4) VMs running OpenBSD.
The NFS server and syslog target also run OpenBSD.
Cheers,
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
