changed:
-
If you have a lot of products, they can get unwieldy. Due to too much information it can be hard to find the what should stand out.
Background
----------
Debian has 18733 individual packages available. Ubuntu should have about the same. Once you start getting package information for these systems, it would be very useful to organize it in a manner which facilitates easy search and retrieval of information.
The simple priority approach
----------------------------
This is the simplest approach. It involves two sets of regular expressions used to create three lists.
:Important: Any packages matching one of the "important" regular expressions goes to the Important list.
:Normal: Any packages matching neither the "important" nor "ignorable" regular expressions goes to the Normal list.
:Ignorable: Any packages matching an "ignorable" regular expression goes to the Ignorable list. By default this list would not be displayed.
We would want to check first the important regular expressions, then the ignorable regular expressions. This would allow people to consider "postfix" important, but consider the associated packages "postfix-(cdb|ldap|mysql|pcre|pgsql)" ignorable.
The bucket approach
-------------------
An extension to the simple set of three lists, would be to have a number of "buckets" which are fed by the regular expressions matching from the product list.
These buckets could have the following groups:
:Unknown: anything unclassified
:Service: anything opening a network port or adding major functionality
:Service Add-on: supporting packages for services
:Development: development packages
:Base OS: core OS features which do not include things in "Service". For most people anything that fits in this category should safely be ignorable.
:Desktop: any X11-based application/tool
:???: (Is there anything else?)
Examples: "postfix" would be a service, but "postfix-(cdb|ldap|mysql|pcre|pgsql)" would be in Service Add-on. gcc and make would be in Development. adduser, bash and coreutils would be in Base Operating System. Any of the GNOME or KDE stuff would be in Desktop. Anything unmatched would be un Unknown.
This has the advantage that a single set of rules will work with any distribution and only requires a simple list of installed packages.
You could also easily have a Show/Hide checkbox for each bucket so you a user could focus on just the interesting parts, without having a lot of screen clutter from packages expected to be on all machines.
The product section approach
----------------------------
If the products are extended to have a "section" field we could populate it from the system's package management system.
This would mean that the data in Zenoss would more closely resemble the data in the package management system, but it would also be more complex as differing distributions can use different sections and priorities for the same version of a product.
I don't really see that many benefits of this approach as the section and priority is more relivant to distribution provider than for administrators who have decided on the packages they want.
Blacklist variation
-------------------
Either the "simple priority approach" or the "bucket approach" could be extended to have a list of packages which trigger Zenoss events if installed. Even if the package data is only recollected on a weekly basis it would still allow administrators to know that a member of their staff installed something they never want to see.
Examples of potentially blacklisted packages could include:
* bit torrent client
* telnet/rsh server
* any MTA which is not the officially recommended MTA in the office
* etc.
Now, this variation becomes useless if we're planning more extensive logic to support package-triggered events. Legitimate package-triggered events would allow you to not only trigger warnings and errors when blacklisted packages are installed, but it should also allow you to trigger a warning or error if package A is installed without companion B. (For instance, it would be nice to trigger a warning if ssh was installed without fail2ban.)
Zenoss News