TurnKey Linux Virtual Appliance Library

Elgg Appliance?

I've gotten mixed messages about where to propose and then follow through on ideas for TKL appliances. (I've been told the general forum, but I see others being directed to the blueprints. I figured I'd follow the instructions I first received):

Is there any interest in an Elgg appliance? Elgg is an open-source social networking platform (learn more about Elgg here: http://elgg.org/). It looks like a manageable patch, looks as though it would be a good final contribution from the students I work with, and looks like they'll be able to accomplish it with minimum guidance. And it fits my requirement of being useful for education institutions. But I only want them to pursue it if it's a possible candidate that would potentially find an audience among your users.

Any thoughts?

Rik Goldman

Patch Completed

Root User:
Username: root
Password: none (until install)
MySQL Root User:
Username: root
Password: root
Elgg MySQL User:
Username: elgg
Password: elgg
Elgg Admin User:
Username: admin
Password: elggadmin
Liraz Siri's picture

Elgg looks awesome. Work on what interests you!

This is the first time I've heard of elgg which is surprising because it looks awesome! No Debian/Ubuntu packaging unfortunately, but don't let that stop you.

I did a bit of research and there seems to be a good amount of interest in elgg (e.g., 165,000 Googles a month). Plus, with all of the recent Facebook privacy abuses, helping to promote open source alternatives is a great idea. I think this would make a good addition to the TurnKey library.

With regards to the confusion on forums vs blueprints, there is no officially blessed way to contribute to TurnKey. We're not big on formalities. We'd rather people just work on what interests them with the tools they're comfortable with.

OTOH, sometimes adding a little structure can be a good thing, but that's something we can evolve incrementally. Currently, registering a blueprint is optional.

Guest's picture

Elgg .deb package

Hi...great to see someone planning to make Elgg easier to install!

Before I joined the Elgg dev team I was working on a dpkg for Elgg 1.5.  I submitted a ITP to Debian [1] and there was a bit of discussion about it.  Unfortunately, no sponsors were interested in sponsoring a PHP package.

Elgg is now at version 1.7.1, but if it would help, I can find the sources for the original 1.5 package and post them somewhere for you?





Liraz Siri's picture

Debian packaging would be neat

Thanks for weighing in Brett! The source code for an Elgg package may be useful down the road. Assuming things haven't changed dramatically since the version you supported it shouldn't be too hard to update the package to the current version.

Even if Rik and his gang don't use it, we might - when we officially add Elgg to the appliance library.

Deb Packaging

Sorry to be so slow to respond. It's great to know there's a deb package; I've had take time to deliberate how to take it into account. I've ultimately arrived at the following -

If you could share a way to access it, that would be great. Because this is a student, Curtis Fawcett's, final assessment, I'd like him to weigh the advantages of deb vs source with the implications each will have on his patch. If he has access to both, it'll make it a much more authentic decision.

In either case, the other students will take on the patch separately. Whichever method Curtis chooses, I'll have the other students build with the other alternative.

In any case, having the deb will serve learning and instruction. And we'll be able to post two different patches, which offers more choice when TKL looks for a best option.

So as I see it right now, having access to the deb increases beneficial opportunities all the way around.

Elgg Build

I think I can anticipate the answer to this one, but I want to be sure: Elgg has both a core and a bundle. The bundle includes plugins the provide essential functionality.  We are building the appliance (and build notes) with the bundle. I'm assuming that is the appropriate choice?

On the other hand, there are a number of plugins that provide additional functionality. They may be really useful to the majority of users. My question here is should we use our judgement and include plugins that seem likely to be helpful? I anticipate the answer to this is no, stick with what's bundled.

I just wanted to double check on this so Curtis doesn't have to double back.

Here's a link to the plug-ins included in the bundle as well as the extra plug-ins: http://www.elgg.org/plugins.php.

Thanks in advance for the feedback,


Liraz Siri's picture

Bundling add-ons can add value to an appliance

I think there's value in helping users discover add-ons when there is a good chance they will find them useful, especially if the bundled add-ons can be easily disabled if users decide they don't want them.

We did some research and bundled the most popular generically useful add-ons with the TurnKey appliances for Drupal, WordPress and MediaWiki.

For Drupal and WordPress in particular there are thousands and thousands of add-ons so it can be ridiculously difficult for a novice to figure out which of them are any good. Throw in the added challenge of integration and that's a significant barrier that prevents most users from discovering add-ons that could add a great deal of value to their projects - if only they know about them.

The disadvantage of bundling is that it can increase complexity and expose uses to additional security issues, but that just means you need to make a trade-off and decide intelligently where to draw the line.


OK I did a poor job of anticipating the answer to that one :) I'm going to provoke meaningful dialog with the students to see what they think would provide the best out-of-box experience with Elgg.

Jeremy Davis's picture

My 2c + more info about apt-get dist-upgrade

At the end of the day its your patch so do what you think is best. If Alon and Liraz disagree when it come times for them to package it as a TKL appliance then they will adjust it as they see fit.

Personally I think you are going the right way using the bundle rather than the core. And then to add plugins or not as you see appropriate. If you look at the other appliances, many of them have additional useful plugins already included. Perhaps try Liraz's trick and uses Google trends to see which plugins are the most used (or at least most mentioned online)?

If you would like to err on the side of caution, then perhaps you could look at doing a base patch (using the bundle) with an additional 'plugin' patch that adds the extra plugins that you think would be useful (TKL patches can be nested).

Also (off topic but relevant to you guys) I have some info that I wanted to share with you. I have found out a little more about apt-get dist-upgrade that I wanted to share following previous comments I've made. I have discovered that I mislead you to some degree. Sorry!

The command apt-get dist-upgrade is part of a depreciated method of upgrading Debian based systems. The other part of the 'old' release upgrade path was to edit the sources list to use the new release repos. So using the command will not upgrade to the next release unless you also change the sources list. However what it will do is upgrade versions if a newer version is available. apt-get upgrade will only upgrade to the newest release of the same version.

So for example if we had testpackage-0.1 installed from the main repo and a new bugfix became available (testpackage-0.1-1) then apt-get upgrade would upgrade it (as would apt-get dist-upgrade). However if there were a newer version (testpackage-0.2) available (perhaps from another repo eg backports or a PPA) you would need to use apt-get dist-upgrade to upgrade the version. apt-get upgrade would ignore the newer version and only recognise the bugfix update.

So bottom line is that with default TKL appliances the usage is generally irrelevant (as there will not be newer versions of packages available). But its probably good to know the full story. Sorry again that I lead you astray!

Thanks Jedmeister

You're so consistently encouraging.

1) Add-ons: given your response and Liraz' response, I will provoke the students into advocating for specific add-ons and have them engage in meaningful dialog with one another.

2) Dist-Upgrade: very helpful. I didn't feel that I was steered far off by you, which prolly meant I didn't fully understand (but thought I did) in the very first place. Thanks for taking the time to look further into it. I'm going to paraphrase your explanation and share with the team here.

Appliance Completed

Curtis Fawcett has completed the Elgg appliance for VMware. I'm waiting on the build notes; they will be posted here asap. In the meantime, the appliance and usage notes are posted at http://9while9.com.

So Curtis' agenda is:

1) Post build notes

2) Write conf script, populate overlays, apply patch

3) Bundle patch and post

Guest's picture

Sorry for the lack of communication

Hey guys...Sorry I wasn't in the discussions!  I thought I was subscribed by email on this forums.

It looks like you've made good progress.  Is my original source package still worthwhile?  I need to dig it up from my home computer but can do that sometime this weekend or early next.  

Again, I apologize for not getting any info to you sooner!  Please feel free to ping me up directly to get my attention: @brettprofitt or #Elgg on Freenode.


Elgg Build Notes

Below are the build notes for the Elgg appliance Curtis put together. This is actually a reconstruction. In the course of the reconstruction, we've made some corrections based on the great substantive feedback we received from one user. The resulting application is at http://9while9.com .

I'll make a separate post about the results.


Elgg 1.71

TurnKey Linux LAMP stack

VMware Player (or Workstation) or VirtualBox OSE

SFTP client (we use Filezilla)

Browser (we use Firefox)

Start TunKey Linux LAMP appliance

Open in VMWare or import with VirtualBox.

Upload Elgg

(Using SFTP client) Upload the extracted contents of Elgg to /var/www/ .

Enable mod_rewrite for Apache

a2enmod rewrite

Install libraries for PHP

apt-get install php5-gd
apt-get install php-soap

Create Data Folder

mkdir /var/elgg-data
chmod 775 /var/elgg-data
chgrp www-data /var/elgg-data

Configure Database

mysql -u root
CREATE USER 'elgg'@'localhost' IDENTIFIED BY 'elgg';
GRANT ALL ON elgg.* TO elgg;

Change Permissions on Web Root

chmod -R 777 /var/www #it's not the right way, but it's how it's done for the moment.

Configure DB Settings in Browser

Point browser to the ip of the elgg host.

Enter database user (elgg)

Enter database password (elgg)

Enter Elgg database name (elgg)

Leave database hostname localhost

Leave database table prefix elgg_

Configure System Settings in Browser

Completing install.php sets the ip address/URL of the site. If it's set, we learned the appliance is no longer portable. Install.php prompts for the following:

  • Site name (Elgg)
  • Site description (Elgg Virtual Appliance)
  • Site email address (?)
  • Site URL (followed by trailing slash) (uh oh)
  • Full path to the data directory (/var/elgg-data)

Register in Browser

Display name: admin

Email: use valid email

User name: admin

Password: elggadmin

Sticking Point

One user who tried out the appliance pointed out that the URL (IP address) was in a table, in a field, in the database.

From this we realize we can't bring Elgg to a fully configured state in an appliance - at least, not while providing portability.

Brett was very helpful at #elgg. I know from our prior experience (with ampache) that a fully installed/configured state is preferred. But Brett reminded me of other appliances from TKL that must surely ask for configuration information (WordPress was suggested as one like this).

So I'm stuck on what to do. For the VMs, we can simply halt the install process and wait for the end user to start up and resume the scripted routine. But for the patch, I'm not sure how to proceed.  What we became accustomed to was a mysqldump from a fully configured vm. But in this case, we'd be stuck on the entry for the field "Site URL" and "Site Email".

Is there a model for post configuration script for a tkl appliance? Am I looking at picking up PHP with the students (as the year ends) or is this something that can be handled by bash?

Thanks as always for the kind consideration and patience.


Cash Costello's picture

Possible solution to the sticking point

A plugin could be written that will run once and set the site's url in the database based on how Elgg was called the first time. This is basically what Elgg does in the install process.

Actually, this plugin could run once - immediately direct the user to a setup screen and collect the information for site url and site email there (while bootstrapping by using the calling url as the base url).

Just some ideas that I hope help.

Jeremy Davis's picture

I think a similar situation exists on the Zimbra appliance

although don't quote me on it. I think what the TKL devs did is just use an example url & email (such as example.com & eg@example.com) and have a setup script to change it. Its probably not the cleanest or prettiest method but it should work.

I'm not much of a programmer myself, but surely you can edit database entries from the CLI - and thus make a bash script to take care of that!?

[edit] I missed Cash's post above when I initially wrote this, but that sounds like a neat way to do it. Only thing is how? Way beyond my abilities to comment on that!

Alon Swartz's picture

Dynamic URL in wordpress

Wordpress's home and siteurl are set in the configuration file, not in the database. Not sure why this should be set in the first place, anywhere...
Anyway, in the Wordpress appliance we specified the URL's to be dynamically generated.
define('WP_SITEURL', 'http://'.\$_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://'.\$_SERVER['HTTP_HOST']);
I'm not sure if this same hack would work in elgg, but maybe something similar might.
Hope this helps...

Thanks for feedback, everyone

Cash's solution sounds good, but I think takes more expertise than we can gather before the final three weeks of the quarter come to a close.

Jemeister's solution sounds manageable, since it relies on bash to carry mysql functions. I'll have to check O'reilly and see how to replace the value of fields. And then we'll need some mentoring on how to get the script to run.

Alon, I'm not sure why Elgg what's an URL in the database either. He made clear it had to be there, and was surprised we hadn't come across that before. He suggested setting the site URL for localhost, but pointed out that Elgg will not then be accessible for the network. Your information about WordPress is helpful - if I read it right though, it's php and doesn't address the mysql problem. Do I understand right (I know little to knothing about PHP so I'm guessing)?

Is there a chance that putting $ipaddr for the site url in the db will work? I realize It's a variable for bash, but I thought perhaps....

Thanks all of you for the help.

Rik Goldman

Cash Costello's picture

a plugin for you

Elgg (theoretically) supports running multiple sites off the same install. Each site has its url in the database. To gain this flexibility, you give up a little ease of configuration.


Here's your plugin: http://bitbucket.org/cash/virtual_setup

I'm assuming that the siteurl was blanked out of the database in the virtual machine. First time someone hits the home page of Elgg, I use that url to bootstrap Elgg. I display a setup page that asks the user for site name, site url, site email, and default language. When the user submits the form, I update the database and disable the plugin.

Right now I am manually logging in the admin user. I'll change that - there is some chance that someone else hits the site before the admin, correct?

Cash - Thank you

Cash, thank you.

I can't imagine a user needing access before the administrator logs in. I would assume the admin is the first to access the site.

A little information for me and my students: what language is this plugin coded in? It looks thoroughly like PHP; am I right?

I'll download the plugin and try to reckon what to do with it (haven't installed plugins on Elgg yet).

Maybe this questions could eliminate other questions: to what state should I bring the configuration of the virtual machine? Or should I leave the web based configuration be and let the plugin do the work? Do I have to call the plugin, somehow?

Sorry, I'm learning with the students.

Thanks again for your tremendous help.

Cash Costello's picture


The plugin is written in PHP (as are all Elgg plugins).

This is the intended use:

  • Take current VM that you built and copy the plugin to the mod directory in Elgg
  • In Elgg activate the plugin (http://docs.elgg.org/wiki/Configuration/Plugins)
  • Put the plugin at the top of the list
  • Clear the current site url in the database so that it is blank (This may not be required. I'll have to check on this.)
  • You are now ready to clone/distribute the VM

When the user/admin hits the front page of Elgg in the VM for the first time, this is what happens

  • The plugin grabs the URL from PHP and bootstraps Elgg's configuration (so that it supports localhost, ip address, or domain name)
  • The plugin overrides the front page and displays a configuration screen
  • When the user saves the settings, the plugin updates the database and disables itself

When I get a chance, I'll add more comments and error checking to the code. I also want to change the way I am logging in the admin user.

Great Stuff

Perfectly timed and it looks like what we need. I'll try it out and reserve daft questions til after I've looked for docs.


New Build Notes / Virtual Appliances

New build notes are posted at http://9while9.com that take into account Cash's plugin.  Also, two virtual appliances based on Elgg 1.7.1 and using Cash's plugins are available for download for VMWare and VirtualBox.

Thanks again, Cash. Next step, a patch.

Curtis Fawcett's picture

TKLPatch for Elgg: Conf Script

My name is Curtis Fawcett, graduting senior at Chelsea School. The following is a link to the conf scrpit for the elgg TKLPatch. http://9while9.com/index.php?option=com_content&view=article&id=46:elgg-...

I'd post the whole bundle, but we haven't gotten the patch to start with Cash's plugin enabled.

Rik Goldman will work with the rest of the team to debug and post a working patch.

In the meantime my thanks to Brett, Cash, Rik Goldman, and everyone's support at #ampache.

Elgg TKLPatch

The Elgg (1.7.1) TKLPatch Curtis Fawcett put so much into is now complete and available as an attachment on the original post for the topic.  By Friday, the patch, the iso, and the build notes will be posted to http://9while9.com .

Curtis had support from me and the rest of the class: Jerel Moses, David Walton, and Maurice Quarles.

I need to make mention of other supporters: Brett, Cash, and especially ascheel at #ampache, who always welcomed our questions.

Original post is at http://www.turnkeylinux.org/forum/general/20100506/elgg-appliance

Jeremy Davis's picture

Great work Rik, Curtis and others!

Once again you guys at Chelsea have shown how its done! Nice work! I also really like the way you operate Rik, happy to step outside your own comfort zone and learn alongside your students. That's what education is about IMO! Not rote learning but learning how to learn. How to research. How to go about finding answers to problems. How there are always more than one answer/solution to questions/problems in real life and how to weigh the options and make informed decisions. Absolutely brilliant!

Liraz Siri's picture

Kudos all around

I applied the attached patch to TurnKey LAMP and installed to a new VM without issues. Elgg loads straight into the administration screen. Everything seems to work right out of the box. This will make an excellent addition to the next release of the library.

I've added an entry on the Elgg tklpatch to the development wiki.

Also, I love how the lead developers for Elgg stepped and helped resolve the issues that came up. This testifies to the power of the open source community. Great work everyone!

Liraz Siri's picture

Rational for inclusion of plugins

If I'm not mistaken there were quite a few good extensions/plugins included with the elgg tklpatch. We're going to go over this list again when we add Elgg officially to the TurnKey library (after the first batch of Lucid builds come out), so it would be useful if the students who worked on this could share more information about their rational behind the inclusions of some plugins and not others.

On the Plugins

After productive dialog, we ultimately went with the plugins included in the bundle. The only exception is Cash's plugin for portability with virtual appliances. We chose the bundle because we felt the endorsement from the developers was a strong signal regarding what's useful for common usage scenarios.

There're other plugins I wanted to include: that walled garden, for example, was attractive to me. But students pointed out that it was a useful one for our usage scenario (on a school campus) but perhaps not for others. So in a nutshell, we trusted Brett and his team to know what would be useful for the majority of users.

To see the plugins included in the patch, login to Elgg, select administration, and choose Tool Administration.

The plugins here seem to be featured plugins: http://elgg.org/plugins.php. The plugins here are other community-contributed plugins: http://community.elgg.org/mod/plugins/all.php

I'm sorry we can't be more helpful. We had spirited discussion, but ultimately chose to defer to Brett and his team's choice of plugins to bundle.

Brett Profitt's picture

Plugins: Bundled vs Official vs Community

Rik let me know there were some questions about plugins, so here's a bit of hopefully helpful information.

Elgg is modular by nature, so the core itself has very few end-user features--basically a just a framework.  Elgg 1.7 bundles 33 plugins to provide the most common end-user features expected in a social network, as well as helper plugins that perform garbage collection, provide security filtering on input, etc.  These are considered core plugins.

In addition to the core plugins, there are officially written plugins that are not packaged with Elgg, but may be useful for some users.  The link Rik posted above is deprecated, a remnant when the Elgg core could be downloaded separate to its plugins.  Official plugins exist currently only in SVN (http://code.elgg.org/plugins/).  We're in a transitional period of deciding which ones to EOL, so nothing is public beyond SVN.  Walledgarden is one such plugin.  (For the record, Wall Garden is extremely popular.  Its functionality has been merged into what will be 1.8.)

Community plugins are plugins written by 3rd parties varying wildly in quality.  Tidypics is a great example of a good community plugin...Cash took over dev of Tidypics before he joined the core team, so it now benefits from being maintained by a core dev, though it is not an official plugin.  There are countless 3rd party plugins, and some of them provide interesting features, but my suggestion is to avoid bundling them with Elgg in TKL as it blurs the line between what is officially supported and what is a community addition.

Liraz Siri's picture

Thanks guys this is a big help

I think I have a much better understanding now of the plugins that were bundled with the Elgg tklpatch. Brett, we'll probably take your advice regarding bundling of third party plugins in the upcoming official TKL appliance. At least to begin with.

I wouldn't rule out adding 3rd party modules in the future, depending on the feedback we get from the community. We do bundle some great 3rd party extensions with some of our other appliances (e.g., Drupal, WordPress, MediaWiki) but we only do that when we feel they would be generically useful to a wide audience and are worth the security risks.

Brett Profitt's picture


I agree that there are some very useful 3rd party plugins, but still don't think it's a good idea to package them with Elgg.  I know Debian sometimes has an -extras package to include supplemental plugins, etc for the main package.  Would elgg-extras be something the TKL system could implement for 3rd party or even non-bundled official plugins?

Liraz Siri's picture

Appliances are monolithic

Appliances are configured to run straight out of the box with no setup. However we could To support additional add-on functionality by documenting how to add various modules from upstream or via the package manager.

No worries though regarding the upcoming TurnKey Elgg. It won't include 3rd party plugins. OTOH, I'm not ideologically opposed to maybe adding them in the future, if there is demand for it and the circumstances are right, but let's leave that discussion for later.

Guest's picture

need help

I followed all the instructions but when I get to the system settings I fill out the info and when im finished it directs me to a blank page. does anyone know why and can any one help.this is the website half done http://kilo.uphero.com/install.php it goes nowere after information is filled out. I want to test it out but it just doesnt seem to work for me. I have installed and uninstalled and tryed every thing.

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)