So how does it work and what to expect.
The LUM Plugin can manage Redhat style (YUM), Debian Style(Apt-GET) and SUSE style(Zypher) package managers.
Each package manager handles things a bit differently so you might see different outcomes based on type and agent of package manager.
The plugin interfaces with the agents via the LUM maintenance automate script. This script has a scan and a update function for each of the package managers. So when you push buttons in the plugin you are scheduling the script to run with a given function. (Scan, update, update all and reboot)
During a scan of Ubuntu
When scanning via AptGet we have the agent pull down 2 different scripts One is a python script and the other is a Perl script.
The first script (Python)
/root/apt-get/APT-GET-Check.py returns 2 numbers separated by a semicolon of updates available and security updates available. In the example it is returning [8;0]
It will typically match what you see when you SSH into the agent and get a standard terminal.
- Capture.PNG (30.13 KiB) Viewed 13629 times
The second script
/root/apt-get/getUpgradeReport.pl returns all the actual packages and their versions using the following command.
and attempts to parse out all the listed packages it finds.
The output of this command un-parsed by plugin looks like the following.
- Capture1.PNG (21.33 KiB) Viewed 13629 times
As you can see from this output that there are no packages reported back in the output.
This is typical for Ubuntu (Debian style) system to report some small set of distro packages that are optional updates. So it shows them in the overall count but not when you ask Apt-Get to show them.
This then causes the first scripts numbers to be recorded (8 non security and 0 security) updates but listed zero in the actual app list.
Now lets just run a manual upgrade everything command on agent to Agt-get (apt-get upgrade -Y)
- Capture2.PNG (29.67 KiB) Viewed 13629 times
As you can see it upgrade 0 files. Where are those 8 applications that should now update? These 8 files are New Kernel files and such. In the current version of LUM we do not offer a Disto Update so even though the system is being updated it is not changing the kernels.
In the past, Linux admins really through up a stink when we automated kernel updates as without proper backups and considerations this may not be a wanted action so we took out the
feature some years ago.
It maybe time to revisit this and add in a function to allow user to select if distro updates should take place. If so should an automated reboot be sent after updates to complete the process?
Caveats:
If no reboot is selected then the counts will remain as they were until the reboot happens. There is a delay between the last upgrades and the MOTD if a reboot is not done.
A system may not come back after reboot if a issue with kernel is present.
A reboot may take place in an inopportune time.
I will look into adding feature to choose this ability but will not resolve the issue of visibility of packages. They will still remain invisible to the plugin.
After we ran the disto updates and rebooted the following MOTD shows packages gone.
- Capture3.PNG (25.17 KiB) Viewed 13629 times
And if we now rescan via the plugin we see those updates are now gone.
- Capture4.PNG (4.73 KiB) Viewed 13629 times
So the plugin is working, just with Distro updates turned off and no forced reboots.