Read Me

scripts/dpkgImport.pl uses ssh to remotely access the server and run `dpkg -l`.

Currently installation is straightforward but manual.

Installation steps:

- Log in to mysql as a user with privileges to create a database, then source the dpkg.sql file:
	mysql> \. <path to sql>/dpkg.sql

- in mysql create a user with INSERT, UPDATE, DELETE and SELECT access to the dpkg tables:
	mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON dpkg.* FOR '<username>'@'localhost' IDENTIFIED BY '<password>';

- in scripts/dpkgIter.sh and htdocs/config.php change db_user and db_pass to the username and password you set in the GRANT statement

- ensure you have apache and mod_php installed

- copy the htdocs directory to wherever you want it serving from, configure apache if necessary

- To test it, run:
	scripts/dpkgImport.pl <server>

- create a file containing the list of servers you want checking

- run:
	scripts/dpkgIter.sh <servers file> <scripts directory>

  where the <servers file> is the list you just created and <scripts directory> is the directory in which dpkgImport.pl resides.

- go to the url


####################
Web frontend:

There are a number of different ways of querying the dpkg database:

- Select one or more servers - this will return all packages on each server and colour code the versions of each package across the servers you selected.

- Select one or more packages for comparison to see all versions of the packages across all servers.

- Fill in the 'From date' field to see all 'changes' since that date.

- Fill in the 'To date' field to see all 'changes' up to that date.

- Use combinations of the above for more restrictive queries, e.g. 'From date' and one or more servers to see all 'changes' since then for any packages on just those servers.


'changes' are based on when dpkgImport.pl was run against the server - this means that the first time you run it all of the package versions will show as having been 'installed/upgraded' at that date/time, and future upgrades/installs will only be picked up when you run the script against the server. You'll probably find that cronning the script to run once a day is adequate for most purposes. To cron the script it will be necessary to use ssh keys to allow non-password access to the remote servers.

For assistance contact me (Tom Hudson) at tom.hudson@isotoma.com

--
Tom Hudson
isotoma
http://isotoma.com