Ridiculously addictive:
Data & Picard | Pogo
Ridiculously addictive:
Thoughts, ramblings and rants…
Ridiculously addictive:
I watched the first episode of Star Trek: Voyager in my Junior Cert year in the function room of a pub with the local Star Trek fan club in early 1995. It was recorded in the US on a NTSC video tape, mailed over to the club runners in Limerick, copied and sent to local clubs around the country and then played on a compatible VCRs.
It was a different era – but, on reflection, a much more sociable one. These episodes, straight from the US, were enjoyed in groups with a few drinks. The new upcoming series will must likely be watched instead in darkened rooms, alone and as downloaded via BitTorrent (every bit as (il)legal as our Voyager viewing).
Voyager came around at a fairly hectic time for me. Started in my Junior Cert year, season 3 hitting my Leaving Cert year and the remaining seasons clashing with a fairly hectic college social life. I don’t think I ever missed an episode but it was certainly a non-linear erratic viewing. It left me with an overall poor impression of the show. So much so that I’ve never rewatched the series in order and in a short space of time until just these last two months. Almost twenty years later.
And that’s a pity. On rewatching, it was a great show. It also bodes well for what Bryan Fuller will do with the new series, Star Trek: Discovery.
So, some early, unedited and initial reflections on the rewatch:
This is a post in the series Daily January 2016 – generally rushed and unedited.
Windows usage is mostly an occupational hazard for access to tools such as Microsoft Visio, VMware vSphere, proprietary VPN software, XenCenter, etc. We tend to use it on an as-needed basis via Parallels on macOS.
For a virtual machine with very little software, the assigned 60GB drive was full. Windows doesn’t display folder sizes in its File Explorer and so TreeSize Free proved a very useful tool for locating the space hogs.
This led me to a system and hidden directory: \Windows\Installer
. It had amassed 30GB or orphaned update files. 50% of my allocated space. To clear this up, PatchCleaner worked a charm.
Good hunting.
In the many years I’ve been using the traditional LAMP stack, I’ve successfully managed to avoid having anything to do with MS SQL server. Until 2016. This year I’ve had to work quiet a bit with it – administration, backups and, now, scripted queries from Linux with PHP.
I suspect I’m (a) lucky I haven’t had to do this before now; and (b) that Azure seems to have pushed Microsoft into greater Linux based support for MS SQL. The evidence? This open source Mircosoft repository with a MS SQL PHP binary driver for Linux released just a few months ago.
NB: installing the Microsoft PHP driver is different to installing the Microsoft ODBC driver for SQL Server on Linux. These may even be incompatible.
For me, I just took a standard Ubuntu 16.04 install (64bit obviously) with PHP 7.0 and downloaded the latest MS PHP SQL extension (for me, at time of writing, this was 4.0.6. When you untar the Ubuntu16.tar
file, copy the .so
files to /usr/lib/php/20151012/
and then create a /etc/php/7.0/mods-available/msphpsql.ini
file with contents:
extension=php_pdo_sqlsrv_7_nts.so extension=php_sqlsrv_7_nts.so
Note that the tar also contains two ‘ts’ versions of these files. Trying to use those resulted in errors. Link this for Apache2 / CLI as required. E.g. for PHP CLI:
cd /etc/php/7.0/cli/conf.d/ ln -s ../../mods-available/msphpsql.ini 20-msphpsql.ini
You can confirm it’s working via:
$ php -i | grep sqlsrv Registered PHP Streams => https, ftps, compress.zlib, php, file, glob, data, http, ftp, sqlsrv, phar PDO drivers => sqlsrv pdo_sqlsrv pdo_sqlsrv support => enabled pdo_sqlsrv.client_buffer_max_kb_size => 10240 => 10240 pdo_sqlsrv.log_severity => 0 => 0 sqlsrv sqlsrv support => enabled sqlsrv.ClientBufferMaxKBSize => 10240 => 10240 sqlsrv.LogSeverity => 0 => 0 sqlsrv.LogSubsystems => 0 => 0 sqlsrv.WarningsReturnAsErrors => On => On
And, finally, for using it, following the the sample scripts from the repository worked a charm.
For another INEX project, I was asked to put together a timeline for IXP Manager – an open source application for managing Internet eXchange Points. Reproduced here:
IXP Manager was originally a web portal written in PHP by Nick Hilliard in 2005. It was a basic database frontend that just did fairly simple CRUD (CReate, Update, Delete operations) and allowed our members to log in and view their traffic usage graphs.
Around this was a ton of Perl scripts that sucked that data out of the the database and created configuration files for route collectors, graphing, monitoring, etc.
The major achievement of Nick’s original system was the database design (the schema). The core of that schema is still the core of IXP Manager over 10 years later.
I started in INEX in 2007 and started to expand IXP Manager using what was becoming a more modern web development paradigm – Model/View/Controller with a framework called Zend Framework.
There wasn’t a grand plan here – it was just “as we needed” organic growth over the coming years.
In 2010 we decided what we had was actually pretty good and could be very useful for other IXPs. We got committee approval to open source the software and we released IXP Manager V2 in 2010 under the GPL2 license (GNU Public License v2).
This license essentially means anyone can use the software free of charge but also that they should contribute back improvements that they may make. The idea being that INEX would eventually benefit from other IXPs contributing to the project.
Open sourcing a project doesn’t mean it’ll be successful though! What we didn’t do in 2010 was put infrastructure around it such as: presentations at IXP conferences, mailing lists for user support, decent documentation, etc.
We corrected all that and re-released an updated version called IXP Manager v3 in 2012. This time it took off! We also started collaborating with ISOC (The Internet Society) around this time to help start-up IXPs (mainly eastern Europe and Africa) use IXP Manager.
Some established IXPs also contributed money towards development of missing features – most notably LONAP in the UK – and these new features fed back into INEX.
We’ve worked hard on v3 and it’s developed well since with many new features and improvements. Sometime in late 2016 – maybe even this month – we’ll release v4 which is a major leap forward again and should hopefully attract new users and developers.
INEX is very well regarded in the IXP community as an exchange that is well run and both operates and teaches best practice. All of what we’ve learnt running a good exchange has fed into IXP Manager and it helps those IXPs that use it to implement those same good practices. IXP Manager has helped raise INEX’s reputation even further.
Lately we’ve begun to realise that as a small team we can’t do it all ourselves – the more exchanges that use it, the more requests for help and features we receive and as a result, new developments take a back seat.
To try and improve this we launched a new website in 2016 – http://www.ixpmanager.org/ – and issued a call for sponsorship so we could hire a full time developer. The ‘we’ here by the way is my and Nick’s own company – Island Bridge Networks. We’re doing this on a purely cost recovery basis. I’m delighted to say we’ve just about reached our funding goal with three top line sponsors all contributing about €20k each – ISOC, Netflix and SwissIX. The hiring process has now begun!
I’m also delighted to say that there are 33 exchanges around the world using IXP Manager /that we know of/.
I was asked to write a personal profile for INEX in <= 300 words. Reproduced here.
If you want to confuse Barry, ask him where he’s from: born in Cork, spent his formative years in Galway and married into Dublin. He got a honours degree in Maths, his first love, from NUI, Galway in 2001 and went on to do four years research in information theory in UCD’s Computer Science department.
In 2005 he took a job with imag!ne to help build their ADSL broadband service from scratch to a position where it supported tens of thousands of subscribers. Barry branched out on his own in 2007 when he formed his own consultancy business, Open Solutions, which continued working with imag!ne as well as building up a portfolio of network, VoIP and web application development customers.
It was 2008 when Nick Hilliard, INEX’s CTO, approached Barry to provide a couple days operational support to INEX. Little did Barry realise what a huge part of his life INEX would become – both here in Ireland supporting INEX’s infrastructure and membership but also as part of the larger European and international IXP community.
Barry is the lead developer of IXP Manager (http://www.ixpmanager.org/) – a full stack management system for IXPs which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. INEX is very proud to say that this project is now in use at over 33 IXPs and has grown legs of its own with the wider community sponsoring a full-time developer.
INEX has always been happy to help other IXPs and, through our relationship with the Internet Society (ISOC), RIPE and Euro-IX, Barry has travelled to countries with a less developed internet infrastructure to advise on best practice, has delivered a number of IXP Manager workshops and contributes to policy development.
There are times when you need to set a PHP array value from evaluated PHP code. Sometimes, you need to this using variables that won’t conflict with the current scope and with throwaway code that you won’t need again – so a closure is ideal.
Typically, you’ll need to assign the closure to a variable but this will negate the above requirement to not interfere with the current scope.
Here’s a way to do this:
return [ 'key1' => call_user_func( function() { $somevar = fn(); // generate value return $calculated_value; }), ];
This has proved particularly used in Laravel configuration files.
Specifically, at time of writing, it’s PHP 7.0.3 on FreeBSD 10.1. Note that I would expect PHP7 to be officially available in FreeBSD and would hope that these instructions become redundant fast. Check for this with:
pkg search php70
At time of writing, the port we’re looking at is in development on Github here and it was announced on the FreeBSD ports mailing list here.
As you may gather from the above, PHP7 is available via ports only, not pkgng as yet. To install, proceed as follows:
portsnap fetch cd /usr/ports git clone https://github.com/miwi-fbsd/miwi-ports.git git-ports-php7 cd git-ports-php7 rsync -av ./* ../ portsnap fetch extract
Now remove your existing php:
pkg info | grep php pkg remove ... ... ...
And install php70:
cd /usr/ports/lang/php70 make make install
Follow this by installing any other PHP extensions you require. Note that in /usr/ports/Mk/bsd.php.mk
I had to add the following at line 283 for database/php70-pdo_mysql
to install:
_USE_PHP_VER70= ${_USE_PHP_ALL} phar sqlite3
Also note that Apache 2.4 is required. But who’s using 2.2 these days? Right..?
After seven years of using Cerberus as our helpdesk system at INEX, we decided it was time to upgrade / move on. Following a fairly exhaustive (and painful!) search, we settled on Zendesk as having the right mix of features:
The first hurdle was migrating all the existing tickets from Cerberus to Zendesk. There’s a number of ways we could have gone about this but the Cerberus schema was fairly intuitive and Laraval makes bootstrapping an application with database access really easy. As such, we simply iterated over the tickets in the Cerberus database and imported them into Zendesk (with attachments and by creating organisations and users on the fly).
See the code on GitHub at inex/cerb5-to-zendesk.
Glendalough Photos 20150209 by Barry O’Donovan is licensed under a Creative Commons Attribution 4.0 International License.