sysadmin

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.

Sequel Pro’s SQL Inserts

Published by Anonymous (not verified) on Wed, 11/04/2018 - 8:24pm in

Tags 

sysadmin

Another tool I’ve  been becoming more familiar with for sites that don’t have phpMyAdmin to access the MySQL databases is Sequel Pro. It’s an open source application for managing SQL databases on the Mac.  I have come to appreciate it in newfound ways after the UNLV migration; it is to databases management what Transmit has been to moving around files via FTP.  Anyway, one think I discovered it can do is copy the structure of a database table, such as wp_users:

And then insert it as SQL code in something like PHPMyAdmin:

Sequel Pro does all SQL query structuring for me, which is awesome. Was a nice little bonus to discover, and another trick for the toolbox.

 

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.