gmane.comp.monitoring.fusion-inventory.devel

[warning] "git rebase" done on 2.2.x

Gonéri Le Bouder — 2012-05-24T08:48:38

Hi all,

For those who have a clone of the fusioninventory-agent git
repository, I did a rebase of the 2.2.x branch
in order to drop some experimental charset changes.

This means your local 2.2.x go nowhere now, you save you changes, for
example with git format-patch
and destroy, recreate it:

  git checkout origin/2.3.x
  git branch -D 2.2.x
  git checkout -b 2.2.x origin/2.2.x

Sorry for this.

Best regards,

Re: [FusionInventoryAgent][NSIS] My lastskeleton...

Gonéri Le Bouder — 2012-05-17T13:17:06

This is awesome! I love it!

I attached a picture with my comments. Do you have a web space somewhere
to upload the .exe? I can create one for you if you want. This well,
it will be much
more simpler to get feedback from people, for example by sending the URL on
the mailing list or IRC.

IMO, wait parameter is useless and we will drop it probably after the
3.0 release.
“Run after installation” already means wait=10, so I don't see the
point to add a
feature only for this key.
It's more or less the same for 'backend-collect-timeout', if someone
really need it
(99.99% or the users won't), he can still create an additional .reg
file to set the
property.

Regarding the spanish/french translation, will this work with Asian or cyrillic
charset?

Cheers,

beta 3 of plugin FusionInventory for GLPI0.83+1.0

David DURIEUX — 2012-04-22T21:04:19

Hello all,

I have release the third BETA of plugins fusioninventory for GLPI 0.83.x

This version have all bugs fixed from 0.80+1.2 version released few
days ago. It pass too unit tests for snmp inventory, network discovery
and computers inventory. But tests not (yet?) test all :p

See tickets: http://forge.fusioninventory.org/versions/67
Some of these tickets will be moved to version 0.84, others are in
progress (like ticket for simplify tasks) and others will be coded in
the next week to set in couple of days the first Release Candidate
version. 

Please use agent 2.1.14, because version 2.2.x have some problem with
network discovery and SNMP inventory (or you can but if you have
troubles,you will don't know if come from agent or plugins).

Download here:
http://forge.fusioninventory.org/attachments/download/614/fusioninventory-for-glpi-metapackage_0.83_1.0-BETA3.tar.gz

For bugs report, use our development forge:
http://forge.fusioninventory.org/projects/fusioninventory-for-glpi

Last thing, NOT USE IT I

Re: Fusioninventory-agent + systemd

Remi Collet — 2012-04-19T12:40:25

Le 18/04/2012 07:47, Remi Collet a écrit :


I renew my request.
I don't want to see this associated to fedora.


_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel< at >lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: Fusioninventory-agent + systemd

Guillaume Rousse — 2012-04-18T07:57:50

Le 18/04/2012 07:47, Remi Collet a écrit :
I didn't removed the environment file definition, it is still present in 
the service, so nothing prevent to pass any arbitrary options, including 
--daemon --no-fork. So I'd rather say the service is usable, just not 
foolproof.

Indeed, as there is few reason to run it as a service without 
daemonizing the agent, this specific option should probably get 
hardcoded. And I guess the --no-fork option should either get hardcoded 
too, or the service type could also get changed to 'fork', to use 
systemd feature rather than agent features.

Re: Fusioninventory-agent + systemd

Remi Collet — 2012-04-18T05:52:39

Le 18/04/2012 07:47, Remi Collet a écrit :


I ever think that the process control options (daemon, no-fork) should
not be available in the agent.cfg.

Remi.


_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel< at >lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: Fusioninventory-agent + systemd

Remi Collet — 2012-04-18T05:47:36

Le 18/04/2012 00:08, Guillaume Rousse a écrit :

Ok, I see this unusable version.

Without the --daemon-no-fork it will not work.
And i really don't think such option are to be set in the agent.cfg


I have always need such an environment file, at least to define the
correct PATH to some "hardware" tools.

Again, I strongly desagree with you.

Options for the service are to be in the service configuration file, not
in the general one.

Options for the cron task are to be in the cron configuration file, not
in the general one.


So please remove this uggly file from contrib, or add a comment about it
"beeing unusable".


Regards,
Remi.



_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel< at >lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: Fusioninventory-agent + systemd

Guillaume Rousse — 2012-04-17T22:08:31

Le 14/04/2012 17:29, Remi Collet a écrit :
Thanks, I just commited a simplified version to contrib directory.

However, there are very few command-line argument that can't be 
specified through the agent configuration file, so using an external 
environment file is mostly useless (and quite confusing for end users).

Re: Software name and arch

Remi Collet — 2012-04-16T07:57:09

Le 15/04/2012 22:16, Guillaume Rousse a écrit :



Ok.

So here is my plan.

Revert this change in the agent, which I still consider as a regression,
and which cause loss of information.

Done :
https://github.com/remicollet/remirepo/commit/0a76528337595eb38d6e92ec3fca6a7d3568fbc4


As soon as the ARCH will be available in the inventory data

=> patch the glpi plugin to do the work (name = name.arch) in all
version <= 0.83 where arch is not managed by GLPI

As soon as GLPI will managed the arch

=> patch the glpi plugin to extract the arch information from the name
when missing (old agent or OCS)


Remi.



_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel< at >lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: Software name and arch

Guillaume Rousse — 2012-04-15T20:16:02

Le 14/04/2012 17:59, Remi Collet a écrit :
Only for rpm, actually, which was main motivation to change this behaviour.

That's a very subjective view. In mixed environment with rpm and non-rpm 
platforms, each software was reported under 3 different identities:
- foo for non-rpm platforms
- foo.i586 for 32bits rpm platforms
- foo.x86_64 for 64bits rpm platforms
And we had to ressort to server-based rules to achieve content 
normalisation. In this regard, I'd rather consider myself the new 
situation an improvement.

That's quite easy to do, and probably the way to go for 2.3.0.

I'd rather avoid reverting to partial and badly-designed behaviour just 
because it's considered useful for some part of the audience (and 
harmful for others). Especially as it is probably as much easy to 
achieve a correct solution within the same time frame.

BTW, there is an (almost) generic workaround to replace any part of the 
inventory not matching your specific needs:
- disable the non-conforming inventory category (--no-ca

Software name and arch

Remi Collet — 2012-04-14T15:59:04

In previous version of the agent, (and in OCS agent)

Software name was  "name.arch"

Starting with version 2.2.0, it's only "name"

I consider this as a regression will make information really difficult
to manage in GLPI in heterogeneous envionment (mixed version / mixed
agent / multi-lib computer)

Currently, with older agent (or ocs agent), I see in my software list
freetype.i6862.4.6-4.fc16
freetype.x86_642.4.6-4.fc16
With agent 2.2.0
freetype2.4.6-4.fc16

OK : using arch in the name is a poor workaround


A better solution will be
- add arch information in the XML
- add arch information in GLPI DB scheme

Another 2 steps solution could be
- add arch information in the XML
- generate "name.arch" in the server side (glpi plugin)


But until this, please consider reverting to the previous behavior.


Remi.

P.S. : GLPI ticket recorded https://forge.indepnet.net/issues/3485

Fusioninventory-agent + systemd

Remi Collet — 2012-04-14T15:29:27

Hi,

Here is a working systemd configuration.

Envirment File
(/etc/sysconfig/fusioninventory-agent ou équivalent)

# Add tools directory if needed (tw_cli, hpacucli, ipssend, ...)
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# Global options (debug for verbose log, rpc-trust-localhost for yum-plugin)
FUSINVOPT="--debug --rpc-trust-localhost"


Systemd Unit file

[Unit]
Description=FusionInventory agent
After=syslog.target network.target

[Service]
EnvironmentFile=/etc/sysconfig/fusioninventory-agent
ExecStart=/usr/bin/fusioninventory-agent $FUSINVOPT
--logfile=/var/log/fusioninventory-agent/service.log --daemon-no-fork

[Install]
WantedBy=multi-user.target



N.B. server, tag, ... could be configured in agent.log or using
FUSINVOPT (I prefer the later), ex:
FUSINVOPT="--debug --rpc-trust-localhost --tag=FUS
--server=http://localhost/glpi/plugins/fusioninventory/"

_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel< at >lists.alioth.debian.org
http://lists.alioth.debia

Re: Confusion between network interfacesandnetwork addresses

Gonéri Le Bouder — 2012-04-07T14:18:10

Hi Stéphane,

Today, an FusionInventory XML is a list of various different data structure:
  -ACCESSLOG
  -ANTIVIRUS
  -BATTERIES
  -BIOS
  -CONTROLLERS
  -CPUS
  -DRIVES
  -ENVS
  -HARDWARE
  -INPUTS
  -LOGICAL_VOLUMES
  -MEMORIES
  -MODEMS
  -MONITORS
  -NETWORKS
  -OPERATINGSYSTEM
  -PHYSICAL_VOLUMES
  -PORTS
  -PRINTERS
  -PROCESSES
  -REGISTRY
  -SLOTS
  -SOFTWARES
  -SOUNDS
  -STORAGES
  -USBDEVICES
  -USERS
  -VIDEOS
  -VIRTUALMACHINES
  -VOLUME_GROUPS

Each data structure has got its own key/value list of parameters. A value is always
a scalar (string). It's never another data structure.

For example:
    <CONTROLLERS>
      <CAPTION>Core Processor Reserved</CAPTION>
      <MANUFACTURER>Intel Corporation</MANUFACTURER>
      <NAME>Core Processor Reserved</NAME>
      <PCICLASS>0600</PCICLASS>
      <PCIID>8086:2d13</PCIID>
      <PCISLOT>ff:02.3</PCISLOT>
      <REV>02</REV>
      <TYPE>Host bridge</TYPE>
    </CONTROLLERS>
    <CPUS>
      <CORE>2</CORE>
      <MANUFACTURER>Intel</MANUFACTURER>

Re: Confusion between network interfaces and network addresses

Gonéri Le Bouder — 2012-04-07T13:20:24

Hi Arnaud,

I agree.
We already do that for ethernet and wifi (NETWORKS/TYPE)
MAC address is an hardware information, much like a serial number whereas
IPv4/6 address network settings.
Yes, in a lot of cases, this information is the sole unique information
between to different computer inventory.

Best regards,
--
     Gonéri

_______________________________________________
Fusioninventory-devel mailing list
Fusioninventory-devel-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB< at >public.gmane.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: Confusion between network interfaces andnetwork addresses

Stéphane Urbanovski — 2012-04-07T07:35:38

Le 05/04/2012 09:42, Guillaume Rousse a écrit :

Hi all

Strategy 6:
(Try to) follow established standards : http://dmtf.org/standards/cim

<LogicalPort> <!-- 
https://www.vmware.com/support/developer/cim-sdk/smash/u4/ga/apirefdoc/CIM_LogicalPort.html 
-->
   <Name>lo</Name>
   <Status>0</Status>
</LogicalPort>

<EthernetPort> <!-- 
https://www.vmware.com/support/developer/cim-sdk/smash/u4/ga/apirefdoc/CIM_EthernetPort.html 
-->
   <Name>eth0</Name>
   <Status>0</Status>
</EthernetPort>

<EthernetPort>
   <Name>eth1</Name>
   <Status>0</Status>
</EthernetPort>

<EthernetPort>
   <Name>eth2</Name>
   <Status>10</Status> <!-- not connected -->
</EthernetPort>

<LogicalPort>
   <Name>bond0</Name>
   <Status>10</Status>
   <_Relations>
     <Slaves>eth0</Slaves> <!-- not a "normalized" relation, may inherit 
from the "depend" relation -->
     <Slaves>eth1</Slaves>
   </_Relations>
</LogicalPort>

<IPProtocolEndpoint> <!-- 
https://www.vmware.com/support/developer/cim-sdk/smash/u4/ga/apirefdoc/CIM_IPProtocolEnd

Re: Confusion between network interfaces and network addresses

Arnaud Quette — 2012-04-06T16:26:53

Hey Fusioners,

2012/4/5 Guillaume Rousse <guillomovitch-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


here is my 2 cents to the discussion (just remember that I'm very new to
FI!):
- I fully agree with the need of enforcing the network strategy.
Network info are the core relationships between devices, and their
accessibility from FI server.
- part of this enforcement, you should ensure that your model is bullet
proof solid for the decade to come.
Thus, it should cover past, current and possible future needs (Ie, be
generic and extensible enough).
This also means that your internal representation can't map 1/1 with OCS
(at least the current model)!
- I would vote for prop. 5, since it's the best one to model multi IP
addresses per interface.
- an adapter to OCS compatible XML should not be that hard, but not
directly bijective.
- having an interface type would be nice (ethernet, wifi, fiber, ...)
- the corollary is an address type (MAC, IP v4 / v6)
- thus, storing the MAC address also makes senses.

cheers,
Arn

Re: Confusion between network interfaces and network addresses

Guillaume Rousse — 2012-04-05T18:17:37

Le 05/04/2012 20:04, Guillaume Rousse a écrit :
I just found out I was wrong, as ip_addr-2 sample shows an interface 
with two different IPv4 addresses:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     link/ether 0f:0f:0f:0f:0f:0f brd ff:ff:ff:ff:ff:ff
     inet 11.11.11.11/25 brd 11.11.11.127 scope global eth0
     inet 172.16.0.201/17 brd 172.16.127.255 scope global eth0

Let's forget my last proposition then :(

Re: Confusion between network interfaces and network addresses

Guillaume Rousse — 2012-04-05T18:04:07

Le 05/04/2012 10:56, Gonéri Le Bouder a écrit :
I missed the fact that actually, only IPv6 is concerned with multiple 
addresses with the same interface names (multiple IPv4 ones usually use 
different interfaces aliases), and only for different classes of 
addresses (link vs global).

Given than they are different attributes for IPv6 and IPv4 addresses, 
and given there is no formal description of how the OCS server handle 
the result, I'd say than only reporting the global IPv6 addresses (the 
routable ones) would allow to keep strict relationship between network 
entries and network addresses.

Given the following scenario:
- active eth0 interface, with
  * IPv4 address A
  * global IPv6 address AAAA
  * local IPv6 address BBBB
- unactive eth1 interface

This would result into the following structure:
{
   description => 'eth0',
   status      => 'up',
   ipaddress   => 'A',
   ipmask      => 'a',
   ipaddress6  => 'AAAA',
   ipmask6     => 'aaaa',
},
{
   description => 'eth1',
   status      => 'down'

Re: Confusion between network interfaces and network addresses

Gonéri Le Bouder — 2012-04-05T08:56:43

Hello all,



OCS uses the second solution, and we are supposed to follow this structure for
the moment.
This is design problem with IPv6, since it's now common to see one
interface with
various IPv6 configuration.

My point of view:
We can continue with this 2nd solution and maybe fix some implementation and
add two new sections:
  -NET_IFS (the network interface)
  -NET_ADDRS (the network interface settings + the NETINFS/NAME)

3.0 agent branch will have a JSON output, we can use this structure
transition to drop
what will be at this time the legacy NETWORKS section.

Best regards,

Confusion between network interfaces andnetwork addresses

Guillaume Rousse — 2012-04-05T07:42:32

While reviewing yesterday changes from Goneri, I found there was some 
confusion in our code between two different concepts: network interfaces 
and network addresses. Worse, we are not even consistent among the 
various OS, most notably between Linux and Windows.

Let's consider a machine with two interfaces, one active with two 
attached addresses, and one inactive.

Strategy 1:
In Windows code, as seen in the t/inventory/windows/networks.t expected 
results, a 'networks' entry is strictly a network interface. The example 
scenario would result into the following internal representation:
{
   description => 'foo',
   ipaddress => [ '127.0.0.1', '127.0.0.2' ],
   ipmask    => [ '255.0.0.0', '255.0.0.0' ]
},
{
   description => 'bar',
   status => 'down'
}
Which translates into the following XML result with multiple elements of 
the same name:
<NETWORKS>
   <DESCRIPTION>foo</DESCRIPTION>
   <IPADDRESS>127.0.0.1</IPADDRESS>
   <IPADDRESS>127.0.0.2</IPADDRESS>
   <IPMASK>255.0.0.0</IPMASK>
   <IPMASK>255.0.0.0

Re: New module for virt-top

DuyLong — 2012-04-02T10:19:58

Yes, except "Total CPU, RAM availables" and "Historical %CPU", these 
informations must be in the physical machine.


I can help you for KVM system (Xen too)


I agree, but the free space (CPU, RAM...) is a inventory data too.


It's a good thing ;-)

Best regards,
--
Duy Long LE
University of Strasbourg