Příspěvky

46

Software / Nefunkční rsync a SSH při připojení přes cron

« kdy: 21. 09. 2017, 12:20:23 »

Ahoj,
udelal jsem si skriptík pro zálohu pomocí rsync a SSH. Veřejný klíč je v authorized_keys na protější straně (ssh server přes Cygwin na win 10). Když skript spustím manuálně přes terminál, SSH se automaticky připojí a vše funguje jak má. Když skript zavolá cron, nepřipojí se.
Skript:

Kód: [Vybrat]

#!/bin/sh
zaloha=den 
DATE=`date "+%Y.%m.%d_%H:%M:%S"`
log=/home/dada/.a/User_rs/log/${DATE}_${zaloha}.log
exec 3>&1 1>>${log} 2>&1
rsync -avv -e 'ssh -p 6665' --delete-during --force --progress --exclude '/User/Desktop/Knihovny' User@95.245.241.111:/cygdrive/c/Users/User  /mnt/Zaloha_User/Dell_${zaloha} | tee /dev/fd/3

Vypis z logu:

Kód: [Vybrat]

tee: /dev/fd/3: Operace zamítnuta
opening connection using: ssh -p 6665 -l User 95.245.241.111 rsync --server --sender -vvlogDtpre.iLsfx . /cygdrive/c/Users/User  (12 args)
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.1]

Ani upravení přístupu k .ssh protějšku nepomohlo:

Kód: [Vybrat]

chmod -R 777 .ssh

Kde dělám chybu? Dík za pomoc

47

Software / Re:Podmínka přítomnosti zdroje před startem zálohy s rdiff-backup

« kdy: 11. 09. 2017, 14:05:57 »

Ahoj, tak křest s Cygwin je za mnou. Ano, opravdu to tak chodí. Ale rychlost ... se sambou připojenou přes Autofs to chodilo tak 40-60MB/s (kde to limituje CPU,Soft-RAID6 +LVM+ LUKS) přes ssh to jede tak okolo 16MB/s bez většího zatížení.
Zbytečná práce to ale nebyla, stejně jsem řešil i zálohy přes internet ale v rámci LAN mi připadá lepší moje prvotní myšlenka.
Zkoušel jsem podmínku existenci složky, souboru, mountpointu ale když je zdroj nedostupný, příkazy to nerozdýchají jako samotný rdiff

48

Software / Re:Unison „realtime sync“ nejde spustit jako služba

« kdy: 08. 09. 2017, 09:22:30 »

AAAAA, něco takového jsem tušil. Valím studovat. Děkuji moc

49

Software / Re:Unison „realtime sync“ nejde spustit jako služba

« kdy: 08. 09. 2017, 08:05:39 »

Ahoj, kofigurák share.prf nikde nefiguruje, žádný takový jsem nevytvářel a ani ho nechci volat. V home/user/.unison mam své tři *.prf. share.prf figuruje v ukázce, podle které jsem to stavěl, vis odkaz v prvním příspěvku. Ale nevidím proč ho unison volá, myslel jsem že je to nějaky deafult, když nemůže najít jiné.

50

Software / Re:Unison „realtime sync“ nejde spustit jako služba

« kdy: 07. 09. 2017, 21:34:21 »

Ahoj, zde je výpis z syslogu:

Kód: [Vybrat]

Sep  7 21:18:30 NOTE systemd[2394]: unison@share.service: Service hold-off time over, scheduling restart.
Sep  7 21:18:30 NOTE systemd[2394]: Stopped Unison.
Sep  7 21:18:30 NOTE systemd[2394]: Started Unison.
Sep  7 21:18:30 NOTE unison[5756]: Usage: unison [options]
Sep  7 21:18:30 NOTE unison[5756]:     or unison root1 root2 [options]
Sep  7 21:18:30 NOTE unison[5756]:     or unison profilename [options]
Sep  7 21:18:30 NOTE unison[5756]: For a list of options, type "unison -help".
Sep  7 21:18:30 NOTE unison[5756]: For a tutorial on basic usage, type "unison -doc tutorial".
Sep  7 21:18:30 NOTE unison[5756]: For other documentation, type "unison -doc topics".
Sep  7 21:18:30 NOTE unison[5756]: Profile /home/pokus/.unison/share.prf does not exist
Sep  7 21:18:30 NOTE systemd[2394]: unison@share.service: Main process exited, code=exited, status=1/FAILURE
Sep  7 21:18:30 NOTE systemd[2394]: unison@share.service: Unit entered failed state.
Sep  7 21:18:30 NOTE systemd[2394]: unison@share.service: Failed with result 'exit-code'.

Když spustím, příkaz z ~/.config/systemd/user/unison@.service ručně v terminálu:

Kód: [Vybrat]

doga@NOTE:~$ /usr/local/bin/unison %i
Usage: unison [options]
    or unison root1 root2 [options]
    or unison profilename [options]

For a list of options, type "unison -help".
For a tutorial on basic usage, type "unison -doc tutorial".
For other documentation, type "unison -doc topics".

Profile /home/pokus/.unison/%i.prf does not exist

Takže to s parametrem %i nemůže najít konfigurační soubory.

51

Software / Re:Unison "realtime sync" nejde spustit jako služba

« kdy: 06. 09. 2017, 12:21:37 »

Ahoj,
tak to dělá ten "zástup" %i v unison@.service. Když ho nahradím konkrétním názvem konfiguračního souboru *.prf, tak to běhá. Jde to zapsat jinak nebo musím pro každy *.prf udělat zvlášť službu?

52

Software / Re:Unison "realtime sync" nejde spustit jako služba

« kdy: 06. 09. 2017, 10:58:30 »

Kde muže být chyba?

U Lennarta, ale to se nesmí říkat.

S PulseAudio se taky trápím Dík za rozšíření obzoru takže existuje jiný způsob?

53

Software / Unison „realtime sync“ nejde spustit jako služba

« kdy: 06. 09. 2017, 10:25:53 »

Ahoj,
nedávno mi zde na fóru někdo poradil při použití unison parametr repeat = watch, super Odinstaloval jsem stavajicí Unison a dle návodu:   https://l0x.de/posts/2016/11/17/dropbox-like-realtime-sync-unison/ jsem udělal následující:

Kód: [Vybrat]

sudo apt-get install ocaml python-pyinotify
sudo apt-get install subversion
svn co https://webdav.seas.upenn.edu/svn/unison/branches/2.48 unison
cd unison
make NATIVE=false UISTYLE=text
sudo cp src/{unison,fsmonitor.py} /usr/local/bin

upravil configurační soubor

Kód: [Vybrat]

# Unison preferences
root = /home/pokus/Plocha
root = /mnt/NFS/pokus/Plocha
auto=true
batch=true
ignore = Name {.Trash}
repeat = watch

vytvořil soubor ~/.config/systemd/user/unison@.service:

Kód: [Vybrat]

[Unit]
Description=Unison

[Service]
Environment="PATH=/usr/local/bin:/usr/bin"
ExecStart=/usr/local/bin/unison %i
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

spustil službu

Kód: [Vybrat]

systemctl --user start unison@share

ale při

Kód: [Vybrat]

systemctl --user status unison@share

mi to vypisuje chybu

Kód: [Vybrat]

● unison@share.service - Unison
   Loaded: loaded (/home/doga/.config/systemd/user/unison@.service; disabled; ve
   Active: activating (auto-restart) (Result: exit-code) since St 2017-09-06 09:
  Process: 21784 ExecStart=/usr/local/bin/unison %i (code=exited, status=1/FAILU
 Main PID: 21784 (code=exited, status=1/FAILURE)

zář 06 09:59:58 STA systemd[2034]: unison@share.service: Main process exited, co
zář 06 09:59:58 STA systemd[2034]: unison@share.service: Unit entered failed sta
zář 06 09:59:58 STA systemd[2034]: unison@share.service: Failed with result 'exi

Při manuálním spuštění

Kód: [Vybrat]

unison Desk

to funguje jak má.
Kde muže být chyba? Dík za pomoc

54

Software / Re:Podmínka přítomnosti zdroje před startem zálohy s rdiff-backup

« kdy: 05. 09. 2017, 15:10:06 »

Tak mohl byste treba otestovat existenci nejakeho souboru. Nicmene nebylo by lepsi hodit na Widle minimalni Cygwin a delat zalohy proti ssh? Rdiff-backup to snad umi a ta zaloha zmen by se tim o dost zkratila.

Ahoj, jestli jsem to správně pochopil, tak na Win dát Cygwin s ssh serverem a s rdiff-backupem a pak se vzdáleně připojovat?

55

Software / Re:Chyba při zálohování s rdiff-backup

« kdy: 04. 09. 2017, 10:32:16 »

Řešení nemám, ale jen bych chtěl vyjádřit soustrast s používáním rdiff-backup. Podobných divných chyb je tam celá řada. Sám jsem ho používal na různé účely a tak jednou za půl roku, za rok se stala podobná chyba (ne přímo tahle, ale podobné). Zejména když člověk přeruší zálohu (třeba protože vidí, že zálohuje něco, co nechce), je riziko maléru skoro 50 na 50. Řešení jsem pokaždé hledal, ale neexistovalo (kromě „smaž všechny zálohy a začni znovu“). Software už je to neudržovaný a kvůli tomuhle dost o nervy.

Nakonec jsem skončil s tím, že zálohuju na btrfs a přírůstky dělám snapshotama. Jediná nevýhoda oproti rdiff-backup je ta, že to má nekomprimované přírůstky, ale většinou u těch přírůstků stejně není moc komprimovat, takže mě to tak nepálí (btrfs sám o sobě komprimovaný je). Naopak výhod to má celou řadu, od bezproblémového běhu, po velice snadné procházení záloh včetně selektivního promazávání i jednoho souboru, i jedné zálohy uprostřed apod.

Rdiff-backup už nikdy více! (sorry za zaplevelování vlákna)

Naopak, děkuji za názor. Tyhle "nešvary" mi drásají nervy a přináší neklid, možná je na čase se zamyslet nad jiným směrem

56

Software / Podmínka přítomnosti zdroje před startem zálohy s rdiff-backup

« kdy: 04. 09. 2017, 10:27:06 »

Ahoj,
pomocí rdiff-backup zálohuji pracovní stanici s Windows 7, kterou mám přes autofs-cifs připojenou v Ubuntu Mate. Zjistil jsem, že rdiff-backup nerozdýchá, že nemá zdroj a doposud vytvořené zálohy poškodí tak, že nejdou vytvářet další, vis:https://forum.root.cz/index.php?topic=16208.0.
Proto bych potřeboval ve skriptu podmínku přítomnosti zdroje. Něco jsem se snažil vytvořit ale nefunguje to:

Kód: [Vybrat]

#!/bin/sh
if [ -d "/mnt/NFS/Mix/Fotky" ]; then
	rdiff-backup --print-statistics --terminal-verbosity 2 \
    --exclude-globbing-filelist /home/pokus/.skript/pokus_rdiff_exclude \
    --include-globbing-filelist /home/pokus/.skript/pokus_rdiff_include \
    --exclude / / /mnt/NFS/Filmy/cil
	rdiff-backup --remove-older-than 30D --terminal-verbosity 2 --force /mnt/NFS/Filmy/cil
fi
exit

pokus_rdiff_include:

Kód: [Vybrat]

/mnt/NFS/Mix/Fotky

Místo samby to tu zkouším z NFS ale princip by měl být asi stejný.
Nějaký nápad jak to zprovoznit nebo dokonce jiný způsob jak podmínit přítomnost zdroje před během zálohy?
Dík za nápady

57

Software / Chyba při zálohování s rdiff-backup

« kdy: 04. 09. 2017, 09:38:31 »

Ahoj,
rdiff-backup mi vyhodil tuto chybu:

Kód: [Vybrat]

Previous backup seems to have failed, regressing destination now.
Exception 'CRC check failed 0xd254c440 != 0x57f339eeL' raised of class '<type 'exceptions.IOError'>':
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/robust.py", line 32, in check_common_error
    try: return function(*args)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/restore.py", line 462, in get_fp
    current_fp = self.get_first_fp()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/restore.py", line 499, in get_first_fp
    rpath.copyfileobj(fp, current_fp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 62, in copyfileobj
    inbuf = inputfp.read(blocksize)
  File "/usr/lib/python2.7/gzip.py", line 268, in read
    self._read(readsize)
  File "/usr/lib/python2.7/gzip.py", line 332, in _read
    self._read_eof()
  File "/usr/lib/python2.7/gzip.py", line 354, in _read_eof
    hex(self.crc)))

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 30, in <module>
    rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in error_check_Main
    try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in Main
    take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 280, in take_action
    elif action == "backup": Backup(rps[0], rps[1])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 337, in Backup
    backup_final_init(rpout)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 501, in backup_final_init
    checkdest_if_necessary(rpout)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 920, in checkdest_if_necessary
    dest_rp.conn.regress.Regress(dest_rp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71, in Regress
    for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281, in __call__
    last_branch.fast_process(*args)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 268, in fast_process
    if rf.metadata_rorp.isreg(): self.restore_orig_regfile(rf)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 290, in restore_orig_regfile
    tf.write_from_fileobj(rf.get_restore_fp())
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/restore.py", line 488, in get_restore_fp
    return robust.check_common_error(error_handler, get_fp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/robust.py", line 32, in check_common_error
    try: return function(*args)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/restore.py", line 462, in get_fp
    current_fp = self.get_first_fp()
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/restore.py", line 499, in get_first_fp
    rpath.copyfileobj(fp, current_fp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 62, in copyfileobj
    inbuf = inputfp.read(blocksize)
  File "/usr/lib/python2.7/gzip.py", line 268, in read
    self._read(readsize)
  File "/usr/lib/python2.7/gzip.py", line 332, in _read
    self._read_eof()
  File "/usr/lib/python2.7/gzip.py", line 354, in _read_eof
    hex(self.crc)))
IOError: CRC check failed 0xd254c440 != 0x57f339eeL

Už se mi to stalo podruhé, poprvé se zaplnil cílový disk a teď jsem zkoušel, jak se rdiff-backup zachová, když bude zálohovaná stanice s Win7 připojená přes autofs - cifs nedostupná, po dvou dnech běhu jsem rdiff-backup ukončil.
Poprvé mi pomohlo až kompletní smazání dosavadních záloh a začít znovu od začátku, což je krajní a v podstatě nepoužitelné řešení
Měl jsem za to, že se rdiff-backup po nekorektně dokončené záloze vrátí k poslední dokončené.
Je nějaký způsob jak to opravit?
Děkuji za pomoc

58

Software / Re:Nefunkční CRON

« kdy: 18. 08. 2017, 22:49:57 »

Ručně přes terminál ji asi spouštíte pod nějakým uživatelem, který má uložen SSH klíč nebo spuštěného SSH agenta. Z cronu to předpokládám spouštíte ze systémového cronu, tedy pod uživatelem root. Pokud to nemusí běžet pod rootem, nakonfigurujte to raději pro toho uživatele, pod kterým to spouštíte z terminálu – crontab -e spuštěné pod daným uživatelem vám spustí editor s crontab souborem pro daného uživatele.

Ahoj, cron i terminal to spouští pod uživatelem a do mých experimentů to bezchybně fungovalo Jiný nápad? Dík

59

Software / Re:Nefunkční CRON

« kdy: 11. 08. 2017, 21:10:12 »

Důvod byste se dozvěděl právě v tom logu. Tak to místo do /dev/null aspoň přesměrujte do nějakého souboru, ať se můžete podívat, co vám vlastně vypisuje.

Dobrý nápad, toto je výsledek:

Kód: [Vybrat]

Contacting server...
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
Fatal error: Lost connection with the server

Když úlohu unison pustím ručně přes terminál, úloha proběhne ale když jí zavolá cron, nemůže se unison připojit na SSH.

Souhlasím. Pokud máte v distribuci msmtp, nainstalujte ho a nakonfigurujte (a nebo budete mít v distribuci něco podobného). Posílání e-mailů při chybě je běžná věc a dost to pomáhá při řešení problémů.

Díky, už se snažím msmtp nakonfigurovat.

60

Software / Re:Nefunkční CRON

« kdy: 10. 08. 2017, 12:23:33 »

Máte cron nakonfigurovaný tak, aby v případě chyby odesílal e-maily pomocí programu sendmail. Binárku sendmail tam zajišťuje Postfix, který není nakonfigurovaný. Chyb je tam několik – za prvé tam máte zbytečně nainstalovaný Postfix, který asi nechcete používat – takže byste jej měl odinstalovat. Za druhé vám ta úloha cronu vypisuje něco na standardní nebo chybový výstup, to se vám cron pokouší poslat e-mailem – to už vám napsali jiní. Za třetí, to, co se pokoušíte dělat s Unisonem, je opravdu divné, a pokud např. jedno spuštění bude trvat déle a celý proces se spustí souběžně dvakrát, vůbec bych se nedivil, pokud by došlo k poškození souborů. Pro průběžnou synchronizaci má Unison volbu -repeat.

Ahoj,
postfix jsem již odinstaloval a do cronu přidal:

Kód: [Vybrat]

1-59/2 * * * * /usr/bin/unison Desk>/dev/null 2>&1

ale stále unison nejede. V logu:

Kód: [Vybrat]

NOTE CRON[13872]: (doga) CMD (/usr/bin/unison Desk>/dev/null 2>&1)

O parametru -repeat jsem nevěděl, dík, podívám se na něj.
Jak by šlo cron nakonfigurivat aby přestal posílat maily? Už si za boha nemůžu vzpomenout, jak se mi to podařilo zapnout.
Dík