Introducing KIPP – Kaltura Install Made Simple.

by Jess Portnoy

kaltura-light-blue-bg

The installation of Kaltura, just like the platform itself, went through a lot of metamorphosis over the years.

Over the years, we invested many resources at making Kaltura the best media management platform. Featuring grand batch system, complex metadata engine, robust entitlements, simplified video transcoding and more.

Alas, built on many different technologies, the installation of the platform became a bit of a complex task. Requiring many pre-install steps and several tricky pit-falls, even for the expert Linux engineers.

 

Announcing “KIPP” – Kaltura’s Install Packages Project!
Putting in place the resources to simplify and standardize the installation of Kaltura.
To enable the use of standard Linux package managers (e.g. yum, aptitude) to deploy the Kaltura platform with ease.

 

Community ahead!

It was important for us to create an open and collaborative project from day 1. Enabling community users to take part in defining, testing and developing the project.

Open repository and packaging tools –

All RPM and deb specs are accessible on an open GitHub repository.
Also available a chrooted ready-to-go build environment to allow experienced package developers to get started with ease and contribute packages for other CPU architectures or other operating systems.

 

Many dependancies, many challenges.
Kaltura requires many 3rd party components. Some of which are available via official Linux repositories. Many are in different versions or compilation options than what Kaltura requires. And other are missing altogether from official repositories.

Most packages are available from supplementary repositories such as EPEL and RPMForge. But, relying on unofficial repositories would force a list of pre-install steps that KIPP was set to avoid. And it would also introduce the challenge of keeping up with updates from these repositories.

 

Clean & Simple!
To meet our simplicity goal, we’ve chosen a few project guidelines.

All packages will have the ‘kaltura-‘ prefix.
This ensures a no-conflict with other packages the machine may already have installed.
It would also provide a simple approach to handling updates –
# yum update "*kaltura*"

All files go under /opt/kaltura/.
Apart from standard init scripts: /etc/init.d and symlinks to Apache and logroate configurations. If the user runs the un-install script – everything gets removed.

Release notes matter.
Every package contains project metadata, that includes the project’s github repository and changes log. The changes-log contain all changes or patches for each version as well as links to Knowledge Center release notes.

Simple single-server without compromising cluster installs.
A single call to the ‘kaltura-server’ meta-package will install a complete all-in-one Kaltura server. But, as you grow your usage, so should your network grow into a smarter cluster of dedicated servers.

Modular packages structure.
A key characteristic of Kaltura is its ability to scale and deploy across any size cluster. The install packages should allow for the same level of modularity in deployment:

  1. You only install what you need.
  2. You should always know exactly what you have installed and of which version.
  3. You should have full control over which parts to update or patch.
  4. You should deploy packages based on desired server-role by calling its role. E.g. front, batch, sphinx, DB, etc.

Automated, silent installs.
Repurposing and adding new servers in your network should be a painless and automatic task.

Post-install script for each server role, allows for an easy deploy or repurpose of Kaltura servers.
Utilizing answers-file, preconfigured server-role templates allow for automatic deployment of new servers.
Admins can use Chef scripts with preconfigured answers-file to deploy complete clusters with ease.

Building for today, designing for long-term.
The short-term goal is to solve deployment of Kaltura on Fedora and Debian based Linux systems. Utilizing simple shell post-install scripts we maintain a common code base whenever possible. That allows for reuse in future packages, reducing time to package for other systems such BSD variants or even OSX.
Also, if we add new directives or variables in the future, all we need to update is the answer file template.

 

Support the project:

  • Kaltura Admins – Follow the new install guide (http://bit.ly/kipp-rpm). Help test the installation and upgrade flows.
  • Packagers / Package Developers – If you’re experienced with Linux packaging (or brew/macports on OSX) drop us a line!
  • Tech writers, translators and anyone who cares – Let’s reach everyone who cares about online video, anywhere!

To stay updated and learn more, visit the project page!

 

 

  • Babin Lonston

    The Installation steps were very easier, struggle a lot while using Kaltura CE5 to install it, But its just took 10 min for setup now, Could you please help me to setup a Drop folder and live media streaming.

  • http://www.kaltura.org Jess Portnoy

    Hello Babin,

    Happy to hear the install went well for you:)
    Drop folder is easy to setup:
    $HOST/admin_console/index.php/partner/create
    And create a partner.

    Then, in the table, on the row of your partner, the ‘Profile’ column selectbox should be on ‘Drop Folders’
    Then ‘Create New”
    Submit the form as per your configuration and remember the directory of the dropfolder must have apache and kaltura permissions, you could do:
    # chown kaltura.apache /path/to/dropper
    # chmod 775 /path/to/dropper

    Media streaming – you should run:
    # kaltura-red5-config.sh

    Follow setup directions here:
    https://github.com/kaltura/platform-install-packages/blob/master/doc/install-kaltura-redhat-based.md#configure-red5-server

    And then stream to rtmp://$RED5_HOST/oflaDemo

    Let me know if you need more help.

    Thanks,