Deja Vu

I had a complete moment of deja vu on Friday and I have no idea why. Reclaim is putting on a workshop next week called Workshop of Own’s One. We are showing some Domain of One’s Own administrators from a few schools an in-depth look at supporting DoOO. This past week was full of research and preparation for our presentations, my topics are website migrations and domain transfers.

As I’m researching website databases, I had this strong feeling that I was sitting in a library like I was writing a research paper for a class. This was the strangest feeling too because I was sitting in the office at my laptop, definitely not the library. Tim was building a barn door to section off the unfinished side to the office, and Lauren was in the conference room working on her portion of the workshop as well. This was definitely not a library.

After the deja vu subsided, I got to thinking and realized that the learning doesn’t really stop after college. I don’t completely stop preparing presentations, researching new topics, or write blog posts. I continue to learn new things every day. And now it’s actually things I enjoy and want to learn not what I need to learn to graduate on time.

Here are what the doors look like now! They’ll be hung before the end of the week:

 

 

DNS Intro

Humans are better with names than they are with numbers. If I want to visit a specific website on the internet, I’d rather remember the domain name attached to the site (reclaimhosting.com) as opposed to the IP address of the server where the site lives (162.243.224.94).

However, computers are better with numbers, not names. So we have to find something that translates domains to IP addresses and vice versa. We do this with DNS, which stands for Domain Name System. Just as it sounds, DNS is a protocol for names of systems.

So when I type reclaimhosting.com into my web browser, I’m asking a resolver, or query participant, to send out a DNS query. What exactly is a DNS query? Well, it could look like one of two things:

•A recursive query asks the DNS server, “Can you look for the IP for me and report back?”
•An iterative query says, “if you can’t find it, send along the next place I should look. I’ll keep looking until I find an answer.”

Once the end DNS server receives the query, it sends a “hey, I’m over at this IP address!” message back to my browser. At that point, the translation is over and the browser communicates using just IP addresses from that point on.

DNS works by holding individual records. Records are simply single mappings of between a domain location and a server. (If we’re using the “your domain is your house” metaphor, a record would be a single direction to get to your house.) While there are dozens of record types, some are way more common than others. Here are the most common DNS records that you may deal with in a Domain of One’s Own instance:

A Record: This is your pointer record– kind of like speed dial for a host. It’s the most common DNS record and is used to point a domain/subdomain to an IPv.4 address.

AAAA Record (“Quad-A Record”): This is essentially an updated version of the A record built primarily for the IPv.6 address. So an A record is hardly wrong, but if both the A record and the AAAA record exist, the network will prefer the AAAA record.

CNAME Record: (Canonical Name) This record allows you to refer to a location by more than one name. A CNAME is used to map an alias to a domain name. Ex: mapping the subdomain ‘www.’ to the domain it’s associated with.

MX Record: (Mail Exchange/Mail Exchanger)- The MX record is built to identify mail services; it specifies what server is responsible for handling email associated with the domain name. If there are multiple mail servers available, you can prioritize your records.

NS Record: (Nameserver) Helps identify other nameservers in the DNS hierarchy.

TXT Record: Just that- a text record is used to store additional information.

An in-depth overview of DNS Concepts, terminology, etc can be found here.

Changing Ownership of a Hosting Account in WHMCS

Changing ownership of a web hosting account in WHMCS is surprisingly simple. But why would you want to do this? Well, say for example a student or faculty was running a club or research site and they want to pass the ownership on to another person. As of now you  still cannot have multiple admins on a cPanel account (we do hope this comes soon!), so you would have to transfer the account to the new owner.  Assuming the user you want to transfer the account to already has an account in WHMCS, all you would need to do is go to the Product/Services tab for the hosting account you want to move and click the Move/Transfer button. 

Transfer a web hosting account between users in WHMCS

Transfer a web hosting account between users in WHMCS

After that, a window will pop-up asking you to add the user’s client ID number that you want to move the account to. Once you do that and click transfer you are all done. It is really that simple. You might want to Resend the Welcome Email to the new user, but that should be all.

Resending Product Emails in WHMCS

A simple, but useful bit on WHMCS is re-sending product emails. In this instance almost always product means web hosting given that is really the only product you would provide save for a domain depending on your school. Also, the only email you would really need to resend is the Welcome Email with their FTP credentials and other details. To do this login to WHMC and search for the user in the search box in the upper right-hand corner. Once you have found them, navigate to the Products/Services tab.

Click on the Products/Services tab

After that, at the bottom of that page there is a drop-down menu for re-sending email templates, you would want to re-send the “Hosting Account Welcome Email.”

This can also be done from the Emails tab by clicking the email button next to the “New Account Information” email:

After that they should have been sent another copy of their Welcome email.

Cancel, Delete, Terminate: Removing Accounts in WHMCS

When supporting Domain of One’s Own, on e of the issues folks run into is someone having created an account they not longer want. This can happen for several reasons: they think Facebook is the one true web, they believe aliens invented the internet and are using it against humanity (distinct possibility), they don’t like the domain they created, they have done their work and want it gone, etc. Probably the most common is someone created a domain they no longer want, and would like a new domain new. If they have content on the site, this would be better done by changing the domain in WHM. But, if the account is empty, and they just want to start over, we can terminate their hosting account in WHM through WHMCS, and then delete their WHMCS account. NB: It is important that both are done on order for folks to start anew.

Click on the terminate button in WHMCS to delete the web hosting account product. Keep in mind you will still need to delete the user on order for them to create a new account.

Terminating the WHM account through WHMCS is only half the battle. Once that is done, the WHMCS account for that user most also be deleted (assuming they only had one hosting account that is now terminated) given when they try and re-create a domain from the Dashboard page in WordPress the system will only let them create a new account if there is no trace of them in WHMCS. This is one way to prevent users from creating multiple web hosting accounts.

After you have terminated the account, you will need to also delete the client’s account in WHMCS so they can create a new account from WordPress.

Once the WHMCS client is deleted there will be no more sign of that user in WHM or WHMCS, so when they login through the Domain of One’s Own portal, they will have a clean slate. Keep in mind this is not recommended if the user already has created content given terminating the web hosting account will delete all their content.

Approaching a Support Ticket

This blog post is for Domain of One’s Own support admins.

At first glance, no two support tickets look the same, which means that the process for finding a fix always looks different as well. That, mixed with a combination of vague errors & a broken dashboard can make any admin who believes he/she to be well-versed in technical domain support of any kind to feel less than adequate.

So when you’re faced with an error you’ve never seen before and aren’t sure where to turn, use the following checklist:

  1. Make sure the user’s IP isn’t blocked in CSF.
  2. Rule out the probability of a DNS resolution, Browser cache, or Network Cache Issue.
  3. Use the Error Log to eliminate the possibility of a theme and/or plugin confliction.
  4. Fix Permissions on the cPanel account.
  5. Check .htaccess files & Apache error log.

^In almost all cases, the fix can be found by starting with one of the above. If, however, you’ve made it through the list and you’re still unsure, you can always escalate the ticket to Reclaim’s support team with the following information:

  • Contact information for the user in question
    • first + last name, email address, domain name, user’s IP address
  • Screenshot of the error
  • What the user did to receive the error
  • When the issue first occurred
  • The steps you took to provide a fix

Post Icon Credit: “Support” by Gregor Cresnar from the Noun Project

Fixing Permissions

Fixing permissions of Files and Folders in an account can be a helpful step in troubleshooting a web error of your own, or someone else’s support request. Reclaim Hosting has Apache software on all servers, both Shared Hosting and Domain of One’s Own, to run behind the scenes and handle all content on the server. The software’s job is to accept requests from clients and then send responses to those requests. Apache receives a URL, translates it into a program or file name, executes it, and then sends it back to the requester. If Apache can’t complete this process, it throws an error (discussed in depth in other posts).

Sometimes permissions to handle these requests may be set too openly, which can also cause Apache to send an error to the user. All Reclaim users technically are permitted to reset their own permissions, as Reclaim servers have a shell script located at /root/fixperms.sh– this will fix permissions in the cPanel automatically (this includes all directories, not just public_html). To fix permissions on a specific account, run the following command:

sh fixperms.sh -a cpaneluser

^Make sure to replace cpaneluser with the cPanel username of the account you’d like to fix.

If you’re only really needing to fix permissions on a single directory, not the full cPanel account, navigate to the top folder in terminal and run the following commands:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

^Please note that these commands should never be used at the root of an account, but always in public_html subfolders.

Transferring Account Ownership

Occasionally we’ll get support tickets asking us to transfer the ownership of a hosting account and/or domain. This is common if leadership positions change within an organization, or if the student running a club website on a DoOO instance is graduating. The admin process for transferring ownership is essentially the same regardless of your setup:

  1. Make sure the new user already has an account. If this is on a shared hosting server, you can manually create the account for them, or ask them to sign up for an account. If this is Domain of One’s Own, the new user will have to have previously logged into your DoOO environment at least once (they don’t need to signup, but just log in). If the new user already has an account, you’ll need to give them a reseller account in WHM.
  2. In WHMCS search for the hosting account that you’ll be associating with a new user. Go to the Product/Services tab and click Move Product/Service.

Continue reading “Transferring Account Ownership”

Understanding .htaccess

All Reclaim Hosting servers run Apache Web Server Software. So when an account is provisioned the server creates a directive telling Apache what a user’s domain is and where the files for that domain are located on the server. A single server is able to host multiple sites this way because Apache reads the domain URL and then looks at its list of folders and information about each domain it has a record for and then displays the contents of the right URL.

What is a .htaccess file?

.htaccess is a configuration file that is used on all servers running Apache. The .htaccess file allows you to enable/disable Apache functions and capabilities, so it’s essentially your personal overriding feature. A .htaccess file is loaded, detected, and executed by the Apache Web server software. Though the .htaccess file sometimes comes with a few lines by default, we can write commands of our own to redirect away from 404 file not found errors, for example.

What’s something that happens by default in .htaccess? The WordPress .htaccess file will redirect labrumfield.com/index.php to labrumfield.com because there’s a rule that will tell the server that index.php is what the server should display.

What’s an example of why I would need to edit the .htaccess file? In a scenario where someone migrated a site from WordPress to Ghost, editing the .htaccess file would be helpful to redirect all old WordPress URLs and permalinks to their new location. A user may also be interested in editing their .htaccess file to force HTTPS onto their siteContinue reading “Understanding .htaccess”

Generic HTTP errors: Turning off Plugins & Themes

Occasionally you’ll go to a website and get a very general HTTP error 500 like the one shown above. Aside from “This page isn’t working” (well, duh) there really isn’t much to go off of. Naturally, the next chain of events would be to log into the WordPress dashboard and figure out what’s going on, but a lot of times that’s broken as well. So as a starting point, defining an HTTP error 500 can be helpful before understanding how it relates specifically to a single site.

HTTP error 500: The server encountered an unexpected condition which prevented it from fulfilling the request.

While that doesn’t sound like much for pointing us in the right direction, it’s more helpful than you think. It tells us what errors are not happening. For example, we know that there aren’t any temporary redirects on the site (error 307), we know that there wasn’t a network timeout (error 599), and we know that there’s definitely content at the URL, the server just doesn’t know what to do with it (error 404). P.s. if you’re ever in need of a full list of HTTP Error codes, this one is great.

Continue reading “Generic HTTP errors: Turning off Plugins & Themes”