Today, the first RC of BIND 10 was released. There are some new features that will change how you use my previous articles on this subject. Apart from a slew of bug fixes, there are some functionality changes that will affect both the installation and configuration of BIND 10. The BIND 10 Guide has also been updated to reflect these changes.

The major change of note is:

The previous versions of BIND 10 (I was using 1.0.0-beta previously) would have a master process - bind10. This Boss process was responsible for managing the state of other modules, restarting them when they fail, and so on. bind10 is now a shell script that fires up b10-init. This keeps the module names consistent, and we can now address the module as Init. Thus, a Boss shutdown now becomes Init shutdown, Boss show_processlist becomes Init show_processlist, config add /Boss/components b10-auth is now config add /Init/components b10-auth, and so on.

Building the Release Candidate of BIND 10

I have two BIND 10 instances running on two servers in a master/slave configuration. The notable piece above is “Existing configuration is automatically updated”. Time to compile. All prerequisites are already available on both nodes (for a thorough walk-through of the installation process for the previous version - 1.0.0-beta, see my first BIND 10 article):

Compilation was painless - no issues encountered. Next, remove the symlink to the previous version (presuming you don’t have BIND 10 running on either node), and recreate it pointing to the new version:

Configuring BIND 10

Another change in the release candidate has removed the default root/bind10 management user (this is the default set of credentials we used to log into bindctl previously):

Therefore, I created an administrative user with b10-cmdctl-usermgr as follows:

Next, I copied b10-config.db and zone.sqlite3 across from my previous 1.0.0-beta installation to my new 1.0.0-rc installation:

Testing the Upgrade

After starting BIND 10 on the both nodes, I am happy to report that things appear to be working as they should. Checking the logs, you’ll hopefully see something along the following lines:

So - our configuration has been successfully updated, and our SQLite database, whilst running schema version 2.1, is compatible with the current schema - 2.2.

Connecting via bindctl yielded the following message upon first connect:

The file was created after first successful login using the new account. It’s worth noting that this file (stored in ~/.bind10/user_default.csv) contains a username,password pair - with the password in CLEAR TEXT.

Next, I tested adding a record via nsupdate. Notifies were sent from the master, and the transfer logged …

… whilst on the slave, we see

With software as complex and immature as BIND 10, the upgrade process is thankfully rather painless.

Database Compatibility

As you can see, BIND 10 complains on start up that the database has an older version of the schema (although it will still work):

This is due to:

We should be able to fix this with b10-dbutil. First, shutdown both instances via bindctl - remembering that it’s no longer the Boss that we shutdown:

Once both instances are shutdown, run b10-dbutil to upgrade the SQlite3 database - AFTER BACKING UP YOUR DATABASE FIRST:

Start BIND 10 once again, and check that all is well. For me - it was

Conclusion

This article has briefly discussed three of the major changes introduced between BIND 10 1.0.0-beta and BIND 10 1.0.0-rc, and has also shown how to upgrade to the latest release from the beta.

Any questions or comments, please let me know.