also listed as item 4 at ZBXNEXT-647

i'm not sure about the "host" and "host.device" keys. maybe it would make sense to split these up in hw/sw parts and make naming a bit more descriptive (as well as extendable) ?

something like system.hw.serial or system.hw.sn, then we'd get system.sw.os[short] etc.

at which point do we make additional narrowing down part of the key and when is it a parameter ?
as in system.cpu.load vs (current) host.device[serial] ?

system.cpu.info => system.hw.cpu[cpunum,<vendor|model|curspeed|maxspeed>]
host.arch => system.sw.arch
host.device[type|vendor|chassis|model] => system.hw.chassis[type|vendor|model|serial]
host.lspci => system.hw.devices[pci|usb]
host.macs => system.hw.macaddr[all|<device>]
host.name => already supported system.hostname, remove
host.os[full|short|...] => system.sw.os[...] + partially supported system.uname
host.packages => system.sw.packages

if using lspci... plain lspci ? -v ? -mm ? -t ? -tv ? -k ?

maybe allow manually specifying lspci params ?
<rudolfs> the key system.hw.devices accepts 'usb' or 'pci' as an argument, calling lsusb or lspci. since they do not have the same flags, none are specified

<richlv> maybe we shouldn't mix lsusb & lsbpci in the same item key then ? wouldn't that limit us later if we add support for other buses ?
<rudolfs> reviewer, please discuss the specifications with feature owner

1) Added items:
system.hw.chassis[full|type|vendor|model|serial] - default is [full], root permissions needed
system.hw.cpu[all|cpunum,full|maxfreq|vendor|model|curfreq] - default is [all,full]
system.hw.devices[pci|usb] - default is [pci]
system.hw.macaddr[interface,short|full] - default is [all,full], interface is regex
system.sw.arch
system.sw.os[name|short|full] - default is [name]
system.sw.packages[package,manager,short|full] - default is [all,all,full], package is regex

Available in dev branch: svn://svn.zabbix.com/branches/dev/ZBXNEXT-677

these should also be documented at :

http://www.zabbix.com/documentation/2.0/manual/appendix/items/supported_by_platform
http://www.zabbix.com/documentation/2.0/manual/appendix/items/agent_items

it should include info on what is done to retrieve information, like running lspci, lsusb etc. for those which are read from /dev/mem, it would require running agent as root, right ?
<rudolfs> all documentation will be done after the final changes are accepted

package list gathering :

as far as i can figure out, currently dpkg installed package list is read from a file. would be useful to support other approaches :

1. rpm systems - "rpm -qa" will give back a list. by default format is :
sed-4.2.1-2.1.i586
it can be customised with parameters.

2. on slackware, "ls /var/log/packages/" will give a list of installed packages. example :
zabbix-1.9.4-i386-1

but on slackware one can also run rpm and install packages using it, so detecting rpm and running with it would not be desirable...

zalex, thanks for the info, although i guess another zbxnext will handle that. is the directory readable by non-root users ?

(B12)

there seems to be some overly aggressive caching of positive (non-empty) results when requesting package list. consider the following exchange on a freshly started agent :

1. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms]

1. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms]

1. zabbix_get -s localhost -p 11050 -k system.sw.packages[age,showpms]
   [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
2. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms]
   [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
3. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms]
   [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586

<rudolfs> FIXED

<richlv> CLOSED

(B13)

if package request results in no packages, empty string is returned. zabbix documentation explicitly states that userparameters should not return empty string (http://www.zabbix.com/documentation/1.8/manual/processes/zabbix_agentd), so it should be decided what to do about built-in items.
latest zabbix server seems to simply discard such values, but the item is not set to be unsupported.

<rudolfs> the current logic was to return NOTSUPPORTED only if no supported packaging systems are found, otherwise an empty string should mean that there are no packages installed (which might indeed be useless if another unsupported packaging system have the packages...)

<richlv> yes, but server seems to discard this value, thus the item just stops gathering values (and it also somewhat contradicts our own suggestions and behaviour with userparameters). i don't have a great solution, so just thinking aloud here

<rudolfs> Changed the logic:
1) by default, ''showpms" is used
2) [regex,showpms] lists every supported PMS followed by package list matching regex e.g. "[dpkg] pck, pck2, [rpm] pck3, [pacman]"
3) [regex,onlylist] lists all the packages matching regex and returns an empty string if no package matches the regex

<asaveljevs> Shall we start each package manager on its own line?

<asaveljevs> Fixed in r19396, fixed again in r19406.

<rudolfs> Please review changes in r19423.

<asaveljevs> CLOSED

You might want to run the command 'pkginfo -E *' on FreeBSD, this returns the current packagelist.

Please add requests for other operating systems to ZBXNEXT-771.

Available in pre-1.9.5 r19752.

I see the patch for the table "help_items" in the rev 19752.
But, if you decide to alter this table, would be very logical to include this issue ZBX-2265 since you are not performed even better way ZBXNEXT-554