Bug report

How to report issues efficiently ?

In order for the developers to track and fix issues properly, you need to use GitHub bug tracker, and report an issue with the proper component. This requires an user account.

Here are a few usage rules, so as to avoid wasting efforts both for the reporters and for the assignees.

Component identification

You have to identify if the problems occurs on agent (the agent doesn’t report the expected value) or on server side (the server doesn’t display the expected value).

In order to do this, you have to look at the raw content generated by the agent, and transmitted to the server. The easiest way is to look at the import information tab available for each GLPI object (computer, network device, etc…), which provides a link to download this content. Another solution is to use the various fusioninventory-something executables (see agent man pages for details) to produce the same content directly on the agent host. However, subtile differences may occurs, if the execution environment and privileges are not the same as non-interactive executions.

Once the faulty component identified, use either:

Problem description

You have to use english, for sake of internationalization.

You have to describe your problem clearly and precisely, for someone without any prior knowledge of your environment to understand it. Posting screenshot is not a solution if you’re unable to explain it with words. Posting relevant log extract, or agent output, is a better idea.

Also, the agent is available for different platforms, with different versions, and different installation methods. You have to specify at least the system you’re using, the agent version, and how you did install it.

It is useless to set a priority, it will be re-evaluated by the assignee anyway.

Execution traces

Agent log verbosity may be increased by raising debug configuration parameter value (alternatively, by using multiple –debug command-line options).

Server log verbosity may be increased by enabling extra-debug configuration parameter in plugin configuration.

Please post only relevant part of logs: we don’t care about local inventory task execution messages, for instance, when dealing with a remote inventory issue.

External content

When the issue is related to some missing or invalid value, most of the time, it is caused by a parsing error while processing external data (a command output, a file, whatever…). In order to reproduce the problem, fix it, and ensure it won’t happen again, we need a sample of those data.

Either attach the relevant file or command output as an attachement to the bug report (just pasting it will usually result in formating loss), or if there is any privacy concern, send them by email to walk at fusioninventory dot org, with bug ID in mail subject.

When running any command for such purpose, unset locales first (export LC_ALL=C undex Unix) to avoid localized output. Here are other command-specific advices.

WMI queries

Windows WMI queries can be exported with wmic tool:

wmic path <somequery> get /Format:list > <somefile>

Registry extract

Windows registry content can be exported with regedit tool:

regedit /e <somefile.reg> <somekey>

dmidecode output

dmidecode output can be generated on any system, including windows, as we ship a dmidecode executable in windows distribution of the agent, in the perl\bin subdirectory.

\path\to\fusion\perl\bin\dmidecode > <somefile>

snmpwalk output

snmpwalk output can be generated with the following command:

$> snmpwalk -v <version> -c <community> -t 15 -Cc -On -Ox <somehost> .1 > <somefile>

Using an explicit root OID (.1 here), a non-default timeout (15s, as the agent), and disabling internal consistency checks (-Cc) if often required to extract all required information.

Option ‘-Ox’ is not mandatory but can help to enhance debugging but also discovery and inventory tasks as we may not know anything about the related MIB. So just having full numeric OID can help.