Case Studies

The starting point

Security maintenance needs more than a version number.

An urgent PHP security release prompted SDH to verify the vendor’s fixes, maintain additional runtimes and check the operating environment. Vendor-backported fixes required examination of package builds and changelogs alongside the installed PHP versions.

The websites used EA PHP with PHP-FPM. The scope combined server maintenance, PHP security verification, backup and recovery checks, and selected website functions after the work.

The work performed

From package evidence to the running websites.

1. 01

   Prepare and test recovery

   SDH confirmed that backups were made before maintenance and that restoration testing succeeded.

2. 02

   Verify the PHP security evidence

   SDH examined package builds and changelogs and confirmed the documented EA PHP vendor fixes were already present before the additional runtime updates. The follow-up also covered active PHP workers, overrides, CGI configuration and the separate 23 October PHP advisory.

3. 03

   Maintain packages and recheck services

   The maintenance covered 114 package upgrades, CloudLinux Selector setup and a targeted service adjustment. SDH checked service state and inspected web and PHP processes for references to replaced executable files.

4. 04

   Check the websites after maintenance

   SDH recorded responses from three homepages and 102 selected assets. SDH also confirmed successful inquiry, email delivery, navigation and image checks.

The recorded outcome

Recovery, runtime and service checks.

The 24 October follow-up recorded the queried application and mail services as active. SDH reported no downtime experienced during the 21–23 October maintenance. This is SDH’s report of that work, not an uptime guarantee or a claim that every application workflow was tested.

The starting point

Conflicting packages were blocking maintenance.

An older PHP image extension depended on an older image library and prevented normal updates. Legacy package version ordering also kept older PHP and Apache builds in place.

SDH needed to align compatible packages, apply security fixes and verify the running server. The environment included a hosting control panel, Linux, Apache and four PHP branches with GD image support.

The work performed

Resolve dependencies and verify the running services.

1. 01

   Back up before maintenance

   SDH made backups and checked the installed packages and image-library conflict before applying changes.

2. 02

   Remove the update blockers

   SDH aligned compatible control-panel packages and updated image libraries to resolve the dependency and version-ordering issues.

3. 03

   Update and activate

   SDH applied PHP, Apache and operating-system updates, removed older kernel packages, and restarted to activate the updated kernel.

4. 04

   Check the live environment

   Follow-up checks covered dependencies, Apache configuration, PHP image support, service status and public homepage responses.

Recorded verification

What SDH’s maintenance record shows

Updated kernel active

The running kernel matched the updated installation; package dependencies and Apache configuration passed their checks.

4 PHP branches

GD image support loaded in all four checked PHP branches after maintenance.

0 failed services

The post-maintenance service-state check returned no failed services.

12 homepage responses

All 12 checked public homepages associated with the hosted environment returned HTTP 200 on 23 October.

The recorded outcome

The update blockers were resolved.

SDH’s record reports completed server maintenance, an active updated kernel and passing server checks. The sampled homepages responded during the post-maintenance verification.

The availability sample covered 12 homepages in the hosted environment on 23 October. These point-in-time server and homepage checks do not establish continuous availability or complete website-function testing.

The starting point

Accepted mail was waiting in the queue.

Outgoing messages entered the mail service but remained delayed in processing. SDH traced storage-path errors to the scanning integration, where a numeric version comparison selected an older storage handler.

The recovery covered the connection between message scanning, storage and delivery. Correcting the active integration also required a separate plan for messages already held in the incoming and outgoing queues.

The work performed

Correct the cause, then recover the backlog.

1. 01

   Protect the working files

   SDH backed up the mail-processing script before changing its version comparison.

2. 02

   Compare version components

   The correction compared major and minor components separately, then SDH restarted the scanning service.

3. 03

   Recover legitimate messages

   SDH backed up queue data and relocated affected messages for reprocessing, selecting legitimate mail for delivery.

4. 04

   Review the remaining queue

   SDH selectively removed reviewed unwanted and frozen items, then checked service state, queue locations and delivery responses.

Recorded verification

What SDH’s recovery record shows

New messages accepted

External receiving servers returned successful acceptance responses for new test messages from ngqcpas.com.

Delayed message accepted

Both destination providers accepted a previously delayed legitimate message after reprocessing.

0 queued · 0 frozen

The final totals followed both delivery processing and selective, reviewed cleanup.

The recorded outcome

Mail processing resumed with a clear queue.

SDH’s record describes a corrected processing path and successful handoff of new and previously delayed mail.

These are recovery-time checks. Receiving-server acceptance does not establish final inbox delivery. A clear queue includes reviewed removals as well as processed deliveries.

The starting point

Understand what is driving CPU demand

High processor use can come from growing demand, expensive queries, overlapping scheduled jobs or another resource constraint. Each cause calls for a different response.

The SDH Cloud Server assessment considers application processes, database activity, memory, storage and scheduled workloads alongside CPU measurements.

The technical approach

The proposed assessment sequence

1. 01

   Establish a baseline

   Compare representative busy and quiet periods, correlating requests, processes, queries, scheduled tasks and response times.

2. 02

   Identify the constraint

   Review memory pressure and storage latency alongside processor demand to distinguish sustained load from short peaks.

3. 03

   Plan a controlled change

   Consider job concurrency, query improvements or a suitable instance. Define a comparison period, recovery plan and restart requirements.

4. 04

   Compare service behavior

   Assess the selected change under representative workloads against the original constraint.

How the work is checked

Assessment acceptance criteria

Service response

Compare response consistency and error rates over the defined observation period.

Resource headroom

Review CPU demand together with memory and storage activity.

Workload completion

Verify scheduled jobs complete and reassess the original constraint.

Value of the approach

A decision linked to workload needs

The method supports a specific tuning or capacity decision, considering service behavior, operating headroom and cost.

Assessment findings depend on the defined workload and observation period, interpreted alongside service response, memory and storage activity.

The starting point

Restore access while protecting consistency

An unreachable primary database may reflect a network interruption or a stopped server. Promoting another database while the original accepts writes can create conflicting data.

The design considers primary and secondary roles, replication and an application connection endpoint. Promotion depends on the selected database platform.

The technical approach

The proposed recovery sequence

1. 01

   Define the recovery rules

   Establish replication mode, lag, failure signals, promotion authority and accepted recovery objectives.

2. 02

   Verify and isolate

   Confirm the failure condition and isolate the former primary where required before allowing another writer.

3. 03

   Promote and reconnect

   Follow the platform-supported procedure, coordinating application routing and connection handling.

4. 04

   Assess the returning node

   Check for divergence and identify the authoritative data source before rebuilding or rejoining replication.

How the work is checked

Recovery acceptance criteria

Write authority

One authorized writable primary and verified isolation controls.

Application checks

Successful selected transactions and a clear status for interrupted operations.

Recovery readiness

Healthy replication, backup restoration checks and working monitoring.

Value of the approach

A plan for controlled recovery

The approach defines how availability and data consistency inform each recovery decision.

These are design and acceptance criteria. Validation covers selected transactions, roles and replication behavior against agreed recovery objectives.

The starting point

Connect the update to active workloads

Installed updates may still require service restarts or dependency changes. The assessment needs to follow corrected code into the processes serving requests.

The proposed review covers the hosting platform’s operating-system packages, runtimes, dependent services and selected workloads.

The technical approach

Recommended maintenance workflow

1. 01

   Map the advisory

   Compare vendor guidance with installed builds, active processes and execution paths, accounting for supported backported fixes.

2. 02

   Prepare recovery

   Review backup readiness, dependency compatibility and restart requirements before sequencing changes.

3. 03

   Apply and activate fixes

   Use compatible vendor updates and restart affected services or the server where required.

4. 04

   Check the workload

   Review dependencies, service state and targeted workloads before closing the maintenance record.

How the work is checked

Acceptance criteria

Active fix

Package and process evidence show the applicable correction is installed and active.

Service continuity

Dependencies remain consistent and the required services are running.

Workload checks

Selected workloads complete successfully, with any temporary mitigation’s scope and review date recorded.

Value of the approach

Business value

This method connects security maintenance with operational continuity and gives customers a clear record of addressed components, activation steps and completion checks.

Verification covers the defined advisory, services and workloads. It establishes a scoped maintenance record rather than a guarantee about every security condition.

The starting point

Make the public endpoint the reference

A successful installation message alone cannot establish what visitors receive. Hostname coverage, the private key, certificate chain and public endpoint need to agree.

The proposed scope follows HTTPS through the relevant hosting, proxy or content-delivery layers. Authorized administrators handle certificate material.

The technical approach

Recommended deployment workflow

1. 01

   Identify the endpoint

   Locate where TLS terminates and compare the configured certificate with the certificate presented publicly.

2. 02

   Match the certificate

   Check intended hostnames, validity dates, the issuing chain and the certificate-to-key match.

3. 03

   Apply controlled changes

   Use supported controls and restricted key storage; arrange reissuance when a key needs replacement.

4. 04

   Verify and plan renewal

   Check each relevant termination point, record ownership and define renewal handling.

How the work is checked

Acceptance criteria

Certificate identity

Each intended hostname receives the expected certificate within its valid dates.

Trusted HTTPS

The issuing chain validates and selected HTTPS requests complete successfully.

Consistent handling

Endpoint configuration, restricted key handling and renewal responsibility are documented.

Value of the approach

Business value

This method supports dependable encrypted access and clearer ownership, helping reduce avoidable mismatches during deployment and renewal.

Validation applies to the selected hostnames and termination layers. Certificate checks provide a defined HTTPS assessment, not a universal security guarantee.