Common steps for new childen

Creating a new virtual machine

Create a new virtual machine, which will use a “child” disk image.

Identifying the new machine
Handling automatic address assignment
Log into the machine running the “DHCP server”

SSH will do nicely.

Modify the configuration for the “DHCP server”
cpytobak /etc/dhcpd.conf
echo ${VISUAL}
sudoedit /etc/dhcpd.conf

Add support for the machine's MAC-48 address, using these steps:

Copy the configuration from another machine

Find a line that says “host static-client {”, and which is just before a bunch of configuration options for another machine that will have similar values for things like the routers and domain-name-servers.

Use a text editor's “copy and paste” features to duplicate that section.

Customize the comment

The comment that provides the machine's name should be updated to refer to the new system, not the older system that is having its configuration copied.

Customize the MAC-48 address

If this guide has been getting followed the whole time, then the MAC-48 address includes the “VMNUM” of the machine. Find the VMNUM from the old machine, and update that to use the VMNUM of the new machine.

Also, if this guide has been getting followed the whole time, then the end of the MAC address has a reference to the NIC number. In most cases, that should probably be 01 (for the system's first NIC.)

Customize the IPv4 address that will be handed out

Refer to the network documentation, which hopefully has such addresses documented.

If such documentation does not have the IPv4 address because no decision has been made about which IPv4 address to use, then take care of that problem by making a decision. The system addressing plan: early addresses and system addressing plan: first half of octet may be helpful in choosing addresses (if such choices have not yet been made). After making such a decision, make sure the document that decision in the network documentation, and then update this /etc/dhcpd.conf file.

Customize related comments
Check the entire configuration section that is related to this machine. Make sure that all references to the machine's name are correctly referring to the right machine. Make sure all other data seems sensible.
Cause the “DHCP server” to use the updated configuration.
  • With the ISC “DHCP server” software (or at least Henning Brauer's reworking of it, included with OpenBSD), this is done by terminating the software, and starting a new copy of it. (OpenBSD manual page for dhcpd: “BUGS” section discusses the non-support of using SIGHUP to just reload the configuration files.)

On systems other than OpenBSD, the following may need to be customized due to ps implementation differences.

dhcpd -n
echo ${?}
ps -auxww | grep -i dhcpd | grep -v grep
sudo kill $(pgrep dhcpd )
sudo dhcpd
ps -auxww | grep -i dhcpd | grep -v grep
Start the virtual machine

In general, it makes sense to delay this until after the “automatic addressing” is configured. That way, the new system will benefit from the automatic addressing during the system's boot process. However, the later steps frequently do not benefit from additional delay, so starting the machine's boot

  • echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}
    ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
  • If you need to unpause the machine, go ahead and do that (by use Qemu monitor).
Handling Name Resolution

(Some of this may be similar to the original configuration of the computer running the DNS server.)

Log into the computer running the “DNS server”

SSH can do a fine job.

Update the internal zone files
Forward DNS zone files

Here are some directions that are specific to some “nameserver” software. (Follow the directions that match what software is being used.)

Updating forward DNS zones with NSD

If you have been following this guide:

ls -l /var/nsd/zones/
ls -l /var/nsd/zones/internal/
cpytobak /var/nsd/zones/internal/iSOMETHING
echo ${VISUAL}
sudoedit /var/nsd/zones/internal/iSOMETHING

(The desired file to update is likely the one that is named similar to VMGenNam, although VMGenNam is likely defined on a different computer, so trying to actually use that variable will probably not be a worthwhile approach.)

(Then, after changing the data files, the DNS server will need to be restarted, which is discussed later.)

Updating forward DNS zones in BIND
echo ${BINDCFHM}
export BINDCFHM=/var/named/.
echo ${BINDCFHM}
sudo ls -l ${BINDCFHM}/master/internal/
cpytobak ${BINDCFHM}/master/internal/DEMODOM.zz
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/internal/example.zz

These instructions assume that the zone already has some entries, so adding support for a new system may be as simple as properly copying one of those entries, and then editing the copy. If further details are needed, see setting up the DNS server.)

Also handle “Reverse DNS

Further details about setting up Reverse DNS may be found in this earlier section: Reverse DNS (in BIND)

Updating Reverse DNS zones with NSD

If you have been following this guide:

ls -l /var/nsd/zones/
ls -l /var/nsd/zones/internal/
ls -l /var/nsd/zones/internal/iv?rdns*
cpytobak /var/nsd/zones/internal/iv?rdns*
echo ${VISUAL}
sudoedit /var/nsd/zones/internal/iv6rdns*

(Perform for both IPv6 and IPv4.)

(The following example does not back up the file, because it was presumably backed up by the prior example which included a wildcard.)

echo ${VISUAL}
sudoedit /var/nsd/zones/internal/iv4rdns*

(Then, after changing the data files, the DNS server will need to be restarted, which is discussed later.)

Updating Reverse DNS zones in BIND
echo ${BINDCFHM}
export BINDCFHM=/var/named/.
echo ${BINDCFHM}
sudo ls -l ${BINDCFHM}/master/internal/rdns
IPv6 “Reverse DNS
cpytobak ${BINDCFHM}/master/internal/rdns/rdnsfds8
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/internal/rdnsfds8
IPv4 “Reverse DNS

(For those who are using “copy and paste” of these instructions, see the prior instructions for an example of listing the files.)

cpytobak ${BINDCFHM}/master/internal/rdns/19202s24
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/internal/19202s24
Update the zone files containing details about the “publicly accessible”/external IP addresses

This is only needed if the server ought to be accessible to the outside world. For instance, a webserver might be accessible via the HTTP protocol, while automatic address assignment (e.g. DHCP/IPv4) or a server focused on handling backups of internal data, might not need so much direct accessisibility from a connection coming from the Internet.

echo ${BINDCFHM}
export BINDCFHM=/var/named/.
echo ${BINDCFHM}
sudo ls -l ${BINDCFHM}/master/
cpytobak ${BINDCFHM}/master/DEMODOM.zz
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/example.zz
Also handle “Reverse DNS” on the external IP addresses

(These next two text sections should be reviewed for possible merging...)

Revised text

This is only necessary for each unique publicly-accessible IP address that will be pointing to this system. If the system is not using its own unique publicly-accessible IP address (such as if it only gets accessed by using traffic that is redirected from another IP address that already has a Reverse DNS entry), there may be no need to do this process for the newly created computer.

Further details about setting up Reverse DNS may be found in this earlier section: Reverse DNS (in BIND)

Earlier text

This only applies if a new external/public IP address is used. So, if no new external/public IPv4 address is being used, then there's no need to update the IPv4 “Reverse DNS”. (This isn't even a case of updating “Reverse DNS” being optional but not required. This is a case of there not really being an update to perform.)

These instructions are meant to be quick, so the intent is to copy a successful configuration that is being used by another machine. If this is the first “Reverse DNS” entry for the network, the process may take a bit longer than doing a “copy and paste”-then-customize process. (In that case, see setting up the DNS server for details.)

Updating External Reverse DNS in NSD

(No info is here at this time.)

Updating External Reverse DNS in BIND
echo ${BINDCFHM}
export BINDCFHM=/var/named/.
echo ${BINDCFHM}
sudo ls -l ${BINDCFHM}/master/rdns
IPv6 “Reverse DNS
cpytobak ${BINDCFHM}/master/rdns/rdns20010db8
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/internal/rdns20010db8
IPv4 “Reverse DNS

(For those who are using “copy and paste” of these instructions, see the prior instructions for an example of listing the files.)

cpytobak ${BINDCFHM}/master/rdns/203000113s24
echo ${VISUAL}
sudoedit ${BINDCFHM}/master/203000113s24
Make sure the “DNS server” software is using the updated configuration
Having NSD and Unbound reload
Having NSD reload
sudo nsd-checkconf -v /var/nsd/etc/nsdint.cnf
sudo nsd-checkconf /var/nsd/etc/nsdint.cnf
echo ${?}

The next command is completely unnecessary, but it seems sensible to see what instances are running. (Then, if something silly happens, like forgetting to type -HUP, there may be a recent report of what was running.) On systems other than OpenBSD, the following may need to be customized due to ps implementation differences.

ps -auxww | grep nsd | grep -v grep

The following tells all NSD instances to update. If a system has multiple NSD instances, and if the configuration used by the other NSD instance didn't get updated, then reloading shouldn't break anything, so sending a SIGHUP to all instances ought to be rather okay.

sudo pkill -HUP nsd
Getting Unbound to update

This is unnecessary if the domain name and IP addresses are all brand new, because there should not be any old information cached for these names.

Also, Unbound should flush away any old information that is cached. Experience has shown that restarting Unbound has proven to be an effective way to get the new settings enabled. If performance on a busy server is an issue, then the desirable action may be to flush away information about only the updated domains. For small servers, just removing all of the cache (for the rather uncommon occasions when DNS is getting updated) may be tolerable.

The easy way

To be safe, the recommended process is to display a quick reminder of the command line that was used to start unbound. On systems other than OpenBSD, the following may need to be customized due to ps implementation differences.

ps -auxww | grep -i unbound | grep -v grep

The man page for unbound.conf tells us that unbound will perform a reload upon receiving SIGHUP.

sudo pkill -HUP unbound
The long way

This also works.

First, figure out the precise command line used to load the unbound command.

On systems other than OpenBSD, the following may need to be customized due to ps implementation differences.

ps -auxww | grep -i unbound | grep -v grep

Then restart it. e.g.:

sudo pkill unbound
sudo unbound -c /var/unbound/etc/unbndint.cnf
The efficient way

This may be a bit more manual work, but then results in the unbound program doing less work, which may be desirable on a busy server.

This has not been fully tested at the time of this writing... At the time of this writing, this documentation is mainly a pointer to some (unverified/untested) steps.

Preparation must be done

First, this option is not available unless some preparation steps were made. Namely, the configuration file will need a couple of lines such as:


remote-control:
control-enable: yes

Further info about supporting control is at: the Unbound guide: Generating keys for unbound-control.

Steps to proceed

This is recommended to start with:

sudo -u _unbound unbound-control -c /var/unbound/etc/unbndint.cnf status
echo ${?}

Make sure that returns zero (“0”) before continuing...

Then, “reload” is the easy step (which probably isn't much more effective than just sending a SIGHUP to unbound's process). That easy step will make sweeping changes that ought to be effective.

sudo -u _unbound unbound-control -c /var/unbound/etc/unbndint.cnf reload

e.g.:

$ sudo -u _unbound unbound-control -c /var/unbound/etc/unbndint.cnf reload
ok
$ echo ${?}
0
$

There are some alternatives that may be more precise, although require some more information. At this point, the man page for unbound-control and unbound-control-setup can be nice to have available (particularly since this documentation isn't currently showing a bunch of examples). Using an appropriate “flush” command will be faster and will be suitably effective in most situations. Actually, the most precise option may be “flush_type”, which also requires knowing which resource record type (e.g., “TXT”) to remove. Using flush_zone is a more thorough process that is a bit slower than some of the other options, but may still be faster than reload since flush_zone still targets just information about a specific domain.

Having BIND reload
echo ${BINDCFHM}
sudo named-checkzone example.zz ${BINDCFHM}/etc/named.conf
  • This example is using example.zz as the domain name. (That is the name for an entire zone, not the DNS name of an individual machine.) Customize as appropriate.
  • Repeat for each zone that was edited.

(Try sending a SIGHUP.)

sudo ls -l /var/run/
sudo kill -HUP $( sudo cat /var/run/named.pid )
Handling firewall

ACTUALLY, SKIP THIS.
(These notes remain in case they are useful to copy to another section.) In general, redirecting traffic to the new server may not be the best course of action to take, at least until the new system's services are configured.

This may require some more details than just the name and address of the machine. If those details aren't available yet, you might choose to delay this action. (Just know that network communications might not work until this does get done.)

  • Log into the firewall
  • Start modifying the firewall's configuration file
  • If you know what TCP port communication and/or UDP port communication (or SCTP port communication) is going to be needed by the new machine, you can add the new rules at this time.
    • cpytobak /etc/pf.conf
      sudoedit /etc/pf.conf
    • Details about IANA's listing of service ports references the most recognized lists of TCP ports and UDP ports (which are IANA's lists, and the /etc/services file found on Unix machines). Also, the IPv4 “Protocol” field and the corresponding IPv6 “Next Header” field may be useful for other types of protocols that are documented by Details about IANA's listing of protocols at the /etc/protocols file found on Unix machines).
    • From reading OpenBSD's manual page for /etc/pf.conf, it seems that protocols mentioned by /etc/protocols is supported, so therefore SCTP would be supported. That doesn't necessarily mean that SCTP port numbers would be recognized...
  • After the new rules are added:

    sudo pfctl -n -f /etc/pf.conf && sudo pfctl -f /etc/pf.conf
Add machine to system startup sequence

Actually, maybe this is undesirable. Consider whether this machine should be started automatically, or manually.

These are not meant to be full instructions for setting up “virtual machine” auto-starting. However, if a solution has already been implemented (discussed elsewhere in this guide), then consider editing a file to add support for this machine.

The following example commands might be useful for those who have set up “virtual machine” auto-starting by following instructions from another part of this guide (“virtual machine” auto-starting).

cpytobak /etc/virtmach.tmx
echo ${?}
sudoedit /etc/virtmach.tmx
Remotely access the new machine
Rationale

If these steps are being followed manually, then setting up the DNS data (and mucking with the firewall configuration, if that was also done) may have taken sometime. During that time, the new machine has likely contacted the DHCP/IPv4 server to obtain a new address. That probably should work as an address that can be used to remotely access the machine using a protocol such as SSH. This may end up meaning that there is no need to have a VNC client communicate over a forwarded SSH port to reach Qemu's internal VNC server, nor use any other method to see the local display.

(In addition, the system will have a IPv6 link-local address that may be predictable since the MAC-48 address is known. If the MAC-48 address is 12-34-56-79-AB-CD then the IPv6 link-local address may be fe80::1234:56fe:ff79:abcd. However, IPv6 “privacy extensions” may randomize part of that address, making it less predictable. Even if this address is predictable, the link-local nature means that the address cannot be reached by a system on a different network link, which may make this address less convenient than an IPv4 address which, nicely, can be routed internally.)

(At the time of this writing, this guide relies upon manual configuration for a routable IPv6 address. The machine may have the same IPv6 address as the “parent” image. Until the IPv6 address gets customized, the IPv6 address used by this machine might not match the long term documentation. For that reason, using the IPv4 address may temporarily be more convenient, at least at this stage of the process.)

If no time was spent mucking with firewall rules or DNS zones (perhaps because the routine actions have been automated, or perhaps this specific system has been pre-configured in some way), there may be a need to wait a little bit (a minute or two?) for the system to boot up and assign its addresses.

Then, using a nice “remote access” protocol/method may allow a nice way to be able to “copy and paste” into the new machine.

Why this should NOT be done

This will generally mean accepting an SSH key without first verifying it. The more proper way would be to use the virtual machine's local display (visible by using Qemu's built-in VNC server, accessible by using a TCP port that is being forwarded through an SSH tunnel), and then using that to verify the SSH key. If the communications are only going over a trusted network connection, the extra caution may be “going overboard”.

  • Use a remote access protocol, such as SSH, to log into a known IP address that the machine is likely to have. If IPv4 automatic address assignment has been configured, then that automatically assigned address might be more convenient, at this time, than an IPv6 addresses.
Customizing the new machine