Jeremy Davis's picture
Jeremy Davis - Fri, 2022/01/07 - 13:55

I just discovered that Aleksand posted on GitHub asking about how to update Snipe-IT. Rather than answer there, I thought I'd post here instead.

Please note that this only applies to a v16.x server, future releases (i.e. v17.0 or later) should be easy as the line line of this post... (TBC)

Reading the upgrade docs, it looks like git install is preferred. Unfortunately, our v16.x Snipe-IT appliance uses tarball install, so we could use the manual upgrade path. As git install is preferable, I'm aiming to move the appliance to a git install, so now is a good time to switch your server to git install too, so let's do that. This will basically be what the docs note, but we'll use the custom TurnKey tools.

First SSH in as root (or use Webshell - don't use the shell in Webmin! - it's not a proper interactive shell).

First run a backup. If you're using TKLBAM, then:

tklbam-backup --full-backup now

If you're not using TKLBAM or you want a local backup as well, then create a local backup like this (using TurnKey's PHP artisan wrapper):

turnkey-artisan snipeit:backup

Then rename the current Snipe-IT directory and clone the latest version via git:

cd /var/www
mv snipe-it snipe-it-backup
git clone https://github.com/snipe/snipe-it

Now fix permissions, enter the snipe-it dir and install dependencies with composer:

chown -R www-data:www-data snipe-it
cd snipe-it
turnkey-composer install --no-dev --prefer-source

That will likely take a little while. When it's done, copy in the required old files:

cp -R ../snipe-it-backup/public/uploads/* public/uploads
cp -R ../snipe-it-backup/storage/private_uploads/* storage/private_uploads
cp -R ../snipe-it-backup/storage/app/backups/* storage/app/backups
cp -R ../snipe-it-backup/.env ./
cp -R ../snipe-it-backup/storage/oauth-private.key storage/oauth-private.key
cp -R ../snipe-it-backup/storage/oauth-public.key storage/oauth-public.key

Then finally, you can run the update itself (migrate DB, clear cache, etc). Unfortunately this command is a little convoluted, but perhaps we'll write a helper script for that too in the future?:

runuser - www-data -s /bin/bash -c "cd /var/www/snipe-it && php upgrade.php"

Once you've done that, all future updates can be done via this same command. Although to make your life marginally easier, you could just make a helper script. We might do that for future releases... Here's what I would suggest:

cat > /usr/local/bin/turnkey-snipe-it-upgrade 


From now on, you can just run:



turnkey-snipe-it-upgrade
Forum: 
Support
Tags: 
snipe-it
v16.x
update
snipe-it update
upgrade
snipe-it upgrade
L. Arnold's picture

L. Arnold - Fri, 2022/01/07 - 20:28

What can be done to make information like this easy to find on different Apps would be great.

I have worked through a few upgrades (Joomla was one,  Magento another)..  but having a general path on any/all apps would be more than fantastic.  I know that is difficult but it really makes a difference in terms of users assessments of reliability and long term usability.

I hate to be a broken record. I know that I sometimes am.

Jeremy Davis's picture

Jeremy Davis - Sat, 2022/01/08 - 08:55

Yes I agree. Unfortunately it all takes time and I don't always have the time. Plus, this appliance was/is particularly easy. Most of my post was copy/paste direct from their docs (with a little adjustment for our custom helper scripts) and the Snipe-IT devs provides a pretty powerful upgrade script that does most of the heavy lifting.

It'd be great if you could document your upgrades when you next do one. AN/dor if you get stuck, please do ask and I'm more than happy to do what I can to help.

As for organising, I added some tags which hopefully might make it easier to find. But perhaps we should add pages to the wiki? My only reservation is that there are already some out of date pages (which already desperately need an update) in the wiki and I don't want to just make that problem worse. Writing and maintaining docs is a full time job in and of itself really... Having said that, perhaps we could add a page for snipe-it and just link to this thread?! (Then it would be clear how old it is and how relevant it might be?! WHat do you think?

Jeremy Davis's picture

Jeremy Davis - Mon, 2022/02/07 - 05:05

Assuming that you are running the TurnKey Linux Snipe-IT appliance, then you now need to set a domain. If you installed Snipe-IT via some other method (i.e. not a TurnKey appliance), then the solution below will almost certainly not help!

It is now required to set the "domain" (if you want to access via IP address, then you'll need to set the IP address as the domain). If you have an earlier version of our appliance, then you'll need to download the latest update of the Snipe-IT inithook.

Be sure to backup before downloading and running this inithook, just in case something goes wrong. Get the script and run like this:

script=usr/lib/inithooks/bin/snipe-it.py
url=https://raw.githubusercontent.com/turnkeylinux-apps/snipe-it/master/overlay/$script
wget -O /$script $url
chmod +x /$script
./$script
Jeremy Davis's picture

Jeremy Davis - Thu, 2022/03/03 - 07:42

Yes, these need to be run within an interactive terminal. SSH via a native client is the best option IMO, but Webshell (via https on port 12320) is another option. If you are running your TurnKey server as some sort of VM, then using the terminal directly is likely another option. Note that Webmin's terminal isn't a complete interactive terminal, so won't work for this (or any other operation that requires interaction).

Having said all that, IMO SSH is the best way to go. I'm a Linux user and just use the built-in OpenSSH client CLI tool within a local terminal. If you are using Mac OSX, then you should already have the OpenSSH client too. If you're on Windows, you'll need to install an SSH client. A few common/popular ones are:

  • OpenSSH - pure CLI; run within a CMD window,
  • PuTTY - GUI terminal, and
  • WinSCP - GUI terminal, remote SFTP file manager and text editor.

Once connected to your server, then you should be able to simply copy paste those instructions into the terminal (note that to paste in PuTTY, use right mouse click).

If you have any troubles and/or further questions, please let me know.

Jeremy Davis's picture

Jeremy Davis - Sat, 2022/03/05 - 08:29

Why are you using an IP address instead of the github domain? I think you are confused.

It's not possible for an IP address to get a valid SSL cert, that's why you're getting that error. And it looks like you ar trying to download the script from yourself?! You need to SSH into your server, run the code exactly as I posted it earlier in this thread. That will download a script from GitHub, then run it. The script will be interactive and one of the steps, it will ask for a domain.

Ideally you should use a domain for your server, but if you don't want to and want to just access your Snipe-IT server web UI via IP address (i.e. type in IP in web browser address bar), then instead of a domain, input the IP address (in the interactive script - when it asks for domain).

Hopefully that clears things up a bit...?!

Keith Boddy's picture

Keith Boddy - Wed, 2022/08/31 - 16:05
Hey, I ran into the same issue again with patching Snipe IT.  Browser redirects to 'localhost/login' again.  The provided script seems to not work either and errors: 
root@snipe .../inithooks/bin# ./snipe-it.py
Traceback (most recent call last):
File "./snipe-it.py", line 14, in
from libinithooks.dialog_wrapper import Dialog
ModuleNotFoundError: No module named 'libinithooks'
Any input would be great again! Thanks, Keith
Jeremy Davis's picture

Jeremy Davis - Thu, 2022/09/01 - 00:14

It looks like you've upgraded to a Debian Bullseye/11 base as well?!

The issue you are hitting is that we've refactored Inithooks in v17.x/Bullseye so they now provide a library (the first steps in allowing inithooks and confconsole to share some code). But it appears that you don't have the current v17.x Snipe-IT inithook. It's been updated, so you should be able to just download the current one from Github.

Re running the code snippet I posted earlier in this thread should do the job:

script=usr/lib/inithooks/bin/snipe-it.py
url=https://raw.githubusercontent.com/turnkeylinux-apps/snipe-it/master/overlay/$script
wget -O /$script $url
chmod +x /$script
./$script
Keith Boddy's picture

Keith Boddy - Thu, 2022/09/01 - 15:12

No... I didn't upgrade the entire OS, all I did was PHP7.4 which was a requirement for Snipe IT 6+, then I ran the update as per above.

root@snipe ~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
root@snipe ~#

root@snipe ~# php -v
PHP 7.4.30 (cli) (built: Jun 27 2022 08:11:59) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies

I can certainly try what you've suggested and let you know.

Keith

 

Jeremy Davis's picture

Jeremy Davis - Sat, 2022/09/03 - 04:07

My apologies, the issue should have hit me right between the eyes! The problem is that we've updated the build code in the Snipe-IT buildcode repo - to support the new (but not yet released) v17.x TurnKey Snipe-IT appliance. The code that I provided via my copy/paste instructions was literally the cause of the problem... Doh!

The fix is to download the code from that particular point in time. So mostly it's the same, just via a different URL. I.e. try this:

script=usr/lib/inithooks/bin/snipe-it.py
commit=b1214cbf4eb6e3134d24f5346da6052e887a138c
url=https://raw.githubusercontent.com/turnkeylinux-apps/snipe-it/$commit/overlay/$script
wget -O /$script $url
chmod +x /$script
./$script

Hopefully that should work now. Note the specific 'commit' ID - FYI that URL provides the "raw" (aka plain text) copy of snipe-it.py file at the correct point in time.

Apologies again about that. Hopefully this last piece of guidance gets you across the line! Please let me know how you go.

Keith Boddy's picture

Keith Boddy - Wed, 2022/09/14 - 15:11
Sorry for the delay. Thanks for the fixed script - I'm back up and running! Amazing support as always!  Again, would love to see updated image... ;) Keith
Anand's picture

Anand - Thu, 2022/05/19 - 17:29
Hi, I have used the above commands perfectly and finally got errors. It says the current version of Php 7.3 doesn't support, when i used the following one " 
turnkey-composer install --no-dev --prefer-source
"
Jeremy Davis's picture

Jeremy Davis - Fri, 2022/05/20 - 02:27

Please share the error message. Otherwise, I have no idea what might be going wrong.

Anand's picture

Anand - Sat, 2022/05/21 - 12:27 
root@snipe-it /var/www# mv snipe-it snipe-it-backup
root@snipe-it /var/www# git clone https://github.com/snipe/snipe-it
Cloning into 'snipe-it'...
remote: Enumerating objects: 127435, done.
remote: Counting objects: 100% (508/508), done.
remote: Compressing objects: 100% (246/246), done.
remote: Total 127435 (delta 307), reused 417 (delta 262), pack-reused 126927
Receiving objects: 100% (127435/127435), 139.53 MiB | 4.76 MiB/s, done.
Resolving deltas: 100% (82491/82491), done.
Checking out files: 100% (6349/6349), done.
root@snipe-it /var/www# cd snipe-it
root@snipe-it .../www/snipe-it# cd /var/www/
root@snipe-it /var/www# chown -R www-data:www-data snipe-it
root@snipe-it /var/www# cd snipe-it
root@snipe-it .../www/snipe-it# turnkey-composer install --no-dev --prefer-source
	Installing dependencies from lock file
	Verifying lock file contents can be installed on current platform.
	Your lock file does not contain a compatible set of packages. Please run composer 
	  Problem 1
	    - Root composer.json requires php >=7.4 <8.3 but your php version (7.3.27) does not satisfy that requirement.
	  Problem 2
	    - lcobucci/clock is locked to version 2.0.0 and an update of this package was not requested.
	    - lcobucci/clock 2.0.0 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.
	  Problem 3
	    - lcobucci/jwt is locked to version 4.1.5 and an update of this package was not requested.
	    - lcobucci/jwt 4.1.5 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.
	  Problem 4
	    - league/commonmark is locked to version 2.3.1 and an update of this package was not requested.
	    - league/commonmark 2.3.1 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.

	  Problem 5
	    - league/config is locked to version v1.1.1 and an update of this package was not requested.
	    - league/config v1.1.1 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.
	  Problem 6
	    - league/csv is locked to version 9.8.0 and an update of this package was not requested.
	    - league/csv 9.8.0 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.
	  Problem 7
	    - psr/container is locked to version 1.1.2 and an update of this package was not requested.

	    - psr/container 1.1.2 requires php >=7.4.0 -> your php version (7.3.27) does not satisfy that requirement.
	  Problem 8
	    - league/commonmark 2.3.1 requires php ^7.4 || ^8.0 -> your php version (7.3.27) does not satisfy that requirement.
	    - laravel/framework v8.83.12 requires league/commonmark ^1.3|^2.0.2 -> satisfiable by league/commonmark[2.3.1].
	    - laravel/framework is locked to version v8.83.12 and an update of this package was not requested.
Jeremy Davis's picture

Jeremy Davis - Thu, 2022/08/25 - 06:45

I've just discovered this post (from ages ago) was stuck in the spam filter. If you log in when you post, then you will likely avoid many of the spam traps (and I can manually grant you user permissions to avoid the spam traps if you still have issues posting).

Anyway, I suspect that you may have already worked out the cause of the issue and/or discovered a workaround. Regardless, my reading of your post (after I updated the formatting so it was readable - another reason why posting as a logged in user is preferable) suggests that the primary issue is that the newer version requires a newer version of PHP than what is installed by default.

You have 2 choices there.

The first is to install a newer version of PHP on your current system. I've actually just done an up to date post on how to do that this morning.

The other option is to do a Debian style "in place" OS upgrade. The current appliance you are using (v16.x) is based on Debian Buster/10. The newer version of Debian (Bullseye/11) includes PHP 7.4 (the minimum requirement noted in your posted output). Technically an "in place" upgrade isn't "supported", but that's only because we don't have the spare cycles to exhaustively test that. We don't explicitly do anything that should cause issues with the process though, so It should still work. You just won't get all of the tweaks that we apply to the newer release. The best and most complete documentation on doing a Buster -> Bullseye upgrade can be found in the specific section of the Debian Bullseye/11 Release Notes. It's probably a bit over the top really and a number of steps can be skipped. I suggest that you also do an internet search for something like "upgrade debian buster to bullseye" for some less convoluted and explict instructions on upgrading to give you some more ideas about that. Worst case scenario, following the Debian docs should get you over the line.

Which ever way you go, once you are using a newer version of PHP (either 7.4 or 8.0) then hopefully, the upgrade will "just work".

Either way, if this is still relevant, please post back to let us know how you get on.

Add new comment