# Direct www.learnitive.com production install

This release is packaged for the production move to `https://www.learnitive.com`.

## One command workflow

1. Upload the ZIP to `/var/www/learnitive.com/`.
2. Extract it so the directory contains `run.sh` and `public_html/`.
3. Run as root:

   ```bash
   cd /var/www/learnitive.com
   chmod 755 run.sh
   ./run.sh
   ```

The root launcher performs a read-only Apache/TLS preflight **before** stopping or replacing Learnitive application services. It then promotes the existing Learnitive staging state into the production root, runs the normal production installer and acceptance suite, and finally installs/verifies the production Learnitive vhosts.

## What the production launcher does

- runs the `www` deployment profile from `/var/www/learnitive.com/public_html`;
- preserves filesystem-backed Learnitive state from `/var/www/edu.learnitive.com` when present;
- keeps the existing `learnitive_os` database and applies only normal forward migrations;
- normalizes active Learnitive service/config paths to `/var/www/learnitive.com`;
- installs `www.learnitive.com` HTTP/HTTPS routing;
- redirects `learnitive.com` to `https://www.learnitive.com` in one hop;
- redirects `edu.learnitive.com` to `https://www.learnitive.com` in one hop after the production application has passed its local acceptance checks;
- verifies production canonicals, robots/sitemap, private-route noindex, WebSocket CSP, redirects, and the removed top-menu Learn link;
- retains a backup of the previous Learnitive Apache vhost state under `/var/backups/learnitive/apache-vhosts/`.

The old `/var/www/edu.learnitive.com` filesystem tree is **not** deleted and remains available as a rollback copy.

## TLS requirement

The launcher does not run Certbot and does not alter the shared Apache module set. Existing readable certificates must already cover:

- `www.learnitive.com`
- `learnitive.com`
- `edu.learnitive.com`

The preflight first reuses a valid certificate/key already referenced by an enabled vhost for that hostname, then falls back to matching certificates under `/etc/letsencrypt/live`. Host-specific certificate paths can also be supplied with:

```bash
LEARNITIVE_WWW_TLS_CERT_FILE=/path/fullchain.pem
LEARNITIVE_WWW_TLS_KEY_FILE=/path/privkey.pem
LEARNITIVE_APEX_TLS_CERT_FILE=/path/fullchain.pem
LEARNITIVE_APEX_TLS_KEY_FILE=/path/privkey.pem
LEARNITIVE_EDU_TLS_CERT_FILE=/path/fullchain.pem
LEARNITIVE_EDU_TLS_KEY_FILE=/path/privkey.pem
```

For a certificate that covers both apex and `www`, `LEARNITIVE_TLS_CERT_FILE` and `LEARNITIVE_TLS_KEY_FILE` may be used as the shared apex/www override.

If a required certificate is missing, or an existing enabled vhost mixes a target Learnitive hostname with an unrelated hostname such as `legacy.learnitive.com`, the preflight aborts **before application services are changed**.

## Shared-server safety

The vhost step is deliberately narrow. It does not run `a2ensite`, `a2dissite`, Certbot, or change Apache modules. It snapshots Apache files belonging to Interactive Shell before and after the Learnitive cutover and aborts if any protected Interactive Shell vhost/config content changes.

Legacy enabled vhost files are automatically disabled only when their `ServerName`/`ServerAlias` set consists exclusively of `learnitive.com`, `www.learnitive.com`, and/or `edu.learnitive.com`. Mixed-domain files fail closed for manual review.