Azi mi-am stors creierii sa aflu de ce un script merge OK rulat din CLI dar din cron nu.
Scriptul meu facea niste operatii, dupa aia apela un script de expect care rula un scp si tot asa. Anyway, important era sa mearga scp-ul ala si sa mute un fisier dintr-o parte in alta.
Din CLI mergea de n-avea aer:
spawn scp $fisier user@server:/locatie expect "Password:" send "parola\r"
Din cron crapa cand cerea scp parola in mod subit.
Dupa dat cu capu de masa si de servere si un pic de cautat pe interneti am gasit varianta salvatoare:
spawn scp $fisier user@server:/locatie expect "Password:" send "parola\r" expect 100% sleep 5 exit
Banuiala mea e ca din cauza ca atunci cand ruleaza din cron n-are terminal, scp nu poa sa scrie pe undeva progresul de copiere si atunci moare dar fara sa chitaie de eroare, in schimb daca ii dau cu expect 100%, atunci cumva scrie intr-un fel de buffer al lui expect si nu se mai strica jucaria.
Asta din categoria cu ce-mi mai ocup eu timpul in ultima vreme: fac Frankensteini din bash, expect, sed, awk, python, perl si ce mai am pe la indemana :)
Cred ca problema se rezolva mai elegant daca rulai scp ala cu ceva parametri (poate -q ?) care sa-l faca sa se comporte la fel si interactiv si neinteractiv. Asta cu comportamentul diferit al anumitor programe cand vad ca au terminal si prezenta variabilelor de mediu setate din bashrc (gen PATH) sunt principalele pitfalls la probleme cu scripturi care merg din consola dar nu din cron.
Am facut probe, nici cu -q nu vrea si nici sa zica ce-l doare cu “log_user 1” cum mi-a mai zic Cioby pe FB sa incerc.
Am patit si eu ceva asemanator. Am pus “set -x” si initial am redirectat in cron output-ul script-ului intr-un fisier, dar n-am vazut mare lucru. Apoi am adaugat 2>&1 si am vazut la fel cum vedeam in consola. Si asa m-am lamurit ca trebuia “/sbin/ifup” in loc de “ifup”.
Dupa care aveam o linie cu “/etc/init.d/openvpn start”. Aici plangea ca nu stie cine e start-stop-daemon. Asa ca am pus PATH=blabla explicit in crontab. Tot n-a mers. In final, am rezolvat punand PATH=bla explicit in script-ul pe care-l rulam din crontab si n-a mai comentat.
Iar pentru completitudine tehnica sa adaugam urmatoarele:
1) A stoca credentiale (de orice natura) in scripturi e ca si cum ai implora sa fii impuscat in picior
2) A incerca sa imiti comportamentul uman atunci cand sistemul in cauza are un mod automat sau o interfata programatica, iarasi, e ca si cum ai implora sa fii impuscat in picior (hint: public key authentication)
3) In general, in lumea UNIX, s-au cam inventat toate rotile posibile (hint: rsync peste ssh)
Ca o paranteza la acest punct, desi inteleg care a fost intentia celui ce l-a inventat pe scp, in experienta mea personala mereu am avut nevoie de ceva (putin) mai mult decat o simpla copie asa ca mereu am folosit ssh cu forced-command. Fie direct, ca in “tar jcf – /drum/catre/sursa | ssh -e none cont@masina ‘cat > /drum/catre/destinatie.tar.bz2′”, fie indirect ca transport autentificat si criptat pentru ceva mai inteligent ca rsync, svn, git etc.
4) Cum zicea un mare clasic intr-un film de referinta: “assumption is the mother of all fuckups”. Nu presupune ca exista un TTY, nu presupune ca PATH o sa aiba o valoare anume, nu presupune ca HOME va fi setat, nu presupune ca ce scrii se executa sub Bash doar pentru ca shell-ul tau e Bash si lista ar putea continua ad infinitum :-)
Fac scp catre un sistem care doar asa ma lasa. Nu vrea cheie publica instalata pe motiv de “support voided” daca il manaresc cumva. Restul de chestii le-am abuzat cat am putut sa indeplinesc “obiectivul” :)
A, nu mi-a picat fisa ca e vorba de parola de ssh, acolo problema e ca ssh saracul chiar se straduie ca ala sa fie un terminal proper. Pentru amarati de-astia ca tine care nu au cum sa se dea cu chei exista sshpass https://tracker.debian.org/pkg/sshpass (dadeam link la homepage dar e pe sourceforge).
Lasa-ma sa ghicesc, ceva institutie financiara ;) (si eu am avut aceeasi problema cu unii care ar trebui sa stie mai bine).
Ceva de genul ;)
Auzisem de sshpass dar eram convins ca vine cu openssh-{server,client} si nu l-am gasit si am zis ca poate e din cauza de distro vechi si ca asta e, trebuie gasita alta solutie.