The Details part 3

So there seems to be this thing about snap and snappy apps and suchlike.  I have no idea, I’ve dipped my toes in to it, but it seems like Snappy is the structure on which snaps are placed that interact with each other like little virtual instances on your main virtual instance (or dedicated piece of hardware), providing modularised services to each other to create a website. I think WordPress can be a snap, and so too can Nextcloud.  I’ve tried installing the Nextcloud site as a snap as per this Digital Ocean guide but came up with nothing good, it came apart during the Let’s Encrypt SSL stage.  So I installed it just as I used to, following these instructions here from TechRepublic and a bit of this to allow for the utf8mb4 thingy.

With everything in place, OTRS was a doddle, though ironically (I think, I’d have to check with Alanis Morrisette), OTRS insisted on having the SQL database configured in utf8.

So, it would seem that my master database is set up with the best version of utf8 character encoding (utf8mb4) which allows 4 bytes per character and is compatible with all the world’s alphabets (maybe Tolkien and Trek languages too!) and emoticons.🏆  Which is great for WordPress.  Regular utf8 encoding is 3 bytes per character, and lacks all alphabets and emoticons, a bit of a botch job fixed by MySQL when utf8mb4 came along, but never removed.  This is all from various forums I read up in the last few days.

Within your MySQL installation, each database can have its own character encoding, so regardless of the SQL master database being utf8mb4, it was no issue creating a database just for OTRS that was utf8.  OTRS offers to create the database for you, or use an existing DB but can only make the new one when the master DB is utf8. That being so, I just created its database with utf8 as required, within phpmyadmin.  So it is nice that WordPress is on utf8mb4, but for OTRS, the whole rip-it-up-and-start-again needn’t have happened.  All good practice though.  The standard instructions to OTRS install on their website was easy enough, with some slight tweakages in how I set up my sites-available/enabled and conf-available/enabled creating the links the a2ensite and a2enconf commands.  It was the second or third time through playing with the OTRS install anyway.

(In Apache, the configuration files are named *.conf and are stored in /etc/apache2/mods-available and conf-available and sites-available .  They’re activated by linking the conf files within, to similar folders named mods-enabled conf-enabled and sites-enabled.  In the instructions for WordPress and Nextcloud installs, the right way to make that link is with an apache commands a2ensite site.conf a2enconf config.conf a2enmod mod.conf and similarly a2dissite a2dissconf a2dismod to break that link, to take a site offline or disable a configuration.  Here endeth the parenthesis.)

More recently, I’ve been trying to wrap my head around the OTRS system itself and how it might best suit my place of work.

The Details Part 2

Continued…

Then I recreated my LAMP stack to support all my usual pages; WordPress, NextCloud, phpMyAdmin and OTRS ultimately.  I built the bog standard info.php file, named it index.php so it was served up by default by apache (and so detected by Lets Encrypt and got my cerificate for all my sites at once.

Soon as I got on the MySQL database, I corrected it to fully support utf8mb4 character set, to incorporate multi-lingual posts and comments, and emojis 🤞.  I found these instructions for MySQL 5.7 on Ubuntu 16.04, worked fine for the same MySQL on 18.04.  This is also important for OTRS when I get that installed later this afternoon or tomorrow.  OTRS won’t work without utf8mb4 support.

As an aside, figuring out where to apply mysql instructions in files was a bit arsey, since various instruction I’ve read references config files in /etc/mysql  but the master control file is /etc/mysql/mysql.conf.d/mysqld.cnf and I suppose this may be a feature of Ubuntu 18.04.  Still, found it in the end.  The file suggested in some posts exists but has barely any config in it.  If config is applied, and it contradicts the config in /etc/mysql/mysql.conf.d/mysqld.cnf then MySQL just doesn’t run. Best to apply everything in the main file.

I created phpMyAdmin first, configuring it the way I always have with 2 layer password authentication, one for access to the login page, one for the sql users login that phpMyAdmin uses by default.  I then installed WordPress and imported my back-up.  What worked nicely this time, for some unknown reason, was after importing the site from my back-up that I’d done first thing, I could change the permalink settings.  When I did my export-import last week, from my AWS to this server, that didn’t work so well, and had to have my blogs posted with page id in the URL, rather than date and page title as you see here  /2018/09/11/the-details-part-2/ for this page.  Its nice to have that back.

Time now to reinstall nextcloud, paying attention to utf8mb4 nuances.  I’ll write that up in details part 3.

The Details

Today, I ripped it up and started again, doing so in a particular order to make sure that I got almost everything right, first time, every time, nearly.  So I backed up WordPress using All-in-One WP Migration and pressed the button on OHV server control panel to reset back to vanilla Ubuntu server 18.04.

After powering back up, it comes with root account that you’re emailed the password for and an ubuntu user that I don’t know the password for, which is weird.

I deleted ubuntu and recreated with a nice 20 character password, and logged in as such.  But I’m used to being logged in automatically through SSH, as user ubuntu, since that’s how Amazon Web Services comes preconfigured.  This involves public and private key pairs and the public key being submitted automatically on connection.  I found these steps on good ol’ Digital Ocean which I had to amend since it is written assuming your SSH app is SSH for Linux commandline and not PuTTY for Windows.  That being the case, I swapped step 1 for the PuTTYgen method, copied the public key created, then pasted in to file ~/.ssh/authorized_keys (being logged in as ubuntu, it saved to /home/ubuntu/.ssh/authorized_keys ).  I saved PuTTYgen’s private key to my Windows Home Directory My Documents and connected with it in PuTTY.  Bang, I’m in!

I continued the steps recommended on Digital Ocean so password authentication is disabled, only SSH key pairs work.  I have a key for root, and a key for ubuntu.   The purpose of the exercise was to use an account that requires sudo for any system-altering commands (which most are when installing various platforms).

More later, I’m going out to buy some green hair dye.

It’s been a while…

Geeking has been minimal.  My efforts and concentration has been directed at my place of work, where we’ve hired a new technician replacing one who left earlier, gone through a staff buy-out, and relocated.

But as of late, I’ve found my amazon charges creeping up, especially since some of my first-year discounts have expired.  So I’ve bought a new Virtual Private Server for 12 months, got 40GB SSD, 1 core, 4GB RAM (yup, 4GB) to host my site, my nextcloud, my experiments.  And it’s on 18.04 Ubuntu, none of this 16.04 of yesteryear (or the year before yesteryear).

I’m pleased with my 4GB of RAM.  On Amazon, I launched another instance with 2GB for an experiment with a web-app for a few days and it struggled to run the web app under certain circumstanced, ground to a halt and free RAM evaporated.  The cost of running that extra instance is quite high compared to my new VPS.

Cost £60 + VAT.

So far, this blog is the only thing I’ve moved.  Though I did a dry run by moving it to xfer.digitaltinker.co.uk (now no longer a site).