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
Forum: 
Tags: 
Liraz Siri's picture

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.

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.

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,

Rik

Liraz Siri's picture

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

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!

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.

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

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.

Materials

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 DATABASE elgg;
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

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.

Rik

Cash Costello's picture

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

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

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...

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

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.

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.


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.

Rik

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

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.

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

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

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

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.

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

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

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 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.

Add new comment