What's wrong with the ' Couldn't make an API request to ...'

When I install my kaltura,wrong as follow:

Kaltura install answer file written to /tmp/kaltura_06_04_10_00.ans - Please save it!
This answers file can be used to silently-install re-install this machine or deploy other hosts in your cluster.

Configuration of 10.7.0 finished successfully!
Running FrontEnd config…

base-config completed successfully, if you ever want to re-configure your system (e.g. change DB hostname) run the following script:

rm /opt/kaltura/app/base-config.lock


It is recommended that you do work using HTTPs. Would you like to continue anyway?[N/y]
Which port will this Vhost listen on? [80]
Please select one of the following options [0]:
0. All web interfaces

  1. Kaltura Management Console [KMC], Hosted Apps, HTML5 lib and ClipApp
  2. KAC - Kaltura Admin Console
    Enabling Apache config - apps.conf
    Enabling Apache config - var.conf
    Enabling Apache config - admin.conf

Kaltura install answer file written to /tmp/kaltura_06_04_10_00.ans - Please save it!
This answers file can be used to silently-install re-install this machine or deploy other hosts in your cluster.

Redirecting to /bin/systemctl restart httpd.service
注意:正在将请求转发到“systemctl enable httpd.service”。
Restarting kaltura-monit (via systemctl): [ 确定 ]
Running Sphinx config…

base-config completed successfully, if you ever want to re-configure your system (e.g. change DB hostname) run the following script:

rm /opt/kaltura/app/base-config.lock


Starting kaltura-monit (via systemctl): [ 确定 ]

Configuring your Kaltura DB…

Checking MySQL version…
Ver 5.5.41-MariaDB found compatible

CREATE USER kaltura;
CREATE DATABASE kaltura_sphinx_log;
CREATE DATABASE kalturadw_ds;
CREATE DATABASE kalturadw_bisources;
Checking connectivity to needed daemons…
Connectivity test passed:)
ERROR: Couldn’t make an API request to
Please check your setup and then run /opt/kaltura/bin/kaltura-db-config.sh again.
Do you wish to remove the existing DB or keep for debugging puropses [n/Y]?

This will drop the following DBs:
kaltura kaltura_sphinx_log kalturadw kalturadw_ds kalturadw_bisources kalturalog
and remove users:
kaltura etl

NOTE: this is not reversible.
It is recommended you also back up the current data using mysqldump before continuing.
You can use /opt/kaltura/bin/kaltura-export-db.sh to export the data.

Are you absolutely certain you want this? [n/Y]

root DB passwd:
Removing kaltura
Removing kaltura_sphinx_log
Removing kalturadw
Removing kalturadw_ds
Removing kalturadw_bisources
Removing kalturalog
ERROR: we failed on something else…



This means the request to
Start by making it manually from the shell with:
# curl -I -v

Then check the apache configuration with:
# apachectl -t -DDUMP_VHOSTS

Thanks Jess.
l hava a question about DB,can I replace mariadb with postgresql?

Hi Ning,

I am afraid not. Must be either MySQL or MariaDB. While it might work with Postgres, it is not officially supported and since all the install scripts use mysql client to talk to the DB, it would fail.

Now l hava two problems.
1 l configure Red5 server as https://github.com/kaltura/platform-install-packages/blob/master/doc/install-kaltura-redhat-based.md#configure-red5-server.But when l request http://hostname:5080 and Click ‘Install a ready-made application’,nothing in the page and l can’t find ‘OFLA Demo’.
2 l run /opt/kaltura/bin/kaltura-sanity.sh,l can login to Kaltura Administration Console but cannot login to KCM.what should l do?


Red5 - what version are you using?
# rpm -q kaltura-red5
to find out.

KMC - run kaltlog while making the request and lets see the errors this is generating.

I ran

/opt/kaltura/bin/kaltura-config-all.sh [path/file]

and get [OK]s for FrontEnd and sphinx config scripts, but while “Configuring your Kaltura DB…”
(shows the scripts creating the databases), and “Connectiviy test passed” boom!
ERROR: Couldn’t make an API request to https://xx.xxxx.xxxxx:443/api_v3/index.php?service=system&action=ping.

As suggested above, run (Xs for IP and domain)

apachectl -t -DDUMP_VHOSTS

Passing arguments to httpd using apachectl is no longer supported.
You can only start/stop/restart httpd using this script.
If you want to pass extra arguments to httpd, edit the
/etc/sysconfig/httpd config file.
VirtualHost configuration:
xx.xxx.xxx.xx:443 xx.xxxx.xxxx (/etc/httpd/conf.d/zzzkaltura.ssl.conf:22)

In my Apache config, I browse to http, and if I create a VH for 443, it all works (SSL is happy). Is it something about that zzzkaltura.ssl.conf:22

Any help is appreciated

Hi @riclaso,

Please post the contents of /etc/httpd/conf.d/zzzkaltura.ssl.conf so I can help you further.
Also, what’s the full output for:

$ curl -I -v https://xx.xxxx.xxxxx:443/api_v3/index.php?service=system&action=ping

Thanks @jess,
This is how zzzkalturra.ssl.conf look like

<IfModule !ssl_module>
        LoadModule ssl_module modules/mod_ssl.so

SSLPassPhraseDialog  builtin
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
<IfVersion < 2.4>
        SSLMutex default
<IfVersion >= 2.4>
        Mutex sysvsem default
SSLCryptoDevice builtin

SSLCertificateFile /path/to/xx.xxxx.xxxx/cert.pem
SSLCertificateKeyFile /path/to/xx.xxxx.xxxx/privkey.pem
SSLCACertificateFile /path/to/xx.xxxx.xxxx/fullchain.pem
<VirtualHost xx.xxxx.xxxx:443>
        SSLEngine on
        SSLProtocol all -SSLv2

        ErrorLog "/opt/kaltura/log/kaltura_apache_errors_ssl.log"
        CustomLog /opt/kaltura/log/kaltura_apache_access_ssl.log vhost_kalt

        Include "/opt/kaltura/app/configurations/apache/conf.d/enabled.*.conf"

[1] 3028
[user@hostname /]$ * About to connect() to xx.xxxx.xxxx port 443 (#0)

  • Trying xx.xxx.xxx.xx…
  • Connection refused
  • Failed connect to xx.xxxx.xxxx:443; Connection refused
  • Closing connection 0
    curl: (7) Failed connect to xx.xxxx.xxxx:443; Connection refused

Hi @riclaso,

Is Apache currently listening on port 443

# netstat -plntu|grep 443
if not, you need to check why, if it is, perhaps you have FW rules dropping packets? does:
# telnet $SERVICE_URL 443


Sorry about that… I commented the IncludeOptionals last night when testing a dummy VirtualHost *:443 Here it is the new curl’s output
[1] 4374
[user@hostname /]$ * About to connect() to xx.xxxx.xxxx port 443 (#0)

  • Trying xx.xxx.xxx.xx…
  • Connected to xx.xxxx.xxxx ( xx.xxx.xxx.xx) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • Server certificate:
  • subject: CN=xx.xxxx.xxxx
  • start date: Jun 21 01:06:00 2017 GMT
  • expire date: Sep 19 01:06:00 2017 GMT
  • common name: xx.xxxx.xxxx
  • issuer: CN=Let’s Encrypt Authority X3,O=Let’s Encrypt,C=US

HEAD /api_v3/index.php?service=system HTTP/1.1
User-Agent: curl/7.29.0
Host: xx.xxxx.xxxx
Accept: /

< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
< Date: Fri, 23 Jun 2017 15:33:37 GMT
Date: Fri, 23 Jun 2017 15:33:37 GMT
< Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips PHP/5.4.16
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips PHP/5.4.16
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1


  • Connection #0 to host xx.xxxx.xxxx left intact

Hi @riclaso,

What other files do you have under /etc/httpd/conf.d/? I suspect you have a different vhost that takes precedence over the Kaltura one and thus when you request:


you hit IT instead and hence are getting HTTP 404.

Thanks @jess

I have autoindex, php, ssl, userdir, welcome and zzzkaltura.ssl
ssl.conf is empty… the others have the standard stuff

As of
netstat -plntu|grep 443
tcp6 0 0 :::443 :::* LISTEN 4216/httpd

telnet $SERVICE_URL 443
https://xx.xxxx.xxxx:443: Unknown host

I am now able to see the Kaltura welcome page (/start), and this is what I did:

  • Tried to re-install the certificate using certbot. It did not like it the way zzzkaltura.ssl.conf has the certificates. I manually edit the file by moving the SSLCeritificateFile(s) and SSLCeritificateKeyFile and place them inside the VirtualHost tags.
  • Run curl -I -v https://xx.xxxx.xxxx:443/api_v3/index.php?service=system&action=ping and get
    curl: (35) SSL received a record that exceeded the maximum permissible length
  • Back to edit the zzzkaltura.ssl.conf file and replace by

The thing seems to work, but I have the feeling that once I re-run /opt/kaltura/bin/kaltura-config-all.sh [path/to/answer_file] , It will overwrite those changes. Is there any way to jump to the Configuing your Kaltura DB installation (when creates tables, etc).

Does it all make sense?

For documentation, just in case that it might help someone else:
As expected, once I re-run kaltura-config-all.sh it overwrote my changes. Then, as a work around, I edited kaltura.ssl.conf.template , and hard-coded the following line (please, note that “default” goes in between underscore:

instead of <VirtualHost @KALTURA_FULL_VIRTUAL_HOST_NAME@>

Then moved the three certificates lines to be inside the VH tags


Finally run:
/opt/kaltura/bin/kaltura-config-all.sh /path/to/answer/file

It is now working, but @jess am wondering whether that it is a bug, or my changes are somehow wrong, and just good for now to get me going.


Hi @riclaso,

As for your first question, [quote=“riclaso, post:14, topic:2108”]
. Is there any way to jump to the Configuing your Kaltura DB installation (when creates tables, etc).

/opt/kaltura/bin/kaltura-config-all.sh is a wrapper script that calls:

This is meant to make the all in one instance deployment easier but of course, each of these scripts can be invoked separately, in fact, this is how it’s done when deploying a cluster, since each node has different designated roles.
Note however that $BASE_DIR/bin/kaltura-front-config.sh does more than just configuring the Apache Vhost so, of course, it cannot be skipped.

As for [quote=“riclaso, post:15, topic:2108”]
<VirtualHost default:443> instead of <VirtualHost @KALTURA_FULL_VIRTUAL_HOST_NAME@>

Apache can be configured in many ways depending on your desired use. Setting the Kaltura VH as default is not always what one wants. It may work correctly for your use case and that’s fine but there’s no bug in the default configuration, it works fine in most cases:)

Note also that while the Let’s Encrypt’s certbot script usually does a good job updating the Apache configuration, it cannot always handle it. The script also supports a “certonly” mode which would allow you to generate the cert without making changes to the Apache config, then you should be able to simple run kaltura-front-config.sh and input the location for the certs and all should work correctly.

Thanks @jess, appreciate the extra info

Most welcome, @riclaso.