Commando via Crontab werkt niet, console wel

[smeerbartje]

Ik wil het volgende commando elke dag draaien, dus @daily in crontab.

code:

/bin/cp /smb/dropbox/Apps/Keepass/Keepass.kdbx /smb/share/backup/Keepass.`date +%Y.%m.%d`.kdbx

Als ik dit vanaf de console draai, dan wordt het copy commando netjes uitgevoerd. Echter vanuit Cronacle lukt dit niet. Ligt het aan dat date element wat erin zit? Ik krijg het maar niet voor elkaar . Wie o wie?

[Verwijderd]

En wat zeggen je logs?

[smeerbartje]

Fuck!! stom stom stom... was even case-sensitivity vergeten. Vandaar dat ik niks vond in /var/logs/. Het ligt dus inderdaad aan die date. Maar hoe fix ik dat? Zou het pad naar date ook expliciet opgegeven moeten worden?

code:

syslog.1:Aug 24 00:00:01 server CRON[9589]: (ik) CMD (/bin/cp /smb/dropbox/Apps/Keepass/Keepass.kdbx /smb/share/backup/Keepass.`date +)

[edit]
Volgens mij heb ik het: man crontab geeft het volgende:

code:

The sixth field of a line in a crontab file is a string that is executed  by the shell
at the specified times. A percent character in this field (unless escaped by \) is 
translated to a NEWLINE character.

Ofwel ff proberen met escape.

[ Voor 30% gewijzigd door smeerbartje op 24-08-2013 09:49 ]

[MdBruin]

Ik had hetzelfde probleem maar zover ik heb terug kunnen vinden wordt het door de automatische datum string (eigenlijk het % teken )veroorzaakt.
De oplossing hiervoor is door een script te laten aanroepen door crontab.

Bijv.
keepass_backup.sh
cp /smb/dropbox/Apps/Keepass/Keepass.kdbx /smb/share/backup/Keepass.`date +%Y.%m.%d`.kdbx

Deze uitvoerbaar maken door chmod +x keepass_backup.sh
Dan kan je in je crontab het script laten uitvoeren

[smeerbartje]

Kan inderdaad ook; echter escapen werkt ook. M'n crontab ziet er nu zo uit:

code:

@daily               /bin/cp /smb/dropbox/Apps/Keepass/Keepass.kdbx /smb/share/backup/Keepass.`date +\%Y.\%m.\%d`.kdbx

Dit werkt.

[Verwijderd]

Toch wil ik afraden om dat zo te doen. En ik wil ook afraden het commando in een one-line scriptje neer te zetten. Bij dit soort zaken doe je er goed aan om een paar gewoontes aan te leren.

1: alles escapen wat nodig en/of nuttig is
2: maak sommige zaken configureerbaar, en je script derhalve leesbaar
3: gebruik umask
4: gebruik nooit backtick quotes ` maar altijd $( en ) want die zijn nog te nesten ook
5: gebruik altijd ${ en } rond variabelen, dat werkt altijd

Hoe ik dit simpele scriptje zou schrijven is als volgt:

Bash:

#! /bin/sh -e

umask 0377

PATH="/usr/bin:/bin"
SOURCE="/smb/dropbox/Apps/Keepass/Keepass.kdbx"
TARGET="/smb/share/backup/Keepass.$(date '+%Y.%m.%d').kdbx"

cp "${SOURCE}" "${TARGET}"

Absolute paden is goed, relatieve paden ook zolang je maar expliciet je PATH set.

[Rainmaker]

offtopic:
Er hoort geen spatie tussen de shebang en de interpreter.

[Hero of Time]

Cheatah, kan je de noodzaak voor umask eens uitleggen?

[smeerbartje]

Thanks allen! Leerzaam dit.. ben ook benieuwd naar reden voor gebruik umask.

[Verwijderd]

Een script als deze hoeft geen files te maken die executable of writable zijn. De uiteindelijke file mode die ik vooe een backupbestand wil hebben is in het algemeen 0400, dus alleen lezen, en dan ook nog eens alleen voor de user zelf. Als je dit naar een gesharede backupdirectory zet is een foutje met bestandsrechten zo gemaakt.

Rainmaker schreef op zondag 25 augustus 2013 @ 11:35:
Er hoort geen spatie tussen de shebang en de interpreter.

Dit heeft niets met "horen" te maken of niet. Het werkt gewoon (en heeft altijd al gewerkt) en ik vind het duidelijker, dus gebruik ik het altijd op deze manier.

[MdBruin]

Misschien wordt dit gezien als topic kapen, maar dat is niet mijn bedoeling. Mogelijk dat de TS hieruit ook wat kan leren

Als ik dus het goed begrijp zou je dus een mysql dump zo kunnen laten uitvoeren

Bash:

#! /bin/sh -e

umask 0400

PATH="/usr/bin:/bin"
USER="username"
PASSWD="password"
DATABASE="database name"
TARGET="/home/username/backup/databasename_$(date '+%y-%m-%d').mysql.gz"

mysqldump -u "${USER}" -p"${PASSWD}" "${DATABASE}" | gzip -c > "${TARGET}"

[BrZ]

Ja, behalve dan dat die umask niet is wat je wil, en ik zou altijd %Y in een filename gebruiken ipv %y. En dan kan je ook die hele date weergave veranderen in %F

[vanaalten]

MdBruin schreef op zondag 25 augustus 2013 @ 12:42:
Misschien wordt dit gezien als topic kapen, maar dat is niet mijn bedoeling. Mogelijk dat de TS hieruit ook wat kan leren

Als ik dus het goed begrijp zou je dus een mysql dump zo kunnen laten uitvoeren

Bash:

#! /bin/sh -e

umask 0400
...

Volgens mij klopt het wat je gescript hebt, behalve die umask. Het getal geeft alle bits aan die NIET gezet mogen worden bij het maken van een nieuwe file. Als je dus wil dat niemand toegang heeft behalve jijzelf (en voor jezelf alleen read-toegang wil geven), dan moet je precies het geinverteerde doen: 0377 dus.

Met 0400 heeft iedereen read&write toegang behalve jijzelf; jij hebt alleen write-toegang.

Voorbeeldje:

code:

vanaalten@vanaalten:~ $ touch test1.txt
vanaalten@vanaalten:~ $ umask 0400
vanaalten@vanaalten:~ $ touch test2.txt
vanaalten@vanaalten:~ $ umask 0377
vanaalten@vanaalten:~ $ touch test3.txt
vanaalten@vanaalten:~ $ ls -l test*
-rw-r--r-- 1 vanaalten vanaalten 0 Aug 25 13:21 test1.txt
--w-rw-rw- 1 vanaalten vanaalten 0 Aug 25 13:22 test2.txt
-r-------- 1 vanaalten vanaalten 0 Aug 25 13:23 test3.txt

[MdBruin]

Na de opmerkingen van BrZ en vanaalten zou het dus het volgende worden

Bash:

#! /bin/sh -e

umask 0377

PATH="/usr/bin:/bin"
USER="username"
PASSWD="password"
DATABASE="database name"
TARGET="/home/username/backup/databasename_$(date '+%Y-%M-%D').mysql.gz"

mysqldump -u "${USER}" -p"${PASSWD}" "${DATABASE}" | gzip -c > "${TARGET}"

Moet toch maar eens bash scripting gaan leren, heb al een uitgebreide gevonden:
http://www.tldp.org/LDP/abs/abs-guide.pdf
Of als iemand nog een betere sugestie heeft (lig nu toch maar op bed te herstellen van een zware hersenschuddig )

[Verwijderd]

Geen username en passwords in je scripts zetten, maar in ~/.my.cnf (en die chmodden naar 0600) bijvoorbeeld.

Waarom? Omdat bijvoorbeeld de volledige command line van draaiende processen door andere gebruikers gezien kan worden.

[Hero of Time]

Verwijderd schreef op zondag 25 augustus 2013 @ 12:13:
Een script als deze hoeft geen files te maken die executable of writable zijn. De uiteindelijke file mode die ik vooe een backupbestand wil hebben is in het algemeen 0400, dus alleen lezen, en dan ook nog eens alleen voor de user zelf. Als je dit naar een gesharede backupdirectory zet is een foutje met bestandsrechten zo gemaakt.

Ok, dat klinkt logisch. Maar het zal daarna niets helpen bij de TS, omdat hij met een Samba share werkt, en die doet niet aan umask aan de client kant. Dat wordt gezet tijdens mounten, erna kan je 't niet meer veranderen. Als je een goede umask wilt over een samba share, moet je dat in smb.conf opgeven.

Maar we gaan nu te ver door. het ging erom dat een commando via cron niet werkte, maar handmatig wel en dat bleek te komen door missende character escaping en interpretatie van cron.

Als je 't verder wilt hebben over dingen scripten voor cron en umask toepassen e.d. zal dat in een nieuw topic moeten.

[Verwijderd]

Klopt. Mijn belangrijkste punt was dat je je crontab zo schoon mogelijk moet houden.

[smeerbartje]

Topicstarter heeft het in dit geval over een home servertje dat gewoon ff elke dag een backupje moet draaien. Topicstarter heeft ook geen ambities om professioneel bash / sysadmin-werk te gaan doen . Toch bedankt allemaal.

[deadinspace]

Rainmaker schreef op zondag 25 augustus 2013 @ 11:35:
Er hoort geen spatie tussen de shebang en de interpreter.

Als je het niet erg vindt dan geloof ik liever Dennis Ritchie

... To take advantage of this wonderful opportunity, put #! /bin/sh at the left margin of the first line of your shell scripts. Blanks after ! are OK. Use a complete pathname (no search is done)...

(zelf gebruik ik altijd een spatie omdat ik dat leesbaarder vind, maar dat is natuurlijk een kwestie van smaak)

[sam.vimes]

Verwijderd schreef op zondag 25 augustus 2013 @ 10:13:
4: gebruik nooit backtick quotes ` maar altijd $( en ) want die zijn nog te nesten ook
...

code:

#! /bin/sh -e

Dat werkt alleen in ksh en bash en niet als je shell strikt bourne-shell (POSIX 1003.2, 1003.2a) compatible is. De Bourne-shell kent $(...) niet. Ik heb al verschillende bugmeldingen verstuurd omdat scripts ervan uitgaan dat /bin/sh bash-compatble is. Als je syntax-kleuring in vim gebruikt, zie je dat de $( met een rode achtergrond als syntaxfout gemarkeerd wordt.

Bash:

#!/bin/sh
x=$(...)

5: gebruik altijd ${ en } rond variabelen, dat werkt altijd

Persoonlijk vind ik dat van een overmatig gebruik van accolades scripts minder goed leesbaar maakt. De regels wanneer je accolades mag weglaten zijn eenvoudig te onthouden maar zijn wel toepasbaar bij de meeste gevallen van eenvoudige variabelensubstitutie, wat een hoop typwerk scheelt.

code:

#! /bin/sh -e

Weet je dat in het geval van de sh-optie -e een eventuele trap ... EXIT niet wordt uitgevoerd als er een fout optreedt? Daarom begin ik zelf altijd mijn scripts als volgt:

Bash:

#!/bin/sh
trap exit ERR

FWIW, alle enkele en dubbele quotes in de assignments zijn hier overbodig:

code:

PATH="/usr/bin:/bin"
SOURCE="/smb/dropbox/Apps/Keepass/Keepass.kdbx"
TARGET="/smb/share/backup/Keepass.$(date '+%Y.%m.%d').kdbx"

cp "${SOURCE}" "${TARGET}"

Wat ik in je voorbeeld wel toejuich, is het gebruik van dubbele quotes waar variabelensubstitutie voor ongewenste spaties zou kunnen zorgen.