Automation
Automated security updates for Linux systems
A recurring manual maintenance process on several Linux VMs was automated. Updates, reboot checks, logging and notifications have run since then without a manual start.
- Area
- Automation
- Technologies
- Linux, shell, cron, email
- Project type
- Operations automation
Starting point
-
01
Several Linux VMs had to be supplied with security updates on a regular basis.
-
02
The flow ran manually before. Each system had to be checked, updates started and then verified.
-
03
After each update it also had to be established whether a reboot was required.
-
04
Because several virtual machines were involved, the same administrative flow arose every week.
-
05
At the same time it had to be ensured that errors do not go unnoticed and that it is always clear what happened on which system.
Goal
The recurring maintenance process was to be automated as fully as possible.
The systems were to independently:
- run updates
- check whether a reboot is required
- identify the respective host unambiguously
- report the status to the people responsible
- send log information automatically on errors
Manual intervention was no longer to be required in the normal case.
Architecture
- 01 Cron job
- 02 Shell script
- 03 Linux update process
- 04 System status check
- 05 Reboot logic
- 06 Logging and email notification
The shell script is started automatically once a week by a cron job.
At the start the hostname of the system is determined. Each notification can therefore be assigned unambiguously to a specific VM.
The intended updates are then run and the relevant output is logged.
After completion the script checks whether a reboot is required for the system.
Implementation
Automatic start
The entire process runs on a schedule once a week.
Update process
The intended Linux updates are installed and logged automatically.
Reboot check
After the update finishes, the script checks whether a reboot is necessary.
If a reboot is required, the people responsible are informed. The system then restarts automatically after a defined waiting time.
Status messages
After a successful run, an email is sent with the respective hostname and the relevant update information.
Error handling
If an error occurs during the update, the process is not simply ended.
Instead the people responsible automatically receive an error message including the relevant log output.
Result
The recurring manual maintenance effort was largely removed.
Less routine work
The individual systems no longer have to be opened and updated by hand every week.
Automatic check
The script checks on its own whether a reboot is necessary after the updates.
Transparent status
Each run produces a traceable message with hostname and update information.
Errors are reported actively
Problems do not have to be discovered by chance. On a failed run the people responsible are informed automatically.
Before and after
Check systems one by one
Automatic weekly start
Run updates by hand
Automatic update
Check reboot need by hand
Automatic reboot check
Trace the status of individual VMs by hand
Notification with hostname and logs
Errors have to be found actively
Automatic error message
Regular administration effort
Intervention mainly on deviations
Why this solution
- Neither AI nor an extra automation platform was necessary for this use case.
- A shell script together with the Linux tools already on the machines was the simplest and most robust solution.
- The actual task was not to run an update command automatically.
- What mattered was the complete flow of scheduling, status check, reboot logic, logging, error handling and communication.
- The point was not to use as much technology as possible, but exactly the technology the process needed.
Room to grow
The existing flow can be extended if needed.
Central monitoring
The patch status of several systems could be shown centrally.
Historical evaluation
Update results could be stored and evaluated over the long term.
Ticket integration
Errors could automatically create tickets in an existing service management system.
Different maintenance windows
Systems could be updated at different times depending on role and criticality.
Central patch management
In a clearly larger system landscape the simple script approach could later be complemented by a central management solution.
A similar use case?
Many recurring technical tasks need no new platform and no complex AI solution. Often a small, robust automation is enough to remove regular manual work for good.