Rsync en mounten van smb share

[roelke]

ik wil mijn data backuppen naar een NAS.
dit wil ik gaan doen via Rsync, alleen kan Rsync niet backuppen naar een netwerklocatie.
Nu lees ik op internet dat ik hem moet mounten, dit gaat opzich goed maar daarvoor heb ik root rechten nodig.
En gezien het feit ik het automatisch wil doen is het niet erg handig om elke keer mijn wachtwoord te moeten ingeven.

nu heb ik al een tijdje zitten googlen, maar ik heb nergens iets gevonden om een smb share te mounten zonder root rechten.
iemand een idee hoe dat wel kan ?

het betreft fedora 11

[DeTeraarist]

schijf toevoegen aan fstab met de opties noauto en user
door noauto mount hij niet automatisch tijdens de boot en user geeft aan dat iedere user de schijf kan mounten.

[Sallin]

Is er een speciale reden dat je de samba schijf niet altijd wilt mounten? Anders het volgende toevoegen aan je /etc/fstab:

code:

//netwerklocatie/schijf /media/mounthier cifs user=****,passwd=****,iocharset=utf8,file_mode=0777,dir_mode=0777    0    0

Let wel op jouw gewenste permissies.

[ Voor 6% gewijzigd door Sallin op 07-08-2009 21:13 ]

[roelke]

fstab ken ik, maar ik denk (zal het voor de zekerheid testen) dat de NAS wordt wakkergemaakt tijdens het mounten.
en dat wil ik niet, want dat betekend dat bij iedere boot de schijven van de NAS opspinnen.

[DeTeraarist]

Daarom "noauto" voor het niet automatisch mounten bij booten.

[Rainmaker]

Als je je user / pass van de SMB mount zelf nog wil afschermen, zou je eventueel ook een credentials file kunnen gebruiken die je ergens in /root zet.

Hierdoor kunnen "normale" gebruikers op het systeem je user / pass van de NAS niet zien.

[autostatic]

roelke schreef op vrijdag 07 augustus 2009 @ 21:04:
dit wil ik gaan doen via Rsync, alleen kan Rsync niet backuppen naar een netwerklocatie.

uit de man page van rsync:

There are two different ways for rsync to contact a remote system:
using a remote-shell program as the transport (such as ssh or rsh) or
contacting an rsync daemon directly via TCP.

Ik zou dan ook één van deze twee manieren gebruiken, in jouw geval is het draaien van een rsync daemon op de NAS het handigst en simpelst denk ik.

[Verwijderd]

Je hebt je niet verdiept in rsync. Het is namelijk wel mogelijk om te syncen van en naar 'netwerklocaties'. Via ssh of via een rsync daemon.

man rsync

[orillion]

AutoStatic schreef op vrijdag 14 augustus 2009 @ 23:20:
[...]
uit de man page van rsync:
[...]

Ik zou dan ook één van deze twee manieren gebruiken, in jouw geval is het draaien van een rsync daemon op de NAS het handigst en simpelst denk ik.

Over het algemeen is een NAS closed source en kun je dat soort dingen niet installeren/draaien....

[autostatic]

Zodra ik op "Verstuur bericht" had gedrukt realiseerde ik me dat ook. Ga soms teveel uit van mijn eigen thuissituatie.
Maar mounten van een samba share zonder root rechten kan met fusesmb:
http://fuse.sourceforge.net/
https://help.ubuntu.com/community/FuseSmb

[Verwijderd]

Waarom gebruik je geen FTP? (er vanuitgaande dat je NAS FTP heeft).
Het lijkt mij het handigst om een FTP-servertje op te zetten. Dit kun je ook prima scripten, is goed te beveiligen en altijd bereikbaar. Dan hoef je ook niks met NFS en rechten te doen, als je NAS ook WakeonLan ondersteund hoeft hij ook geen 24/7 te draaien.

^{(hier ben ik zelf toevallig ook mee bezig)}

[ Voor 25% gewijzigd door Verwijderd op 15-08-2009 11:52 ]

[Verwijderd]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 11:47:
Waarom gebruik je geen FTP? (er vanuitgaande dat je NAS FTP heeft).
Het lijkt mij het handigst om een FTP-servertje op te zetten. Dit kun je ook prima scripten, is goed te beveiligen en altijd bereikbaar. Dan hoef je ook niks met NFS en rechten te doen, als je NAS ook WakeonLan ondersteund hoeft hij ook geen 24/7 te draaien.

^{(hier ben ik zelf toevallig ook mee bezig)}

Waarom zou je dat willen? rsync is makkelijker om te configureren en velen malen efficienter dan ftp. (compressie + aleen verzenden van diffs.)

[Verwijderd]

@ Cagalli, je hebt gelijk dit had ik over het hoofd gezien, rsync stuurt alleen de data op die ontbreekt aan het doelbestand.

Maar... als je steeds losse bestanden verzend gaat dat voordeel verloren (het werkt alleen als je bestanden bijwerkt of up-date). Anders vind ik ftp toch handiger omdat rsync geen permissies ondersteund en je met ftp met een account werkt.
en als je de data alleen over je eigen netwerk verstuurd maken die paar mb's compressie ook niet zoveel uit.
Maar idd het kan meer voordelen bieden, net hoe je het gerbuikt

[ Voor 19% gewijzigd door Verwijderd op 15-08-2009 12:17 ]

[Verwijderd]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 12:14:
@ Cagalli, je hebt gelijk dit had ik over het hoofd gezien, rsync stuurt alleen de data op die ontbreekt aan het doelbestand.

Maar... als je steeds losse bestanden verzend gaat dat voordeel verloren (het werkt alleen als je bestanden bijwerkt of up-date). Anders vind ik ftp toch handiger omdat rsync geen permissies ondersteund en je met ftp met een account werkt.
en als je de data alleen over je eigen netwerk verstuurd maken die paar mb's compressie ook niet zoveel uit.
Maar idd het kan meer voordelen bieden, net hoe je het gerbuikt

Stel ik heb een LVM snapshot van mijn systeem drive: 250GB. Wat wil je dan verzenden? Het verschil van een paar MB of ga je gewoon weer 250G opnieuw verzenden? Wil je dan vervolgens ook nog gaan comprimeren? Wat 1 argument extra is aan rsync. Met andere woorden: het is helemaal niet een paar MB's. Ik weet niet precies wat je bedoeld dat het voordeel verloren zou gaan als je steeds losse bestanden gaat sturen?

PS. rsync ondersteund gewoon permissies en UNIX accounts.

[ Voor 3% gewijzigd door Verwijderd op 15-08-2009 12:33 ]

[Verwijderd]

Ik bedoelde dat als je kleinere losse bestanden upload je niet het voordeel van het verzenden van diffs hebt omdat, dat alleen werk bij het updaten / bijwerken van een bestand, of ik moet het verkeerd begrijpen.

maar laten we hier geen discussie van maken in het geval van jou voorbeeld heb je zeker gelijk.
(ik heb net de wiki van rsync doorgelezen en ga het misschien ook wel gebruiken)

P.S Ik las net in de wiki dat rsync idd permissies ondersteund

[ Voor 8% gewijzigd door Verwijderd op 15-08-2009 12:56 ]

[Verwijderd]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 12:37:
Ik bedoelde dat als je kleinere losse bestanden upload je niet het voordeel van het verzenden van diffs hebt omdat, dat alleen werk bij het updaten / bijwerken van een bestand, of ik moet het verkeerd begrijpen.

maar laten we hier geen discussie van maken in het geval van jou voorbeeld heb je zeker gelijk.
(ik heb net de wiki van rsync doorgelezen en ga het misschien ook wel gebruiken)

P.S Ik las net in de wiki dat rsync idd permissies ondersteund

Duplicity is ook een aanrader: Zie: http://duplicity.nongnu.org/

[Verwijderd]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 16:23:
[...]
Duplicity is ook een aanrader: Zie: http://duplicity.nongnu.org/

De Rdiff backup uit die link is echt superhandig.

En gezien het feit ik het automatisch wil doen is het niet erg handig om elke keer mijn wachtwoord te moeten ingeven.

Beste Roelke, wat jij hier beschrijft kun je prima oplossen door RSA keys over te gooien. Dan hoef je geen wachtwoord meer op te geven bij de ssh connectie.

Stel:
je wil dat de server, de client backupped dan doe je het volgende (volgens mijn visie)
De client laat je RSA key genereren,
Deze kopieer je naar de server als authorized_keys file. Nu is de server geauthorizeerd bij de client en mag de server ssh'en naar de client zonder wachtwoord.
in bash kun je dat natuurlijk in een prachtig if-statement verwerken

code:

Client:
cd ~/.ssh
ssh-keygen
cp id_rsa.pub local.key
scp local.key backup-user@server:/home/user/.ssh

Server:
cd ~/.ssh
cp local.key authorized_keys

Dit is mijn backup methode, per extensie. Om gescheiden backups van muziek, documenten enz te maken
find -L ./ -regex ".*\(odp\|odt\|doc\|docx\|ppt\|pptx\|xls\|xlsx\|pdf\|chm\|txt\)$" > $temp
tar -zcvf $backup/document-backup-$date.tgz -T $temp

[ Voor 43% gewijzigd door Verwijderd op 15-08-2009 17:41 ]

[Verwijderd]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 17:21:
[...]

Beste Roelke, wat jij hier beschrijft kun je prima oplossen door RSA keys over te gooien. Dan hoef je geen wachtwoord meer op te geven bij de ssh connectie.

Dit is een veel gebruikte methode maar ik vind het ook een hele enge methode. Deze methode is heel wat minder eng door in de pub key forced commands te zetten, wel een wachtwoord op die key zetten maar een agent te draaien en daarnaast door middel van allowuser statements en/of dmv firewalling aan te geven welke connecties er opgezet mogen worden.

En een linkje: https://people.chem.umass..._SSH_With_Automated_Login

[ Voor 7% gewijzigd door Verwijderd op 15-08-2009 20:08 ]

[Verwijderd]

Dit is een veel gebruikte methode maar ik vind het ook een hele enge methode.

Wat vind jij er eng aan?
ik heb uit nieuwsgierigheid geprobeerd de authhorized_keys file te manipuleren, door de gebruiker@host te vervangen door root@host maar bij iedere aanpassing ook draai je hem terug vervalt de key.

En ik weet natuurlijk dat als je de key kopieerd en ongewild in iemand ze ~/.ssh gooit, je hele nare dingen kan doen. Maar voor thuis zie ik er geen gevaar in.

[ Voor 10% gewijzigd door Verwijderd op 16-08-2009 00:00 ]

[autostatic]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 20:03:
[...]


Dit is een veel gebruikte methode maar ik vind het ook een hele enge methode. Deze methode is heel wat minder eng door in de pub key forced commands te zetten, wel een wachtwoord op die key zetten maar een agent te draaien en daarnaast door middel van allowuser statements en/of dmv firewalling aan te geven welke connecties er opgezet mogen worden.

En een linkje: https://people.chem.umass..._SSH_With_Automated_Login

Draai dagelijks backups over het internet met rsync en doe het inderdaad ook zoals Stacheldraht aangeeft. Zoiets wil je potdicht hebben. Op een lokaal netwerkje maakt het niet zo gek veel uit.

[Verwijderd]

@AutoStatic mooi mooi

@ahimza /me wordt er soms een beetje moe van dat ik dit soort eenvoudige security zaken keer op keer onder de aandacht moet brengen.

Overigens ik maak nooit een onderscheidt tussen lokale en niet lokale netwerken