Client/Server snelle overdracht bij beveiligde bestanden.

[Carharttguy]

Hallo

Vroeger zou dit topic waarschijnlijk in SE&A beland zijn, maar nu post ik het dus hier.
Ik zit met het volgende probleem:

Ik heb een client en serverapplicatie. Allebei zelf geschreven en dus volledig onder eigen beheer.
Vanaf de client vertrekt broncode naar de server, die daar gecompileerd wordt en een executable terugstuurd naar de client.

Nu, omdat volledige broncode & volledige executables versturen bij kleine aanpassen heel veel overtollig verkeer en vertraging met zich meebrengt, dacht ik om met een diff te werken, die stuurt dan alleen kleine broncode aanpassingen door, en alleen patches van de bestaande executable terug.

Natuurlijk, die diff moet de server kunnen toepassen op bestaande code, en de patch moet gemaakt kunnen worden. Maar dat wil zeggen dat die bestanden leesbaar op de server zouden moeten staan. Dit lijkt me helemaal niet gewenst, vanuit beveiligingsperspectief.

Ik zou natuurlijk eerst de bestanden kunnen ontsleutelen, diff toepassen, en terug versleutelen. Of ontsleutelen, patch maken, terug versleutelen. Maar dat zorgt weer voor vertraging (die niet gewenst is). En het feit dat, als mijn server het kan ontsleutelen, dat ook kan gedaan worden door eventuele kwaadwillenden die dan toch al toegang hebben tot mijn bestanden.

Dus vroeg ik me af of iemand hier misschien een idee heeft om zoiets veilig, en toch snel op te lossen. Een geheel andere insteek is ook welkom. Het zou kunnen dat diffen en patchen absoluut niet de beste oplossing is voor mijn probleem.

Dank voor uw tijd.
Mathias

[joppybt]

Carharttguy schreef op maandag 03 december 2012 @ 20:10:
Natuurlijk, die diff moet de server kunnen toepassen op bestaande code, en de patch moet gemaakt kunnen worden. Maar dat wil zeggen dat die bestanden leesbaar op de server zouden moeten staan. Dit lijkt me helemaal niet gewenst, vanuit beveiligingsperspectief.

Maar als de code op de server wordt gecompileerd staat het er toch sowieso al leesbaar op? Het enige wat verandert met de patches/diff is dat het mogelijk wat langer bewaard moet blijven.

En het feit dat, als mijn server het kan ontsleutelen, dat ook kan gedaan worden door eventuele kwaadwillenden die dan toch al toegang hebben tot mijn bestanden.

Als het echt encrypted moet zou je kunnen overwegen bij booten van de server een random sleutel te genereren die je alleen in het geheugen onthoudt. Je server kan dan nog steeds wel bij de bestanden maar een hacker met toegang tot je schijven kan mogelijk niet bij de sleutel in het geheugen komen.
Enige nadeel is dat je bij een reboot/crash van de server zelf de sleutel ook kwijt bent. Dan moet je maar een keer weer de volledige set van de client opvragen.

[RobIII]

Carharttguy schreef op maandag 03 december 2012 @ 20:10:
Vroeger zou dit topic waarschijnlijk in SE&A beland zijn, maar nu post ik het dus hier.
[...]
Het zou kunnen dat diffen en patchen absoluut niet de beste oplossing is voor mijn probleem.

Vroeger in SEA (maar ook in PRG ) was dan ook de meest logische eerste vraag: begin eens met 't beschrijven van 't probleem dat je probeert op te lossen. Dan pas kunnen we écht wat zinnigs zeggen.

[Carharttguy]

joppybt schreef op maandag 03 december 2012 @ 20:32:
[...]

Maar als de code op de server wordt gecompileerd staat het er toch sowieso al leesbaar op? Het enige wat verandert met de patches/diff is dat het mogelijk wat langer bewaard moet blijven.

[...]

Als het echt encrypted moet zou je kunnen overwegen bij booten van de server een random sleutel te genereren die je alleen in het geheugen onthoudt. Je server kan dan nog steeds wel bij de bestanden maar een hacker met toegang tot je schijven kan mogelijk niet bij de sleutel in het geheugen komen.
Enige nadeel is dat je bij een reboot/crash van de server zelf de sleutel ook kwijt bent. Dan moet je maar een keer weer de volledige set van de client opvragen.

Maarja, er is een verschil tussen bestanden opslaan voor later gebruik, of het binnenkrijgen via socket en onmiddellijk compilen.

Dat van die sleutel is helemaal geen slecht idee! Ga ik zeker onthouden.

Maar omdat Roblll het vroeg, ga ik mijn 'probleem' wat beter omschrijven.

Ik maak dus een client, dat een IDE is, gebruikers kunnen er lay-outs ontwerpen, en programmeren. Bij het 'builden' van een project wordt een bestand samengesteld met daarin de lay-out en bijhorende code. Dat bestand zou verzonden worden naar de server. Die server ontvangt de code en compileert de boel. Het afgewerkte programma wordt dan teruggezonden naar de client. Klaar voor gebruik.

Over dat bestand met lay-out/code maak ik me niet zoveel zorgen, dat loopt in de KB's, en dat valt makkelijk te comprimeren daar het platte tekst is.
Over die executable ben ik heel wat minder zeker, dat kan makkelijk enkele MB's groot zijn, en dat duurd toch nog altijd even voor dat verstuurd is. Zeker bij een 'snelle' test is dat toch al lang wachten.

Daarom dacht ik aan diffen/patchen, om maar fracties van bestanden door te sturen. Dat scheelt al een hele hoop. En kostbare seconden.

Als er nog vragen zouden zijn..

[Niemand_Anders]

Ik heb het idee dat je probeert om een build server op te zetten. Helaas geef je niet aan voor welke taal of platform.

Een eenvoudige oplossing om alleen de gewijzigde bestanden naar de server te sturen is om eerst van de server een file listing terug te krijgen. (file path + last write date is voldoende). Vervolgens kan jouw client een zip archive opbouwen en daarin de bestanden (met relatief path tov van project root) plaatsen welke een recentere datum hebben dan de server versie.

Die zip kun je vervolgens naar de server sturen welke deze uitpakt en de bestanden naar de bestaande code kopieert. Vervolgens kun je de nieuwe code compileren en eventueel de output uit de output folder oppakken, zippen en weer terug sturen naar de client.

Dat is de basis waarop al veel build servers zijn gebaseerd. Maar omdat het een eigen client/server app betreft is het zeer eenvoudig een extra security laag aan de server kant toe te voegen.

clients moeten zich in de regel authenticeren bij de server. Die account gegevens (username/password (hash) staan ergens opgeslagen, vaak een database. Voeg aan de account gegevens een symmetrische encryptie sleutel toe zoals AES (encryptie/decryptie sleutels zijn hetzelfde).

De zip vanaf de client zelf hoef je niet te encrypten want voor transport moet je gewoon gebruiken maken van een SSL/TLS stream.

En nou komt de clou: Bij elke opdracht (na authenticatie) decrypt de server een broncode zip en pakt het archive bestand uit, voert de opdracht uit (filelisting, merge, build, etc) en zodra de server klaar is worden alle bron bestanden weer in een zip geplaatst en deze encrypt je weer. Vervolgens kan de server de workfolder verwijderen.

Op die manier kan niemand eenvoudig bij de broncode op de server, wat ook voor jouw geldt. Andere belangrijke punten waarop je moet letten: gebruik een obfuscator om magic strings te verbergen en zet een beveiligde (!) verbinding op met je database server zodat een tcp sniffer niet de database communicatie kan afvangen..

[RobIII]

Misschien dat hier iets bruikbaars bij/in zit? (Kleine toelichting)

[edeboeck]

Niemand_Anders schreef op maandag 03 december 2012 @ 20:59:
Een eenvoudige oplossing om alleen de gewijzigde bestanden naar de server te sturen is om eerst van de server een file listing terug te krijgen. (file path + last write date is voldoende). Vervolgens kan jouw client een zip archive opbouwen en daarin de bestanden (met relatief path tov van project root) plaatsen welke een recentere datum hebben dan de server versie.

Die zip kun je vervolgens naar de server sturen welke deze uitpakt en de bestanden naar de bestaande code kopieert. Vervolgens kun je de nieuwe code compileren en eventueel de output uit de output folder oppakken, zippen en weer terug sturen naar de client.
(...)
En nou komt de clou: Bij elke opdracht (na authenticatie) decrypt de server een broncode zip en pakt het archive bestand uit, voert de opdracht uit (filelisting, merge, build, etc) en zodra de server klaar is worden alle bron bestanden weer in een zip geplaatst en deze encrypt je weer. Vervolgens kan de server de workfolder verwijderen.

Op die manier kan niemand eenvoudig bij de broncode op de server, wat ook voor jouw geldt.
(...)

Hier ben je me even kwijt: hoe kan je de filelisting opbouwen, merging doen, etc. als de bestanden geëncrypteerd en, vooral, weer verwijderd zijn? Of bedoel jij dat de bestanden nog ergens anders dan in de workfolder staan? En zijn ze dan sowieso niet toegankelijk voor een hacker (of bedoel je dat de encryptie daar dan voor de beveiliging moet zorgen)?

[Carharttguy]

Niemand_Anders schreef op maandag 03 december 2012 @ 20:59:
Ik heb het idee dat je probeert om een build server op te zetten. Helaas geef je niet aan voor welke taal of platform.

Het gaat om een zelfontwikkelde taal en framework.

Verder vind ik jouw methode niet slecht eigenlijk. Maar courgette van Google zoals Roblll aangeeft, is ook helemaal niet slecht. Maar gaan alletwee uit van 2 verschillende principes, bij courgette heb je weer een oude versie nodig om mee te vergelijken, bij jouw methode (of die van een build server) gaat de boel waarschijnlijk trager gaan.

Misschien een combinatie van de 2, zeker dat van die file listing kan heel goed van pas komen denk ik!

Edit: edeboeck heeft gelijk eigenlijk, een file listing is natuurlijk onmogelijk zonder de bestanden op de server te staan hebben. Misschien moet ik me gewoon heel goed vertrouwen op filepermissies enzo, daar valt ook al een heleboel mee te doen.

[ Voor 14% gewijzigd door Carharttguy op 03-12-2012 21:39 ]

[RobIII]

Wat is er geheim aan bestandsnamen? Daarmee heb je de inhoud toch nog niet? Je kunt toch, bij wijze van, gewoon een tekstfile/db/whatever hebben met daarin de bestandsnamen (en wat metadata als lastchanged, hash, weet-ik-het?)

[Niemand_Anders]

edeboeck schreef op maandag 03 december 2012 @ 21:29:
[...]
Hier ben je me even kwijt: hoe kan je de filelisting opbouwen, merging doen, etc. als de bestanden geëncrypteerd en, vooral, weer verwijderd zijn? Of bedoel jij dat de bestanden nog ergens anders dan in de workfolder staan? En zijn ze dan sowieso niet toegankelijk voor een hacker (of bedoel je dat de encryptie daar dan voor de beveiliging moet zorgen)?

Nee, de server pakt de bestand uit om een opdracht uit te voeren en nadat de opdracht is uitgevoerd worden de bestanden weer ingepakt. De tijdelijke workfolder kun je daarna weer verwijderen..

Omdat de bestanden normaal in een encrypted archive staan, kun je er normaal niet bij. De bestanden worden alleen uitgepakt op het moment dat de server een command moet uitvoeren. Je kunt het uit- en inpakken zien als een pre en post action..

bij jouw methode (of die van een build server) gaat de boel waarschijnlijk trager gaan.

Als je werkt met versleutelde bestanden, zul je bij een actie altijd de bestanden ook weer moeten ontsleutelen. een zip (zonder of met zeerlichte) compressie is vrij snel en daarbij hoef je maar 1 bestand te decrypten..

Courgette is slechts een diff methode welke voorkomt dat je het gehele bestand over hoeft te sturen. Maar dat betekend dat je op de client ergens een 'cache' moet bijhouden van het originele bestand (anders kun je geen diff maken). De copy-if-newer methode is vrij eenvoudig te implementeren en als je eenmaal de basis hebt staan kun je altijd nog optimalisaties doorvoeren..

[Gomez12]

Wat is je verwachte hoeveelheid aan clients en wat is de gemiddelde verwachte netwerksnelheid?

Ik bedoel je zit nu heel moeilijk te doen en ik zit me af te vragen of de ontwikkelkosten/complexiteit wel tegen de baten opwegen.

Een paar MB lijkt me gemiddeld genomen zo gedownload en als het maar om een honderdtal clients gaat dan is het netwerkverkeer ook niet echt grandioos lijkt me.

Het hele diff-patch verhaal lijkt mij redelijk ingewikkeld, zou je wellicht niet met een soort plugin-systeem kunnen werken waarbij je de basis hebt en elk gecompileerd iets een plugin is zodat je in ieder geval de core niet hoeft te downloaden. Dan kan je periodiek een nieuwe core kunnen uitbrengen met standaard geintegreerde plugins oid.

[Hydra]

Waarom wil je dit uberhaupt encrypted versturen? Is er een business case voor dat het extreem gevoelige code is (zo gevoelig dat SSL niet afdoende is) of vind je dit gewoon leuk om zo te bouwen?

[ Voor 3% gewijzigd door Hydra op 04-12-2012 09:16 ]

[Janoz]

Eigenlijk vind ik het wel een redelijk botte aanname dat de client vast de vorige gecompileerde executable nog heeft. Nu ken ik de exacte eisen en omstandigheden niet, maar het zou natuurlijk best kunnen dat de gebruiker die al lang weggegooid heeft, of dat er meerdere gebruikers aan hetzelfde project werken waardoor ze om en om een versie 'downloaden'. In dat geval is de vorige versie helemaal niet beschikbaar om de patches op uit te voeren.

[Carharttguy]

Nog even wat extra informatie:

Het is dus een hobby project. Ik hoop dat er simultaan ooit een honderdtal clients tegelijk verbonden zijn, maar die builden/compilen natuurlijk niet tegelijkertijd. Netwerksnelheid is vrij onvoorspelbaar, daar iedereen het programma zal kunnen gebruiken.

@Hydra: Ik wil niet extra encrypted versturen, bestanden worden verstuurd over SSL, maar ik vraag me af of bestanden encrypted op de server bewaard zouden moeten worden, in geval van een hack.
Misschien moet ik de bestanden helemaal niet op de server bewaren, maar dat was m'n eerste idee, omdat ik dan een difftool kon gebruiken om dataoverdracht te versnellen.

@Janoz, dat is inderdaad de aanname dat de client de vorige gecompileerde executable nog heeft. Is die er niet, dan compile ik de boel opnieuw, en stuur een volledige executable terug. Maar mijn vraag gaat dus meer over de situatie als de executable aan de client kant wel nog beschikbaar is. Want dan zijn er snelheidsoptimalisaties beschikbaar, en die zoek ik dus

Ik heb dus wel al veel tips gehad hier van in dit topic, het zet me zeker aan het denken. Maar als jullie nog ideeën hebben, mag je ze altijd ventileren natuurlijk! Hoor het graag.

[YopY]

Mbt het encrypted opsturen naar de server van diffs, waarom gebruik je niet gewoon een bestaand (gedistribueerd) versiebeheersysteem? Met Git is het bijvoorbeeld mogelijk om een remote toe te voegen; het sturen van een nieuwe versie naar de buildserver is dan een kwestie van 'git push build' (of hoe je de remote van de buildserver maar noemt). Het enige wat je dan opstuurt zijn de diffs, die (neem ik aan) ook nog gecomprimeerd worden. Ten tweede, Git communiceert standaard via ssl of, als alternatief, via https, dus encryptie zit dan wel snor.

Qua beveiliging / encryptie op de server zul je iemand anders moeten vragen; waarschijnlijk kun je het wegschrijven naar een encrypted volume, maar ook dan zul je nog Git toegang moeten geven. Mogelijk is er wel iets te doen met home directories die alleen toegangkelijk zijn voor die gebruiker.

En mbt het laatste (kijken of de executable nog hetzelfde is) lijkt me een kwestie van een eenvoudige hash check (md5 moet afdoende zijn). if (buildserver hash == local hash) niet updaten, else updaten.

[Hydra]

Carharttguy schreef op dinsdag 04 december 2012 @ 10:49:
@Hydra: Ik wil niet extra encrypted versturen, bestanden worden verstuurd over SSL, maar ik vraag me af of bestanden encrypted op de server bewaard zouden moeten worden, in geval van een hack.
Misschien moet ik de bestanden helemaal niet op de server bewaren, maar dat was m'n eerste idee, omdat ik dan een difftool kon gebruiken om dataoverdracht te versnellen.

Nogmaals: heb jij dit zo bedacht of komt dit uit een businesscase? Want volgens mij zit je eigenlijk 'om niets' een enorm complex systeem te bouwen. Als iemand echt toegang tot die server krijgt is een tool installeren die gewoon de unencrypted zooi uit 't geheugen plukt compleet kinderspel en dan zit jij daar met een overengineered stuk software dat eigenlijk niks toevoegd.

[H!GHGuY]

Hydra schreef op woensdag 05 december 2012 @ 11:47:
[...]


Nogmaals: heb jij dit zo bedacht of komt dit uit een businesscase? Want volgens mij zit je eigenlijk 'om niets' een enorm complex systeem te bouwen. Als iemand echt toegang tot die server krijgt is een tool installeren die gewoon de unencrypted zooi uit 't geheugen plukt compleet kinderspel en dan zit jij daar met een overengineered stuk software dat eigenlijk niks toevoegd.

Dat en:
binaries diffen/patchen is zinloos. Er moet maar 1 functie aangepast worden om een lawine aan changes te krijgen. Bovendien is binaries diffen betrekkelijk moeilijk.
Daarnaast heb je nog andere problemen zoals beschikbare libraries, cross & native compilation, etc.
Waarom niet de compiler naar je client streamen?

[edeboeck]

Niemand_Anders schreef op maandag 03 december 2012 @ 22:10:
[...]
Nee, de server pakt de bestand uit om een opdracht uit te voeren en nadat de opdracht is uitgevoerd worden de bestanden weer ingepakt. De tijdelijke workfolder kun je daarna weer verwijderen..

Omdat de bestanden normaal in een encrypted archive staan, kun je er normaal niet bij. De bestanden worden alleen uitgepakt op het moment dat de server een command moet uitvoeren. Je kunt het uit- en inpakken zien als een pre en post action..

Zover was ik ook mee en dat zag ik wel in. Alleen heb je het zelf al aangehaald:

Niemand_Anders schreef op maandag 03 december 2012 @ 20:59:
[...]Een eenvoudige oplossing om alleen de gewijzigde bestanden naar de server te sturen is om eerst van de server een file listing terug te krijgen. (file path + last write date is voldoende). Vervolgens kan jouw client een zip archive opbouwen en daarin de bestanden (met relatief path tov van project root) plaatsen welke een recentere datum hebben dan de server versie.

Tenzij jij die file listing op voorhand al opbouwt en opslaat in een bestand kan je die niet meer opbouwen (wegens bestanden niet meer aanwezig).

Die zip kun je vervolgens naar de server sturen welke deze uitpakt en de bestanden naar de bestaande code kopieert. Vervolgens kun je de nieuwe code compileren en eventueel de output uit de output folder oppakken, zippen en weer terug sturen naar de client.[...]

Hoe kan je die naar de bestaande code kopiëren als die zich niet meer op de server bevindt (omdat enkel de gewijzigde bestanden verstuurd zijn)?

Voor alle duidelijkheid: helemaal niet als rant of zo bedoeld (hoop dat het ook niet zo overkomt)... wel om iets bij te leren!

[Gomez12]

Hydra schreef op woensdag 05 december 2012 @ 11:47:
[...]


Nogmaals: heb jij dit zo bedacht of komt dit uit een businesscase? Want volgens mij zit je eigenlijk 'om niets' een enorm complex systeem te bouwen. Als iemand echt toegang tot die server krijgt is een tool installeren die gewoon de unencrypted zooi uit 't geheugen plukt compleet kinderspel en dan zit jij daar met een overengineered stuk software dat eigenlijk niks toevoegd.

Uit 't geheugen plukken is nog relatief moeilijk, gewoon continue een map kopieren en de hele ingewikkelde bewerking van verwijderen (en de daarbij komende complextiteit) is zinloos geworden.

Als ik zo het topic lees bekruipt me toch iets van : Wellicht moet je je huidige idee eens laten varen en de businesscase uitleggen dan kan er aan de hand van de businesscase bedacht worden wat het handigste is.
Want de meeste aangedragen ideeen gaan nog steeds door op je idee en eigenlijk ondersteunt zo goed als niemand dat idee. Technisch kan jouw idee, maar het is simpelweg niet handig en ook bijna geen beveiliging.

[Carharttguy]

Ok, ik leg het even helemaal uit. Eerst en vooral is het geen bestaande businesscase die ik krijg van een werkgever ofzo, maar gewoon een hobbyproject (een vrij groot eigenlijk).

Wat ik wil proberen:

Een ontwikkelingsomgeving creeëren waarbij je heel gemakkelijk cross-platform applicaties kan maken. En met cross-platform bedoel ik niet allen Win/Mac/Lin maar ook Android/iOS/Blackberry/Eventueel Mozilla mobile OS?

Hoe wil ik dat doen? Ik ben bezig met een soort van compiler (compiler is misschien een groot woord) die een vertaling maakt van mijn eigen ontworpen code, naar bestaande programmeertalen als .Net, Python, C++, Obj-C, HTML/PHP, eender wat, het moet zo generiek mogelijk zijn, dat het heel gemakkelijk kan uitgebreid worden met andere talen. (Aan de hand van een soort code-templates die ik maak in een bepaalde taal, en dan worden ingevuld met de juiste waarden).
En dan die code automatisch compiled naar een geselcteerd platform. Ik wil die 'vertaler' dus draaien op een VPS, omdat ik dan zelf controle heb over code die ik toevoeg, zonder dat alle gebruikers deze code ook op hun PC moeten hebben. Een ander voordeel is dat ik bijvoorbeeld iOS software kan compilen, wat vanop een Win/Lin PC normaal niet gaat. Met mijn systeem zou het wel gaan.

Wat zijn de nadelen?
1) Snelheid bij compilate, de code gaat over internet naar mijn VPS, code wordt gecompileerd, executable moet terug naar de gebruiker. Dat neemt tijd.
2) Debugging wordt heel lastig.

Punt 2 boeit me op dit moment niet zo heel veel. Punt 1 zou ik wel een oplossing voor willen vinden, gewoon omdat dit volgens mij toch echt wel opgelost moet worden.
Ik wil dus gewoon tijdswinst behalen, en liefst nog wat datavekeer ook. Maar die twee gaan meestal hand in hand natuurlijk. Minder data is minder vekeer.

Daarom dat ik dus dacht aan diff/patch.

Maar er zijn waarschijnlijk dus betere oplossingen. Dank voor jullie tijd.

[Gomez12]

1e gedachte na lezen case : Schrap het als hobbyproject en herpositioneer het als leerproject.
Dit gaat je 100'en / 1000'en ervaren manjaren kosten om goed te bouwen.

2e gedachte na lezen case : Begin bij het begin en niet bij het einde, snelheid is totaal niet relevant op dit moment. Bouw het eerst op in een vps en benader die voor je mobile devices via wifi.

3e gedachte na lezen case : Beperk je scope tot realistische doelen. Je scope kan altijd uitgebreid worden maar nu komt het op mij over als te werk gaan als een kip zonder kop en het moet maar alles kunnen en alles ondersteunen.

4e gedachte na lezen case : Probeer eens te begrijpen wat je probeert te doen, begrijp je je scope dan zal je gelijk inzien waarom er niet 1 one-size-fits-all oplossing is, maar je qua snelheid wellicht 20 aanpakken zal moeten hanteren.

Simpel voorbeeldje : In je scope valt html, veel succes met in een markuptaal diff-patch inbouwen.

Simpel gezegd : Binnen de genoemde scope zijn er simpelweg geen 1-stop solutions, je zal per taal / platform moeten kijken wat daarvoor de beste oplossing is (maar daarvoor moet je wel eerst de basis in die taal/platform draaiende hebben)

[Niemand_Anders]

edeboeck schreef op woensdag 05 december 2012 @ 19:05:
[...]
Zover was ik ook mee en dat zag ik wel in. Alleen heb je het zelf al aangehaald:

[...]
Tenzij jij die file listing op voorhand al opbouwt en opslaat in een bestand kan je die niet meer opbouwen (wegens bestanden niet meer aanwezig).

Maar de bestanden zijn wel aanwezig in de encrypted zip welke je bij elke client request uitpakt en daarna weer inpakt..

[...]
Hoe kan je die naar de bestaande code kopiëren als die zich niet meer op de server bevindt (omdat enkel de gewijzigde bestanden verstuurd zijn)?

Voor alle duidelijkheid: helemaal niet als rant of zo bedoeld (hoop dat het ook niet zo overkomt)... wel om iets bij te leren!

De bestanden staan alleen niet in plain-text op de server. Misschien is de TFS build server een beter voorbeeld. Als jij een release build gaat maken, begin je met een lege directory. Vervolgens haal jij uit TFS je project op, compileer je enkele producten, laat documentatie genereren en vervolgens verplaats je de bestanden naar een release folder en daarna ruim je netjes weer je troep op..

Nu staan de bestanden niet in een source repository, maar in een encrypted zip. Die wordt dus continue uitgepakt, vervolgens wordt het request uitgevoerd (filelisting genereren, project compileren, etc), output wordt terug naar de client gestuurd en vervolgens wordt er weer een nieuwe encrypted zip aangemaakt..

Een van de requirements was de broncode niet zichtbaar mocht zijn op de server voor vreemden. Dit is het eenvoudigst te implementeren met encryptie. Door een zip te gebruiken aan de server kant, kan de client een gewijzigde en verwijderde bestanden doorgeven en daardoor is versie beheer vrij simpel.

Ga je met patch bestanden werken, dan moet de basis van de client en de server gelijk zijn. Daarbij zijn er wel enkele VCS systemen welke encryptie op transport niveau bieden, maar de repository storage is voor zover ik weet overal plain-text. Als je een eigen version systeem wilt schrijven, is het raadzaam naar RCS te kijken. Dat is een version systeem per bestand op een local file system. versie beheer pur sang dus.

En de concepten uit RCS worden ook toegepast in CVS, SVN, maar ook bij distributed versie systemen zoals git alleen werken die systemen niet langer op een enkel bestand, maar op een tree. Veel versie beheer systemen hebben een incremental version bestand (met alle incremental wijzigingen vanaf versie 1) en een 'current' versie als cache omdat deze het meest aangesproken zal worden..

[Carharttguy]

Gomez12 schreef op donderdag 06 december 2012 @ 22:22:
1e gedachte na lezen case : Schrap het als hobbyproject en herpositioneer het als leerproject.
Dit gaat je 100'en / 1000'en ervaren manjaren kosten om goed te bouwen.

Simpel voorbeeldje : In je scope valt html, veel succes met in een markuptaal diff-patch inbouwen.

Is honderden of duizenden manjaren niet wat overdreven? Manuren zou ik nog ergens begrijpen.
Mijn programmeertaal zou worden omgezet naar html. En er zou dus een diff/patch moeten toegepast worden op die html, en dat is gewoon platte tekst, dus dat is perfect logisch.

[BasieP]

Carharttguy schreef op maandag 10 december 2012 @ 14:57:
[...]


Is honderden of duizenden manjaren niet wat overdreven? Manuren zou ik nog ergens begrijpen.
Mijn programmeertaal zou worden omgezet naar html. En er zou dus een diff/patch moeten toegepast worden op die html, en dat is gewoon platte tekst, dus dat is perfect logisch.

Er zijn zat diff tools voor platte tekst. Dat wil niet zeggen dat het resultaat (na compilatie) van die code ook anders is als de source anders is.

Zo kun je commentaar toevoegen of bij xml bijv. de volgorde van elementen aanpassen zonder dat het resultaat anders wordt.


Aan de hand van jou businesscase kan ik maar 1 ding zeggen:
vind het wiel svp niet opnieuw uit

kijk eens hier, hier en hier.
Pak twee tooltjes (een lexer en een parser) en gebruik die om je eigen compiler te bouwen.

Nu kun je je parser gewoon aan je clients geven (moet je dus een windows client bouwen en een linux variant.. of.. ow shit.. je bouwt hem in java dat is crossplatform)

mocht je nou echt dmv een buildserver willen doen, draai dat ding daar. Ook prima.
Maar ga er in ieder geval voor zorgen dat je (wat hierboven al staat) je scope gaat aanpassen.

het bouwen van een compiler (wat je aan't doen bent) is een ding

het bouwen van een web-interface voor een buildserver die gebruik maakt van die compiler is iets heel anders.
Ook daarvoor geld: vind het wiel niet opnieuw uit.
Hierboven ook al gezegd: hoe doen buildservers het nu?

juist, ze halen code op uit bestaande repo's.
gebruik subversion oid om je code in te stoppen, en laat gebruikers gewoon in subversion inchecken.

Je hebt zat mogelijkheden om bestaande pakketten (gratis pakketten) te gebruiken om eerst via een veilige verbinding de code te downloaden, dan jouw compiler aan te schoppen met de juiste parameters en vervolgens de code weer te verwijderen.
Ik denk bijv. aan Jenkins

[ Voor 54% gewijzigd door BasieP op 10-12-2012 18:53 ]

[Gomez12]

Carharttguy schreef op maandag 10 december 2012 @ 14:57:
[...]
Is honderden of duizenden manjaren niet wat overdreven? Manuren zou ik nog ergens begrijpen.
Mijn programmeertaal zou worden omgezet naar html. En er zou dus een diff/patch moeten toegepast worden op die html, en dat is gewoon platte tekst, dus dat is perfect logisch.

Lol, heb je je eigen scope wel doorgelezen?

Je hebt het over lin/win/mac/android/ios etc etc en dan ook nog eens een taaltje of 10.
Wil je een beetje complexiteit bieden dan gaat er zomaar 1000 uur zitten in 1 taal op 1 platform. En dat dan dus x het aantal talen / platforms...

Laat ik het zo zeggen : java / .net gebruiken een VM en daarmee bestrijken ze nog niet eens een fractie van jouw scope.

BasieP schreef op maandag 10 december 2012 @ 18:39:
[...]
Nu kun je je parser gewoon aan je clients geven (moet je dus een windows client bouwen en een linux variant.. of.. ow shit.. je bouwt hem in java dat is crossplatform)

Java is nog geen ios, dus niet crossplatform genoeg. Wat dat betreft zou ik eerder aanraden om het te maken in zijn eigen compiler. Die is crossplatformer dan java als hij klaar is.

[BasieP]

Gomez12 schreef op maandag 10 december 2012 @ 19:36:
Java is nog geen ios, dus niet crossplatform genoeg. Wat dat betreft zou ik eerder aanraden om het te maken in zijn eigen compiler. Die is crossplatformer dan java als hij klaar is.

lol

nee serieus, ik denk dat zijn scope lang niet zo cross-platform is als hij zelf denkt.
Hij heeft het ook over websites.. volgens mij wil hij echt geen applicatie bouwen die kan draaien op scada systemen.
Hij heeft het niet zo opgeschreven, maar ik denk dat het met het 10 omgevingen echt wel klaar is.
windows, unix, linux(en), android, OsX, blackberryOs, etc.

[Gomez12]

BasieP schreef op maandag 10 december 2012 @ 19:46:
[...]
lol

Dit was een serieuze opmerking, zonder compiler is het zinloos om na te gaan denken over optimalisaties qua data-overdracht etc.

Normaal gesproken kan je rekening houden met dit soort dingen bij het initieel bouwen van de app, maar als het zo'n groot scala bestrijkt dan moet je tientallen implementaties gaan bouwen die allemaal platformspecifiek zijn (en dat was juist het hele idee achter de compiler) en dan is het tijdsverspilling.

Hij heeft het niet zo opgeschreven, maar ik denk dat het met het 10 omgevingen echt wel klaar is.
windows, unix, linux(en), android, OsX, blackberryOs, etc.

Ik weet even niet of java op blackberryOs draait, maar zoja dan gaat hij dus enkel java nabouwen en is het hele stuk over meerdere talen etc niet relevant.

Ik denk eerder dat TS nog helemaal niet weet wat hij wil gaan bouwen, en dat hij momenteel enkel maar futiliteiten aan het maken is om over 2 weken te zeggen : Ik kom er niet meer uit, ik kap er mee.