How urgent is a *** System restart required *** for security?
Rise to the top 3% as a developer or hire one of them at Toptal: https://topt.al/25cXVn
--------------------------------------------------
Music by Eric Matyas
https://www.soundimage.org
Track title: Puzzle Game Looping
--
Chapters
00:00 How Urgent Is A *** System Restart Required *** For Security?
01:34 Accepted Answer Score 48
02:14 Answer 2 Score 0
02:57 Answer 3 Score 3
04:55 Thank you
--
Full question
https://superuser.com/questions/815433/h...
--
Content licensed under CC BY-SA
https://meta.stackexchange.com/help/lice...
--
Tags
#linux #reboot
#avk47
ACCEPTED ANSWER
Score 48
The is no simple answer as it depends on the updates made. If the kernel had a serious security problem then it is good to restart as soon as possible. If the kernel had only minor fixes then the restart could be postponed.
If you guarantee an availability > 99.9% then you will almost always have a clustered system where you can reboot the nodes one by one without interrupting the service.
So you reboot the first system and reatach it to the cluster. Then the second and so on. Then the service will never become unavailable.
ANSWER 2
Score 3
addon for the topic solution
I perform similar check for 'reboot requirement' for zabbix monitoring system
I see 2 issue in 'Topic' solution:
- aptitude usually works badly in scripts. I kill a few hours but still didn't make it work with zabbix
- if only 1 changelog includes urgent update - your check will always show positive results
My logic is:
- Check last change only in changelog for every package which requires system reboot
- As an output show only highest priority update
Using Debian documentation I found 5 possible values for 'urgency' and also fact that it can followed by equal("=") or semicolon(":") characters. Also there're can be upper and lower case characters
So I ended up with following:
#!/bin/bash
##################################
# Zabbix monitoring script
#
# Checking urgency in changelog
# for updates which require system restart
#
##################################
# Contact:
# anton.lugovoi@yandex.ru
##################################
# ChangeLog:
# 20151205 initial creation
# 20151208 check uniq packages only
##################################
case "$1" in
status)
if [ -f /var/run/reboot-required ]; then
echo 1
else
echo 0
fi
;;
urgency)
if [ -f /var/run/reboot-required.pkgs ]; then
while read pkg; do
tmp=`/usr/bin/apt-get changelog $pkg | \
/bin/grep -m1 -ioP '(?<=[Uu]rgency[=:])(low|medium|high|emergency|critical)' | \
tr '[:upper:]' '[:lower:]'`
if [ -n $tmp ]; then
if [ "$tmp" == "low" ] && \
[ "$urgency" != "medium" ] && \
[ "$urgency" != "high" ] && \
[ "$urgency" != "emergency" ] && \
[ "$urgency" != "critical" ]; then
urgency=low
elif [ "$tmp" == "medium" ] && \
[ "$urgency" != "high" ] && \
[ "$urgency" != "emergency" ] && \
[ "$urgency" != "critical" ]; then
urgency=medium
elif [ "$tmp" == "high" ] && \
[ "$urgency" != "emergency" ] && \
[ "$urgency" != "critical" ]; then
urgency=high
elif [ "$tmp" == "emergency" ] && \
[ "$urgency" != "critical" ]; then
urgency=emergency
elif [ "$tmp" == "critical" ]; then
urgency=critical
break
fi
fi
done < <(sort -u /run/reboot-required.pkgs)
else
urgency=none
fi
case "$urgency" in
none) urgency=0 ;;
low) urgency=1 ;;
medium) urgency=2 ;;
high) urgency=3 ;;
emergency) urgency=4 ;;
critical) urgency=5 ;;
*) urgency=42 ;;
esac
echo $urgency
;;
esac
exit 0
As a result:
reboot_required_check.sh status
returns 1 if reboot is required, 0 if isn'treboot_required_check.sh urgency
returns highest 'urgency' level or '0' if reboot is not required
Hope it helps someone to save a time ;)
ANSWER 3
Score 0
What I wonder about though, is how this works for webservers which should be up 99.9999etc% of the time? Do they simply not restart and risk the security being breached because security updates are not installed (which I cannot imagine)? Or do they take the downtime for granted (which I cannot imagine either)?
Big web servers are restarted when * System restart required * appears for security reasons.
But this is transparent to the user and the site is never down because big servers often run two or three servers that store exactly the same files and display the same site. The first one is the main server while the two others are secondary and are used only when the main server is down.