London – April 2014

My trip to London, in photos. Not pictured: Freezing cold wind, tons of advertisements everywhere, an efficient metro rail system, and the general sense that everything’s just put together properly.

Confidence shedding

I don’t get involved in politics, as a general rule. It’s messy, it’s scary, and (to quote my 11th grade English teacher), creates more heat than light. A pertinent maxim, given the current load shedding. For the first time since 2008 (that’s 6 years), Eskom is cutting power again.

Now, I get it – shit happens. Every organization, every level, every scale, shit happens. It doesn’t particularly bother me that we’re enduring a rotating blackout. What bothers me are the statements from the politicians in charge of ensuring these crises don’t happen:

“We expect the rains will subside and as the rain subsides obviously we’ll be back to normal. That’s the timeline we’re more or less expecting to have a return to normality,” Molewa said.

It’s absurd that our national energy supply could be affected by the weather. I mean, other countries endure tornadoes, hurricanes, earthquakes, nuclear meltdowns, and actual acts of terrorism, and they manage to keep the lights on. So that worries me, but not as much as this:

“It is a question of utilisation, that’s why cabinet… said we are making a call to all South Africans to ensure we use energy efficiently.” #

Or, put another way: There’s plenty of power available, if you use less of it. Given that electricity is an artificial resource, and that you can produce more of it given the correct facilities and resources, the question is: where are those facilities?

In fact, where is the sense of urgency to say “well, crap, we have to fix this”? Saying that there’s plenty of energy and we should simply use less, is horrifically short-sighted. In what market (hell, in what universe), does it become the consumer’s fault that demand exceeds supply?

Jackie Chan is not amused.
Jackie Chan is not amused.

By that logic, they need never expand our national capacity again. Every time there’s another shortfall, they just trot out the “efficiency” rhetoric, somehow making it everyone else’s fault for using too much electricity – electricity that we’re paying a ridiculous amount for in the first place, because the vendor has failed to create adequate capacity.

What a circus.

User authentication in Laravel 4.1

Laravel ships with Eloquent’s user authentication built in, but I had to do a little extra massaging to get it to work.

First, I had to create a migration that looked like this:

Schema::create('users', function($t) {
  $t->increments('id');
  $t->string('username', 16);
  $t->string('password', 64);
  $t->string('email', 96);
  $t->timestamps();
  $t->datetime('deleted_at'); // For softDelete
});

Then I had to edit app/models/User.php to add these variables to the User class:

protected $softDelete = true;
protected $guarded = array();

Then I created app/database/seeds/UserTableSeeder.php with:

DB::table('users')->delete();

User::create(array(
  'email' => 'foo@bar.com',
  'username' => 'admin',
  'password' => Hash::make('password')
));

And finally I added this to app/database/seeds/DatabaseSeeder.php:

$this->call('UserTableSeeder');

I then ran:

php artisan migrate
php artisan db:seed

And used the rest of the authentication system as prescribed by the documentation.

New toys: 2014

I’m on leave. Or at least I’m supposed to be, but beaches and cocktails don’t suit me very well. So instead I’m updating my technology skill stack, learning a whole bunch of new stuff along the way:

PSR-0
Not actually a technology, but I’ve managed to structure a new PHP app to follow the PSR-0 autoloading standard, which immediately enabled the use of:

Composer
Which is actually pretty cool. Still an issue or two with memory handling, but it’s fantastic to be able to install all sorts of supporting software in one go – especially when included in a:

Vagrant
file. Vagrant is awesome, pure and simple. My largest Vagrantfile, when run, produces a box, installs software from 3 sources (apt, pear and composer), creates mysql databases with random passwords, and runs my application-level provisioning (database migrations mainly).

I love Vagrant so much, I’ve started applying it to other people’s projects!

Python
I finally got around to writing some rudimentary Python – first, a script that used urllib2 and basic regex to scrape stuff off a webpage. Then, a more complex use case, when I started using:

Flask
Which is another fantastic toy. Not dissimilar from Rails’ WEBrick, Flask makes it easy to build simple web apps. And I’m sure, with enough application, more complex ones. I’ve just been tinkering with it, but it looks really useful for building simple APIs.

Git
I’ve been using Git for ages, but only the bare basics – init, remote add, commit, push. This year I’ve actually started using (Github-specific) forking, branches and pull requests, and it feels great to contribute some code back to the open source arena – even if they’re only tiny patches for now :)

LESS
Good lord, LESS is what CSS has needed since inception. It’s hard to overstate how much time it saves – both in writing CSS, and in reading complex stylesheets. I can’t imagine not using LESS in any of my future projects.

node-webkit
There’s a growing number of solutions for running HTML5 applications on your desktop. Adobe AIR’s been around for a while, but it’s monolithic when compared to current solutions, and node-webkit is one of them – two files, one command, and I have a packaged app ready for distribution, backed by the full power of webkit and nodejs (which I have yet to learn).

Phinx
A lifesaver if there ever was one – it’s PHP-based software for doing MySQL database migrations. Migrations are usually nothing more than a feature included in larger ORMs, but when you just want migrations, it’s damn near impossible to find a good system. Until I came across Phinx, obviously, which has a CLI client and is ridiculously easy to install and use.

Monolog
Never going to write a custom logging library again. In about 5 minutes I had monolog installed, and configured to write events to two files on disk, plus send critical alerts via Pushover.

What I’m most impressed by, though, is that every new technology above is open-source. I don’t know much about the Sun/Eclipse ecosystem, but I know that Microsoft is basically playing catch-up at this point. NuGet, WebGrease, escalating versions of MVC and EF, all of it iterates frantically in the wrong direction, requiring more and more updates to the monolithic entity that is Visual Studio.

The future seems to be moving in the opposite direction – singular packages, dependencies and integration. That’s what PHP, Python and Ruby all have in common now – package management with dependency resolution, all of it managed by the system default command prompt, none of it locking you into any specific IDE.

And I still haven’t gotten around to rails, argh.

Run a test instance of ThinkUp with Vagrant

Right now, Vagrant is steadily gaining the lead on list of things I like (it’s still a few months away from topping espresso and cyberpunk anime, though), and I’ve started adding Vagrant to just about every project I’m working on.

Including other people’s projects! Like ThinkUp, which takes social media monitoring and puts it on your own server – not that the reach of global social monitoring systems is unnerving in any way.

Assuming you’re using a *nix OS and have git and Vagrant installed:

git clone git@github.com:woganmay/ThinkUp.git
cd ThinkUp
git checkout vagrant
vagrant up

Should get you a precise64 box running that you can access on http://localhost:8080/ – with the following default user configured:

  • Email: vagrant@vagrant.local
  • Pass: thinkup00

thinkup running

You can actually create the oAuth apps with localhost as a URL and callback – or, at least, I was :)

Tested on:

  • OSX 10.7.5
  • VirtualBox 4.3.6 r91406
  • Vagrant 1.4.3

How to set up public key SSH authentication

Passwords are so 2001, and quickly become a major pain in the neck when you’re routinely shelling into Linux servers to do stuff. As a rule, I set up publickey authentication whenever I’ll be working with a server, and there seem to be so few human-friendly articles on what it is, and how it works. So here’s mine!

What is “Public Key Encryption”?

There’s a long, complex answer that stretches back to the dawn of computing, cryptography and impressive neckbeards. The short answer is, it’s a way of securing information in such a way that anyone can lock a file, but only one person can unlock it.

You’ll always have two keys: A public key, and a private key. The public key can be placed anywhere – in email signatures, on web pages, billboards – and the private key has to remain private. To make this a bit more accessible, think of the public key as a padlock, and the private key as an actual key:

lock and key

One key, one lock, simple. You put that lock on something you want to secure, and then you use the key to open it – this box, for instance:

lock and key 1

So now, you need to provide your private key in order to unlock the box. Where public key encryption comes in useful, is that you can copy the lock (public key) as many times as you want, and use it to lock whatever you want:

lock and key 3

And now you can use the same private key to unlock all of those. There’s a lot more to asymmetrical encryption, but the off-hand, casually derogatory mention of neckbeards has already filtered that audience out, so we move on:

Public Key Authentication for SSH

When you connect to a server, the first thing it does (after all the other things) is tell you what authentication mechanisms it supports. There are loads, but two common ones are “password” and “publickey”.

SSH Login, verbose

Right now, you’re not using public keys, so your client prompts you for your password, and you get logged in:

SSH session, logged in

But, to extend our analogy, we can set up public key authentication – so instead of a password, you use your private key to unlock the session:

Keys (3)

Best part is, you can have this happen entirely automatically – so to connect to a server, all you have to do is:

ssh [username@]remoteserver

And you’re connected and authenticated without any further intervention on your part. We’ll do this by putting a public key on the server, and telling the SSH system to offer it you as a login method.

Setting it up

To set that up, there are 3 things you need:

  1. A server that supports publickey authentication – which is a default, and if it’s disabled on your server, there are more serious questions you should be asking your administrator.
  2. An account on the remote server – which I take for granted you already have
  3. A public/private key pair on your local machine.

We’ll start by generating a key pair. If you’re on Windows, you’ll use PuTTYgen for this (which requires an article all on its own, and won’t be covered here), and if you’re on a *nix OS like OSX or any Linux variant, you’ll simply do:

ssh-keygen -t dsa

And hit enter for every prompt that comes up. By pressing enter through everything, it will create a pair of files in a special folder, and it won’t lock the key with a passphrase.

(The fact that I even used the phrase, “lock the key” should indicate that there’s more to this than this cursory breeze through the subject of encryption, so do your own homework if you have questions.)

Take a look at them like so:

cd ~/.ssh
ls

That should list 2 files – possibly more, if you’ve been using the system a while:

id_dsa    id_dsa.pub

The first one is your private key – under no circumstances should this key be shared, ever. The second is the public key – our padlock, which we’ll be uploading to the server like so:

scp id_dsa.pub remoteserver:~/

What does that mean?

  • scp – Secure CoPy, which can move files over SSH connections
  • id_dsa.pub – The file we’re copying
  • remoteserver – The hostname of the target, and:
  • :~/ – on the target (:), copy it to the user home directory (~/)

When that’s done, connect to the server like normal:

ssh remoteserver

If it’s never been run before, run ssh-keygen here, too – it creates the folder structure which we’ll need, in order to do:

cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
rm ~/id_dsa.pub

That reads the content of the file and appends it to authorized_keys, which is what the SSH server reads from when accepting incoming keys. The second command deletes the file (since we no longer need it).

Now, exit, and try shelling in again. If everything works out, you’ll be dropped straight into an authenticated shell session, no passwords necessary.

Digital Polymath

Follow

Get every new post delivered to your Inbox.

Join 155 other followers