-
Notifications
You must be signed in to change notification settings - Fork 2
This section serves to expand upon settings in lib/CMU/Netdb/Config.pm, lib/CMU/WebInt/Config.pm, and lib/CMU/NetMon/Config.pm. You probably want to see the first few sections of "NetReg Design" and "NetMon Design" to understand how these configurations work together.
The following configuration parameters are defined in lib/CMU/Netdb/config.pm.
ADMIN_ADDRESS Netreg is setup to mail the administrators about problems it encounters - generally these are things that you probably want to pay attention to. If you really don't want to receive email, set the MAILER to ''. But REALLY, you WANT to receive this mail.
ADMIN_ADDRESS is the address to which this mail will be sent.
ADMIN_NAME ADMIN_NAME is just the pretty name that will be used as the recipient name on the outgoing administrative mail.
DHCP_SERVICE This should be set to the name of your DHCP Server Pool service in NetReg. The DHCP generation script will look for this service when creating DHCP configurations. Default is dhcp.
MAILER MAILER needs to specify a mail program (like sendmail) that can accept a mail message on its STDIN, and takes as an argument the address to send the message. Default is /usr/lib/sendmail.
NRHOME Specifies the home directory for all of the NetReg modules, password cache, output area, administrative binary area, etc. The default is /home/netreg.
SENDER_ADDRESS SENDER_ADDRESS specifies the email address indicated as the sender of administrative mail. It's not strictly necessary, but helpful if you set it to something useful. That way you can reply easily to the administrative mail (if you want to comment on an error, for example.)
SENDER_NAME Outgoing administrative mail will indicate the sender's pretty name as SENDER_NAME.
SERVICE_FILE Specify the location that you want the default services file to be written. The default is $NRHOME/etc/service-gen/services.sif. We request (recommend?) you at least specify a filename with a .sif extension, as we'd like to standardize on Service-Information-Files having that extension.
DHCP_GENPATH Specify the location of your DHCP configuration file generation. The default is $NRHOME/etc/dhcp-gen, which should be all setup for you.
DHCP_XFERPATH Specify the location from which your DHCP configuration files are transferred to the DHCP servers (after being copied from DHCP_GENPATH.) The default is $NRHOME/etc/dhcp-xfer.
DHCP_SERVICE Specify the name of your DHCP service pool, as configured in the Services area of NetReg. We use dhcp.net.cmu.edu, for example, but you probably want to change this to something more location-oriented.
DHCP_RR_DNS_SERV The DHCP_RR_DNS_SERV array is a convenient way for you to specify a number of nameservers that you want to hand out to clients. You can configure the nameservers on a per-subnet (or per-machine) basis via NetReg, and in fact dhcp.pl will be smart enough to recognize when you do (on a per-subnet basis) and ignore this array. However, for subnets that do not contain name servers, they will be filled in from entries on this list.
The actual method of filling in the nameservers is to do so in a round-robin fashion (based off the NetReg subnet ID). Since most clients accept multiple nameservers, but most clients hit the first nameserver a good percentage of the time (and in fact take several seconds to timeout to additional nameservers), this method gives you decent loading across all your nameservers. However, if you know that certain clients will be better served by a particular nameserver, we recommend you specify the nameserver option explicitly on the subnet.
The default is: qw/128.2.4.21, 128.2.32.37, 128.2.64.2/, our nameservers. We highly recommend you change this to be a group of your own nameservers. If we decide to up and move ours, your clients could break (aside from which, your queries will take much longer to resolve than if you use your own, or even your ISPs, servers).
DHCP_NSKEY This specifies a path to the file that will contain additional zone and key information from your DNS configuration generation that will be used in the DHCP configuration. DHCP can only update DNS if it has the proper keys configured for the various zones (or the nameservers explicitly allow the DHCP servers' IP, but we prefer the key approach.) The default of: $NRHOME/etc/zone-config/dhcpd.conf.nsaux should be okay for most purposes.
DNS_GENPATH This specifies the path in which your DNS zonefiles are written. The default is: $NRHOME/etc/zone-gen.
DNS_XFERPATH This specifies the path from which your DNS zonefiles and configurations are copied to the DNS servers. The default is: $NRHOME/etc/zone-xfer.
DNS_CONFPATH This specifies the path in which your DNS configurations are written. The default is: $NRHOME/etc/zone-config.
DNS_TOP The DNS_* configuration bits are specified so that your DNS configurations are correctly generated. This needs to be the top directory of where you store your DNS related files on your nameserver. For example, we have historically used /usr/domain as the homedirectory. Under that, we have a db directory for storing zone files, a var directory for logs, an etc directory for the actual configuration, and bin and sbin for the server itself plus assorted utilities.
Specify the top directory here, and specify the remaining DNS_* variables as they fit into your environment.
DNS_DBDIR In our environment, /usr/domain/db is where we store zonefiles. If your zonefiles will be in a different location, adjust this variable accordingly.
DNS_SBIN The DNS_SBIN directory should be the location of the named binary as well as assorted support utilities (ndc, named-xfer, dns).
DNS_VAR The DNS_VAR directory is the location that we'll setup for your named process ID (named.pid) file.
DNS_ETC The DNS_ETC directory should contain the named.hints file, and this is the location that we use to put the named.conf.
RSYNC_PATH We use rsync to copy our DNS zone/config files and our DHCP config files to the proper servers. This utility is pretty flexible in allowing you to use different transport mechanisms while retaining the easy of copying many files. RSYNC_PATH should specify the complete path to your rsync utility. We use /usr/ng/bin/rsync, which probably isn't the proper location for you.
RSYNC_OPTIONS Specify any options that you want to pass to rsync in the RSYNC_OPTIONS variable. The default of: -a -v -v -v --rsync-path=$RSYNC_PATH is probably sufficient, unless you have a special configuration.
RSYNC_REM_USER Specify the remote user that you will use to rsync files with. We use the ftp user on our DNS and DHCP servers, because it's an easy user that already had a local home directory configured.
RSYNC_RSH The RSYNC_RSH variable controls what the environment variable RSYNC_RSH will be set to while performing rsync operations. This is how we invoke SSH, for example, as the underlying transport mechanism for syncing files. To use SSH we specify: /usr/local/lib/ssh/bin/ssh -x -i $NRHOME/etc/.identity-xfer.
We use an RSA keypair to authenticate the connection. The $NRHOME/etc/.identity-xfer files needs to be owned by the netreg:netreg, and we set the permissions to 400.
ADMIN_GROUP This is the plaintext description of the group responsible for your installation of NetReg -- it will be printed on the bottom of every NetReg page. We use "Carnegie Mellon Network Development", for example.
BGCOLOR The background color attribute is simply that: the background color of all NetReg pages. We use 'white'.
DEF_ITEMS_PER_PAGE On most screens NetReg will try to paginate the displays - ie show you only a subset of the entire dataset (limited to X rows). You can control the parameters of that paging. The DEF_ITEMS_PER_PAGE variables specifies the default number of items that will be presented on a single page. The default "default" is 40.
DEF_MAX_PAGES Another aspect of the NetReg paging is to specify the maximum number of links to pages that will be displayed. The links are always centered around the current page. Don't make this too high or the pagination will take too much horizontal space. Our default is '15'.
ENABLE_CABLES_OUTLETS If you want to use the cable/outlet interface, set this to '1'. '0' is recommended unless you are interested in development of this section and have read the "Outlets" section of the manual.
HDCOLOR The Heading color is that which is used for major subheadings, delineating major sections of a page. The default of '#c6d4ff' is a light blue. The color can (or should) be somewhat darker than your TACOLOR/THCOLOR, but it still needs to allow black text on top to be readable.
LocalRealm At Carnegie Mellon, we use a Kerberos-based authentication system, so the actual IDs passed from Apache (in the REMOTE_USER environment variable) are: userid@ANDREW.CMU.EDU. In this case, setting LocalRealm to 'ANDREW.CMU.EDU' causes the effective UserID to be stripped of the at-sign and the realm. However, a user connecting as, for example, ju33@CS.CMU.EDU, would be treated as the full string, including non-local realm. Set this to '' if the userIDs from Apache will lack any realm.
MACHINES_PER_PAGE On the main NetReg page, both machines and outlets are displayed (if ENABLE_CABLES_OUTLETS is activated), causing the default number of pagination entries to be too many. We recommend setting the MACHINES_PER_PAGE value to half the DEF_ITEMS_PER_PAGE (so we set it to '20').
NetReg_Web_DB The NetReg_Web_DB variables defines parameters for establishing the database connection. It should be a reference to an array of 3 elements. The first should be the driver, the second the username to connect to the database as, and the third the password to use. The username is strictly a username defined in the database server (it has no relationship with NetReg users).
The driver parameter needs to specify the hostname as well. We use: DBI:mysql:netdb:localhost. This instructs DBI to use the 'mysql' connection method to connect to the 'netdb' database on server 'localhost'. If you are installing the database and web server on the same machine (our setup), then this should not need to be changed.
We use the 'netreg-web' user for the web accesses to the NetReg database. If you use the netreg-install script, it should give you instructions for configuring this user to have access to the mysql database.
The password can either be specified in plaintext. Alternatively it can provide a reference to a file that contains the password. The format for this reference is: file=/path/to/password/file. The contents of this file MUST be the password only. If there is a trailing newline, it will be sent along to the database with the newline. To prevent your standard editor from adding a newline, we update the passwords as: perl -e 'print "PASSWORD"' > /path/to/password/file
Putting it all together, the value we set NetReg_Web_DB to is: ['DBI:mysql:netdb:localhost', 'netreg-web', 'file=/home/netreg/etc/.password']
SuperUsers [Array] The SuperUsers array should contain a list of all SuperUsers of the system. This is currently only helpful for one case (which we haven't ever used). By setting the DB_OFFLINE key in the _sys_info table you will lock out all users except SuperUsers. SuperUsers database access is still drawn out of the standard permissions, though. Default: blank.
SYSTEM_MAIN_URL This should contain the full URL to the main page of your NetReg installation. It will be presented to users in this manner. Default: 'http://FILL-ME-IN.EXAMPLE.ORG'
SYSTEM_NAME Whatever you decide to call your system, fill it in here. Default: 'Network Registration System'.
TACOLOR Most of NetReg's output is done via tables containing many rows of information. We use an "alternate" color (other than "white") every other row, to make it easier to read entire rows. The default of '#c0f7de' is an aqua color. We recommend a fairly light color.
THCOLOR The Table Heading color is used for the headings to input fields. The default of 'lightyellow' is, well, a light yellow. :) A light color is recommended.
USER_MAIL Set the USER_MAIL variable to the email address that should be given to users for contacting you. This email will be a link on the bottom of every NetReg page, so it should be your standard helpdesk/support staff, but it's probably a bad idea to set this to the same value as your ADMIN_MAIL address.
We have tried to minimize the amount of configuration required for the support utilities. You should definitely read about them below (NetReg Design) to determine which ones will need additional assistance. However you should also definitely configure vars.sh and vars_l.pm appropriately.
NRHOME The perpetual configuration required is to make sure everything knows about your NetReg home directory. Make sure both vars and vars_l know about NRHOME.
NRLIB vars_l.pm will assume NRLIB to be $NRHOME/lib, which is a good assumption if you used netreg-install. Otherwise, change this.
NRUSER Just leave NRUSER set to netreg.
MYSQL_PATH This is used to quickly change the MYSQL and MYSQLDUMP variables below; set this to be the path to your mysql/mysqldump binaries.
MYSQL Specify the full path to your mysql binary.
MYSQLDUMP Specify the full path to your mysqldump utility. This is used by dump-db.sh.
It's probably a good idea to read the section on NetMon design prior to configuring it, because there are several concepts there that you should understand prior to configuration.
Configuration is done in the CMU/NetMon/Config.pm file. Like Netdb/WebInt, there are a number of variables.
NetMon automatically begins capturing ARP and CAM information from devices that match certain parameters in NetReg. Thus, if a new switch is added to NetReg, NetMon will begin recording CAM table information within a day or so.
GW_PATTERN GW_PATTERN is specified as an array of patterns to match in looking for new routers ("gateway device"). Basically, it will look at the NetReg host_name field using the SQL LIKE operator with wildcards around each pattern. You should make sure to include preceding dot separators to match a domain completely. For example, our array of patterns is: (.gw.cmu .gw.net.cmu) so a host_name of foo.gw.cmu.net would match, while foogw.cmu.net would NOT (due to the dot in the pattern.)
If a new GW is located in NetReg, it is added to the device table in NetMon. Additionally, device_timing entries are added for types ARP, Ping, and DevMAC.
SW_PATTERN SW_PATTERN is similar to GW_PATTERN except that it looks for switches (or other non-gateway devices) and adds them to NetReg. It uses the same pattern matching syntax as GW_PATTERN. When added, new devices have device_timing entries for CAM, Ping, and DevMAC.
IGNORE_LOAD It pays to standardize on your naming conventions when using NetMon, because you can easily exclude certain patterns of devices (for example, aliases for the same box). You can specify an array of patterns to exclude. Unlike GW_PATTERN, you MUST include wildcard ("%") expressions where necessary. For example, we might have foo.gw.cmu.net and foo-vlan34.gw.cmu.net. By having %-vlan% in our IGNORE_LOAD list, we do not create a separate entry for foo-vlan34 in NetMon.
Note that GW_PATTERN, SW_PATTERN, and IGNORE_LOAD are used ONLY while adding new devices from NetReg -- even name changes will not be verified by these rules. (See the NetMon Design, "Device and Device Timings") section for more information.
PERM_DEACTIVATE PERM_DEACTIVATE applies to all existing NetMon devices. It is similar to IGNORE_LOAD in syntax, ie an array of patterns (wildcards required). Any devices matching these patterns will always have all device_timings for the device set to "Deactivated" state (ie, no capturing will occur). We use this to mark off devices that are unreachable from the main network.
NetMon has a general Capture engine (see the NetMon Design section for more detail). The engine is more or less continuously running (it dies if there is nothing to do, but cron re-starts it every minute, or 5 minutes, or whatever you decide.)
During each iteration, it looks to see how much work needs to be done (ie, how many devices haven't been captured in their configured captured interval, and thus need to be touched). It also identifies how many processes are already running, trying to touch the devices. It will double the number of collection agents of a given type if any devices have not been touched in 1.3 times their collection interval -- we call this "falling behind". The parameters here control some aspects of this collecting. After it has taken care of this work, it sleeps for some period of time before re-checking the state of the world.
Each individual capture agent (children of the master capture process) will loop until there is no more work (of its designated capture type) doing the following:
If there is work to do, get some chunk of the work (and mark the last_begin time to now() to indicate such to other agents. For each device in the chunk, try capturing from it.
TIMEOUT If we start capturing from a device, but for some reason don't finish, then last_begin will be some time AFTER last_end. Once the difference between last_begin and now() exceeds $TIMEOUT*(capture interval for this device and type), then we'll declare that the previous capture attempt failed, and we'll try again. We set this value to '5', and it's basically here to make sure that two agents don't collide. Normally this would never happen, but devices that are down or otherwise unreachable take some time to timeout.
FORKNUM If the master capture process determines a capture type has available work, it will spawn this many processes to start working. We set the value to '3'. The goal is that this many processes can always keep up with the work required (and thus, we never need to start doubling the active agents.) You definitely should set this value to something other than '1', unless you have some reason for not wanting parallel work -- the time required to transit the network, even a very fast <1ms transit network means you are wasting CPU cycles unless you have a couple running in parallel.
Note that we also spawn a separate process for handling "slow" devices -- ie devices that we've identified as down or otherwise unreachable (this determination is done by the capture agents and automatically updated as we re-obtain or re-lose reachability). That way, your main processes are mostly handling fast, responsive devices, and we trudge along with one process verifying each of the slow devices.
MAXFORK While the master process will double the number of agents of a particular type as needed, it will never exceed the MAXFORK value (plus the extra "slow" agent). This is to prevent the master process from running away and killing your system with dozens of capturing agents. We set this value to '12', which seems like a reasonable value. If the entire NetMon system is paused for awhile (which we do once in awhile during testing), and then restarted, we quickly hit the MAXFORK value. While the system is slow, it still handles the load.
DEV_PER_RUN Each capture agent will select a chunk of DEV_PER_RUN devices to begin work on during each iteration. The goal here is to reduce database hits (by grabbing a few devices that need work instead of just one-at-a-time). However, going too high may mean that you don't enjoy the benefits of parallel work, and also means you can't stop the whole system quite as fast. The agents will only check for the existence of /etc/nonetmon once every iteration, and especially with the slow-device agent, it may take a few minutes to get through a reasonably large list of devices. We set this value to '5'.
SPIN_SEC The master capture process will sleep for SPIN_SEC seconds at the end of each iteration of checking the scheduled work and active agents. Setting this for too low means you are doing a fair bit of extra database and system work identifying the number of agents, while going too high means a slower reaction time to changes in the environment (new work, falling behind, etc.). We use a value of '10' seconds.
SEARCH_LIST This list is used to translate the names assigned to routers and switches into valid hostnames. (As retrieved by the SNMP OID .1.3.6.1.2.1.1.5.0.) Basically we recommend that you create this list of any domains used by any of your network devices.
NetMon has a database separate from NetReg, but requires a connection to the NetReg database for much of the useful cross-linking. Additionally, certain components of NetMon are designed to be installed on machines other than the NetMon machine (for example, the DHCP server), so we have multiple database connection strings. The format of the DB connection strings is exactly the same as the NetReg_Web_DB variables (as configured in the WebInt section).
Note that MySQL's connections across the network are not currently encrypted (though the password exchange is done via a challenge-response). We have tried strategies involving SSH tunnels, but these have been extremely unreliable. MySQL 4.0.0 is supposed to include support for SSL connections, though as of this writing, 4.0 is not in 'beta' stage. We recommend your user table on both the NetReg and NetMon server allow specific users access from specific IPs only (or 'localhost' for local connections). This will minimize any ability for malicious password guessing. Also, the netreg-install.pl script has a routine for easily generating some random strings to use as passwords.
NetReg_DB This needs to be a connection string that grants NetMon read access to the entire netdb database on your NetReg server. Note this does not need to be read-write. Our default string is: ['DBI:mysql:netdb:netreg.net.cmu.edu', 'netmon', 'file=/home/netreg/etc/.password-s=netreg-u=netmon'].
NetReg_RW_DB This connection string is used to establish read-write access to the NetReg database. Wherever possible, the read-only connection is used (to minimize potential exposure). If you do not want to allow read-write access from NetMon, some features (such as subnet purges) will be unavailable, as they must update NetReg records.
NetMon_DB This is the standard connection string used for connecting to the NetMon database. It should grant read-write access. See the Installation section above for an exact definition of what 'read-write' needs to encompass.
NetMon_Rem_RW_DB This is the connection string used by NetMon components when they are accessing the NetMon database remotely (for example, the DHCP lease information loader).
NetMon uses syslog to record a variety of log information. This section allows you to tune some of the logging parameters. In general, you should run: perldoc Sys::Syslog for a description of the various terms, and how they need to be specified.
SYSLOG_FAC The default facility is 'daemon', but you may want to adjust this depending upon your syslog configuration.
SYSLOG_OPT By default we specify 'pid' as the only syslog option; this means that the process ID of the process originating the log message will also be logged.
SYSLOG_LOGSOCK If your syslog server uses a unix domain socket to listen for new syslog entries, the logsock should be 'unix'. Again, consult the man page (see 'setsockopt') for more details.
The processing engine takes the raw captured data and processes it. During this, extraneous or duplicate information is eliminated, other data is condensed by using "begin", "end" and "last updated" times (and thus eliminating data that continues a series). The variables here affect the processing.
Process_Modules The Process_Modules variables defines the set of capture_types that need to be processed. The format is an associative array of capture_type keys to a reference to an array of three elements. The keys are, by convention, lower case and prefixed by a dash. You should verify that no key is a substring of another (ie '-foo' and '-foobar' would conflict.)
*A reference to a function that conforms to the processing API and processes the selected capture type
*The name of a lock that will be used to ensure mutual exclusion. By convention we use the upper case form of the capture type prefixed by 'RUN_'
*The processing interval. This is the minimum elapsed time between sucessive runs of the processing engine. The format must conform to that suitable for use with MySQL. Generally speaking, the format is the word 'interval ', followed by the quantity, followed by the units. The units are typically the singular form of traditional time spans (minute, hour, day, etc.)
Note that there is no requirement that only valid capture types be used as keys for the processing engine -- as long as the requirements are met (a valid function, for example), you could have a processing routine to make coffee. (Perhaps there would be a few other requirements in this case..)
ROOT_DEVICES The network topology generation code needs to have some idea of the root of your network. The format is a list of devices that should be put at the top of your automatically generated network topology.
LOCK_OVERWRITE If the processing engine for any component does not finish in LOCK_OVERWRITE seconds, the master processing engine will start a new process agent and overwrite any locks of the previous agent.
MAX_PROCESS MAX_PROCESS specifies the maximum number of entries to process at a given time. You should set this to be more than the approximate number of MACs on all devices, or it will probably thrash around trying to run topology and what-not. It's mainly to prevent Process from being choked if Process doesn't run for some period of time and is trying to recover.
SaveCAMForTopology This variable triggers the CAM processing engine to save certain MAC addresses (those belonging to network devices known via DevMACs) so that the topology information can be completely generated. However, we recommend you set this to '0' unless you are actively using Topology (see the section under "NetMon Design"). Otherwise you'll get a number of entries in cam_capture that don't go away.
Capture_Components The VARIABLE Capture_Components contains a list of all the various capture types and the associated methods for invoking them. There is a standard API for capture routines. The variable is specified as an associative array of "key" to a reference to an array of capture type information. The capture type information contains a reference to the function that processes that type of data, a generalized name for the capture type, and a printable name for the capture type. The various types should be formatted as:
*Key: The Key is used while counting capture agents, so it should be unique and not exist as a substring to any other key. (IE, if you had -foo, you would NOT also want to have -foobar, because they could be incorrectly counted as the same.) The convention is to have the capture type prefixed by a dash, all lowercase.
*Function: This should be a reference to the function that accepts the standard API for capture routines.
*General Name: The convention is to use the lower-case capture type plus the string '_capture'.
*Printable Name: This should just be a human-readable, nicely formatted name, like "ARP".
StatFile We set this to $NRHOME/etc/statfile. The statfile contains some statistics on how current capturing is going (for each capture type, how many processes are running, how many devices want attention, etc.)
MAX_PAGE This should be the maximum number of database rows to present on a single page table. We use '20'.Th
NETREG_URL This should be set to the full path to your netreg.pl script (ie, not a pre-page, but the actual NetReg script). This will be used to create links from NetMon direct to NetReg pages. For example, we use http://netreg.net.cmu.edu/bin/netreg.pl.
NETMON_SERVER This should be set to base URL of the NetMon server (ie http://netmon.net.cmu.edu).
NETMON_AUTH_URL NETMON_AUTH_URL should contain the complete URL to your protected NetMon pages. We allow only administrators access to these pages. Our value is, for example, $NETMON_SERVER/bin/netmon.pl.
NETMON_UNAUTH_URL NETMON_UNAUTH_URL should contain the complete URL to your public NetMon pages (ie the network debugger). Our value is, for example, $NETMON_SERVER/pbin/netmon.pl. The only difference between "bin" and "pbin" is that "pbin" does not require or attempt authentication, and netmon.pl will recognize the difference and handle the situation accordingly.
TREE_URL This should contain the complete URL to the Topology Tree graphing engine. By default you might want to use $NETMON_SERVER/bin/main.pl?id=.
TOPOLOGY_HEADER This contains the complete path to your header file for the topology generation. You probably want to use our supplied header and footer unless otherwise desired. The default is $NRHOME/htdocs/tree/code-top.html.
TOPOLOGY_FOOTER This is the complete path to the topology footer file. By default this is: $NRHOME/htdocs/tree/code-bot.html.
TOPOLOGY_TREEFILE The file generated from the topology information will be written to TOPOLOGY_TREEFILE. By default this is $NRHOME/htdocs/tree/code.html.
READ_LEV The READ_LEV should specify the level being used to indicate read-only access to NetMon. This value should be lower than the RW_LEV or ADMIN_LEV. We use '3', for example. This does not need to be changed unless you have a good reason for doing so.
RW_LEV The RW_LEV should specify the level being used to indicate read-write access to NetMon. This value should be higher than READ_LEV and lower than ADMIN_LEV. We use '6', for example. This does not need to be changed unless you have a good reason for doing so.
ADMIN_LEV The ADMIN_LEV should specify the level being used to indicate administrative access to NetMon. This value should be higher than RW_LEV and READ_LEV. We use '9', for example. This does not need to be changed unless you have a good reason for doing so.
EmailAddress Similar to NetReg's ADMIN_MAIL, this should be an address to receive NetMon error reports. We use a different address than NetReg, for ease in identifying the source.
ReportInterval To reduce the likelihood of NetMon falling off its rocker and spamming you with email, we implemented a duplicate-message-type suppression system. The interval specified in ReportInterval (in seconds) will be the minimum time between reporting similar type errors to the EmailAddress. The error reports will still be logged to the NM_ERR_DIR below. We use a value of 3600 seconds (1 hour).
NM_ERR_DIR The NetMon Error Directory will receive a copy of all error reports, even those suppressed due to time intervals. We use $NRHOME/etc/netmon-errors.
NetMon has a number of features related to DHCP management. For complete details, read the "NetMon Design" section. None of these configuration bits are relevant unless you are using the DHCP lease loading/graphing capabilities.
DHCPStaticLog This variable specifies the location of your DHCP static log. As described in the "NetMon Design" section, this is a custom logfile that records fixed-address assignment. This variable needs to be set correctly on all DHCP servers being used to load lease information. We use /var/log/dhcpd.static, for example.
DHCPLeasesFile The DHCPLeasesFile variable should point to the location of your DHCPD leases file. This is typically in /etc/dhcpd.leases, but your location may be different. This is the standard DHCP leases file from ISC DHCP 3.0. This variable must be set on all DHCP servers being used to load lease information.
DHCPConf A copy of your dynamic DHCP configuration (see the NetReg sections for our definition of "dynamic" versus "static") must reside on the NetMon server. Using NetReg, it's easy to add your NetMon server as a recipient of a DHCP configuration (and adds very little overhead to DHCP configuration generation). Please specify the complete path to the DHCP configuration. You might use $NRHOME/etc/dhcp-xfer/dhcpd.conf.HOSTNAME.
DHCPGraphInterval NetMon must translate DHCP leases (specified with a start and end time) into a series of data points representing "X users had leases at this time". In order to do that, it steps through time and generates data points at certain intervals. The DHCPGraphInterval variable specifies that interval (in seconds). We use a value of 300 seconds. Since we added the graphing after we started collecting lease information, the initial graphing run took several hours as it stepped through time passed.
RRDToolPath This variable should contain the location of your rrdtool utility. For example, we have it installed in /usr/local/bin/rrdtool.
RRDDBPath This variable should contain the directory that you want to use to store your RRD database of DHCP utilization information. We use $NRHOME/rrd.
DHCPImgPath This provides the absolute path on disk to the directory your DHCP graphs should be created in. Probably want to use $NRHOME/htdocs/dyn-img.
DHCPImgURL This provides the path as web clients would see to your DHCP graphs. We use /dyn-img.
DHCPImgPeriods Utilization graphs for all dynamic subnets will be constructed based on the DHCPImgPeriods array. One graph will be created for each entry in this array. Each entry indicates a number of days to cover in the graph. If you want reasonable titles over one month, you probably want to look at pdhcp_gen_graphs in CMU/NetMon/Process/DHCP.pm. The default is: (7, 28).
[ Contents| First Page | Previous Page | Home | Next Page | Last Page ]
[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
Copyright © Carnegie Mellon University 2000-2003. All rights reserved.