The base of PACT is found in the database. PACT - at current - does not keep any data in flat files, all configuration data is read from the database. That means that before you can call the collector (or anything else), you will need to set up some basic information for the system. To start out with, you will need to add router or server data. From the main menu, use the link "Server" (or the file host.php3) to get an overview of the currently defined servers. Most likely, after installing for the first time, no entries will be present. After selecting "New Entry", a form is displayed allowing for some data entry. Enter the symbolic name or IP of the machine you wish to query, and the snmp community (make sure you get both right, as the collector does not handle illegal names or wrong communities to gracefully yet). The field "Interface#" can be left empty, it will be filled automatically by the collector.

After saving the data, you can go and add additional servers or hosts to the database. Once you're finished with that, it's time to add the ports. As it would be quite some work adding every desired port with the appropriate name and data by hand, no function to create new port entries is provided. Instead, the collector handles this when being called with the "-c" option. Therefore, once you're finished with the servers (or any time in between), call the collector. Usually, when using the default setup, you can do this with "collector -p <password> -c -v" (of course, replace "<password>" with the password for your database). The collector should now go through all entries in the host-database, check for available interfaces, and update the database appropriately.

After successfully creating the port entries, you can now go ahead and add the customer data. Apart from the name, a password (which is used to give the user access to his own accounting data) and a description an excternal user-id can be defined. It can be used later to export the accounting data to another program.

After setting up the customer data, you can now define which ports belong to which customer. Please note that only ports that have a customer-ID that is bigger than "0" are accounted. On the port definition, it shouldn't be necessary to alter the bandwidth entry. The value, in bit/s, is read from the server or router and used to do sanity-checks before storing the data in the accounting database.

Select any customer from the drop-down-menu, and setup the description of the entry. After clicking "Update", the data is stored in the database, and any subsequent call of the collector program will now store the amounts of data used on this port in the database.

As mentioned before, the collector is the main part of PACT. Apart from creating the port definitions, it reads, checks and stores the accounting data. At the moment, the following options are supported in collector:

/tmp/debug.pact-YMD-hms

Once you have confirmed that the collector is called correctly, and that the data is stored in the database (do a "select * from raw;" in mysql), you can set the collector up to be called in cron. You can use the following entry:

    */5 * * * * /usr/local/bin/collector -p mypasswd

in just about any user's crontab. Warnings or error messages will automatically be sent to the owner of the cronjob. At the moment, collector will notify you if:

• a counter overrun occurs, which - at least with Ciscos - happens at approx. 4 gig (32bit unsigned). Collector will store the total of the data amount in the database (counter_new+0x100000000-counter_old). This should be correct with any device complying to the SNMP standard (check the collector options to disable the warning)
• a server and therefore the counter is reset. This will result in the "counter_new" being stored as the amount of data transfered.
• more data than technically possible has been transmitted (based on the time since the last query and the bandwidth defined for that interface). Apart from the error message displayed, no data is stored in the database. This shouldn't happen, if it does you might have some kind of problem (like the bandwidth of a port being defined smaller than the actual line is) ...
  Additionally to the error message, an SQL line will be output you can use to store the "lost" data in the database with.

Depending on the option in "global.php3", the query-page will either expect a manual input of a customer ID, or have a Select-button containing all available customer entries. After entering either the customer's access password, or the systerm master password, a list of all ports that have been assigned to that customer is displayed, together with a numerical info on the amount of transfered data. Every port can then be selected to show a per-day-listing of usage, combined with a graphical representation of the amount of traffic created. Also, an overview over the combined sum of all ports can be selected.

In order to reduce both the amount of data stored in the database, and decrease access times to archived data, PACT has functions to compress collected raw data into an archived form. At the moment, sums of data transfer are created, storing one hour's data in one data set. Data is still kept seperate per customer and port. All consolidation functions are found under the "Consolidate" menu link. Calling the main page results in an overview, displaying important data about both the raw and archived tables, e.g.:

In the raw data area, you can either select to consolidate the collected data into the archived format, or delete the collected data. Please make sure the data has been correctly written to the arc table before deleting it from the raw table (when consolidating, a check will be done to see whether the sum of the transfered data is the same in both tables). In the archived table you can also select to delete the data, use this when creating temporary consolidations, as there is no check for dupplicate values. I'd advise you to work as follows:

PACT always uses the raw table to do current month statistics. For anything older than the current month, the arc table is used (as of PACT 0.8). Therefore, at the beginning of the new month, make sure the arc table for the previous month is empty, consolidate the data, check, whether the results are plausible, and then delete that month's raw data.

As of version 0.9f, ipchains accounting has been added. This adds quite some possibilities to PACT's functionality. While there are some limitations on the side of PACT (due to some internal handling), ipchains' filtering and accounting functions outweigh them easily.

In order to use ipchains accounting, you will need to run a 2.1 or 2.2 kernel. ipfwadm accounting will not be added (no real reason for running 2.0 kernels anymore), and 2.4's iptables support has not been added yet. Also, you will have to make sure that you have ipchains enabled in your kernel, otherwise - of course - it will not work.

With PACT, all you have to do is add a new virtual host, selecting "ipchains" as system type. The name of the host doesn't matter, it is not used for anything at the moment. Once the host is created, run collector with the "-c" option (as you always have to do to add ports). This should result in at least two "ports" being created - the default chains of ipchains, input and output. Should you already be running a firewall with custom chains, those, too, should appear as ports.

Please note that only the first entry of a chain will be accounted, therefore you will have to set up extra chains that will be used for counting the traffic. They may be addressed by several other rules. For example, imagine you wanted to do two seperate accounting chains, one that counts all the traffic to a certain host, and one that counts all SSH traffic. You could use the following commands to set it up:

ipchains -N accthost
ipchains -N acctssh
ipchains -I input -j accthost -s 192.168.0.3
ipchains -I output -j accthost -d 192.168.0.3
ipchains -I output -j acctssh -p tcp --source-port 22
ipchains -I input -j acctssh -p tcp --destination-port 22
ipchains -I accthost -j ACCEPT
ipchains -I acctssh -j ACCEPT

The first two lines set up two new chains, accthost and acctssh. Then, two rules are installed that send all traffic coming from and going to the host 192.168.0.3 to the new chains accthost. Then, all tcp packets that either come from port 22 or go to port 22 (the SSH port) are forwarded to chain acctssh (please note that chain names may only have 8 characters). Then, both new chains get a rule that will accept any traffic, which also is used by PACT to count the traffic.

Once the ipchains rules have been set up, the regular handling inside of PACT applies. That is, assign the virtual port to a customer, and that's it. Please note that no matter if traffic is coming or going, it will be counted as "incoming" in PACT; as the ipchains do not use sperate counters for the two directions. You could set up two different accounting chains with the redirection from input and output going to one each, but still PACT will count both chains as "incoming" (any reasonable ideas on solving this differently are appreceated).

One final (and important) note about ipchains accounting - in order to be able to access the appropriate data, the collector will require read access to the file

/proc/net/ip_fwchains