elgg_logo1 Here’s the scenario; you’re a developer and you’ve been asked to do some work on an existing Elgg site, or you’ve built an Elgg site with some complex plugin interdependencies that you need to copy on to a live site.

In both cases, this primarily involves copying the source code and Elgg database from one site to another, here’s how…

Source code and database

  1. Install the source code for your project; scp it from the other site, git clone –recursive, whatever…
  2. On the site you’re copying, take a dump of the database. You can look in your engine/settings.php for the database username and password:

    mysqldump -u your-db-user -p elgg_database > database-dump.sql

  3. Copy this file onto your new host.
  4. Create a new database and install the Elgg database into it, in the mysql client do the following:

    create database new_elgg_database;
    grant all on new_elgg_database.* to `db_username`@`localhost` identified by 'db-password';
    use new_elgg_database;
    source /path/to/database-dump.sql

  5. You should now have a local copy of the elgg database installed, but in order for it to work you need to change a few paths. Firstly, alter your dataroot and site location details in your prefix_datalists table:

    update elggdatalists set value="/path/to/elgg/" where name="path";
    update elggdatalists set value="/path/to/dataroot/" where name="dataroot";

    Don’t forget the trailing slash on the paths!

  6. Next, you need to update the site url in the site object stored in the prefix_sites_entity table. For the vast majority of people (who only have one site object) this will be straightforward, for others, you might have to use a slightly different query in order to get all sites working as expected.

    update elggsites_entity set url="http://localhost/path/to/site/";

    Again, don’t forget the trailing slash on the URL!

  7. Finally, alter your copy of engine/settings.php to reflect your new database details.

When I view my site, all the CSS is broken!

This is almost certainly a mod-rewrite problem.

  • Firstly, check that it’s installed and enabled, and that overrides are enabled for your site URL (common problem if installing into ~/public_html).
  • Next, make sure that your RewriteBase is configured. If you’re installing into a subdirectory on a domain (e.g. http://localhost/~marcus/elgg/) you’ll need to set the RewriteBase in your .htaccess file accordingly, in the case of my example, RewriteBase /~marcus/elgg/

Files

The above should get you up and running with a usable site for testing, however if you want to fully migrate a site, you’ll also need to copy the data directory across.

  1. Using rsync or similar copy the complete data directory from your old site’s data directory to the new.
  2. Ensure that the directory, subdirectories and files are read and writeable by your web server’s user.
  3. Flush the caches. This is important since Elgg caches the locations of template files and other data in the data directory, which obviously will cause issues if you copy a cache file from another location! If the admin panel has become unavailable at this point, deleting the system_cache directory from dataroot by hand will often restore it.

Happy hacking!

On Sunday, myself and a few friends went to the TEDx event in Oxford.

TEDx, for those who don’t know, are TED style events organised by interested parties. They happen all over the world, and are usually pretty popular. This one packed out the New Theatre in central Oxford, which is no mean feat.

The speakers spoke on a number of subjects; from neuroscience to artificial intelligence. Some speakers were inspiring, others were… confusing… but all were interesting.

Interestingly, the speaker that sparked the most conversation over lunch and after the event was probably Laura Bates from the Every day sexism project. The stories she relayed shocked us all; with the men in the audience seeing this as new, but with the women nodding along in bitter recognition.

Myself, I was aware of similar horrors through the various “Women in Technology” conversations I have had, where every single woman I spoke to could relay situations where an actual crime had been committed, but pretty much shrugged it off as something that “happens”. Still, it was still shocking, and through our discussions after it seems that there is a variation of the observer effect going on for the men in our group – that is, the very act of us being present, means that the acts won’t occur to the women around us.

A new trend that was highlighted in the talk, which I found interesting, is that now the abuse seems to be often couched in a joke (which is clearly not funny), but means that the perpetrator can play the victim when the woman objects. I’ve seen this a couple of times in tech circles, but it’s clearly a growing trend.

One thing I wish was covered in her talk (although, perhaps it’s a complex subject for 15 minutes), is what can we actually do to address this? Particularly, what can we as men do? This is clearly a massive problem, and I know we seem to be losing ground in the tech world, but it seems the equality cause is losing ground elsewhere as well.

Depressing stuff. How do we fix it?

So, I recently performed some long overdue upgrades on my work computers, which involved performing a complete from scratch rebuild of the house server.

This involved, among other things, moving the OpenLDAP directory in which I store, among other things, my email address book. Easier said than done.

Previously, when I had done this, it was a simple matter of installing slapd, copying /etc/ldap and /var/lib/ldap and restarting slapd. This time proved more tricky; slapd initially spat out errors complaining that the database was corrupt. Check out https://www.sapphire.net/mss/incident-response-services/ for more information on the benefits of improving your cybersecurity at work.

Fixing the corrupt database could be done in one of two ways: 1) deleting /var/lib/ldap/DB_CONFIG, forcing slapd to recover the database, or 2) running db_recover directly. After this was done, slapcat displayed the directory as expected, and slapd restarted, however any queries on the database – via phpldapadmin, ldapsearch or the email address book – caused the answering slapd process to lock with no error. Each subsequent query would cause another slapd thread to lock, eventually bringing down the whole ldap server.

Hmm…

I’m not entirely sure what was going on, perhaps it was a bug in my particular version of slapd, or perhaps it was the fact that I was moving from 32bit to 64bit, who knows. I eventually found a solution, and I write this down primarily as a note for myself.

The workaround

    1. Install slapd, copy the config and db over, then run a db recover on the database:

      db_recover -v -h /var/lib/ldap

    2. You should now be able to list the directory with slapcat, so dump it to a file:

      slapcat > /tmp/directory.ldif

    3. Next, we need to nuke the database and force slapd to create a fresh blank database. There’s probably an easy way of doing this, but the quickest way I found was to delete /var/lib/ldap/* and reinstall slapd:

      cd /var/lib/ldap; rm *; apt-get remove slapd; apt-get install slapd.

The apt-get remove will remove the program but by default it’ll leave your configuration intact, if it doesn’t you might need to copy your config back as well.

  1. Next, stop slapd and import your ldif file.

    /etc/init.d/slapd stop; slapadd -l /tmp/directory.ldif; /etc/init.d/slapd start

If you had the same problem as me, your OpenLDAP directory should now be back in place, imported into the new database. For me, my address book now functions correctly and phpldapadmin no longer hangs.

There are probably easier ways, but I was tired. Let me have your thoughts in the comments below!