poftim /etc/cron.d/cron.5/fetchmail.cron ( at least parts of it )...
#!/bin/bash
random=`echo $RANDOM`
temp_file="/tmp/"${random}
cat << EOF > $temp_file
set postmaster "postmaster"
set bouncemail
set spambounce
set properties ""
poll mail.fx.ro via mail.fx.ro with proto POP3 and options uidl
user 'un_user' there with password '_o_parola_' is
'[EMAIL PROTECTED]' here
EOF
chmod 710 ${temp_file}
fetchmail -KN -f ${temp_file} 1>/dev/null 2>/dev/null
rm -rf ${temp_file}
si la tine poate merge. o recomandare a mea ar fi sa nu folosesti
fetchmail ca root. nu ai de ce. nu spun ca este insecure sau ceva dar
pur si simplu nu ai de ce. fetchmail nu face altceva decat sa se
conecteze la un imap/pop3/whatever si sa pipe-uiasca ce gaseste acolo
prin sendmail catre altundeva. ideea este ca chestia asta o poate face
oricine.
poti sa folosesti criptuletzul asa cum e sau poti sa il adaptezi sa iti
mearga cu normal user. eu am preferat sa tin rc-ul inside ca sa imi fie
usor sa il mut din stanga in dreapta daca urma sa mai am nevoie de el pe
altundeva.
On Sun, 2003-07-27 at 12:58, lonely wolf wrote:
> KobrAs wrote:
> > da
> > chown user.user /usr/bin/fetchmail
> > chmod +s /usr/bin/fetchmail
> > si va rula ca, user-ul de pe chown
> >=20
> no offense, asta nu e o idee buna. fetchmail ruleaza ca orice user fara=20
> greturi, nu trebuie suidat
>
>
> paul: vezi ce eroare da:
> - verifica daca intr-adevar PATH-ul trecut in rc.local e cel corect (un=20
> prim test simplu e sa rulezi rc.local din shell)
> - redirect output intr-un fisier (eventual pune in un wrapper in locul=20
> lui fetchmail, care sa log-eze inainte/dupa executia binarului; ceva e=20
> genul
> mv fetchmail fetchmail.bin;
> echo "#!/bin/bash
> echo "$1" >/tmp/log.fetchmail
> echo "/path/to/fetchmail.bin $1>> /path/to/fetchmail"
> echo "ce crezi ca e cazul sa verifici pe baza exit codes ale lui=20
> fetchmail, conform man page" >>/path/to/fetchmail
> chmod +x /path/to/fetchmail
> hint:
> The -L <filename> or --logfile <filename> option (keyword: set logfile)=20
> allows you to redirect status messages emitted while detached into a=20
> specified logfile (follow the option with the logfile name). The logfile=20
> is opened for append, so previous messages aren=92t deleted. This is=20
> primarily useful for debugging configurations.
>
> The --syslog option (keyword: set syslog) allows you to redirect status=20
> and error messages emitted to the syslog(3) system daemon if available.=20
> Messages are logged with an id of fetchmail, the facility LOG_MAIL, and=20
> priorities LOG_ERR, LOG_ALERT or LOG_INFO. This option is intended for=20
> logging status and error messages which indicate the status of the=20
> daemon and the results while fetching mail from the server(s). Error=20
> messages for command line options and parsing the .fetchmailrc file are=20
> still written to stderr, or to the specified log file. The --nosyslog=20
> option turns off use of syslog(3), assuming it=92s turned on in the=20
> ~/.fetchmailrc file, or that the -L or --logfile <file> option was used.
>
> )
>
> BTW, nu e asa ca stii ca daca nu ii dai argumentele in linia de comanda,=20
> TREBUIE sa ai parametri in ~/.fetchmailrc, sa stie si el ce servere sa=20
> interogheze, cu ce user, etc ?
>
> citez din manual:
> The behavior of fetchmail is controlled by command-line options and a=20
> run control file, ~/.fetchmailrc, the syntax of which we describe in a=20
> later section (this file is what the fetchmailconf program edits).=20
> Command-line options override ~/.fetchmailrc declarations.
>
> Each server name that you specify following the options on the command=20
> line will be queried. If you don=92t specify any servers on the command=20
> line, each =91poll=92 entry in your ~/.fetchmailrc file will be queried.
>
> --=20
> Computers are devices for converting data into error messages
>
>
>
