Well now that the school season has started up sucessfully I can revisit this issue… If I were more WAMP savvy I think I may have solved this problem already. I agree with you it does appear to be stripping the data, but only from the library directory. I feel as though that WAMP must have permission to the folder becuase uploading to the CMS sends complete files. But when the client attempts to GET the files, nothing is transmitted. Could the following be in any way related? ; Whether PHP will read the POST data.
; This option is enabled by default.
; Most likely, you won’t want to disable this option globally. It causes $_POST
; and $_FILES to always be empty; the only way you will be able to read the
; POST data will be through the php://input stream wrapper. This can be useful
; to proxy requests or to process the POST data in a memory efficient fashion.
; http://php.net/enable-post-data-reading
;enable_post_data_reading = Off
It is my assumption that this is the request from a client to download some media from the CMS. I also assumed that the file in the request is some MD5 hash of the file name. So I tried to find that hash in the xibo database but did not find any matches. Could this be the root cause of my issue? Is there anything else I can provide to help figure this out?
It does appear to be a problem is the MD5. The client is requesting an MD5 that does not exist in the sql database, Do any of you have any idea why this would be? Below is an error log snippet from a client. FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread alive and Lock Obtained
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread Started
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread alive and Lock Obtained
RequiredFilesAgentThread|10/3/2016 4:16:47 PM|Info|RequiredFiles - ReportInventory|Reporting Inventory FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Error|FileAgent - Run|Downloaded file failed MD5 check. Calculated [d41d8cd98f00b204e9800998ecf8427e] & XMDS [ 3e5ce4cb098ca820c7d49814f87c17e8] . 37.mp4
FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Releasing Lock
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|File Downloaded Successfully. 14.xlf
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|Schedule - LayoutFileModified|Layout file changed: 14.xlf
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Releasing Lock
Are you connecting to the cms with https? Or a proxy? I am wondering if deep packet inspection on a firewall is not the problem. If it is turned on I think that would cause the MD5 check to fail.
There are no firewalls between my client and the CMS, all are running on the same campus network. Windows firewall is disabled for all domain computers. There are no proxies involved either. When I log into the CMS to manage it everything is done in HTTP. I do not know how to see if the clients are using HTTPS. My assumption is that they are not.
How does the client determine what hash is used for the GET request?
I, unfortunitaly do not know. @Dan, might be able to shed light on that part. But I think they are not matching because the file is not getting written to the client so the hashes will not match.
Also I should of read your posted log better. I see that the clients are talkng to the CMS via http.
Would it be possible to connect a client to the CMS server direct with a unmanaged switch or hub, and both machine having all other network connections turned off? This was we can rule out network security as far as devices.
In the CMS settings there is an option for “File Download Mode” - I would imagine you have that set to either Apache or Nginx ?
In either of those cases Xibo will offload the file downloading directly to the web server, rather than using the SOAP service to download the file. This requires the sendfile module to be configured on the web server such that the X-Sendfile or X-Accel headers are obeyed (causing the web server to get the file directly without involving PHP - better for performance).
Setting this to Off will revert to the SOAP service.
Configuring sendfile on Apache is fairly straight forward:
a2enmod xsendfile
Config file
XSendFile on
XSendFilePath <your library location>
The CMS was set to Apache. I switched it to OFF, as a test. There seems to be updating and file transfers now, but they are painfully slow, to the point of hours to get a 35MB video file downloaded and not all the clients completed getting the new content. This is far too slow and unreliable for our pursposes. So I would like to go back to the Apache method of file copies.
I’ve tried to confirm the settings in the webserver but I’m not a web admin/developer by trade. I do know enough to be dangerous and I can follow directions. It is my assumption that your code snippets are from the httpd.conf file. If not please let me know where to look for these settings. Unfortunately, my httpd.conf has nothing like the lines you provided. The only thing I found that was remotely similar is below:
#
# EnableMMAP and EnableSendfile: On systems that support it,
# memory-mapping or the sendfile syscall may be used to deliver
# files. This usually improves server performance, but must
# be turned off when serving from networked-mounted
# filesystems or if support for these functions is otherwise
# broken on your system.
# Defaults: EnableMMAP On, EnableSendfile Off
#
EnableMMAP off
EnableSendfile off
As always, thank you for your time, and let me know if I can provide any additional detail.
To the best of my ability, it appears that my version of WAMP (3.0.0) does not support the XSendFile module. I have looked for a version of the module that matches my Apache version (2.4.17) but to no avail. It so appears that I will have to, at the very least, update my Apache to the latest build (2.4.23) and then confirm that the XSendFile module is installed and configured. This is not something that I have done before, especially in regards to Xibo (my predecessor did the present installation). What can I expect in the way of pitfalls or caveats? Any advise or encouragement will be appreciated.
I have updated the Apache binary in WAMP to 2.4.23 and followed the instructions for installing the XSendFile module. I set the CMS File Download Mode back to Apache, but still no joy. The client will receive the layouts but none of the media. I have even removed and re-installed the client in an attempt to get them talking to each other. I’m getting pretty frustrated with myself and the software.
What would happen if I mapped a windows network drive on the client machine to the CMS library location and set that as my “local” library?
Progress, sort of. I can certainly say that the XSendFile module is loaded. See Below:
[Tue Oct 25 14:25:01.795057 2016] [:error] [pid 7188:tid 872] (20023)The given path was above the root path: [client 10.200.240.82:49964] xsendfile: unable to find file: c:\XiboData\jquery-1.11.1.min.js
[Tue Oct 25 14:25:01.826306 2016] [:error] [pid 7188:tid 864] (20023)The given path was above the root path: [client 10.200.240.82:49965] xsendfile: unable to find file: c:\XiboData\xibo-layout-scaler.js
[Tue Oct 25 14:25:01.966927 2016] [:error] [pid 7188:tid 872] (20023)The given path was above the root path: [client 10.200.240.82:49964] xsendfile: unable to find file: c:\XiboData\xibo-webpage-render.js
[Tue Oct 25 14:25:01.982551 2016] [:error] [pid 7188:tid 864] (20023)The given path was above the root path: [client 10.200.240.82:49965] xsendfile: unable to find file: c:\XiboData\moment.js
[Tue Oct 25 14:25:02.138796 2016] [:error] [pid 7188:tid 872] (20023)The given path was above the root path: [client 10.200.240.82:49964] xsendfile: unable to find file: c:\XiboData\xibo-text-render.js
[Tue Oct 25 14:25:02.232543 2016] [:error] [pid 7188:tid 864] (20023)The given path was above the root path: [client 10.200.240.82:49965] xsendfile: unable to find file: c:\XiboData\jquery.marquee.min.js
[Tue Oct 25 14:25:02.295041 2016] [:error] [pid 7188:tid 872] (20023)The given path was above the root path: [client 10.200.240.82:49964] xsendfile: unable to find file: c:\XiboData\flipclock.min.js
With that said, you see my current dilemma. I tried to change the library location both in the httpd.conf file and in the CMS to the root of the Apache www directory (c:\wamp64\www\XiboData) and restarted all the services, but the error log still states the above. Is there somewhere else I need to change this info?
Hey everybody! I fixed it. I’m not sure how or why it took so long for me to figure it out, but I learned a lot. Thanks for the ideas and troubleshooting @dan@Peter and @cslaughter it was appreciated.
Just for posterity, the final step was to make sure that my library was physically located within the same directory as the CMS. In my case this was (C:/wamp64/www/Xibo/XiboData). With Xibo being the CMS directory and XiboData being my Library directory. Now XSendFile can find and transmit the media files and do it quickly. I can delete the local library (on the client) and be back to fully functional in less than 5 minutes.