Unable to run CLI commands on official Docker images

[maxxer]

Hi.
I'm trying to run CLI commands using the official Docker image for v8.7.1, but it complains about PHP version being not compatible.

❯ docker run --rm snipe/snipe-it:v8.7.1 php artisan ldap:troubleshoot --force
PHP Version: 8.3.6 WARNING - Versions before 8.3.21 or 8.4.7 will return INCONSISTENT results!

 Are you sure you wish to continue? (yes/no) [no]:
 > ABORTING

If I want to run an unattended command (like in a cloud environment), I'm unable to bypass that check, and thus I'm unable to run the command...

The image should be shipped with a compatible php version

[kratos0718]

You've hit an actual inconsistency in the command rather than doing anything wrong — --force genuinely doesn't cover that prompt.

In app/Console/Commands/LdapTroubleshooter.php the other two confirmations are guarded by the flag:

// ~line 149
if (! $this->option('force')) {
    $confirmation = $this->confirm('WARNING: This command will display your LDAP password on your terminal. ...');

// ~line 207
if (! $this->option('force')) {
    $confirmation = $this->confirm('WARNING: This command will make several attempts to connect to your LDAP server. ...');

but the PHP-version one isn't:

// ~line 200
$this->warn("PHP Version: $php_version WARNING - Versions before 8.3.21 or 8.4.7 will return INCONSISTENT results!");
if (! $this->confirm('Are you sure you wish to continue?')) {   // <- no option('force') check
    $this->warn('ABORTING');
    exit(-1);
}

Given --force is documented in the signature as "Skip the interactive yes/no prompt for confirmation", that looks like an oversight rather than intent — the same wrapper as the other two would fix it.

Why --no-interaction won't rescue you either. Laravel's confirm() signature is confirm($question, $default = false), so under -n it returns the default, which is false, and you land on ABORTING anyway. That's worth knowing before you reach for it.

Working around it today, feed the prompt on stdin — note the -i, without it Docker gives the process no stdin at all:

docker run --rm -i snipe/snipe-it:v8.7.1 \
  sh -c 'yes | php artisan ldap:troubleshoot --force'

yes answers this prompt and anything else the run asks (there are further confirm() calls later in the command, around line 427, for the authentication attempts). If you'd rather answer only this one, printf 'yes\n' | in place of yes | works.

On the image's PHP version — you're reading it right. The Dockerfile is FROM ubuntu:24.04 installing distro php8.3-* packages, and noble ships the 8.3.6 line, patched by Ubuntu rather than tracked to upstream 8.3.21+. So the check compares upstream version numbers against a distro-patched build and will keep firing on this image no matter what. Ubuntu may well have backported the relevant fix into 8.3.6-ubuntuN without the version string moving — which is exactly the case that version-number comparisons can't distinguish.

That's arguably the more useful thing for the maintainers here: the guard is a straight version_compare-style check, so any distro-packaged PHP will trip it regardless of what's actually patched in.

[maxxer]

Thank you very much for the detailed review! Are you filing an issue for the --force mishandling in this command, or should I?

About the Distro issue, that's not an easy call. I was experimenting in using Ondrej PPA to install the latest 8.3 in the image, but I'm unsure if it's the best solution.

[kratos0718]

I've filed it — PR is up at #19514, since I had the file open anyway.

It just wraps that confirmation in the same if (! $this->option('force')) the other two already use, and leaves the warn() outside the guard so the caveat still shows up in unattended logs even when the prompt is skipped. php -l is clean; with confirm() stubbed to what a non-interactive run returns, --force=false still aborts and --force=true now continues, so nothing changes for the interactive path.

On the distro question — I'd gently push back on reaching for the Ondřej PPA. Ubuntu's 8.3.6-*ubuntu*N is a security-supported build with fixes backported and the upstream version string left alone, so it may well already contain whatever the LDAP check is worried about; you'd be swapping a supported package for a third-party one to satisfy a string comparison. The check itself is the weak part: any distro-packaged PHP will trip it regardless of what's actually patched in, so a PPA today just moves the problem to whenever the next threshold gets added.

If the goal is for the warning to be accurate rather than merely quiet, that's really a question for the maintainers about how the version gate should work at all — worth raising separately from your original ask, and I've kept it out of the PR for that reason.

[kratos0718]

No need, I opened #19514 for it earlier today. It is just the missing if (! $this->option('force')) around that one confirm, so it matches the two guards already above it. Happy to file a separate issue as well if you would rather track it that way.