Poor men's NetBSD part II (aka configuring NetBSD for usage in virtualbox)

In my previous post I documented the installation of NetBSD using virtualbox, the result was that at the end we had a virtual instance running which booted to a prompt. While this is already a good starting point, we're still virtually nowhere. 

The first thing we will need however is access to the network, the default installation of virtualbox gave me a pseudo Intel E1000 ethernet adapter which is NAT'ed by default. When the virtual instance boots there is not attempt made to configure the network but after running

dhclient wm0

manually I get an ip address and a connection to my host operating system (and the Internet is possible).  However for my purposes what I really need is the ability to access the guest OS (being NetBSD) from the host OS. (The main reason to do this is because then I can just copy/paste snippets from the console, without the need to keep taking screenshots. In order to accomplish this we need to edit the virtual machine settings:

And here we change the type from NAT to Bridged and we create a bridge with whatever real device your are using on your host system (in this case I'm using my wlan) and then we say we will bridge this with the Intel PRO/1000 which will be visible in the guest (just don't expect gigabit speeds ;-) ). Running a

dhclient wm0

will give you a DHCP lease in your 'regular' domain (in this case a lease handed out by my wireless access point instead of one handed out in a private range by virtualbox itself), the good news is that this ip address is accessible from the host os as well. This implies that I can now connect to it and start copy pasting. And a first copy paste is perhaps the output of ifconfig -a which shows a configured ethernet adapter and the loopback device:

# ifconfig -a
wm0: flags=8843 mtu 1500
        capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
        enabled=0
        address: 08:00:27:4c:94:06
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 192.168.10.104 netmask 0xffffff00 broadcast 192.168.10.255
        inet6 fe80::a00:27ff:fe4c:9406%wm0 prefixlen 64 scopeid 0x1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Now in order to connect to the system it is advised to start the sshd daemon by issuing

# /etc/rc.d/sshd start

Instead of using start you can also use start, stop, restart and status as parameters:

# /etc/rc.d/sshd status
sshd is running as pid 357.

At this point we've done all these tings manually, while we really want the system to do this by default at startup. For this the files /etc/rc.conf  and /etc/defaults/rc.conf come into play. The file /etc/rc.conf is sourced by rc, meaning that rc.conf should contains valid sh-compatible statements (read: setting variables).  man 5 rc.conf  will give you a full description of the known variables, but take also a look in /etc/defaults/rc.conf since this file is sourced by rc.conf:

# Load the defaults in from /etc/defaults/rc.conf (if it's readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
        . /etc/defaults/rc.conf
fi

In the case of sshd, the defaults file states it should not be started:

# cat ./defaults/rc.conf | grep -i ssh
sshd=NO                 sshd_flags=""
ssh_keygen_flags="-b 1024"      # generate 1024 bit keys if host keys missing 

So by adding sshd=YES to /etc/rc.conf we can have the rc system start the ssh daemon at startup. Sometimes you want to know which rc.conf variables can help you to influence the behavior of an initscript. For this you can call an rc.d script with the rcvar  parameter.

# /etc/rc.d/sshd rcvar
# sshd
$sshd=YES

Now all we need after this is proper network configuration, in this case we extend rc.conf with:

dhclient=YES
hostname=flying_spaghetti_monster

Setting the hostname is optional, after a reboot the dhcp client will start and it will be accessible through ssh.

An interesting paper to get a better understanding of the NetBSD rc system can be found at http://www.mewburn.net/luke/papers/rc.d.pdf and there is also the rc chapter in the NetBSD guide at http://www.netbsd.org/docs/guide/en/chap-rc.html

Post scriptum:
In the setup above I suggested the use of a bridged adapter, this however is not without risks, later on I used this setup in combination with an NFS share (NFS share between host and guest), this however resulted in a lot of NFS related packets going over the ether, which caused my poor wireless router to suffocate.  A better solution is to used the 'host-only adapter' option, this will create a virtual interface on your host in a private subnet with your guest, this way (given that your NAT is configured properly) the same requirements as above can be met.