Changes between Version 1 and Version 2 of WikiStart

Jul 7, 2010, 6:09:29 PM (11 years ago)
Kris Deugau



  • WikiStart

    v1 v2  
    1 = Welcome to Trac 0.11.5 =
     1= !DeepNet IP Database =
    3 Trac is a '''minimalistic''' approach to '''web-based''' management of
    4 '''software projects'''. Its goal is to simplify effective tracking and handling of software issues, enhancements and overall progress.
     3This is an IP address management tool I developed originally for my then and current employer [ ViaNet Internet Solutions] as a replacement/upgrade for an existing internal staff tool that got left gathering dust.
    6 All aspects of Trac have been designed with the single goal to
    7 '''help developers write great software''' while '''staying out of the way'''
    8 and imposing as little as possible on a team's established process and
    9 culture.
     5I started originally from the perspective of exporting netblock allocation data to [ rWHOIS] from the existing tool.
    11 As all Wiki pages, this page is editable, this means that you can
    12 modify the contents of this page simply by using your
    13 web-browser. Simply click on the "Edit this page" link at the bottom
    14 of the page. WikiFormatting will give you a detailed description of
    15 available Wiki formatting commands.
     7On trying to make sense of the existing tool's database structure, and how it handled netblocks (basically, it didn't;  it allocated ranges of IP addresses which were free to begin and end places other than CIDR boundaries), I started replacing data structures and code to get the stored data consistent enough to export to [ rWHOIS].  That basic need was met before using source control, and is represented by r4 - almost a complete replacement of the original code.
    17 "[wiki:TracAdmin trac-admin] ''yourenvdir'' initenv" created
    18 a new Trac environment, containing a default set of wiki pages and some sample
    19 data. This newly created environment also contains
    20 [wiki:TracGuide documentation] to help you get started with your project.
     9Code has since developed to support most of the needs of a medium-sized ISP.  As of writing, code up to SVN revision r396 (/branches/stable) has been in live production use.
    22 You can use [wiki:TracAdmin trac-admin] to configure
    23 [ Trac] to better fit your project, especially in
    24 regard to ''components'', ''versions'' and ''milestones''.
     11=== (Mis)Features: ===
     13As of v2.6:
    27 TracGuide is a good place to start.
     15- mostly supports IPv6, although a few segments still assume v4 addresses.
     16- internal data structures emulate the general routing configuration of most networks, although
     17  it does not directly represent or emulate deep routing chains.
     18- "maxiumum contiguous free space" allocation alogorithm;  if a /29 and /26 are allocated from a /24, then allocation of a /27 will happen from the free space between the /29 and /26.  Planned enhancement:  Reserve space for expanding a block (#24).
    29 Enjoy! [[BR]]
    30 ''The Trac Team''
     20  This also relies on NOC staff using the IPDB allocation interface to request address space for customers, rather than looking at what's free on the router and using something handy...  as well as relying on NOC staff to enter whatever arbitrary changes they've made.  Planned enhancement:  Module to walk router configs (either live or backup copies) and compare with allocations as listed (#25).
     21- hook to support checks against an external system for customer IDs
     22- rWHOIS export with either organization name/address or customer data as contact for published netblocks.  This can be toggled on a per-allocation basis.  Note that you still need to submit SWIP templates (if you're getting address space from ARIN) if you wish to delegate rDNS nameserver authority on /24 and larger blocks.
     23- preliminary support for email notifications to arbitrary destinations on any action.  Currently, static IP assignments, netblock assignments, deallocations, and updates to blocks with the SWIP flag set will generate notices.
    32 == Starting Points ==
     25=== Notes on SVN history ===
    34  * TracGuide --  Built-in Documentation
    35  * [ The Trac project] -- Trac Open Source Project
    36  * [ Trac FAQ] -- Frequently Asked Questions
    37  * TracSupport --  Trac Support
     27Original development was done without any regard for keeping proprietary or company-specific information out of the code and SVN (eg, database passwords, hostnames, hacks for certain bits of awkward legacy data).  I've taken the in-house repository used for development, and recreated all revisions up to r396 without most information specific to [ ViaNet].
    39 For a complete list of local wiki pages, see TitleIndex.
     29Development past r396 has been committed entirely to this new repository, and most of those commits have been to trim out some dangling bits of hardcodedness necessary to make it simple(r) to install this and use it for any organization without having to patch the code.
     31=== Conventions ===
     33- A "larger" block is one with more IP addresses in it.  Conversely, a "smaller" block is one with fewer addresses.
     35=== Requirements ===
     37- Perl
     38  - NetAddr::IP.  I would not recommend using anything older than 4.x;  however it should work well enough with 3.x.
     39  - CGI::Carp
     40  - DBI
     41  - File::Path
     42  - POSIX
     43  - Sys::!SigAction.  This isn't strictly required;  it's used in an example hook for validating customer IDs against an external database.
     44  - Sys::Syslog
     45- PostgreSQL v7.4 or higher.  Postgres provides an IP address/IP netblock data type, and operators to match;  much of the functionality relies on these database operations.  Other database engines could be used, with variying degress of trouble and hackery.  v8.x is probably a good idea since 7.x is no longer supported upstream.
     46- Webserver supporting CGI executables.  Note that the current code is somewhat inflexible about its web path, but that's due to be fixed (see #3, #15, and #17).
     48CPU and memory requirements have not been very high to date at [ ViaNet];  performance has mainly been impacted by everything else we've crammed onto the same server.