RIP IM?

Considering the recent decline in IM usage thanks mostly to the rise in social networking sites like Facebook and platforms like Twitter, I decided it was time to make some cuts. I usually stay connected to most of the major IM clients (AIM, Yahoo, MSN) concurrently through a multi protocol program called Empathy.


One of the hardest decisions was who should go. I was able to take client performance out of the equasion, so it had to be purely on usage and global coverage. This article at Silicon Alley really helped concrete that for me, Yahoo is still blowing competitors out of the window, even if it's own usage has dropped in recent years.

So it really did turn out to be a fairly easy decision! Empathy also supports Facebook chat login; which is where most of my IM activity happens now anyway.

Dy-na-mite!

What. On. Earth. The Google devs seem to be on some kind of go-faster crack right now. Yesterday they decided to get creative and greet users with pointer sensitive multi-coloured blobs using dynamic CSS3... but only US and European users. People from the remaining 5 continents (yes remaining five) were greeted with the regular logo.

Google's official statement says merely that "today's doodle is fast, fun and interactive, just the way we think search should be".

Adding to the wonderfully hyped-up geek fuelled mystery, the company also tweeted on Twitter, "Boisterous doodle today. Maybe it's excited about the week ahead..."

The following day, it was replaced by a similarly dynamic greyscale Google that filled with colour at each key stroke, letter by shining letter. Aww. They reported, "doodle is dressing up in its brightest colours for something exciting coming very soon".

There was some wild speculation on what this could all possibly mean... Google's September birthday maybe? Or the arrival of HTML5 (even though it was coded in CSS3). Only on the second day did word leak out that it was all to do with Google's new dynamic search feature.

What? Dynamic search? Chrome=Pokeball? Yes. Google have created a mechanism whereby instead of searching once for a term, you are now searching on the input of every single letter. Apparently all this to reduce search times, however slower connections will struggle, and the behemoth's search traffic will most likely sky-rocket, nicely congesting an already busy super highway. I could have however, swallowed all of this, if it wasn't for the fact that Google made this a default option today, forcing users to trial this new technology. Google. Dynamic. Sigh.

Yawn!

2 AM and the UnifiedBlue relaunch is officially complete. The unified wiki originally at the main domain has now been split into subdomains between secure and public content and the wiki software has been changed to Dokuwiki. The wiki-blog entries have now been deprecated and have been manually been moved to Imboogled. The mailserver has been officially launched, and work will shortly begin to move content and subscriptions. Finally the main domain now hosts a gateway page linking to the two wikis, the mail server and the server subdomains.... Phew!

The decision was taken to move from Mediawiki not because it was not proficient enough, but simply that it was not fit for purpose. It was almost too powerful for the limited use the UB requires, and also lacked innate security features that the secure wiki required. As mentioned previously, an OpenID token authentication method was active for the secure wiki previously, however it's integration to Mediawiki was limited, and showed signs of possible security flaws. The new site features secure basic https authentication provided by Apache as a first line and then a subsequent wiki user/pass combination to access content.



The deprecation of wiki-blogs was simple; Mediawiki or Dokuwiki for that matter, have no business hosting blog entries and are not built as such. It was fitting that they should move to the Imboogled blog.

It was an epic move, but one that will help shape the future of UnifiedBlue.

Pokoogle?

Just a quick one Imbooglers. Take a look at this... but sit down first:

Google Chrome Logo + Pokeball = Pokoogle?

Drop It!

After some serious musing over various CentOS server backup alternatives, I finally settled on the cloud for my modus primo. Obviously the server company could have provided either a secondary HDD or a network share to which I could have SFTP'd out, and I could have also gone third party and used SFTP with them... or even stored just critical data locally... but these options were all limited or costly.

Dropbox is a service I've been using for personal backup for some time, it's a free cloud based system, running from Amazon's S3 backend. It provides 2GB initial data offering, expandable on subscription to 100GB. OK, so it does cost in the upper storage bands, but to me $99 for a year of 100GB cloud storage isn't bad at all. I'm also thinking for people wanting to go above 100GB that Dropbox would happy oblige on a prorated basis.

I used both the headless Tips and Tricks page on the Dropbox Wiki and multiple forum entries to finally arrive at the solution.

My first step was to get the Dropbox client. Dropbox release a stable client on their website and a semi-stable client on their forums. I would recommend the latter; cloud technology is constantly evolving and Dropbox seem to fairly stable semi-stable releases... if that makes sense!

After downloading with wget and extracting to home, I started the process with:

~/.dropbox-dist/dropboxd &

As soon as I had done this, the CLI issued me with a verification link, which I could then paste into a local browser either to setup a DB account or link an existing one. When the program detected that this link had been made, it completed execution and returned me to a prompt. Dropbox was running!

You'll see forum posts and web references to the official Dropbox CLI, which allows for starting/stopping etc. This is a useful script, however requires a very much updated version of Python. This was messy, as I had 2.43 already installed, and built parallel version of 7 in order to execute the script. Once both Python's are installed, you can prefix scripts with python (instead of just running them natively) to allow the higher version to be used. As certain system processes are built around Python, removing 2.43 would require other modules such as Yum to be recompiled as well. It would get very messy. I would actually suggest that you forgo this "official CLI" because in reality you will rarely use it, and the cost is not worth the gain.

So the next step was to manually edit some of the Dropbox settings. Without a GUI, the sqlite3 database has to be manually edited. First off stop Dropbox. If you haven't got your script working as above, then just kill the process.

Switch into your /home/user/.dropbox folder and run sqlite3 dropbox.db or... for newer releases such as mine, sqlite config.db.

The database interface will then load and you are ready to tweak some settings! These first two will allow you to remove the upload/download cap. If you are running on a server then you should definitely do this and take full advantage of your backbone. The third option stops Dropbox broadcasting locally looking for other Dropbox instances to P2P with. This is really important in a server environment, because your server company may see any local broadcasting, especially P2P broadcasting, as dangerous or consumptive. There are both new and old SQL statements below as Dropbox have usefully changed their DB structures between releases. If you have a config.db, then use the new statements, else use the old ones!

Old:

insert into config (key, value) values ('max_upload_kBs', 'RjAKLg==');
insert into config (key, value) values ('max_download_kBs', 'RjAKLg==');
insert into config (key, value) values ('p2p_enabled',0);

New:

delete from config where key='throttle_download_style';
delete from config where key='throttle_upload_style';
INSERT INTO "config" VALUES('throttle_download_style',0);
INSERT INTO "config" VALUES('throttle_upload_style',0);
insert into config (key, value) values ('p2p_enabled',0);

Then just quit and save with .quit. You can use the same process to move the Dropbox storage folder. There are scripts for this, however I found them to be outdated and resulted in corruption. By issuing the following commands as above you can change the location:

delete from config where key='dropbox_path';
INSERT INTO "config" VALUES('dropbox_path','/home/ufblue/Dropbox');

Your final step is to get Dropbox to start at startup and run as a sytem process. If you do this, the CLI script will become redundant because you'll be able to use the service dropbox command to either stop, start or restart the service.

For the service script, I used the script available on the Tips and Tricks page. You should be able to find your distrib there. I used the Fedora/Red Hat script and it worked just fine. It's really important to set the users file correctly if you are using symbolic or soft links, as permissions issues can occur. Dropbox looks at parent directory permissions rather than specific file permissions, so you can work around it that way, but for recursive permission liberated structures, you'll have to run the DB client as root. I'm really not sure of the ramifications of this, and can only entertain that the Dropbox company could potentially exploit this at worst.

If security is a concern, there are always the options of using TrueCrypt or encFS and then Dropboxing the encrypted volume in it's entirety. I can see why this is an attractive option, because you are still risking unencrypted data to both Dropbox and ultimately Amazon's S3 service.

The possibilities are then fairly limitless. Remember the you can use softlinks to link files into your Dropbox directory system wide, and these will then be included in the backup. Remember that Dropbox contains a 30 day revision history, so every time a file is changed, it's revision is stored. This got me to consider the possibility of Dropbox watching an active mySQL database. I'm not sure how this would work however and even if the files would be locked? There is no data about this on the net right now so it might be worth experimenting.

Consider the additional server based possibilities though, from torrents, to email stores, to databases, to VM instances... even more if you are running a local client and then you have a smooth replacement for SFTP or WebDAV... the options are limitless, and would provide an outstanding interface for any client. It's only a matter of time before we see more server-side application of this, but beware that although this will bring ease of use, it will also bring with it cost as people start to recognize it's value. DB is already more than Googleworthy, and I am sure they've been approached, but I guess for now they are holding out for their own reasons... for now.

Dropbox on their part are doing a stellar job at promoting the various uses, and don't seem to mind any of it's applications. There is even a DB client for smartphones now, enabling you to literally sync on the go. To me, effective cloud storage application is an important a milestone as VM. Your store of information is now truly dynamic, truly transversal. Information has ascended.