[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 
test.)


B10_FROM_BUILD
  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:
		/src/bin/auth/auth.spec
		/src/bin/cmdctl/cmdctl.spec
		/src/bin/resolver/resolver.spec
		/src/bin/stats/stats.spec
		/src/bin/xfrin/xfrin.spec
		/src/bin/xfrout/xfrout.spec
		/src/bin/zonemgr/zonemgr.spec


B10_FROM_SOURCE
  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/
		/src/bin/cmdctl/cmdctl-accounts.csv
		/src/bin/cmdctl/"cmdctl-keyfile.pem
		/src/bin/cmdctl/cmdctl-certfile.pem
  for stats-httpd templates:
		/src/bin/stats/stats-httpd-xml.tpl
		/src/bin/stats/stats-httpd-xsd.tpl
		/src/bin/stats/stats-httpd-xsl.tpl
  to point to spec files:
		/src/bin/bind10/bob.spec
		/src/bin/stats/stats.spec
		/src/bin/stats/stats-schema.spec
** there is a bug if B10_FROM_SOURCE is set in environment
   breaks a different (unrelated?) unittest


B10_FROM_SOURCE_LOCALSTATEDIR
  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


BIND10_MSGQ_SOCKET_FILE
  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


BIND10_XFROUT_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
  

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


CMDCTL_SRC_PATH
  only used cmdctl unittests
  for a unittest to point to
	cmdctl-accounts.csv
	cmdctl-keyfile.pem
	cmdctl-certfile.pem


BIND10_TEST_SOCKET_FILE
  only used in msgq and cc unittests
  to point to a msgq socket file
  for unittests point to:
	$(builddir)/test_msgq_socket.sock
	@builddir@/test_socket.sock


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


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


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


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


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


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


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


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


TESTDATA_PATH
  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


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


B10_LOGGER_DBGLEVEL
	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?


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


B10_LOGGER_SEVERITY
	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