defs-example

#
# This is an example definitions file for configure.
#
# This version has an entirely private address space; i.e., the servers
# and nodes cannot be accessed directly from the Internet.
# The control network looks like:
#
# Complete:            10.1.32/22
# "public" segment:      10.1.33/24
# "private" segment:     10.1.32/24
# "node control segment: 10.1.34/23 (aka: 10.1.34/24, 10.1.35/24)
#
# This configuration requires a router/firewall between the segments
# and providing access to the outside. The router interface addresses
# for each segment are 10.1.{32,33,34}.1.
#
# Use the --with-TBDEFS=filename to specify your own file.
# If you add a variable, be sure to go and update configure.in.
#
# ALL VARIABLES MUST BE DEFINED! DO NOT COMMENT OUT VARIABLES!
#

# The name of this installation
THISHOMEBASE=Example.Emulab.Net

#
# Various domain and host names
#
# NOTE: If a fully qualified hostname is used as an example, then
# be sure to use a fully qualified hostname! Do not use an IP. 
#

# Fully-qualified hostname of the our web server.
# This name should resolve to boss's IP address - though it can be a CNAME
WWWHOST=www.example.emulab.net

# Fully-qualified hostname of the boss node
BOSSNODE=boss.example.emulab.net

# Fully-qualified hostname of the ops (also called users) node
USERNODE=ops.example.emulab.net

# Fully-qualified hostname of the fileserver (will typically be the same
# as the ops node; ops.example.emulab.net)
FSNODE=fs.example.emulab.net

#
# Minimum Unix uid and gid values for Emulab users.
# Emulab will create the initial user with these values and all additional
# users will have values greater than these.  It would be unwise to make
# these less than 1000 to avoid conflicts with "standard" BSD and Linux
# users.  These can also be tweaked to avoid pre-existing accounts on the
# fileserver machine.
#
MIN_UNIX_UID=10000
MIN_UNIX_GID=6000

# 
# Addresses to which email will be sent - These are expected to go to mailing
# lists. You can either host the lists on your ops node, send them off to
# some external server. If you chose to run them from the ops node, the
# ops-install script sets up empty lists for you.
#

# Main address for the 'operations staff' - Copies of error messages, etc. will
# get sent to this address, and in some cases users are directed to this
# address if they have questions and/or problems.
TBOPSEMAIL=testbed-ops@example.emulab.net

# Notification of new projects requests get sent to this address for approval.
# Should have a few admin-types on it.
TBAPPROVALEMAIL=testbed-approval@example.emulab.net

# Logs, such as experiment creation/deletion go to this address. Probably no
# more than one person needs to be on this one.
TBLOGSEMAIL=testbed-logs@example.emulab.net

# Various auditing message about account maintenance go here. Again, probably
# only needs one member.
TBAUDITEMAIL=testbed-audit@example.emulab.net

# Some web reports get sent to this one.
TBWWWEMAIL=testbed-www@example.emulab.net

# Our node state management daemon sends mail to this address. Someone should
# be on this list, and reporting persistent error messages to Utah would be a
# good idea.
TBSTATEDEMAIL=testbed-stated@example.emulab.net

# We have a test suite to test the front end. This email is for the results
# of the testsuite, but is not used yet.
TBTESTSUITEEMAIL=testbed-testsuite@example.emulab.net

# We dynamically create two email addresses for notifications to users - one
# for all testbed users, and one for all users whose projects have active
# experiments. These addresses are included in the above lists, with the
# intent that they can be used to archive all mail sent to them.
TBUSERSARCHIVE=testbed-users-archive@example.emulab.net
TBACTIVEARCHIVE=testbed-active-users-archive@example.emulab.net

#
# Real paths (no symlinks) to the directories that get exported from ops
#
# FSDIR_SCRATCH is optional.  The intent is that it provides per-project
# space that is not "guaranteed" (for the Utah Emulab that means we do
# not back it up to tape).  If defined, you would either set no quotas,
# or higher quotas than for FSDIR_PROJ, on this filesystem.  If you are
# not providing guarantees and are not doing quotas, you might as well
# just put all your space in /proj and leave FSDIR_SCRATCH= blank.
#
FSDIR_GROUPS=/q/groups
FSDIR_PROJ=/q/proj
FSDIR_USERS=/users
FSDIR_SHARE=/share
FSDIR_SCRATCH=

#
# Filesystems on which quotas should be enforced.
# Note that if multiple of the FSDIR_* vars above are on the same filesystem
# (e.g., /q/proj and /q/groups) then you should only specify the base of the
# common filesystem on which they all reside here (e.g., /q).
# Set to the empty string to turn off quota checking.
#
FS_WITH_QUOTAS="/q /users"

#
# SSL Certificate stuff. Used to customize config files in ssl directory.
# Note that OrganizationalUnit is set in the cnf file.
# CommonName is typically set to BOSSNODE and emailAddress to TBOPSEMAIL
#
# The Country *must* be a two letter abbreviation.
# See: http://sustainablesources.com/resources/country-abbreviations/
#
SSLCERT_COUNTRY="US"
SSLCERT_STATE="Utah"
SSLCERT_LOCALITY="Salt Lake City"
SSLCERT_ORGNAME="Utah Network Testbed"

#
# Control network configuration stuff.
#
# Used primarily to generate initial named and dhcpd config files.
# See doc/setup-network.txt for definitions of the private, public and
# control segments.
#

#
# Boss and users node IP addresses on the control network.
# For boss this is an address on the private segment of the control net.
# For users this is an address on the public segment of the control net.
#
BOSSNODE_IP=10.1.32.70
USERNODE_IP=10.1.33.74
FSNODE_IP=$USERNODE_IP

#
# If your boss/ops nodes are multihomed (and typically, one of the
# networks is a public routable network, and the other is an internal
# unroutable network), then define the the external addresses here (and
# the internal addresses above).
#
EXTERNAL_BOSSNODE_IP=$BOSSNODE_IP
EXTERNAL_USERNODE_IP=$USERNODE_IP
EXTERNAL_FSNODE_IP=$EXTERNAL_USERNODE_IP

#
# Network definitions - see doc/setup-network.txt for a description of how
# we recommend laying out your network. The definitions below are for the
# "segmented" topology. If you using a "basic" (or "flat") topology, see
# the commented out defintions further down.
#

#
# The overall control network range - this subnet should cover the
# CONTROL, PRIVATE, and PUBLIC networks below.
#
# The name server on the boss node will only respond to queries from nodes
# in this range and will only provide info about nodes in this range.
#
TESTBED_NETWORK=10.1.32.0
TESTBED_NETMASK=255.255.252.0

#
# As above, if you have internal and external networks, define the
# external network here, and the internal network above.
#
# The name server on the boss node will respond to queries from any node
# not in the testbed (i.e., not in TESTBED_NET{WORK,MASK}) and provide info
# about only nodes in this range. Thus if you want to advertise all nodes
# in your testbed to networks "upstream", define these the same as for
# TESTBED_NET{WORK,MASK}. If however you only want to expose your boss (ops)
# node, define it the same as PRIVATE_NET{WORK,MASK} (PUBLIC_NET{WORK,MASK}).
# 
EXTERNAL_TESTBED_NETWORK=$TESTBED_NETWORK
EXTERNAL_TESTBED_NETMASK=$TESTBED_NETMASK

#
# The node control network segment.
# The DHCP server on boss provides information about nodes in this range.
#
CONTROL_ROUTER_IP=10.1.34.1
CONTROL_NETWORK=10.1.34.0
CONTROL_NETMASK=255.255.254.0

#
# The private network segment.
# Where boss lives.
#
PRIVATE_NETWORK=10.1.32.0
PRIVATE_ROUTER=10.1.32.1
PRIVATE_NETMASK=255.255.255.0

#
# The public network segment.
# Where ops (users) and fs live.
#
PUBLIC_NETWORK=10.1.33.0
PUBLIC_ROUTER=10.1.33.1
PUBLIC_NETMASK=255.255.255.0

#
# A range of addresses within the node control network segment
# to use for new nodes being added to the testbed.
# You need at least one.
#
DHCPD_DYNRANGE="10.1.34.200 10.1.34.219"

#
# This commented out set of network defintions is for a basic (everything
# on one flat subnet) topology. Note that you can still multihome boss
# and ops, as described above. 
#
#BOSSNODE_IP=10.1.32.2
#USERNODE_IP=10.1.32.3
#FSNODE_IP=$USERNODE_IP
#EXTERNAL_BOSSNODE_IP=$BOSSNODE_IP
#EXTERNAL_USERNODE_IP=$USERNODE_IP
#EXTERNAL_FSNODE_IP=$EXTERNAL_USERNODE_IP
#TESTBED_NETWORK=10.1.32.0
#TESTBED_NETMASK=255.255.255.0
#CONTROL_ROUTER_IP=10.1.32.1
#CONTROL_NETWORK=10.1.32.0
#CONTROL_NETMASK=255.255.255.0
#PRIVATE_NETWORK=10.1.32.0
#PRIVATE_ROUTER=10.1.32.1
#PRIVATE_NETMASK=255.255.255.0
#PUBLIC_NETWORK=10.1.32.0
#PUBLIC_ROUTER=10.1.32.1
#PUBLIC_NETMASK=255.255.255.0
#DHCPD_DYNRANGE="10.1.32.200 10.1.32.219"

#
# Fill in the nameservers for your campus network here - the nameserver on boss
# will forward requests for domains other than your own to these nameservers
# OR
# Leave this variable empty to have boss ignore any local nameservers and go
# straight to the roots itself. This is NOT recommended, as you won't get the
# benefit of local caches, and may be blocked on some campuses.
#
NAMED_FORWARDERS="1.1.1.1 1.1.2.1"

#
# NTP server configuration:
#
# NTPSERVER: boss|ops|fs|<external-server-name-or-IP>
#   Default: "ops"
#   Normally, one of boss, ops, or fs is designated as a local NTP server
#   but this can be set to a fully qualified name of some other machine.
#   If NTPSERVER is set to an external server, then boss/ops/fs are made
#   clients of that server just as any testbed node is.
#
# EXTERNAL_NTPSERVER[1-4]: <external-server-name-or-IP>
#   Default: "[0-3].pool.ntp.org"
#   If NTPSERVER is one of boss/ops/fs, then these values are used as the
#   upstream servers for the local server. These can be changed to four of
#   your favorite NTP servers.
#
# NTPDRIFTFILE: <path>
#   Default: "/var/db/ntp.drift"
#   If NTPSERVER is one of boss/ops/fs, then this is the name of the drift
#   file for the local server.
#

#NTPSERVER="ops"
#EXTERNAL_NTPSERVER1="0.pool.ntp.org"
#EXTERNAL_NTPSERVER2="1.pool.ntp.org"
#EXTERNAL_NTPSERVER3="2.pool.ntp.org"
#EXTERNAL_NTPSERVER4="3.pool.ntp.org"
#NTPDRIFTFILE="/var/db/ntp.drift"

#
# Windows support. Turn this on if you think you might want to use WindowsXP
# or Windows7 images on your experimental nodes. Note though, that Utah cannot
# provide those images to you (because of obvious licensing issues), so it
# will be up to you to generate an image yourself and install the Emulab
# client side that enables Windows to work inside your testbed. Turning on
# Windows support will install and enable Samba on your ops node, so there 
# are firewall issues to be aware of (you want to block the appropriate ports
# so that your ops samba server can be accessed from *only* your control
# subnet!).
#
WINSUPPORT=0

#
# Additional Windows7-related variables. See:
#     http://users.emulab.net/trac/emulab/wiki/WindowsImageCreation
# for details.
#
WINDOWS_ORGNAME="Some Organization"
WINDOWS_OWNER="Some Owner"
WINDOWS_TIMEZONE="Mountain Standard Time"
WINDOWS_KEY_7PRO_X86=""

#
# Enable an NS verification path using a clean version of NS.
# There is no reason to disable this unless NS won't build on your ops node.
#
NSVERIFY=1

#
# Turn this on to disable exporting NFS filesystems to nodes.
# User home directories on all nodes will be local and unsynchronized in
# this case.  There will also be no access to a central /proj, /group or
# /share either.
#
NOSHAREDFS=0

#
# Set to one if you are using an NFS server that has an "exports race".
# FreeBSDs before 10.x have this condition. There is currently one workaround
# and one fix for this, both apply to the new NFS implementation and only
# in 9.x and 10.x as far as I know:
#
#  * The -S (suspend) option to mountd, integrated into 10.x (and 9.x
#    as of 11/2012), is a workaround that allows suspension of the NFS
#    server while the exports are changed.
#
#  * The new nfse (http://nfse.sourceforge.net/) atomic exports framework
#    for FreeBSD 10.
#
# Since we currently only support FreeBSD 8.x fileservers, we default this
# to one. Set it to zero if you are using one of the above.
#
NFSRACY=1

#
# Set to one if using the new DBI Perl interface to mysql. This should be
# set to one on all new installations involving FreeBSD 8.x and above.
# The packages associated with the emulab-boss-4.0 and beyond meta port
# install the necessary package for DBI support.
#
# Only set this to zero for old installations (emulab-boss-3.1 and before).
#
TBUSEDBI=1

#
# If set to one, this will serve tarballs, RPMs and blobs to be served
# from the web server on ops (aka, "fs" or "users") rather than from boss.
# This is more efficient since the tarballs/RPMs/blobs are stored on ops.
# This can be set to one for all emulab-stable and emulab-devel releases
# after 12/24/12.
#
SPEWFROMOPS=1

#
# Set the type of the console on nodes. This is used when customizing
# the MFSes at Emulab setup time and for customizing the image loaded
# on a node at experiment setup time.
#
# "sio"	 use the "com1" serial port
# "sio2" use the "com2" serial port
# "vga"  use the VGA device
# "null" don't use a console
#
NODECONSOLE="sio"

#
# Set the version of the MFSes used. Determines the version of FreeBSD
# used for the binaries and kernel.
#
# Note that you may need multiple versions of an MFS if you have really old
# and really new hardware. Such configurations will have to be setup manually.
#
# "72"    Really old FreeBSD 7.2, 32-bit; do not use unless you have old nodes
# "82"    Semi-old FreeBSD 8.2, 32-bit; use if you have 32-bit nodes
# "8-64"  Semi-old FreeBSD 8.2, 64-bit; use if you have ALL 64-bit nodes
#
MFSVERSION="82"

#
# Set this if you are running:
#	- Perl 5.8
#	- Perl 5.10 with SelfLoader version 1.18 or greater
#	- Perl 5.12 or beyond
# As of Jan 2011, this should include all Emulab installs (we apply a patch
# to Perl 5.10 and 5.12 to update the SelfLoader (patches/SelfLoader.patch).
# This enables serious runtime performance improvements.
#
SELFLOADER_DATA="__DATA__"

#
# Virtual node network configuration (if you don't want virtual nodes,
# just leave this as is).
#
# Needs at least a /16 network.  For a /16 the layout of an IP is:
#	X.Y.<pnode>.<vnode>
# where <pnode> is the physical host node and <vnode> is the virtual
# node on that host.  Both are between 1 and 254.  If you have more than
# 254 physical nodes then the assignment code will increment Y, meaning
# that you had better have larger than a /16 network.  If you are using
# the default 172.16/12, then you can have up to 16 * 254 physical hosts.
# If you want more than 254 vnodes per pnode, you are screwed.
#
# ********* DO NOT CHANGE THESE UNLESS YOU ASK UTAH FIRST! *********
#
VIRTNODE_NETWORK=172.16.0.0
VIRTNODE_NETMASK=255.240.0.0
# XXX compat
JAILIPBASE=$VIRTNODE_NETWORK
JAILIPMASK=$VIRTNODE_NETMASK

#
# Dynamic public addresses for virtual nodes.  Leave as "none" if you don't
# have public IP addresses to spare, otherwise define to an otherwise
# unused block of addresses that will be given out to virtual nodes asking
# for routable control net interfaces (instead of the VIRTNODE_NETWORK
# block they'd otherwise get).
#
VPUBADDR_BASE=none
VPUBADDR_BITLEN=none

#
# Selective disable of a couple of features.
#
# DISABLE_NAMED_SETUP	If you are not running a name server on your boss.
#			This will prevent you from using the virtual node
#			names (e.g., node1.eid.pid.<your-domain>).
#
# DISABLE_EXPORTS_SETUP	Prevent dynamic configuration of the exports file
#			on your "fs" node.  You will need to use this if
#			your fs node is not running FreeBSD or is otherwise
#			not under your control.  If you set this option, you
#			will need to ensure that ALL your Emulab filesystems
#			(e.g., /proj, /users) are exported to ALL your nodes.
#			This has obvious security implications and YOU REALLY
#			SHOULD NOT DO THIS. 
#
DISABLE_NAMED_SETUP=0
DISABLE_EXPORTS_SETUP=0

#
# Frisbee address/port parameters (and yes meant to spell it that way).
#
# FRISEBEEMCASTADDR	Starting multicast address to use. Each frisbeed
# 			download server instance gets a unique address.
#
# Traditionally, we have used a subset of 234/8 which is officially
# "unassigned" according to IANA. You would probably be better off using the
# 239/8 range which is officially "administratively scoped" (i.e., for local
# use). At any rate, you should not allow this traffic beyond your router.
#
# Note that MC addresses ARE NOT REUSED. They will increment from the start
# value up to the next /8 boundary, at which point frisbee WILL STOP WORKING.
# So if you start at "234.5.6" they will increment til it reaches 235.0.0.0.
# The fact that we define the address to be three octets is historical (as
# is our not reusing MC addresses).
#
# FRISEBEEMCASTPORT	When non-zero, starting port for download (UDP) and
# 			upload (TCP) servers. Each instance of a server gets
#			a unique port number. When zero, the server is free
#			to choose any ephemeral port and NUMPORTS is ignored.
#
# FRISEBEENUMPORTS	When non-zero, limits the range of ports used for
# 			download/upload to MCASTPORT to MCASTPORT+NUMPORTS-1.
#			When zero, any port at or above MCASTPORT can be used.
#
# A value of 0 for MCASTPORT is the most efficient setting as it allows the
# kernel to choose an available port. Otherwise, the server must try binding
# to each port in the indicated range until it succeeds.
#
FRISEBEEMCASTADDR="234.5.6"
FRISEBEEMCASTPORT=0
FRISEBEENUMPORTS=0

#
# Some switches do not support the stack MIB. This means snmpit cannot
# set the port/duplex during swapin, so you are stuck at a particular
# bandwidth, and have to change them from the console. Set to 1 if
# your switch has no stack MIB.
#
NOSTACKMIB=0

#
# Deprecated and should always be zero.
#
ARCHIVESUPPORT=0
SFSSUPPORT=0
PELABSUPPORT=0
PLABSUPPORT=0
PLAB_ROOTBALL="plabroot-18.tar.bz2"
WIKISUPPORT=0
BUGDBSUPPORT=0
MAILMANSUPPORT=0
CVSSUPPORT=0
CHATSUPPORT=0
NFSTRACESUPPORT=0
OPSDBSUPPORT=0

#
# You shouldn't have to change anything below this point
#

TBADMINGROUP=tbadmin
TBDBNAME=tbdb
IPBASE=10
DELAYCAPACITY=2
DISABLE_NSE=1

# Sometimes the main page is down in a directory on WWWHOST
# No trailing '/'!
#WWW=www.example.emulab.net/emulab-www

# Image directories
IMAGEDIRECTORIES=1

# Fancy new browser in the console support
BROWSER_CONSOLE_ENABLE=1