Come cancellare i log di controllo di Zimbra per liberare spazio su disco in modo sicuro

Inizia decidendo cosa devi effettivamente rimuovere

Un server Zimbra con spazio su disco insufficiente può far sì che la pulizia dei log sembri un'esigenza urgente, ma /opt/zimbra/log/audit.lognon si tratta di semplici output diagnostici usa e getta. Zimbra li documenta come traccia di controllo per gli eventi di autenticazione e le attività amministrative. Ciò significa che il metodo di pulizia migliore dipende dalla necessità di liberare spazio immediatamente, conservare le prove storiche o optare per una soluzione di conservazione a lungo termine.

La soluzione più sicura è lasciare il audit.logfile attivo intatto e occuparsi prima delle copie ruotate più vecchie. Se si è soggetti a una politica di conservazione interna, a un blocco legale o a un requisito di conformità, è necessario archiviare tali file su un altro file system prima di eliminare qualsiasi elemento. Se il file attivo è diventato insolitamente grande, è possibile svuotarlo, ma questa operazione dovrebbe essere considerata una misura di emergenza perché rimuove la cronologia di controllo corrente e può introdurre una piccola finestra di competizione se il server continua a scrivere mentre si tenta di copiarlo.

La documentazione ufficiale di Zimbra sui log colloca audit.loge /opt/zimbra/logdescrive Log4j come il componente responsabile della rotazione di file come audit.loge mailbox.log. Altri log di Zimbra potrebbero invece utilizzare la logrotateconfigurazione del sistema operativo, quindi non si deve presumere che ogni file nella directory segua lo stesso meccanismo. Consultare il riferimento ufficiale di Zimbra sui file di log e le note sulla rotazione dei log di Zimbra .

Confronta le opzioni di pulizia prima di agire

Passaggio 1: Misura il problema prima di eliminare qualsiasi cosa

Innanzitutto, conferma che i log di controllo siano effettivamente responsabili della pressione. Eseguili come root:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

Il primo comando indica il livello di riempimento del filesystem /opt. Il secondo mostra l'ingombro complessivo dei log di Zimbra. Il terzo visualizza il file di audit attivo e le eventuali generazioni ruotate. Se i file di audit rappresentano solo una piccola parte del filesystem, la loro cancellazione potrebbe non risolvere il problema reale; lo spazio potrebbe essere occupato da archivi di caselle di posta, backup, file di database o un'altra famiglia di log.

Annota anche la versione installata prima di modificare il comportamento:

su - zimbra -c 'zmcontrol -v'

Questo è importante perché la documentazione di Zimbra si estende su diverse generazioni di prodotto e la sintassi esatta di Log4j, la configurazione generata e i processi di pruning possono variare. Non copiare un valore di retention da un vecchio esempio wiki e presumere che sia il tuo valore predefinito attuale.

Prima di decidere cosa rimuovere, verifica l'utilizzo del filesystem, la dimensione totale dei log di Zimbra e le singole generazioni di log di controllo.

Passaggio 2: Verifica come questo server gestisce la rotazione e la pulizia dei file di log.

Zimbra documenta due meccanismi rilevanti: Log4j per i file inclusi audit.loge il sistema operativo logrotateper diversi altri log di Zimbra. Nota inoltre che il crontab di Zimbra stesso può contenere attività di manutenzione dei log. È consigliabile esaminare la configurazione in tempo reale anziché procedere per tentativi:

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

Se uno di questi file non contiene l'impostazione prevista per la tua release, controlla la configurazione di logging circostante anziché forzare l'inserimento di un esempio precedente. I file generati possono anche essere sovrascritti dopo il riavvio del servizio o la rigenerazione della configurazione. Le note di logging di Zimbra distinguono specificamente le modifiche temporanee al file delle proprietà generato dalle modifiche permanenti apportate al .inmodello corrispondente.

Per i server con un volume di audit insolitamente elevato, verificare se è stata abilitata intenzionalmente una registrazione aggiuntiva. Le note di rilascio di Zimbra 10.0.6 documentano l' zimbra_additional_loggingattributo di configurazione locale, che può aggiungere ulteriori eventi di autenticazione non riusciti o altrimenti utili audit.log. Non disabilitare la registrazione di sicurezza utile solo per risparmiare spazio; se il volume è legittimo, una soluzione migliore è solitamente la conservazione, la compressione o l'archiviazione centralizzata dei log. Consultare le note di rilascio ufficiali di Zimbra 10.0.6 .

Prima di modificare il comportamento di conservazione o rotazione dei dati, esamina la configurazione effettiva di crontab e Log4j del server.

Passaggio 3: Preferire l'archiviazione o l'eliminazione dei log ruotati

Per la maggior parte degli amministratori, i vecchi log di controllo ruotati rappresentano il primo obiettivo migliore. Utilizzateli findin modalità solo report prima di eliminare qualsiasi elemento. L'esempio seguente elenca i log di controllo ruotati più vecchi di 30 giorni; 30 giorni è solo una soglia esemplificativa, non un periodo di conservazione prescritto da Zimbra:

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

Se quei file non sono più necessari, eliminate solo i file ruotati che avete esaminato. Se invece dovete conservarli, copiateli o archiviateli prima su un filesystem diverso. Utilizzare un altro punto di montaggio è importante quando la partizione di Zimbra è già quasi piena, perché la creazione di un archivio compresso sullo stesso filesystem pieno può temporaneamente consumare ancora più spazio.

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

Ripeti l'operazione per gli stessi nomi di file che hai controllato. Verifica il backup prima di rimuovere la sorgente. Evita modelli generici come rm -f /opt/zimbra/log/audit.log*; questo modello corrisponde anche al file attivo.

Se si desidera conservare i vecchi file di log in locale ma ridurne l'ingombro, comprimere solo i file ruotati:

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

L'utilità della compressione dipende dalla configurazione attuale della rotazione dei log. Alcune implementazioni potrebbero già comprimere i log storici nell'ambito delle attività di manutenzione. Verifica cosa è effettivamente presente prima di aggiungere un ulteriore livello di compressione.

Le linee guida di Zimbra sulla registrazione storica avvertono inoltre che i log di controllo possono contenere dati sensibili. Trattate gli archivi con gli stessi controlli di accesso dei log in tempo reale. Consultate le linee guida ufficiali di Zimbra sulla registrazione .

Elenca prima i vecchi file ruotati, copia la cronologia necessaria in una memoria separata e solo dopo rimuovi le generazioni esaminate.

Quando il troncamento del registro di controllo attivo è giustificato

Se i file ruotati non sono il problema e il file attivo audit.logstesso sta consumando spazio critico, il troncamento può recuperare spazio immediatamente. È anche l'opzione con il compromesso più chiaro: la cronologia di controllo corrente viene eliminata una volta che il file viene troncato.

Una procedura di emergenza più sicura consiste nell'arrestare brevemente mailboxd, copiare il file attivo su un altro file system, troncare l'originale sul posto in modo da preservarne la proprietà e i permessi, e quindi riavviare mailboxd:

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

Questo comporta un'interruzione del servizio di posta elettronica, quindi non è la soluzione ideale per ogni ambiente. Copiare il file attivo senza arrestare mailboxd evita l'interruzione del servizio, ma crea una condizione di competizione in cui le voci scritte dopo la copia e prima del troncamento potrebbero andare perse. Se la pressione sul disco non è eccessiva, è preferibile pulire i file ruotati e correggere i criteri di conservazione.

Non utilizzare rmil log attivo come prima risposta. Un processo può continuare a scrivere attraverso un descrittore di file aperto anche dopo l'eliminazione della voce di directory, quindi lo spazio su disco previsto potrebbe non essere recuperato immediatamente. Il troncamento dell'inode esistente è più prevedibile quando è realmente necessario un'eliminazione di emergenza.

Passaggio 4: Verificare sia il ripristino del disco che la registrazione continua

Dopo la pulizia, conferma il risultato anziché basarti sull'assenza di errori:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

Un buon risultato si manifesta con tre segnali: lo spazio libero sul filesystem di destinazione è aumentato, il filesystem audit.logesiste ancora e riceve nuovi eventi, e i relativi servizi Zimbra rimangono in esecuzione. Se dfil filesystem risulta ancora pieno nonostante dula riduzione dello spazio disponibile sia stata drastica, prima di eliminare ulteriori dati, verificare la presenza di file eliminati ancora aperti da processi in esecuzione.

Verificare lo spazio recuperato, le recenti attività di audit e lo stato del servizio dopo la pulizia.

Scegli la soluzione a lungo termine in base al motivo per cui i log sono cresciuti

Se la crescita è normale ma la ritenzione è troppo lunga

Modificate il processo di conservazione o eliminazione solo dopo aver documentato il periodo di cronologia richiesto. Esaminate la configurazione esistente di Zimbra crontab e Log4j, quindi apportate la modifica più piccola possibile in base alla versione. Conservate una copia della configurazione originale e verificate che la successiva rotazione crei effettivamente i file previsti.

Se il rumore di autenticazione sta influenzando il volume

È preferibile indagare sulla fonte piuttosto che limitarsi a eliminare i dati più velocemente. Tentativi di accesso ripetuti, client configurati in modo errato, sonde di monitoraggio o un'espansione intenzionale dei log di autenticazione possono tutti aumentare il volume dei dati di audit. Poiché questi dati audit.logsono utili per le indagini sulla sicurezza, ridurre il rumore di fondo è generalmente meglio che sopprimere le prove.

Se devi conservare mesi di storico delle verifiche

Spostare o inviare i log a un archivio progettato per la conservazione. La registrazione centralizzata, l'archiviazione a oggetti o un filesystem di log dedicato separano la cronologia di conformità dalla capacità richiesta dalla piattaforma di posta. La documentazione di Zimbra sui file di log discute esplicitamente le opzioni di registrazione centralizzata, tra cui audit.log.

Cosa non fare

• Non eliminare audit.log*utilizzando un carattere jolly non verificato.
• Non si presume che /etc/logrotate.d/zimbracontrolli il registro di controllo attivo su ogni rilascio; Zimbra documenta Log4j come meccanismo di rotazione per audit.log.
• Non comprimere o archiviare sullo stesso filesystem quasi pieno a meno che tu non abbia verificato che ci sia spazio temporaneo sufficiente.
• Non ridurre i tempi di conservazione senza aver prima verificato i requisiti organizzativi, legali o di sicurezza.
• Non modificare in modo permanente i file Log4j generati senza prima aver verificato se Zimbra li rigenererà a partire da un modello.

Controllo finale

Se i vecchi file di log ruotati erano la causa principale della riduzione dello spazio occupato, la soluzione ideale è semplice: il file di log di controllo attivo rimane intatto, i file storici vengono archiviati o rimossi in base alle policy e il filesystem recupera spazio sufficiente per funzionare normalmente. Se lo spazio ricomincia immediatamente a diminuire, è necessario smettere di considerare la pulizia come la soluzione e analizzare la velocità di scrittura, l'attività di autenticazione, la configurazione della rotazione e le eventuali impostazioni di logging aggiuntive. Questa distinzione – pulizia una tantum rispetto alla crescita ricorrente dello spazio occupato – è ciò che determina se il problema è stato effettivamente risolto.