I am using NZBdrone on synology using the great package from @maxrogers.
Now we always have a question about the update process.
Recently i created a script (sh one) to update NZBdrone correctly.
And it got me wondering:
Could NZbdrone check for that script existence on linux based system? Clicking on the “install” button would be:
if the local script exists then run the script with the parameters : branch and version
if the script does not exist, do what you do today and show the tutorial page.
The script location could be an NZBdrone settings. That way we could create a synology package including that script and with the correct default location setting for it.
And it would virtually work for any linux based system, or even windows …
What does the script need to do that’s customized for syno? Drone already does automatic updating on Windows and I’ve started work to have the same done on Linux/OS X.
Well i am just not sure the service is started/stopped the same way.
also i wonder about permission and stuff.
Really i think a sh script to update on linux would be the best.
That way we could customise it on synology.
It would only need 2 parameters right? the branch and version?
may be i can help you testing the update process on synology
Not against it, just wondering what it needed, with the service, you’re right a script would be better.I had never considered this, but it would make our lives MUCH easier.
I think drone could handle the downloading (optional, but preferred) to a temp location, then the path could be passed to the script, this is how the update process works on Windows, if the version and branch are important then they could be passed as well.
All we would need on the NzbDrone side of things is:
[1] The above or similar added to settings
[2] A means to check for “update compatible” systems (only syno so far.) If a compatible system is detected, the above is made available.
Note: Adding the default script location for each system automatically would solve a lot of potential issues.
When someone wants to add update support for a system, they would simply send you the logic to detect their system & the default location of their script on that system. You could then add their system to the list of compatible systems (allowing the settings above to show.)
Anyways, just thinking through it a bit. If NzbDrone downloaded the requested updates when available and then called the script, there would be no need to pass the version info or branch info (only the directory or package location of the new build would be needed.)
Logic for detecting Synology system:
uname -a | grep -q 'synology' &> /dev/null if [ $? == 0]; then echo "matched, this is a synology system" fi
Best location for Synology update script (in my opinion:)
Seems all good. About the system check. Why not make it a script? That way markus don’t have to add any new code for a new system.
Finally about the “unzip” process, i think it s better to do it in the script. Why? Just because you never the specific details of a platform (like permissions, remote install(pi?), you name them). I guess my point is that the script can handle it all, just like the post process scripts do in NZBGet
farfromrefuge, markus101 and I have been chatting about it on irc. He has some ideas regarding system detection etc. He is going to try them tomorrow.
He shared this progress:
The script would still unzip the package, place the package, modify permissions, and pretty much anything else that needs to be done.
NzbDrone would schedule/run the update checks, select and download the proper package as needed/available, and execute the update script.
IMO NzbDrone is better suited to do the above items since it is already aware of the currently installed version & the latest version(s) available (for both branches.) Plus, this simplifies the function of the update scripts for all systems.
I just wanted to drop in and give absolutely 0 helpful input on this. I’m still a very junior dev / systems admin working full time and college part time with not much time for social life or other interests tbh… but seriously the work all of you guys are putting into this is really something fantastic to see.
I’d love to help but for now I will chime in on reddit and elsewhere with my limited knowledge to help, and provide a donation so you can at least get a few pints of beer in.
I created a NzbDrone package for the ASUSTOR NAS and would like to say that calling an upgrade script is a good solution from my point of view. I do have to set the permissions too.
In a perfect (ASUSTOR) world the upgrade script could be found in <NzbDrone.exe location>/…/CONTROL/upgrade.sh. That would translate to /usr/local/AppCentral/nzbdrone/CONTROL. Branch wouldn’t be necessary of course since the user had made her choice before by adjust the settings (in the beautifull GUI btw).
For the customizing point of view it would help if the location of the upgrade script could be set by an env. or Mono variable. For detecting the ASUSTUR an uname will be of no help. For all the NAS out there I think it doesn’t make sense to let NzbDrone do the detecting. But that’s only my 3 cents (used to be 2 cents but … inflation ).
@farfromrefuge, I have a working spk that is running a test “updater” branch that @markus101 made for me to test with. Everything seems to work great for me. If you want to test it out I would appreciate it. I will send you a link to the spk. Thanks for spurring the script idea forward! And, of course, a HUGE thanks to @markus101 for working on this for all of us!!!
@MrK, @markus101 ended up using parameters in config.xml rather than detection. It is a much better idea. Thanks guys. You might find portions of my scripts useful in adding update support to your ASUSTOR package (with modifications.) I will post them here for you in a bit.
Edit 2: FYI, It turns out that the built-in updater that @markus101 is working on works for Synology. This means there will be no need for a script (for us at least.)
I want to warn you about the script right now. It actually wiped out my installation.
First there is a permission issue with the script
14-5-16 16:08:03.6|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:03.9|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:04.4|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:04.7|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:05.0|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:05.1|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:05.3|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 68: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:05.6|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 70: can't create /nzbdrone/var/upgrade.log: nonexistent directory
14-5-16 16:08:05.8|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 70: can't create /nzbdrone/var/upgrade.log: nonexistent directory
14-5-16 16:08:06.0|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 70: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:06.2|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 70: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
14-5-16 16:08:06.4|Error|upgrade.sh|/usr/local/nzbdrone/bin/upgrade.sh: line 70: can't create /usr/local/nzbdrone/var/upgrade.log: Permission denied
Now this is not what wiped out my install. What did is the fact that you move ./var to /tmp/var. Such a bad idea!
The script failed in between the backup and the restore of var. And on top of that the script was run twice because the gui of NZBdrone allows to click twice and run the update process twice.
Which leads the script to overwrite my var backup in tmp with an empty var.
Why do you backup var :s and why that way …
Plus the script doesn’t report success which means that nzbdrone can’t bring back the backed up var when failed.
I am sorry to say that but that script is dangerous!
Sorry about that @farfromrefuge! As I mentioned in my PM and above, we are no longer using the script. You are the only one I have had test it.
However, this is great info for anyone that wants to use a script! Ensure that you create solution that protects from a double run due to a double click of the install button! In that scenario, this script in it’s current state WILL delete the user data backup if the install button is clicked again (twice) during the upgrade.
@farfromrefuge, if you still want to use a script for some reason you could add a simple upgrade check that disallows the upgrade if there is currently a user data backup stored.
The “permission denied” errors above are a result of the user data folder getting wiped out (not permissions.) Sorry again man, I recommend using the built-in upgrade now added to develop branch.
@markus101, perhaps the install button should have a “patience” timeout when clicked that visually disables the install button after it is clicked for x seconds?
@maxrogers don’t worry i don’t hold you responsible or anything. Truly i don’t care. The only thing is that i have to re configure all my series
So the script will not be an option anymore in the build process?
Cause what i like is that i can plug in mine
That s also what i loved about the script thing, you can customise it to your needs
Well for now i think i ll stick to my script and maybe a daily backup
@markus101 A stupid question: how can I test the update process? I download latest develop but now there’s nothing to update. And if I install the latest master the ‘Install’ button redirects to the website. And I can’t download a previous deveoper archive since there is none.
