Some notes about Digital Ocean servers

I’ve been unhappy with my current website host. My old hosting company, Verio, sold part of its webhosting business (including my websites) to another company. Verio used to provide php by default. The new host does not. I decided to try out another cloud provider, Digital Ocean, to see what they can provide.

I spent a while reviewing their help pages to prepare myself for surprises. I spent enough time on their documents site that they gave me a $10 credit when I set up a new account. Eventually, I set up an account with them and received the credit. Click on the link above to get your own $10 credit. (I’ll get some credit, too.)

Setting up a droplet is just as described in their setup page. It’s almost exactly the same. Digital Ocean provides more machine size options ($320/month and above) for monster machines with dedicated CPUs and/or high RAM requirements. I don’t need that. I want a small Ubuntu machine that I can use to hold the domain names that I have and don’t use.

I like their suggestion to use public/private keys. I did not realize that each machine should use exactly one key pair. I had set up key pairs for Bitbucket, Github and now Digital Ocean. I was unable to log in automatically with the key pair until I replaced the public key with the default public key I created on my machines a long time ago. I still set up a password for the non-root account. I still have to key it in for ‘sudo’ stuff, which is annoying, but login works automatically and well.

I decided to follow their instructions for setting up a server firewall. I’m not familiar with IP tables and Digital Ocean recommends using ufw. I followed their instructions and discovered that new terminal windows were not logging in automatically with ssh. It kept timing out for some reason. I rolled back my ufw changes, but I still had trouble with logins. I sent in a help ticket and received some additional instructions that look like they work. They have so far, so that’s good.

I continued setting up the server. Apache installed without trouble, even though they recommend Nginx. (I don’t know Nginx yet.) I skipped MySQL because I did not need it for a placeholder / testing site. I followed their instructions for installing PHP and … discovered that Ubuntu 16.04 does not have default repositories for PHP5. It has repos for PHP7. I had to add an additional repo for the PHP 5 files. Not a big deal, once I knew what was going on. Finally, I have PHP5 installed on the placeholder site. For a placeholder site, I like it.

Advertisements

Friday link dump for later reading

While trying to find some info about CakePHP 3 and its integration with AJAX, I stumbled across Zen of Coding, which had several posts on this topic. I realized I needed to find part one of his six part series, so I went to his home page. In the content list, I saw another post titled “Making Sense of Vagrant for your CakePHP or Symfony 2 project.” There, it discusses a GUI for the Vagrantfile config, based off of something called PuPHPet, a “GUI configurator for Puppet and Vagrant“. Puppet is for system administration, which I don’t do much any more. Vagrant configures “virtual development environments”.

I like the idea of Vagrant, where I can set up the same Ubuntu instance (for example) and feel confident it will work with any other Ubuntu instance running the same version (more or less). I plan on installing it (VirtualBox, then Ubuntu and maybe Vagrant) one day, when I get around to installing all the other stuff I need to load onto my machine first. For now, I have this post to remind me of all the links I want to visit very, very soon.

Fixing an Ubuntu update issue

I started having problems with Ubuntu updates. I noticed them at the beginning of the year. At first, the message that appeared was a notice about lack of space. A notice appearing after failed upgrades also described possible issues and fixes. I ran the suggested commands, *>sudo apt-get install -f” and “sudo apt-get clean”, but the error was not resolved.

I was unsure if the problem had to do with the lack of space needed to unpack the updates. “sudo apt-get autoremove” did not resolve the space issue. I focused on adding extra space the Ubuntu VM, described here. Once that was completed, I tried the suggested commands, but still had the same issues and errors. The error displayed read something like this:

> dpkg: error processing linus-headers – generic (~configure)
> linux-generic depends on linux-image-generic (3.2.0.59.70)
> however version of linux-generic in system is 3.2.0.60.70

I ran the suggested commands

> sudo apt-get purge linux-generic
> sudo apt-get install –reinstall linux-generic

I believe the idea is to remove the linux-generic version that is causing the issue. However, after running these commands, I still had the same message appearing. Running

> sudo apt-get clean
> sudo apt-get auto remove

did nothing new. I considered running dpkg, but dpkg won’t install dependencies that apt-get will, so I left dpkg alone.

After some more google searches, I ran across something that did work:

> sudo apt-get remove linux-image-generic linux-generic linux-headers-generic

As I understand it, this removes these items from the software waiting to be updated without removing configuration files.

> sudo apt-get -f install
> sudo apt-get auto remove

loaded the proper versions of the missing files and the Ubuntu updates have been running fine since.