Newsgroup: it.comp.os.linux.sys
Titolo: "cronizzare" fetchnews e procmail ghost

Due problemi.
Mi sono messo in testa di automatizzare tutti i servizi, quindi posta e
news. L'obiettivo è fare in modo di non dover più fare niente da mano di
quello di cui si deve occupare il pc a livello "server".
Con procmail in modalità daemon ho raggiunto perfettamente lo scopo, in
ip-up.local (ho una Redhat) ho messo:
su - utente1 -c "fetchmail -d 301"&
su - utente2 -c "fetchmail -d 303"&
e via così. E funziona tutto perfettamente, nel senso che fetchmail parte
in daemon mode per tutti gli utenti e fa il suo lavoro.
Il problema nasce nel momento nel quale mi disconnetto.
Io ho aggiunto in ip-down.local il quit:
su - utente1 -c "fetchmail -q"
su - utente2 -c "fetchamil -q"
...
ma non funziona. Cioè anche una volta che mi disconnetto, i fetchmail
restano demonizzati. Perché???? Se lancio il comando a mano, il processo
termina regolarmente. Quindi ip-down.local non viene letto... ma per quale
motivo?
Secondo problema, volevo ottenere qualcosa di simile concettualmente anche
per fetchnews.
Fetchnews non ha un daemon mode, quindi ho dovuto arrangiarmi. L'idea che
ho avuto è stata quella di mettere in crontab un richiamo che ogni 15
minuti lancia uno script.
Questo script controlla se c'è una connessione a internet. Solo se la
connessione è rilevata, lancia fetchnews, altrimenti no.
Problemino: su cosa basare il riconoscimento della connessione? Ho
parzialmente risolto con uno script di questo tipo:
if (ps -Af | grep -F -e pppd) && ! (ps -A | grep -F -e fetchnews)
then
play /usr/share/sound/iniziofetch.wav
/usr/local/sbin/fetchnews
play /usr/share/sound/finefetch.wav
fi
La cosa singolare è che questo script funziona per quanto riguarda il
fetchnews, ma non mi esegue i suoni!! I suoni sono corretti perché se da
consolle eseguo:
$ play /usr/share/sound/iniziofetch.wav
lo sento.
Ma quello che mi lascia perplesso, è il grep su pppd. Infatti, pppd è
attivo anche durante l'handshake, per cui pppd compare al ps -Af | grep,
ma di fatto non c'è ancora connessione.
Non che sia un grossissimo problema, tuttavia è formalmente scorretto per
cui mi chiedevo se si potesse fare qualcosa di più "elegante".
Eppoi perché ogni 15 minuti scarica le news, ma non mi suona i due wave??? 
Suggerimenti? Grazie.
-- 
Crononauta
==========
ICQ UIN: 4005815
IDAnet: 
http://adcserver1.biodip.unimi.it/ida/index.htm
GP Legends: 
http://www.multiplayer.it/driving/

wave???
Forse perche' l'output e' reindirizzato da un'altra parte ?
-- 
                                                                     __
 __                                                              _  ///
| _        Student in Computer Science, Swiss Federal Institute  \\///
|__|iambo      of Technology - mailto:
ggia...@iiic.ethz.ch
       \X/

Forse perche' l'output e' reindirizzato da un'altra parte ?
E dove potrebbe? E' uno script eseguibile che viene richiamato dal
crontab. Ogni 15 minuti viene eseguito quello script.
La cosa curiosa è che se lancio quello script da consolle, infatti, i
suoni si sentono!!!
Non riesco a spiegarmelo!


 cui mi chiedevo se si potesse fare qualcosa di più "elegante".
Dunque: pppd ha appunto il file ip-up (o nome simile) che
permette di far partire i programmi che si vuole quando
s'instaura il link. Si puo` benissimo fare un semplice script
che fa un backup del vecchio ip-up e ip-down, ne crea dei nuovi
con i comandi che si vuole, fa il collegamento che, una volta
stabilito, esegue i comandi di ip-up tra cui l'ultimo e` di
chiudere il link ppp. Poi un ip-down rimette a posto i
precedenti ip-up e ip-down. In questo modo si evita il problema
di cui dici.
Se invece si vuole tenere il link ppp attivo sempre o durante
il giorno o la notte o comunque per un certo numero di ore
basta che nell'ip-up si metta il nome di uno script che crea
un crontab che nel periodo in cui ppp e` attivo lancia i
programmi che si vuole ogni tot minuti. Quando il ppp si chiude
con ip-down si rimuove quel crontab (o, meglio, lo si rinomina
cosi` e` pronto per la prossima volta).
Ad ogni modo per controllare se pppd gira meglio affidarsi
all'esistenza del file *.pid in /var/run che contiene tra
l'altro anche il numero del processo (ottenibile sempre
comunque con pidof).
Quanto a fetchnews il consiglio e` quello di eseguirlo come
user news, quindi
su news -c /path/fetchnews.
-- 
Bye by Red  |  PCC on a FreeBSD box                  E-mail: 
rw...@mclink.it
            |---------------------------------------------------------------
            |  "Confusion will be my epitaph"
            |      (King Crimson)

su news -c /path/fetchnews.
Questa è un'ottima obiezione! Grazie! :-)


Eppoi perché ogni 15 minuti scarica le news, ma non mi suona i due wave??? 
forse perche' nel comando play non hai messo il percorso completo
/usr/bin/play /usr/share....wav
bye
-- 
     #@@@   missinglink on slackware 7 ###
     ####       member of telug        #@@
 

crontab.
Forse il cron non ha i diritti su /dev/audio :-)


Forse il cron non ha i diritti su /dev/audio :-)
yeah, questo l'ho finalmente capito! Io in crontab avviavo lo script con i
diritti di news, non di root. Ma news non ha il diritto di accesso a
/dev/audio (che motivo avrebbe???); ho rimediato facendo lanciare lo
script coi diritti di root, cosě l'accesso a /dev/audio č di root, e
funziona; poi avvio fetchnews con su - news e cosě viene avviato come
news (cosa migliore).


avviato come news (cosa migliore).
Almeno ti sono stato d'aiuto :-) ...


Almeno ti sono stato d'aiuto :-) ...
Sì, grazie! :-)


 Questa è un'ottima obiezione! Grazie! :-)
Prego.
-- 
Bye by Red  |  PCC on a FreeBSD box                  E-mail: 
rw...@mclink.it
            |---------------------------------------------------------------
            |  "I don't smile anymore, too many smiling faces lie"
            |      (Urge Overkill)

 che non usano shell di bash ma shell diverse.
E hai ragione, e' informativa, serve proprio a informare il sistema con
quale shell o intrerprete deve trattare lo script in questione. Solo che
essendoci in giro anche altri interpreti di script oltre la bash (mai
sentito parlare del perl?) non credo proprio siano cosi' rari.
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

quale shell o intrerprete deve trattare lo script in questione.
Quel che vorrei capire è che se scrivo:
#!/bin/bash
predomina # a inizio riga, che indica che tutto quel che segue è un
commento, e quindi va ignorato; oppure #! è una sintassi specifica per
indicare "adesso specifico la shell da usare"?
In sostanza #! è un comando di sistema o una normale remark?
Perché io in tutti gli script che ho fatto non l'ho mai messa ma hanno
sempre funzionato...
E' anche vero che uso esclusivamente shell di bash, quindi il problema
(nel mio caso) non dovrebbe comunque sussistere.


(nel mio caso) non dovrebbe comunque sussistere.
Quasi esatto, potresti aver bisogno di lanciarlo da qualcosa di diverso
dalla bash, non in modalita' interattiva, e in quel caso potrebbe essere
piuttosto importante.
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

perché di quella riga, all'inizio!
E' diverso: La riga comincia con "#" *e* con "!". Da "man bash":
       If the program is a file beginning with #!, the  remainder
       of  the  first  line specifies an interpreter for the pro-
       gram.  The shell executes  the  specified  interpreter  on
       operating  systems that do not handle this executable for-
       mat themselves.  The arguments to the interpreter  consist
       of  a  single  optional argument following the interpreter
       name on the first line of the  program,  followed  by  the
       name of the program, followed by the command arguments, if
       any.
Purtroppo  non   ho  nuove   idee  a  proposito   di  ip-down.local:
Probabilmente non viene neppure richiamato da ip-down (?) ...


 # e' un remark, #! no.
Diciamo che non lo e' all'inizio del file. Il #! e' il magic number per
dire che quel file e' uno script (il magic number sta all'inizio del
file, per cui se metti #! a meta' e' un remark) che deve essere eseguito
con la shell (o l'inteprete) indicata a seguire.


sempre funzionato...
Perche' erano script della shell che usi. Fai questa controprova: due
filettini, in uno ci metti:
    #!/usr/bin/perl
    print "Bravo!\n"
nell'altro solo la seconda riga:
    print "Bravo!\n"
Quindi li rendi eseguibili. Output del primo:
 
    Bravo!
output del secondo:
   ./
file.pl
: print: command not found
Il tutto, ovviamente, se hai perl installato.
 
Ciao.

shell diverse.
No, se "marchi" un file di testo (il tuo script) come eseguibile, la
shell cerchera` di eseguirlo via exec() ed e` quest'ultima a usare la
riga con "#!..." per richiamare l'interprete giusto (lo fa` anche
Solaris e probabilmente altri *nix)
Comunque la bash, se trova uno script senza "#!", lo considera roba sua
e se lo interpreta, e` per questo che ti funzionano lo stesso
Ciao
-- 
Fabio Cobianchi | 
fabi...@tiscalinet.it

ip-down.local ho messo la chiusura dei demoni di fetchmail con l'opzione
HO RISOLTO!!!
Come al solito, cercando di sistemare un'altra cosa, sono venuto a capo di
un'altra!! ;-)
La cosa era semplice e banale: ip-down era solo rw-r--r--!!!! =:-O
Ovvio che non andava!!! Aggiunti i permessi di eseguibilità ora
funziona!!!
Naturamente io che sono un fobico della sicurezza ho messo come permessi
rwxr-x--- root.root, non vedo perché lasciare l'accesso a others, quando i
vari ip-up/down vengono avviati coi diritti di root, ed è bene che solo il
sistema li gestisca...


Non sara` mica un banale problema di path?
No, è un problema che sono fesso!!!! Non avevo dato i diritti di
eseguibilità a ip-down.local, te lo credo che non partiva!!!!
=:-OOOOOO
