This was fixed for 13.16.0 which was released today but you can easily patch the batch.ini file manually as I explained in my reply.
The DWH test sometimes fails due to timing, does not necessarily means anything is wrong. Check /opt/kaltura/dwh/logs/*log for errors, if you see none, we should be OK.
The @MONIT_PASSWD@ token is replaced in kaltura-base-config.sh.
Not sure why it was not replaced in your case but you can edit the file manually and set a passwd. Once done, restart the kaltura-monit service.
For general guidance in regards to Monit’s configuration, see:
I added missing directive in /opt/kaltura/app/configurations/batch/batch.ini.
Checked kaltlog: same errors
I have updated to v 13.16
run /opt/kaltura/bin/kaltura-config-all.sh
** kaltura-base-config.sh**
Appreciate your time and effort, Thanks, Dmitri
kaltlog
==> /opt/kaltura/log/kaltura_apache_errors.log <==
[Thu Mar 29 10:17:33 2018] [error] [client 10.48.12.178] PHP Warning: file_get_contents(/opt/kaltura/app/cache//api_v3/classMap.cache): failed to open stream: Permission denied in /opt/kaltura/app/infra/KAutoloader.php on line 415
[Thu Mar 29 10:17:33 2018] [error] [client 10.48.12.178] PHP Class map could not be loaded from path [/opt/kaltura/app/cache//api_v3/classMap.cache] file permissions [0600]
–
2018-03-29 10:17:33 [0.011054] [1825021608] [8] [BATCH] [KalturaClientBase->doQueue] NOTICE: server: [sb-kaltura…], session: []
2018-03-29 10:17:33 [0.000319] [1825021608] [9] [BATCH] [KalturaClientBase->doQueue] NOTICE: result (serialized): PHP Class map could not be loaded
2018-03-29 10:17:33 [0.000372] [1825021608] [10] [BATCH] [KScheduleHelper->run] ERR: exception ‘Exception’ with message ‘System is not yet ready - ping failed’ in /opt/kaltura/app/infra/log/KalturaLog.php:83
Stack trace: #0 /opt/kaltura/app/batch/batches/KScheduleHelper.class.php(42): KalturaLog::err(‘System is not y…’)
I might miss something. There were the same errors as before after adding missing directive in /opt/kaltura/app/configurations/batch/batch.ini.
Then I did update to v13.16.
209 [KAsyncExtractMedia : JobHandlerWorker] 210 params.ffmpegCmd = /opt/kaltura/bin/ffmpeg
211 id
There are not the same errors as before after update to v13.16
This should be fixed by adding the line I referenced to bach.ini or else, by upgrading to 13.16.0.
The errors you posted here:
Have to do with /opt/kaltura/app/cache and its sub-directories bearing the wrong permissions.
For this, following the commands specified in my reply here:
The PHP scripts kaltura-sanity.sh runs will not work as they are w/o a valid CA.
That said, if you disable the SSL verification in admin.ini and batch.ini as I detailed before, the Admin Console and batch daemon and its workers should be able to function properly.
However, as mentioned before, it is really most recommended that you configure Apache and Nginx with a proper valid [not self signed] cert, key and CA. For testing, you can just skip SSL altogether. For Production [or any machine whose IP is mapped to real domain and is accessible from www, for that matter], you can use letsencrypt and obtain a valid cert for free.
Certificate is signed by an untrusted issuer: ‘CN=sb-kaltura…,C=CA’
NSS error -8172
Closing connection #0
Peer certificate cannot be authenticated with known CA certificates
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.
with the -k (or --insecure) option
curl -l -v -k https://sb-kaltura.domain.com
About to connect() to sb-kaltura.domain.com port 443 (#0)
Trying 10… connected
Connected to sb-kaltura.domain…com (10…) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
warning: ignoring value of ssl.verifyhost
skipping SSL peer certificate verification
SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Server certificate:
start date: Mar 27 13:49:31 2018 GMT
expire date: Mar 27 13:49:31 2019 GMT
common name: sb-kaltura…com
issuer: CN=sb-…=CA
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sb-kaltura.mydomain.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. sb-kaltura.mydomain.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for sb-kaltura.mydomain.com
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
Not really sure about the point you’re trying to make with the curl CLI output:)
We already know you set up a self signed cert and have no CA and that curl CLI will fail unless you pass -k.
The kaltura code base [and several of the sanity tests] does not use curl CLI but the PHP curl extension [since the entire server side is written in PHP]. The Admin Console and batch code checks the directives in admin.ini and batch.ini to determine whether to set the CURLOPT_SSL_VERIFYPEER option [the parallel of the CLI -k] to true or false but the sanity scripts do not support this option and so, they will fail.
In regards to letsencrypt, like I said, it will only work if the domain is accessible from www because certbot places a simple verification code in your docroot and then tries to access it from outside to make sure this domain is really mapped to the server you are running certbot from.