Category Archives: Uncategorized

Secondary DNS Server

Leave a comment

Prerequisites

sudo apt install bind9

Install template files

tar -xvzf /srv/scripts/xfer/202005051009-dns-secondary.tar.gz
cd tmp/dsm-xxxxxxxx/etc/bind
sudo cp ../default/bind /etc/default/
sudo cp * /etc/bind/

Customize template files

cd /etc/bind/
sudo nano named.conf.local
    <edit all "masters" options to provide the
     primary DNS server's IP address>
sudo nano named.conf.options
    <edit the "listen-on" option to reflect the
     host's IP address>

Other environment configuration

sudo mkdir /var/cache/bind/slaves/
sudo chown bind: /var/cache/bind/slaves/

Startup and test

sudo systemctl restart bind9
grep named /var/log/syslog
ls -al /var/cache/bind/slaves

Related or dependent settings

  1. DHCP server settings
  2. Domain NS records
  3. Other?

DHCP Configuration

Leave a comment

Primary DHCP Server

General Settings

These files define the general characteristics of the DHCP Server service. They should work with pretty much any local network configuration.

There is a separate section (below) for Subnet-specific Settings, which is where all the customization for my particular network resides.

dhcpd.conf

This file simply includes other files that contain the specific configuration settings for the DHCP server service.

##############################################################
# Main configuration file for isc-dhcp-server
##############################################################
# PRIMARY, SECONDARY OR SOLE DHCP SERVER (uncomment one)
include "/etc/dhcp/dhcpd.sole.conf";
#include "/etc/dhcp/dhcpd.primary.conf";
#include "/etc/dhcp/dhcpd.secondary.conf";

# Global settings
include "/etc/dhcp/dhcpd.global.conf";

# Settings for the local (subnets)
include "/etc/dhcp/dhcpd.subnet1.conf";

# Settings to support PXE booting
include "/etc/dhcp/dhcpd.pxeboot.conf";

# OMAPI settings (for primary/secondary server communication)
#include "/etc/dhcp/dhcpd.omapi.conf";

As indicated in the comments, this suite of files can be used to define and configure either a “sole” DHCP server or, in a multi-server environment, to specify whether the host machine is a “primary” or secondary” server.

dhcpd.global.conf

Overall (global) dhcpd settings. Not much to say here. The file is pretty well commented.

# Allow only one IP address per MAC address
one-lease-per-client true;

# Set default lease times (in seconds)
#default-lease-time 600;        # 10 minutes for debugging
#max-lease-time 600;            # 10 minutes for debugging
default-lease-time 43200;       # 12 hours
max-lease-time 43200;           # 12 hours

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# Configure dynamic DNS updates (as DHCP ip addresses are allocated)
ddns-updates on;

# bind9 expects standard update style
ddns-update-style standard;

# Do DNS updates even for MAC addresses with static IP reservations
update-static-leases on;

update-optimization off;

dhcpd.sole.conf

This file is also pretty straightforward, since there’s only this server. Mark it as authoritative.

#
# SOLE server configuration settings for isc-dhcp-server
# (LoonSong network)
#

# This DHCP server is the official DHCP server for the local network
authoritative;

################################################################
# Define the failover partnership between this server and
# the secondary DHCP server (uFirewall).

# REMEMBER TO COMMENT OUT THE FAILOVER BIT IN
# dhcpd.subnet*.conf files

dhcpd.primary.conf

Oh, my! I don’t have a copy of this file on my (sole server) machine. Got to dig through the network and backups!

dhcpd.secondary.conf

Here’s the file defining the attributes of the secondary server.

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;


################################################################
# Define the failover partnership between the primary server
# and the secondary DHCP server.
failover peer "failover-partner" {
        secondary;
        address 192.168.178.1;
        peer address 192.168.178.2;
        max-response-delay 60;
        max-unacked-updates 10;
        load balance max seconds 3;
}

dhcpd.pxeboot.conf

This file enables the PXE Boot features, defining 192.168.178.16 as a PXE Boot server.

##############################################################
# PXE boot parameters and identify the PXE server machine
allow booting;
allow bootp;
option option-128 code 128 = string;
option option-129 code 129 = text;
next-server 192.168.178.16;
filename "pxelinux.0";

dhcpd.omapi.conf

I don’t even recall what omapi is for. It’s commented out in the dhcpd.conf for now anyway.

#
# OMAPI configuration file for isc-dhcp-server
# OMAPI is used to share DHCP leases with the secondary server
# (LoonSong network)
#

omapi-port 7911;
omapi-key omapi_key;
key omapi_key {
        algorithm hmac-md5;
        secret "<secret key goes here>";
}

Subnet-specific Settings

dhcpd.subnet1.conf

This is the main subnet file (in this case, for 192.168.178.*).

It includes some other, subsidiary, files that provide specific information that is likely to change as machines are added and removed. These are the DDNS settings and a reservations file.

#
# Subnet and DDNS configuration file for isc-dhcp-server
# (LoonSong network)
#

################################################################
# Include DDNS zone information for this subnet
include "/etc/dhcp/dhcpd.subnet1.DDNS.conf";

################################################################
# Specify the subnet for local IP addresses
subnet 192.168.178.0 netmask 255.255.255.0 {

        # Hardwired IP addresses
        option routers 192.168.178.1;
        option broadcast-address 192.168.178.255;
        option domain-name-servers 192.168.178.1;
        option netbios-name-servers 192.168.178.1;

        # Standard DHCP parameters
        option subnet-mask 255.255.255.0;
        option domain-name "ustiger.local";

        # Additional DDNS parameters
        ddns-domainname "ustiger.local.";
        ddns-rev-domainname "in-addr.arpa.";

        # Define the allocable IP range and failover peer
        pool {
                range 192.168.178.20 192.168.178.200;
#                failover peer "failover-partner";
        }

        # Include static IP reservations for this subnet
        include "/etc/dhcp/dhcpd.subnet1.reservations.conf";
}

dhcpd.subnet1.DDNS.conf

################################################################
# Identify the zone to be used for DDNS updates
# (These zones must match SOA records on the DNS server.)
zone ustiger.local. {
        # Identify the primary DNS server (this machine)
        primary 192.168.178.1;
        # Identify the secondary DNS server
#       secondary 192.168.178.2;
}
zone 178.168.192.in-addr.arpa. {
        # Identify the primary DNS server (this machine)
        primary 192.168.178.1;
        # Identify the secondary DNS server
#       secondary 192.168.178.2;
}

dhcpd.subnet1.reservations.conf

This is the most “dynamic” of the dhcpd configuration files. It reserves IP addresses (within the subnet) for machines that:

  1. Do not set their hostname properly (so we can get a proper hostname over the network).
  2. Require a consistent IP address (often because of other server configurations that require an IP address, rather than a hostname, to define the target machine).

So it gets edited whenever a new machine that meets one of these criteria is added to the network.

I have omitted the repeated entries from the list, since they all have the same format and the same features:

  • MAC address
  • IP address
  • DDNS hostname
#
# Reservation file for isc-dhcp-server
# (LoonSong network, subnet1)
# This file contains the definitions for reserved IP ad dresses.
# Some machines' activities require a known, fixed IP address.
# Others don't properly supply their hostnames, so this is an
# straightforward way to ensure that they can be accessed by
# hostname and not just IP address.
#

##############################################################
### MACHINES THAT DO NOT SET HOSTNAME PROPERLY ###
host hloonSong {
        hardware ethernet xx:xx:xx:xx:xx:xx;
        fixed-address 192.168.178.14;
        ddns-hostname hloonSong;
}

##############################################################
### MACHINES THAT REQUIRE A CONSISTENT IP ADDRESS ###
host wdc01 {
        hardware ethernet xx:xx:xx:xx:xx:xx;
        fixed-address 192.168.178.251;
        ddns-hostname wdc01;
}

DNS Musings

Leave a comment

HowTo: Clean .jnl files

.jnl files grow in the /var/lib/bind/ directory as bind9 operates. They make it a bit difficult/confusing whenever the database file needs to be edited. Here’s how to flush those .jnl files into their main database files:

sudo rndc sync -clean ustiger.local
sudo rndc sync -clean 178.168.192.in-addr.arpa

Consider putting this in a cron script to be run periodically (daily?).

Permission Denied when Opening Serial Port

Leave a comment

When opening a serial port to access a Z-Wave controller, the library may indicate an error such as:

Cannot open serial port /dev/ttyUSB0: Permission denied

On Linux machines, this is often due to the fact that, to control serial ports, the user must be a member of the “dialout” group.

Edit /etc/group to add the user to this group, then log out and log back in to make this group membership effective.

Controller command messages time out despite success

Leave a comment

The Issue

I’ve found that sometimes controller command messages will time out even though they have already completed successfully.

Here’s a log example:

SendZwMessage: 
There are 0 messages in the pending queue ((nil)(0) (nil)(0) (nil)(0)) and a controller function is NOT executing
01:00:29.923 Write Msg D T 7641 N 9 ZwRequestNodeNeighborUpdate starting [with itv 20000 and otv 20000]
01:00:29.923 Write Msg X T - N - Controller Command fn: 0x48 node 9
01:00:29.923 Write Msg M T 7641 N 9 Write: 0x01 0x06 0x00 0x48 0x09 0xbb 0x5c 0x5f
01:00:29.924 Serial In M T - N - Read (controller->buffer): 0x06
01:00:29.925 Read Msg X T - N - Created message 0x95641e8 in HandleIncomingAck
01:00:29.925 Read Msg X T - N - Deleting message 0x95641e8 in SetMessageCompletionStatus
01:00:29.934 Serial In M T - N - Read (controller->buffer): 0x01 0x05 0x00 0x48 0xbb 0x21 0x28
01:00:29.935 Read Msg M T - N - Write: 0x06
01:00:29.935 Read Msg X T - N - Created message 0x95641e8 in HandleIncomingFrame
01:00:29.935 ProcessMsg R T - N 9 Node neighbor update has started.
01:00:29.935 ProcessMsg P T 7641 N 9 ZwRequestNodeNeighborUpdate is OuterCompleteSuccess
01:00:29.935 ProcessMsg X T - N - Deleting message 0xb5e6d570 in RemoveMessageFromPendingQueue2
01:00:29.936 ProcessMsg X T - N - SMQE 2 messages in the send queues, 0 pending, 1 controller
01:00:29.936 ProcessMsg X T - N - Deleting message 0x95641e8 in ProcessMessagesThread
01:00:35.505 Serial In M T - N - Read (controller->buffer): 0x01 0x05 0x00 0x48 0xbb 0x22 0x2b
01:00:35.505 Read Msg M T - N - Write: 0x06
01:00:35.505 Read Msg X T - N - Created message 0x95641e8 in HandleIncomingFrame
01:00:35.505 ProcessMsg X T - N - ZwController::HandleZwRequestNodeNeighborUpdate entered with NULL _pendingMsg. m_controllerCommandNode is 9.
01:00:35.505 ProcessMsg R T - N 9 Node neighbor update completed successfully.
01:00:35.506 ProcessMsg X T - N - SMQE 2 messages in the send queues, 0 pending, 0 controller
01:00:35.506 ProcessMsg X T - N - Deleting message 0x95641e8 in ProcessMessagesThread
01:00:49.923 Write Msg S T 7641 N 9 WriteThread Transaction timed out (after 20000ms) before achieving minimum threshold 2015-11-16 01:00:29.923
01:00:49.923 Write Msg P T 7641 N 9 $㵡 is OuterCompleteTimedOut

The problem appears to be that some controller commands are moved to the “dead node” message list and are mangled (appended to) when they are moved off this list.

Troubleshooting