feat(recording): Add new custom gems

[GuiLeme]

What does this PR do?

This PR makes it possible to add new custom gems to the recording and post scripts.

Motivation

As discussed, some users need to use other dependencies not previously installed, such as rest-client for the post_event scripts.

More

In order to use/test this feature:

• Create a folder /etc/bigbluebutton/recording (all overridings will be there);
• Create a GemsToAdd file and insert your custom dependencies such as if it was in common Gemfile (versions and all).
• Make sure the new bbb-record script is placed correctly:
  • You can replace the old bbb-record to the new one in /bin/bbb-record;
• Run the command bbb-record --addcustomgems to build those dependencies;

From now on, the scripts that follows are used to test the feature:

Place the following content in /etc/bigbluebutton/recording as /etc/bigbluebutton/recording/GemsToAdd

gem 'unicode-emoji', '~> 1.0', '>= 1.0.3'
gem 'rest-client'

The following ruby script must be placed in /usr/local/bigbluebutton/core/scripts/post_events as sample_analytics_sender.rb.

#!/usr/bin/env ruby
# frozen_string_literal: true

require '../../core/lib/recordandplayback'
#require 'rubygems'
#require 'bundler/setup'
require 'optimist'
require 'yaml'
require 'fileutils'
require 'bbbevents'
require 'json'
require 'uri'
require 'logger'
require 'rest-client'
require 'redis'
require "unicode/emoji"

opts = Optimist.options do
  opt :meeting_id, 'Meeting id to archive', type: String
end

meeting_id = opts[:meeting_id]

logger = Logger.new("/var/log/bigbluebutton/sender-events-#{meeting_id}.log", 'daily')
BigBlueButton.logger = logger
BigBlueButton.logger.info("Publishing #{meeting_id} using multipart upload")
string = "String which contains all kinds of emoji:

- Singleton Emoji: 😴
- Textual singleton Emoji with Emoji variation: ▶️
- Emoji with skin tone modifier: 🛌🏽
- Sub-Region flag: 🏴󠁧󠁢󠁳󠁣󠁴󠁿
- Keycap sequence: 2️⃣
- Sequence using ZWJ (zero width joiner): 🤾🏽<200d>♀️

"
BigBlueButton.logger.info(string.scan(Unicode::Emoji::REGEX).inspect)

• Make sure that defaultKeepEvents=true is set in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties, if not, set it and reload bbb-web;
• Record anything;
• When finished, as the post_event script can tell us, there will be some logs in /var/log/bigbluebutton/sender-events-<meeting-ID>.log

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[kepstin]

One idea for handling upgrades - add a check to "bbb-conf --check" which looks for the renamed original Gemfile (e.g. Gemfile.orig) and checks if that Gemfile.orig file is newer than Gemfile - and if so, recommends re-running the bbb-record --addcustomgems tool to update the custom gems.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[GuiLeme]

Hey @kepstin.

Re-running the bbb-record --addcustomgems command a second time keeps appending to the existing file, which can cause conflicts if for example some tries to update a gem to a different version.

I just made a commit correcting this behavior, see if it fits the what is expected

What's the story for handling upgrades? In the case of an upgrade, the Gemfiles need to get re-merged and the additional gems reinstalled. We might have to add some handling for that in the package post-install scripts.

About this concern, I haven't really thought about that, but in the commit I mentioned, I handled something similar to it, so, the idea is: When the user wants to add an already installed gem, the script will check if the gem requested has a higher Version, and install it, otherwise, it will just ignore.

So as an example, we have:

Gemfile:

gem 'builder', '~> 3.2'

GemsToAdd:

gem 'builder', '~> 3.2.4'

In this case, the Gemfile will receive the 3.2.4 version and the script will run bundle install, and if there is a problem with the install (say the version doesn't really exist because the user mistook the numbers), it will just take the backup Gemfile and Gemfile.lock (which was made previously), redo the bundle install to ensure all is running correctly, and it will notify the user what went wrong.

Other than that, I wasn't able to understand the strategy here:

One idea for handling upgrades - add a check to "bbb-conf --check" which looks for the renamed original Gemfile (e.g. Gemfile.orig) and checks if that Gemfile.orig file is newer than Gemfile - and if so, recommends re-running the bbb-record --addcustomgems tool to update the custom gems.

So if you could elaborate on it I would really appreciate.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.