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
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
