Newsgroup: it.comp.os.linux.sys
Titolo: parere su script

per ripulire le cartelle spam degli utenti
avrei pensato a uno script del genere:
find /home -user  vmail -type f -ctime +30 | grep ".Spam/cur" 
| xargs rm -f
find /home -user  vmail -type f -ctime +30 | grep ".Spam/new" 
| xargs rm -f
uguale per Trash
ho un server di posta con pop e imap, basato su maildir 
secondo voi ci sono contro indicazioni ?
volevo un parere prima di far danno.
grazie


io con questo mi trovo discretamente:
find /home/*/Maildir/.Junk/cur/ -type f -mtime +30 -exec rm {} \;
DATE=`date`	
echo "$DATE - Remove Junk 30 days older" >> /var/log/
mylogfile.info
unset DATE
tralasciando il fatto che ogni mio script segna una riga in un file di 
log personalizzato, utilizzo find con rm.

 secondo voi ci sono contro indicazioni ?
S�.
* ctime non � indicato in questo caso, ma si usa mtime.
* fare un find, poi un grep e poi uno xargs cos� non � un metodo pulito ed � 
prono ad errori
* se hai dei files con spazi puoi avere casini (se hai utenti bastardi 
rischi di farti cancellare roba buona)
* Se hai roba con spazi pu� farti casino.
Se la struttura � una classica:
home + Utente1 - Maildir + .Spam + cur
      |                   |       + new
      |                   |       + tmp
      |                   + .INBOX + cur
      |                   |        + new
      |                   |        + tmp
      |                   ...
      + Utente2 - Maildir + .Spam + cur
      |                   |       + new
      |                   |       + tmp
      ...
      + Utente3 - Maildir .....
E se gli utenti non sono diverse migliaia, allora � _pi� meglio_ una cosa cos�:
find /home/*/Maildir/.{Spam,Trash}/{cur,new} -type f -mtime +30 -print0 | \
    xargs -0 rm
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 xargs -0 rm
E si puo' anche "risparmiare" un xargs eseguendo rm da find:
find /home/*/Maildir/.{Spam,Trash}/{cur,new} -type f -mtime +30 -exec rm {} 
+
(tutto su una riga)

 +
Ma perch� hanno cambiato il ';' con il '+'? E ora per backward 
compatibility e per compatibilit� con script fatti per altre versioni di 
tar, ce li ritroviamo tutti e due.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 così:


 find /home/mail -user vmail
Anche con questa struttura è comunque non molto indicato il sistema che hai 
usato. Una via di mezzo (sempre se non hai migliaia di utenti per dominio) 
può essere:
for dir in /home/mail/*
do
     find $dir/*/Maildir/.{Spam,Trash}/{cur,new} -type f -mtime +30 \
                                                 -exec rm {} \;
done


grazie per il consiglio 
mi sembra valido 
ho qualche decina di utenti per dominio , con un centinaio di 
domini.
per capire meglio, una domanda : se io lancio il comando find 
/home -user  vmail -type f -mtime +30 | grep ".Spam/cur" 
da shell,  l'otput che mi viene fuori pare corretto 
o sia i file dentro la directory indicata degli utenti 
.Spam/cur
quindi nel caso di errore sarebbe comunque dentro la directory 
indicata?
oppure c'è rischio che cancelli su inbox o send?


 oppure c'è rischio che cancelli su inbox o send?
Su inbox e send no, ma se al rm ci aggiungi un -rf potresti rischiare mezza 
casella.


 come prova e per le quali ha fatto un ricorso al Garante, che succede?
urgh: utente andare a comperare vaselina, affittare negro per mezza 
giornata, e andare a sistemare sistemista per le feste!


 find /home/*/Maildir/.Junk/cur/ -type f -mtime +30 -exec rm {} \;
  Decisamente meglio.  Dovesse find trovare un bordello di file è
possibile che il loro elenco superi la dimensione massima della riga di
comando che rm può gestire con conseguente suo abbandono, errore e
fallimento dello script.  Funzionasse lo stesso, un tale script si
mangerebbe una quantità di RAM spropositata, che in condizioni
opportunamente critiche del server potrebbe avere effetti alquanto
deleteri (OOM kill) o comunque prestazioni ridotte (=server letargico
per swapping prolungato, ad es.).
  Se lo script poi deve essere eseguito non interattivamente, è meglio
premunirsi contro la possibilità che rm chieda conferma di cancellazione
per eventuali alias o di fronte a file protetti da scrittura.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 fallimento dello script.
E' proprio il motivo per cui esiste xargs (o -exec con + finale).

intendi decisamente meglio del mio o di antani e The_ZiPMaN?


antani wrote:

quindi se faccio 
for dir in /home/mail/*
do
find $dir/*/Maildir/.{Spam,Trash}/{cur,new} -type f -mtime +30 
-exec rm {} +
mi avvicino a quello che mi serve?

 mi avvicino a quello che mi serve?
Il "-exec rm {} +" rende rm safe, ma e' la parte 
$dir/*/Maildir/.{Spam,Trash}/{cur,new}
che potrebbe espandersi troppo e creare una riga di comando troppo lunga, 
nel caso tu abbia troppi utenti, o utenti con nomi lunghi etc. Ho detto 
"potrebbe", quindi puo' anche darsi che ti funzioni.
Per vedere qual e' la massima lunghezza della riga di comando che il tuo 
sistema supporta, puoi usare questo comando:
$ getconf ARG_MAX
2097152
(in quel valore sono da includere tutti gli argomenti passati al comando e 
l'environment)
In Linux il valore e' molto alto, quindi non dovresti avere problemi; POSIX 
fissa il valore minimo a 4096 (nel qual caso avresti problemi anche con 
pochi argomenti).
(In realta', sembrerebbe che in Linux la limitazione sia stata eliminata - 
vedi 
http://lwn.net/Articles/246528/
 - eppure riesco ancora a provocare 
"Argument list too long". Devo investigare meglio)
Per il tuo problema, in definitiva, probabilmente la soluzione piu' sicura 
e' un loop sulla struttura delle directory come era stato suggerito da 
THe_ZiPMaN.

 {} +
Esistono altri due modi più sicuri ed efficienti per cancellare un file con 
find:
find $startdirectories -depth -type f -mtime +30 -execdir rm {} +
find $startdirectories -type f -mtime +30 -delete
L'opzione  -depth serve per sicurezza nel caso si debba cancellare una 
directory (OK, non sembra questo il caso) mentre l'azione -execdir 
cambia la directory prima di eseguire il comando ed evita una race 
condition. Il secondo comando usa l'azione -delete per cancellare il 
file; questo è il massimo della efficienza e della sicurezza perché 
find stesso cancella il file evitando le fork ed ogni problema con il 
nome dei file. 

 find $startdirectories -type f -mtime +30 -delete
Estiquatsi pensa: l'abitudine porta spesso ad arenarsi sulle proprie 
posizioni senza cercare di migliorarsi.
Saranno 10 anni che uso find e che di tanto in tanto sfoglio il man perché 
la memoria fa cilecca, e MAI mi ero accorto dell'opzione -delete.
E ora a rileggersi il man di find un po' più approfonditamente. :-)
Non si finisce mai di imparare.


 nome dei file.
E' vero, il -delete (che e' un'estensione GNU a cui non avevo pensato) e' 
ottimo qui.

 E ora a rileggersi il man di find un po' più approfonditamente. :-)
Credo faresti meglio a leggere le pagine info 

 Credo faresti meglio a leggere le pagine info 
Eh... Info non è nemmeno installato sui miei sistemi da tanto lo odio.
E' inusabile e stupido come l'emacs che ci sta sotto; se c'è il man bene, 
altrimenti piuttosto doc in HTML da sfogliare con links2.
Ma mai e poi mai info (dovrebbero inventare un info sfogliabile alla vi).


 Ma mai e poi mai info (dovrebbero inventare un info sfogliabile alla vi).
Ora ho capito perché non mi piace info. È il subconscio. La mia mano 
cerca di evitare la sindrome del tunnel carpale ;-)
in effetti nel 99% dei casi su info ci sono le stesse informazione 
delle pagine del manuale però formattate in modo da risultare illeg_
gibili. Però alcune (come le info su tar e find, appunto) sono dei 
veri e propri tutorial scritti molto bene, cosa che le manpage non 
potranno mai essere. In tal caso puoi sempre scaricarti la versione 
HTML o PDF sul sito della GNU.

> finale).
io lo avvio ogni ora e sto tranquillo!! :D lol

 come prova e per le quali ha fatto un ricorso al Garante, che succede?
In un mondo ideale si attacca al cazzo, è come se uno tenesse i
documenti importantissimi nel bidone del pattume e si lamentasse che
qualcuno l'ha svuotato!
Nel mondo reale... non so :-/
-- 
Massimo Bacilieri AKA Crononauta

anche nel mio mondo! tranquillo.
il server è un distributore di posta non un archivio. 


 qualcuno l'ha svuotato!
Conosci anche tu la mia collega della contabilità?
Quella che mi ha mangiato la faccia perché durante una manutenzione le
ho vuotato il cestino del mail-reader dove aveva archiviato sette anni
di corrispondenza *importantissima*?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 di corrispondenza *importantissima*?
Ibidem. 3 anni fa, quando ho fatto la migrazione a Zimbra della posta di un 
nostro cliente, l'AD (che casualmente è anche nel CDA della mia azienda) si 
è raccomandato che non venisse persa la sua posta elettronica archiviata 
perché durante la precedente migrazione gli aveva fatto un nostro 
concorrente aveva perso tutta la sua posta importante.
Ovviamente io l'ho rassicurato ed ho installato tutto da manuale, con 
autocancellazione dei messaggi in trash più vecchi di 30 giorni.
Dopo una settimana è arrivata una lamentela ufficiale che gli avevamo perso 
la posta archiviata. Ovviamente casco dalle nuvole, vado da lui (incazzato 
come una bestia) e mi mostra che dal cestino mancano i messaggi dei mesi 
precedenti. Mi spiega che lui per archiviare preme il tasto canc in modo da 
avere tutto l'archivio nel cestino.
Ovviamente ho ripristinato tutto da backup e gli ho spiegato come usare i 
folders IMAP, mostrandogli come archiviare tutto correttamente. Ancora oggi, 
dopo 3 anni, ogni 3 settimane c'è un mio collega che si connette dal cliente 
e gli sposta i messaggi dal cestino nella cartella archivio.


 dal cliente e gli sposta i messaggi dal cestino nella cartella archivio.
Ma ROTFL !!!
Dimmi che non e' vero veramente !!!! Ti prego !! Questa e' da "Storie di sala 
macchine".... minchia che gente !!!
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verità è 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciò che 
si possiede.

 sala macchine".... minchia che gente !!!
Mandala a Davide Bianchi! :-D


 minchia che gente !!!
E' perché son buono e non faccio i nomi... ma pensa solo che questo tizio 
dichiara redditi per 305.000 euro l'anno, quindi in 3/4 giorni guadagna 
quello che mediamente noi guadagnamo in un mese.


 guadagna quello che mediamente noi guadagnamo in un mese.
Argghhhh !!! Ti giuro che queste cose mi fanno piangere !!!
Ma non perche' lui non sappia usare le mail che puo' anche essere lecito (non e' 
il suo mestiere) ma per la rigidita' mentale con cui si approccia al problema !!
Non conoscere e' un conto, non voler imparare e' un altro !
E per 305.000 €/anno imparerei anche la divina commedia in russo io !!!
Vabbe' stendiamo un velo pietoso e torniamo ai nostri server che almeno quando 
riesci a far loro imparare qualcosa (di solito) lo fanno per sempre e bene !


 Dove e' scritto che sono proprio 10?  :-)
mmmmh, non so da dove mi sia uscito sto 10 effettivamente. Ricordo delle 
prove fatte e forse erano addirittura 100 (almeno nelle mie prove). Anche se 
da man non è specificato:
       -exec command {} +
              This variant of the -exec action runs the specified command on 
the selected files, but the command line is built by appending each selected 
file name at the end; the total number of invocations of the command
              will be much less than the number of matched files.  The 
command line is built in much the same way that xargs builds its command 
lines.  Only one instance of `{}' is allowed within the command.  The  
command
              is executed in the starting directory.
-- 
Vide

 sono affatto sicuro).
Direi che è di GNU find del 2000 e fischia (quindi sì, relativamente 
recente)
-- 
Vide

 tar, ce li ritroviamo tutti e due.
Max, leggiti il man del find. Il ; passa un argomento alla volta all'exec. 
Il + pasa blocchi di 10 argomenti alla volta all'exec.
-- 
Vide

 Il + pasa blocchi di 10 argomenti alla volta all'exec.
Dove e' scritto che sono proprio 10?  :-)

 Argghhhh !!! Ti giuro che queste cose mi fanno piangere !!!
Premetto che non vado più in giro per i desktop da, buff, buff, buff... 
da almeno sei anni.
Però ricordo ancora le rotture di palle tra le più assurde. C'era tizio 
che se la prendeva con me perché aveva rotto il disco del suo desktop ed 
aveva perso tutti i suoi dati (e non salvava nulla sui server). Un'altro 
(a proposito di redditi) che da windows 98 non riusciva a stampare il 
PDF di 500 pagine con tutte le dichiarazioni dei redditi, e anche lui se 
la prendeva con me. Installo NTOP e sgamo un direttore di stabilimento 
che passava il tempo a guardare film porno. Insomma, come tutti voi, 
penso di averne viste di cotte e di crude.
Oggi, però, in maniera un po' più distaccata direi che i cestini degli 
altri non cono caXXi che non mi riguardano. E prima di svuotarlo 
proverei a spiegare che il cestino, prima o poi va svuotato, e di solito 
è una operazione che non si fa selettivamente, ma cliccando su "svuota 
cestino", o su "select all, delete".
Però, no: i dati degli utenti, sono i dati degli utenti. Così come i 
tuoi dati, sono i tuoi dati e i miei dati sono i miei dati.
Tu faresti accedere una persona al tuo PC per farti riordinare i tuoi 
messaggi di posta?


 al problema !!
Personalmente vedo rigidita` da ambedue le parti. A parte che alcuni client 
email (e.g. KMail) ti chiedono come comportarsi con i messaggi piu` vecchi 
di tot giorni, visto che stiamo parlando di IMAP io avrei impostato uno 
script che spostava i messaggi da una casella ad un'altra in automatico 
(anche se devo dire che non so quanto sia fattibile con la gestione della 
posta di Zimbra)
Enrico
P.S. 
http://picocool.com/images/uploads/img_891.jpg
 :)

 
se paghi uno affinché il server sia sempre efficiente, gli hai 
anche firmato un contratto per farlo, clausule privacy 
incluse.
comunque va anche capito di che tipo di server si tratta; se è 
un server locale che archivia è un conto, se è un server 
remoto che distribuisce è un altro.
il mio è il secondo caso. 

Vide wrote:

ho una centos4.4 dici che non funziona? 


d'accordo sul discorso privacy. Però: privacy != cancellare.
Cancellare dati arbitrariamente non rientra in nessun compito di 
manutenzione. Io capisco quello che ha fatto Zip (posso aver fatto anche 
io una cosa del genere, anche se ora non mi ricordo). Lo si fa in 
assoluta buona fede, perché tu pensi che "l'idiota" si è dimenticato di 
eseguire "svuota cestino".
p.s.: ma zimbra usa la maildir o ha un qualche DB per le mail? Il mail 
server di Sun usa un DB per archiviare le mail.


 eseguire "svuota cestino".
In buona fede potrei anche organizzare un tool di backup che *ignori*
tutti i cestini o i folder dedicati allo spam, poiché più che
ragionevolmente potrei pensare che è stupido fare il backup di ciò che è
 nei fatti *già* stato cancellato volontariamente.



molto ma molto controversa come cosa :-) Non so che rispondere... sarei 
portato a dire: bene è così che si fa! .... però .... da un'altra parte 
è il cliente che paga e se un domani perdi la commessa perché gli hai 
cancellato un dato in buona fede? Chi la spunta tu o lui?
mi stavo chiedendo: non ho mai giocato a spostare messaggi direttamente 
nella maildir (se non tramite procmail). Ho visto che dovecot usa un 
file di indici. Cosa succcede se gli togli i messaggi da sotto il 
"sedere"? (domanda retorica) Fila tutto liscio? (domanda retorica) *non* 
fila tutto propriamente liscio. E il fatto che dovecot si debba 
ricostruire gli indici diminuisce le performance.
http://wiki.dovecot.org/procmail
Procmail delivers mails into Maildir folders, if a slash is appended to 
the folder name (e.g. ".spam/"). But Procmail itself could not update 
the Dovecot index files. This decreases the performance a bit, because 
the Dovecot IMAP or POP3 server has to add new mails for the index files.
Insomma, questi spostamenti forse è meglio farli a server scarico (la 
notte, i fine settimana).


Max_Adamo wrote:

in genere si mette un cron alle 2 di notte

 cancellato un dato in buona fede? Chi la spunta tu o lui?
Dipende dalle policy accettate di comune accordo. Ad esempio, per policy 
aziendale il backup dei dati presenti sul file server del mio ufficio e` 
definito in un documento specifico, in cui e` scritto chiaramente che solo i 
dati di alcune directory condivise sono posti sotto backup, mentre non vi e` 
alcun backup specifico per le home directory (eccetto il palliativo offerto 
dal RAID) a meno che non vi sia una richiesta esplicita (richiesta che, 
ovviamente, dev'essere tracciata e tracciabile). Tale documento e` stato 
stampato e firmato dai miei superiori, di conseguenza il giorno in cui ci 
sara` (e ci sara`, oh se ci sara`) una perdita di dati non posti sotto 
backup nessuno, sia esso un collega od un capo potra` imputare la colpa a me 
o ai miei colleghi di reparto
Enrico

 ho una centos4.4 dici che non funziona?
Sì che funzionerà.
-- 
Vide

 
a questo punto di una cosa cosi che ne pensate?
for dir in /home/mail/*
do
     find $dir/*/Maildir/.{Spam,Trash}/{cur,new} -type f -
mtime +30 -delete
done
oppure 
 
      for dir in -user  vmail
do
     find /home/mail/*/$dir/Maildir/.{Spam,Trash}/{cur,new} -
type f -mtime +30 -delete
done    

 for dir in -user  vmail
Ridondante e prono a errori. Lo puoi fare con una linea di find. Cerca nel 
man find l'opzione "-user".
(ometto la soluzione perchè ormai banale e te la puoi cercare da solo, che 
siamo su .sys :P
-- 
Vide