IXP Manager – Planning for v4

A lot has changed in the 3 to 5 years that the decision was made to use certain libraries / technologies / methods on IXP Manager.

In previous major version changes we made some serious architecture changes in one sweep. For example v2 -> v3 saw the complete migration from Doctrine ORM v1 to v2 (which was a change from the Active Record pattern to the Data Mapper pattern).

Today, IXP Manager is a very large project and to do such a sweeping migration in one go would stifle development, break something that isn’t actually broken and take a lot of time.

But, sticking with older technologies and libraries has negative effects also. It creates developer apathy (for which I can personally vouch for). It also provides a major stumbling block for bringing on new developers and contributors (who wants to learn Zend Framework 1 now which has been EOL’d for sometime?).

So, our plan for v4 is to bring in new technologies without throwing away or rewriting everything we have.

IXP Manager is a MVC application that currently uses Doctrine2 as the Model, Smarty as the View and ZF1 as the Controller. Doctrine2 is still current and won’t be changing.

Smarty will remain as the view engine for current / unmigrated functionality. But Smarty is… oh my God… soooooo bad. v4 will default to Twig which is more modern and far better structured from a programming point of view. Coupled with the new framework, it will also allow for a nicer means of skinning. For the interested, Twig has some very nice features including layouts, macros and also some nice security features.

ZF1 has served us well but it’s been EOL’d and is now quite outdated. The new hotness in PHP is Laravel, which I’ve been using to great effect for a while now. Laravel show cases some of the new and best functionality of PHP and using very modern techniques (such as IoC).

But more importantly, Laravel will let us do things in a much different and much more flexible manner for the IXPs using IXP Manager. Some of these include:

  •  Job queues: built-in and simple (to use) support for job queues via Beanstalkd and others. Queuing jobs will provide functionality that we at INEX have been looking for (and it’s also an FAQ from other IXPs) -> reconfiguring services on demand (or, at least quicker than a twice daily cronjob).

Put this together with:

  • Events: Laravel allows us to trigger events and subscribe to them.

A key example of queue and event functionality would be that a change to a VLAN interface (such as checking the route server client box) would trigger a vlan interface changed event. One subscriber to this event would be the route server configuration manager. Based on the VLAN change, this event handler can then queue events. The route servers themselves would monitor these queues and rebuild / reconfigure the route servers appropriately on demand.

Similar handlers for route collectors, DNS ARPA changes, etc. can offer much more real time control of all the services at an IXP.

IoC decouples logic from the controller. What this means is that IXPs who want to do things differently than INEX (let’s say use Cacti instead of MRTG as an example), can swap out MRTG with Cacti with one line of code (that’s assuming we write contracts – interfaces – for such handlers and a Cacti version is coded of course!). But that’s the kind of power and flexibility we’re looking to bring in.

Other features Laravel provides includes:

  • Much improved unit testing on controller actions. Right now, we spin up Apache and MySQL to test controller actions. This is no longer required with Laravel making tests easier to write, more robust and more focused with built in support for mock objects.
  • A much nicer and more structured way of creating command line interfaces rather than the quite clunky way we have of doing it currently.
  • A much more natural way to develop REST API endpoints with json:api compatible responses.

And that leads us to the front end. Right now, the front end and the back end are tightly coupled. During the development lifetime of v4, we want to move more towards an API is Everything back end with a decoupled front end.

This separation will again aid unit testing providing a more reliable and robust IXP Manager. It will allow other IXPs to create their own front end on member facing portals or, even, move to IXP Manager as their back end system but retaining investment of current member portals by adding new features from IXP Manager through API endpoints. It will also allow existing systems in IXPs to integrate with IXP Manager to provision services and ports for example.

One of the bigger tests of this plan will be the (long awaited and badly needed) revamp of the member facing area. We’re currently planning the UI / UX of this to deliver key information to members in the best way possible. This will include Bootstrap v3 which is fluid from the ground up so mobile browsers to wide screen browsers should be supported naturally.

During the early stages of v4, we’ll create the API endpoints necessary to support the member portal functions and then create a front end on that using Ember.js.

Other changes in v4 will include:

  • A switch from package management via Git sub-modules to composer and Packagist as is current standard practice.
  • Introduction of Bower for front end asset management.
  • And we’ll need a task runner for pulling everything together – for that we’ll use Grunt (although that’ll mostly be a development / release prep tool rather than an end user requirement).

So, that’s what we’re looking at! It won’t happen overnight but we’ll continue our policy of release early, release often and we’ll update the documentation and provide complete upgrade instructions at the appropriate times. Some of the above is also subject to change depending on practical experience / issues as we move towards it.

Comments, ideas, etc. are all welcome.

Posted in INEX, IP Networking, IXP Manager, News, OSS, Software, Work | Tagged , , , , , | Leave a comment

ViMbAdmin and Vacation / Out of Office Auto-responders

An FAQ post for future reference because, well, it’s a FAQ!

ViMbAdmin is primarily a database frontend for managing virtual mailboxes with mail services such as Postfix and Dovecot.

A frequently asked question is does it / can it support vacation / out of office auto-responders. The short answer is no.

The main way to handle OOO responders is via SIEVE (e.g. Dovecot’s version). To put a front end on this, you need a server configured for external SIEVE management and a client with SIEVE support (which ViMbAdmin does not have).

I’ve done it in three ways in the past:

  1. directly editing the .dovecot.sieve file. This is only really good for people with access to the server and some clue.
  2. Using a Thunderbird plugin allowing editing of SIEVE files. Again, clue required.
  3. For one customer, they can do it via the SoGO web interface we installed for them. This is a very nice interface for people migrating from Exchange.

We did look at fixing a Thunderbird Out of Office plugin but didn’t get very far.

What we all need here is for someone for write / sponsor a decent SIEVE based Thunderbird OOO plugin. Here’s some prior art: https://addons.mozilla.org/en-US/thunderbird/addon/sieve.

Posted in OSS, ViMbAdmin, Work | Tagged , , , , | Leave a comment

Cordova, Facebook, Android and no Eclipse

This post relates to creating an Android application with Facebook support (via phonegap-facebook-plugin using Cordova 3.5 and, specifically, without Eclipse. Most existing documentation expects you to spin up Eclipse to link the Facebook libraries – but, we’re using an automated build system with Grunt so that’s not a possibility.

Firstly – the steps to get it working:

  1. Add the Cordova Facebook plugin:
    cordova plugin add https://github.com/phonegap/phonegap-facebook-plugin \
        --variable APP_ID="1234567890" 
        --variable APP_NAME="Test App"
  2. Edit platforms/android/project.properties and add:
    android.library.reference.2=FacebookLib
    

    where n is the next available reference index. Also note the target parameter here as you’ll need it next:

  3. Update the Android project for the plugin:
    cd platforms/andoird/FacebookLib
    android update project --target android-19 -p .
    

     where android-19 should match the target parameter from above.

  4. Prepare and build your application:
    cordova prepare android
    cordova compile android
Posted in Recipes, Work | Tagged , , | Leave a comment

Net Neutrality

Posted in News | Comments Off

Shatter’s Donation

Our Taoiseach – who cannot seam to string a coherent sentence together most of the time – said, if you can parse it, the following of Alan Shatter’s donation:

“I think nobody can complain about the benefit that the children who are in the care, the subject of attention from Jack and Jill, nobody can complain about it.”

He was of course referring to Alan Shatter donating the €70,000 severance pay he is due to the Jack and Jill foundation.

What’s effectively happening here is that Alan Shatter, a member of the governing party and a cabinet minister until recently, is effectively saying that he doesn’t trust his own partners in Government to spend this money more wisely than he can.

Typical of Shatter’s arrogance. And a damning critique of Kenny.

Posted in Politics | Tagged | Comments Off

Development Contracts

At Open Solutions, we tend to undertake a lot of fixed price contracts to develop web applications. In fact, clients usually insist on fixed price contracts as they want to know in advance what the bill will be.

However, fixed price contracts have big negatives for both parties:

  • for the client, a fixed price contract can often limit them to their earliest ideas. Now, as a service provider, we want to be flexible and so we’re happy to chop and change as a project develops. But, this leads to:
  • for the service provider, if change and revision requests are not carefully managed agreed and billed for, the service provider could very quickly end up making a loss on the contract and thus find themselves in the position of funding their clients project!

To this end, we’ve recently been reviewing various web development contracts and have found some nice inspiration for basing our own on.

Following the success of Killer Contract, Andy wrote a plain language NDA (also available as a Gist).

Posted in How-tos, Links, Work | Tagged , , | Comments Off