[bind10-dev] environment variables used by BIND 10

Jeremy C. Reed jreed at isc.org
Fri May 27 13:18:09 UTC 2011

The following notes and questions are about the environment variables 
used by BIND 10.

- Rename: some are called B10, BIND10, and some don't indicate BIND 10.

- Document these, whether for end-user, for developer, unit tests only, etc.
  (Some are documented in source code headers.)

- Make sure specific environment variables override generic regardless
  if generic is defined.

- Maybe make better abstract for these so not "source" nor "build" specific.

- Remove some environment variables -- we have too many, some do the
  same thing/duplicate functionality, and some maybe are not needed.

My goal is to simplify and document.  (I started looking at this again, 
since I saw that the new systest framework sets a environment variable 
which caused my custom environment variable to be ignored. Also we have 
one known regression when an environment variable is used in a wrong 

  in writable build tree (not installed / real locations)
  in real code, in a few run_*sh scripts, and also used by various tests
  to point to sqlite3 database (/bind10_zones.sqlite3)
  to point to xfrout socket file (/auth_xfrout_conn)
  to point to spec files:

  in read-only source tree
  a few run_*sh scripts set this
  used in real code and a various tests use this
  to point to cmdctl configurations in src/bin/cmdctl/
  for stats-httpd templates:
  to point to spec files:
** there is a bug if B10_FROM_SOURCE is set in environment
   breaks a different (unrelated?) unittest

  used in auth, xfrout, and /bind10_config.py
  for xfrout and auth, to point to xfrout socket file (/auth_xfrout_conn)
	if B10_FROM_BUILD is set
TODO: why not for msgq socket too?
  for bind10_config.py, to point to cfgmgr plugins (/src/bin/cfgmgr/plugin)
	and location of configuration file(s) **actually I don't see used**
	if B10_FROM_SOURCE is set
  used in systest startup script
  used in some unittests

  used in some run_*sh scripts
  used in python cc module
  used in real code and tests
  to point to msgq socket
  used by some unittests
  same name reused but not as an environment variable
	in ./src/lib/python/bind10_config.py.in
	like bind10_config.BIND10_MSGQ_SOCKET_FILE

  documented to specify socket for communication between
  	b10-auth and b10-xfrout
	BUT it is not used if B10_FROM_BUILD is defined
  to point to xfrout socket (/auth_xfrout_conn)
  used in auth and xfrout real code and unittests

  only used cmdctl unittests
  to point to /cmdctl.spec in a unittest

  only used cmdctl unittests
  for a unittest to point to

  only used in msgq and cc unittests
  to point to a msgq socket file
  for unittests point to:

  used in bind10_config.py python module
  only set by cfgmgr/plugins unittests
  colon delimited path containing cfgmgr related plugins

  to see specific reason for an unexpected exception
  used in the run_all unittests wrapper

  used in an bindctl unittest to check of $HOME/.bind10 is same as
  Note that this is commonly set by Unix login/sshd daemon.

  sets directory where the b10-loadzone tool is located within
  the build directory as used for the functional tests there

  used only for loadzone tests
  points to loadzone test data and a test data creation script
  in the source tree

  used only for loadzone tests
  points to the build tree for zone database creation and
  results output for the loadzone tests

  used only for config tests
  points to config test data in the source tree

  used only for config tests
  points to writable directory for creating b10-config.db file for unittests

  for cfgmrg unittests, points to plugins in source tree
  for pydnspp unittests, is colon delimited and points to plugins in
	source tree and build tree (but one is source tree only)
  for datasrc unittests, points to example sqlite3 zone databases in source tree

	? is this "b10root" just internal use or actually logged into
	target log file?
	? okay for admin to set this?

	also for logging severity
	? it is confusing and maybe wrong to use the same terminology
		"severity" for this and B10_LOGGER_SEVERITY
	? okay for admin to set this?

	set to filename that contains replacement messages
	? okay for admin to set this?

	log severity level
	? okay for admin to set this?

? I am confused if admin sets these generic LOGGER environment variables
for logging if they will cover all modules and not specific enough.

More information about the bind10-dev mailing list