Hello,
I’m building a new kaltura cluster with RPM. I’ve built the first Front End and am running kaltura-db-config.sh. It gets to insertContent.php, then the following error is logged in the console.
> Connectivity test passed:)
Cleaning cache..
Populating DB with data.. please wait..
Output for /opt/kaltura/app/deployment/base/scripts/installPlugins.php being logged into /opt/kaltura/log/installPlugins.log
Output for /opt/kaltura/app/deployment/base/scripts/insertDefaults.php being logged into /opt/kaltura/log/insertDefaults.log
Output for /opt/kaltura/app/deployment/base/scripts/insertPermissions.php being logged into /opt/kaltura/log/insertPermissions.log
Output for /opt/kaltura/app/deployment/base/scripts/insertContent.php being logged into /opt/kaltura/log/insertContent.log
the insertcontent.log file has these lines at the end of the file…
Executing failed for request #7 with error [The uploaded file was not found by the given token id, or was already used]
PHP Fatal error: Uncaught exception ‘KalturaException’ with message ‘The uploaded file was not found by the given token id, or was already used’ in /opt/kaltura/app/tests/standAloneClient/exec.php:351
Stack trace: #0 {main}
thrown in /opt/kaltura/app/tests/standAloneClient/exec.php on line 351
I can’t seem to figure out what the problem is at this point. All other steps in the RPM Cluster guide seems to have worked just fine. I’ve dropped the databases using kaltura-drop-db.sh mulitple times. To make sure I’m starting clean.
Any help is much appreciated! Let me know if i need to provide more information!
In /opt/kaltura/log/insertContent.log, is the upload request the only one that failed?
Under /etc/php.d, are the zz-kaltura-.ini files present?
Is it possible you have another INI file [in the PHP scandir or php.ini itself] that overrides the value for upload_tmp_dir?
While you’re at it, check the same for the other directives in this file.
The files are scanned in alphanumerical order and thus zz-kaltura.ini are supposed to be scanned last and override the rest but it’s worth checking.
As far as I can tell, yes, the upload request is the only one that failed. the UIConf add’s that precede it seemed to work OK. At least, the only time the word ‘error’ appears in the insertContent.log file is in relation the upload failing.
There is exactly one zz-kaltura-*.ini file in /etc/php.d
the upload_tmp_dir value is only present in the zz-kaltura-front.ini file and is set to /opt/kaltura/web/tmp
Perhaps there is something wrong with my nfs permissions. There is no directory /opt/kaltura/web/tmp as specified in zz-kaltura-front.ini file.
All the directories there are owned by root right now too. Not sure that matters. I know one of the scripts I ran verified that the kaltura user could write to the NFS mount though…
This directory is created by the kaltura-base package:
# rpm -qf /opt/kaltura/web/tmp
kaltura-base-12.20.0-3.noarch
If it wasn’t created, things will malfunction so need to understand what happened.
Is it possible that you installed the kaltura-base package BEFORE mounting the NFS volume? In which case, the directory would have been created on the local FS instead of on the remote volume…
You could try to reinstall the kaltura-base package with:
# yum reinstall kaltura-base
Make sure all relevant dirs were created and then re-run the configure scripts.
Also, in regards to file permissions on the NFS volume, note that you shouldn’t use the root_squash option, it may be the cause for the bad permissions.
I think the root cause here was not having the NFS mounted before installing kaltura-base. I’m not sure when I mounted the directory in relation to running kaltura-base, honestly. I had assumed it would be taken care of by a config script.
As far as root_squash, I think I had the exports wrong. I was exporting \opt\kaltura\ instead of \opt\kaltura\web. I was using the no_root_squash option but I think it wasn’t working as expected because of the exports being not configured correctly.
I’ve run the base-config and front-config scripts again. They completed normally.
The db-config script now also seems to complete without error. I have yet to install a batch node yet. I will do that as the next step.