| Pianificazione | Comando | Descrizione | Stato | Azioni |
|---|---|---|---|---|
0 5 * * * |
/usr/local/bin/custom-backup.sh >> /var/log/arciveo-cron.log 2>&1 |
Nightly backup to remote storage | ||
*/15 * * * * |
/usr/local/bin/healthcheck.sh |
Ping external uptime monitor |
| Comando | |
|---|---|
30 1 * * * /usr/local/bin/clamav-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 |
|
@reboot chmod 755 /var/lib/aide |
|
0 3 * * * /usr/local/bin/lynis-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 4 * * * /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
@reboot sleep 60 && /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
30 4 * * * /usr/local/bin/debsums-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 6 * * * /usr/local/bin/logwatch_daily.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 8 * * * /usr/local/bin/daily-report-all.sh >> /var/log/arciveo-cron.log 2>&1 |
|
*/30 * * * * /usr/local/bin/smart-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 * * * * /usr/bin/apt-get update -qq >/dev/null 2>&1 |
|
*/5 * * * * /usr/local/bin/collect-metrics-all.sh >> /var/log/arciveo-cron.log 2>&1 |
Cron non racconta nulla di sé. Non segnala che un'attività è fallita, non mostra quando è stata eseguita l'ultima volta, e un errore di sintassi nei cinque campi della pianificazione non ha modo di emergere. Formalmente invia una mail all'utente locale, ma su un server dove la posta in uscita non è mai stata configurata quel messaggio non lo legge nessuno. Un'attività può restare rotta per mesi, e a tradirla sono le conseguenze.
Questa pagina elenca le attività aggiunte dal pannello: pianificazione, comando, descrizione e stato, con la possibilità di attivarne, disattivarne o eliminarne una senza aprire un terminale. Sotto, in un elenco separato, ci sono le altre righe del crontab di root, quelle che lei o un pacchetto installato avete messo in precedenza. Sono in sola lettura: il pannello non modifica di proposito ciò che non ha scritto.
Qui vale la pena controllare tre cose. Un'attività il cui output finisce in /dev/null 2>&1 tace allo stesso modo quando funziona e quando è rotta. Un comando scritto come nome breve anziché come percorso completo si comporta diversamente che nella sua shell, perché cron ha un proprio PATH, molto scarno. E la pianificazione stessa: un'attività disattivata una volta per il debug di solito resta disattivata. Dopo ogni sospetto di intrusione anche il crontab merita una rilettura: insediarsi tramite lo scheduler è più semplice che tramite un'unità di avvio, e la riga sembra del tutto ordinaria.