Closed tzielinskiaptn closed 1 year ago
You might be able to figure out which dependencies are broken using php -m
and repair/reinstall those with your package manager until you have addressed all the dependencies Snipe-IT requires (check the docs). Possibly PDO for example.
Thank you for the suggestion, I've read through the installation and configuration docs, and I don't see a list of PHP extensions that SnipeIT depends on. EDIT: I'm an idiot. I see them listed in requirements. Thank you for reminding me.
Also if there are any additional guides for updating PHP/MariaDB/SnipeIT specifically on Windows/IIS machines that would be super helpful.
I've got the PHP issues sorted out. Does anyone know what version of MariaDB is supported for SnipeIT? The docs say 10.0.0.14 but that was built in 2014.
The docker-compose uses 10.6 LTS
Great, thank you, that's excellent information.
I've made the changes, I have PHP 7.4.33 running with all extensions required, and maria DB 10.6.11 running.
I performed a manual upgrade from 5.0.4 to 6.0.13. I did not see any errors installing packages, and the table migrate went just fine.
When I launch my site I see the following instead of the view I'm used to:
I checked the common issues, and I didn't see anything pertaining to this.
I ran through all the clears in the installing/upgrading common issues thread,
EDIT: clicking on links trigger 404 errors.
What's your error log telling you? I'm pretty sure this can be caused by a number of things from permissions issues to problems with app_URL or your apache/IIS configuration.
I'm not seeing anything in the laravel log, and for the IIS I'm seeing the 404 errors:
2022-11-22 16:46:25 10.0.0.40 GET /js/dist/bootstrap-table.js id=14d9a2affec7b066d20fcba2e6e67ad2 80 - 10.0.0.205 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/107.0.0.0+Safari/537.36+Edg/107.0.1418.52 - 404 0 2 0 2022-11-22 16:46:25 10.0.0.40 GET /vendor/livewire/livewire.js id=c69d0f2801c01fcf8166 80 - 10.0.0.205 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/107.0.0.0+Safari/537.36+Edg/107.0.1418.52 - 404 0 2 0
I appreciate your help, debugging webservers is not something I do very often.
Is there another log I should check out?
I would double check your APP_URL doesn't have any of the most common errors. Ensure this is set to your root URL such as https://localhost or https://mysnipeapp.com. Make sure it's http or https as appropriate for whether you are running with or without cert. No trailing slash or /public or /login?nosaml or anything. Also try running composer and pay close attention to errors composer install --no-dev --prefer-source
(they'll often indicate missing or malfunctioning php modules). Double check IIS setup https://snipe-it.readme.io/docs/windowsiis
I've verified my app_url is http://snipeit.aptn.local (which it has always been)
I've run through the IIS configuration - PHP is registered, mappings are good, folder permissions for IUSR have been set as per the doc.
Re-ran composer install --no-dev --prefer-source
Here's the output:
C:\inetpub\wwwroot\SnipeIT>composer install --no-dev --prefer-source Installing dependencies from lock file Verifying lock file contents can be installed on current platform. Nothing to install, update or remove Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead. Package swiftmailer/swiftmailer is abandoned, you should avoid using it. Use symfony/mailer instead. Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested. Generating optimized autoload files Warning: Ambiguous class resolution, "ReCreateLicensesTable" was found in both "C:/inetpub/wwwroot/SnipeIT/database/migrations/2013_11_25_013244_create_licenses_table.php" and "C:/inetpub/wwwroot/SnipeIT/database/migrations/2013_11_25_013244_recreate_licenses_table.php", the first will be used. Class ParsedownTest located in C:/inetpub/wwwroot/SnipeIT/vendor/erusev/parsedown\test\ParsedownTest.php does not comply with psr-0 autoloading standard. Skipping.
Illuminate\Foundation\ComposerScripts::postAutoloadDump @php artisan package:discover --ansi Discovered Package: arietimmerman/laravel-scim-server Discovered Package: barryvdh/laravel-debugbar Discovered Package: barryvdh/laravel-dompdf Discovered Package: eduardokum/laravel-mail-auto-embed Discovered Package: facade/ignition Discovered Package: fideloper/proxy Discovered Package: fruitcake/laravel-cors Discovered Package: intervention/image Discovered Package: laravel/passport Discovered Package: laravel/slack-notification-channel Discovered Package: laravel/tinker Discovered Package: laravel/ui Discovered Package: laravelcollective/html Discovered Package: livewire/livewire Discovered Package: maatwebsite/excel Discovered Package: mediconesystems/livewire-datatables Discovered Package: nesbot/carbon Discovered Package: nunomaduro/collision Discovered Package: pragmarx/google2fa-laravel Discovered Package: spatie/laravel-backup Discovered Package: unicodeveloper/laravel-password Package manifest generated successfully. @php artisan vendor:publish --force --tag=livewire:assets --ansi Copied Directory [\vendor\livewire\livewire\dist] To [\public\vendor\livewire] Publishing complete. 84 packages you are using are looking for funding. Use the
composer fund
command to find out more!
The site was running with version 5.0.4, I tested after changing the PHP version to 7.4.33 and upgrading the DB to 10.6. I was not seeing these errors.
I took a backup of my SnipeIT folder. If I stop IIS, change the folder names and restart IIS is it possible to walk back to 5.0.4 or are there extra steps to revert?
I'm not sure about downgrading. You mentioned that the table migrate went fine. If you run it again does it just say nothing to migrate? Is there anything in IIS (e.g. PHP manager, URL rewrite installed and working?) that might indicate a problem? I'm assuming that you'll see 404 errors if you check your browser windows console (dev tools) but whether there's something else that clues you into the issue. Whenever I've run into issues on IIS I've typically just review the setup steps in the following tutorial to remind me which parts to look at (not sure if it will help your specific case): https://www.youtube.com/watch?v=AHNi9eU9icw&t=84s
I'll give the tutorial a watch. For now I'm trying a clean extract and install following the manual upgrade instructions. If I get that working then I'll look at converting it to a GIT install.
Worst case, I re-apply my Veeam image of the VM from last night and go back to a working 5.0.4.
Alright, I realized I was using port 8080 for my site, changing the binding to port 80 seems to have resolved a lot of the issues. If I wanted to use an alternate port, would I just have to add that to the app_url?
Also weird one, I can't seem to hit the site from a web browser on the IIS server itself, I'm not 100% sure why.
I think I'm mostly up and running for now.
Yes, I think something like http://snipeit.aptn.local:8080 (it's what I'd typically do in development on Vagrant or something). I can't remember all my IIS settings and have been using Linux for a while.
If you can't reach it locally, the host file (C:\Windows\System32\drivers\etc) might have been modified. It could also just be a firewall. I seem to remember that with IIS, it was really particular about connecting with the URL listed in IIS bindings and not just http://localhost:8080 for example. Or maybe it was the other way around.
Thanks, that's a good starting place. At least I have it running on Port 80. It's an internal server, and there isn't anything else really running on that VM, so I'm good to tinker.
Plus I can tell my supervisor the DB engine is updated.
On that note, I've uninstalled MariaDB 10.0 and 10.2, and I have 10.6 running.
The instance has been updated, and checkins and checkouts on the site seem to be working, along with my LDAP sync.
When I try to do a DB backup, I get a failure about the path not being found.
I've updated the DB_DUMP_PATH to equal DB_DUMP_PATH=C:\PROGRA~1\MARIAD~1.6\bin do I need quotes? Or is there another step I need to do to pick up the updated path?
EDIT. I did an artisan config:cache after the change, and the dbdump works now... so I'm cautiously good to go.
All good now, thanks all for your help.
Debug mode
Describe the bug
I am in the process of upgrading a working install of Snipe-IT 5.0.4 to 6.1.3.
This is a manual install on Windows Server 2019 (IIS 7)
I've upgraded my PHP to 8.1.2 from 7.2.7
I've also upgraded MariaDB from 10.0.14 to 10.10.2
I am getting an error running PHP Artisan Migrate - Illuminate\Database\QueryException
could not find driver (SQL: select * from information_schema.tables where table_schema = aptn and table_name = migrations and table_type = 'BASE TABLE')
Also getting a 500 error on my snipeit site, but I'm guessing I messed up one of the settings while switching PHP.
There's not a lot of documentation for Windows/IIS.
Reproduction steps
...
Expected behavior
I expect the tables to be migrated.
Screenshots
No response
Snipe-IT Version
6.1.3
Operating System
Windows Server 2019
Web Server
IIS
PHP Version
8.1.12
Operating System
No response
Browser
No response
Version
No response
Device
No response
Operating System
No response
Browser
No response
Version
No response
Error messages
Additional context
This is a manual install of a working deployment of SnipeIT 5.0.4 upgrading to 6.1.3.
I broke the cardinal rule and tried to upgrade a few dependencies at once.
I'd like some direction on verifying I've got the right PHP running as well as which version of MariaDB is supported.
This process was triggered by a security issue being detected in the previous version of MariaDB, and I figured while I was upgrading that, I may as well do the whole setup.