Closed caretakerscurse closed 2 years ago
welcome[bot]
commented
2 years ago 👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
caretakerscurse
commented
2 years ago In respect of yalls time: is there somewhere I can be pointed that show how to get my core asset data recovered so I can get a new instance running?
I will keep my current instance around if it's helpful for bug hunting.
snipe
commented
2 years ago Howdy - it looks like you are trying to run composer as root, which can sometimes have unexpected (bad) consequences. Was this an upgrade from a reeeeeeeally old version of Snipe-IT? Or a restore from a different server where there might have been table prefixes in use? The license seats table has been around for a very long time, so I can’t think of a normal reason why you’d be seeing this.
Seems like you can’t actually run artisan, which is going to be a problem, for sure. Can you run upgrade.php and show me the output? It usually tries to do a good job of troubleshooting environmental things. (You can’t run it as root though.)
caretakerscurse
commented
2 years ago Thank you for your response.
I suppose I'm technically running as root, but the P{G/U}ID is 911 for most of my containers.
It if helps I just noticed that I'm running the linuxserver/snipe-it not the proper snipe/snipe-it... not that this helps me at all but at least maybe it will help you or someone else understand how screwed I am?
This wasn't an upgrade. I had to restore the volumes from a backup after a data loss. Prior to my efforts I was in a known working state, running the latest docker container version. The database volume was restored in the same way the apps config was. The backup should have been identical, but clearly something wasn't.
No big surprise here at this point but upgrade.php is giving the same output as the others:
root@e73f89a433d1:/# php upgrade.php
Could not open input file: upgrade.phpUnless there some other magic you're aware of, I'm beyond the point of thinking there is a any coming back from this. If there is a way to recover names/serial numbers/order numbers/prices from the DB, I'm more then happy to just manually re-enter my assets on a new instance running the official repo container.
Sorry for the trouble.
snipe
commented
2 years ago Hi there - can you clarify what you mean by linuxserver/snipe-it - do you mean their docker image? (We have heard of some reports of folks having issues with that image, and only even learned of its existence kind of recently. Currently fighting with Docker to at least get an open source badge on Dockerhub so we show up as an official image. 🤬)
If you're seeing Could not open input file: upgrade.php, my guess would be that you're running that command from the wrong directory. It should be run from whatever the top level of your Snipe-IT directory is (based on your logs, I'd guess /var/www/html/.)
That said, if you did a standard backup using the Snipe-IT backup tool, it should work. That backup tool just uses a traditional mysqldump, so all tables should be present and accounted for. If you run php artisan migrate (from that Snipe-IT directory), what's the output you see?
caretakerscurse
commented
2 years ago Hello again.
Yes, I'm using their docker image. If I had known there was an official image I would have used it. I've had to migrate other packages from linuxserver for instability and trouble shooting. But they also have the only docker images for some projects.
Sorry for running the command from the wrong dir, here are the corrected outputs:
root@e73f89a433d1:/var/www/html# php upgrade.php
Skipping user check as it is not supported on Windows or Posix is not installed on this server.
--------------------------------------------------------
WELCOME TO THE SNIPE-IT UPGRADER!
--------------------------------------------------------
This script will attempt to:
- validate some very basic .env file settings
- check your PHP version and extension requirements
- check directory permissions
- do a git pull to bring you to the latest version
- run composer install to get your vendors up to date
- run migrations to get your schema up to date
- clear out old cache settings
--------------------------------------------------------
STEP 1: Checking .env file:
- Your .env is located at /var/www/html/.env
--------------------------------------------------------
--------------------------------------------------------
STEP 2: Checking PHP requirements:
--------------------------------------------------------
Current PHP version: (7.4.26) is at least 7.4.0 - continuing...
FYI: The php.ini used by this PHP is: /etc/php7/php.ini
Checking Required PHP extensions...
--------------------------------------------------------
You have the following extensions installed:
--------------------------------------------------------
- Core
- date
- libxml
- pcre
- zlib
- filter
- hash
- readline
- Reflection
- SPL
- session
- bcmath
- ctype
- curl
- dom
- fileinfo
- gd
- iconv
- json
- ldap
- mbstring
- openssl
- PDO
- standard
- SimpleXML
- sodium
- sqlite3
- tokenizer
- xml
- xmlwriter
- zip
- mysqlnd
- pdo_sqlite
- Phar
- xmlreader
- pdo_mysql
- mcrypt
--------------------- !! ERROR !! ----------------------
✘ MISSING PHP EXTENSION: mysqli OR pgsql
--------------------------------------------------------
ABORTING THE INSTALLER
Please install the extensions above and re-run this script.
--------------------------------------------------------root@e73f89a433d1:/var/www/html# composer dump-autoload; php artisan cache:clear; php artisan config:clear; php artisan route:clear; php artisan debugbar:clear; php artisan event:clear; php artisan view:clear; php artisan optimize:clear; php artisan clear-compiled
Generating optimized autoload files
> 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.
Generated optimized autoload files containing 8521 classes
Application cache cleared!
Configuration cache cleared!
Route cache cleared!
Debugbar Storage cleared!
Cached events cleared!
Compiled views cleared!
Cached events cleared!
Compiled views cleared!
Application cache cleared!
Route cache cleared!
Configuration cache cleared!
Compiled services and packages files removed!
Caches cleared successfully!
Compiled services and packages files removed!Sadly I didn't do any of the in app backups, because I -wrongly- assumed my filesystem backups would have had me covered.
root@e73f89a433d1:/var/www/html# php artisan migrate
**************************************
* Application In Production! *
**************************************
Do you really wish to run this command? (yes/no) [no]:
> yes
Nothing to migrate.If I had known there was an official image I would have used it. I've had to migrate other packages from linuxserver for instability and trouble shooting
Yeah, that's not your fault. Linuxservers gets the nice badge on Dockerhub and looks more official, even though our image is the real one. (I cannot speak to the quality of the linuxservers one, and I don't blame them for anything - this is a beef we're going through with Docker so that people like you don't get confused, and we end up trying to support something we don't know anything about.)
✘ MISSING PHP EXTENSION: mysqli OR pgsql
That one worries me a bit there... I'm surprised it can connect to the database at all if you're genuinely missing that extension, even just to tell you that a table is missing. 🤔
If you wanted to try this, you could create the license seats table manually via cli prompt. I would not normally recommend this, since we don't have a smoking gun as to why that table didn't get carried over from your backup, but I guess it can't be worse than where you're at now. In general, if one table is missing, it usually means something else has gone horribly wrong and you may end up with weird issues down the line.
If you decide to go that route, you can create the license_seats table this way via mysql cli:
CREATE TABLE `license_seats` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`license_id` int(11) DEFAULT NULL,
`assigned_to` int(11) DEFAULT NULL,
`notes` text COLLATE utf8mb4_unicode_ci,
`user_id` int(11) DEFAULT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL,
`deleted_at` timestamp NULL DEFAULT NULL,
`asset_id` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `license_seats_license_id_index` (`license_id`),
KEY `license_seats_assigned_to_license_id_index` (`assigned_to`,`license_id`),
KEY `license_seats_asset_id_license_id_index` (`asset_id`,`license_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Thank you for the quick reply,
...well... the plot thickens....
mysql> CREATE TABLE `license_seats` (
-> `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
-> `license_id` int(11) DEFAULT NULL,
-> `assigned_to` int(11) DEFAULT NULL,
-> `notes` text COLLATE utf8mb4_unicode_ci,
-> `user_id` int(11) DEFAULT NULL,
-> `created_at` timestamp NULL DEFAULT NULL,
-> `updated_at` timestamp NULL DEFAULT NULL,
-> `deleted_at` timestamp NULL DEFAULT NULL,
-> `asset_id` int(11) DEFAULT NULL,
-> PRIMARY KEY (`id`),
-> KEY `license_seats_license_id_index` (`license_id`),
-> KEY `license_seats_assigned_to_license_id_index` (`assigned_to`,`license_id`),
-> KEY `license_seats_asset_id_license_id_index` (`asset_id`,`license_id`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
ERROR 1813 (HY000): Tablespace '`snipeit`.`license_seats`' exists.I'm going to do some digging and will get back when I can.
snipe
commented
2 years ago Gaaah. That's somehow worse... lol
Is it possible you have more than one Snipe-IT database on that box?
caretakerscurse
commented
2 years ago This is my life theses days.... lol
I have wiped the dir and restored from the backup, and the volumes look good so I'm going to start testing all kinds of things including just turning off the DB container and seeing if it changes anything.
I'll post again when I learn something, or perhaps when I'm sick of finding nothing.
Thank you again so much for your time.
snipe
commented
2 years ago Keep us posted -we'll try to help where we can. Sorry you're going through this. Data recovery is always awful. :(
caretakerscurse
commented
2 years ago Turning off the DB container:
SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name does not resolve (SQL: select * from `users` where `id` = 1 and `users`.`deleted_at` is null limit 1) With a bad password in the app config:
SQLSTATE[HY000] [1045] Access denied for user 'snipeit'@'172.29.0.2' (using password: YES) (SQL: select * from `users` where `id` = 1 and `users`.`deleted_at` is null limit 1) Bad DB name in app config:
SQLSTATE[HY000] [1044] Access denied for user 'snipeit'@'%' to database 'snipeit_eh' (SQL: select * from `users` where `id` = 1 and `users`.`deleted_at` is null limit 1) So I feel safe in saying it is using the remote database.
Next I killed both volumes, started fresh containers, mostly to check that the new volumes are where I expect them. Got this on the setup page:
D'oh! Looks like we can't connect to your database. Please update your database settings in your .env file. Your database says: SQLSTATE[HY000] [1045] Access denied for user 'snipeit'@'172.29.0.2' (using password: YES) (SQL: select 2 + 2) Took a number of tests, but after I changed the user name in the app config to root that error cleared:
Great work! Connected to snipeitok... so I try with the old data in place but with the user set to root and I get the same snipeit.license_seats error... =(
Back with the recovered data in place, I tried to a manual cli connection from inside the app container to the DB container and checked for the table:
ERROR 1813 (HY000): Tablespace '`snipeit`.`license_seats`' exists.but strangely if I SHOW TABLES;:
+-------------------------------+
| Tables_in_snipeit |
+-------------------------------+
| accessories |
| accessories_users |
| action_logs |
| asset_logs |
| asset_maintenances |
| asset_uploads |
| assets |
| categories |
| checkout_acceptances |
| checkout_requests |
| companies |
| components |
| components_assets |
| consumables |
| consumables_users |
| custom_field_custom_fieldset |
| custom_fields |
| custom_fieldsets |
| departments |
| depreciations |
| imports |
| kits |
| kits_accessories |
| kits_consumables |
| kits_licenses |
| kits_models |
| licenses |
| locations |
| login_attempts |
| manufacturers |
| migrations |
| models |
| models_custom_fields |
| oauth_access_tokens |
| oauth_auth_codes |
| oauth_clients |
| oauth_personal_access_clients |
| oauth_refresh_tokens |
| password_resets |
| permission_groups |
| requested_assets |
| requests |
| settings |
| status_labels |
| suppliers |
| throttle |
| users |
| users_groups |
+-------------------------------+Now I only know enough to be very dangerous with sql but shouldn't the table in question be in this list?
In good news, using a sql client I was able to dive into the DB and see that my assets are there. Also I didn't see any rouge databases, there is just the one:
+--------------------+
| Database |
+--------------------+
| information_schema |
| snipeit |
+--------------------+So wile I'm out of time for the moment, I think I might just dump as much of the data as I can and just rebuild snipeit from the ground up. Looks like yall have some CSV importing built int so I'll have some reading up to do there....
Thank you again so much for your help @snipe
caretakerscurse
commented
2 years ago Alright, I've given up. The only other thread I have is that in the DB files there 'might' be a missing file? but I am no DBA so I couldn't say for sure.
-rwxrwxrwx 1 systemd-coredump root 8750 Apr 4 2021 kits_models.frm
-rwxrwxrwx 1 systemd-coredump root 98304 Mar 4 02:23 kits_models.ibd
-rwxrwxrwx 1 systemd-coredump root 147456 Jul 19 05:23 license_seats.ibd
-rwxrwxrwx 1 systemd-coredump root 9650 Jun 11 2021 licenses.frm
-rwxrwxrwx 1 systemd-coredump root 114688 Mar 4 02:20 licenses.ibdI was able to dive into my DB and export tables, then form that into CSVs that could be imported into a new instance.
@snipe I doubt you want to still bug hunt on this given I wasn't even using the official container, so I'm going to close the ticket. I'll be keeping my old instance around until my next housekeeping if for some crazy reason you want to dive into it further.
CLOSED: Bug likely related to use of Linuxserver.io container
Debug mode
Describe the bug
After having a data loss I'm restoring my docker instance from backup. 500 at GUI and
Table 'snipeit.license_seats' doesn't existin laravel.log.If some form of recovery and recreation is required I'll take what I can get.
Human note: Please excuse any error, oversight, or missing context from this post. I'm up past my eyeballs in recovering data / services so I'm a bit frazzled. Thank you for any and all help in advance.
Reproduction steps
chown -R 777...the volume dir (just in case)docker-compose up -d(no errors in laravel.log yet)500,Table not foundExpected behavior
Arrive at dashboard
Screenshots
No response
Snipe-IT Version
6.0.8
Operating System
Ubuntu | Docker
Web Server
Nginx
PHP Version
7.4.26
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
php -m