sysadmin

Migrating a cPanel server between Cloud Hosting Providers

Published by Anonymous (not verified) on Mon, 22/10/2018 - 4:48pm in

This post is a quick run down of the steps for migrating servers so the next time I have all the steps in one place. The scenario in this case is we’re migrating a school’s server from Linode to Digital Ocean. In preparation for such a migration you need to make sure that a) we have control over the DNS for the domain (i.e. it is registered through Reclaim) or b) the domain is using a CNAME record rather than an A record. Why? CNAMES point to host names like stateu.reclaimhosting.com rather than an IP address. When moving servers the IP address will most likely change, whereas hostnames do not—which means by using CNAME records the DNS switching will be seamless.

So, once you can confirm you control the domain and/or it’s pointed to a CNAME you can start the process.

1) Setup cPanel on the target server (in this case Digital Ocean) using Reclaim’s deploy script
2) Update your local host records to point to target server’s IP address
3) Login to the target server and use the Transfer tool in cPanel to move all account from the old server (in this scenario Linode) to the target server (Digital Ocean)
4) When using the Transfer tool make sure you enter the IP of the old server rather than a hostname
5) After all the accounts have moved successfully point the hostname (which for Reclaim is in AWS’s Route 53) to the IP of the new server on Digital Ocean
6) You will also need to update the DNS Cluster on the nameservers (both ns1 and ns2) with the new API token or access hash
7) The final bit is to make sure all traffic hitting old server is redirected to new server using this guide

Here’s the code to enter in the command line on the old server:

echo “1” > /proc/sys/net/ipv4/ip_forward
sysctl net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination your.target.IP.address.here:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination your.target.IP.address.here:443
iptables -t nat -A POSTROUTING -j MASQUERADE

The other thing particular to Reclaim is that monitoring is using a URL so that will not change, but R1Soft (our backup solution) will need to have the public key refreshed. 

And that should do it.

Fixquotas

Published by Anonymous (not verified) on Wed, 01/08/2018 - 12:58am in

Tags 

sysadmin

Used the fixquotas cPanel script  this morning will working support. This comes in handy when the list of cPanel accounts showing storage quotas for each account gets corrupted. This script repairs them. I found the script while repairing Coventry’s server two weeks ago, so when I got the question this morning I knew the answer directly. It’s really simple, just run the following command from root and you are golden:

/scripts/fixquotas

Whoowns or Whoowens?

Published by Anonymous (not verified) on Tue, 31/07/2018 - 7:37pm in

Tags 

Fun, sysadmin

One of the cPanel scripts I’ve found really useful as of late is the whoowns script that let’s you know which account owns a specific domain. Let me provide a quick scenario.  You have an issue with a domain and you can’t figure out which account in lives in, which could mean it’s an addon domain that wasn’t registered through us, etc. Tracking it down can be a pain. You can figure out what server it is on by using a command like nslookup (nameserver lookeup) that will tell you the hostname and identify the server:

nslookup themissingdomain.tld

The above command will return something like beathap.reclaimhosting.com.  Which means the account is on the Beathap server, but given it is not the primary domain of an account it is not going to appear in the list of all cPanel account. And this is where I would get stuck.

But using whoowns will tell you the account owner, just log in via terminal and use the following command:

/scripts/whoowns themissingdomain.tld
themissi

That will tell you the account that domain lives in which means problem solved. A simple, useful script.

So, when extolling its virtues in Slack I wrote /scripts/whoowens —and soon after Tim had some fun and wrote his own script. So, when you run /script/whoowens on any of Reclaim’s servers you get the following:

That’s geeky and it’s awesome. Hosting humor #4life.

Users and groups in Debian: getting it right

Published by Matthew Davidson on Thu, 19/10/2017 - 1:15pm in

So ideally when I set up a new computer, I want all the users I trust — including, by necessity and regrettably, myself — to be in the staff group, and all the files they create to be by default writable by anyone in that group. This ought to be easy, and in fact now is, but has changed repeatedly over the decades I've been using Debian GNU/Linux, so I can never remember how it's done, hence this note.

You will need to do all this as root, and to be on the safe side, make sure any user(s) you want to put into the staff group are not currently logged in, as files and directories in the affected home directories will be reassigned to the group, which (I guess) won't work for any currently opened by a running process.

If you enable the pam_umask PAM module, you will only need to configure group-writability once, and it will work regardless of whether you're logging in locally, SSHing, or whatever. As root, edit /etc/pam.d/common-session to include this line:

session optional        pam_umask.so

Then edit the umask line in /etc/login.defs like so:

UMASK 002

If yours isn't a fresh Debian install, the umask setting may already have been overridden in one or more of:

  • /etc/profile
  • /etc/bash.bashrc
  • ~/.profile
  • ~/.bashrc

If so, delete or comment out where necessary. (Source)

Adding a user to the staff group is:

usermod -a -G staff myusername

Making staff the user's primary group — the one which by default newly created files and directories are owned by — is just:

usermod -g staff myusername

Too easy.

Saturday, 7 October 2017 - 6:42pm

Published by Matthew Davidson on Sat, 07/10/2017 - 6:42pm in

I should never reboot my computer.

I am so out of touch that I didn't realise that a new version of Debian came out in June. "Splendid!", I thought. So:

# apt-get update
# apt-get dist-upgrade

… then off for a walk while two gigabytes downloaded (really must get rid of all those first-person shooters that are anyway far too violent for a gentleman of my advanced years).

Get through the upgrade, reboot the computer, and my USB WiFi dongle doesn't work. Here's how to diagnose/fix:

# lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
[…]
Bus 003 Device 003: ID 045e:00cb Microsoft Corp. Basic Optical Mouse v2.0
Bus 003 Device 002: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 003 Device 007: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
[…]

Yes, I use a Microsoft mouse. Microsoft branded peripherals have generally been pretty darn good. I think this mouse is at least ten years old, and it's as good as the day I bought it. So now I know the WiFi chipset. I go to the Debian Wiki WiFi page, and find that I need the rtl8192cu driver, which is in the (non-free) firmware-realtek package, which is of course already installed because the blasted thing used to work. So now it's just a matter of:

# modprobe rtl8192cu

…and we're back in business. For good measure, I added rtl8192cu to the /etc/modules file, so that maybe I'll survive the next reboot unscathed. Not that I will be rebooting any time soon.

Note to self

Published by Matthew Davidson on Mon, 08/02/2016 - 3:05pm in

I forget this every time I go to upgrade Drupal, because it's so simple, and spend an hour trying to make absolutely sure I have it right and haven't missed anything. So assuming you're deploying Drupal with git (with the contents of sites/ untracked, presumably), all you have to do is:

git fetch
git rebase origin/7.x
drush @sites updb

Optionally, you can do a git hard reset to the latest tagged release.