Git Version Control: Soon with Automatic Deployment!

This is the sixth and final blog post in a series around Git and a new feature in version 72, Git Version Control.  See the full list of entries in this series at the end of this post! This post talks about something that we’re adding in Version 74, which we expect will be entering EDGE sometime during the first week of July, and will be headed to CURRENT sometime in July! 


If you have been following along on the feature request site, you already know about our new feature, Git Version Control. We’re designing it to make hosting repositories as easy for developers as a “Hello World!” script — and, in cPanel & WHM Version 74, we’re adding deployment to the mix, too!

This feature will let you create and manage repositories and view change history in a friendly interface. A lot of Git’s functionality requires command line knowledge, but don’t worry! It’s easy to learn. Here’s the rundown on what you can expect from our new deployment functionality.

Automatic and Manual Deployment

cPanel’s Git Version Control feature (cPanel >> Home >> Files >> Git Version Control) automatically adds a post-receive hook to all cPanel-managed repositories.

  • When you push changes directly to a cPanel-managed repository that includes a .cpanel.yml file, the hook deploys those changes automatically.
  • For more information, read Git’s githooks documentation.

Automatic or “push” deployment of a website.

With automatic or push deployment, a single git push command sends changes from your local computer to your cPanel-managed repository. The system then automatically runs the commands in your .cpanel.yml file to send changes from the cPanel-managed repository to a production directory. (For example, to the directory that contains your website’s public files.)

Manual or “pull” deployment of a website with a remote repository.

With manual or pull deployment, the git push command sends changes from your local computer to a remote repository. When you click Update from Remote in the Manage section of the Git Version Control interface (cPanel >> Home >> Files >> Git Version Control), the system retrieves changes from the remote repository and applies them to the cPanel-managed repository. When you click Deploy HEAD Commit, the system runs the commands in your .cpanel.yml file to send changes from the cPanel-managed repository to a production directory. (For example, to the directory that contains your website’s public files.)

Prerequisites

Before deployment, repositories must meet the following requirements:

  • A valid checked-in .cpanel.yml file in the top-level directory.
  • One or more local or remote branches.
  • One or more local commits.
  • clean working tree.

If a repository does not meet these requirements, the system will not display deployment information and will disable deployment functionality.

Awesome, right?

If you already use Git, we hope that this feature will knock your socks off! If you don’t, we’re hoping we can help you start!


A note from benny:

Ready to give it a shot? The Git Version Control feature is already available to any server on the RELEASE tier. You can join us in our slack or discord channels, post your questions on the cPanel forums or subreddit, or come visit Houston, Texas for the 2018 cPanel Conference, October 1st – 3rd. Need to catch up on the previous posts about Git Version control? Here they are!

  1. What is Git? 
  2. Introducing the Git Version Control interface
  3. Introducing Gitweb
  4. Setting Up Git
  5. Git Problems and How to Fix Them
  6. Git Version Control: Soon with Automatic Deployment!

How to Spot a Phishing Email

A new well-designed phishing email has been aimed at cPanel users recently, and we want to help all of our users stay safe.

What is Phishing?

Phishing, by definition, is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication. Phishing emails can be sent to any email address. The most effective phishing emails make use of e-mail spoofing, where the ‘from’ address that your mail clients display seems to be valid. These emails will include a link that directs users to enter details at a fake website. This fake website will have the same look-and-feel as the legitimate one and are often nearly identical to the real one.

How Phishing Emails Affect cPanel Users

With cPanel & WHM powering more than 1/3 the websites on the internet, cPanel users are some of the easiest targets out there. We take steps to help end users more easily weed out some of the obvious offenders by using strict SPF records, but that doesn’t prevent all attacks. Education, reporting, and mitigation is key to preventing the effectiveness of these attacks.

What to do if you get a Phishing Email

The first step if you think you’ve received a phishing email is to confirm it.

  • check the full email headers for the ‘Sender’ address
  • check for links, logos, typos included in the email
    • Typos, misspellings, and incorrect capitalization (e.g., CPanel or Cpanel, vs. the correct cPanel) are red flags
    • URLs or names that aren’t quite right (e.g., cpanelcom.com therealcpanel.com) are red flags
  • report the email and the URL

What do they look like?

An example of a very well designed phishing email is below.

Notice that the content has very few typos, but the ‘from’ address has an incorrectly capitalized ‘CPanel.’ If you were to click on the ‘Accept the new terms’ button, you would be taken to a legitimate-looking form that appeared to be a cPanel login page, but the URL didn’t have cPanel anywhere it in.

Oh, no! I put my credentials in there!

If you fell for the trick (as so many of us have), the first step is to change the password for the impacted account. If you have used that password anywhere else, change your password there, too. Then make a plan to sign up for a password manager and start making unique passwords for each account you have.

Phishing attacks…

  • often display spoofed email addresses, to trick receivers into believing they are coming from legitimate users
  • will send users to a site that has a legitimate design, and ask for a user’s legitimate login, password, other personal details
  • need to be reported to help reduce their reach

If you spot a phishing email, report it! If you spot a phishing email that claims to be from cPanel or sends you to a cPanel login page, report it and then send that email to cs@cpanel.net with the full headers. That way we can track it them as well.

New SSL Standard Hooks for cPanel & WHM Integrators!

Hello, all you lovely people out in third-party developerland!

Don’t you hate it when you’re installing an SSL certificate through a script or API calls, but there’s some action that you want to take before or after the installation? Well, thanks to the hardworking folks on the Development Team, cPanel & WHM Version now includes a Standardized Hook for the SSL Installation event.

What is a Standard Hook?

Standardized Hooks are our way to help developers trigger events when cPanel & WHM performs a specific action. Developers use the Standard Hooks system to execute custom code (hook action code) to customize how cPanel & WHM reacts in specific scenarios (hookable events). For example, you could use this system to make certain that a script runs each time a cPanel account is created or terminated.

Take advantage of the new SSL Hooks

With the new hooks, you can automatically run code before and after the installation process. For example, if you want to touch a file  /var/cpanel/hooks_test_log_post whenever an SSL is installed you would create the /usr/local/cpanel/3rdparty/bin/techhookpost.pm script hook with the following code  (provided in Perl):

package Testhookpost;
use strict;
use warnings;
use JSON;
# Embed hook attributes alongside the action code.
sub describe { my $my_add = { 'category' => 'Whostmgr', 'event' => 'SSL::installssl', 'stage' => 'post', 'hook' => 'Testhookpost::do_the_thing', 'exectype' => 'module', }; return [ $my_add ];
}
sub do_the_thing { my ( $context, $data ) = @_; my $filename = '/var/cpanel/hooks_test_log_post'; open HANDLE, ">>$filename" or die "touch $filename: $!\n"; close HANDLE; my $result = 1; my $message = 'OK'; return $result, $message;
}
1;

Then, you would use the manage_hooks utility to register that hook:

bin/manage_hooks add script /usr/local/cpanel/3rdparty/bin/testhookpost.pm

In addition to the SSL certificate installation hook, we’ve also created an AutoSSL certificate installation hook.

Twice the fun, and twice the power!

These new hooks join the family of our other fine Standardized Hooks that you’ve come to know, love, and rely upon.

For more information, read our delicious Standardized Hook SSL documentation.


A note from benny:

Ready to give it a try? This feature is already available to any server with a supported version of cPanel & WHM. You can also join us in our slack or discord channels, post your questions on the cPanel forums or subreddit, or come visit Houston, Texas for the 2018 cPanel Conference, October 1st – 3rd. 

Git Version Control Series: Git Problems and How to Fix Them

This is the fifth in a series of blog posts around Git and a new feature in version 72, Git Version Control.  See the full list of entries in this series at the end of this post! 


If you follow our feature request site, you already know about our upcoming feature, Git Version Control. We have designed it to make hosting repositories as easy for developers as a “Hello World!” script. To make sure you get the most out of it, we want to make sure you’re familiar with Git.

When you begin learning Git, it’s easy to run into issues that might be a little tricky to solve. We want to tell you about a few of the ones we encounter the most, to keep you going full-steam-ahead with Git. If you need help with some of the Git-specific terms in this post, check out Git’s gitglossary.

Help! Apparently, I was beheaded?

While you’re getting used to how Git handles branches, it’s pretty easy to find yourself in something called “detached HEAD state.”

What this basically means is that you checked out a specific commit, rather than checking out the branch itself. Git can also enter this state if you try to switch to an upstream branch instead of the local version. When you check out the whole branch, Git moves chronologically with each recent commit (the HEAD commit at any given time). When HEAD is detached, you’re basically on your own.

Staying in this state — if it’s not intentional — can cause a lot of problems, and any changes you commit from this state might not even belong to a specific branch, so you could end up losing changes.

The easiest way to get to the right branch and preserve your uncommitted changes is to just check out another branch:

Help! Git says things have diverged — a lot.

If you see a message like this (maybe when you run git status), your branch and the remote version have separated ways:

Yikes!

If this is because you haven’t pulled down updates from the remote repository, it’s a pretty simple fix. Just run git pull, and you should be good to go with your changes intact.

Sometimes, though, it gets a little more complicated. You’re up-to-date, you make your changes, you try to commit… and some so-and-so beat you to the punch and committed changes between your last update and your commit.

This problem comes with two solutions: merging or rebasing. Which one you choose depends on how you’d like the history to look.

When you merge, Git takes everything from your version of the branch and merges it into the remote version of the branch. This results in a multi-line history, with separate lines of development running in parallel. If you rebase, Git goes back to the point when things diverged, adds the remote changes, and then applies the changes from your branch next, so you get the same nice linear history that you would’ve had if nothing had diverged.

OR

Help! I made changes, but now I don’t like them.

Making changes to any project can require a lot of back-and-forth as you try out new ideas, iterate on improvements, or repair bugs before committing. If something just isn’t working out, the simplest fix might be to just revert it to its original state.

This will grab the version of the file from the last commit to the branch and give you a clean slate to work from.

If you’re feeling a little more hardcore, and you just want to trash everything and start over, you can revert everything at once:

You’ll be returned to the branch’s state at its last commit. Be careful with this option, though. This will reset your entire working tree, and you’ll lose any local commits.

Help! I made changes in the wrong branch!

You made some awesome changes! You might have even committed those awesome changes! You went for a celebratory prune juice! … and then you realized that you did it all on the wrong branch.

This gets trickier if you already pushed your changes to your remote, but as long as things are just local, the fix isn’t too bad.

If you haven’t committed anything, you just need to create a new branch out of the current branch’s contents, and then you can reset the existing branch back to where it started:

Now, you can check out the new branch to add more changes, or continue in your current branch, which is now in the state of the last commit. Easy-peasy.

If you made a commit or two, it’s just a little more complicated. You’ll need to create and check out a new branch (or just check out an existing branch), cherry-pick the commit you want from the other branch, swap over to that branch, and then reset it:

Bam! Your changes are happily perched in the new branch, and the existing branch is back to where it started. Problem solved.

Protip: If you need to find out which branch you’re on, you can run ‘git status’ at any time. It’ll show you your current branch, its state, and any modified tracked or untracked files.

Help! I regret my commit choices!

Git wouldn’t be nearly so valuable without its revision history, and commits are a huge part of that. So, it makes sense that updating commit messages and data after the fact is a pretty common Git function.

If you just need to alter the commit message itself, you only need:

Git will open up the commit message in your preferred text editor, and you can make whatever changed you’d like. This actually creates a new commit and uses it to replace the original, but the outcome is the same as just editing.

You can also use amending to add files you forgot to add to the commit or to update author information. Using this to alter commits that you’ve already pushed is a bit trickier, though, so you’ll want a good understanding of how history revisions work before you give that a try.

Help! I’m a pacifist, but now there’s a merge conflict!

Most of the time, when you integrate changes from one branch into another, Git’s able to automatically merge everything together. Sometimes, though, you’ll run into a merge conflict.

The most common merge conflict involves two sets of changes to the same line(s) of the same file(s). The impacted file will show up in the initial warning message, or you can run git status to find a list of files:

There are some pretty cool merge tools that you can use to handle these situations, or you can fix it on the command line.

If you open up a file with merge conflicts, you’ll see some helpful indicators that show you where the problems are:

All you have to do is pick what you want to keep, and delete everything else:

Save the file, commit the changes, and the conflict is over.

If you end up seeing the same conflict often, and you always want to fix it the same way, you can be proactive and add the rerere.enabled setting to your Git config file. This records how you resolve the conflict so that Git can automatically resolve that specific conflict the next time that it occurs. This is a little advanced, though, so before you use it, read up on it more here.

I give up! Nuke it from orbit!

If you’ve exhausted everything else and your local, cloned repository’s still on fire, or if you tried a few things but don’t feel like trying anymore, you can ragequit the repository, too. Be careful, this is NOT a safe option for your remote repository! Only do this if you’re using a local repository and can re-clone a separate remote repository. Otherwise, you’re deleting your entire project and won’t be able to recover it. You could do that if you really want to, but starting over from scratch isn’t usually fun.

If you’ve decided it’s worth it, just get out of the repository directory, delete the whole thing, and then clone your project again.

Either way, you’ll lose all of your local changes… but if you’re doing this, you probably didn’t want them anyway.

We hope you don’t have to nuke things from orbit too terribly often, but even if you do, we hope our new Git Version Control feature will help that be just a little easier.


A note from benny:

Ready to give it a shot? This feature is already available to any server on the CURRENT tier. You can also join us in our slack or discord channels, post your questions on the cPanel forums or subreddit, or come visit Houston, Texas for the 2018 cPanel Conference, October 1st – 3rd. Need to catch up on the previous posts about Git Version control? Here they are!

  1. What is Git? 
  2. Introducing the Git Version Control interface
  3. Introducing Gitweb
  4. Setting Up Git
  5. Git Problems and How to Fix Them
  6. Git Version Control: Soon with Automatic Deployment!

Managing Multiple Domains from a Single Hosting Account

This post was originally added to our blog on January 31st, 2012. It has been updated for accuracy, and readability.

cPanel has made it easier to manage your domains in a single place. In this post, we will go over how to add another domain to your existing cPanel account. This tutorial will require that you have a hosting account and have access to cPanel to add the domain.

Are you unfamiliar with what DNS is or what the different DNS records mean? Please review cPanel’s DNS FAQ article for more information!

In this walkthrough, cpanel.rocks is our primary domain, and cpdocs.com is our addon domain. We will also need the nameservers from the web host, and the IP address that the addon domain will point to. The IP address is found in cPanel by clicking the Server Information tool under General Information and then viewing the Shared IP address value.

Let’s recap with some example information for the necessary DNS information:

  • cpanel.rocks— The account’s main domain. This domain was set up for you by your hosting provider. In other words, we already control this domain.
  • cpdocs.com — The domain we are going to add to our account.
  • ns1.cpanel.rocks — The server’s primary nameserver.
  • ns2.cpanel.rocks — The server’s secondary nameserver.
  • 209.59.172.159 — The IP address our addon domain will use.

What is an addon domain?

The cPanel “Addon Domains” feature allows you manage multiple domains from a single hosting account. Unlike with Parked domains, Addon domains are expected to be completely different websites all hosted inside the same cPanel account. You can also create additional sub-accounts (for example, email addresses) for your addon domains.

Why addon domains?

You can use them to save money. With addon domains, you don’t have to purchase an additional hosting account for each domain you operate. You can simply create addon domains and split your existing account’s resources.

Addon domains. How do they work?

Like subdomains, addon domains are stored in a subdirectory in your home directory. Essentially, online visitors to your addon domain are routed to this directory. As shown below, you may specify the name and precise location of this directory when creating the addon domain. Most commonly, the document root for any addon domain will be in /home/$user/$addon-domain/. In our example, the addon domain’s public_html subdirectory will be /home/$user/cpdocs.com/.

What do I need to do before creating the addon domain?

While not required, it’s a good idea to update the DNS of your domain to resolve to the server where it is hostedWe recommend contacting your web host for the proper nameservers and IP address for your serverThen, take this information to your domain’s registrar (or your hosting provider if they are the domain registrar) and update the domain’s DNS settings. If you’re not sure who your domain’s registrar is, you can always search for your domain on WHO.isThis action will perform a lookup and display which company was responsible for registering your domainIf your domain is not registered, this would be the perfect opportunity to purchase the domain from your preferred registrar.

How do I add the addon domain to cPanel?

To add an addon domain, we can use cPanel’s Addon Domains feature, in the Domains section of the cPanel interface.

  1. Enter the domain name in the New Domain Name field. In this case, we will enter cpdocs.com.
  2. Ensure the FTP username is appropriate in the next field. In this scenario, we will leave it as its default value, cpdocs.
  3. Make sure that the document root is in the appropriate place. In this example, we will use the default value, /home/$user/cpdocs.com/.
  4. Enter and confirm the password you want to use with this domain in the appropriate fields. Note- There is a checkbox to create an FTP account when adding your addon domain. Unless you specifically need an FTP account for the addon domain (i.e., allowing limited access to a developer or similar) we do not recommend creating this FTP account.
  5. Click the Add button.

If you see an error in this interface, that means that your hosting provider has not enabled this feature for your account, or there may be another problem. Please contact your hosting provider to fix the error before continuing.

Verifying our DNS settings

When adding an addon domain, cPanel will automatically create a DNS zone file for the domain. From the Zone Editor interface, we can see that the A record for ‘cpdocs.com’ is set to 209.59.172.159, the cPanel account IP address. If you do not see those options, your account may not have the correct feature permissions. The next step is to talk to your hosting provider to have the Advanced DNS Editor feature added. Once these are enabled, you will be able to see all of the DNS records assigned to your domain.

If you need to assign a different A record to your domain, you may use the “Edit an A record” function in cPanel’s Zone Editor.

Please make sure when editing the A record for your addon domain, there is a period at the end of the domain name. If this period is missing, the DNS record will be incorrect, as it will not be considered a Fully Qualified Domain Name (FQDN). Now that the DNS record has been added, the domain will begin a period of propagation. DNS records can sometimes take up 24 hours to fully propagate so a bit of patience will be required.  Once the propagation period has passed, your domain will be publicly accessible!

I’ve set up my addon domain! Now what?

Now you can start building your website!  Not sure where to get started? Why not give WordPress a try by using the WordPress Manager!  You can also discuss all of these awesome features with us over our Discord or Slack channels, on the Official cPanel subreddit, or meet us in person at the 2018 cPanel Conference!

Git Version Control Series: Setting Up Git

This is the fourth in a series of blog posts around Git and a new feature in version 72, Git Version Control.  See the full list of entries in this series at the end of this post! 


If you follow our feature request site, you already know about our upcoming feature, Git™ Version Control. We’re designing it to make hosting repositories as easy for developers as a “Hello World!” script.

Git’s extremely useful when you configure it to transfer content between a local and remote repository. When you set this up, changes on your local branch automatically push to your cPanel-hosted repository. Of course, before you can use our feature for this, you will need to set everything up.

Creating repositories

Before you can do anything in Git, you need repositories! You’ll need one on your local computer and one hosted on your cPanel account.

To create one on your cPanel account, log in and navigate to the Git Version Control interface. Then, click Create, enter a repository name and path, and click the toggle to create a new repository rather than cloning one.

Now, you want to clone that repository to your local computer. You could create a new repository with the ‘git init’ command and then hook everything up to use your cPanel-hosted repository as the remote, but trust us — this is easier.

Go back to the list of repositories, find your new repository, click the expand button, and then copy the clone URL to your clipboard. Then, run the ‘git clone’ command. (You can find that command and a few others on the success page when you first create a repository.)

Setting up your workflow

To ensure that you don’t accidentally transfer changes, create and check out a separate branch. Here, we’re calling that branch ‘release’.

Then, push the branch to the cPanel-hosted repository.

Congratulations! The branch on your local computer is connected to the branch on your cPanel account. Git now assumes that you want changes on the local branch pushed to your cPanel-hosted repository. You’re not quite finished yet, though.

Log in to your cPanel account and go to the Git Version Control interface to perform the final step. Locate the repository in the list, and click Manage.

In the Active Branch menu, you should see your branch. Select it, click update, and you’re done.

Keep everything up-to-date

Your cPanel-hosted repository is a full repository with all of the features of any Git repository. You should make sure to push and pull regularly. Unlike other Git hosts, cPanel-hosted repositories include access to the repository’s working tree. Because of this, you should work in your local computer’s copy of the repository. Then, push the work up to your cPanel-hosted repository when you’re ready.

Select the right branching strategy for your needs

When you use your repository, you’ll want to set up a branching strategy to help you separate lines of development. There are a couple of different ways to do this, and the method you choose should be tailored to your specific needs.

Skip authentication without skipping good security practices

When you push or pull, Git will ask you to authenticate with your cPanel account. To skip this step without security risks, install your SSH public key on your cPanel account and authorize it. You can use the SSH Access interface in cPanel to set this up.

Write great commit messages

When you commit changes, you also create a commit message to send with them. Good commit messages make Git really useful.

Since we display the first line in the interface, they’ll help you quickly identify the state of your active branch, too. There are some great guides to creating good commit messages.

If you already use Git, we hope that this feature will knock your socks off! If you don’t, we’re hoping we can help you start!


A note from benny:

Want to be involved in the development process? Post your ideas, comments, and questions on the feature request. You can also join us in our slack or discord channels, post your questions on the cPanel forums or subreddit, or come visit Houston, Texas for the 2018 cPanel Conference, October 1st – 3rd. Need to catch up on the previous posts about Git Version control? Here they are!

  1. What is Git? 
  2. Introducing the Git Version Control interface
  3. Introducing Gitweb
  4. Setting Up Git
  5. Git Problems and How to Fix Them
  6. Git Version Control: Soon with Automatic Deployment!

Updates to cPanel’s Privacy Policy and Customer Agreements

Privacy Shield Certification

We’ve been keeping you up-to-date about how the GDPR impacts our policies and agreements.  Today we are making two changes to our policies that are affected by the GDPR.

  • As I noted in my May 24, 2018 blog post, we had not, at that time, received notice that our Privacy Policy had been certified by the U.S. / E.U. / Swiss Privacy Shield program. Our Privacy Policy has now been certified, and our contracts and policies have been revised to reflect that.
  • We have also updated our Privacy Policy to be more clear about our cookie disclosure. Paragraph 2.2 has been updated to more precisely define the term “cPanel Product.”  This revised definition includes only software and services created by cPanel and not third-party products that may be incorporated into our software and services.

Policy Updates

Our revised policies are as follows:

  • Our revised Privacy Policy is here.
  • If you licensed our products through our store, our updated agreement is here.
  • If you are a reseller or distributor, you are required to provide our agreement to your customers. Their revised agreement is here.
  • If you have a “Partner NOC” agreement with us, amendments to your Partner NOC agreement are here.

More Info on Privacy Shield

Information about the Privacy Shield is here.  Understanding why complying with EU laws and regulations related to data flows is important. To help understand which countries provide an adequate level of data protection, and which, like the U.S., are required to implement programs to facilitate adequacy, it may be helpful to review this document.

Communication Re-Opt In

Per GDPR regulations and our data processing practices, if you wish to receive communications from cPanel moving forward and have not yet done so, you must re-opt in by completing this form.

Ask Us Your Questions

Since the GDPR implementation date, we’ve responded to quite a number of questions about its impact on our product and our customers.  We welcome the opportunity to work with you to understand how we facilitate GDPR compliance.  If you are a customer, the fastest way to interact with us is to open a ticket. Otherwise, you can email gdprquestions@cpanel.net

Removal of PHP 5.4 and PHP 5.5 in EasyApache Profiles

The week of June 18th we will be removing PHP version 5.4 and 5.5 from all cPanel-provided EasyApache 4 profiles. To help users understand what to do, and how to react when that change occurs, we’ve put together a quick list of questions that we think will frequently be asked.

What exactly will happen?

The week of June 18th (likely on June 18th, but maybe June 19th), we will push an update for EasyApache 4 that includes updated cPanel-provided profiles. With this release, the cPanel-provided profiles will no longer contain PHP 5.4 and 5.5. If you re-provision one of these profiles, these PHP versions will be removed from your server.

My customers use PHP 5.5 right now. What does this mean for me?

PHP 5.4 and 5.5 both reached End of Life more than a year ago (2.5 years ago for PHP 5.4). That means they are no longer receiving updates of any kind, including security updates, from the providers of PHP. Any user that you have on your server using these out of date versions are putting your server at risk. If your users require PHP 5.4 or PHP 5.5, we recommend you use CloudLinux. CloudLinux provides updated and patched versions of End of Life PHP and is well worth the protection if your users need it.

If you can’t get your users to upgrade, and you don’t want to use CloudLinux, you can create a custom EasyApache 4 profile.

I use a custom profile, not a cPanel-provided one. Will I be impacted?

Nope! We won’t be adjusting any customized profiles in any way with this release.

What about PHP 5.6 and 7.0? Are they going away too?

The short answer is “Yes.” We’re changing our approach with EasyApache 4, and going forward our profiles will only include supported PHP versions. That means that PHP 5.6 and 7.0 will be removed from our profiles in December of this year. Our new approach, which will be added to our documentation shortly, is this:

EasyApache 4 adheres to the php.net supported versions timeline. The profiles that we supply in WHM’s EasyApache 4 interface (WHM >> Home >> Software >> EasyApache 4) only provide PHP versions that php.net currently supports. RPMs for unsupported versions of PHP will remain on the cPanel Inc. mirrors and servers, but we will not provide any further updates.

My question isn’t here!

No problem at all! You have many avenues available to you. You can always open a ticket with our support team, or start a conversation on the cPanel subreddit. You can also find us on SlackDiscord, or the cPanel forums. No matter which avenue you take, we’re here to help! If the in-person approach is more your style, the majority of the cPanel Team will be at the cPanel Conference this October in Houston, Texas. Join us October 1st – 3rd for two days and three nights of connecting, learning, and fun.

Git Version Control series: Introducing Gitweb

This is the third in a series of blog posts around Git and a new feature in version 72, Git Version Control.  See the full list of entries in this series at the end of this post! 


If you follow our feature request site, you already know about our upcoming feature, Git Version Control. We’re designing it to make hosting repositories as easy for developers as a “Hello World!” script.

Alongside our feature, we’re also shipping a great application that’s developed by Git: Gitweb. It’s a fantastic tool for exploring your repositories from within a simple interface. (Remember, if you need help with some of the Git-specific terms in this post, check out Git’s gitglossary.)

What is Gitweb?

Gitweb makes finding information a whole lot easier than doing it on the command line. It’s comparable to some of the features included with paid Git hosting, without that pesky “paying for it” part.

Gitweb organizes your repository’s information into reports. Summary reports give you the high-level data. Detailed reports let you “drill down” into the specifics. When you navigate between commit-specific reports, Gitweb keeps everything within that context. You can also search within repository information and within the files themselves.

Gitweb may be especially helpful if you’re using our new feature to manage deliverable code. You could show changes, like website designs, to your clients without worrying about unwanted edits. All they’d need is access to a cPanel account.

Explore your repository

Gitweb’s simplest functionality allows you to browse your working tree. In oversimplified terms, the “working tree” is Git’s name for the file structure for a commit. The default shows you information from the HEAD commit, but you can also view previous versions. You can view this without Gitweb, but sometimes it’s more convenient to have it all at your fingertips.

Let’s say you want to check the contents of a file several commits ago. Without Gitweb, you’d check out that commit and then use a command-line text editor (or other tool). With Gitweb, you just locate the commit, view the working tree, and click on the file you want. Git and Gitweb call this a “blob,” but all you really need to know is that it’s the file contents.

Compare versions

Maybe just viewing a file as it was in a specific commit isn’t telling you everything you need to know. Maybe you need to evaluate line-by-line changes that came into the project recently. Maybe you need to figure out when something was added or deleted. You can view this from the command line, but it can be hard to work with. You’ll have to find what you need in a wall of not-so-pretty text, and digging deeper means running more commands.

Gitweb lets you view a comparison of two commits (a “diff“) from a couple of different reports. When you’re tracking down changes, diffs are your best bet. You can view the diff for the entire working tree or just one file, and you can compare each commit against the HEAD commit or any other commit in the project.

You can even switch between report formats. View changes side-by-side or inline, whichever suits your mood.

Investigate your project’s history

Sometimes, a diff only leads to more questions. Gitweb gives you access to some of Git’s most powerful historical tools to help you answer those questions.

You can find reports for:

  • The history of changes to individual files, so that you only have to sift through the relevant commits.
  • The branch’s logs, so that you can quickly reference recent commits in both short and long formats.
  • Each commit, so that you can view the commit message and other relevant information. That includes each commit’s author, so that you know who to blame.

If you don’t want to wait for our Git Version Control feature, you can use the default Gitweb interface with most existing repositories. Simply run git instaweb and Gitweb will open in your browser. It won’t look quite like what you’re seeing here, though, We’ve done a little bit of customization.

If you already use Git, we hope that this feature will knock your socks off! If you don’t, we’re hoping we can help you start!

Want to be involved in the development process? Post your ideas, comments, and questions on the feature request.


A note from benny:

Want to be involved in the development process? Post your ideas, comments, and questions on the feature request. You can also join us in our slack or discord channels, post your questions on the cPanel forums or subreddit, or come visit Houston, Texas for the 2018 cPanel Conference, October 1st – 3rd. Need to catch up on the previous posts about Git Version control? Here they are!

  1. What is Git? 
  2. Introducing the Git Version Control interface
  3. Introducing Gitweb
  4. Setting Up Git
  5. Git Problems and How to Fix Them
  6. Git Version Control: Soon with Automatic Deployment!