Build `hosting-repair`

We now have:

hosting-create
hosting-list
hosting-info
hosting-health

The next layer is repair.

The principle is:

Repair the failed component without rebuilding or deleting the entire website.

1. Why `hosting-repair`?

Suppose:

example.com

has:

Filesystem       ✓
PHP-FPM          ✓
PHP socket       ✗
Nginx            ✓
Database         ✓
WordPress        ✓

You don’t want:

hosting-delete example.com
hosting-create example.com

That could destroy configuration or data.

Instead:

sudo hosting-repair example.com --php

2. Repair Architecture

                    hosting-repair
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
            PHP          Nginx       Permissions
             │             │             │
             ▼             ▼             ▼
          Validate       Validate      Validate
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                      Health Check

3. Supported Repair Operations

Initial version:

sudo hosting-repair example.com --php

sudo hosting-repair example.com --nginx

sudo hosting-repair example.com --permissions

sudo hosting-repair example.com --wordpress

And eventually:

sudo hosting-repair example.com --all

4. Important Rule

hosting-repair should not blindly recreate everything.

For example:

--php

should repair:

PHP-FPM configuration
PHP-FPM service
PHP socket

It should not:

drop database
delete WordPress
delete website

5. Find Site Metadata

The repair command reads:

/var/lib/cresignsys/sites/example.com/site.conf

which provides:

SITE_ID
SITE_USER
WEB_ROOT
DB_NAME
DB_USER
PHP_VERSION
PHP_SOCKET

6. Basic Script

Create:

sudo nano /usr/local/bin/hosting-repair

Start:

#!/usr/bin/env bash

set -Eeuo pipefail

STATE_DIR="/var/lib/cresignsys/sites"

if [[ $# -lt 2 ]]; then
    echo "Usage: hosting-repair DOMAIN --php|--nginx|--permissions|--wordpress|--all"
    exit 1
fi

DOMAIN="$1"
ACTION="$2"

7. Load Site Configuration

SITE_DIR="${STATE_DIR}/${DOMAIN}"
SITE_CONF="${SITE_DIR}/site.conf"

if [[ ! -f "$SITE_CONF" ]]; then
    echo "ERROR: Site not found: $DOMAIN"
    exit 1
fi

source "$SITE_CONF"

8. Validate Action

case "$ACTION" in
    --php|--nginx|--permissions|--wordpress|--all)
        ;;
    *)
        echo "ERROR: Unknown repair action: $ACTION"
        exit 1
        ;;
esac

9. Repair PHP

The PHP repair sequence should be:

Read site configuration
       ↓
Check PHP version
       ↓
Generate PHP-FPM pool
       ↓
Validate configuration
       ↓
Reload PHP-FPM
       ↓
Check socket

10. PHP Pool Path

For PHP 8.3:

/etc/php/8.3/fpm/pool.d/SITE_ID.conf

For example:

/etc/php/8.3/fpm/pool.d/csp1027.conf

11. Generate Pool From Template

Rather than duplicating configuration in multiple scripts, use:

/etc/cresignsys/templates/php-fpm.conf

Example template:

[{{SITE_ID}}]

user = {{SITE_USER}}
group = {{SITE_USER}}

listen = {{PHP_SOCKET}}

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = {{PM_MAX_CHILDREN}}
pm.start_servers = {{PM_START_SERVERS}}
pm.min_spare_servers = {{PM_MIN_SPARE_SERVERS}}
pm.max_spare_servers = {{PM_MAX_SPARE_SERVERS}}
pm.max_requests = {{PM_MAX_REQUESTS}}

12. Why Use a Template?

Without templates:

hosting-create → PHP configuration
hosting-repair → PHP configuration

could gradually become inconsistent.

With one template:

template
   ↓
create
   ↓
repair

both use the same configuration standard.

13. PHP Repair

After generating:

php-fpm8.3 -t

If successful:

systemctl reload php8.3-fpm

Then:

test -S "$PHP_SOCKET"

14. If the Socket Is Missing

Investigate:

journalctl -u php8.3-fpm --no-pager -n 50

This may reveal:

configuration error
permission error
pool error
resource error

The repair command should ideally report the failure rather than hiding it.

15. Repair Nginx

Nginx repair:

Read site metadata
       ↓
Generate Nginx config
       ↓
Check symlink
       ↓
nginx -t
       ↓
reload nginx
       ↓
HTTP health check

16. Nginx Configuration Path

/etc/nginx/sites-available/example.com.conf

Enabled link:

/etc/nginx/sites-enabled/example.com.conf

17. Recreate Only the Site Configuration

The repair command can regenerate:

example.com.conf

from the standard template.

It should not modify:

/storage/websites/example.com/

or:

database

18. Validate

Always:

nginx -t

before:

systemctl reload nginx

If:

nginx -t

fails:

DO NOT RELOAD

19. Repair Permissions

Use:

find "$SITE_ROOT" -type d -exec chmod 755 {} \;
find "$SITE_ROOT" -type f -exec chmod 644 {} \;

and:

chown -R "$SITE_USER:$SITE_USER" "$SITE_ROOT"

But this must be adapted to the actual ownership model.

20. Important Warning

Do not automatically run:

chmod -R 777

during repair.

A repair command should never turn a permission problem into a security problem.

21. WordPress Repair

--wordpress needs to be handled differently.

We shouldn’t blindly reinstall WordPress.

First inspect:

wp core is-installed

If installed:

WordPress already exists

then repair may mean:

verify files
verify database
verify permissions
verify core

22. Verify WordPress Core

WP-CLI provides:

wp core verify-checksums

Run as the site user:

sudo -u "$SITE_USER" \
wp --path="$WEB_ROOT" core verify-checksums

This can identify modified or corrupted WordPress core files.

23. WordPress Core Repair

If the core is damaged, WP-CLI can reinstall core files without necessarily removing site content.

A controlled repair could use:

sudo -u "$SITE_USER" \
wp --path="$WEB_ROOT" core download --force

But do not execute this blindly on a production site.

Before repair:

backup
 ↓
verify
 ↓
repair
 ↓
verify again

24. Database Repair

WP-CLI:

wp db check

tests connectivity/database integrity at a basic level.

Don’t automatically run database repair commands on every health failure.

A database failure needs diagnosis first.

25. `--all`

The --all operation can eventually perform:

PHP
 ↓
Nginx
 ↓
Permissions
 ↓
WordPress verification
 ↓
Health check

But it should still avoid destructive operations.

26. Repair Locking

Repair also needs locking.

Why?

Imagine:

Admin A → hosting-repair example.com --php
Admin B → hosting-repair example.com --nginx

Running simultaneously may be okay in some cases, but concurrent modifications can still create conflicts.

Use the same per-site lock strategy as provisioning.

27. Lock Model

example.com
     ↓
/var/lock/cresignsys-example.com.lock

Then:

repair A
   ↓
gets lock
   ↓
repair

repair B
   ↓
wait/fail

28. Repair Status

When repair starts:

STATUS=REPAIRING

When successful:

STATUS=ACTIVE

When unsuccessful:

STATUS=ERROR

29. Don’t Hide Existing Errors

Suppose the site was:

STATUS=ERROR

and PHP repair succeeds.

Don’t automatically declare:

ACTIVE

until the complete health check succeeds.

Instead:

repair PHP
   ↓
health check
   ↓
healthy?

Only then:

ACTIVE

30. Repair Workflow

STATUS=ERROR
       ↓
hosting-repair example.com --php
       ↓
PHP repaired
       ↓
health check
       ↓
healthy
       ↓
STATUS=ACTIVE

If another problem remains:

PHP repaired
       ↓
HTTP still failing
       ↓
STATUS=ERROR

This is honest system reporting.

31. Repair Logs

Example:

2026-08-13 16:20 REPAIR START
2026-08-13 16:20 PHP CONFIG GENERATED
2026-08-13 16:20 PHP CONFIG VALIDATED
2026-08-13 16:20 PHP-FPM RELOADED
2026-08-13 16:20 SOCKET VERIFIED
2026-08-13 16:20 HEALTH CHECK
2026-08-13 16:20 STATUS ACTIVE

32. `hosting-repair --php`

Example expected output:

CresignSys Repair
=================

Domain: example.com
Repair: PHP-FPM

[OK]   Configuration generated
[OK]   Configuration validated
[OK]   PHP-FPM reloaded
[OK]   PHP socket available
[OK]   Health check

Status: ACTIVE

33. `hosting-repair --nginx`

CresignSys Repair
=================

Domain: example.com
Repair: Nginx

[OK]   Configuration generated
[OK]   nginx -t
[OK]   Nginx reloaded
[OK]   HTTP response

Status: ACTIVE

34. `hosting-repair --permissions`

CresignSys Repair
=================

Domain: example.com
Repair: Permissions

[OK]   Ownership
[OK]   Directory permissions
[OK]   File permissions
[OK]   WordPress access
[OK]   Health check

Status: ACTIVE

35. `hosting-repair --wordpress`

A safer workflow:

Check WordPress
      ↓
Check database
      ↓
Check checksums
      ↓
Backup if modification required
      ↓
Repair
      ↓
Verify

Don’t simply replace the entire installation automatically.

36. Why Backups Matter Before WordPress Repair

A repair operation may change:

core files
plugins
themes
database

Therefore:

repair
 ↓
backup
 ↓
modify
 ↓
verify

should become the eventual model.

37. Repair Is Not Backup

Keep separate commands:

hosting-backup
hosting-restore
hosting-repair

A repair may use backup functionality, but shouldn’t become a backup system itself.

38. Repair Should Be Deterministic

If you run:

hosting-repair example.com --nginx

twice, the second run should produce essentially the same correct Nginx configuration.

That is another form of idempotency.

39. Repair vs Reprovision

Important distinction:

Repair

Fix an existing installation.

Reprovision

Build infrastructure again.

Restore

Recover data from a backup.

Delete

Remove a site.

These should never be treated as the same operation.

40. Command Architecture

hosting-create
        ↓
new site

hosting-repair
        ↓
existing site

hosting-backup
        ↓
copy site data

hosting-restore
        ↓
recover site

hosting-delete
        ↓
remove site

41. What `hosting-repair` Should Never Do Automatically

Unless explicitly requested and carefully implemented, don’t automatically:

DROP DATABASE
rm -rf public
delete uploads
delete plugins
delete themes
change domain
change DNS

Repair should be conservative.

42. Site Recovery Matrix

You can think about failures like this:

Failure	Repair
PHP socket missing	`--php`
PHP-FPM config broken	`--php`
Nginx config broken	`--nginx`
Wrong ownership	`--permissions`
WordPress core damaged	`--wordpress`
Database unavailable	Diagnose MySQL
Website deleted	`restore`
Bad deployment	`restore`

43. Database Failure

If:

wp db check

fails, don’t automatically run:

hosting-repair example.com --database

yet.

First determine whether the problem is:

MySQL service
database user
password
database existence
permissions
disk
corruption

This deserves a separate database repair module.

44. Next Repair Module

Eventually:

hosting-repair example.com --database

can inspect:

MySQL service
database existence
database user
grants
connection

without dropping anything.

45. Health → Repair Loop

The operational cycle becomes:

HEALTH CHECK
     │
     ▼
PROBLEM DETECTED
     │
     ▼
IDENTIFY COMPONENT
     │
 ┌───┼────┬─────┐
 ▼   ▼    ▼     ▼
PHP Nginx Files WordPress
 │   │    │     │
 └───┴────┴─────┘
        │
        ▼
      REPAIR
        │
        ▼
   HEALTH CHECK
        │
        ▼
      ACTIVE

46. This Is the Beginning of Self-Healing

Eventually, the platform could automatically detect:

PHP socket missing

and recommend:

Run PHP repair

or, for safe predefined failures, automatically repair them.

However, automatic repair should be introduced cautiously.

47. Don’t Automatically Repair Everything

Some failures require human judgment.

For example:

WordPress database corruption

should not trigger:

automatic destructive repair

Instead:

ALERT
 ↓
diagnose
 ↓
backup
 ↓
human-approved repair

48. `hosting-repair` as an Operator Tool

At this stage:

Administrator
    ↓
hosting-health
    ↓
find problem
    ↓
hosting-repair
    ↓
health check

This gives you a safe operational workflow.

49. Lesson 068 — Core Principle

The purpose of repair is:

Fix the smallest possible component while preserving the site’s data and configuration.

Therefore:

PHP problem
   → repair PHP

Nginx problem
   → repair Nginx

permission problem
   → repair permissions

WordPress problem
   → verify/repair WordPress

rather than:

any problem
   → delete and recreate website

50. Current CHP Command Set

You now have the conceptual design for:

hosting-create DOMAIN
hosting-list
hosting-info DOMAIN
hosting-health DOMAIN
hosting-repair DOMAIN --php
hosting-repair DOMAIN --nginx
hosting-repair DOMAIN --permissions
hosting-repair DOMAIN --wordpress

Next we need to solve an important missing piece:

DOMAIN
  ↓
DNS
  ↓
HTTP
  ↓
HTTPS
  ↓
SSL certificate

Next Lesson — 069

Build `hosting-ssl`

We will design:

sudo hosting-ssl example.com

to handle:

DNS verification
       ↓
HTTP validation
       ↓
Let's Encrypt certificate
       ↓
Nginx HTTPS configuration
       ↓
HTTP → HTTPS redirect
       ↓
Certificate verification
       ↓
Auto-renewal
       ↓
Health check

We will also design it so SSL failures do not break an already-working HTTP website.

CresignSys Learn — Lesson 068

Build hosting-repair

1. Why hosting-repair?

2. Repair Architecture

3. Supported Repair Operations

4. Important Rule

5. Find Site Metadata

6. Basic Script

7. Load Site Configuration

8. Validate Action

9. Repair PHP

10. PHP Pool Path

11. Generate Pool From Template

12. Why Use a Template?

13. PHP Repair

14. If the Socket Is Missing

15. Repair Nginx

16. Nginx Configuration Path

17. Recreate Only the Site Configuration

18. Validate

19. Repair Permissions

20. Important Warning

21. WordPress Repair

22. Verify WordPress Core

23. WordPress Core Repair

24. Database Repair

25. --all

26. Repair Locking

27. Lock Model

28. Repair Status

29. Don’t Hide Existing Errors

30. Repair Workflow

31. Repair Logs

32. hosting-repair --php

33. hosting-repair --nginx

34. hosting-repair --permissions

35. hosting-repair --wordpress

36. Why Backups Matter Before WordPress Repair

37. Repair Is Not Backup

38. Repair Should Be Deterministic

39. Repair vs Reprovision

Repair

Reprovision

Restore

Delete

40. Command Architecture

41. What hosting-repair Should Never Do Automatically

42. Site Recovery Matrix

43. Database Failure

44. Next Repair Module

45. Health → Repair Loop

46. This Is the Beginning of Self-Healing

47. Don’t Automatically Repair Everything

48. hosting-repair as an Operator Tool

49. Lesson 068 — Core Principle

50. Current CHP Command Set

Next Lesson — 069

Build hosting-ssl

Comments

Leave a Reply Cancel reply

More posts

CresignSys Learn — Lesson 094

CresignSys Learn — Lesson 093

CresignSys Learn — Lesson 092

CresignSys Learn — Lesson 091

Build `hosting-repair`

1. Why `hosting-repair`?

25. `--all`

32. `hosting-repair --php`

33. `hosting-repair --nginx`

34. `hosting-repair --permissions`

35. `hosting-repair --wordpress`

41. What `hosting-repair` Should Never Do Automatically

48. `hosting-repair` as an Operator Tool

Build `hosting-ssl`