Talk:OCS Inventory Tools

see history for old info !

rpm -3 installs fine, deploy=>builds ok, /downloads is accessible

a minor point, I suggest you add /downloads to accounts db as a url next rpm

deploying =>

I think we should just ignore the activate error, the files are visible from clients

i installed a cacert certificate as per the contribs howto,

copied the domain.crt to cacert.pem in the client ocs folder

deployed a file, run a client update and it is now aware of the update, so we now wait

impatient people see http://forums.ocsinventory-ng.org/viewtopic.php?id=1079

stephen

---

Thanks for cleaning this up!

Your comments are on my todo's list ;-)

Can you confirm that ipdiscover works on your install?

As I used 3 PCs to get ipdiscover info, I didn't test only with SME enabled.

Try the following:

ipdiscover eth0 10

	Note:
	Usage : ipdiscover [iface name] [latency in ms]

Here's what I got on my server:

<IPDISCOVER>
<H>192.168.0.100<M>00:xx:xx:xx:xx:xx</M><N>pc-00100.mydomain.com</N></H>
<H>192.168.0.253<M>00:xx:xx:xx:xx:xx</M><N>pc-00253.mydomain.com</N></H>
<H>192.168.0.254<M>00:xx:xx:xx:xx:xx</M><N>pc-00254.mydomain.com</N></H>
</IPDISCOVER>

Sounds like it's working for me...

Cool34000

---

looks to be working here also, maybe it was operator error ?

[root@kiwi more]# ipdiscover eth0 10
<IPDISCOVER>
<H>192.168.35.2<M>00:0b:ad:a0:0a:2d</M><N>pc-00002.dom.net</N></H>
<H>192.168.35.3<M>00:0d:88:44:fc:fd</M><N>ap.dom.net</N></H>
<H>192.168.35.233<M>00:0f:20:fd:e1:e7</M><N>pc-00233.dom.net</N></H>
<H>192.168.35.242<M>00:0e:08:da:e7:e1</M><N>pc-00242.dom.net</N></H>
</IPDISCOVER>

prompt client to call home

ocsinventory-client.pl -debug 

DOWNLOAD: <?xml version='1.0' encoding='ISO-8859-1'?>
<REPLY>
 <OPTION>
   <NAME>IPDISCOVER</NAME>
   <PARAM IPDISC_LAT="100">192.168.35.0</PARAM>
 </OPTION>
 <OPTION>
   <NAME>DOWNLOAD</NAME>
   <PARAM FRAG_LATENCY="10" PERIOD_LATENCY="0" TIMEOUT="30" ON="1" TYPE="CONF" CYCLE_LATENCY="60" PERIOD_LENGTH="10" />
   <PARAM ID="1194355263" CERT_PATH="INSTALL_PATH" PACK_LOC="2321.net/download" CERT_FILE="INSTALL_PATH/cacert.pem" TYPE="PACK" NFO_LOC="2321.net/download" />
   <PARAM ID="1194356189" CERT_PATH="INSTALL_PATH" PACK_LOC="2321.net/download" CERT_FILE="INSTALL_PATH/cacert.pem" TYPE="PACK" INFO_LOC="2321.net/download" />
 </OPTION>
 <RESPONSE>SEND</RESPONSE>
 <PROLOG_FREQ>24</PROLOG_FREQ>
</REPLY>

DOWNLOAD: Writing config file.
DOWNLOAD: Retrieving info file for 1194355263
DOWNLOAD: Initialize ssl layer...
DOWNLOAD: Connect to server: 2321.net/download...
DOWNLOAD: Starting SSL connection...
28948: callback: ssl connect!

deploy stalls, with this error/warning on server

# tail  /var/log/httpd/error_log 
could not find ParserDetails.ini in /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX

hide warning ? with
touch /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini

still waiting...

stephen

---

I found this link We need to build this file!

touch /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini
perl -MXML::SAX -e "XML::SAX->add_parser(q(XML::SAX::PurePerl))->save_parsers()"
chmod 0444 /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini

Here's the content of generated file:

[XML::SAX::PurePerl]
http://xml.org/sax/features/namespaces = 1

No more warning! :-D

That's strange, this RPM (XML::SAX) comes from smeupdates. Shouldn't it create this file on its own?

Cool34000

---

goodwork, do we notify the upstream rpm packager, or just add it to your rpm for now

maybe i have a SSL error, or maybe i have to wait, but PC's are going off now

stephen

---

I can add a test in the RPM install as described in the doc. But we should raise a bug I think.

I will also add dependency perl-XML-SAX to the list.

This code should do the job in the RPM install:

if [ ! -e   /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini ]; then
  touch     /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini
  chmod 444 /usr/lib/perl5/vendor_perl/5.8.5/XML/SAX/ParserDetails.ini
  perl -MXML::SAX -e "XML::SAX->add_parser(q(XML::SAX::PurePerl))->save_parsers()"
fi 

This is enough for our needs right now but if it's a bug, we should raise it. As this test check if the file exists, it will never overwrite so after an hypotetical update of the upstream package the test is still safe to use...

The good question is where should we raise this bug! SME bugtracker??

My understanding of the doc is yes, maybe ask for a NFR smeserver-perl-xml-sax-x.x-x or fix the existing SRPM in smeupdates?

Or rebuild the original package? I think no, because the doc says that the RPM should be adapted for other RPM based distros... But I'm no expert!

What do you think? You're the pro! ;-)

Cool34000

---