Multi-distro Linux python auto update script - EmbyUpdate

[doonze 30]

So, I did this thing, now I'm sharing this thing.

 

https://github.com/doonze/EmbyUpdate

 

EmbyUpdate is a multi-distro python 2/3 (2 is no longer supported as of version 4.0 rolled 9/21/2021, but 3.6 runs on python 2 fine) script I wrote to keep my Emby up-to-date with the standalone github version. That's the version you get if you go to download and install from the downloads section here on the Emby site. This script can be used manually when needed, or as a cron job if you want auto-update functionality. 

 

• Before doing anything, make sure you have the backup/restore plugin installed and have a good backup of your current server!
• If switching from a repo version, don't forget to "apt remove emby-server" (or whatever your distro uses) first! You don't want it updating back to a repo version later!!!! **MAKE SURE YOU HAVE A BACKUP** so you don't have to start from scratch!

Currently at: Version 4.0 Beta, Version 3.6 Stable

 

IMPORTANT: This is ONLY for admins that install the "standalone" version from the github page or here through the downloads link!!!!!! If you have a distro version or the MONO version installed, this is not the script you're looking for! This COULD play havoc with your install if you are not using the STANDALONE version. If you're not sure, move along. You've been warned. You can use this script to switch, just be aware last I messed with this there were pathing issues with the data directory when switching. See https://emby.media/community/index.php?/topic/53091-debian-repo-update-beware/  for more info on that.

This is untested except with python 2.7 and 3.*. I think it will work on any version 2.6+. Also untested on any Distro besides Debian 9+ (Untested by me that is, several users have reported it works on the other distro's as well).

The script checks the API of Emby's GitHub and finds the latest version listed. It then checks to see what the last version the script installed for you was. If they don't match, the script downloads the latest version and issues the install command. It can also stop and start the server for you if needed. At this time, as far as I know, all the installers do it for you anyway. Server stop/start is a simple true/false boolean that's easily modified if needed. On Deb systems it then deletes the downloaded and installed deb to keep things nice and neat.

The most recent version also auto updates itself from my github page in the same way it updates Emby. If I make a new release, the script will update itself the next time it runs.

 

Supported Distros:

 

* If it's offered, both X64 and ARM are supported for all distros

 

Debian (Ubuntu, Mint, etc) 

Arch Linux

OpenSuse

Fedora

CentOS

 

Thoughts:

 

Yeah, I know, like it's SOOO hard to go to the download page and download the new version when your server tells you it's time. But I just wanted something to keep it up to date for me. My server is headless so I don't login unless needed. This way I can stay up to date without taking action. 

• The first time it runs it will update you to the latest version. I could have done some logic test and even had it find out what version you have installed currently. But it won't hurt anything updating, and on Debian type systems it will download the deb, then check to verify it's an upgrade. If it's not an upgrade it will output or log that fact and do nothing anyway. If the other distros installers can do that or not I don't know. Once it's ran for the first time, it will keep track internally and only update if needed.
• I did add logic to the script so if it encounters any error getting the newest version, has any file permissions issues, or encounters other errors, the script exits at the point of error. This should prevent any unwanted behavior.
• Will only work if you have admin rights. But you'd need those anyway to manually install, so moot point I guess.
• @@Luke and @@ebr or any other maintainers, please don't monkey with your GitHub download links format, petty please!! LOL I honestly had a way to filter through the GitHub API json and pull the correct links in a bash script, but I was never smart enough to figure it out in python. So it's all hard coded. Just sayin...... 
• If for some reason you downgrade, you'll need to turn off the script till you get back in sync with the current version. I thought about keeping track of all installed past versions, but didn't see enough use to bother. Could add if it's needed.
• And of course, use at your own risk. Nor responsible for data loss, corrupted installs, fire, or alien abduction resulting from the use of this script!
• The API has links to many installs not listed elsewhere. Like for Western digital NAS. I have no way of testing them, but if there was interest I could easily add them if someone wants to explain the install process. I can add any device that can run Python, just need the details.

Edited September 21, 2021 by doonze
updates

[doonze 30]

EmbyUpdate 1.1 is out! 

 

Main new feature, per popular request, is autoupdating to the latest BETA versions! I'll explain below, but if I can get the attention of @@Luke for a moment I have some questions!

 

1. For some reason the API list many newer versions that do not appear on the release page on Github. I've validated what I'm pulling from the API is the version you provide on the download page here. So all's good. But I'm confused why they show up in the API, but not on the main Github page? In fact the most recent stable and all Beta's since 3.4.1.18 show up on the API but NOT on the release page. Is this because you doing all the downloads from your Download page now, and trying to force it's use? I think all those are the old mono versions. No biggie, as the API is correct and up to date... but what the heck? How is it in the API but not on the page? Have have you made them private since then? If so, just FYI, they are in the API. I'm just asking so I'm aware of what your doing so I can plan for my app.
2. Do you ever release a stable under the same version # as a Beta? Like when it moves from Beta to Stable? I don't think you do, not with they way your using tags on Github. Since you use the version number as the tag, you can't have two releases with the same version #. If I'm understanding Github correctly. I've added logic to overcome this if it ever happened, but once again the better I understand how you do things the better I can make my app.
3. Please please, with sugar on top and a big fat cherry, don't change your file name/download path naming convention! Of course I'm mostly kidding, you have to do what you have to do. But to save about 100 lines of code, and a bunch of complicated string comparisons, I hard coded the file names and paths to make things fast and simple. All I change is the version #'s in the path and file name. This is what your also doing, keep it up, don't fix it if it ain't broke!! LOL

OK, enough of that. To download beta's and keep them autoupdated all you have to do is change this to True: 

installbeta = False

 Its right at the top directly under where you choose your distro. Next time you run EmbyUpdate it will then switch you to the beta version, and keep you updated with the latest releases. In theory you can switch back an forth as much as you like, but I don't suggest it. The app will do it gladly, but I can't promise nothing unforeseen will happen on the Emby side.

 

The Github API list releases from most recent to oldest. It doesn't care if it's beta (prerelease in Github language) or stable. The most recent is in index 0. When a new release of any kind comes out it moves the old one to index 1 and puts the new one in index 0. So if you use the default setting of stable, it searches through every release until it finds the first stable version and then uses that. That will always be the most recent one, as it searches in order of newest to oldest. Of course it you choose beta, it does the same thing, stopping at the first (newest) beta release it finds. 

 

Really it's pretty simple, and effective. However, if Luke and friends forget to check pre-release on a beta version release, or vice versa, things are of course not going to go as planned. If that happened it would correct itself whenever they correct it on Github, but not a lot I can do about that. 

 

I haven't tested beta out, as I run a pretty heavily used server I don't want to monkey with it too much. So I need.... erm.... beta testers! There has only been one stable version roll since I wrote this app, but it updated automatically without issues.  The changes for beta installs were pretty easy once I figured out the API, so I don't expect any issues unless I fat fingered something. I guess I could spool up a virtual machine, or use one of my old servers for testing. But meh.... the changes were so straight forward if it works for stable it should work for beta just fine. Had to update like 6 lines of code. 

 

Any questions, just ask!

[doonze 30]

Any mod who sees this, can you change the title to:

 

EmbyUpdate - Multi-distro Linux python auto update script

 

I just realized it way it reads now it might seem I wrote a script to auto update python! LOL Just sayin....

[doonze 30]

EmbyUpdate 2.0 Beta released

 

I just want to say, whomever over at python that decided spaces and tabs are not the same thing needs dragged out back and beaten with a power cable. Just sayin'.

 

Here's my highlight changelog:

 

• Added self update ability
• Added input dialog to create config file in configupdate.py
• Moved all user updatable options from main program into config.ini file
• Added logic to all code to handle both Python 2 and Python 3
• Added -c/--config, -v/--version, and -h/--help comand line options
• Created changelog file
• Added version info into code

 

That's really glossing the changes over. Lines of code increased about 4x, and complexity increased about 10x! I had already thought about moving the options into a config file, but I had a user request the ability of the app to selfupdate, and since I needed an external config file to do that I just took the plunge and rewrote the entire thing. My wrist hurt!

 

So the big things are:

 

Command line arguments

 

-c/--config = First run config file builder. Any time on demand config file updater.

-v/--version = Display version number. Cause why not?

-h/--help = Help. Yeah, so it's build into the class. Still cool to have.

 

Interactive input driven config file builder/updater

 

There is now an interactive config builder that creates/updates the config file based on user responses. You choose your distro from the list, choose your options like Stable or Beta, and choose if you want it to selfupdate the script.

 

Self updating script

 

The script is now 100% self updating if you choose to allow it to do so. It will check for newer versions any time the script is run. If it finds a newer version it will download the zip and overwrite the current script as needed. The config file is not touched so it just keeps you updated with the newest features and bug fixed. Plus it keeps you future proofed somewhat if @@Luke goes crazy and changes things on me. I don't plan on having beta/stable options in the selfupdater as I don't plan on always having beta's. I did have to delete my first release of this beta as I realized anyone who installed it would have their Beta version reverted back to the last stable version. I have some ideas to correct this going forward, and the next release should have some way to deal with it. But for now, I'm only going to release non-prerelease versions on github.

 

Full Python 2 and 3 support

 

So the config file creator as well as input code is different in 2 and 3. To the level of being totally uncompatible. I suggest using 3 for this script, but only because it always tries 3 commands first. If those throw an exception it then tries 2 code. Believe it or not, this is the python preferred way of handling these issues. I have no idea what they were thinking when they didn't make 3 backwards compatible, but no one asked me. I think my code logic is pretty bullet proof, and in just about every case it should be able to handle being ran with either flavor of Python. Even if the version is switched when running subprocesses (yes, that can happen). 

 

There are just too many distro's still running 2 for me to write an app just for 3. And to be honest it was kind of fun writing it to handle both in the same script. A pain, but fun.

 

 Other

 

Lots of little tweeks to logic and output format. Lots and lots of comments as well. 

 

As always, I need beta testers. I have no real desire to spool up a bunch of VM to test this in other distro's than Debian. So if your using another supported Linux flavor please give it a try and tell me how it works. 

[ssg99si 4]

Hey this is working great! Thanks for the updates!

[halfrican 0]

@@doonze would it be possible to add a option to rotate the logs periodically perhaps once a week? Or would it be best to handle this externally in it's own cron job?

[doonze 30]

@@doonze would it be possible to add a option to rotate the logs periodically perhaps once a week? Or would it be best to handle this externally in it's own cron job?

 

Yes, it's possible. I had thought about it then abandoned the idea. I run this headless, so in my use case it might be many months before I get around to checking the logs. So I like to keep my logs till I manually decide to rotate or delete them. I also worried about permission errors if people like to keep their logs somewhere custom. Lastly, the two lines this outputs every time it runs (normally) would take 100 years to reach a size where it would matter on modern systems. So in the end I decided to just let the user handle it themselves however they saw fit. Through CRON, manually, or even with each distro's built in log rotation process.   

 

I did test it some a few weeks ago. If I grab the output and pipe it myself to a file, CRON loses the ability to see the output itself as the script intercepts it. Without looking into it deeper, it seemed I'd have to either force using an internal function on the user, or manually write a function for each action to output to both the console and a file. The more complex I make the script, the more chances of hidden issues cropping up in someones setup. 

 

That all being said, if there is interest in an internal log writer, I'm more than happy to write one. Let me know here or on github if you'd like to see it. 

 

Thanks! 

[doonze 30]

Just as an update. I have a new version out with more error checking (when I moved to using subprocess to run commands I figured it was like calling the command through the OS. I figured exceptions would be passed back to the calling script. However python doesn't do that. So I added return codes in all critical subprocesses so the script can know there was a problem and exit correctly before updating the config file. Otherwise the script thought the update was successful when it wasn't. 

 

Also, I can confirm the script handled the update to 4 with no issues on my system. This is the first stable release update since I wrote the script. I had of course faked it out to test updating while writing it, but this was the first "live" test. Worked perfectly.  

[Nostradamus1973 18]

Running this on Kubuntu 21.04, and all I can say about this script is:

• This thing had me at Hello! What an elegant yet simple solution for someone like me who has touch and go moments with OCD, I find myself checking once or twice a day for an update..... Yes, I'm that guy.

I didn't need to jump through major hoops to get this installed, the installation notes were concise and easy to understand, my only sticking point was I had to use "sudo python3 embyupdate.py --config" which any intermediate Linux user should be able to figure out quickly with ease.

Of course I would prefer to do this through a repository, but, that's not available to us at this time, until then, this is an excellent substitute.

Thanks for all your hard work doonze

[doonze 30]

So any of you running my script, I broke it accidently, here's the blurb:

There was a critical bug in version 3.3 that broke the auto self updater, you will need to download and install version 3.6 or higher over your existing install (or do a fresh install) to fix!!! Sorry!!

Long story short, an untested and unintended change in a pull request got merged into the master branch, and it broke every single auto-updating instance of EmbyUpdate that ran during the time frame until I became aware of the bug and rolled a fix. This was my fault as I thought I could install (and had) just some parts of the pull request, but instead parts I have not tested yet got into the master branch and I rolled out a new version without being aware. 

This was my first time merging in a pull request, so it's been a learning experience. Sorry for all the inconvenience. 

 

I have no way of knowing who all has it installed, or any way of letting them know there was a problem. So many people are unlikely to realize they are broken and not updating! So I'm trying to let people know here. Several have already reported it on Github, so thanks guys!!! And my fix even rolled a copy/paste error into 3.5 that one of you amazing fellows did a pull request on to fix and that's been fixed in 3.6. In my rush to get a break fix out I missed a simple extra ")" in the configupdate.py file. 

[doonze 30]

On 6/12/2021 at 5:53 AM, Nostradamus1973 said:

Running this on Kubuntu 21.04, and all I can say about this script is:

• This thing had me at Hello! What an elegant yet simple solution for someone like me who has touch and go moments with OCD, I find myself checking once or twice a day for an update..... Yes, I'm that guy.

I didn't need to jump through major hoops to get this installed, the installation notes were concise and easy to understand, my only sticking point was I had to use "sudo python3 embyupdate.py --config" which any intermediate Linux user should be able to figure out quickly with ease.

Of course I would prefer to do this through a repository, but, that's not available to us at this time, until then, this is an excellent substitute.

Thanks for all your hard work doonze

Thanks, I appreciate it! This script has ran fine for 3 years till I broke it this week. So unfortunately you'll have to install it one more time to get the fix as I broke the self update feature. Sorry! 

Edited September 17, 2021 by doonze

[doonze 30]

EmbyUpdate version 4.0 Beta is out!

Do to the recent kerfuffle that hosed everyone using the script, I've finally got around to making a Beta branch that all new changes will got into first, and after testing will make it into stable. I also rewrote the selfupdate and configupdate portions of the script more or less from the ground up.  

Mainly this is now a true OOP project, and no longer just a overgrown bash script. It grew up and became an actual app! I haven't documented the Beta changes yet. But here's the highlights:

• There will no longer be support for Python 2 going forward, I will write logic later that will lock the app to the last python 2 supported version, 3.6 Stable, for anyone still running 2, but as of 4.0 Python 2 will no longer work. So if your running 2, don't bother updating past 3.6. I'll have the new logic in place before releasing a stable version.
• The selfupdate and config portions of the app are now Object Oriented, and mostly conform to PEP8 conventions. 
• There is now an option in the config creator to update the app itself to Beta versions. 
• If the app discovers there is no config file (like on new installs) it launches the config creator interface instead of just a message to run it manually.
• It will now unzip the app release zips following correct directory pathing. Before it dumped all files into the main app directory. Currently this only impacts the example files in the systemd directory, but this opens up possibilities later. I can now update to directories.
• File downloads for Debian/selfupdate are now handled by Python through requests instead of calling wget through linux. Also file removal is handled by Python now too instead of calling linux commands.
• Most sub processes have been replaced by the new OOP design. 
• Due to changes in the config file format, when you install version 4.0 the next run will read the old pre 4.0 config file, delete it, then create a new file in the new format. It will also delete the old configupdate.py file that's no longer used in 4.0+.

The honest truth, aside from some cleanup of some output, some different error handling, and adding a new option to the config creator, nothing is changing for the user. The app is just smarter and more complex, but still works the same as it always did in the end. It keeps your Emby up to day with the latest releases. But I do need some beta testers if anyone is feeling brave an has some time. I want to make sure it work right.

Since the current version does not have config options for Beta versions of the app, but I DID have the code written into the app to do Beta if needed down the road, you have to go into the selfupdate.py file and change 

    

installbeta = False

to
 

installbeta = True

save it, and run the app. It will update to version 4.0, and the next time it runs after that it will be running on 4.0. And it SHOULD correctly rewrite the config file. This is the part I mainly need tested, as it worked on my system eventually, but I want to confirm it works "in the wild" before releasing it to Stable. So I don't break everyone again. So if you do update please let me know here or on GitHub.

THANKS!