You are not logged in.
Interesting new wrinkle. I have a new iMac, C2D, running Leopard (10.5.2, Build 9C7010), and here's what I get when I try to execute manually:
Notice: Undefined property: OCS_MacAgent::$_getName in /usr/local/sbin/ocs_mac_agent.php on line 326
SystemFlippers: didn't consume all data for vers ID 1 (pBase = 0x2f457b0, p = 0x2f457d9, pEnd = 0x2f457f5)
SystemFlippers: didn't consume all data for vers ID 1 (pBase = 0x2f5a8f0, p = 0x2f5a902, pEnd = 0x2f5a903)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">...
Note, particularly, lines 2 and 3 in that readout. Those I hadn't seen before. When the process runs at reboot, I get:
[ INFO ] OCS Mac Agent started at Thu, 17 Apr 2008 10:51:58 -0500
[ INFO ] No new update needed for this agent
[ INFO ] Starting inventory of COMPUTERNAME
[ ERROR ] Could not find SPApplicationsDataType in system_profiler XML. Corrupted output?
This is just getting weird, now.
Offline
Great work gebura! I am glad to see that there is progress being made with this error. Unfortunately for me, however, this is still not working on an OS X.4.x server. I am getting the same error: "Cannot transmit inventory. Response Code: 500"
Hi All!
Seams like I found the problem. On different Mac OS releases system_profiler report CPUs number by two different way. First one is:
<key>number_processors</key>
<integer>2</integer>
(implemented in ocs_mac_agent.php)
Second:
<key>number_cpus</key>
<integer>1</integer>
In that case ocs_mac_agent assign the value "N/A" to the output PROCESSORN property
<PROCESSORN>N/A</PROCESSORN>
When ocs server receive output from agent it try to insert value "N" in number-only field in mysql table and apache generate error 500
I change the line #834 in ocs_mac_agent.php from:
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_processors', $s_node, 'integer');
to
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_cpus', $s_node, 'integer');
and it work now. However this is not clear fix.
Last edited by Iskander (2008-04-23 10:41:42)
Offline
I change the line #834 in ocs_mac_agent.php from:
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_processors', $s_node, 'integer');
to
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_cpus', $s_node, 'integer');and it work now. However this is not clear fix.
Brilliant!
Finally it worked for me on a Leopard server after looking for solutions over a month.
Now I'll keep two versions of the ocs_mac_agent.php until next version. One (the original) that worked for both Tiger server and client. and the revised version for Leopard (except I have to test it on a Leopard client tomorrow).
Result from my Leopard client test:
Tried to run script from my Leopard client on a old G4 iMac with 10.5.2. I did get "SPApplicationsDataType" error. Following suggestions from couple threads mentioning this bug, I removed some apps from Application folder, mainly freeware from a "Local" folder inside. The script finished successfully.
So there are at least two bugs in current version of the script. One is the definition change of the number of processors. Since Leopard using a different keyword "cpus", the null entry probably annoyed the input processing code in OCS server.
Secondly, under Leopard the script try to find more apps under different folders, like Core thing under Library. Total number of apps are far exceeding what defined limit in the script. Under this theory, if you have tons of apps install in Applications folder under Tiger, you would get the same error.
Last edited by khorazm (2008-05-02 00:41:58)
Offline
Hi guys,
I, too, am getting the "Response Code: 500" error, but only on some of my Macs. I've tried the "number_processors" -> "number_cpus" suggestion but that didn't work.
Here's a rundown of my situation:
Hostname Type Processor OS Result of OCS agent install
---------------------------------------------------------------------------------------------------
Herzog G5 PPC 10.4.11 OK
Einstein iMac Core2Duo 10.4.11 OK
Cavendish iMac Core2Duo 10.4.11 OK
Copernicus iMac Core2Duo 10.4.11 OK
Octavo iMac Core2Duo 10.5.2 Error - "Response Code: 500"
iMac2 iMac Core2Duo 10.5.2 Error - "Response Code: 500"
iMac3 iMac Core2Duo 10.5.2 Error - "Response Code: 500"
MacTop MacBook Pro Core2Duo 10.5.2 Error - "Response Code: 500"
MacTop2 MacBook Pro Core2Duo 10.5.2 Error - "Response Code: 500"
So, as you can see, there's a clear distinction: the agent works great on 10.4.11 but fails on every Mac running 10.5.2.
The homepage for the Mac agent says that it runs on 10.5, but I'm wondering if it's only been fully tested on PPC Macs running 10.5 or, more likely, it worked on 10.5.0 and Apple changed something either in 10.5.1 or 10.5.2 that breaks it.
If anyone has any other suggestions on what I can try I'd really appreciate it!
hux
Last edited by hux (2008-05-09 18:35:46)
Offline
There are two other fixes that have been found. One is removing some of your applications out of your applications folder. There seems to be a limit of how many applications the script will report. The other fix is to make sure that all the apps have been opened. If you notice in 10.5, instead of Safari warning you when you click to download an app that it might be malicious, it gives you the warning when you go to open it for the first time instead. They are embedding metadata into the app that says that this app has not yet been approved. This seems to prevent the script from talking to it in a way. Try those and let us know.
Offline
That makes sense because I just did another install of the agent today on a 10.5 iMac and, unlike the rest, that one is reporting just fine, so the problem definitely isn't as simple as "it doesn't work on 10.5".
I'll try out both those things you mentioned and report back.
Offline
Following on from the above, I tried the following:
- Ensured that every app in "Applications" had been opened at least once
- Moved everything out of "Applications" into a different folder
- Moved everything back, then renamed "Applications" to something else
After each of the above I ran the agent, but each time it failed with the same 500 error code. Based on this, it would seem that neither of the two possible problems mentioned above (too many items in "Applications"; items in Applications that were downloaded but never opened) is causing the problem.
So, what can we try next?
Offline
Hello, i am having the same issue on Leopard on a G4 proc, where is does not update at all, have tried on an intel quad mac, and updates automatically, but not by a manual run.
I have only get the Response Code Error 500, but not the SPApplicationDataType or anything like that, even so i made the proc to cpu change in the php script and still no difference. I doubt it has anything to do with the Apps folder, since it works on the intel and not on the G.
Any insite or updates on getting this to work on OSX 5 on a PPC proc (G's)?
Offline
Got it working (somehow) on 10.5.3 with a G4 proc, bt only updates on cabled (non airport) connection.
Will post again if i figure out what changed
It only transfers when connected over a wired connection, not over Airport (Wireless)
Last edited by jimsmithkka (2008-06-25 14:35:21)
Offline
I change the line #834 in ocs_mac_agent.php from:
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_processors', $s_node, 'integer');
to
$this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_cpus', $s_node, 'integer');and it work now. However this is not clear fix.
I found the same thing Iskander noticed. I handled it by adding new lines 835-837:
834: $this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_processors', $s_node, 'integer');
835: if($this->_data['CONTENT']['HARDWARE']['PROCESSORN'] == "N/A") {
836: $this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_cpus', $s_node, 'integer');
837: }
838: $this->_data['CONTENT']['HARDWARE']['MEMORY'] = $this->_toMB($this->_getValByKey('physical_memory', $s_node));
This way if there is no number_processors value and _getValByKey returns "N/A" it will check number_cpus instead.
I dug through a number of system_profiler reports and found that 10.3PPC, 10.4Intel, 10.4PPC and 10.5Intel all have number_processors. However, 10.5PPC has number_cpus. Why? No idea. But I modified the code so that it will work on either kind of hardware.
I also sent a patch with these changes to Jason; it may be fixed in the next release.
I've got to hand it to Jason - this Agent is incredibly helpful! I'm so glad I didn't have to try and write one myself. The OCSNG Mac Agent even help me recover a stolen laptop by reporting in from the thief's home!
jd
Offline
Has any one come up with a root cause for this? I have several that are coming up the the error 500 and as of yet have not been able to track down why.
Offline
I found the same thing Iskander noticed. I handled it by adding new lines 835-837:
834: $this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_processors', $s_node, 'integer');
835: if($this->_data['CONTENT']['HARDWARE']['PROCESSORN'] == "N/A") {
836: $this->_data['CONTENT']['HARDWARE']['PROCESSORN'] = $this->_getValByKey('number_cpus', $s_node, 'integer');
837: }
838: $this->_data['CONTENT']['HARDWARE']['MEMORY'] = $this->_toMB($this->_getValByKey('physical_memory', $s_node));
You are a genius, nicely done (You too Iskander).. works perfectly now. It makes sense, I track an aweful lot of machiens with this, mainly Windows and Linux and they were never an issue but certain (I'd say 5%) ones were causing
DBD::mysql::db do failed: Unknown column 'N' in 'field list' at /usr/local/share/perl/5.8.8/Apache/Ocsinventory/Server/Inventory.pm line 167.
In my apache logs... it's obvious now what the N was, start of the N/A
Have you heard any word from Jason, he's not updated it in a while and it'd certainly be easier if he rolled out another than having to manually drop my own one in.
Offline
Hello,
We have also the 500 error message.
Sometimes doing "ssh localhost" solve this, but not every time.
When we create a launchdaemon starting "ocs_mac_agent" at startup or a given time,
as root it always work perfectly.
You can create the launchdaemon with Lingon (with Lingon : http://lingon.sourceforge.net/ )
or putting the appropriate .plist file in /Library/LaunchDaemons
Offline
Ah hah! Another error 500 fix. I did a search on 500 errors and ended up at this post in 'Forums index » OCS Inventory NG Server for Unix'. This post talked about how error 500 is actually a server issue, not a client issue. If you look in apache error log of your ocs server, you might see a line like this:
[Thu Sep 11 10:28:16 2008] [error] [client 172.18.7.181] Failed to open log file : Permission denied ()\n
I have our OCS server running on a SUSE server so I found the error_log in /var/log/apache2. It was riddled with this error since we had set it up. The next step was to find the ocsinventory-server and the ocsinventory-NG log folders and make sure that the apache user could edit them. The post says to set the permissions to 664 and the owner/group to apache, but our server was setup strangely. Our apache user was actually root and had to give everyone read write and execute (777). After I did this, we haven't come across the 500 error...so far
. Our log file had at least 6 'Failed to open log file' errors almost every hour and now we don't see it. Hopefully this will be the final nail in the 500 error issue.
Offline
I don't know where to start, first off you *really* shouldn't run apache as root, secondly a log file never needs to have execute permissions, so 666 permisison at the least, but none but apache should writing to it anyway, and if apache is running as root 644 should be fine. I tihnk your error is coming from somewhere else Jason. You should really look into changing apache to the suse user it should run under.
At 777 someone could edit it as a user and put malicious code in there. If you accidentaly "run" your logfile it'll be able to do some serious if not annoying dmagae to your system. I could just echo rm -rf ~/ into the logfile and you as a normal user running the logfile would wipe out your home directory !
Offline
We will be looking into that. I just wanted to see if this lead anyone to the error 500 fix.
Offline
Hmm. I switched the permissions to those folders to 666 instead of 777 and immediately started to get error 500 again. Why would this process need execute to log folders? We hadn't had a failure since I had set it to 777 and it immediately came back when it got turned off. I completely understand why having this set to execute is bad but why would it affect the communication?
Edit: 775 seems to also work fine.
Edit: scratch that, 774 did not work. Trying 755.
Last edited by jasonlund (2008-09-11 20:57:06)
Offline
Hey Jason,
Hang on are you talking about the log or the folder/directory to the log ? All directories need to have execute enabled, most will be set to 755, which is in general the correct mode, that is read, write and execute mode for the owner while only read and execute for everyone else. The execute mode allows you to "Run" the directory to go into it as such..
The logfile itself should be 644, maybe this is where you are getting mixed up. A log file itself should never have execute permission but a directory always does.
Last edited by felimwhiteley (2008-09-12 09:05:08)
Offline
It was my log folders that were set with no executables. We didn't touch any of the folders permissions after installing OCS back in the spring and when I followed the post above, I had found those folders (/var/log/ocsinventory-NG, /var/log/ocsinventory-client and /var/log/ocsinventory-server)set as 644 with no log files in them at all. That's when I started to play with permissions to see if I could get the error to go away. Sorry that I did not make myself clear on what I was modifying. I now have set the folders to 755 and have not received either an error 500 on my client nor any further 'Failed to open log file' errors in my apache error_log. I just wanted to bring this up to everyone to check the permissions on these folders (755) and log files (644) since it is a known issue with error 500 responses.
Offline
We are getting a large number of MACs that report error 500's. These are new installs running the latest version 4.4
In going though the Apache access log we have a high number of error 500's and they are all Mac clients runing V12 (4.4).
The workstation log reports the following:
[ INFO ] OCS Mac agent started at Mon. 05 Jan 2009 21:43:52 -0808
[ INFO ] No new update needed for this agent
[ INFO ] Starting inventory of mac82162
[ INFO ] Cannot transmit inventory. Response code: 500
The Apache Server access log will report:
72.233.228.138 - - [27/Jan/2009:15:06:51 -0800] "POST /ocsinventory HTTP/1.1" 500 1045 "-" "OCS-NG_mac_client_v12"
I also notice in the server log that the log prior to the error 500 there are 3 lines:
72.233.228.138 - - [27/Jan/2009:15:05:30 -0800] "POST /ocsinventory HTTP/1.1" 200 88 "-" "OCS-NG_mac_client_v12"
72.233.228.138 - - [27/Jan/2009:15:05:30 -0800] "POST /ocsinventory HTTP/1.1" 200 88 "-" "OCS-NG_mac_client_v12"
72.233.228.138 - - [27/Jan/2009:15:05:30 -0800] "POST /ocsinventory HTTP/1.1" 200 351 "-" "OCS-NG_mac_client_v12"
72.233.228.138 - - [27/Jan/2009:15:05:30 -0800] "POST /ocsinventory HTTP/1.1" 200 351 "-" "OCS-NG_mac_client_v12"
That give the impression that things were ok. What is being reported for "1045" that returns the 500 error?
The problem only occurs on our MAC clients as PC do not have the problem. Some MAC OS 10.5.6 work ok and others do not.
Would this also be part of the reason that MAC clients do not report the correct hostname or do not report a new host/computer name after the name has been changed.
Thank you.
Offline
I am getting response code 500 on most of my non Intel Macs:
[ INFO ] OCS Mac Agent started at Fri, 08 May 2009 08:48:52 -0700
[ INFO ] No new update needed for this agent
[ INFO ] Starting inventory of Music 213-04
[ ERROR ] Cannot transmit inventory. Response Code: 500
We have use STH's patches and other patches mentioned in these threads to fix the SpApplication error but I am not sure why I am getting the error 500 and it is on most of my non Intel Macs running OS 10.5
Thank you.
Offline
@Southerner
What is the activity log of the server. The 500 is a server error code that it does not understand the file transmitted. Start monitoring the server log
tail -50f /var/log/ocsinventory-server/activity.log
and then ask the client Music 213-0 to update manually. Or you can go back and check the log for that ID. I am not sure what happens if the machine ID has a space in it. That may throw one of the scripts out of kilter.
Offline
I have many computers named like that so OCS does not have a problem with a space being in the name. I have many Intel Macs that have this same build installed on them and they have no problem but these Motorola Macs do and I am not sure why. I have at least 50 computers with this problem and all are non Intel Macs. Some of them are named MAC##### where # is a number so most are named MAC82123 or similar.
Thank you.
Offline
And then what does the server activity log show? That should list the problem. 500 is a very generic error. The client is connecting to the server, but the server thinks that the sent inventory is incorrect and corrupted for some reason. The server should itemize at least what part of the inventory it is having problems with.
Offline
The OCSinventory-NG.log will show:
Tue May 26 10:50:20 2009;104;Music 213-06-2009-05-04-09-15-05;72.233.228.88;OCS-NG_mac_client_v12;inventory;Incoming
Tue May 26 10:50:20 2009;515;Music 213-06-2009-05-04-09-15-05;72.233.228.88;OCS-NG_mac_client_v12;end;Processing error
The Access.log will show:
72.233.228.88 - - [26/May/2009:10:50:20 -0700] "POST /ocsinventory HTTP/1.1" 500 1175
and Error.log will have no entry for that machine.
These were the log files on the Windows 2008 server in C:\Program Files\OCS Inventory NG\XAMPP\apache\logs directory.
I have a large number of MACs that have the client loaded but do not report or may report once and never again. They are running version 4.4 with your patches incorporated.
Offline