|
|
Line 1: |
Line 1: |
| see history for old info ! | | 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
| |
| ---- | | ---- |
| | | |
Line 23: |
Line 6: |
| | | |
| Your comments are on my todo's list ;-) | | Your comments are on my todo's list ;-) |
− |
| |
| | | |
| Can you confirm that ipdiscover works on your install? | | Can you confirm that ipdiscover works on your install? |
Line 43: |
Line 25: |
| Cool34000 | | Cool34000 |
| ---- | | ---- |
− | looks to be working here also, maybe it was operator error ? | + | ipdiscover looks to be working here also, maybe it was operator error ? |
− | [root@kiwi more]# ipdiscover eth0 10
| |
− | <IPDISCOVER>
| |
− | <H><I>192.168.35.2</I><M>00:0b:ad:a0:0a:2d</M><N>pc-00002.dom.net</N></H>
| |
− | <H><I>192.168.35.3</I><M>00:0d:88:44:fc:fd</M><N>ap.dom.net</N></H>
| |
− | <H><I>192.168.35.233</I><M>00:0f:20:fd:e1:e7</M><N>pc-00233.dom.net</N></H>
| |
− | <H><I>192.168.35.242</I><M>00:0e:08:da:e7:e1</M><N>pc-00242.dom.net</N></H>
| |
− | </IPDISCOVER>
| |
| | | |
− | prompt client to call home
| + | Draft steps for deployment |
− | ocsinventory-client.pl -debug
| |
| | | |
− | DOWNLOAD: <?xml version='1.0' encoding='ISO-8859-1'?> | + | Installed a cacert certificate eg. http://wiki.contribs.org/Custom_CA_Certificate |
− | <REPLY>
| + | copy the domain.crt from cacert to cacert.pem in the client ocs folder |
− | <OPTION>
| + | (this is the public key right ??) |
− | <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 [http://perl-xml.sourceforge.net/faq/#parserdetails.ini 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
| + | deploying => Activate => activate package |
| + | complains that the directory and info files don't exist, |
| + | I think we should just ignore the activate error, the files are visible from clients |
| | | |
− | maybe i have a SSL error, or maybe i have to wait, but PC's are going off now
| + | deployed a file, optional, run a client update and it is now aware of the update |
| | | |
| + | in => Package activation |
| + | when you delete a package, ocs complains, but it deletes the files anyway, document later |
| + | ERROR: Can't delete directory /opt/inventory/ocs/download/1194356189 |
| stephen | | 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
| |
− | ----
| |
− | New RPM built
| |
− |
| |
− | Changelog:
| |
− |
| |
− | => perl-XML-SAX dependency added
| |
− |
| |
− | => ParserDetails.ini generated if not exist (using the above code). By the way, I installed a SME 7.1 test server and this file was present... I will raise a bug at contribs ASAP.
| |
− |
| |
− | => Account ''download'' created with ''url'' as type
| |
− |
| |
− |
| |
− | I've also added a quick fix in the article for SME 7.1 (it may not be needed on other 7.1.x versions, can't test this!)
| |
− |
| |
− | I was getting random deflate errors and 500 errors. Updating perl-Compress-Zlib fixed my problem on this 7.1 non-updated SME Server.
| |
− |
| |
− | [http://bugs.contribs.org/show_bug.cgi?id=3525 I've raised a bug at contribs.org] about ParserDetails.ini
| |
− |
| |
− |
| |
− | Cool34000
| |
| ---- | | ---- |
see history for old info !
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
ipdiscover looks to be working here also, maybe it was operator error ?
Draft steps for deployment
Installed a cacert certificate eg. http://wiki.contribs.org/Custom_CA_Certificate
copy the domain.crt from cacert to cacert.pem in the client ocs folder
(this is the public key right ??)
deploying => Activate => activate package
complains that the directory and info files don't exist,
I think we should just ignore the activate error, the files are visible from clients
deployed a file, optional, run a client update and it is now aware of the update
in => Package activation
when you delete a package, ocs complains, but it deletes the files anyway, document later
ERROR: Can't delete directory /opt/inventory/ocs/download/1194356189
stephen