Six and a half years ago my needs outgrew a simple shell host, having previously outgrown a shared Web host.
Back in July 2008 I started off small, with a Taster VPS that came with 64 MB RAM (128 MB burstable), 5 GB HDD, and one IP address. I knew before completing the order that 64 MB RAM would not be enough so added on 128 MB RAM (128 MB burstable) bringing me to 192 MB RAM (256 MB burstable), 5 GB HDD, 50 GB monthly transfers, and 1 IP address on an OpenVZ container.
In March 2010 I needed more RAM, so added on another 64 MB (128 MB burstable) taking me to 256 MB RAM (384 MB burstable), 5 GB HDD, 50 GB monthly transfers, and 1 IP address.
In May 2011 I took stock and saw a deal on a Bronze VPS—£5 per month compared to the £6.99 per month I was previously paying; although it did come with the condition that billing periods be annually rather than monthly.
My Bronze VPS package was on the Xen platform, and came with 512 MB RAM, 10 GB HDD, 125 GB monthly transfers, and 2 IP addresses.
A year later I was running low on disk space (should have purged some old kernel packages) so added another 5 GB HDD in August 2012.
In June 2013 my VPS provider had a major service outage. As compensation for the downtime I was granted an additional 15 GB HDD and 1 IP address.
So, I am currently running Ubuntu 14.04 LTS (with an older kernel—couldn't get PyGrub to work) with 512 MB RAM, 30 GB HDD, 125 GB monthly transfers, and 3 IP addresses.
I am paying £72 per year (£6 per month). Although I could cancel the £12 per year 5 GB HDD add-on, I would really be losing 10 GB HDD (a third) because the compensation was only supposed to be for the base package (long-time customer bonus). Although I have now moved my e-mail in-house, I'd rather not lose that 10 GB just in case I need it in the future (I prefer having at least 50% free so a full backup is possible).
What VPS Specifications Are Needed?
This is a difficult question to answer. Although I have moved a lot of things in-house, I can not ignore my place in society. Next month is my ESA tribunal and if I am ignored I could well end up having to make difficult decisions.
Although I could move out of "shared accommodation rate" (house-share) accommodation because I am disabled, and am therefore excluded from the Under 35s restrictions for single room rate LHA, I will have to deal with the DLA to PIP change some time over the next 8–32 months and could potentially end up being deemed not disabled.
What all this basically means is that I need to leave myself with options. I can't completely bring my e-mail in-house because I need a public IPv4 IP address to send e-mail that isn't on the PBL—for £84 per year more than I'm paying for Virgin Media 152 Mb/s I could get Virgin Media Business 50 Mb/s with a static IP address, but that is more than what I'm currently paying for my VPS, would result in a slower upload (and download) speed, and I would be foolish in making such a decision.
On the other hand, dropping down to the 50 Mb/s consumer package would save me £150 per year, but during the minimum term it wouldn't make sense reducing the package if I would have to pay a fee equivalent to what I would have paid sticking with the more expensive package.
There is also the question of bandwidth. On my VPS, a 20 GB extra bandwidth (transfers) per month add-on costs £1.00. At 4 Mb/s upload (the Virgin Media 2 hour reduced speed cap on the 152 Mb/s package) I could upload 20 GB in under 12 hours. Or put another way, my Virgin package is worth £60 per month in VPS add-on bandwidth.
I need at least one IPv4 IP address.
So that narrows the number down to somewhere between one and four billion-ish. The thing I need to think about is encrypted connections, where the same port number is used and the client does not support SNI.
Until my consolidation of content is complete, I need one IP address for watfordjc.co.uk/watfordjc.com and another for johncook.co.uk/johncook.uk/watfordjc.uk.
I need a static IP address for my DNS master, and I also need one for my outgoing mail.
If I were to start using DNSCurve again, I would need a second IP address to do key rollovers. I suppose I could get away with an NS hostname that only has an AAAA record and somehow micromanage the rollover, but that sounds too tedious.
How many DNS servers does Nominet require at a minimum? From the look of things, more than zero. The IANA (and some RFCs) require two nameservers, but not only do they require they be different IP addresses they also require they be from two different networks.
If I decide to test DNSSEC, I will need two IP addresses as Hurricane Electric's backup DNS service doesn't (yet? RNS) support DNSSEC.
I can probably get away with just one IPv4 IP address after consolidating my Websites, although there are several reasons why two would be better.
By bringing e-mail in-house, I have freed up a little space on my VPS (around 321 MiB).
Disk usage on my VPS currently stands at 3.1 GiB out of 30 GiB after running updates and using
sudo apt-get autoremove && sudo apt-get autoclean, however, I do not currently have all my Web content restored on my VPS and a lot of packages that I probably need have not yet been installed.
It also hasn't even been a month yet since I started from scratch with my VPS, so there is also that chunk of space needed for log files (although the backup of my previous VPS instance only has 21 MiB of log files).
Disk usage requirements is one of those things where you have plenty of space until one day you wonder what is causing an error and it is the fact you have zero bytes free space. I have around 7 TiB free space currently on my home server, but I'll need some more disks in 6–9 months as I will undoubtedly have run out of space again.
On my laptop, I give 150 GiB to an OS install, with 298 GiB (13.7 GiB free) for Documents (and some program data) and 478 GiB (101 GiB free) for Downloads (and some programs). I have a microSD card with greater total space than my VPS has. Although 30 GiB may currently be too much space, how much will I need to meet my future needs?
That is basically the underlying question throughout this, and calculating savings is rather difficult when you have to balance savings on what I cut back on now versus losses when I add those things back but have to pay a higher price. For example, if I get rid of 10 GiB of space saving me £1.00 per month for 6 months, but then need that 10 GiB for the next 2 years and it costs £2.00 per month, that'd be 6 GBP saved versus 24 GBP lost.
This used to be rather simple to calculate—if I'm running out of free memory I need to add more.
Things now are slightly more complicated.
Monthly Transfers and Bandwidth Utilisation
In the last hour I have transferred 5.74 MiB in and 6.14 MiB out on IP address 188.8.131.52. As that is the IP address I am using CJDNS over, and my ULA IPv6 tunnel has now moved to tunnelling over CJDNS (due to latency and packet loss issues with Hurricane Electric's 6in4 tunnels), I can assume that a get every 5 seconds of /inc/esi/site_name equals around 12 × 24 = 288 MB/day.
It isn't one GET every 5 seconds though. For my VPS, there is a GET to my home server's varnish instance, my home server's nginx instance, and my VPS's nginx instance. That is two GET requests using the network every 5 seconds. On my home server, there is a GET request to my home server nginx, and one to my VPS's nginx. That is a grand total of three GET requests over the network every 5 seconds.
So, I can say the background level of traffic (i.e. that required to ensure my Web sites remain available) is approximately 300 MB per day, or around 100 MB per day per 5 second health probe.
300 MB per day is 9,300 MB in 31 days (3,100 MB per 5 second health probe) which is a huge amount of traffic. With a 125 GB monthly usage allowance the health probes alone are using around 7.5% of my transfers allowance.
184.108.40.206, on the other hand, has has a total 51.49 KB in and 16.20 KB out in the last hour (a total of 67.70 KB). This IP address is primary used for incoming/outgoing e-mail—in the last 24 hours total transfers on that IP address was 1.91 MB (around 60 MB per month).
Even though e-mail transfers from my VPS to my home server are over my ULA IPv6 network (and thus over CJDNS over my .49 IP address) that is an extremely small amount of traffic in comparison to the health check pings.
So, what I want to do first is cut down on the health checks. There is no real reason for my home server to check my VPS, so I can cut that health check out. There is also no real reason why my VPS should be checking my home server's nginx instance if my home server's varnish instance is already doing that, so I can cut that health check out.
I could also cut the health checks back to once every 15 seconds. So one health check (3,100 MB) at a third of the time equals 1,033 MB per month (0.83% of my bandwidth quota versus a current 7.5% of my bandwidth quota).
However, having switched from GET to HEAD, and dropping down to one request every 15 seconds, bandwidth usage has only dropped to around 6 MB per hour (around 4.5 GB per month, or around 3.6% of my monthly usage cap.
This suggests that only a third (now half) of bandwidth usage is for the Varnish probe. Perhaps some of the other half is used up by CJDNS, MySQL replication, and e-mail.
A bit of Googling, and a MySQL query on my VPS later, and I discovered that compression is not enabled for replication. To determine this, and to turn on compression, I performed the following MySQL commands on my VPS:
show global variables like 'slave_compressed_protocol'; stop slave; set global slave_compressed_protocol=1; start slave; show global variables like 'slave_compressed_protocol';
In order to make this permanent, I edited /etc/mysql/my.cf on my VPS to add
slave_compressed_protocol = 1 to the
[mysqld] section and restarted MySQL.
As could probably be expected with a database that only changes when I create an e-mail alias or mailbox, this had absolutely no effect on bandwidth usage. Turning compression on probably can't hurt, though.
Traffic is one of those things that is hard to predict when you're small. With optimisations like caching so your sites can handle large spikes in visitors you also don't have the luxury of your site failing completely during a traffic surge capping the maximum possible bandwidth your server can serve.
I don't know how many concurrent visitors my server software and VPS's share of hardware can handle. Also, with half of my sites returning a 503 server error until I recreate them it is even harder to estimate total bandwidth usage. My old blog domain, for example, has completely dropped off of Google so if anything on there was worth reading I can't rely on server log 503s to make predictions.
Assuming a 100 Mb/s upstream on my VPS, that is 12.5 MB/sec, 750 MB/min, or 45 GB/hr. In three hours I could use my entire bandwidth allowance for the month. With a 5 minute TTL (minimum on dns.he.net) then 750 MB/min × 10 = 7.5 GB, or 6% of my monthly bandwidth quota if I can switch A/AAAA records as soon as a spike is detected.
Content Delivery Network for Static Content
This is, I suppose, where Cloudflare could save me. If I move all my static content to a sub-domain of an entire domain I don't care about the DNS of, I will only have to worry about page views and the bandwidth such page views use (i.e. only caring about the bandwidth of the HTML, not the CSS, JS, and media).
The reason I mention DNS is because Cloudflare demands, for their free plan, that you give absolute control of the DNS for that domain to them. If you use someone else for backup DNS in your registrar/registry settings Cloudflare purportedly disable their CDN on your domain.
Ergo I want a domain that I do not use for e-mail or that I have delegated sub-domains for. Without a major re-organisation, that rules out all of my domains. If Cloudflare requires it be enabled for a domain in order to enable it for a sub-domain, that would make things a lot harder to think about were it not for Heartbleed.
The reason I bring up Heartbleed is that it resulted in me switching sub-domains rather than paying StartSSL for certificate revocations. That means that JohnCook.UK (and WWW.JohnCook.UK) are not the canonical domains for the URL of this page, it is instead Web.JohnCook.UK.
Therefore switching on Cloudflare for the base domain of this site would not result in traffic going through Cloudflare unless I flipped the switch for the web sub-domain. In fact,
ls -al /etc/nsd/zones on my VPS shows that my smallest zone file is for this site, with johncook.uk.zone only using 1,122 bytes (watfordjc.uk.zone is a close second at 1,141 bytes, probably because the base domain is a character longer).
; johncook.uk Dumped Sat Jan 24 20:03:31 2015 ; johncook.uk. 2560 IN SOA ns5.thejc.me.uk. hostmaster.johncook.co.uk. ( 2015011403 ;serial 10800 ;refresh 900 ;retry 1209600 ;expire 60 ) ;minimum johncook.uk. 172800 IN NS ns5.he.net. johncook.uk. 172800 IN NS ns5.thejc.me.uk. johncook.uk. 172800 IN NS ns7.thejc.me.uk. johncook.uk. 7200 IN TXT "v=spf1 -all" johncook.uk. 7200 IN SPF "v=spf1 -all" _domainkey.johncook.uk. 7200 IN TXT "o=-; t=n;" _adsp._domainkey.johncook.uk. 600 IN TXT "dkim=discardable; t=s" _dmarc.johncook.uk. 60 IN TXT "v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; rua=mailto:postmaster@[example.com];" johncook.uk. 86400 IN MX 1 mail3.thejc.me.uk. johncook.uk. 3600 IN A 220.127.116.11 johncook.uk. 60 IN AAAA 2001:470:1f09:38d::80:c ybycblyios64.johncook.uk. 7200 IN CNAME gv-yyw32j2xgeehlf.dv.googlehosted.com. web.johncook.uk. 3600 IN A 18.104.22.168 web.johncook.uk. 60 IN AAAA 2001:470:1f09:38d::80:c web.johncook.uk. 7200 IN TXT "v=spf1 -all" web.johncook.uk. 7200 IN SPF "v=spf1 -all" iqc36mcx52fq.web.johncook.uk. 7200 IN CNAME gv-cehdrreas5knno.dv.googlehosted.com.
That is the most basic of zone files I could probably have. NS records, TXT and SPF records for "legal" hostnames (i.e. those that aren't CNAME records or hostnames starting with an underscore), MX records, DKIM, DKIM ADSP, and DMARC records, and the obviously important A/AAAA records.
A recursive grep of that directory shows the only other file with a record referring to johncook.uk is the TXT record johncook.uk._report._dmarc.thejc.me.uk, so it would be fine if Cloudflare were to have DNS issues (although Cloudflare taking this site down during a DNS problem would itself be an issue).
Likewise, a MySQL search for e-mail addresses/mailboxes/aliases for the domain johncook.uk only show the standard reporting mailboxes as standardised in the relevant RFCs.
Having thought about this, I have decided to give Cloudflare a go, at least for testing purposes.
Having already looked at my DNS for my domain, signing up with cloudflare was pretty straight forward. I created an account, added my domain (johncook.uk), loaded the draft copy of this page to copy and paste my zone file to a text file that I loaded into Cloudflare, manually added the SPF records that Cloudflare ignored for some reason, and then set my Web sub-domain A/AAAA records to bypass Cloudflare.
I then edited my zone file on my VPS, commenting my NS and SOA records and replacing them with that obtained from performing the relevant lookups on the DNS servers Cloudflare told me to use. I then saved and performed a reload on NSD, and not long later my zone as Cloudflare sees it was identical to how both my nameserver and Hurricane Electric's nameservers saw it.
I set the SSL mode to strict, and made a few other tweaks to the settings.
I then created a subdomain static within Cloudflare, using the same A/AAAA IP addresses for the base domain, and also set SSL to strict.
At this point, johncook.uk was going through Cloudflare, and has been the case since before I joined Cloudflare all URLs are redirected to web.johncook.uk. I have basically put a domain on a CDN that has only redirects, and I have no intention of using the base domain for static content.
Obviously, without a valid SSL certificate for static.johncook.uk Cloudflare is returning an error in SSL Strict Mode, as expected. The next stage will be generating a key and CSR for static.johncook.uk, getting a certificate from StartSSL, and then creating an nginx configuration for the domain.
This is where using a separate sub-domain is a good idea. By splitting static content to a separate configuration I can make it so only some PHP files actually exist, with everything else returning a 404 (or a 403 as I'm currently doing).
Thus this page can be kept off the CDN by simply not creating a rewrite rule for all .php files. I can even go the other way and make it available on the CDN by creating a rewrite rule so the URL points at the PHP file and nginx passes it to PHP-FPM.
After setting everything up and waiting for the old TTL to time out (a couple of hours) I shifted all my static content from references of https://web.johncook.uk/... to https://static.johncook.uk/... and that was it. Static content on my site is now served from Cloudflare's CDN.
Well, I did have to modify my nginx configuration for static.johncook.uk because Pragma/Cache-Control set as private, rather than public, prevented Cloudflare from caching the files. With that change made, a new TLS certificate in place, and a reload of nginx, Cloudflare is now serving as a proxy for my static files.
Of course this is not entirely within the Cloudflare terms of service. Section 10 states that it is prohibited to use the service for "the storage or caching of a disproportionate percentage of pictures, movies, audio files, or other non-HTML content".
One obvious issue is that Cloudflare does not support ESI. Although they have this thing called Railgun, it isn't available for free accounts. This means that if I flip the switch and enable Cloudflare for Web.JohnCook.UK then requests to my origin server will be higher than if Cloudflare supported ESI.
Therefore, to fully utilise HTML caching with Cloudflare, I will need to modify how I do things. For the time being, I have enabled web.johncook.uk for Cloudflare so all content (including HTML) goes through it per the terms. I have also changed static content back to that domain to reduce DNS lookups.
DireVPS is run by OpenITC, the same people that run xenvz.co.uk. As I am mostly satisfied with my current provider, xenvz.co.uk/OpenITC, the obvious question is whether any of DireVPS's packages would be suitable for me and at a price point less than I'm currently paying.
KVM 1: £2.50/m - 512MB RAM, 25GB Disk, 2.5TB BW, Gigabit port, Two IPv6/64 subnets and 1 IPv4 address, 2 vCPU Cores, 12.5GB Free FTB backupwww.direvps.com
The best way to make a comparison between DireVPS and XenVZ would be to create a comparison table.
|RAM||512 MB||512 MB|
|HDD||30 GB||25 GB|
|Monthly Bandwidth||125 GB||2,500 GB|
|Virtual CPU Cores||2||2|
|IPv6 IPs||2||2 × 264|
|Backups||5 GB||12.5 GB|
|VPN/Proxy||✓||✓ (personal use)|
|Other lawful services||✓||✗|
Herein lies the difference between the two services, and it is that of what is considered acceptable use.
Question: Can I use my VPS for ______?
Answer: If you have to ask, most likely not.DireVPS, FAQ
Do you allow adult hosting, IRC, VPN, TeamSpeak, Ventrillo, torrents, forums and proxy sites?
Absolutely! It's your VPS, so you are free to do what you like with it as long as it complies with UK and your local laws. (Yes, we do know our ToS states no IRC, though we do allow it on request...)XenVZ, FAQ
With a second IP address from DireVPS costing the same as from XenVZ (£1.00 per month), I will be looking at £3.50 per month for 2 IPv4 IP addresses, 2×264 IPv6 IP addresses, 25 GB HDD, 512 MB RAM, 2.5 TB Transfers, and 2 virtual CPU cores.
That brings my annual cost down from £72.00/year to £42.00/year—a 41.67% saving, or £30/year cheaper (£2.50/month).
By adding the cost of this VPS to my Nominet annual fee and 5 domain renewals every 2 years, my costs per year per domain is (3.50 × 12) + 120.00 + 15.00 = £177.00, or £35.40/year per domain (£2.95/month).
Of course, the new package will come with a lot more restrictions than what I am used to. Whereas I currently do not have to worry about what I have running on my VPS, I will no longer have that luxury.
As I previously said, however, the plan is to bring as much of my stuff in-house as reasonably possible. DNS, e-mail, and Web sites are probably all I would need a VPS for if I were to really commit to going down this route. If, for example, I decided I wanted to use my VPS as a proxy for SIP (VOIP) traffic that may no longer be an option.
A KVM VPS is sort of like a Xen VPS, but with a bit more control. By that I mean you can point the VPS control panel at an ISO file to install an OS from, rather than being restricted to the operating systems available from the VPS provider.
I gave up trying to upgrade the kernel on my XenVZ VPS as I couldn't quite get PyGrub to work, so my VPS is running Ubuntu 14.04 LTS on an old kernel. Not being able to get a newer kernel to work is a bit like my reason for moving from OpenVZ to Xen: I couldn't control iptables how I wanted to because the modules weren't available.
So I will theoretically be able to point the OpenITC control panel at a Ubuntu Server 14.04 ISO and install it as if I were installing it on my home server.
OpenITC's forum has a Howto: Install an operating system on a KVM VPS thread which links to a List of ISO files compatible with our KVM system that includes an URL for an ISO of Ubuntu Server 14.04.1 64-bit (among others).
From the look of things, installation is a bit more involved than for recreating a Xen VPS using a template, but it doesn't look like it is that different.
As DireVPS is monthly billing, I decided to go through the order form (same layout for all OpenITC services) going for the KVM service I mentioned above, with a 1 IPv4 IP address add-on.
As I am already an OpenITC customer, I used my existing OpenITC login credentials at the Collecting your details stage of the order process, and at the Order complete stage I faced the following:
Step 6: Order complete
Thank you for your order request.
Based on your particulars, your order has been flagged for manual review by a member of staff. Once approved, an invoice will be raised and sent out by email.
Though this typically takes only a few hours, it may take longer depending on third party background checks. In the event of delay, please do not contact us for an order update until at least 72 hours have passed.
Please ensure that any spam filters do not block e-mail from @openitc.co.uk so we may deliver your login information.
My order has probably been flagged because of my request for 2 IPv4 IP addresses. My order was completed at around 00:20 UTC+0 on a Tuesday, and at 00:30 UTC+0 I switched tabs and looked at my OpenITC account. My next invoice date had changed from 90 days to -15 days and I saw the following beneath:
You have ordered 2 new service(s) but have not yet finalised your order. To make any alterations simply use the cancel button next to the order. Click here to commit to your order (you won't be able to cancel after this point) and generate an invoice. If you do not do anything our systems will commit to your order (you won't be able to cancel after this point) and generate an invoice at roughly 9:30am UK time.
So I tapped where it says click here, and the system generated an invoice. I opened the e-mail, clicked to pay the invoice, logged in, and it said the invoice had been paid by direct debit. Back on my iPad, however, the system still said I had an unpaid invoice. In invoices I tapped to pay the invoice, hoping it wouldn't result in a duplicate invoice, and received 4 e-mails.
As only one e-mail was from GoCardless, I assume that the first direct debit payment wasn't recognised for some reason. In any case My Virtual Servers now listed my existing VPS and my new VPS.
My new VPS has not been provisioned yet, so I clicked on it, and then selected the only host node available: kvm06 in Maidenhead, UK (same data centre as my existing VPS). At the time of writing it had 30+ active VPS, 4096+ MB free RAM, 400+ GB free disk, 60+ IPv4, and 8×7200 rpm SATA disks in hardware RAID 6 with battery backed cache.
After clicking next I had the option to choose my primary IPv4 IP address. I pulled up a DNS blacklist checking site in another tab and checked the first available IP address. It was listed at several places, as was the second and third. I need an IP that is clean as I am going to be using it for e-mail and don't want an IP that is blacklisted anywhere.
The fourth IP address I tested was only listed by AHBL, but upon further inspection that is because not only is AHBL no longer active, but according to Wikipedia its "DNSBLs were shut down on Jan 1, 2015 and now appear to be blacklisting the entire Internet."
With my primary IPv4 address chosen, I clicked next, noted my chosen Operating System is listed as kvm self install via ISO file, and with everything looking fine I clicked Agree & Confirm.
After a few moments I was met with a message saying:
VPS provisioned! You may now install your operating system of choice via the recovery console. Click here to continue to the VPS manager.
So I clicked, and then I naturally clicked on Recovery Console.
Recovery Console and OS Installation
I was then faced with the first obvious difference between a Xen installation and a KVM installation: SSH is not an option here, I can either choose to use VNC (Plaintext) or Spice (TLS). Since Spice (TLS) is not only selected by default, but is recommended by OpenITC because of TLS, I left it selected.
Under console details I was given a link to where I can download Spice. As I am using my laptop, I clicked the link next to virt-viewer Windows installer - 64 bit and then clicked the link for the Win x64 MSI of virt-viewer 2.0.
I ran the installer twice, and after nothing happened closed Google Drive as it was using a lot of CPU time. I then right-clicked the download and uninstalled it. I tried again, this time it installed.
I booted my new VPS using the OpenITC VPS Manager.
I downloaded the .vbs script from OpenITC and tried running it. Although it installed the certificate fine, I couldn't get it to find virt-viewer.exe and my VBS coding is not good enough to get the rest of the script to recognise paths with spaces in, so I copied the --spice-host-subject=… part from the OpenITC Recovery Console and pasted it to the right of the path in the Start Menu shortcut so it became a link to …/bin/remote-viewer.exe" --spice-host-subject….
I then pasted in the spice:// URI from OpenITC, copied and pasted the password when prompted, and was looking at an obvious error message: No bootable device. I am on the right track.
Back in OpenITC, I clicked the link to (Re)install OS from CD/DVD and then copied/pasted the link to the Ubuntu Server 14.04.1 64-bit ISO. I enabled booting from CD/DVD, saved, and was then told I can restart my VPS and continue with the installation via the recovery console, with a reminder to disable CD/DVD booting after installation has completed.
I clicked reboot, and waited. After an automated forced power off, I was informed to check the recovery console. I restarted VirtViewer Remote viewer (herein after referred to as Spice) and copied/pasted the password. I was at the familiar (from my Ubuntu LiveDVD) sight of the Ubuntu language selection menu. English, of course.
A change of Keymap (F3) to UK, and I think that is all I needed to do. Install Ubuntu Server.
I mostly chose the defaults, although I chose United Kingdom for the timezone because I couldn't find Etc/UTC in the options. I had to relaunch Spice during the installation.
I was then told there was a network issue. I chose to Configure network manually because OpenITC say that DHCP is not available for KVM. In the OpenITC VPS Manager I went back into the (Re)install OS from CD/DVD page and used it as a reference for my network settings. When it came to choosing a hostname, I went with the unimaginative vps3.thejc.me.uk.
After entering my full name, user name, and password, I was asked if I wanted to encrypt my home directory. I chose no because it might cause issues with things like SSH logins.
Next I was asked to configure the clock, with Europe/London being automatically suggested based on physical location (previous selection choices). I chose no, went right to the bottom of the available time zones, and picked UTC (None of the above).
Next up was partitioning. The options available being the following:
- Guided - use entire disk
- Guided - use entire disk and set up LVM
- Guided - use entire disk and set up encrypted LVM
Ordinarily I would choose the default here, which is the second listed option. My home server uses an encrypted LVM even though it is on all the time because I would rather it be encrypted if turned off (and potentially stolen) without my knowledge and I have gone so far as to make it impossible to be booted back up without me present to enter my passphrase.
I decided to go with the default option, but at the LVM partitioning stage I chose to only use 50% of the disk space for guided partitioning—I want to keep 50% available for backups, future use, etc.
No proxy configured, and then time for the installer to Select and install software.
After choosing not to use automatic updates I had to choose from a list of optional predefined software "To tune the system to [my] needs". The only thing I'm interested in from this list is OpenSSH Server—everything else that I will want are probably not what the Ubuntu installer will install, such as DNS server probably meaning BIND.
Something that is starting to become annoying is Spice keeps shutting down after what appears to be an idle timeout.
At 100% I reconnect yet again and see that grub is being configured. I choose to install to the MBR. After that I am faced with the installation complete dialog, and a reminder to remove any installation media. I disable CD/DVD booting in the OpenITC VPS Manager and save the changes, as I was previously told to do.
CD/DVD booting has been disabled.
After choosing to continue in Spice, the VPS rebooted. Wow, no disconnection during the reboot. After logging in I checked for and installed any updates, and since a kernel update was included I rebooted afterwards.
While the updates were being installed, I configured the rDNS of my primary IP address to mail4.thejc.me.uk and requested the second IP address with reason "SSL website web.watfordjc.co.uk". With the updates applied I rebooted the VPS.
After logging in again I was presented with some statistics for my VPS. System load was at 4.17, usage of / was at 12.5% of 11.57 GB, and memory usage was at 14%.
A look at
free -m showed that I had 441 MiB (out of 512 MiB) free, or put another way: I was using 13.87% of my RAM.
df -h said I was using 1.5G out of 12G, or 12.5%. As nothing could be removed using apt-get autoremove and autoclean, it is likely these numbers are the lowest possible without customising the kernel or something.
top said my CPU was 99.9–100.0% idle, so system load is presumably what it was during the end of the boot process.
I currently only have one IP address inside my VPS. I need to add the second.
sudo nano /etc/network/interfaces
auto eth0:0 iface eth0:0 inet static address 22.214.171.124 netmask 255.255.254.0
sudo ifup eth0:0
I then requested an IPv6 prefix, added the rDNS zone in dns.he.net, and then delegated the rDNS to
ns2.he.net,ns3.he.net,ns4.he.net,ns5.he.net. There appears to be a problem with how OpenITC calculate available IPv6 subnets for a VPS—my old VPS has −2 additional prefixes available (⁰⁄₂) and my new VPS has −2 additional prefixes available (½). Although not an issue for the moment, it might be at a later date.
After 5 minutes a DNS lookup of
dig d.126.96.36.199.0.0.8.0.8.a.c.3.0.a.2.ip6.arpa -tns @ns7.openitc.net revealed my IPv6 rDNS delegation has gone through correctly. Now I just need to add the prefix to my VPS.
I shutdown my VPS and then used the OpenITC control panel (VPS manager) to update quotas. I did this after several hours of trying to get IPv6 and my second IPv4 IP working, forgetting I needed to update quotas in order to use the new IPs.
With that done I booted my VPS, logged in, and I edited /etc/network/interfaces again:
… auto eth0 auto eth0:0 iface eth0 inet static address 188.8.131.52 netmask 255.255.254.0 gateway 184.108.40.206 dns-nameservers 220.127.116.11 18.104.22.168 iface eth0 inet6 static pre-up modprobe ipv6 address 2a03:ca80:8001:769d:: netmask 64 up /sbin/ip -6 route add 2a03:ca80:8001::/48 dev eth0 up /sbin/ip -6 route default via 2a03:ca80:8001::1 iface eth0:0 inet static address 22.214.171.124 netmask 255.255.254.0
Another reboot later and both my IPv4 IP addresses and my …::0 IPv6 IP address are able to ping google.com.
With networking configured, and the rDNS for my new VPS configured (albeit without forward DNS (A-/AAAA-Records) configured), it is time to end the VPS configuration phase and to move on to services configuration phase.
My server is not entirely secure at the moment. I need a firewall, and I need SSH access using keyed login.
Unlike my other VPS which is running on kernel 126.96.36.199-cs-domU, my new VPS is running on kernel 188.8.131.52-generic. Why am I bringing this up now? Because looking at Linux VPS security considerations I saw a mention of nftables, which is supposed to be the future replacement of iptables et al.
Linux kernel 3.13 is the first to include nftables. Unfortunately, Ubuntu 14.01 doesn't include nft or any user space tools/commands. iptables/ip6tables are, however, still included so I shall continue to use them.
As ip(6)tables is already installed, it is just a matter of creating rules and a way to restore them on reboots.
For iptables, I want to completely lock down everything. For my primary IP I want ICMP echo to work, but not for my second IP. Likewise, for SSH. I don't want to block any localhost traffic, and I want to let through responses to outgoing connections.
sudo nano /etc/network/iptables.save
*filter :INPUT DROP :FORWARD ACCEPT :OUTPUT ACCEPT ### Permit localhost traffic ### -A INPUT -s 127.0.0.1/8 -d 127.0.0.1/8 -j ACCEPT ### ICMP ### # Ignore fragmented ICMP packets -A INPUT -p icmp --fragment -j DROP # Permit ICMP echo requests to primary IP -A INPUT -d 184.108.40.206 -p icmp --icmp-type echo-request -j ACCEPT # Permit ICMP echo replies from primary IP -A OUTPUT -s 220.127.116.11 -p icmp --icmp-type echo-reply -j ACCEPT # Permit ICMP echo requests from primary IP -A INPUT -s 18.104.22.168 -p icmp --icmp-type echo-request -j ACCEPT # Permit ICMP echo replies to primary IP -A OUTPUT -d 22.214.171.124 -p icmp --icmp-type echo-reply -j ACCEPT # Permit ICMP Path MTU Discovery to/from all IPs -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT # Permit ICMP TTL exceeded to/from all IPs -A OUTPUT -p icmp --icmp-type time-exceeded -j ACCEPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT # Permit UDP traceroute rejections -A INPUT -p udp --dport 33434:33523 -j REJECT -A OUTPUT -p icmp --icmp-type port-unreachable -j ACCEPT # Ignore all other ICMP requests/replies -A OUTPUT -p icmp -j DROP -A INPUT -p icmp -J DROP ### Outgoing Connections ### -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -m conntrack --cstate NEW,ESTABLISHED,RELATED -j ACCEPT ### SSH ### # Permit SSH on primary IP -A INPUT -d 126.96.36.199 -p tcp --dport 8043 --syn -j ACCEPT ### DNS ### # Permit DNS requests to primary IP #-A INPUT -d 188.8.131.52 -p tcp --dport 53 -j ACCEPT #-A INPUT -d 184.108.40.206 -p udp --dport 53 -j ACCEPT ### HTTP(S) ### # Permit HTTP(S) connections to primary IP #-A INPUT -d 220.127.116.11 -p tcp -m multi --dports 80,443 -j ACCEPT # Permit HTTP(S) connections to secondary IP #-A INPUT -d 18.104.22.168 -p tcp -m multi --dports 80,443 -j ACCEPT ### E-Mail ### # Permit SMTP connections for inbound e-mail #-A INPUT -d 22.214.171.124 -p tcp --dport COMMIT *nat :PREROUTING ACCEPT :INPUT ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT COMMIT
sudo iptables-restore < /etc/network/iptables.save
As for IPv6, the rules I need are somewhat different because ICMP in IPv6 is pretty much required.
sudo nano /etc/network/ip6tables.save
*filter :INPUT DROP :FORWARD ACCEPT :OUTPUT ACCEPT :in-new - :permitted-dns - :permitted-mysql - ### Permit localhost traffic ### -A INPUT -s ::1 -d ::1 -j ACCEPT ### ULA Network ### # Home LAN -A INPUT -i ula-net -s fdd7:5938:e2e6:1::/64 -d fdd7:5938:e2e6:6c8d::/64 -j ACCEPT -A OUTPUT -o ula-net -s fdd7:5938:e2e6:6c8d::/64 -d fdd7:5938:e2e6:1::/64 -j ACCEPT # VPS2 -A INPUT -i ula-net -s fdd7:5938:e2e6:9660::/64 -d fdd7:5938:e2e6:6c8d::/64 -j ACCEPT -A OUTPUT -o ula-net -s fdd7:5938:e2e6:6c8d::/64 -d fdd7:5938:e2e6:9660::/64 -j ACCEPT ### ICMP ### -A in-new -p ipv6-icmp -j ACCEPT ### Outgoing Connections ### -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT ### Incoming Connections ### -A INPUT -m state --state INVALID -j DROP -A INPUT -m state --state NEW -j in-new ### SSH ### # Permit SSH -A in-new -d 2a03:ca80:8001:769d:: -p tcp --dport 8043 --syn -j ACCEPT ### ULA Network Traffic Restrictions (tunnelling) ### # ULA Traffic from Home LAN via Hurricane Electric -A in-new -i eth0 -s 2001:470:1f09:1aab::2 -d 2a03:ca80:8001:769d::2 -j ACCEPT -A FORWARD -i eth0 -s 2001:470:1f09:1aab::2 -d 2a03:ca80:8001:769d::2 -j ACCEPT # ULA Traffic from Home LAN via CJDNS #-A in-new -i tun0 -s fc1f:a237:8377:7d3b:db9b:4221:471:f46a -d TODO -j ACCEPT #-A FORWARD -i tun0 -s fc1f:a237:8337:7d3b:db9b:4221:471:f46a -d TODO -j ACCEPT # ULA Traffic from VPS2 LAN via Hurricane Electric -A in-new -i eth0 -s 2001:470:1f09:38d::2 -d 2a03:ca80:8001:769d::2 -j ACCEPT -A FORWARD -i eth0 -s 2001:470:1f09:38d::2 -d 2a03:ca80:8001:769d::2 -j ACCEPT # ULA Traffic from VPS2 LAN via CJDNS -A in-new -i tun0 -s fc33:e8dd:42c3:9871:ddca:cb6d:1aad:8c19 -j ACCEPT -A FORWARD -i tun0 -s fc33:e8dd:42c3:9871:ddca:cb6d:1aad:8c19 -j ACCEPT COMMIT *nat :PREROUTING ACCEPT :INPUT ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT COMMIT
Firewall Up Before Network
In order to bring the firewall up before the network comes up, I restore the ip(6)tables rules in /etc/network/interfaces:
… iface eth0 inet static … pre-up /sbin/iptables-restore < /etc/network/iptables.save iface eth0 inet6 static … pre-up /sbin/ip6tables-restore < /etc/network/ip6tables.save …
Note that this does not save any new changes to the ip(6)tables rules. This is because I have now decided it is easier to just modify the file and flush/reload the rules, rather than changing the rules and then hoping they get saved on reboot.
I recently covered SSH in Ubuntu Server VPS Upgrade: 12.04 Precise Pangolin to 14.04 Trusty Tahr, so I shall condense the SSH configuration into a single section here.
sudo nano /etc/ssh/sshd_config
LogLevel VERBOSE AuthorizedKeysFile /etc/ssh/%u/authorized_keys
sudo service ssh reload sudo mkdir /etc/ssh/thejc sudo chown thejc:root /etc/ssh/thejc sudo chmod 700 /etc/ssh/thejc
From VPS2, copy my authorized_keys file to vps3.
scp -P 8043 /etc/ssh/thejc/authorized_keys firstname.lastname@example.org:/etc/ssh/thejc/authorized_keys
Back on VPS3, create a symbolic link from my home folder to my ssh folder, and then disable SSH password authentication.
ln -s /etc/ssh/thejc /home/thejc/.ssh sudo nano /etc/ssh/sshd_config
sudo service ssh reload
After testing everything works, which it does, my new VPS is ready for software installation. This time I am going to try and cover each thing in its own article, if possible.