Linux
View all Worklets
LinuxLinux

Set Timezone

Enforce a consistent timezone on Linux endpoints by rewriting /etc/localtime to the correct zoneinfo file

Worklet Details

What the Linux timezone enforcer does

This Automox Worklet™ enforces a designated timezone on Linux endpoints by rewriting the /etc/localtime symbolic link to point at the matching file under /usr/share/zoneinfo. The evaluation script exits non-zero on every run, which means the remediation script always fires. In the remediation script, the Worklet checks whether /etc/localtime is a symlink and whether it already points at the correct zoneinfo file using a file-equality comparison. Endpoints already at the correct target are left untouched; endpoints with a wrong or missing symlink are updated.

The target timezone is defined by editing the timezone variable in the remediation script (for example, /usr/share/zoneinfo/America/Chicago or /usr/share/zoneinfo/Europe/London). The remediation script verifies that /etc/localtime is a symbolic link before acting, then checks whether the target zoneinfo file matches the configured value using [ ! "$(readlink /etc/localtime)" -ef "$timezone" ]. When the symlink is wrong, the script removes the existing symlink with rm -rf /etc/localtime and recreates it with ln -s pointing at the configured zoneinfo file.

The Worklet uses the symlink approach instead of timedatectl set-timezone so it runs uniformly on systems with and without systemd, including container hosts and older RHEL 6-era servers still in production. On systemd-managed endpoints, the rewritten /etc/localtime is the same artifact timedatectl manages, so subsequent status output (timedatectl status, ls -l /etc/localtime, date +%Z) reports the enforced zone consistently. Where /etc/timezone is also present (Debian and Ubuntu), administrators can layer a companion Worklet that writes the canonical zone name into that file for tools that read it directly.

Why hold the Linux timezone baseline at fleet scale

Drifted timezones quietly break the operations stack. Log correlation across SIEM pipelines depends on every endpoint reporting the same zone (or UTC), and a single host stuck on the wrong zoneinfo file shifts its events out of the timeline an incident responder is reading. Cron and systemd timers fire against the local zone, so a misaligned endpoint runs nightly backups at the wrong wall-clock hour, misses maintenance windows, or stacks two jobs on top of each other. CIS Linux Benchmarks call out timezone configuration as a baseline control, and SOC 2 and PCI-DSS audits expect timestamp consistency across in-scope systems.

The /etc/localtime symlink is one of those settings that nobody touches deliberately but plenty of automation rewrites unintentionally. A cloud-init template ships the wrong zoneinfo target, an Ansible run rewrites the symlink to match a stale group_var, an engineer fixes a single host by hand during an outage and forgets to push the change back. Because the evaluation script always exits non-zero, the remediation script checks the symlink on every policy run and swaps it when it diverges, so /etc/localtime returns to the configured zone before the next nightly cron firing or SIEM ingest window.

How Linux timezone enforcement works

  1. Evaluation phase: The evaluation script exits non-zero unconditionally, so the Automox agent always schedules remediation. There is no conditional logic in the evaluation script.

  2. Remediation phase: The remediation script checks that /etc/localtime is a symbolic link, then compares its target to the configured zoneinfo file using a file-equality test. If the symlink already points at the correct file, the script takes no action. If the symlink is wrong, the script removes it with rm -rf /etc/localtime and recreates it with ln -s pointing at the configured timezone file. The change takes effect immediately for new shells and processes; long-running services that cached the previous zone may need a restart to pick up the new value.

Linux timezone enforcement requirements

  • Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, or Ubuntu with the tzdata package installed (default on every mainstream distribution)

  • Root or sudo privileges for the Automox agent (the default agent context already meets this)

  • Bash interpreter at /bin/bash for the evaluation and remediation scripts

  • Target timezone defined by editing the timezone variable in the remediation script to a valid path under /usr/share/zoneinfo (run ls /usr/share/zoneinfo or timedatectl list-timezones on any reference endpoint to enumerate valid values)

  • /etc/localtime must exist as a symbolic link; if it is a regular file rather than a symlink, the remediation script will not rewrite it

  • Optional: pair with a Worklet that writes the canonical zone name (for example, America/Chicago) into /etc/timezone on Debian and Ubuntu endpoints where tools read that file directly

Expected state after timezone enforcement

On a compliant endpoint, ls -l /etc/localtime shows the symlink resolving to the configured zoneinfo file. The date command prints timestamps in the enforced zone (date +%Z returns the matching abbreviation), and timedatectl status on systemd hosts reports the same Time zone value. Subsequent Automox policy runs always fire the remediation script, which exits without making changes once the symlink is correct. New shells, cron entries, and systemd timers immediately use the enforced zone; long-running daemons (rsyslog, systemd-journald, application servers) may continue to log in the previous zone until restarted, so plan a rolling service restart or scheduled reboot if the change must propagate to in-flight processes.

For audit evidence, capture the output of readlink /etc/localtime, timedatectl status (where available), and date -u together with the Automox policy run identifier. The enforced timezone survives reboots and kernel upgrades because /etc/localtime is a persistent file on the root filesystem. The link is only displaced if an administrator removes or rewrites it, or if a configuration management tool (Ansible, Puppet, Chef, cloud-init) re-applies a competing baseline. In either case the remediation script checks the symlink on the next policy run and swaps it back with ln -s.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets