In part I of this post (written, ahem, two and half years ago) I described the decision-making process that led me to the fateful choice to create my very own bespoke chat room, and host it on my very own server within the vaults of the University of Nottingham. By doing this I could keep control of my participants’ data throughout the whole process, and I’d also (he thought optimistically) be able to have some control of features of the platform, tailoring it to suit my research needs.
So began the epic struggle.
Two initial areas to investigate: how to make a chat room, and how to host it. For the latter I contacted the University IT department. I had an initial meeting to discuss options ranging from the very basic to the bells-and-whistles. A Virtual Machine seemed like the best bet – basically a slice of a University server, a computer always on and always online, given over to my administration. I then had a follow-up meeting with another chap to discuss my exact requirements. This was difficult, as I was very vague as to what these were likely to be. I didn’t understand many of the questions.
What is the requested OS for the VM (Windows, CentOS (Linux) or other)?
Preferred hostname (Please use the server naming convention e.g. UiWapMED01)?
(My original answer to that second question was: “Do I have to specify this? Is there a ‘default’ option? I don’t mind!”).
I was suffering from terrible imposter syndrome throughout all this. In fact no, I just was an imposter. I was worried that one of these IT-type people might suddenly catch on and say “Hang on! We’re not giving you one of our precious University computers, you know absolutely fudge all about any of this!” So I didn’t ask the questions I should have (assuming I even knew what they were), and I nodded reassuringly when I shouldn’t have.
In the discussion it emerged that, as a PhD student, I already had a chunk of personal webspace on a University server, and the IT chap wondered whether it might be possible to do what I wanted using my personal University web space. Spoiler alert – no. But this seemed like an easier option to explore before delving into the arcania of trying to run my own web server, so I nodded reassuringly, we agreed to call off the search, and I’d look into that first, and be in touch again if need be.
Eventually, despairing of the whole business (not for the last time), I contacted the directors of my PhD programme, wondering if there was any official channels of support for this sort of thing. It is, after all, a Digital Economy Centre for Doctoral Training, and we did modules with names like Enabling Technologies. The programme director arranged a meeting with one of the web developers at the Research Institute connected to the CDT. Javid was extremely kind and helpful, did not imply that I was an idiot who had no business trying to do any of this and would probably end up crashing the entire University network, and instead suggested that I look at pre-existing chat rooms freely available online, if you know where to look. So he did a bit of looking, and that’s how I came across AJAX-Chat.
There it was on github (an online repository of code), a fully functioning chat room that someone had just made, and then made available to anyone to use, for no personal gain. It reminded me that the internet as we know it is founded on this kind of not-for-profit knowledge sharing, but this system only works when everyone is an expert. The attempt to bring this stuff-for-free ethos to non-experts who can’t reciprocally contribute leads to Google and Facebook, services offered apparently for free but very much for profit, and with enormous hidden costs of surveillance and mind-control on top.
Anyway, Javid also put me on to XAMPP, a pre-packaged production environment that is necessary to install on a bare-bones server in order to host web applications. More generically it’s called a LAMP stack: L for Linux, the operating system that underlies it, A for Apache, a piece of software that organises your server’s communication with the internet, M for MySQL, a database programme that stores and handles data passing through your website, and P for PHP, a programming language that sits on web pages and does stuff. Important stuff. All of these are necessary for the workings of AJAX-Chat (and many other web applications besides) and the nice people at XAMPP put them together in one freely available package, that can be installed comparatively easily. As a final act of kindness, Javid put me in touch with a senior colleague, a chap called Dominic with whom I had worked on a previous project, who is an administrator for the University’s Microsoft-hosted research servers. He offered to make me a virtual machine from this resource, on which I could get everything set up and get a better understanding of my requirements before getting back to IT with a request for a Uni VM.
Buzzing on an adrenaline rush of pure progress, I started work on this new puzzle. Dominic set me up with what I thought of as my “test-bed” VM, running the Linux-based operating system Ubuntu. Other than the OS, it was a blank slate. Its actual physical whereabouts as a metal box of flashing lights and whirring fans was, of course, completely unknown to me, and all my communication with it was done remotely, using the command line text interface. Fortunately I had been learning how to use this as part of my IT skills self-improvement drive, and was able to figure out the relevant commands to connect securely to the VM and then install XAMPP. Again, this carefree sentence glosses over the technical hitches encountered every step of the way, such as when the XAMPP installation initially ‘killed’, with an opaque error code. I traced the code and found the problem to be a lack of swap space, which I was able to fix with the following commands:
- sudo dd if=/dev/zero of=swapfile bs=1024 count=2000000
- sudo mkswap -fswapfile
- sudo swapon swapfile
That’s quite a good example of the endless loop of problem solving needed every step of the way.
With that all sorted, and XAMPP successfully installed, I turned my attention to AJAX chat. This had to be cloned from GitHub (after changing folder permissions of course), and then set up. The database needed to be configured (cue crash course in mysql-speak), and then channels and users added to the relevant php files (a different channel for each focus group, a different user for each participant). Fortunately AJAX came with an excellent readme file, so this was all largely straightforward.
A certain amount of wrinkle smoothing later….
It worked! Success! Or at least, interim success!
Now to do it for real, on a UoN server. I went back to IT, requested and got my University-based VM. And started the process again. I had kept meticulous notes of every step in the initial process, so had a step-by-step guide to follow. Unfortunately, in my rush of victorious pride I neglected to keep such detailed notes during this next part, so while memory tells me there were a number of issues thrown up by differences between the testbed VM and the UoN VM, memory has also suppressed the details of these problems as a defence mechanism, and I am unable to go into them.
Not to worry though, the real kick in the Bolingbrokes was yet to come.
I finally got the whole thing set up as before, this time on the UoN VM. Tested it in my office on campus – success! Went home to show it to my almost entirely disinterested wife – error! Despair and head scratching, though the problem is probably glaringly obvious. To access the chat room from outside the University network, as all my participants would need to, required safe passage through the University firewall. I needed to make a request to IT for a firewall change to allow traffic to my site (chat research.nottingham.ac.uk – no longer functioning). This involved two procedures: I needed to obtain and enable an SSL security certificate, and IT needed to run a diagnostic scan of my site to identify any potential security weaknesses. The scan duly came back with the following results:
Once again (and still not for the last time), I completely despaired at this point of ever being able to get this all figured out, and all these ‘multiple vulnerabilities’ resolved. Still, pulling myself together I was able to see from the results that the versions of php and OpenSSL were outdated. These were both integrated in the XAMPP package, so with the whiff of a solution I went back to the XAMPP installation website to find a more recent version.
There was no more recent version.
Thing is, weaving together the various components of XAMPP into a single installation is a complex business that takes time. And it’s freeware, so presumably the people doing it have other calls on their time. So, great though it is, the components of XAMPP had already been superseded – newer releases of PHP and OpenSSL were available, but not as a single convenient package.
So. No XAMPP then. Everything I had done to get XAMPP working and to install AJAX on top was unusable. And the only way around it was to start from scratch, and to manually, and separately, install the latest versions of Apache, MySQL, PHP, OpenSSL, and finally AJAX again.
It turned out I couldn’t even use the standard apt-get command to install the most recent version of OpenSSL, as it wasn’t even in Linux’s APT library yet. However, with the good people of the Internet coming to my rescue once again, I was able to find instructions to do everything I needed, here and here. IT provided me with an SSL certificate, which I figured out how to install and configure, using these instructions. Here’s another taste of the constant wrinkle-smoothing, taken from my notes:
“Although slightly confused as there wasn’t a .conf file in /etc/apache2/sites-enabled in the name of my domain, only a default file. The above instructions (and those on other websites) instructed me to run sudo a2ensite chatresearch.nottingham.ac.uk if the file wasn’t there, but that returned an error saying the site doesn’t exist. Eventually figured out that the a2ensite command enables (as opposed to a2dissite) sites whose config files are present in /etc/apache2/sites-available. Checking in there I noticed there was a default-ssl.conf file, so I enabled that and used it as the configuration file. It may be that this is not ok, however.
Then after figuring out how to use Filezilla to connect to my server (using sftp through port 22, although I think I could have left the port blank as that’s the default stfp port), I transferred the certificate files from my computer to the server, then put them all in /etc/ssl/certs. Then I edited the file default-ssl.conf to uncomment the relevant lines and change the details to those of my certificate files. Finally I stopped and started apache.”
My very own, University-hosted chat room, complete with channels, usernames and password-protected logins, chat-log exporting (by querying the MySQL database underpinning the whole thing), emoticons, text gestures (e.g. ‘username waves’), ‘username writing…’ functionality, even customisable colour schemes! And even better, it all looked awesomely retro. And even, even better, it worked, it was secure, and it allowed me to do my focus group research.
A truly Herculean labour, if I do say so myself, a gauntlet-run of mind-bending, brain-hurting problem-solving. And an enormous sense of achievement.
And yes, probably what GCSE IT students do.
Just let me have this one, ok?