From 3e44bb5f3c0f413e67e861341ae72f05e5cb5ee4 Mon Sep 17 00:00:00 2001 From: Mike Hibler Date: Fri, 21 Dec 2012 11:49:49 -0700 Subject: [PATCH] Bug Fix: Update defs-example with latest variables. Clarify some comments. This may also fix some problems that people have had with their name server when starting with this config--some of the IP addrs/masks were not right. Also, remove defs-example-privatecnet since defs-example has been pretty much the same thing for many years. --- defs-example | 119 +++++++++++--- defs-example-privatecnet | 328 --------------------------------------- 2 files changed, 98 insertions(+), 349 deletions(-) delete mode 100644 defs-example-privatecnet diff --git a/defs-example b/defs-example index 37788e8a0..eece364c4 100644 --- a/defs-example +++ b/defs-example @@ -1,6 +1,22 @@ # # 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! # @@ -122,6 +138,7 @@ 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. @@ -155,25 +172,37 @@ EXTERNAL_FSNODE_IP=$EXTERNAL_USERNODE_IP # 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.255.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.36.1 -CONTROL_NETWORK=10.1.36.0 -CONTROL_NETMASK=255.255.255.0 +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 @@ -181,6 +210,7 @@ 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 @@ -191,7 +221,7 @@ PUBLIC_NETMASK=255.255.255.0 # to use for new nodes being added to the testbed. # You need at least one. # -DHCPD_DYNRANGE="10.1.36.200 10.1.36.219" +DHCPD_DYNRANGE="10.1.34.200 10.1.34.219" # # Fill in the nameservers for your campus network here - the nameserver on boss @@ -204,11 +234,11 @@ DHCPD_DYNRANGE="10.1.36.200 10.1.36.219" NAMED_FORWARDERS="1.1.1.1 1.1.2.1" # -# Windows support. Turn this on if you think you might want to use windows -# XP images on your experimental nodes. Note though, that Utah cannot +# 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 XP image yourself and install the -# Emulab client side that enables XP to work inside your testbed. Turning +# 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 @@ -216,6 +246,16 @@ NAMED_FORWARDERS="1.1.1.1 1.1.2.1" # 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. @@ -232,12 +272,41 @@ NOSHAREDFS=0 # # Set to one if you are using an NFS server that has an "exports race". -# FreeBSDs before 8.x have this condition. FreeBSD 8 and above (and -# probably newer Linuxes) do not. Since we currently only support FreeBSD -# 7.x and below fileservers, leave this at one. +# 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 @@ -254,9 +323,9 @@ NODECONSOLE="sio" # Set this if you are running: # - Perl 5.8 # - Perl 5.10 with SelfLoader version 1.18 or greater -# - Pefl 5.12 or beyond +# - Perl 5.12 or beyond # As of Jan 2011, this should include all Emulab installs (we apply a patch -# to Perl 5.10.1 to update the SelfLoader, see patches/SelfLoader.patch). +# to Perl 5.10 and 5.12 to update the SelfLoader (patches/SelfLoader.patch). # This enables serious runtime performance improvements. # SELFLOADER_DATA="__DATA__" @@ -282,11 +351,13 @@ VIRTNODE_NETMASK=255.240.0.0 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 @@ -324,6 +395,14 @@ FRISEBEEMCASTADDR="234.5.6" FRISEBEEMCASTPORT=3564 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 + # # Only supported on the Mother Ship (emulab.net) right now. # @@ -333,8 +412,12 @@ MAILMANSUPPORT=0 CVSSUPPORT=0 CHATSUPPORT=0 NFSTRACESUPPORT=0 -ARCHIVESUPPORT=0 OPSDBSUPPORT=0 + +# +# Deprecated and should always be zero. +# +ARCHIVESUPPORT=0 SFSSUPPORT=0 PELABSUPPORT=0 PLABSUPPORT=0 @@ -353,9 +436,3 @@ DISABLE_NSE=1 # Sometimes the main page is down in a directory on WWWHOST # No trailing '/'! #WWW=www.example.emulab.net/emulab-www - -# Some switches do not support the stack MIB. This means snmpit cannot -# set the port/duplex during swapin, so youare 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 diff --git a/defs-example-privatecnet b/defs-example-privatecnet deleted file mode 100644 index 3b94d38a4..000000000 --- a/defs-example-privatecnet +++ /dev/null @@ -1,328 +0,0 @@ -# -# This is an example definitions file for configure. -# -# This version has a non-routable control network; i.e., nodes must be -# accessed via the multi-homed, publically routable "users" node. -# The control network looks like: -# -# Complete: 192.168.0/22 -# "public" segment: 192.168.3/24 -# "private" segment: 192.168.2/24 -# "node control segment: 192.168.0/23 (aka: 192.168.0/24, 192.168.1/24) -# -# This configuration requires a router/firewall between the segments -# (addreses 192.168.{0,2,3}.1). -# -# Use the --with-TBDEFS=filename to specify your own file. -# If you add a variable, be sure to go and update configure.in. -# - -# The name of this installation -THISHOMEBASE=Example.Emulab.Net - -# -# Various domain and host names -# - -# Host name of our web server (or host:port) -WWWHOST=www.example.emulab.net - -# Fully-quailified hostname of the boss node -BOSSNODE=boss.example.emulab.net - -# Fully-quailified hostname of the ops (also called users) node -USERNODE=ops.example.emulab.net - -# Fully-quailified hostname of the fileserver (will probably be the same -# as the ops node) -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 -# -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=192.168.2.70 -USERNODE_IP=192.168.3.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=155.98.32.70 -EXTERNAL_USERNODE_IP=155.98.33.74 -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 overall control network range - this subnet should cover the -# CONTROL, PRIVATE, and PUBLIC networks below. -# -TESTBED_NETWORK=192.168.0.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. -# -EXTERNAL_TESTBED_NETWORK=155.98.32.0 -EXTERNAL_TESTBED_NETMASK=255.255.240.0 - -# -# The node control network segment. -# -CONTROL_ROUTER_IP=192.168.0.1 -CONTROL_NETWORK=192.168.0.0 -CONTROL_NETMASK=255.255.254.0 - -# -# The private network segment. -# -PRIVATE_NETWORK=192.168.2.0 -PRIVATE_ROUTER=192.168.2.1 -PRIVATE_NETMASK=255.255.255.0 - -# -# The public network segment. -# -PUBLIC_NETWORK=192.168.3.0 -PUBLIC_ROUTER=192.168.3.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="192.168.1.240 192.168.1.250" - -# -# If you have forwarders for your named, specify them here for named.conf -# generation in the named directory. -# -NAMED_FORWARDERS="1.1.1.1 1.1.2.1" - -# -# Windows support. Turn this on if you think you might want to use windows -# XP 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 XP image yourself and install the -# Emulab client side that enables XP to work inside your testbed. Turning -# 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 - -# -# 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 8.x have this condition. FreeBSD 8 and above (and -# probably newer Linuxes) do not. Since we currently only support FreeBSD -# 7.x and below fileservers, leave this at one. -# -NFSRACY=1 - -# -# Set this if you are running: -# - Perl 5.8 -# - Perl 5.10 with SelfLoader version 1.18 or greater -# - Pefl 5.12 or beyond -# As of Jan 2011, this should include all Emulab installs (we apply a patch -# to Perl 5.10.1 to update the SelfLoader, see 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.. -# where is the physical host node and 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. -# -VIRTNODE_NETWORK=172.16.0.0 -VIRTNODE_NETMASK=255.240.0.0 -# XXX compat -JAILIPBASE=$VIRTNODE_NETWORK -JAILIPMASK=$VIRTNODE_NETMASK - -# -# 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.). -# -# 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 - -# -# Only supported on the Mother Ship (emulab.net) right now. -# -WIKISUPPORT=0 -BUGDBSUPPORT=0 -MAILMANSUPPORT=0 -CVSSUPPORT=0 -CHATSUPPORT=0 -NFSTRACESUPPORT=0 -ARCHIVESUPPORT=0 -OPSDBSUPPORT=0 -SFSSUPPORT=0 -PELABSUPPORT=0 -PLABSUPPORT=0 -PLAB_ROOTBALL="plabroot-18.tar.bz2" - -# -# You shouldn't have to change anything below this point -# - -TBADMINGROUP=tbadmin -TBDBNAME=tbdb -IPBASE=10 -DELAYCAPACITY=2 -DISABLE_NSE=1 -FRISEBEEMCASTADDR="234.5.6" -FRISEBEEMCASTPORT=3564 - -# Sometimes the main page is down in a directory on WWWHOST -# No trailing '/'! -#WWW=www.example.emulab.net/emulab-www - -# Some switches do not support the stack MIB. This means snmpit cannot -# set the port/duplex during swapin, so youare 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 -- GitLab