1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
This document will attempt to describe how the program works
internally to simplify making code changes.
On the database side there are tables to hold the area, range,
customers etc. I think that is self explanatory. IP addresses and
network addresses are stored in the databases as integer so that
comparisons can be made directly in the database. There are numerous
helper functions in the ipplanlib.php script to deal with the
conversion from int to quad and vice versa. (These functions should be
converted to a class, but it looks like too much of a mission to
integrate). The integrated functions that is available in php for IP
conversion are broken, so they cannot be used.
Most of the tables also have complex indexing schemes to prevent
duplicate info being entered (see ipplandbf.sql for the table
layouts). I use the indexes to test for integrity by just inserting
into the table and checking for errors. All referential integrity
is handled by ipplan itself, not the underlying database. The reason
for this is to make ipplan as cross database as possible.
Subnet sizes are stored as "number of hosts", not masks. This once
again makes calculating overlaps simpler. Most of the helper functions
used many times are in ipplanlib.php, most of the database stuff used
many times is in class.dbflib.php. There are some database calls local to
some scripts too, but they are only used in those scripts.
Getting back to the databases. Table base contains all the subnet
definitions for all customers. There cannot be dups within a customer
(customer field has a multiple primary key), but there can be overlaps
between customers (you will be warned via a test in createsubnet.php).
When a subnet is created, an auto increment is generated. This is the
key for the ipaddr table which contains the individual ip address
details. Only ip addresses that actually have assignments or values
exist in this table - reason is to conserve space. Imagine allocating
a class B and adding 64k entries to this table - just not on. The
display functions know this fact and "fill in the blanks". See
displaysubnet.php around line 216. Conversely if a record is deleted
or is entirely blank, it gets removed from this table.
The access control is described in a little detail in the README. It
consists of three tables; user, usergrp, and grp. user contains all
the users and usergrp contain which users belong to which groups from
the grp table. Access to the base table for modifying or creating
subnets are governed by these groups. If you belong to a group, you
can do stuff, if not access denied. So everything is group based.
Users cant get access anywhere, only groups. So when you log in, all
the groups you belong to get returned from the authentication class in
an array. A simple scan is then done through this array to see if you
can work with the component in question. You will see code like this:
$grps=$auth->authenticate();
$grps is the array containing which groups you belong to. Later a scan
is done when inserting, deleting, modifying etc.
Additional attributes are available as part of the group. The one is
if a group can create customers (createcust) and the other is a binary
encoded integer (getopt) which can contain many attributes. Currently
only bit 1 is used. If it is 0, user can only see info for groups he
belongs to, if 1, user can see everything. If 1, this does not imply
that the user can modify all, but mearly view all.
Note that if a user belongs to more than one group, a true value for
createcust or getopt implies true for all groups the user belongs to.
Finally, there is a table called schema. This contains a version
number which describes what the tables look like. At each startup
(called from the main index page) a check is made against this version
number. If the version number in the database and the version number
embedded in schema.php are the same you can run the program. If the
schema version is out of sync, ipplan will try to perform the
database schema changes to bring the database in sync. So if a person
wants to add extension (like SWIP) which will require database
changes, bump the version and add the "ALTER TABLE" etc statements to
the array in schema.php. Next time the users starts ipplan, they will
be prompted that changes need to be made with enough rights. If they
cannot make the changes, the program will not continue.
|
