Snipe-IT php upgrade.php install
-
Here is a github ticket I've opened to formally track the issue.
-
Running
php upgrade.php installwith sudo immediately fails as there are permissions issues that get caused.So that isn't an option.
-
Have you tried doing it this way?
sudo -u apache php upgrade.php install -
@black3dynamite said in Snipe-IT php upgrade.php install:
Have you tried doing it this way?
sudo -u apache php upgrade.php installWhy aren't you sitting next to me. That seems to have been it.
-
I still get some permission denied errors, but the system upgraded to 4.1.4
-
@dustinb3403 said in Snipe-IT php upgrade.php install:
I still get some permission denied errors, but the system upgraded to 4.1.4
What other permission denied errors?
-
PHP Notice: Undefined offset: 1 in /var/www/html/snipeit/upgrade.php on line 16 Welcome to the Snipe-IT upgrader. Please note that this script will not download the latest Snipe-IT files for you unless you have git installed. It simply runs the standard composer and artisan commands needed to finalize the upgrade after !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! If you have any encrypted custom fields, BE SURE TO run the recrypter. !! See the Snipe-IT documentation for help: !! https://snipe-it.readme.io/docs/upgrading-to-v4 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -------------------------------------------------------- STEP 1: Backing up database: -------------------------------------------------------- -- Starting backup... Dumping database snipeit... Backup failed because The dump process failed with exitcode 1 : General error : sh: /var/www/html/snipeit/storage/laravel-back ups/temp//snipeit.sql: Permission denied . Backup completed! -------------------------------------------------------- STEP 2: Putting application into maintenance mode: -------------------------------------------------------- -- Application is now in maintenance mode. -------------------------------------------------------- STEP 3: Pulling latest from Git (master branch): -------------------------------------------------------- Git is installed. Already on 'master' -- No local changes to save -- -- Already up-to-date. -------------------------------------------------------- Step 4: Cleaning up old cached files: -------------------------------------------------------- -- No bootstrap/cache/compiled.php, so nothing to delete. -- Deleting bootstrap/cache/services.php. It it no longer used. -- Deleting bootstrap/cache/config.php. It it no longer used. -- Configuration cache cleared! -- Cache cleared successfully. -- Route cache cleared! -- Compiled views cleared! -------------------------------------------------------- Step 5: Updating composer dependencies: (This may take an moment.) -------------------------------------------------------- -- Local composer.phar detected, so we'll use that. Cannot create cache directory /usr/share/httpd/.composer/cache/repo/https---packagist.org/, or directory is not writable. Proc eeding without cache Cannot create cache directory /usr/share/httpd/.composer/cache/files/, or directory is not writable. Proceeding without cache Generating optimized autoload files Cannot create cache directory /usr/share/httpd/.composer/cache/repo/https---packagist.org/, or directory is not writable. Proc eeding without cache Cannot create cache directory /usr/share/httpd/.composer/cache/files/, or directory is not writable. Proceeding without cache Loading composer repositories with package information Installing dependencies from lock file Package operations: 0 installs, 0 updates, 23 removals - Removing squizlabs/php_codesniffer (3.1.1) [RuntimeException] Could not delete /var/www/html/snipeit/vendor/squizlabs/php_codesniffer/.git/refs/heads/master: date_default_timezone_get (): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you m ost likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to se lect your timezone. install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scri pts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-aut oloader] [--ignore-platform-reqs] [--] [<packages>]... -------------------------------------------------------- Step 6: Migrating database: -------------------------------------------------------- -- Nothing to migrate. -------------------------------------------------------- Step 7: Checking for OAuth keys: -------------------------------------------------------- - OAuth keys detected. Skipping passport install. -------------------------------------------------------- Step 8: Caching routes and config: -------------------------------------------------------- -- Configuration cache cleared! Configuration cached successfully! -- Route cache cleared! Routes cached successfully! -------------------------------------------------------- Step 9: Taking application out of maintenance mode: -------------------------------------------------------- -- Application is now live. -------------------------------------------------------- FINISHED! Clear your browser cookies and re-login to use : your upgraded Snipe-IT. -------------------------------------------------------- -
Did you check the SELinux context for those? I would disable SELinux and run the script. that would inform you.
-
@jaredbusch What would an selinux denial look like so I can search for it?
-
You can get rid of the message about not able to create cache directory by following this post.
https://mangolassi.it/topic/15461/snipe-it-cannot-create-cache-directory -
@dustinb3403 said in Snipe-IT php upgrade.php install:
@jaredbusch What would an selinux denial look like so I can search for it?
You can find SELinux denial by doing one of the following:
# If you have setroubleshoot-server package installed sealert -a /var/log/audit/audit.log OR tail -f /var/log/audit/audit.log | grep 'denied' -
No denials found.
100% done found 0 alerts in /var/log/audit/audit.log -
@dustinb3403 said in Snipe-IT php upgrade.php install:
No denials found.
100% done found 0 alerts in /var/log/audit/audit.logIs apache the owner of snipeit directory, subdirectories, and files?
-
@black3dynamite said in Snipe-IT php upgrade.php install:
@dustinb3403 said in Snipe-IT php upgrade.php install:
No denials found.
100% done found 0 alerts in /var/log/audit/audit.logIs apache the owner of snipeit directory, subdirectories, and files?
apache : apache owns at least storage, which is where those files are. (I am a part of this group)
