I realize there may be issues with things possibly getting broken.. but I think it's a security issue to not be running sudo apt-get update && sudo apt-get upgrade -y. It might be nice to have a security tab that discusses what fixes are available and the option to apply them. I don't think it's a good idea to wait for the next release of an Octopi image.
I really don't like the idea of putting it in cron as that could go off in the middle of a print and be really bad.
I see a bunch of threads discussing how to run the commands to do it and some discuss if that is a good idea as it could possibly break things.. but I don't see any that discuss the security implications of not doing it. Perhaps we could overcome the issue of it possibly breaking things with a way to back it out if it did. A rollback like idea?
I guess it could be made into a plugin, but it seems to me to be more of a core program functionality.
I admit I am security paranoid, but that is not necessarily a bad thing
Personally, I don't love any auto-update features of the OS since I'm a developer. I don't want any surprise changes to what I'm working on.
I don't really think of this as an OctoPrint feature; perhaps more of an OctoPi-provided script at best:
touch ~/scripts/raspbian-update
chmod a+x ~/scripts/raspbian-update
nano ~/scripts/raspbian-update
#---
#!/bin/bash
if [ "$(id -u)" != "0" ]
then
echo "Please run this with sudo since updating requires that." 2>&1
exit 1
fi
apt-get update
apt-get -y upgrade
#---
sudo ~/scripts/raspbian-update
As for the possibility of breaking things, yes, that's always a possibility that something new (Raspbian drivers) breaks something old (code). I honestly don't run OS upgrades that often. I do it mostly when I'm radically adding something new to my printer (like Python 3).
Personally, I don't love any auto-update features of the OS since I'm a developer. I don't want any surprise changes to what I'm working on.
I don't really think of this as an OctoPrint feature; perhaps more of an OctoPi-provided script at best:
touch ~/scripts/raspbian-update
chmod a+x ~/scripts/raspbian-update
nano ~/scripts/raspbian-update
#---
#!/bin/bash
if [ "$(id -u)" != "0" ]
then
echo "Please run this with sudo since updating requires that." 2>&1
exit 1
fi
apt-get update
apt-get -y upgrade
#---
sudo ~/scripts/raspbian-update
As for the possibility of breaking things, yes, that's always a possibility that something new (Raspbian drivers) breaks something old (code). I honestly don't run OS upgrades that often. I do it mostly when I'm radically adding something new to my printer (like Python 3).
It would need the ability to tell if a print was going as you wouldn't want it to run in that situation. I agree that it possibly would make development/debugging of issues harder but the idea of never getting updates until a new image is pushed out just gives me the chills.. I admit I come from a sysadmin background for many years so to me security is very critical and not really optional.
You can configure your own update checks and routines in the bundled software update plugin, either from a plugin or via config.yaml. Having something check if there are new Debian packages and then notifying you about that could be done, as could triggering that from OctoPrint's UI and seeing the output.
But something like that definitely doesn't belong into OctoPrint's core (OctoPrint ain't OctoPi), I'm already crossing a line there with the pi support plugin, and I only did that because I just had to find a way to warn people about their crappy PSUs and the problems they cause due to undervoltage.
"unattended-upgrades" seems like a good fit as it would send an email to you as to what was upgraded. What is the "approved" way to know if a printer is actively printing? I still feel that we don't want to do this while a print is happening.
whatever files that are open, stay open and readable as long as the process is running, even if the file (as in library) is removed in case of an upgrade. Linux is really neat on this. With this in mind, it should be pretty damn hard for an upgrade to break even a running print unless you have configured unattended-upgrades to automatically reboot for you, which wouldn't be wise.
An unattended upgrade could steal some resources that are needed to push GCODE as fast as possible to the printer.
Should be possible to set APT::Periodic::Unattended-Upgrade "1"; in /etc/apt/apt.conf.d/02periodic on print start, and reset to the original value on finish/cancellation from a (setuid) shell script called either through an event handler or a full blown plugin.
An unattended upgrade could steal some resources that are needed to push GCODE as fast as possible to the printer.
Just make sure to run renice -n -19 and ionice -c 1 -n 0 -p where is your octoprint PID. Also, use nice/ionice in the systemd script when starting the service. With these, it should be no way a normally working system should slow down the process because of a simple upgrade.
It just feels like a bad idea to run OS updates while OctoPrint (or mjpg_streamer or whatever else) is running. To me, this feels like hiring a company to remove/replace your carpet during a wedding; somebody's bound to be inconvenienced.
Just to be clear. I agree that upgrades/updates should not happen while a print is actively being printed. That is why I have been asking how one can tell that a print is active from code/shell script. The upgrade/update should ONLY be allowed to run on an idle system that is NOT actively printing. It would be nice if after it ran there was some indication in the GUI if a reboot was necessary.
So in pseudo code...
Check if a print is actively printing..
if so wait until it is done or exit.
else
check if there are update/upgrade that should be installed..
if so set a flag that will not let prints start
run the update/upgrade
check if a reboot is needed if so send a notification to gui
clear flag preventing prints from starting
I’m just a user and I don’t have the slightest desire to delve into packages if something stops working due to updates. I already have a bunch of negative experiences with PIO autoupdates when building marlin 2.0. I don’t want to get the same experience here
.. but to be fair, I probbly left original passwords so it's kinda my fault