Incrementeel bestanden oversturen, met logging

[Boudewijn]

Hoihoi

Ik ben bezig met een projectje voor een vriend van me die graag 350 gigabyte op mijn colocated server kwijt wil. Het is een complete backup van zijn cd's.

No problem, als hij er maar voor betaalt. Zowel dataverbruik als diskspace is al rond. Dat is dus het probleem niet.


Wat wel een probleem is, is hoe ik dit ga engineeren.
Mijn server is Debian etch, maar ik kan prima een VM hiervoor draaien. Zeker als ik zo mijn nieuwe server weghang is een VM meer of minder geen issue.
Client is een ubuntu doosje achter een pruttig consumenten-lijntje (dus restart van de initiele upload is wel leuk, want 350gb wil je niet in 1x doen ).

USB diskje overbrengen is niet mogelijk, de initiele transfer moet gewoon over het internet.
Updates gebeuren vrij weinig (bij aanschaf nieuwe cd) en downloads alleen als zijn pc (waar het op staat) afbrandt en hij dus de backup bij mij moet gebruiken.
De deal is dat na de initiele upload traffic nagecalculeerd wordt, dus ik wil kunnen loggen. Dat is eis 1.

Eis 2 is incrementele mogelijkheid (beetje lullig om alles opnieuw te sturen als er maar 1 cd is vernaderd).
Eis 3 is scriptbaar onder Linux.


Rsync is hier prima, voor maar is te krijgen in 2 smaken. Over SSH, lekker veilig en mooi van een SSH-pubkey gebruik kunnen maken. Echter moet ik daar wel een systeem user voor aanmaken, of een eigen VM voor maken. Dat is dan wel weer jammer, weet iemand of ik hem in een rootjail kan stoppen en dan toch nog kan rsyncen?
Ook is traffic logging afaik niet mogelijk!


De andere optie is rsyncd, maar die werkt niet met een pki infrastructuur. Verder kan hij wel loggen, maar zit er geen encryptie op. Ecnryptie is geen eis, maar wel een leuke pre.

Beide zijn prima te scripten op de client uiteraard.

Weet iemand wat ik hier het beste kan doen? Als in: zijn er nog leuke alternatieven die ik over het hoofd zie, of dingen die ik toch wel\niet kan doen.

[anandus]

Kan je (voor ssh-rsync) niet een user aanmaken voor hem, en dan zelf de desbetreffende map plaatsen waar je wilt?
Wat niet helemaal duidelijk is, is of de user ook gewoon bij z'n bestanden moet kunnen, of dat dat via jou gaat?

Is misschien iets als SCP (daar is een prima Windows-client voor, WinSCP) of SFTP een optie?

[ Voor 8% gewijzigd door anandus op 17-01-2009 18:30 ]

[Boudewijn]

SCP en SFTP zijn niet incrementeel, dus daar heb ik geen zin in. WinSCP is bekend ja.
Verder wil ik ook zijn traffic kunnen loggen.


Hij moet er zelf wel bij kunnen ,maar dat kan prima met rsync.
Zijn ~ kan ik wel ergens plaatsen ,maar het gaat er meer om dat ik hem verder niet met login rechten op mijn systeem wil hebben. Hij met dus rsync over ssh kunnen draaien, en verder niets.

[gertvdijk]

Als je toch gaat gebruiken als backup zou ik rdiff-backup gebruiken i.p.v. rsync. Dit ondervangt user error gevalletjes waarbij ook de bestanden op de server worden verwijderd en default hashed ie alles, zodat je bij het verplaatsen/hernoemen van bestanden geen extra traffic hebt.
Een aparte VM is volgens mij helemaal niet nodig. Je kan namelijk met SSH forced-commands, pub/private keys en gebruikmakend van een aparte user al een heel eind komen wat betreft bescherming. Kijk ook eens naar deze HowToForge howto. Daar wordt wel een backup gestart op initiatief van de backupserver. Dat is imo eleganter, aangezien je dan geen schrijfrechten hebt op een server. Dat kan natuurlijk wel een probleem opleveren wanneer hij zelf wil bepalen wanneer er data van zijn PC wordt getrokken (zodat hij niet zijn pc aan hoeft te laten).

[ Voor 23% gewijzigd door gertvdijk op 17-01-2009 18:44 ]

[Boudewijn]

Ja dat is niet handig.
Sowieso moet ik dan bij hem poorten openzetten, dat is niet de bedoeling. Verder is het de bedoeling dat hij zelf kiest wanneer hij backupped en dan ook die machine daarvoor aan zet\laat staan.
Niet handig dus.

aparte user en pki is uiteraard te doen, maar daar zit toch geen traffic logging in? Ik wil nml wel gewoon een factuur uitschrijven als hij doodleuk 50gb traffic verbruikt.

[anandus]

offtopic:
Google is snel
Ik zoek op "SFTP traffic logging" en kom bij dit topic aan

(Overigens logt SFTP geen traffic, kwam ik inderdaad achter)

[gertvdijk]

Boudewijn schreef op zaterdag 17 januari 2009 @ 18:47:
Ja dat is niet handig.
Sowieso moet ik dan bij hem poorten openzetten, dat is niet de bedoeling. Verder is het de bedoeling dat hij zelf kiest wanneer hij backupped en dan ook die machine daarvoor aan zet\laat staan.
Niet handig dus.

Wat let je om dit andersom te doen t.o.v. die how-to? Feitelijk verandert er niet zoveel.

Boudewijn schreef op zaterdag 17 januari 2009 @ 18:47:
aparte user en pki is uiteraard te doen, maar daar zit toch geen traffic logging in? Ik wil nml wel gewoon een factuur uitschrijven als hij doodleuk 50gb traffic verbruikt.

Ik heb geen verstand van hoe je traffic moet loggen, maar ik weet wel dat je dit alleen gaat kunnen bepalen vanuit IP+poort (met iptables). Userdata kan je niet netjes loggen aangezien het over SSH gaat en je dus niet kan 'zien' om welke user het gaat.

[Boudewijn]

Daarom, en ik heb zo meer klanten die dit willen. Ook met mogelijkerwijs dynamische IPs.
Niet handig dus.
Verder kan ik gewoon een logfile parser zoals awstats over het rsyncd logje rammen en het inzichtelijk voor de klant krijgen.

Daarom wil ik het de daemon laten doen ,wat rsync kan met de transfer logging optie.

Atm werkt het prima met rsynd namelijk, alleen is de kwaliteit van de password hash ruk (staat in de docu), en was pki mooi geweest.

[Gomez12]

Idd voor loggen gewoon iptables of iets dergelijks gebruiken. Desnoods maak je 1 subdomain aan, waarop hij kan inloggen en dat log je.

Niet iets zoeken wat rsync logt ofzo, je hosting rekent namelijk ook gewoon het totale verkeer af ( inclusief headers etc ) en niet alleen bruikbare data.

[Kees]

Rsync kan ook geen incremental dingen aan; als hij eenmaal stopt op 99% gaat hij doodleuk verder bij 0% als je hem weer start iirc.

Waarom zo moeilijk doen? Oude oplossingen voor dit probleem werken vaak prima: Het beste wat je kan doen is een ftp iets opzetten, en dan gewoon met ftp uploaden, proftp kan prima logs bijhouden van up en downloads en is chrootable. Het enige 'nadeel' is dat data dus niet encrypted over de lijn gaan, voordeel is wel dat je geen login hoeft aan te bieden. Scripten met FTP gaat prima.

[Boudewijn]

Gomez12 schreef op zaterdag 17 januari 2009 @ 19:02:
Idd voor loggen gewoon iptables of iets dergelijks gebruiken. Desnoods maak je 1 subdomain aan, waarop hij kan inloggen en dat log je.

Dat wil ik niet zeg ik al. Sowieso is een subdomein aanmaken een beetje een rare oplossing.
Verder ga ik dat soort dingen niet met iptables doen.

Niet iets zoeken wat rsync logt ofzo, je hosting rekent namelijk ook gewoon het totale verkeer af ( inclusief headers etc ) en niet alleen bruikbare data.

Nee dat doen ze niet , maar goed.


Van de homepage van rsync:

rsync is an open source utility that provides fast incremental file transfer.

Uploaden gaat toch prima als je op file 10 van de 20 onderbreekt? Zo eens even proberen.

[ Voor 7% gewijzigd door Boudewijn op 17-01-2009 19:22 ]

[Kees]

Boudewijn schreef op zaterdag 17 januari 2009 @ 19:17:
[...]

Dat wil ik niet zeg ik al. Sowieso is een subdomein aanmaken een beetje een rare oplossing.
Verder ga ik dat soort dingen niet met iptables doen.

[...]

Nee dat doen ze niet , maar goed.


Van de homepage van rsync:

[...]

Uploaden gaat toch prima als je op file 10 van de 20 onderbreekt? Zo eens even proberen.

Dat wel, maar niet als je halverwege een file onderbreekt volgens mij. En aangezien het blijkbaar om .iso's gaat, denk ik niet dat ze 10-20 mb zijn maar gewoon de volle 700mb in een keer.

[Boudewijn]

Nop, zijn flacjes van een megabyte of 30 per stuk. Is dus best acceptabel.

offtopic:
Ik wil hier niet de auteursrechten discussie aangaan, ik host het alleen. Hij heeft alle cd's legaal liggen, maar wil ze graag gebackupped hebben.

[anandus]

Boudewijn schreef op zaterdag 17 januari 2009 @ 19:30:
Nop, zijn flacjes van een megabyte of 30 per stuk. Is dus best acceptabel.

offtopic:
Ik wil hier niet de auteursrechten discussie aangaan, ik host het alleen. Hij heeft alle cd's legaal liggen, maar wil ze graag gebackupped hebben.

offtopic:
Zolang hij ze niet aanbiedt is er volgens mij geen probleem

[Erik Jan]

Zo te zien zoek je een duurzame oplossing en wil je je vriend vooral geen mogelijkheid geven misbruik te maken.

Dan zit je toch echt aan iptables vast om de verstookte traffic te meten. Ik kan immers een miljard connecties maken met jouw server en geen byte versturen. Dat verschijnt dan niet in je onderliggende logfiles maar toch verbruik ik je halve datalimiet.

Je motivering om alles dicht te spijkeren en nauwgezet af te rekenen, maar zonder iptables te gebruiken is dus enigszins krom.


Verder kan je rsyncd gewoon onder stunnel draaien en zo SSL krijgen vziw.

[Zwerver]

Kees schreef op zaterdag 17 januari 2009 @ 19:27:
[...]
Dat wel, maar niet als je halverwege een file onderbreekt volgens mij. En aangezien het blijkbaar om .iso's gaat, denk ik niet dat ze 10-20 mb zijn maar gewoon de volle 700mb in een keer.

Uhhh, rsync kent de append optie, dus dan neem ik aan dat hij ook checkt op filesize e.d.? Dus dan doet ie dat toch wel?

Boudewijn schreef op zaterdag 17 januari 2009 @ 19:01:
Daarom, en ik heb zo meer klanten die dit willen. Ook met mogelijkerwijs dynamische IPs.
Niet handig dus.
Verder kan ik gewoon een logfile parser zoals awstats over het rsyncd logje rammen en het inzichtelijk voor de klant krijgen.

Daarom wil ik het de daemon laten doen ,wat rsync kan met de transfer logging optie.

Atm werkt het prima met rsynd namelijk, alleen is de kwaliteit van de password hash ruk (staat in de docu), en was pki mooi geweest.

Rsyncd over stunnel geeft encryptie en logging, als je op de juiste manier gebruik maakt van rsync over ssh dan hoef je alleen maar toegang tot de rsyncd toe te laten (ik heb het gister met google uitgezocht voor svn+ssh, dit zou ook moeten werken voor rsync) en dan ben je toch klaar?

Over je PKI verhaal, gebruik jij een gepatchte SSH-daemon dat hij full flex PKI aankan? Of haal je nu dingen door elkaar. Laatste keer dat ik keek (feb 2008) moest je SSH nl patchen voor PKI-support.

[ Voor 6% gewijzigd door Zwerver op 17-01-2009 20:53 ]

[Boudewijn]

Erik Jan schreef op zaterdag 17 januari 2009 @ 19:52:
Zo te zien zoek je een duurzame oplossing en wil je je vriend vooral geen mogelijkheid geven misbruik te maken.

Dan zit je toch echt aan iptables vast om de verstookte traffic te meten. Ik kan immers een miljard connecties maken met jouw server en geen byte versturen. Dat verschijnt dan niet in je onderliggende logfiles maar toch verbruik ik je halve datalimiet.

Je motivering om alles dicht te spijkeren en nauwgezet af te rekenen, maar zonder iptables te gebruiken is dus enigszins krom.


Verder kan je rsyncd gewoon onder stunnel draaien en zo SSL krijgen vziw.

Nou nee. Ik verwacht geen bewust misbruik (dus vooral veel connecties aanmaken) , en dat los ik op door maar 1 simultane connectie toe te staan.

Het is meer het idee dat als hij 10 cd's bijkoopt en die uploadt dat ik dat kan billen.
iptables is leuk, maar dan mag ik een hostname per gebruiker\klant aanmaken , daar ik mischien nog wat van deze vrienden heb . Niet echt mooi imo, en dan ben je ook uitgepraat zodra je stunnel gebruikt lijkt me.


stunnel: hmmm dan gaan we daar eens over lezen.

[Boudewijn]

Zwerver schreef op zaterdag 17 januari 2009 @ 20:51:
[...]


Uhhh, rsync kent de append optie, dus dan neem ik aan dat hij ook checkt op filesize e.d.? Dus dan doet ie dat toch wel?


[...]

Rsyncd over stunnel geeft encryptie en logging, als je op de juiste manier gebruik maakt van rsync over ssh dan hoef je alleen maar toegang tot de rsyncd toe te laten (ik heb het gister met google uitgezocht voor svn+ssh, dit zou ook moeten werken voor rsync) en dan ben je toch klaar?

Hoe doe je dat precies?

Over je PKI verhaal, gebruik jij een gepatchte SSH-daemon dat hij full flex PKI aankan? Of haal je nu dingen door elkaar. Laatste keer dat ik keek (feb 2008) moest je SSH nl patchen voor PKI-support.

PKI is gewoon publieke sleutel authenticatie. Dat kan elke OpenSSH daemon al jaren.
Volgens mij bedolen we beiden iets anders?

offtopic:
Zwerver, alles kits?

[Zwerver]

Boudewijn schreef op zaterdag 17 januari 2009 @ 21:04:
[...]

Hoe doe je dat precies?

http://www.netbits.us/docs/stunnel_rsync.html
[google=rsync over stunnel]

[...]

PKI is gewoon publieke sleutel authenticatie. Dat kan elke OpenSSH daemon al jaren.
Volgens mij bedolen we beiden iets anders?

PKI is Public Key Infrastructure met certificaten en zo en dat kan OpenSSH niet.
Even een opfrissertje voor je:

PKI werkt met certificaten, waarbij een Certificate Authority server (CA-server) de boel beheert.
SSH werkt met keys (Pre Shared Keys PSK), waar geen centraal management voor is. Je kan keys niet eenzijdig intrekken, wat bij een PKI-omgeving wel kan.

Het is niet handig om die twee termen door elkaar heen te halen omdat mensen die zich wel aan de correcte termen houden dan verward raken

Dus OpenSSH != PKI maar wel PSK

Tot zover de stoomcursus

offtopic:
Zwerver, alles kits?

Goed man

[gertvdijk]

Zwerver schreef op dinsdag 20 januari 2009 @ 10:45:
SSH werkt met keys (Pre Shared Keys PSK), waar geen centraal management voor is. Je kan keys niet eenzijdig intrekken, wat bij een PKI-omgeving wel kan.

Het is niet handig om die twee termen door elkaar heen te halen omdat mensen die zich wel aan de correcte termen houden dan verward raken

Dus OpenSSH != PKI maar wel PSK

Dat is ook weer niet waar. SSH biedt wel degelijk een public/private keypair. Dat er vervolgens net als bij SSL een symmetrische encryptie (PSK) wordt afgesproken om verder te lullen staat daar los van.

[Seth4Chaos]

Kees schreef op zaterdag 17 januari 2009 @ 19:10:
Rsync kan ook geen incremental dingen aan; als hij eenmaal stopt op 99% gaat hij doodleuk verder bij 0% als je hem weer start iirc.

daar is een optie voor:

--partial keep partially transferred files
--partial-dir=DIR put a partially transferred file into DIR

Je had het er over dat je wel een VM wil aanmaken voor hem, dan kan je toch gewoon de interface uitlezen (van de VM) om te kijken hoeveel die verbruikt (dit is dan meteen al zijn verkeer, dat klopt).

[Zwerver]

gertvdijk schreef op dinsdag 20 januari 2009 @ 12:50:
[...]

Dat is ook weer niet waar. SSH biedt wel degelijk een public/private keypair. Dat er vervolgens net als bij SSL een symmetrische encryptie (PSK) wordt afgesproken om verder te lullen staat daar los van.

PKI werkt met certificaten en heeft een centrale authority die bepaald of een certificaat nog geldig is. Dat heeft SSH met pre-shared-key-pairs niet. Daar zit het grote verschil, ben je het daar mee eens?

[Boudewijn]

Uhh ja je hebt gelijk. Ik verkeerde in de veronderstelling dat ssh met publiek\private sleutelparen ook al onder de definitie PKI valt.

Momenteel is het toch gewoon rsync geworden. Extreme beveiliging is niet relevant, het is maar wat muziek .
Logging moeten we nog even testen, ik ga van de week wel even wat uploadjes daar draaien.

[gertvdijk]

Zwerver schreef op dinsdag 20 januari 2009 @ 13:40:
PKI werkt met certificaten en heeft een centrale authority die bepaald of een certificaat nog geldig is. Dat heeft SSH met pre-shared-key-pairs niet. Daar zit het grote verschil, ben je het daar mee eens?

Ja, met die toevoeging kan ik leven.

[axis]

Ik zou het gewoon lekker simpel maken.. Geef hem een virtual machientje met een system user account, en hij kan los gaan. Hij kan dan gewoon vanuit een batch file rsyncen met psk authenticatie, en het enige waar jij je druk over hoeft te maken is dat je het verkeer naar de interface van die vm uitleest met snmp bijvoorbeeld.

[Boudewijn]

Ja en een losse, nog steeds te onderhouden, VM.
Alhewel dat wmb bijna met een cronjobje zou kunnen .

[ajvdvegt]

Boudewijn schreef op dinsdag 20 januari 2009 @ 15:23:
...
Momenteel is het toch gewoon rsync geworden. Extreme beveiliging is niet relevant, het is maar wat muziek .
...

Je gebruikt nu dus gewoon SSH met een public/private key pair, en je stuurt je rsync verkeer door dit een tunneltje? Kan gewoon met ssh (zelfs PuTTY) en rsync, zonder stunnel. Lijkt me inderdaad niet 'extreem' beveiligd, maar toch zeker voldoende voor staatsgeheimen e.d....

[Boudewijn]

Nee zelfs zonder ssh, dan wordt het anders te lastig.
Ben er ook niet blij mee, maar goed.... het gaat maar om muziek (alhoewel veel traffic door een hack erger is).

Ik ga denk ik toch maar op mijn nieuwe server een VM installeren voor dit geintje.