Host and IP-space Management Platform

 

  • Project Background

  • The original goal of this project was to come up with a way to manage a large network environment with a minimal staff in an academic environment. However, we wanted to continue assigning permanent addresses for systems, dynamic address pools were ruled out. Further, we decided that we wanted this to be the basis of a larger system for managing maintenance and billing information.

    The result was that we created a database schema abstracting the information that we wanted to track and put a web front-end on it. The primary concern for the interface was to simply handle changes to hosts including moving them between networks. A couple of shell scripts then pull the information out of the database and build the configuration file for the DHCP server and the zone files for BIND and then reload the daemons.

    All computers are configured to use DHCP. However, the DHCP server is configured to assign the same address to a computer by checking the MAC address and looking the host up in DNS. This allows us to change addresses for systems without breaking most network services hosted on the system. So long as the users rely on DNS for services they provide, we can make changes to the network invisible to them and without spending hours visiting hundreds of computers.

  • Project Status / System requirements


    At this point, the package is a solid, undocumented (the code is well documented, but I haven't even started installation instructions) beta product. We have relied on it since January 2001 and find it stable and reliable. That's not to say that it is complete. There are a bunch of features that need to still be incorporated, but these primarily simplify use rather than providing new features.

    So what does this require?


    I'll be adding screenshots and documentation in the future.

  • How it works

  • The database schema abstracts host information into a series of tables:

    • cname - handles all CNAME type records
    • doman - handles domain-specific information
    • filerevision - watches to increment the serial numbers of the DNS zone files
    • hosts - stores all information that is unique to a particular system
    • location - lookup table mapping building locations to the appropriate subnet
    • mx - handles MX type records
    • network - stores information that is specific to a particular class-C subnet
    • os - lookup table of operating systems referenced from the hosts table

Each subnet has a range of addresses set aside for network devices (switches, hubs, firewalls, routers, etc.), a block of addresses that are available for dynamic allocation, and other network specific information that DHCP distributes to client systems (lease times, gateway addresses, etc.). Different locations (buildings or portions of buildings) are associated with the subnets such that computers in a given location will be assigned addresses and appropriate options in the subnet.

Further complicating things, we classify non-network systems into three categories; desktop, portable, and mobile. Desktop systems are assigned a single address and cannot take part in dynamic address pools. Portable systems are your typical laptop. They have a home location, but need network connectivity in other places as well. Therefore, these systems are assigned a fixed address on their home subnet, but can participate in dynamic pools on other subnets. Finally mobile systems are devices which have no home location. In our environment, these are primarily carts with LCD projectors and laptops, but you can envision network aware Fluke meters, Network General sniffers and other things which need to get an address anywhere they attach. These systems only participate in the dynamic pool assignments.

When a computer is added the following happens:

    1. The user (a staff member tasked with handling network connection requests) requests to add a new computer of a specific system type in a particular physical location via a web form.
    2. The system checks against the subnet that services that location for an available address.
    3. If an address is available, a new entry is created in hosts and assigned an IP address (if a desktop, portable, or network device).
    4. The user then faces a form requiring a bunch of additional information to fill out our record of the equipment.
    5. After making all necessary changes and additions, the user orders that the DNS and DHCP tables be rebuilt. This generates new tables (saving the old version) and reloads the daemons.

Once these steps are complete, the new computer is up with its address via DHCP and resolves under both forward and reverse DNS queries.

  • To-do list
    • Bounds checking on MAC address and hostnames
    • Add database-based user controls rather than relying on Apache.
    • Beef up report structure.
    • Add account tables and reports (version 2?)
For more information, send me a note at SourceForge
SourceForge Logo