Install from a shell

One script prepares the machine: the system user, the file layout and its modes, the systemd units, TLS, a dedicated PHP-FPM pool and a validated vhost. Then it hands over to the setup wizard and waits for real documents before telling you it worked.

git clone https://github.com/phpcip/loghound.git
cd loghound

# Look before you leap. This changes nothing at all.
sudo ./install/install.sh --dry-run

sudo ./install/install.sh

It stops at the first problem, and everything is logged in plain text to /var/log/loghound-install.log.

1. Preflight, before a single change. PHP version and every required extension, systemd or cron, the adm group, write access to the target, a complete source tree, the web server and its runtime user, the FPM pool directory, the Apache modules it needs, and a check for any file it would collide with. Prints a PASS/FAIL table and exits non-zero on any failure.
2. The system user. loghound: system account, no login shell, no home directory, added to adm for read access to /var/log. If the user already exists it is left alone, and usermod -aG only ever adds a group.
3. Files and permissions. The single most common cause of a broken install, so they are verified rather than assumed. The permission model is its own page.
4. Verification, as the actual users. Three checks, all printed — the web server user must be able to traverse the prefix and read public/index.php, and must fail to read config. Plus a test, with a real process rather than by reading /etc/group, that the service user can actually read your access logs.
5. systemd units. The tail service plus the score and retention services and timers, hardened with NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, an empty CapabilityBoundingSet and a memory cap. Both timers are enabled.
6. TLS. It looks for an existing certificate in the usual places and checks every candidate four ways: does the private key match the certificate by public key so it works for EC keys too, is it valid for at least another day, does it list your hostname, and does it chain to a trusted root.
7. PHP-FPM pool. A dedicated pool running as the service user on its own socket — never the shared pool, which would make every other site on the box execute as a user that can read your API key. Validated with php-fpm -t before anything is reloaded.
8. Vhost. Generated with your hostname, prefix, certificate paths and socket filled in, written as zzz-loghound.conf so it sorts last, then validated with apache2ctl configtest or nginx -t before being enabled. If validation fails, the files this run created are removed and validation is re-run to prove your host is back where it started.
9. The setup wizard. Hands over to bin/loghound-setup running as the service user. Pass --skip-setup to stop here and finish in a browser instead.
10. Start, and prove it. Starts the daemon, then waits up to sixty seconds for the first documents to reach Solr, rather than declaring success because a unit is running.

• Modify an existing vhost, FPM pool, cron entry, systemd unit or any file it did not write.
• restart — as opposed to reload — your web server or PHP-FPM.
• Deploy a TLS certificate it has not verified.
• Write to, truncate, rotate or delete any log file it reads.
• Overwrite config/loghound.php.

An install somewhere other than the default, with everything — the vhost document root, the pool’s open_basedir, the unit paths, the deny rules — following it:

sudo ./install/install.sh --prefix=/var/www/loghound