Howto install OpenMeetings 2.2 server on a Debian Wheezy box

This guide is written specifically to cover a lack of quality documentation for the installation procedure of an OpenMeetings 2.2 server on a Debian Wheezy box.

It will be based on the manual available already for this procedure (but relatively badly structured and written in a rather improvable English), by Alvaro Bustos with the help of Federico Christian Tomasczik. Thanks to both of them. My manual is mostly a rewrite of the information in their guide, hopefully with enough precision to allow someone to script it. Also the fact that the guide is only available publicly as PDF is not ideal. Finally, there is a lot of space for interpretation in the dynamic links provided which, in my case, made me mistakenly go for 3.0 instead of my intended 2.2, which had considerable consequences in the particular task I was trying to achieve: write an OpenMeetings plugin for Chamilo.

Because that’s probably the easiest way to do it for anyone reading this manual, I will be explaining on the basis of a Digital Ocean virtual machine (or “Droplet”). I found that the $40/month (4GB of RAM) image works fine, but you can try with a 2GB one, maybe that works out too.
If you never tried Digital Ocean before, you have two options:

You create an account, pay $20 in advance with PayPal, create a new Droplet, choose Debian Wheezy 64bit (I picked New York 2 Data Center, but it *really* shouldn’t matter where it is) and jump to the beginning of this tutorial or
Find a machine where you can install Debian Wheezy (either virtual or physical), make sure it’s got an internet connection and start working

And of course, any Debian Wheezy machine would do.

For the sake of simplicity, I’ll assume you got root access to it.
I’ll also pass the OpenMeetings “client” install. If you don’t know how to install Flash, you should look for that information somewhere else.

I usually use VIM as an editor, so if the Debian box is new, I install vim:

apt-get update
apt-get install vim


Finally, I’ll assume that your server is available through a simple IP address or a domain name. Below, I will assume a ficticious URL of “video.openmeetings.net”. Replace that string with yours however you see fit.

Without further ado, let’s begin.

For some reason, Red5 seems to be failing to start when it cannot find a fully qualified domain name (FQDN) for the server on which it runs. To avoid this, simply put the right (or a fake) domain name in /etc/hosts, at the end of the first line. Following the logic above, I’m calling it video.openmeetings.net. Feel free to call it whatever you like, but try to use something that isn’t used by anyone else:


127.0.0.1 localhost video.openmeetings.net


Create an /etc/apt/sources.list.d/openmeetings.list with the following contents:

deb-src http://http.debian.net/debian/ wheezy main
deb http://http.debian.net/debian/ wheezy contrib non-free
deb http://http.debian.net/debian/ wheezy-updates main contrib
deb-src http://http.debian.net/debian/ wheezy-updates main contrib
deb http://www.deb-multimedia.org wheezy main non-free


Create an /etc/apt/sources.list.d/oracle-java.list with the following contents (because OpenMeetings does not officially support OpenJDK yet):

deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main
deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main


Then do the following (on the command line):

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update && apt-get install -y --force-yes deb-multimedia-keyring oracle-java6-installer


You’ll have to agree to the Oracle Binary Code license terms with the last command (in the oracle-java6-installer). This is manual (as far as I know, there is no way to automate it).

Now, we want to make sure this installed version of Java will be the one used for the rest of the processes on this server, by updating the alternatives and picking the one that says java-6-oracle and “jre” in the same path:

update-alternatives --config java


If this is a new, clean, server, the command will only mention that there is only one alternative, so that there is nothing to select.

You may want to also automatically set the environment variable, feature which is provided by the following package in WebUpd8’s repository:

apt-get install oracle-java6-set-default

Now we want to install Libreoffice, as it will be used by JODconverter (installed below) to convert documents:

apt-get install -y --force-yes libreoffice


On Digital Ocean’s machines, the download is super-fast (around 10 seconds for 450MB) and the whole installation should take about 30 seconds max.

We also need to install a few conversion libraries:

apt-get install -y --force-yes imagemagick libgif4 libjpeg62 libmp3lame0


…and the SWFtools (this is one of the trickiest parts for Debian/Ubuntu installations, but luckily someone packaged it)


cd
wget http://assiste.serpro.gov.br/libs/swftools_0.9.1-1_amd64.deb
dpkg -i swftools_0.9.1-1_amd64.deb

Note: for 32bit, you’ll have to download http://assiste.serpro.gov.br/libs/swftools_0.9.1-1_i386.deb

Now the ffmpeg library needs to be installed by hand in order to get access to a more recent version of the lib. In effect, Debian Wheezy “deb-multimedia” repository’s version is 1.0.8 and we’d like to get 1.1.2. Note that, during the “make” process (which might take more than 10 minutes), you can continue the installation with the other steps in a parallel terminal. Just don’t forget, at the end, to launch the checkinstall process.


apt-get install -y --force-yes libart-2.0-2 libt1-5 zip unzip bzip2 subversion git-core checkinstall yasm texi2html libfaac-dev libfaad-dev libmp3lame-dev libsdl1.2-dev libx11-dev libxfixes-dev libxvidcore4 libxvidcore-dev zlib1g-dev libogg-dev sox libvorbis0a libvorbis-dev libgsm1 libgsm1-dev libfaad2 flvtool2 lame
cd /opt
wget http://ffmpeg.org/releases/ffmpeg-1.1.2.tar.gz
tar zxf ffmpeg-1.1.2.tar.gz
cd ffmpeg-1.1.2
./configure --enable-libmp3lame --enable-libxvid --enable-libvorbis --enable-libgsm --enable-gpl --enable-nonfree
make
mkdir /usr/local/share/ffmpeg /usr/local/share/man /usr/local/include
checkinstall


The “make” command is probably the step that will take the most time of the whole installation (around 12 minutes, just by itself).

Press “Enter” 3 times to select the default options suggested by the installer.
This will (slowly) make a Debian package (ffmpeg_1.1.2-1_amd64.deb) and install it (as I mentioned, this might take more than 12 minutes on the suggested virtual machine).

It is suggested you “hold” this package version, to prevent Debian from trying to update it during the next apt-get upgrade. To do this:

apt-mark hold ffmpeg


At this point, feel free to delete everything you want from the /opt directory where we downloaded and built the ffmpeg package:

rm -rf /opt/ffmpeg*


Install the MySQL server (there is a default database used by OpenMeetings but it’s not meant for production).

apt-get install mysql-server


Give it a root password (twice). Note that it’s considered *really bad practice* to leave a blank password, so please think about something simple and safe instead of avoiding your responsibility. It also has nothing to do with system’s root password.

Connect to MySQL to prepare the openmeetings database:

mysql -uroot -p
mysql> CREATE DATABASE openmeetings DEFAULT CHARACTER SET 'utf8';
mysql> GRANT ALL PRIVILEGES ON openmeetings.* TO 'openmeetings'@'localhost' IDENTIFIED BY 'some-password-here' WITH GRANT OPTION;
mysql> quit


Now we’re ready to install OpenMeetings. You should get the latest stable version from here: http://openmeetings.apache.org/downloads.html
Other sources are likely to be less stable and I certainly did loose a lot of time on this, so I definitely recommend the stable. The following code is based on the stable that was downloadable at the time of writing, so you might want to check the link above. Beware that the link above does not provide a direct link for the download: it sends you to a mirrors page, from which you’ll have to pick a mirror. The command below downloads it directly from one of the mirrors.

mkdir /opt/red5
cd /opt/red5
wget http://www.webhostingjams.com/mirror/apache/openmeetings/2.2.0/bin/apache-openmeetings-2.2.0.tar.gz
tar zxf apache-openmeetings-2.2.0.tar.gz
rm apache-openmeetings-2.2.0.tar.gz
cd webapps/openmeetings/WEB-INF/classes/META-INF/
mv persistence.xml persistence.xml-ori
mv mysql_persistence.xml persistence.xml
vim persistence.xml


For the sake of copy-paste speed, you can launch all but the last command in one go with:


mkdir /opt/red5 && cd /opt/red5 && wget http://www.webhostingjams.com/mirror/apache/openmeetings/2.2.0/bin/apache-openmeetings-2.2.0.tar.gz && tar zxf apache-openmeetings-2.2.0.tar.gz && rm apache-openmeetings-2.2.0.tar.gz && cd webapps/openmeetings/WEB-INF/classes/META-INF/ && mv persistence.xml persistence.xml-ori && mv mysql_persistence.xml persistence.xml

vim persistence.xml

Here is where you’ll have to configure the XML file to set the db name, username and password for the openmeetings database we created above.
Find the “Url=” part. A few lines below, you’ll find a Username and a Password fields. Place the right ones there and save (with :wq if using VIM).


, Username=openmeetings
, Password=some-password-here" />


Now we’ll install the Java to MySQL connector (MySQL Connector/J aka MySQL JDBC).

cd /opt
wget http://ftp.sunet.se/pub/databases/relational/mysql/Downloads/Connector-J/mysql-connector-java-5.1.28.tar.gz
tar zxf mysql-connector-java-5.1.28.tar.gz
cp mysql-connector-java-5.1.28/mysql-connector-java-5.1.28-bin.jar /opt/red5/webapps/openmeetings/WEB-INF/lib/mysql-connector-java.jar
rm -rf mysql-connector*


Download the JOD converter to be able to convert files uploaded to OpenMeetings. Note that we’ll leave it into /opt for now, as OpenMeetings allows us to select the source for this converter. Also note that the version we download is version 3, while the one available in Wheezy is version 2.2.2 (I have no idea if this is relevant, but considering it is not to be installed or anything, the effort is not really worth the question in this case).


cd /opt
wget http://jodconverter.googlecode.com/files/jodconverter-core-3.0-beta-4-dist.zip
unzip jodconverter-core-3.0-beta-4-dist.zip

Newer versions might come in the future, so make sure you check http://code.google.com/p/jodconverter/downloads/list for any other version.

Now our red5 folder is ready to be put online, so we’ll move it to somewhere more permanent.

mv red5 /usr/lib
chown -R nobody /usr/lib/red5


Starting and stopping OpenMeetings is kind of complex, because there are several services involved. Luckily, someone wrote a script for us which, although not perfect, will help us solve this problem quickly:

wget https://cwiki.apache.org/confluence/download/attachments/27838216/OpenMeetings+2.x+run+script+Squeeze.zip?version=1
unzip OpenMeetings+2.x+run+script+Squeeze.zip\?version\=1



mv OpenMeetings\ 2.x\ run\ script\ Squeeze/red5 /etc/init.d/
chmod +x /etc/init.d/red5


And then we can finally start OpenMeetings (or should I say the Red5 server, which serves OpenMeetings):

/etc/init.d/red5 start


Now load it from your browser on http://video.openmeetings.net:5080/openmeetings/install and follow the information carefully.
Please note that the database doesn’t have to be configured through the web interface: it’s already been done in the XML file (remember?).

You will have to indicate the paths to the different conversion services, though.
To do this, you only need to know the following:
FFMPEG Path = /usr/local/bin
JOD Path = /opt/jodconverter-core-3.0-beta-4/lib

This should be enough for you to complete the installation and be able to use OpenMeetings! Have fun!

Bonus: if you want your server to be able to send e-mails, do the following:

apt-get install exim4
dpkg-reconfigure exim4-config

And then type “Enter” for every question except the one with 5 options beginning with “Internet sites”. There, you should select the first option “Internet sites” if you don’t know better, of course. Then go on with just “Enter” through it until you’re back on the command line.

Creating multiple git forks using upstream branches

Working with Git is… complex. It’s not that it’s from another world, and the complexity is probably worth it considering the crazy things it allows you to do, but sometimes it’s just mind-bloggingly complex to understand how to do things right.

Recently, we’ve had to manage a series of projects with changes that cannot be applied directly to our original Git repository on Github, so we decided, after giving it some thought, to make several forks of the project (instead of branches), to manage more clearly permissions and the real intentions behind each of the forks.

This would allow us a few important things:

• define precisely permissions based on the repository
• use the repository to pull changes directly on our servers
• have some level of local customization on each server, using local commits (and subsequent merges)
• keep easy track of the changes that have been made on requests from some of our “customers” (they’re not necessarily commercial customers – sometimes they’re just users who decided to go crazy and show us what they can do, and we want to show that in public)

To do that, we need to fork our project (chamilo/chamilo-lms) several times over.

So the first problem is: you cannot fork the same project twice with the same user.
Adrian Short (@adrianshort) kind of solved that issue in his blog article, saying that you can just do the fork manually, creating an empty repo on Github and filling it with a copy of the main repo, then adding the origin remote manually.

Even though that works, the Github page (starting from the second fork with the same user) will *not* indicate it has been forked from chamilo/chamilo-lms: you’ll have to issue the
git remote -v
command to see that the upstream is correct.

The second problem is that the article doesn’t dive into the details of branch-level forks, so this article intends to solve that particular missing detail, and in that respect, the Github help is definitely useful. Check Syncing a fork help page if you want the crunchy details.

To make it short, there are 3 issues here:

• fetching the branches from the original repo (upstream)
• getting the desired branch to be checked out into your local repo
• defining that, from now on, you want to work on your repo as a fork of that specific branch in upstream (to be able to sync with it later on)

The complete procedure then, considering my personal account (ywarnier) and the original chamilo/chamilo-lms project on Github, with the intention to work on branch 1.9.x, would look like this:


git clone git@github.com:chamilo/chamilo-lms
git remote -v
git remote rename origin upstream

(here you have to create the “chamilo-lms-fork1” repo by hand in your Git account)

git remote add origin git@github.com:ywarnier/chamilo-lms-fork1.git
git remote -v
git push -u origin master
git branch -va
git fetch upstream
git branch -va
git checkout --track remotes/upstream/1.9.x


This should get you up and kicking with your multiple forks in a relatively short time, hopefully!

1 laptop + 2 lcd = 3 pantallas para un solo escritorio, bajo Linux

Por los que están interesados en aumentar su capacidad de visualización de aplicaciones en su lugar de trabajo, los costos empiezan a ponerse democráticos (pantalla 19″ alrededor de $100, adaptadores también) para extender su laptop no con una pantalla más, sino con 2.

El tema es que las cosas todavía no son “tan” sencillas (pero deberían serlo dentro de muy poco) para usuarios de Linux, porque el kernel 3.11 (el estable usado en Ubuntu 13.10) no tiene un muy buen soporte para el tipo de extensión necesario.

No os preocupeis demasiado, que el kernel 3.12 en realidad es muy sencillo instalar, gracias a nuestros amigos de Ubuntu Handbook, quienes nos dan una lista de 4 comandos que entrar en una terminal para actualizar Ubuntu 13.10 al kernel deseao. Bueno, ojo que conlleva unos riesgos, ya que podría no funcionar bien su Ubuntu con este kernel (depende mucho del hardware que uno tenga, y de los drivers que fueron instalados en este), pero de generar problemas, basta con ir a ver las opciones avanzadas de arranque de Ubuntu, seleccionar el kernel anterior (3.11) en modo normal, para volver al modo anterior y desinstalar el kernel no funcional.

En mi caso particular, como lo iba a explicar, funcionó todo bien. Seguí las instrucciones del blog de Ubuntu Handbook y reinicié mi máquina, y ya funcionó la tercera pantalla. Demostración? Aquí va…

(la captura está en francés, pero ya os dais una idea de lo que representa)

Entonces, cual es lo que teneis que hacer ahí? Pues es bastante simple…

Primero, hay que tener una computadora (cualquiera) con Ubuntu instalada (Debian va también), una pantalla adicional (no es necesario tener 2, pero si solo teneis una, no importa mucho fregarse todo este procedimiento) y, muy importante, un adaptador USB a VGA (o DVI).

Por ejemplo, yo me compré un Trendnet TU2-DVIV por alrededor de 50€ en una tienda cercana y me funciona bien.

Una vez todo este material listo, quizás querais probar sin actualizar el kernel. Con suerte, funciona: solo hay que prender la pantalla, conectar el cable VGA al adaptador y enchufar el otro lado del adaptador en el puerto USB de la compu. De ahí es probable que haya que ir a Configuración -> Monitores para dar clic en “Detectar pantallas”, y luego (clic en la tercera pantalla detectada) activar esta nueva pantalla (no se porque, en mi caso no se había activado sola).

Si no se detecta ninguna nueva pantalla, hay que actualizar el kernel al 3.12. Para esto, seguir el procedimiento del Ubuntu Handbook descrito arriba, reiniciar e ir a la sección Configuración -> Monitores y (me repito) activar esta tercera pantalla. Quizás reposicionarlas un poco, y listo!

Espero haya sido útil para los que no tienen idea de como hacerlo (como yo hace una semana). Ojo que se puede poner más de una pantalla via USB, dependiendo de la cantidad de puertos libres que tiene.

On PHP and cache slams and solutions

While reading about Doctrine’s cache mechanism (which applies to other stuff than database queries, by the way), my eye was caught by a little message at the end (last section) about cache slams.

I have used cache mechanisms extensively over the last few years, but (maybe luckily) never happened to witness a “cache slam”.
There’s a link to a blog (by an unnamed author) that explains that.

To make it short, you can have race conditions in APC (and probably in other caching mechanisms in PHP) when you assign a specific time for expiry of cache data, and a user gets to that expiry time at the same time (or very very very closely) as other users. This provokes a chain reaction (a little bit like an atomic bomb, but not with the same effect – unless some crazy military scientist binds a high-traffic website to the initiation process of an atomic bomb) which makes your website eat all memory and freeze (or something like that).

In reply to me mentioning it on Twitter, @PierreJoye (from the PHP development team) kindly pointed me to APCu, which is a user-land caching mechanism (or so to speak an APC without the opcode, and simplified).

Apparently, this one doesn’t have the cache slam issue (although I haven’t checked it myself, I have faith in Pierre here) and it’s already in PECL (still in beta though), so if you want to try it out on Debian/Ubuntu, you will probably be able to sort it out with a simple:

sudo apt-get install php5-dev php5-pear make
sudo pecl install APCu

(and then configure your PHP to include it).

Don’t forget that it is a PECL library, meaning it’s most likely you’ll have to recompile your PHP to enable it, but PECL should handle that just fine (in our case it’s a bit more complicated if we want to avoid asking our users – of Chamilo, that is – for more dependencies).

Anyway, just so you know, there are people like that who like to make the world a better place for us, PHP developers, so that we can make the world a better place developing professional-grade, super-efficient free software in PHP! Don’t miss out on contributing to that!