Migrating My Nextcloud Server to Another Server

When I saw that my version of Ubuntu could not be upgraded any more (due to Digital Ocean’s system), I had to migrate my Nextcloud installation (version 11.0.2) to a newer version of Ubuntu (16.04). In the documentation for Nextcloud, it details how to exactly migrate your Nextcloud installation to another Linux server, so I tried using that. Sadly, though, they left a couple of things out. So here’s my version of how I migrated my Nextcloud installation to another server.

First of all, they say to back up your data, which is what I did (to some extent). Next, I spun up a droplet which had similar specifications to my previous installation (it uses 512MB and has 20GB of storage, for instance). I made sure to put in my usual ssh key for this new droplet, as well as securing it in other ways. At first, I thought I knew how to easily do this: copy over the /var/www/nextcloud directory to the new server (which was also set up for Nextcloud), change some directory names, and it would be done. However, this was not what I found.

When I tried this method, I couldn’t access the web interface. What was worse was that I had forgotten to change the firewall configuration on the new droplet and accidently “locked” myself out. So, through some more research, I tried it again with another droplet.

This time, I copied the files using rsync, and made sure that I used the proper switches (I used the “-a” and “-t” switches, in order to archive the files, as well as save the timestamps). I saved the files to a new directory on the server, and made sure to back up the old files. I thought that this time I had fixed the issue. But Fate can be cruel.

Even though I had copied over the files in the “correct” fashion, the server still wasn’t accessible from the web. Looking at the /var/log/apache2/error.log file, I found that the webserver couldn’t start due to Nextcloud not be able to read the database. After researching the problem more, I learned that the data can’t be just “copied” over; rather the data has to be copied, and the database has to be imported. So, after scrapping that droplet (I had changed it too much already), I spun up a new droplet, and tried this whole thing all over again.

First, I put the server into “maintenance mode” and stopped the Apache server. Then I extracted the data from the database (via the command mysql -u ownCloud -p password ownCloud > /tmp/dump.sql), copied that over to the new server, and imported it into the new database. For importing the new database, I “dropped” the old database, created a new one, and finally imported the data with the command mysql -u nextcloud -p password nextcloud < /tmp/dump/sql. Then I copied the old Nextcloud as I did before (using the official documentation’s recommendation of the command rsync -Aax) and carefully moved the files into the new /var/www/Nextcloud directory. Even through all of this, it still wasn’t enough.

Looking again at the /var/log/apache2/error.log file, I found that the new Nextcloud install couldn’t read the database due to the new server using the old Nextcloud config.php file (are you still with me?). So, I changed a few values in the config.php file so as to use the new database. What I did was change the dbname to the name of the new database, as well as input the new database login information. Also, I added the new IP address to the “trusted hosts” array in the config.php file. This seems to have fixed most of my problems.

Just in case, I also ran a script that I found in the official Nextcloud documentation for fixing the permissions on the new server. Then I changed some of the security configurations for the Apache server. I copied over previous configurations for SSL into the /etc/apache2/sites-available directory, and enabled them through the a2enmode command. With all that finished, I started up the Apache server again, and took the Nextcloud installation out of “maintenance mode”. Finally, I was able to use the server. Except, it wasn’t exactly to my liking.

You see, I had copied over the “data”, “config”, and “themes” directories. I did not copy over all of my previous apps. When I saw that I had only half of my previous apps, I thought, “I need to fix this,” and copied the contents of my previous Nextcloud’s “apps” directory to the new server. With those out of the way, I saw to using some of Nextcloud’s recommendations, and bumped up the memory (as well as putting in a timeout feature). These were harder to fix, partially because I had these problems with my previous Nextcloud installation. Nevertheless, I sought to fix them.

One of my problems was with the /var/www/nextcloud/.htaccess file, specifically that it wasn’t working. To fix this, I edited the /etc/apache2/apache.conf file and changed the AllowOverride directive for the /var/www section to “All”. This allowed the /var/www/nextcloud/.htaccess to work (at least, it would work since I’m accessing the site over a secure connection). Next, I added a memcache so as to speed up performance. I added in php-apcu and edited the /var/www/nextcloud/config/config.php file to reflect this by assigning memcache.local the value \\OC\Memcache\\APCu. My server was made much faster with this tweak. For added polish, I followed the directions on this tutorial and added Redis support.

This was a tough migration that I thought would have been easy. I figured that it would have taken a couple hours. However, it was stretched out to a numbers of hours (not to mention one night). While it’s great that I have migrated to a more manageable configuration, I should have done more research.

Helping Out a Local Charity

I’ve been helping out a local charity with preparing tax returns for the needy and underprivileged for the past few weeks and we’ve run into a problem. Each time we have to print out the tax returns for the clients, we have to take the laptop over to the printer to have it printed out.  This takes a while, and it can be a royal pain.  So I have suggested setting up a small print server so that the laptops on the WLAN can easily print.  My initial set-up looks encouraging: I have set up a Raspberry Pi as a little print server, and have successfully printed from one of the laptops.  With some security measures and other set-up, the other laptops that the tax preparers are using will be able to use this print server, too.

Learning About Setting Controls for I.T. Assets

In my pursuit to get into the information technology (IT) audit field, I must learn about setting controls for securing IT assets, minimizing risk, and eventually testing that said controls work.  In major organizations where information flows constantly and is utilized to advance the organization’s goals, ensuring that the information and knowledge are accurate, intact, timely, and secure are important.  To secure them, though, management must know how this information and knowledge can be lost.  Once they understand this, controls must be put into place so as to prevent this loss.  But management cannot always safeguard these assets.

As a company moves along in its financial year, these controls can break down.  For example, backups can be corrupted (losing information), and employees may leave the company (thus losing knowledge).  So it is also good to reassess whether these controls are working as intended.  This is where the IT auditor steps in, to evaluate these controls, and see to it that that continue to do the job.

Though I know of some ways of testing these controls (e.g. vouching, interviews, and walkthroughs), I have never carried them out.  All I have done is study them.  While studying textbooks is fine, some would say the true teacher is experience, and I have not done so.  For the most part, I have managed a couple of websites (this one included) so that they cannot be hacked.  I have put controls in place to ensure that my website is not compromised.  But to make sure they work, I must turn to someone who has had experience in managing a website.  Not just that, but an IT auditor who will teach me what to exactly do so that this website is not damaged.  Eventually, I would learn more from them so that, when I am on an audit engagement, I can ensure that the company’s valuable assets are kept safe.