Le 10/09/2013 17:43, Marco Gaiarin a écrit :
Mandi! Guillaume Rousse
   In chel di` si favelave...

Then, i was used to run, by hand, when i need to upgrade the GLPI data, the
.bat script on program folder, eg:

        C:\Program Files (x86)\FusionInventory-Agent\fusioninventory-agent.bat

with the new version, what script i have to run?
The same as previously, nothing has been changed sofar. We'll
probably use a new major version number for this kind of change.

Ok, i'm back poking with 2.3.0.

Now on the FI folder there's 3 batch files:
   fusioninventory-agent.bat (taht run 'perl fusioninventory-agent')
   fusioninventory-injector.bat (taht run 'perl fusioninventory-injector')
   fusioninventory-inventory.bat (taht run 'perl fusioninventory-inventory')

To do a simple inventory, by hand, i have still to run the first,
'fusioninventory-agent' as before?
If you want to transmit the result to the server immediatly, that's the only solution currently.

The 'fusioninventory-inventory' confuse me a little... ;-)))
The point of each 'fusioninventory-something' is to run the 'something' task directly, and send the result where you want. With current release (2.3.1), those executables are only able to print those results on stdout, but for next release, they'll be more versatile. It means you have full local control over what to run, when and how.

When you run 'fusioninventory-agent', on the other hand, it contacts each server in its configuration, and ask each of them what should be done. Unless you use --force, if the server doesn't ask for an inventory, the agent won't run an inventory. It means that agent execution control is both local-controled (you decide when to run the agent, and for some tasks, how), and server-controled (the server decide what is run, and for all tasks but local inventory, how). This is ugly and counter-intuitive.

The goal for the 3.0 release is to enforce a better separation between local and server-control, by reducing the 'fusioninventory-agent' to something that is fully server-controlled. But so far, we've not reached this point...
--
Guillaume




_______________________________________________
Fusioninventory-user mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-user

Reply via email to