Upgrade Kaltura CE to 13.0


#1

Hi

I just try to upgrade my single server test instance from 12.10 to 13.0, but the installation of kaltura-base fails with the output:

INFO: Copy tests from [/opt/kaltura/clients-generator/sources/php5]
INFO: Saving client library to [/opt/kaltura/web/content/clientlibs/testsClient]
INFO: testsClient generated successfully
ERROR 1046 (3D000) at line 1: No database selected
mysql: option ‘-P’ requires an argument
mysql: option ‘-P’ requires an argument

There is no posibility to set the db password during install.

The “old” instance have got proper configured config files.

Kind Regrads
Roger


#2

HI @roger78,

During the postinst phase of the kaltura-base deb and RPM, the ‘kaltura’ MySQL user’s passwd is taken from the DB1_PASS ENV var, which is set in /etc/kaltura.d/system.ini. Your output also suggests you’re missing the other DB1_.* vars.
Please check /etc/kaltura.d/system.ini.


#3

Hi Jess

Yes It looks like everything is correct in this file

DB1_HOST=localhost
DB1_NAME=kaltura
DB1_USER=kaltura
DB1_PASS=mycorrectpassword

I doublechecked the credentials and they are correct.

I am using debian.


#4

Hi @roger78,

I recommend that you edit:
/var/lib/dpkg/info/kaltura-base.postinst
so that:

#!/bin/bash

becomes:

#!/bin/bash -x 

And then, either run:
# aptitude install -f
or
# dpkg-reconfigure kaltura-base

BASH will then output a lot of debug info to STDERR which will allow you to see exactly which line of code in the postinst script is failing and what ENV vars were set and what args were passed to the mysql client.
If you need help with the analysing the root cause, please paste that output here [minus the actual passwds of course].


#5

Thank you @jess the DB1_PORT was missing for the kaltura-base setup and the SUPER_USER and SUPER_USER_PASSWD was missing for the kaltura-html5lib setup.
I entered the values to the system.ini and the installation went successfull throught.

After the setup were completed the values, which i entered weren’t in the system.ini anymore.
It seems that a script will overwrite this file after the setup and remove these vaules.

strange.
I entered the value once more for the next update.
Probably this happens only on a all-in-one installation. (Debian)

Best wishes
Roger Barras


#6

Hi @roger78,

All these values are written to $BASE_DIR/app/configurations/system.ini which is symlinked to /etc/kaltura.d/system.ini, during the execution of /var/lib/dpkg/info/kaltura-base.postinst.

If the values do not already exist in the debconf DB, you will be prompted for them during the configure phase.
See:
https://github.com/kaltura/platform-install-packages/blob/Mercury-13.1.0/deb/kaltura-base/debian/postinst#L141-#L163

The writing of these values into system.ini happens here:

So it is a bit odd that this didn’t happen to you.
Are you able to reproduce it when running:
# dpkg-reconfigure kaltura-base
?

Note that if you run the above, you’ll also need to run:
# dpkg-reconfigure kaltura-front
# dpkg-reconfigure kaltura-batch

Afterwards.


#7

Sorry for thread jacking… but how did you manage to upgrade to 13 in the first place?

I’ve followed the steps for my Debian installation detailed here

aptitude install ~Nkaltura
only yields
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

and I’m stuck on 12.20.0-2.


#8

Hi @ArneWeise,

I have updated the upgrade instructions in the hope that they will now be clearer and easier to follow.
Please see:

or, in the event you’re running a cluster:

If you’re still not getting updates when running these commands, please paste the contents of /etc/apt/sources.list.d/kaltura.list here, as well as the output for each of the commands specified in the howto.

Thanks,


#9

Thanks Jess!

mercury instead of lynx should do the trick I think. Will take a snapshot and give it a try.

Will post pack in case of errors.


#10

Welcome @ArneWeise.
Indeed, always best to take a snapshot first:)
Also, I’ve revised the doc again because:

# dpkg-query -f '${Package} ' -W "kaltura-*"

will also output packages that were previously installed and are now removed which is not desired. You could do:

# dpkg-query -f '${Package} ${Status}\n' -W "kaltura-*"|grep "install ok installed"|awk -F " " '{print $1}'|xargs

To only get INSTALLED kaltura packages but to be honest, it’s best to just use:

# aptitude dist-upgrade

since really, you also want to upgrade all the packages the Kaltura packages rely on, such as Apache, OpenSSL, PHP, etc. This is especially important from a security standpoint.


#11

Got this error after updating /etc/apt/sources.list.d/kaltura.list
and adding the new key I still get this error.

W: GPG error: http://installrepo.kaltura.org/repo/apt/debian mercury InRelease: The following signatures were invalid: AD4200615722734CBBE6C52FE7EEDECAA1174D5E
W: The repository ‘http://installrepo.kaltura.org/repo/apt/debian mercury InRelease’ is not signed.
N: Data from such a repository can’t be authenticated and is therefore potentially dangerous to use.


#12

Hi @ArneWeise,

Did you import the right key?

wget -O - http://installrepo.kaltura.org/repo/apt/debian/kaltura-deb.gpg.key|apt-key add -

#13

Yes.

I even tried to first wget the key separately and then running apt-key add kaltura-deb.gpg.key.

What have I missed?
Is InRelease repo it’s own repo? Could it bee that it’s not signed?


#14

Hi @ArneWeise,

All our repos are signed:)
What’s the output for:

# apt-key list|grep Kaltura -A1
# cat /etc/apt/sources.list.d/kaltura.list

Thanks,


#15

apt-key list complaints that one should not parse it’s output…

However these the following keys seems to belong to kaltura
uid [ unknown] Kaltura deb repo community@kaltura.com
sub rsa2048 2015-04-18 [E]

uid [ unknown] Kaltura deb repo community@kaltura.com
sub rsa2048 2015-01-01 [E]

cat /etc/apt/sources.list.d/kaltura.list gives me
deb [arch=amd64] http://installrepo.kaltura.org/repo/apt/debian mercury main


#16

Hi @ArneWeise,

I suggest you try to remove all the Kaltura keys you have and reimport.
I just tested on 2 of my ENVs [it’s not the same Debian version as yours but that shouldn’t make a difference in this respect] and had no issues.


#17

Same thing.

For the purpose of debuging I tried apt-get update before importing the key.
That produced an error indicating a missing key ( NO_PUBKEY E7EEDECAA1174D5E )

After importing the keys again the message is different
The following signatures were invalid: AD4200615722734CBBE6C52FE7EEDECAA1174D5E


#18

Hi @ArneWeise,

Only thing I can try to do is deploy on the exact same Debian version as you’re using, though again, the key handling should be the same regardless of the Debian/Ubuntu version, unless Ubuntu Xenial [16.04] is used, which has its own dedicated repo and thus a different GPG key. What version are you using?


#19

#cat /etc/debian_version = 9.2

As for Kaltura I’m still on 12.20.0-2 - on my way to 13.

I’v read posts about Debian has abandoned SHA1 in apt as of version 9. Could that affect it?


#20

Hi @ArneWeise,

Yes. Also, there are other issues with using Debian 9 [Stretch]. Please see a detailed explanation as to why, here:

For Debian, we only support 7 [Wheezy] and 8 [Jessie], for Ubuntu, both 14.04 and 16.04 are are supported.
If you want, you can deploy a Docker container of one of these versions on your actual machine, of course, a VM is fine too.

Note that the supported distros are always specified here:

Thanks,