sysadmin

Adding Super Admin Access for WPMS

Published by Anonymous (not verified) on Wed, 05/12/2018 - 6:51pm in

Tags 

sysadmin

Image of a Superman bearing WordPress symbol on chest

Super Admin -image found at https://ben.lobaugh.net

While I’m on the sysadmin blogging tip, wanted to record another issue that came my way this week so I can remember how to solve it. WordPress Multisite (WPMS) is probably the application I am most comfortable with supporting (which is probably not saying much) because I have a pretty good sense of the way in which it abstracts the global database tables from the individual blog site tables. So, when I got a ticket this week letting about an issue with super admin access to the Network features, I was fairly certain I could solve it, especially since I asked for help with a similar issue with one of my own blogs earlier this year when moving it from a WPMS environment to a one-off WordPress blog

So, the issue here was an super admin could no longer access the Network admin dashboard after their LDAP details changed. To update the LDAP plugin they needed super admin access, but when I checked the user table there was no super admin.* Anyway, there are a few ways to give a user super admin access as Andy Feliciotti blogged brilliantly already. Given I had no users with super admin access, I was going to have to take the phpMyAdmin route which entails editing the “admins” field in the “wp_sitemeta” table. I’ll quote Feliciotti below given he was quite clear:

You’ll see some serialized data in the value of the field such as “a:1:{i:1;s:5:”admin”;}”. When you’re dealing with serialized data it can get a bit odd, but adding an admin with the user name “Andy” would be done as follows.

"a:2:{i:1;s:5:"admin";i:2;s:4:"Andy";}"

So as you can see the first number a:2 matches how many entries you have so for 3 admins you’d put 3. I simple just copied and pasted the first bit “i:1;s:5:”admin”” and added a semicolon to indicate another entry. Then increased the i by one and s matches how many characters are in the username, in my case 4. If you enter any of the variables wrong you’ll know by checking to see if your new user is an admin.

I did this and was able to restore super admin access to the user, and they could do what they needed to do, which is always nice. As for why this happened, well that might be fodder for another post when I figure it out.

*The cause of the underlying issue is one I am still looking into, not sure if the LDAP details changing had anything to do with it, but I am thinking no.

Restarting a Discourse Container

Published by Anonymous (not verified) on Wed, 05/12/2018 - 8:11am in

Tags 

sysadmin

We have a server that runs a kind of multisite Discourse environment that I discussed a number of years ago in this post. It is an Ubuntu server with Docker installed, and each of the Discourse instances on that server are spun up in Docker containers. It’s a very small, experimental part of what we do. In fact, we discontinued offering Discourse and Ghost in this kind of environment  a while back, and are far more interested in options like Cloudron, which makes hosting Ghost a breeze. That said, we have a couple of Discourse instances we still host and today the biggest one went down, which is always a bit of a scare for me given it is a unique environment. So, this post is simply going to retrace my steps in terminal to fix this because I always forget given it is not something I do often enough.

When I learned the server was down I figured I would try stopping and restarting the Container to see if that works. To do that I needed to go to var/discourse:

cd /var/discourse

From there, I tried to stop the container (to find the container name I looked in the /var/discourse/containers/ directory which has all the YAML files for each install, and the container names are everything before the .yml extension.

./launcher stop containername

That will stop the container and the following will restart it:

./launcher start containername

But when I went to stop the container I got the a storage full error, and when I ran a

df -h

on the server it was confirmed, the disk was full. I then proceeded to run the trusty NCDU command to get a sense of what was taking up all the space, and I have a suspicion it might be related to this overlay2 storage space issue others have complained about with Docker, but I took the easy route and deleted 10 GBs of old backups for the site and it was immediately back up and running. In the end a restart was not necessary, and I was able to solve a fairly random issue fairly quickly. 

Same Old Drupal

Published by Anonymous (not verified) on Wed, 05/12/2018 - 7:32am in

Tags 

drupal, sysadmin

I was fielding a ticket today for someone who was having a couple of issues with Drupal 8 after install, namely they were getting a Trusted Host Settings errorHere is the full error that shows up in the admin area:

*Errors found*
Trusted Host Settings –  Not enabled
The trusted_host_patterns setting is not configured in settings.php. This
can lead to security vulnerabilities. It is highly recommended that you
configure this. See Protecting against HTTP HOST Header attacks for more
information.

Being the awesome web hosting support technician that I am, I Googled it for a solution. And after watching the following video from the DrupalTutor I learned a couple of things:

  • This happens in Drupal  8 on install
  • This issue has been happening as far back as 2016
  • The fix is to edit the settings.php file in sites/default after changing permissions and figuring out a pretty hacky solution

The fact that this was happening to folks as soon as they installed the application is insane to me. What could be a worse user experience? Add to that the caching error below, and you have a perfect storm of terrible:

*PHP *
OPcode caching – Not enabled
PHP OPcode caching can improve your site’s performance considerably. It is highly recommended to have OPcache installed on your server.

Fact is PHP OPcode caching is enabled on this server, so you have to once again search the error message and use the fix given in this forum post to get rid of the error. I did not even check to see if they have a visual text editor after resolving these issues because I just didn’t have strength. Really Drupal?

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.