Spigot Update - 20140909a
The topic of discussion is this for MineOS Turnkey. This is a strange deployment method and a work around. Is there a script we could create to help users keep their systems up to date during this transition?
Excerpt from above link attached below.
Updating your Spigot jar is now a slightly different and marginally more complex process, however it should still be relatively painless, especially for those who have run modded servers before. The steps are as follows:
- Obtain a copy of Spigot build #1649. Unfortunately we cannot help you with obtaining such a build, but please remember to obtain all such copies legally.
- Ensure that the build which you have obtained matches the md5 checksum: f2edc09c45b1f80237602dc0d1b05969
- Download a copy of the patch for the update which you wish to apply and the latest version of SpigotPatcher.
- Run the following command: java -jar SpigotPatcher.jar /path/to/spigot-1649.jar /path/to/patch.bps /path/to/output.jar
- The tool will run and create a new Spigot jar, as well as print out a variety of information.
- You should check that the printed md5 matches the one which is listed on the update post, and then proceed to run your newly updated Spigot.
- Ensure you keep a copy of Spigot #1649 as you will require it next time you update.
Here is the changelog and download to the first update of Spigot, Spigot-20140909a:
Download:
SpigotPatcher 1.0: http://www.spigotmc.org/spigot-updates/SpigotPatcher-1.0.jar (33a73112e1fa90706b96cd02c87b447a)
Spigot-20140909a.bps: http://www.spigotmc.org/spigot-updates/spigot-20140909a.bps
(98bc6f3b4a5927a026739cfe8747f998)
Final Checksum: a08aaa6d7f13b648ddf40801a3343ac8
Though I am unable to download a copy of Spigot because of the DMCA takedown, I don’t see any real reason you’d need to script this out rather than just go through the steps as prescribed with a custom profile.
- Create a ‘standard_jar’ profile ‘spigot1649’, setting ‘run_as’ to something like ‘patched_spigot.jar’.
- SSH in; cd /var/games/minecraft/profiles/spigot1649 (or whatever you called the profile).
- wget -O original_spigot.jar http://example.com/url_to_spigot.jar
- wget http://www.spigotmc.org/spigot-updates/SpigotPatcher-1.0.jar
- wget http://www.spigotmc.org/spigot-updates/spigot-20140909a.bps
- java -jar SpigotPatcher.jar original_spigot.jar spigot-20140909a.bps patched_spigot.jar
- set your server to use this profile (verify the checkmark on the profiles page)
The reason you might want to avoid writing a script is because a) you won’t have to do this again–one unmanaged profile will service any number of servers–and b) by the time you want to do this with an new > 1649 build, you’ll have to do it with a new spigot download, a new binary patch (bps) and possibly a new spigotpatcher. In short, the script might make it more work than its worth.
These instructions were helpful.
After Step 7 when I set the Server’s profile and attempt to start the Server I get a red message in the GUI saying it can’t find patched_spigot.jar.
I can manually move the patched_spigot.jar file to the Server’s root dir and then the Server starts properly. Are we missing a step above, should I have just known to put the file there within the Server directory, since we are doing a manual profile this is just a task I should have known to do, or is there a path variable that I should have pointing to the .jar file upon Manual Profile Creation?
Maybe something like this within the field:
Jarfile to run
/var/games/minecraft/profiles/spigot1649/patched_spigot.jar
Either way, thank you for the assist. =)
William…
I think that means you set the server as ‘unmanaged’, which is definitely an OK way to have done it. I didn’t specify in the instructions, but I suppose I intended for you to create a normal server jar profile (with an empty URL field). The only differences would have been:
- unmanaged profiles are expected to have X rather than checkmarks
- standard jar profiles do the copying from the profile dir to the server jar upon start.
There’s no reason to redo this, however. Once it’s working, just keep with that working profile from here out.
Yes, I created an Unmanaged Profile. I guess I misinterpreted the context of the above sentence.
Either way, thank you for the helpful responses.
William…
A-ha ha. No, you definitely read the instructions better than I did. There was no misinterpretation; I mis-wrote “unmanaged profile” when I should’ve specified “standard jar.”
At any rate, both routes are entirely valid–If I had to pick a pony, I’d say all future users can make a ‘standard jar’ profile, since it will circumvent the need to copy the jars manually. Copying jars is not a lot of work, but its an additional step (SSH/SFTP) that pretty much is just … one unnecessary step.