Page tree
Skip to end of metadata
Go to start of metadata

 

Overview

This document explains how the EasyApache 4 build process works and how you can receive updates when we update the Git™ repositories. 

EasyApache 4 repositories

EasyApache 4 uses many Git repositories, which each include master and production branches.

  • The production branch is the primary branch and contains changes that we push to the public and are ready to use. 
  • The master branch serves as a preview of upcoming releases and is useful to integrators who require time to adjust their own products. 

When we merge a change into either the master or production branch of an EasyApache 4 repository, the system builds the change into an RPM. When the RPM builds successfully, the system then pushes the branch upstream into the corresponding branch in the GitHub® repository. The system then sends a notification of the change to the mailing list that corresponds with the changed branch. 

EasyApache 4 build notifications

We send notifications when we make changes to the EasyApache 4 repositories. The emails contain the following information:

  • The commit message or messages.
  • The updated package with a shortened SHA.

To receive notifications when we update a repository, subscribe to one of our notification mailing lists. 

List nameSubscribeDescription
MasterSubscribeThis list reports any changes to the master branch. These changes are not ready for public use.
ProductionSubscribeThis list reports any changes to the production branch.

Note:

These mailing lists generate a large amount of traffic. The Subscribe link in the table above will subscribe you to the digest by default. We strongly recommend that you keep the list in digest mode.

Build an EasyApache 4 RPM

Important:

  • Only attempt to create your own RPM if you are an experienced system administrator. An incorrect configuration can cause your system to become unstable.  
  • We do not provide support for custom RPMs or provide instructions on how to build them.  

One of the benefits of EasyApache 4 is the ability to build your own RPMs for the system. Most users will not build their own RPMs, but if you require a custom configuration, you can use this option. 

When you are ready to build an RPM and have added your customizations, you can build it with one of the following tools:

Note:

You can also build your RPMs with the source RPMs that our OBS repository provides. We strongly recommend that you only use the GitHub RPMs.  

You must package any PHP or other language RPM as a Software Collection (SCL). 

An SCL is an alternate path inside the /opt file that contains the full file system that various software requires. When you enable an SCL, it adds the path within that environment to the system. The following situations use this path determine the correct software version:

  • Commands that do not specify a path.
  • Scripts that use the /usr/bin/env file to determine their path. 

In cPanel & WHM version 64 or earlier, all EasyApache 4 packages must begin with the ea- prefix. In cPanel & WHM version 66 and higher, the MultiPHP system in EasyApache 4 recognizes SCL PHP packages with prefixes other than  ea- . This allows the use of vendor-provided packages. We strongly recommend that you  use a prefix other than  ea- with an SCL PHP package. 

Note:

You cannot use a prefix other than ea- with any package other than an SCL PHP package. 


The Software Collections standard determines the rest of the name. We strongly recommend that you use the same naming convention for Apache packages. You cannot create an Apache collection as a Software Collection. 

If you wish to implement the whole stack with your repository, you must adhere to the following restrictions:

  • Do not modify or remove the ea-profiles-cpanel package. EasyApache 4 requires this package to function.  
  • You must name your packages with the ea-profiles-vendor syntax, where vendor represents the vendor's name.
  • The package must install your profiles in the /etc/cpanel/ea4/profiles/vendor/vendorname directory, where vendorname represents the vendor's name. 

After you successfully build and package your RPM, upload it to your own repository. For more information, read our Yellowdog Updater, Modified (yum) Basics documentation.