Port: string identifiers read as foreign keys, and php-fpm error log ownership

[mastacontrola]

Ports the two of today's working-1.6 fixes that this branch actually has.

1. String identifiers read as foreign keys — #1153 + #1162

FOGController infers "this is an integer id" from the key's name ending in
id. Right for every real foreign key in the tree, wrong for a string
identifier spelled the same way. The inference lives in two methods,
save() and isValid(), each with its own copy — which is the trap: fixing
only save() leaves an object that saves and then fails validation forever
after. Both are fixed here, in one commit, because splitting them serves nobody
on a maintenance branch.

The casualty list is exhaustive, not "the ones that got noticed"

Every *id key every model declares was resolved to its (table, column) pair
and typed against a real 1.5.10 install's information_schema; all 38
plugin *id columns were typed from their own Schema::createTable() lists.
Exactly two are not integers:

Model key	Column	Type	Effect	Fix here
inventory.sysuuid	iSystemUUID	varchar(255)	SMBIOS system UUID written as 0 on every inventory write	declared not-int
taskLog.taskID	taskID	mediumtext	a non-numeric value written as 0	declared not-int

Reproduced and fixed on a real 1.5 server

Shadow tree in ~ on the 1.5 lab box, running against its own database — the
live tree was never touched (grep for the guard on /var/www/html/fog after:
0):

=== UNPATCHED (live 1.5 code) ===
wrote id=2 sysuuid sent=4C4C4544-0031-3010-8039-CAC04F565831 stored='0'  LOST
=== PATCHED (this port) ===
wrote id=3 sysuuid sent=4C4C4544-0031-3010-8039-CAC04F565831 stored='4C4C4544-0031-3010-8039-CAC04F565831'  MATCH

Both probe rows were destroyed; inventory is back to 0 rows.

taskLog.taskID is fixed differently from 1.6, on purpose

1.6 fixed the column (schema 336, #1156). A column type change is a data
migration, and a maintenance branch is the wrong place to run one over a table
that can hold every task a server has ever run. Declaring the field does the
same job with no schema change. The comment in tasklog.class.php says so, and
points at #1156.

2. php-fpm's error log — #1165

Same defect here: the installer rewrites the pool to run as $apacheuser and
leaves the packaged log owned by the distro's user, so the pool cannot open the
file named by its own php_admin_value[error_log] and every error_log()
call from FOG's PHP is discarded. The log sits at zero bytes looking like an
install with no errors, and nothing reports it.

Guarded exactly like the session-path chown directly above it; the directory
is only re-owned when its own basename marks it as php-fpm's, because on Debian
the log sits directly in /var/log.

Not ported: #1163

The nginx query-string fix does not apply to this branch, and the check was not
"it looks similar":

• the installer writes no nginx vhost at all here — zero location ~ and
  zero try_files in lib/common/functions.sh; only the Apache rewrite, which
  carries [QSA,L] and was never affected;
• Route reads no query parameters here — no INPUT_GET, no
  QUERY_STRING, no $_GET[, and no queryParam() to make public;
• there is no OIDC plugin on this branch to be broken by it.

Test

tests/databasefields-notint.test.php pins both methods separately, including
that each builds its own lookup before the branch that reads it, plus the two
casualties by name. It deliberately carries no column-type sweep: 1.6's
version reads commons/schema-expected.php, which this branch does not have,
and deriving types by regex from schema.php's accumulated ALTER statements
gives wrong answers — it matched an msState belonging to a different table
when tried. The sweep was done once, properly, against a live schema; the test
pins its findings.

Eight mutations verified, all caught, including a comment-only one.
sh tests/run-all.sh → 8 passed, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_017aBSWrDArXHTpKWkkN27LR