mirror of
https://github.com/Security-Onion-Solutions/securityonion.git
synced 2025-12-06 17:22:49 +01:00
Adding airgap hotfix
This commit is contained in:
@@ -572,16 +572,28 @@ update_version() {
|
||||
# Update the version to the latest
|
||||
echo "Updating the Security Onion version file."
|
||||
echo $NEWVERSION > /etc/soversion
|
||||
echo $HOTFIXVERSION > /etc/sohotfix
|
||||
sed -i "/ soversion:/c\ soversion: $NEWVERSION" /opt/so/saltstack/local/pillar/global.sls
|
||||
}
|
||||
|
||||
upgrade_check() {
|
||||
# Let's make sure we actually need to update.
|
||||
NEWVERSION=$(cat $UPDATE_DIR/VERSION)
|
||||
HOTFIXVERSION=$(cat $UPDATE_DIR/HOTFIX)
|
||||
CURRENTHOTFIX=$(cat /etc/sohotfix)
|
||||
if [ "$INSTALLEDVERSION" == "$NEWVERSION" ]; then
|
||||
echo "Checking to see if there are hotfixes needed"
|
||||
if [ "$HOTFIXVERSION" == "$CURRENTHOTFIX" ]; then
|
||||
echo "You are already running the latest version of Security Onion."
|
||||
exit 0
|
||||
else
|
||||
echo "We need to apply a hotfix"
|
||||
is_hotfix=true
|
||||
fi
|
||||
else
|
||||
is_hotfix=false
|
||||
fi
|
||||
|
||||
}
|
||||
|
||||
upgrade_check_salt() {
|
||||
@@ -712,6 +724,15 @@ upgrade_check_salt
|
||||
echo ""
|
||||
echo "Performing upgrade from Security Onion $INSTALLEDVERSION to Security Onion $NEWVERSION."
|
||||
echo ""
|
||||
|
||||
if [[ $is_hotfix ]]; then
|
||||
echo "Do Hotfix Things"
|
||||
copy_new_files
|
||||
echo ""
|
||||
update_version
|
||||
salt-call state.highstate -l info queue=True
|
||||
|
||||
else
|
||||
echo "Updating dockers to $NEWVERSION."
|
||||
if [ $is_airgap -eq 0 ]; then
|
||||
airgap_update_dockers
|
||||
@@ -848,6 +869,8 @@ if [ $NUM_MINIONS -gt 1 ]; then
|
||||
|
||||
cat << EOF
|
||||
|
||||
|
||||
|
||||
This appears to be a distributed deployment. Other nodes should update themselves at the next Salt highstate (typically within 15 minutes). Do not manually restart anything until you know that all the search/heavy nodes in your deployment are updated. This is especially important if you are using true clustering for Elasticsearch.
|
||||
|
||||
Each minion is on a random 15 minute check-in period and things like network bandwidth can be a factor in how long the actual upgrade takes. If you have a heavy node on a slow link, it is going to take a while to get the containers to it. Depending on what changes happened between the versions, Elasticsearch might not be able to talk to said heavy node until the update is complete.
|
||||
@@ -855,9 +878,12 @@ Each minion is on a random 15 minute check-in period and things like network ban
|
||||
If it looks like you’re missing data after the upgrade, please avoid restarting services and instead make sure at least one search node has completed its upgrade. The best way to do this is to run 'sudo salt-call state.highstate' from a search node and make sure there are no errors. Typically if it works on one node it will work on the rest. Forward nodes are less complex and will update as they check in so you can monitor those from the Grid section of SOC.
|
||||
|
||||
For more information, please see https://docs.securityonion.net/en/2.3/soup.html#distributed-deployments.
|
||||
|
||||
EOF
|
||||
|
||||
fi
|
||||
fi
|
||||
|
||||
echo "### soup has been served at `date` ###"
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user