Discussie over de toekomst van ZFSguru

[Verwijderd]

@CurlyMo: Interessante posts heb je, daar zal ik apart op reageren. Dus niet denken dat ik je negeer.
Valt ook niet mee om overal op te reageren als jullie met zijn tienen tegen mij gaan tetteren. Ik kan snel typen maar nu moet ik ook nog nadenken wat ik zeg.

syl765 schreef op zaterdag 04 januari 2014 @ 23:36:
Wat in mijn ogen belangrijk is is dat een knop in de gui ook werkt.

Dan zit je bij ZFSguru best goed. Er zijn uitzonderingen, maar voor een beta doet ZFSguru het juist heel goed met best goed afgewerkte releases. Dat is ook wat maakt dat het langer duurt terwijl je dacht dat alles al klaar was; je wilt alles een beetje bijpoetsen en sommige dingen toch anders doen.

Tevens dient de basis solide te zijn. Als basis van zfsguru zie ik toch het fileserver gedeelte als hoofdmoot, inclusief wat geavanceerde netwerk instellingen zoals LACP enz.
Dus samba, nfs en een duidelijke installer. Heb je dat op orde, dan kun je gaan werken aan de services.

Dat is bij ZFSguru dus wel anders gelopen; services is juist heel veel aandacht aan besteed. Niet de services zelf zozeer maar de infrastructuur en build environment om dit mogelijk te maken.

Maar de gedachte was ook dat goede services zoals Virtualbox, Transmission en SABnzbd+ met goede integratie in ZFSguru het soort users aanspreekt wat ZFSguru probeert aan te boren. Die moeilijk bereikbare 'Windows-watjes' () met watervrees voor Linux laat staan UNIX. Voor deze gebruikers zijn FreeNAS en NAS4Free veel moeilijker bereiken dan ZFSguru. Dit terwijl ZFSguru ook prima gebruikt kan worden door meer ervaren gebruikers.

Wat betreft de netwerkfunctionaliteit was de gedachte dus dat ervaren gebruikers LACP en static IP wel konden instellen. Maar andersom zouden 'newbies' veel moeite hebben om zelf SABnzbd+ of transmission te installeren. En voor virtualbox heb je ook nog kernel sources nodig; nee dat gaat hem niet worden. Maar met één-druk-op-de-knop-en-het-werkt kan zelfs Jan met de pet een ZFS server draaien. En dat was nou precies het doel van ZFSguru toen Jason het project begon: om ZFS naar een breder publiek te krijgen en zodoende een acceptabel niveau van bescherming te bieden. Al het andere is gewoon van een ander tijdperk, zeker zodra Btrfs en ReFS ook aanschuiven bij volwassen 3e generatie filesystems, en wellicht nog meer in de toekomst (zo heeft BSD ook nog HammerFS).

Wat ook belangrijk is zijn toch de monitor functionaliteiten zoals een zabbix, of nagios client. Zeker de zakelijke gebruikers willen graag dit soort zaken op orde hebben.

Nagios is ook beschikbaar als service. Geen dingen standaard integreren die mensen niet willen, tenzij het gewoon basisfunctionaliteit is. Nagios is dat niet, dus moet het als addon.

De meeste gebruikers zullen zfsguru toch als fileserver gaan inzetten en niet als werkstation.

Werkstation/Workstation zei ik ook niet, maar Modulair Server OS. Server OS die ook grafisch bediend kan worden, zoals met name Windows-gebruikers gewend zijn die bijvoorbeeld een FTP server draaien op Windows.

Maar server kan heel veelzijdig zijn. Misschien willen mensen hun eigen mailserver gaan draaien en eigen 'cloudstorage' met Owncloud bijvoorbeeld, na de onthullingen over aftappen en afluisteren wat ook Google Gmail treft. Het idee is dat ZFSguru een modulaire totaaloplossing kan zijn, waarbij je dus van alle services kunt kiezen welke extra functionaliteit je wilt hebben bovenop de standaard basis functionaliteit. Wil je alleen een NAS dan installeer je geen services, hoef je ook niet de troep te draaien die anderen wel willen. Lekker schoon!

Dan noemde je nog wat jullie allemaal zouden willen toevoegen aan zfsguru.
Webserver, mailserver, firewall enz. Ik denk persoonlijk dat je dit niet te veel moet doortrekken.
Een firewall is een project op zich kijk maar eens naar pfsense, is al jaren bezig en nog steeds niet af. En een firewall hoort naar mijn idee niet op je fileserver (buiten wat lokaal filteren) maar gewoon tussen je WAN en LAN te zitten.

Webserver (Apache+MySQL) is er als service.
Mailserver is er als service
Firewall zit al in BSD, de 'pf' Packet Filter firewall van OpenBSD, een van de betere firewalls die ook NAT en traffic shaping kan doen.

Aangezien ZFSguru een ServerOS is, moeten die services die aangeboden worden wel afgeschermd kunnen worden. Er zijn al duidelijk plannen bij Jason hoe de firewall eruit moet zien, althans de Easy Configuration; je kunt als advanced user gewoon direct de file aanpassen via de GUI. Maar het idee is dat iedereen de Firewall moet kunnen gebruiken. Dus NAT instellen moet makkelijk zijn, maar ook toegang afschermen voor de ZFSguru web-interface, voor de webserver, voor Samba/NFS/iSCSI en wat niet al. Dat moet allemaal op een makkelijke manier kunnen en Jason is goed in schetsjes maken hoe hij dat voor zich ziet. Dat levert een heel ander soort Firewall-configuratie-UI op dan gebruikelijk is.

Ook een firewall is belangrijk als gebruikers hun ZFSguru server op internet willen aansluiten. Nu al doen mensen dat, terwijl ZFSguru daar helemaal niet klaar voor is, in elk geval niet out of the box. Maargoed, een firewall is dus wel nodig als ZFSguru echt een multi-purpose server OS wilt worden, wat ook gebruikt wordt enkel voor de services en ZFS misschien meer als bijzaak. Mooi meegenomen.

pfSense ken ik niet zo erg; maar ik vermoed dat het een erg uitgebreide webGUI is waar je heel veel geavanceerde netwerkconfiguraties via GUI kunt managen. Dat gaat ZFSguru niet maken. Het moet veel simpeler en laagdrempeliger. ZFSguru is er voor iedereen.

Misschien is het wel een mooi idee om bijvoorbeeld een web of mailserver als bhyve machine te kunnen starten op je basis zfsguru machine. Zo houd je de geinstalleerde zfsguru mooi schoon en draaien die andere machines op de bhyve hypervisor.

ZFSguru doet het nu met Virtualbox (en QEMU wat ruk is). Betere virtualisatie komt later wel aan bod. Maar goed ook, want Xen en BHyVe hebben nog wel even tijd nodig om te rijpen. Maar het gaat zeker cool worden paravirtualisatie op BSD!

Zou zonde zijn als ZFSguru blijft hangen in enkel een ZFS web-interface. De huidige interface afbouwen en alvast ruim naar voren kijken is beter, we hebben nog meer mooie plannen!

[dylanvana]

Ik heb even naar de website gekeken en het volgende viel mij meteen op

- waarom worden er geen tabs gebruikt in de source code? ziet zfsguru zelf er ook zo uit?
- waarom worden er verschillen stijlen gebruikt voor het noemen van css-elementen en html_attributen in de source?
- waarom draait een "professioneel" product op een shared hosting pakketje?
- waarom die afschuwelijke grijze gradient overlay in de layout en menuknoppen?

Dit is niet persoonlijk, ik waardeer jouw posts enorm op Tweakers

[Verwijderd]

ZFSguru.com website broncode
Website is gebaseerd op oude code die Jason in een verleden voor een klant had geschreven. Dat is gewoon omdat hij liever geen Wordpress ofzo wilde draaien uit veiligheidsoverwegingen. Er is een nieuwe website die we aan het bouwen zijn. Ontwerp is al een beetje klaar en Mesa zal als CMS gaan dienen. Van de zomer online moet je aan denken, misschien eerder. Maar hij wordt wel heel mooi, ook weer veel ideeën over.

Indents in de sourcecode
ZFSguru zelf gebruikt spaties als indents; regels mogen max 80 tekens zijn dus dan is tabs minder praktisch. Tabs worden enkel gebruikt bij array definities, dat wordt aardig consistent aangehouden.

Afschuwelijk grijs
En die grijze tinten; die zie je ook hier op Tweakers.net nietwaar? Mooi grijs is niet lelijk, maar lelijk grijs wel. ZFSguru heeft nu niet zo'n mooie interface. Onduidelijk ook en soms moeilijk te lezen die pagina's bovenaan. Nieuwe theme zit er dus ook wel aan te komen, maar er zijn ook (wilde) plannen voor een mobiele interface en hoe die eruit moet zien, zodat je ZFSguru met je iPhone bedient.

ZFSguru servers
ZFSguru heeft een eigen VPS 100 megabit, één dedicated server op 50 megabit. Maar we willen een dedicated server op AIX, meer dan 100 megabit zou helemaal gaaf zijn voor lekker snel kunnen downloaden. Gemiddeld is het nu geloof ik 400GB per maand aan downloads van .iso en services.

Kosten zijn natuurlijk wel een issue, het wordt allemaal uit Jasons zak betaald.

[Wouter.S]

Verwijderd schreef op zondag 05 januari 2014 @ 01:57:
ZFSguru.com website broncode
Kosten zijn natuurlijk wel een issue, het wordt allemaal uit Jasons zak betaald.

Dat is natuurlijk nog zoiets wat met een actieve community wel opgelost kan worden. Ik heb namelijk wel een donatie over voor een product dat ik al meer dan twee jaar gebruik

[HyperBart]

Verwijderd schreef op zondag 05 januari 2014 @ 01:57:
ZFSguru.com website broncode
Website is gebaseerd op oude code die Jason in een verleden voor een klant had geschreven. Dat is gewoon omdat hij liever geen Wordpress ofzo wilde draaien uit veiligheidsoverwegingen. Er is een nieuwe website die we aan het bouwen zijn. Ontwerp is al een beetje klaar en Mesa zal als CMS gaan dienen. Van de zomer online moet je aan denken, misschien eerder. Maar hij wordt wel heel mooi, ook weer veel ideeën over.

Als ik dat lees, dan denk ik weer van: "god, weer een project, weer iets waar die jongens tijd aan moeten besteden". Over die veiligheidsoverwegingen: ik begrijp ECHT niet dat Jason voor een eigen ontwikkeld pakket kiest als er pakketten zijn waar veel meer mensen (en dus waarschijnlijk ook kennis) aan besteed hebben. Ok, daar kunnen veiligheidslekken in zitten en als die gevonden zijn, zijn ineens X aantal gebruikende organisaties geimpacteerd, maar ik heb nu het gevoel dat jullie een beetje een CMS gaan ontwikkelen om er dan achter te gaan staan en zeggen: "kijk wij zijn veilig" gewoon omdat niemand het bijna gebruikt en dus aanvalt of vulnerabilities in gaat zoeken bij jullie.

[Verwijderd]

@Wouter.S
donaties hadden inderdaad meerdere mensen wel voor over. Punt is wel dat Jason een beetje schuw en terughoudend is op dat vlak. Bang dat hij is dat donaties ook verwachtingen scheppen en hij straks in een positie zit waar de donaties tegen hem kunnen keren. Zeker nu ZFSguru nog niet een 'mature' product is. Hij dacht: eerst 0.2 de deur uit dan zijn donaties misschien van toepassing. Maar dat duurt nu ook al langer. Op termijn zal het er wel van komen want zoals je zegt hebben velen wel een kleinigheid over voor een project als dit. Beter besteed dan de directeurssalarissen van de 'goede doelen' tegenwoordig.

@HyperBart
Nee hoor, een CMS is een goede basis voor meer interface-werk wat we kunnen gaan verrichten in de toekomst, en dient als basis voor de nieuwe website en tevens de library-rewrite van ZFSguru waarbij code wordt opgelapt en netjes in Mesa wordt gezet. Mesa is dan eigenlijk de schone rewrite van ZFSguru libraries, plus de extra's die het een CMS maken. De basis is al functioneel, maar er moet nog wat gebeuren voordat het voor de website kan worden ingezet. En nagedacht worden over een forum. In de tussentijd zouden we naar een ander pakket kunnen, om later weer naar Mesa Forum te migreren.

En wees ook eerlijk HyperBart; er worden best veel sites gehacked omdat er oude WordPress e.d. op draaien. Dat soort pakketten zijn gewoon magneten voor exploit-jagers die als het ware visnetten in cyberspace hebben uitgezet. Veilige code is één, maar buiten de scrutiny blijven is een tweede. Laten we geen discussie houden over security filosofie, dan kunnen we beter een nieuw topic beginnen.

Jason heeft gewoon gebruikt destijds wat hij had. Dat de website nu niet zo mooi en goed is qua functionaliteit vooral op het forum, is geen ramp. Het doet wat het doet. Iets beters komt vanzelf. Maar de veiligheid is beter geregeld dan wanneer hij WordPress had geïnstalleerd, ben ik zeker van mening. Dus wat is nu precies het probleem?

Edit: even ter verduidelijking: de security-punten zijn van toepassing op het op dezelfde server draaien als de twee master servers, zodat als WordPress gehackt zou worden, dit betekent dat ZFSguru gebruikers trojans binnenkrijgen. Dat is dodelijk voor het project; veiligheid is belangrijk! Dat is juist in het belangrijk van jullie gebruikers, dus vecht daar niet tegen zou ik zeggen. Als we binnenkort een nieuwe server krijgen met meerdere IPs en vele jails, dan is het draaien van onveilige pakketten niet zo'n probleem. En up-to-date pakketten zal het ook wel meevallen met exploits, maar het gaat niet enkel om onze systemen maar ook om die van jullie. Logisch en juist goed dat we extra voorzichtig zijn?!

Edit2: nu ik je reactie nog eens lees denk ik vooral dat je je afvraagt waarom we een CMS maken. We maken geen uitgebreid CMS zoals de grote open source alternatieven, die zijn er zat, daar heb je gelijk in. Het gaat om een heel toegankelijk en laagdrempelig CMS wat ZFSguru gebruikers met 'een druk op de knop' kunnen activeren en met een port forward zomaar online zijn met hun eigen website. Dat vinden ze gaaaaaf! Wij misschien niet meer zo. Maar beginners willen experimenteren en moeten dat ook kunnen. Bovendien is het voor eigen gebruik heel fijn en in de toekomst kan de modulaire strategie alleen maar groeien. Maar in dat tijdperk komt inderdaad de vraag over contributie weer aan de orde. Laten we dat bewaren voor een andere dag.

[ Voor 27% gewijzigd door Verwijderd op 05-01-2014 03:12 ]

[syl765]

Ik denk niet dat eigen software per definitie veiliger is.
Sterker nog dat is eerder onveilig. Iedereen programmeerd met een bepaalde gedachte gang. Nu kun je denken dat deze gedachte gang de juiste is en dat het daarmee dus veilig is.
Echter zijn er dus ook zaken waar men niet aan denkt. En dat maakt je software dus onveilig.
Gebruik je wordpress, joomla, drupal of wat voor cms dan ook, dan weet je in ieder geval dat de huidige versie goed is.
En mocht er een security issue zijn dan is deze vaak binnen een hele korte tijd verholpen.
Dus inplaats van je eigen cms in de lucht te helpen wat heel veel tijd kost, hoef je voor een bestaande oplossing alleen te zorgen dat je up to date blijft.
En dat kost veel minder tijd. Ik zie alleen maar voordelen.

Als de eigen code een exploit bevat ben jij de enige die moet gaan zoeken waar dat zit! Dat kost tijd, heel veel tijd. Zeker gezien je dacht dat alles in orde was. Wat zien de gebruikers, website offline. Achter de schermen is er heel veel stress. Ik zie alleen maar nadelen.

Nu kan wordpress en joomla ook een exploit bevatten die in het wild uitgebuit word. Maar deze worden snel opgemerkt. Desnoods haal je dan ook de site even offline met een mooie mededeling dat de site i.v.m exploit xyz uit de lucht is. De community begrijpt dit.
Ondertussen kun je verder met belangrijke zaken, andere lossen die exploit voor je op, zijn ze klaar, patchen en weer verder.

Gr

[Dadona]

Met deze insteek gaan jullie de SSL implementatie ook nog aanpakken.

Waar ik vooral benieuwd naar ben is hoe de veiligheid eruit gaat zien, wetende dat je bij updates van ZFSguru eigenlijk moet wachten op een nieuwe versie van ZFSguru of een nieuw aangeleverde system image. Het zelfstandig updaten van een plugin werd althans afgeraden. Zeker als er ook nog zaken als een mailserver / CMS / ... gaat invoeren.

Stel je zou Wordpress toevoegen dan moet je snel bij kunnen werken. Bij mesa ook, maar ik vermoed dat daar in eerste instantie vooral de uitdaging bij het vinden van kwetsbaarheden ligt. Uiteindelijk moet je hopen dat ZFSguru niet aantrekkelijk genoeg is om uit te zoeken (of te ondoorgrondelijk is). Anders ga je echt Wordpress in het klein achterna. Want uiteindelijk bevat alle code kwetsbaarheden en moet beveiliging er van de grond af aan doorheen zitten. Niet een achteraf gedachte zijn.

[FireDrunk]

Wat we natuurlijk wel helder moeten houden is: In hoeverre ga je je storage bak (welke eigenlijk in een private lan staat) ook nog weer eens aan het internet hangen...?

Dat is sowieso natuurlijk geen goed idee, en ook niet een scenario waar de developers rekening mee hoeven te houden.

Wat wel belangrijk is, is dat de basis veilig is. Ik bedoel, als ik zelf aan de veiligheid ga sleutelen kan ik natuurlijk alles kapot maken, maar ik kan zelfs niets doen aan bijvoorbeeld de sudo rechten van de www user.

ZFSguru moet het zo veilig mogelijk maken binnen de context dat het zou moeten werken.
Private LAN, < 10 gebruikers in eerste instantie, Gebruikers met weinig tot geen kennis van inhoudelijke security van BSD, maar wel gebruikers die snappen dat je een server niet direct aan het internet moet hangen zonder (insert security maatregel).

Dat lijkt mij de basis.

[FireDrunk]

http://redmine.eeplug.com/

Astu, registratie staat open.

PS: Er draaien nog meer projecten onder deze Redmine, mocht je iets kunnen zien wat er niet hoort, stuur even een DM, als het goed is is alleen het project ZFSguru public.

[jacovn]

Ik draai ook liever pfsense op een zuinige pc dan dat ik een zfsguru nas 24x7 moet laten draaien.. (In mijn geval 26 watt voor de firewall, en 150 voor de nas)
Verder heeft dat ook een geweldige community waar je vragen kunt stellen, en antwoorden kunt vinden.
Beetje lastig om dat allemaal te willen intergreren.
Er zijn ook veel packages om bijvoorbeeld IDS functionaliteit implementeren. Als je dat ook allemaal moet gaan porteren en onderhouden..

[Q]

FireDrunk schreef op zondag 05 januari 2014 @ 11:41:
Wat we natuurlijk wel helder moeten houden is: In hoeverre ga je je storage bak (welke eigenlijk in een private lan staat) ook nog weer eens aan het internet hangen...?

Dat is sowieso natuurlijk geen goed idee, en ook niet een scenario waar de developers rekening mee hoeven te houden.

Wat wel belangrijk is, is dat de basis veilig is. Ik bedoel, als ik zelf aan de veiligheid ga sleutelen kan ik natuurlijk alles kapot maken, maar ik kan zelfs niets doen aan bijvoorbeeld de sudo rechten van de www user.

ZFSguru moet het zo veilig mogelijk maken binnen de context dat het zou moeten werken.
Private LAN, < 10 gebruikers in eerste instantie, Gebruikers met weinig tot geen kennis van inhoudelijke security van BSD, maar wel gebruikers die snappen dat je een server niet direct aan het internet moet hangen zonder (insert security maatregel).

Dat lijkt mij de basis.

Ik weet niet precies hoe de meeste van dit soort NAS oplossingen in elkaar zit, maar her probleem dat ze commando's als Root moeten uitvoeren, kennen ze allemaal.

Ik zou zelf een lokale daemon service maken die op local host draait en die een API ter beschikking stelt aan de webinterface. Deze daemon heeft root rechten. De web interface niet. Zelfs als je de interface hackt, kun je alleen api-calls naar de daemon doen en geen arbitrary code executen met root rechten.

Maar aan internet wil je het sowieso nooit ever hangen. Ik zie daar toch weer verlies van focus betreffende het project: ook een cms achtig iets hosten op ZFSguru.

---

Mijn gedachte over ZFSguru:

Ik ben zelf niet de doelgroep, maar oorspronkelijk was het doel van het project om een zelfbouw-NAS distro te maken dat ook mensen met weinig technische kennis de geneugten van ZFS kunnen ervaren.

Het enige wat ZFSguru dan zou moeten kunnen doen is:

1. ZFS filesystems beheren op disks
2. storage delen via SMB / AFP / NFS
3. Management interface
4. User management (security op files)
5. Secure

FreeNAS is erg uitgebreid en pluggable. Maar daarmee ook behoorlijk ingewikkeld geworden. Als je je wilt differentieren wil je meer een apple-style aanpak: minimale features, maar wat er is, is uitstekend en daar kun je eventueel op voortborduren.

Dit zou een flinke beperking van de scope zijn. Dit zou echter een heel realistisch project kunnen zijn. Ergens heb ik de illusie dat ik dat met Python en Django zelf in mijn eentje nog in elkaar zou kunnen zetten, gegeven een jaar ofzo.

Iedereen wil altijd open en pluggable zijn en modulair, en vrijheid etc. Maar dat is flauwekul. Kijk naar apple: die is gesloten als een oester, die maakt keuzes voor jou. En zie hoeveel mensen daar heel erg blij mee zijn. Zij hebben onvoldoende kennis om zelfs de juiste keuzes te kunnen maken. Ga die mensen niet (in eerste instantie of nooit) opzadelen met iSCSI of SLOGof verpak het zodanig dat ze het snappen en er iets mee kunnen dat voor hen iets betekent.

Edit: dingen als LACP: echt niet, laat zitten. Waar ligt de focus? Als je met LACP wilt kloten, ga dan naar FreeNAS, dan ben je een meer advanced gebruiker. Die heeft al dat soort zooi met iSCSI en weet ik wat. Dan ben je ZFSguru of hoe het product ook heet misschien ontgroeid. Maar velen hebben daar geen behoeften aan en zijn prima blij met wat ze krijgen.

[ Voor 39% gewijzigd door Q op 05-01-2014 13:27 ]

[FireDrunk]

Exact, dat lijkt mij ook de beste oplossing. Nadeel is weer dat je die Daemon in een andere taal moet schrijven (C/C++, Perl, Python, w/e)

[Q]

Python, Perl of Ruby. Zeker geen taal met risico op buffer overflows en bovendien: die talen hebben allelei libs waarmee je zo'n daemon volgens mij in 10 regels code schrijft 'bij wijze van spreken'. Niet opnieuw het wiel uitvinden, nergens voor nodig

[CurlyMo]

Zoals eerder aangegeven, met de juiste kennis, zijn die dingen niet zo complex. Of het nu een daemon is of een mini webserver.

Het probleem is overigens ook gewoon op te lossen door sudo te gebruiken. Je zet dan gewoon in je /usr/local/etc/sudoers bestand alle commando's die je php script zonder wachtwoord mag aanroepen. Je php script draait dan standaard als een non-root gebruiker.

[EnerQi]

In eerdere posten in dit topic staat dat Jason een Server-OS wil maken, geen NAS-OS. Waar het straks naar toe gaat voor gebruikers, zijn dus 2 servers: 1 met servertaken (veel services enabled), 24/7 en energiezuinige SSD, 1 met NAS taken (geen/minimale services), wake on lan, vol harde schijven van x TB. Waardoor de gebruiker dus zelf een splitsing maakt wie aan welke data mag zitten (meer veiligheid)

Of ik heb het niet begrepen

[CurlyMo]

Ze zijn prima verenigbaar als je maar weet wat je doet.

[Q]

Verwijderd schreef op zondag 05 januari 2014 @ 01:57:
Maar we willen een dedicated server op AIX,

? IBM AIX?

[FireDrunk]

Verwijderd schreef op zondag 05 januari 2014 @ 01:57:
ZFSguru servers
ZFSguru heeft een eigen VPS 100 megabit, één dedicated server op 50 megabit. Maar we willen een dedicated server op AIX, meer dan 100 megabit zou helemaal gaaf zijn voor lekker snel kunnen downloaden. Gemiddeld is het nu geloof ik 400GB per maand aan downloads van .iso en services.

Kosten zijn natuurlijk wel een issue, het wordt allemaal uit Jasons zak betaald.

Mijn VPS hangt aan gigabit met 2TB 5TB traffic in de prijs inbegrepen...

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 01:32:
@CurlyMo: Interessante posts heb je, daar zal ik apart op reageren. Dus niet denken dat ik je negeer.
Valt ook niet mee om overal op te reageren als jullie met zijn tienen tegen mij gaan tetteren. Ik kan snel typen maar nu moet ik ook nog nadenken wat ik zeg.

Ik wacht het af. Gezien de tijd die je er voor neemt wordt het vast een kei van een reactie (wetende hoe snel je normaal reageert)

[ItsValium]

Mocht dit nodig zijn kan ik altijd wel eens kijken wat ik kan aanbieden qua serverinfrastructuur. Heb wel nog wat spare units vrij in mijn racks. Of een goede VPS kan natuurlijk ook en kan meeschalen met de noden. Uplink kan van 10 mbit tot 10gbit

[Verwijderd]

Het idee qua serverinfrastructuur is dat we straks een goede dedicated hebben draaien op de AmsIX die heel veilig is. Zeg maar de primary master server. De overige servers syncen met de master node. Dat maakt het makkelijk om anderen te vragen om ZFSguru master servers te draaien, zodat bijvoorbeeld ook in China, Australië of Latijns-Amerika er servers dichtbij zijn. De web-interface heeft nu één preferred master server die je instelt op een server die dichtbij is. Mocht die falen dan worden de andere servers willekeurig aangesproken. Zo kan één server die down is niet voor veel problemen zorgen.

Maar een rogue master server is nog wel een probleem. Dus een certificaat-structuur zodat de GuruDB authenticated (wat is dat in het nl? ) kan worden en als dat niet klopt weigert hij de GuruDB van de gekozen master server en kan het andere master servers proberen. Dan is de enige point of failure nog de alpha server. Aangezien die gewoon static files serveert kunnen we dat enorm veilig maken. Dus dan is de server security best goed geregeld.

In het verleden heeft ZFSguru ook geëxperimenteerd met rTorrent in een jail en dat gebruiken voor ZFSguru torrents. Maar dat was geen groot succes. Sommige code van torrent distributie zit nog in ZFSguru; wellicht ooit te vervangen als ZFSguru echt veel groter wordt.

Mensen die zelf hosting ter beschikking willen stellen aan ZFSguru, zouden dit dan met een simpele howto kunnen doen. Cronscript om te syncen om de zoveel tijd, files en permissies op de document root en configureren van de webserver jail. Wellicht is het tevens mogelijk om hier een ZFSguru service van te maken. Dan is het opzetten van ZFSguru master servers natuurlijk kinderlijk eenvoudig, en kun je zelf bijvoorbeeld ook je eigen master server draaien als je meerdere ZFSguru servers hebt. Allemaal toekomstmuziek voorlopig nog, maar zulke plannen kan ik wel enthousiast van worden. De mogelijkheden, de flexibiliteit. Met software is vrijwel alles mogelijk.

[FireDrunk]

Je gaat nu toch niet aanraden om ZFSguru aan het internet te hangen
Dat is je eigen doodsteek...

[CurlyMo]

Server synchronisatie is kinderlijk eenvoudig met rsync (via ssh of ftp).

[ Voor 7% gewijzigd door CurlyMo op 05-01-2014 17:23 ]

[Verwijderd]

@FireDrunk: ZFSguru aan internet hangen is nu niet zo'n goed idee, maar in de toekomst zeker wel. De firewall is belangrijk zodat je controle hebt over welke services toegankelijk zijn vanaf het internet. Zo wil je poort 22 (SSH) misschien een select aantal IPs houden van thuis/werk/vrienden. Poort 80 kun je dan op een webserver draaien met veilige permissies, dus ofwel www-user onklaar maken of onder andere user draaien. Ook kun je de webserver zelf nog eens jailen, maar als de webserver de enige service is die op ZFSguru draait, dan is dat in principe overbodig.

Natuurlijk ga je niet je NAS zomaar aan internet hangen. Maar je kunt bijvoorbeeld meerdere ZFSguru-instances draaien op dezelfde box, met BHyVe virtualisatie bijvoorbeeld. Zo kun je nog beter dan jails de privilege separation bewaken.

Simpele thuisgebruikers doen natuurlijk domme dingen. Nu al worden ZFSguru servers op internet gegooid, die ben ik soms tegengekomen met Google. Beetje dom. Maar in de toekomst wordt dat voor gebruikers wel veel makkelijker gemaakt en vooral veel veiliger om ZFSguru aan internet te hangen. Dan gaat ZFSguru ook gebruikt worden voor niet-NAS-achtige taken. ZFS blijft natuurlijk een heerlijk fundament.

@CurlyMo: is nu gewoon HTTP, het zijn nu tekstfiles. Binnenkort gaan we over op GuruDB. Dat werkt met serienummers zodat je niet de hele DB hoeft te downloaden als de versie die je al hebt de nieuwste is. Dat werkt nu nog niet, er is alleen wat tijdgebonden caching in de web-interface (client side). GuruDB verenigt bovendien alle losse files in één compressed document, met checksum.

[ Voor 14% gewijzigd door Verwijderd op 05-01-2014 17:15 ]

[HyperBart]

Q schreef op zondag 05 januari 2014 @ 13:03:
[...]


Ik weet niet precies hoe de meeste van dit soort NAS oplossingen in elkaar zit, maar her probleem dat ze commando's als Root moeten uitvoeren, kennen ze allemaal.

Ik zou zelf een lokale daemon service maken die op local host draait en die een API ter beschikking stelt aan de webinterface. Deze daemon heeft root rechten. De web interface niet. Zelfs als je de interface hackt, kun je alleen api-calls naar de daemon doen en geen arbitrary code executen met root rechten.

Maar aan internet wil je het sowieso nooit ever hangen. Ik zie daar toch weer verlies van focus betreffende het project: ook een cms achtig iets hosten op ZFSguru.

---

Mijn gedachte over ZFSguru:

Ik ben zelf niet de doelgroep, maar oorspronkelijk was het doel van het project om een zelfbouw-NAS distro te maken dat ook mensen met weinig technische kennis de geneugten van ZFS kunnen ervaren.

Het enige wat ZFSguru dan zou moeten kunnen doen is:

1. ZFS filesystems beheren op disks
2. storage delen via SMB / AFP / NFS
3. Management interface
4. User management (security op files)
5. Secure

FreeNAS is erg uitgebreid en pluggable. Maar daarmee ook behoorlijk ingewikkeld geworden. Als je je wilt differentieren wil je meer een apple-style aanpak: minimale features, maar wat er is, is uitstekend en daar kun je eventueel op voortborduren.

Dit zou een flinke beperking van de scope zijn. Dit zou echter een heel realistisch project kunnen zijn. Ergens heb ik de illusie dat ik dat met Python en Django zelf in mijn eentje nog in elkaar zou kunnen zetten, gegeven een jaar ofzo.

Iedereen wil altijd open en pluggable zijn en modulair, en vrijheid etc. Maar dat is flauwekul. Kijk naar apple: die is gesloten als een oester, die maakt keuzes voor jou. En zie hoeveel mensen daar heel erg blij mee zijn. Zij hebben onvoldoende kennis om zelfs de juiste keuzes te kunnen maken. Ga die mensen niet (in eerste instantie of nooit) opzadelen met iSCSI of SLOGof verpak het zodanig dat ze het snappen en er iets mee kunnen dat voor hen iets betekent.

Edit: dingen als LACP: echt niet, laat zitten. Waar ligt de focus? Als je met LACP wilt kloten, ga dan naar FreeNAS, dan ben je een meer advanced gebruiker. Die heeft al dat soort zooi met iSCSI en weet ik wat. Dan ben je ZFSguru of hoe het product ook heet misschien ontgroeid. Maar velen hebben daar geen behoeften aan en zijn prima blij met wat ze krijgen.

^^ dat dus. Ik was eigenlijk nog het meest gelukkig met de eerste versies van ZFSguru voor ik dit allemaal wist... Als dat de weg is die ZFSguru gaat in slaan of volop aan aan het timmeren is, dan haak ik af.

Dan hoop ik oprecht dat er hier enkele Tweakers op staan en datgene doen wat hierboven staat. Puur en alleen een web interface bouwen die commandootjes op de shell uitvoert. Wil ik iets meer? Prima, dan duik ik zelf wel in de shell en installeer de nodige software zelf wel.

Het is zelfs zo erg dat ik mij nu gewoon zorgen om mijn data begin te maken op ZFSguru... Zie het maar als een motie tot wantrouwen, maar voor mij gaat het ZFSGuru verhaal dan snel stoppen...

[CurlyMo]

Dan hoop ik oprecht dat er hier enkele Tweakers op staan en datgene doen wat hierboven staat. Puur en alleen een web interface bouwen die commandootjes op de shell uitvoert. Wil ik iets meer? Prima, dan duik ik zelf wel in de shell en installeer de nodige software zelf wel.

Zelf gebruik ik nog steeds ZFSguru beta 7, en dan alleen voor:
- Home --> Status
- Disk --> Formatting en Smart
- Pools --> Pool Status en Create

Meer niet. De rest doe ik handmatig via de shell. In die zin ben ik het dus met je eens. Wat let het ZFSGuru om een vinkje in te voeren die zegt, "Show only Bare NAS webGUI information". Dan houdt je ons ook te vriend

---

Ik zou het overigens wel relax vinden als alle script die ik handmatig heb toegevoegd geautomatiseerd zouden worden.
- Dagelijkse snapshots van bepaalde filesystem (max. 30):

code:

[root@server /data/snapshots/curlymo]# ls -Al
drwxr-xr-x  2 curlymo staff  10 Jan  3 00:00 GMT-2014.01.02-23.00.00
drwxr-xr-x  2 curlymo staff  10 Jan  4 00:00 GMT-2014.01.03-23.00.00
drwxr-xr-x  2 curlymo staff  10 Jan  5 00:00 GMT-2014.01.04-23.00.00
[root@server /data/snapshots/curlymo]# ls -AlR GMT-2014.01.04-23.00.00
lrwxr-xr-x  1 curlymo staff  59 Jan  5 00:00 Movies -> /data/shared/Movies/.zfs/snapshot/GMT-2014.01.04-23.00.00/
lrwxr-xr-x  1 curlymo staff  57 Jan  5 00:00 Series -> /data/shared/Series/.zfs/snapshot/GMT-2014.01.04-23.00.00/
lrwxr-xr-x  1 curlymo staff  57 Jan  5 00:00 Work -> /data/curlymo/Work/.zfs/snapshot/GMT-2014.01.04-23.00.00/

- Dagelijkse email met de temperaturen en statussen van mijn HDD's (ook om de mailserver te blijven testen).
- Om de 4 uur een check of de pools nog werken zoals het hoort (bij fout een email).
- Automatische IP adres checker voor mijn proftpd configuratie.
- Een rdiff-backup mogelijkheid met externe pools of externe HDD pools.

[ Voor 47% gewijzigd door CurlyMo op 05-01-2014 17:41 ]

[Verwijderd]

@HyperBart:
Om welke reden dan? Je hebt toch precies wat je wilt hebben?

Even het lijstje quoten wat je vetgedrukt gequote had:

Het enige wat ZFSguru dan zou moeten kunnen doen is:

1. ZFS filesystems beheren op disks
2. storage delen via SMB / AFP / NFS
3. Management interface
4. User management (security op files)
5. Secure

• 1. Je kunt ZFS filesystems e.d. beheren, dat is allemaal redelijk 'af'.
• 2. Bestanden delen via SMB/AFP/NFS werkt ook, alleen die support zijn we nu aan het verbeteren (beta9). Dat is de kern van het project.
• 3. Management interface is niet erg specifiek, maar dat is ongeveer wat ZFSguru web-interface is toch?
• 4. User management, ook dit komt in beta9
• 5. Secure, dit is voor de toekomst. Ik werd zelfs nog bekritiseerd over de meest veilige oplossing een tijdje terug.

Kortom, wij werken nu toch aan de belangrijke dingen? Het is toch niet dat we gekke dingen aan het doen zijn? Voor de toekomst zijn er grote plannen en dan zullen er inderdaad zijwergen ingeslagen worden. Maar dan zijn we ook een episode verder waar ZFSguru een goed bruikbaar stabiel product geworden is. Dat wij in die fase van het project verder werken aan andere dingen in het verlengde ervan is juist goed. Hoe jij het bedoelt klinkt alsof er allemaal junk in ZFSguru terecht gaat komen. Maar je vergeet de modulaire strategie van ZFSguru: jij hoeft geen dingen te draaien die je niet wilt.

Kortom, waar maak je je druk om?

[ Voor 12% gewijzigd door Verwijderd op 05-01-2014 17:54 . Reden: vetgedrukte quote toegevoegd ]

[FireDrunk]

Hij bedoelt denk ik dat jullie door jullie service structuur gebruik van de laatste portstree uitsluiten. Gewoon patches installeren is er niet bij zonder dat je bang hoeft te zijn dat er iets breekt.

[Verwijderd]

Dat is toch onzin? Het is toch niet anders dan dat je op FreeBSD een boel packages installeert, en een maand later er nieuwere versies uitzijn? Als je dan je portstree update en een nieuwe port gaat installeren, kun je ook problemen krijgen omdat die nieuwe poort nieuwere versies van al reeds geïnstalleerde software wilt gebruiken.

Oplossing is om eerst alle packages te updaten, met portupgrade of portmaster is dat het makkelijkst. Maar voor de duidelijkheid: dit is een BSD-issue geen specifiek issue wat ZFSguru kent.

Als de build environment zover gevorderd is dat we wekelijks volautomatisch kunnen releasen, is het ook veel fijner om bij de binary releases te blijven. Sneller en makkelijker te installeren en je kunt gemakkelijk terug als een nieuwe versie problemen geeft, en je hebt feedback van de community over exact die versie. Dan gebruiken ZFSguru users exact dezelfde code. Als er een probleem is in die code, zou het dus goed reproduceerbaar moeten zijn bij andere gebruikers. En dat kom je via communicatiekanalen ('in-game support') vlug te weten.

[CurlyMo]

@FireDrunk, Klopt, zo dacht ik ooit dat het maken van een eigen services tool minder werk zou zijn dan het aanleren van het maken van deb's (voor het debian apt systeem)

Doe dan hetzelfde wat je met debian ook kan doen. Meerdere servers instellen waarvan je programma kan installeren.
http://www.freebsd.org/do...pdate-server/article.html
http://www.daemonology.net/freebsd-update/binup.pdf

[Q]

Verwijderd schreef op zondag 05 januari 2014 @ 17:08:
Simpele thuisgebruikers doen natuurlijk domme dingen. Nu al worden ZFSguru servers op internet gegooid, die ben ik soms tegengekomen met Google. Beetje dom. Maar in de toekomst wordt dat voor gebruikers wel veel makkelijker gemaakt en vooral veel veiliger om ZFSguru aan internet te hangen. Dan gaat ZFSguru ook gebruikt worden voor niet-NAS-achtige taken. ZFS blijft natuurlijk een heerlijk fundament.

Daar gaat je focus. Waarom moet het allemaal zo groots en meeslepend? Waaorm moet ZFSguru een soort van Zwitsers zakmes worden dat alles kan maar uiteindelijk nergens 'echt' goed voor is?

Waarom zou je je niet gewoon richten op de core functionaliteit van het NAS-zijn voor niet-technici en je daar op focussen? En de huidige beta naar een 1.0 brengen?

[Verwijderd]

Omdat tegen die tijd het basisgedeelte af is. Als je niet meer wilt, installeer dan geen addon functionaliteit. Maar wij gaan natuurlijk verder met andere mooie dingen. Allemaal met ZFSguru als basis.

Je krijgt juist wat je wilt: namelijk dat de interface zelf gevrijwaard blijft van allemaal junk die erin terecht komt omdat er allemaal features worden ontwikkeld. Je wilt dat de web-interface schoon en sleek blijft en niet bloated. Dus zodra ZFSguru basisfunctionaliteit af is, gaan wij verder met nieuwe addon functionaliteit. Maar dat hoeft gebruikers niet te storen die enkel een simpele/nuttige no-nonsense ZFS-interface willen. Dan is het zo simpel als geen services installeren.

[FireDrunk]

Ik wil niet afhankelijk zijn van het release schema van een tool met twee devs. Stel er komt een critical security patch voor pkg zelf die remote te exploiten viel. Dan wil ik maar wat graag zelf even updaten ipv moeten wachten op een release van zfsguru.

Als jullie webinterface echt mobiel / portable / klein was, dan hadden we die gewoon los kunnen installeren zonder dependencies...

Wat ik eigenlijk verwacht van zfsguru is dat ik de webinterface gewoon met pkg kan installeren.
Tuurlijk is het handig om een voorgebakken ISO te downloaden waar dit allemaal in zit inc installers. Prima, leuk voor mensen die geen handmatige installatie willen doen.

Waarom wil ik pkg? Omdat ik dan gewoon kan upgraden. Willen jullie zelf services installeren? Prima gebruik pkg. Waarom zou je niet de reeds bestaande infrastructuur gebruiken om services te implementeren?

Of je nou een serivce bouwt voor ZFSguru of je maakt een pkg package, dat maakt geen kont uit.
Tuurlijk krijg je je eigen pkg's niet zomaar in de BSD repo's. Prima, dan host je je eigen pkg server.

Ik vind het niet meer dan normaal dat als ik jullie webinterface gebruik, ik mijn pkg even naar jullie server verwijs voor de sources.

Wat jullie willen kan dan nog steeds, maar dan heb ik de vrijheid om alles zelf te kiezen. Of ik nou de zfsguru webinterface los gebruik, of zelfs meer icm services. Het kan allemaal... via pkg...

[ Voor 56% gewijzigd door FireDrunk op 05-01-2014 18:32 ]

[Verwijderd]

Maar je kan toch even updaten? Dat doe ik zelf ook? Enige waar je mee moet oppassen is genoemd BSD-issue dat je geen nieuwe ports moet installeren met een up-to-date portstree voordat je de huidige ports hebt geupdate. Dan is er een tweede ZFSguru specifiek issue dat je ná het updaten van je ports geen ZFSguru services moet installeren, althans de installatie daarvan kan falen, dus is tricky.

Dus het advies is heel simpel:
- Installeer ZFSguru
- Installeer alle services die je ooit wilt gebruiken (optioneel)
- Installeer de officiële portstree (optioneel)
- Installeer de manual ports die je wilt (optoneel)
- Update de portstree (portsnap fetch && portsnap extract)
- Update alle packages met portupgrade of portmaster
- Installeer nieuwe ports met up-to-date portstree

Dat is allemaal mogelijk. Je kunt ports-mgmt/portaudit installeren zodat je security vulnerabilities in installed packages kunt tracken, dat gebruik ik zelf veelvuldig.

Kortom, ZFSguru is geen dichtgelaste auto waar je niet bij de motor mag komen. Je kunt alles wat BSD ook kan, inclusief een eigen kernel installeren e.d. Enige is wel dat je compatibiliteit met de services kan slopen. In het ergste geval eventjes nieuwe install, reboot en je kan een nieuwe poging wagen. Best wel geinig platform toch? Niet enkel een saaie web-UI die wat ZFS dingen kan en een samba/nfs share aanmaken. ZFSguru wilt toch echt wat meer zijn.

De truc is om zoveel mogelijk gebruikers tevreden te houden. Een modulaire opzet daarbij is cruciaal. En volgens mij werkt dat beter zowel nu als in de toekomst dan jullie denken. Denk aan alle gebruikers die blij zijn met de service addons. Dat hier in een relatief vroeg stadium voorrang aan is gegeven komt natuurlijk voort uit wensen va gebruikers met een andere achtergrond dan die van jullie. Jason heeft op die wensen ingespeeld en ervoor gezorgd dat zij met een paar muisklikken toegang kregen tot de speelgoedjes waar zij blij mee zijn. Hier en daar werkt het nog niet goed en veel services doen weinig meer dan packages installeren. Maar het is een goed begin van een brede addon infrastructuur in de toekomst, waarbij het uitdrukkelijk de bedoeling is dat de community zelf ook services beheert, toevoegt en verbetert.

Kortom, ik zie niet waar jullie precies bang voor zijn. ZFSguru wordt geen bloated monster met allemaal onzin dingen. Centraal staat dat iedere gebruiker zoveel flexibiliteit moet kunnen krijgen als mogelijk is, zonder dat het de gebruiksvriendelijkheid of veiligheid in geding brengt. Ook geavanceerde gebruikers die alle poespas niet willen maar wel een paar dingen van ZFSguru kunnen potentiële gebruikers worden. De toekomst is dus modulair en als het ene af is, werken we aan het andere.

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 18:45:
Dan is er een tweede ZFSguru specifiek issue dat je ná het updaten van je ports geen ZFSguru services moet installeren, althans de installatie daarvan kan falen, dus is tricky.

Waarom is dit niet te integreren in één geheel. Kan je binnen FreeBSD niet net zoals in Apt zeggen dat bepaalde pakketten van Server 1 (FreeBSD) moeten komen en bepaalde van Server 2 (ZFSguru)?

Het is in ieder geval mogelijk met pkgng:
https://github.com/freebsd/pkg#multirepos

[ Voor 8% gewijzigd door CurlyMo op 05-01-2014 18:54 ]

[Verwijderd]

Precompiled binaries op een nieuwer systeem kan problemen geven. De binary heeft dependencies naar bepaalde versies van andere packages. Als die opeens een nieuwere versie hebben, kan dat backwards incompatible zijn. In dat geval krijg je problemen. Tijdens het installeren hoor je pkg dan ook allerlei waarschuwingen afgeven, zoiets als:

warning, package depends on 'png-1.5.8' but 'png-1.6.2' is installed

Het installeren gaat dan wel door, maar het kan zijn dat het geheel dan niet werkt.

Maar dat is niet zo erg toch? Kijk of het werkt, zo niet nieuwe install is zo gebeurd (paar seconden op SSD). Het idee is dat je lekker kunt prutsen en fouten kunt maken. Stel je hebt nu een installatie waar alles goed werkt maar je wilt wat gaan kutten, dan dupliceer je je huidige installatie en boot je naar de nieuwe. Daar kun je je risicovolle activiteiten dan ontplooien. Ik noem maar wat. ZFSguru is er voor de newbies maar zeker ook voor de gevorderden.

[FireDrunk]

Verwijderd schreef op zondag 05 januari 2014 @ 18:45:
Maar je kan toch even updaten? Dat doe ik zelf ook? Enige waar je mee moet oppassen is genoemd BSD-issue dat je geen nieuwe ports moet installeren met een up-to-date portstree voordat je de huidige ports hebt geupdate. Dan is er een tweede ZFSguru specifiek issue dat je ná het updaten van je ports geen ZFSguru services moet installeren, althans de installatie daarvan kan falen, dus is tricky.

Dus het advies is heel simpel:
- Installeer ZFSguru
- Installeer alle services die je ooit wilt gebruiken (optioneel)
- Installeer de officiële portstree (optioneel)
- Installeer de manual ports die je wilt (optoneel)
- Update de portstree (portsnap fetch && portsnap extract)
- Update alle packages met portupgrade of portmaster
- Installeer nieuwe ports met up-to-date portstree

Dat is allemaal mogelijk. Je kunt ports-mgmt/portaudit installeren zodat je security vulnerabilities in installed packages kunt tracken, dat gebruik ik zelf veelvuldig.

Kortom, ZFSguru is geen dichtgelaste auto waar je niet bij de motor mag komen. Je kunt alles wat BSD ook kan, inclusief een eigen kernel installeren e.d. Enige is wel dat je compatibiliteit met de services kan slopen. In het ergste geval eventjes nieuwe install, reboot en je kan een nieuwe poging wagen. Best wel geinig platform toch? Niet enkel een saaie web-UI die wat ZFS dingen kan en een samba/nfs share aanmaken. ZFSguru wilt toch echt wat meer zijn.

De truc is om zoveel mogelijk gebruikers tevreden te houden. Een modulaire opzet daarbij is cruciaal. En volgens mij werkt dat beter zowel nu als in de toekomst dan jullie denken. Denk aan alle gebruikers die blij zijn met de service addons. Dat hier in een relatief vroeg stadium voorrang aan is gegeven komt natuurlijk voort uit wensen va gebruikers met een andere achtergrond dan die van jullie. Jason heeft op die wensen ingespeeld en ervoor gezorgd dat zij met een paar muisklikken toegang kregen tot de speelgoedjes waar zij blij mee zijn. Hier en daar werkt het nog niet goed en veel services doen weinig meer dan packages installeren. Maar het is een goed begin van een brede addon infrastructuur in de toekomst, waarbij het uitdrukkelijk de bedoeling is dat de community zelf ook services beheert, toevoegt en verbetert.

Kortom, ik zie niet waar jullie precies bang voor zijn. ZFSguru wordt geen bloated monster met allemaal onzin dingen. Centraal staat dat iedere gebruiker zoveel flexibiliteit moet kunnen krijgen als mogelijk is, zonder dat het de gebruiksvriendelijkheid of veiligheid in geding brengt. Ook geavanceerde gebruikers die alle poespas niet willen maar wel een paar dingen van ZFSguru kunnen potentiële gebruikers worden. De toekomst is dus modulair en als het ene af is, werken we aan het andere.

Dus nogmaals, waarom encapsuleer je de webinterface niet in PKG en publiceer je die los, dan kan men vrolijk zelf kiezen wat ze willen hebben. Of het nou een complete ISO is, of alleen de webinterface.

ZFSguru is voor mij dus WEL een dichtgelaste auto, want het krakt als ik PHP upgrade.. En hoezo 'even' een herinstallatie? Ik wil echt niet mijn hele configuratie opnieuw doen... 'even' opnieuw installeren is bij mij zo een paar uur werk... De hele configuratie van SabNZBd, Sickbeard, CouchPotato, upsd, en nginx moet ik opnieuw doen.

Jij zegt alleen een 'saaie' webinterface.. Dat is *juist* wat ik alleen maar wil... De rest kan ik zelf wel...
En die paar muisklikken (SabNZBd, Sickbeard, Couchpotato) hebben bij mij nog nooit goed gewerkt... Vooral omdat ik het niet eens ben met het security model (ik wil niet onder de share user werken). Ik moet dus handmatig al die services herconfigureren.

Wat je nu doet, is een extra community willen die *nog* weer een extra package formaat moet gaan onderhouden voor services... Waarom niet gewoon pkg gebruiken met daarbovenop wat installer scriptjes? Nu moeten eventuele software bouwers voor *nog* weer een extra platform packages gaan maken.

Ook geavanceerde gebruikers die alle poespas niet willen maar wel een paar dingen van ZFSguru kunnen potentiële gebruikers worden.

Dat zeg ik dus, ik schaar mijzelf onder de noemer 'geavanceerde gebruiker' en kan dus geen ZFSguru gebruiken. Easy as that..

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 18:54:
Precompiled binaries op een nieuwer systeem kan problemen geven. De binary heeft dependencies naar bepaalde versies van andere packages. Als die opeens een nieuwere versie hebben, kan dat backwards incompatible zijn. In dat geval krijg je problemen. Tijdens het installeren hoor je pkg dan ook allerlei waarschuwingen afgeven, zoiets als:

In XBian hebben we dat toen opgelost door bepaalde xbian-package-* te maken. Bijv. als zoals hier wordt aangegeven ZFSguru breekt doordat je een nieuwe versie van PHP installeert, los je dat op door het volgende:
1. Bouw een zfsguru-webgui (1.0) pakket.
2. Laat dat pakket een bepaalde dependency vereisen bijv. php 5.1
3. Installeert die zfsguru-webgui standaard op het systeem.

Wat er nu gebeurt als een gebruiker php 5.2 probeert te installeren is dat hij een melding krijgt dat je daarmee zfsguru-webgui breekt. De gebruiker kan zelf kiezen of hij dit risico neemt. Als er een nieuwe versie van zfsguru-webgui komt bijv. 1.1, dan kan je deze een nieuwere dependency geven bijv. php 5.2. php wordt dan ook geupdate. Het is dan jullie taak om ontwikkelingen binnen FreeBSD bij te houden als het gaat op patches. Probleem opgelost toch?

Maar dat is niet zo erg toch? Kijk of het werkt, zo niet nieuwe install is zo gebeurd (paar seconden op SSD). Het idee is dat je lekker kunt prutsen en fouten kunt maken.

Is dit nu al "the understatement of the year?" Even opnieuw installeren. Weet je hoeveel werk dat is voor vele van ons?

Stel je hebt nu een installatie waar alles goed werkt maar je wilt wat gaan kutten, dan dupliceer je je huidige installatie en boot je naar de nieuwe. Daar kun je je risicovolle activiteiten dan ontplooien. Ik noem maar wat. ZFSguru is er voor de newbies maar zeker ook voor de gevorderden.

Dit heeft echt nog nooit gewerkt hier

[Verwijderd]

@FireDrunk:

Of je nou een serivce bouwt voor ZFSguru of je maakt een pkg package, dat maakt geen kont uit.

Nou dat maakt natuurlijk wel uit. ZFSguru services zijn meer dan alleen packages.

De manier van automatisch starten, handmatig starten, huidige runstatus bepalen, panel web-interface, additionele installatie/uninstallatie/start/stop-scripts. Allemaal zodat de web-interface niet vies gehackt hoeft te worden.

Waarom wil ik pkg? Omdat ik dan gewoon kan upgraden.

Je hebt toch pkg? pkgNG gebruikt ZFSguru sinds de laatste twee systeemversies. Dat is de nieuwe package-infrastructuur van FreeBSD. De services zijn weinig meer dan pkgNG-packages die ook via pkgNG worden geinstalleerd. Je ziet ze dan ook in de pkg info -v output.

Wat dacht je dan dat ZFSguru services waren? Een heel eigen package-formaat? Het is juist encapsulated. Er is één .tar package uncompressed, daarin zitten wat tekstfiles en optioneel scripts, en de pkgNG-packages in de 'packages/amd64' directory.

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 19:04:
Wat dacht je dan dat ZFSguru services waren? Een heel eigen package-formaat? Het is juist encapsulated. Er is één .tar package uncompressed, daarin zitten wat tekstfiles en optioneel scripts, en de pkgNG-packages in de 'packages/amd64' directory.

Misschien ben ik ouderwets qua ZFSguru, maar downloaden jullie niet een tar en installeren daaruit allerlei zaken? Of wordt alles vanaf begin al via pkgNG geïnstalleerd? Ook de webGUI modules, start/stop scripts enz. Anders gevraagd, maken jullie gebruik van deze pre_install, pre_deinstall en pre_upgrade script zoals ze bedoeld zijn?
https://wiki.freebsd.org/...ling_a_package_with_pkgng

[ Voor 13% gewijzigd door CurlyMo op 05-01-2014 19:13 ]

[Verwijderd]

De web-interface is nog geen package. Gewoon een tarball die naar /usr/local/www/zfsguru wordt uitgepakt. Dat kan veranderen in de toekomst, wellicht ooit een FreeBSD port. Maar nu nog eventjes toekomstmuziek.

De scripts e.d. zijn allemaal opgeslagen in de 'service directory'. Dat is kortweg /services/owncloud in het geval van de Owncloud-service. Maar in werkelijkheid is dit een symbolic link naar een filsystem op je boot pool, zoals tank/zfsguru/services/9.2-001. Dat betekent dat de services per installatie hun eigen ZFS filesystem hebben. Maar niet alleen die stomme tekstfiles maar ook de 'data' folder. Het is de bedoeling dat alle data die de service genereert, hierin terecht komt. Dit maakt het makkelijk met migratie naar een andere systeemversie, zoals een nieuwe installatie. Bij Owncloud en Virtualbox en andere services wordt de 'data' folder in de respectievelijke servicedirectory gebruikt voor opslag van alle gegenereerde data.

Is dit nu al "the understatement of the year?" Even opnieuw installeren. Weet je hoeveel werk dat is voor vele van ons?

Bij ZFSguru is installatie heel laagdrempelig. Je kunt installeren zonder je huidige installatie te verliezen. En weer terugschakelen als het nodig is. Je hebt wel up-to-date bootcode nodig (kun je doen op de Disks pagina, klik op de rode freebsd-boot partitie) daarnaast werkt een mirror installatie op SSD het beste/snelste.

Dus eventjes nieuw installeren is heel gemakkelijk bij ZFSguru, mits je de ZFSguru systeemversies gebruikt natuurlijk. Custom BSD-install is een ander verhaal. Maar ZFSguru heeft natuurlijk een veel coolere installatie, zelfs nu de huidige FreeBSD 10-installer sterk is verbeterd met wat er daarvoor was (sysinstall). Dat was nerdheid ten top. Zoiets wil je een bekende van je niet aandoen, dat is gewoon marteling. Maar ZFSguru heeft dat al goed geregeld.

[CurlyMo]

Als écht per service écht alles vanuit de tgz wordt gedaan (op de correcte manier) dan zie ik inderdaad ook geen reden tot gezeur

[Verwijderd]

Tegenwoordig geen .tgz (GZIP-compressie) meer of .tbz (BZIP-compressie) maar XZ-compressie dus .txz, dat is het nieuwe formaat van pkgNG.

De ZFSguru service zelf is dus een .tar tarball zonder compressie, daarin bevinden zich een paar tekstfiles en de pkgNG packages in .txz formaat. Zaakje wordt uitgepakt in /services/<servicenaam> en na installatie worden de binary packages verwijderd om ruimte vrij te maken, de tekstfiles blijven over en de 'data' folder waar eventueel veel dingen in terecht kunnen komen die worden gegenereerd door de service en wat behouden moet blijven.

Als binnenkort de Migration Manager functionaliteit wordt afgebouwd, dan kun je heel gemakkelijk migreren terwijl je alle instellingen meeneemt, inclusief services. Althans dat kun je heel specifiek aangeven wat je mee wilt nemen door Migration Profiles aan te maken. Allemaal heel gemakkelijk en toegankelijk voor iedereen.

[ Voor 51% gewijzigd door Verwijderd op 05-01-2014 19:36 ]

[FireDrunk]

Dat is al een stuk beter. Ik zou zeker opteren voor een modulaire aanpak van alles... Dus ook de webinterface. Ik wil bijvoorbeeld best meehelpen met de webinterface maar heb niets met Services.

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 19:34:
De ZFSguru service zelf is dus een .tar tarball zonder compressie, daarin bevinden zich een paar tekstfiles en de pkgNG packages in .txz formaat. Zaakje wordt uitgepakt in /services/<servicenaam> en na installatie worden de binary packages verwijderd om ruimte vrij te maken, de tekstfiles blijven over en de 'data' folder waar eventueel veel dingen in terecht kunnen komen die worden gegenereerd door de service en wat behouden moet blijven.

Dat is voor mij dus het probleem. Er moet gewoon een txz geleverd worden waarin alle "zaakjes" geregeld worden in de *_install scripts. Ook het aanmaken van nieuwe bestanden, bijwerken van andere bestanden etc.

Voorbeeldje opnieuw vanuit XBian (postinstall):
https://github.com/xbiano...r/content/DEBIAN/postinst

FireDrunk schreef op zondag 05 januari 2014 @ 19:40:
Dat is al een stuk beter. Ik zou zeker opteren voor een modulaire aanpak van alles... Dus ook de webinterface. Ik wil bijvoorbeeld best meehelpen met de webinterface maar heb niets met Services.

Zo zie je maar weer, als dingen open source waren geweest had je al gelijk FireDrunk mee gehad. Scheelt een hoop discussie en communicatie tijd.

[ Voor 27% gewijzigd door CurlyMo op 05-01-2014 19:44 ]

[Verwijderd]

@FireDrunk: kan ik prima begrijpen! Misschien als er straks een bugtracker is (oh die is er al ) en een repo, dat jij ook geïnteresseerd zou kunnen worden om bugs te melden of patches te submitten. Op dit moment echter, snap ik dat het erg hoogdrempelig en frustrerend is om aan de kern/webGUI mee te helpen afgezien van het melden van bugs die je als gebruiker kunt vaststellen. Maar dat gaat zeker verbeteren in de toekomst!

@CurlyMo:
Waarom zou dat moeten, wat heeft een ZFSguru panel interface voor SABnzbd+ te maken met FreeBSD of PC-BSD als je geen ZFSguru gebruikt? Waarom zou je überhaupt ZFSguru services gebruiken als je geen ZFSguru gebruikt?

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 19:45:
@CurlyMo:
Waarom zou dat moeten, wat heeft een ZFSguru panel interface voor SABnzbd+ te maken met FreeBSD of PC-BSD als je geen ZFSguru gebruikt? Waarom zou je überhaupt ZFSguru services gebruiken als je geen ZFSguru gebruikt?

Omdat je dan alle bestanden onder beheer van pkgNG en daarbij native FreeBSD houdt. Ook gebruik je de kracht van dit programma. Daarnaast gaf ik al aan dat je de mogelijkheid hebt bij pkgNG om eigen repositories in te stellen. Mensen die FreeBSD of PC-BSD gaan waarschijnlijk de ZFSguru repository op de eerste plaats al niet gebruiken. Daarnaast, waarom zou iemand die FreeBSD gebruikt niet de webGUI van ZFSguru kúnnen installeren. Als alles modulair dan kan zelfs die persoon toch gewoon de ZFSguru webGUI gebruiken?

Opnieuw, en ik blijf het voorbeeld gebruiken. Raspbian (debian voor de Raspberry Pi) is om te bouwen naar XBian door alleen de xbian pakketten te installeren. Op zo'n zelfde manier zou het prima mogelijk moeten zijn om mensen op (hun custom) FreeBSD ZFSguru paketten te installeren om het zo om te bouwen naar een ZFSguru systeem zonder hun eigen werk te verliezen.

[ Voor 17% gewijzigd door CurlyMo op 05-01-2014 19:52 ]

[Verwijderd]

Waarom zou je zo'n pkg repo willen gebruiken?

Als je geen ZFSguru gebruikt heb je dat ook niet nodig.
Als je wel ZFSguru gebruikt heb je ofwel via Web-interface al toegang, dan heb je geen command line 'pkg' nodig.
Als je ZFSguru gebruikt maar je wilt handmatig BSD packages installeren, dan kan dat met ports.

Het enige voordeel wat ik zie, is dat met een pkg repo je via de shell ('command line') ZFSguru services zou kunnen installeren, wat nu ook al kan met wat commando's (fetch, untar en start installscript) en dat je bij updaten van packages ook geen web-interface nodig hebt.

Is dat alle moeite het waard? Lijkt me niet echt prioriteit hebben op dit moment. Werkt juist prima, en de extra's noemen jullie niet, zoals de panel interfaces e.d. Zonder die jus zouden ZFSguru services inderdaad weinig meer zijn dan pkgNG-packages.

[HyperBart]

Verwijderd schreef op zondag 05 januari 2014 @ 17:38:
@HyperBart:
Om welke reden dan? Je hebt toch precies wat je wilt hebben?

Even het lijstje quoten wat je vetgedrukt gequote had:

[...]

[list]• 1. Je kunt ZFS filesystems e.d. beheren, dat is allemaal redelijk 'af'.

Ik kom specifiek al niet meer in de buurt van de knop om een device als SLOG in te stellen, gewoon omdat ik echt niet weet wat er vanachter werkt of niet. Niet "af" dus, terwijl dit toch echt wel de kern van de kern is, namelijk een beetje ZFS pools deftig met een Web GUI beheren.

• 2. Bestanden delen via SMB/AFP/NFS werkt ook, alleen die support zijn we nu aan het verbeteren (beta9). Dat is de kern van het project.

Werd ook wel eens een beetje tijd . Ik zou eens moeten zoeken, maar ik denk dat het ongeveer meer dan anderhalf jaar geleden is dat er door mij over geneut is en het zit er nog niet in. In mijn ogen ook kern der kernen van een Network Attached Storage box.

• 3. Management interface is niet erg specifiek, maar dat is ongeveer wat ZFSguru web-interface is toch?

Agree

• 4. User management, ook dit komt in beta9

Idem als puntje 2 eigenlijk.

• 5. Secure, dit is voor de toekomst. Ik werd zelfs nog bekritiseerd over de meest veilige oplossing een tijdje terug.[/list]

Ik heb te weinig diepgaande kennis over UNIX-derivaten en programmeerkennis om daar op in te gaan. Maar het is eerder een onderbuik gevoel dat mijn data nu staat op een distributie waar echt bijzonder veel dingen nog niet in af zijn. Nu, dat is eigenlijk ook gewoon mijn stomme schuld, want het is allemaal nog beta. Daar ben ik gewoon wat te vertrouwend in geweest omdat ik bij "beta" het warme gevoel krijg wat ik kreeg bij Gmail ooit .

Kortom, wij werken nu toch aan de belangrijke dingen? Het is toch niet dat we gekke dingen aan het doen zijn? Voor de toekomst zijn er grote plannen en dan zullen er inderdaad zijwergen ingeslagen worden. Maar dan zijn we ook een episode verder waar ZFSguru een goed bruikbaar stabiel product geworden is. Dat wij in die fase van het project verder werken aan andere dingen in het verlengde ervan is juist goed. Hoe jij het bedoelt klinkt alsof er allemaal junk in ZFSguru terecht gaat komen. Maar je vergeet de modulaire strategie van ZFSguru: jij hoeft geen dingen te draaien die je niet wilt.

Ik maak me vooral druk om het feit dat het in mijn ogen ZFSguru de focus verloren is om een lean mean, zo netjes mogelijk inpassend distrootje is geworden om een ZFS NAS mee te bouwen. Ik hoor hier dingen over CMS'en en wat nog allemaal. Ik had van ZFSguru gewoon een webinterface verwacht zonder al die poespas en zonder dat er zoveel kapot gaat als ik nog maar wat probeer te installeren van ports oid (details: FireDrunk, ik weet bij godshere niet wat er mis loopt)

Q schreef op zondag 05 januari 2014 @ 18:13:
[...]


Daar gaat je focus. Waarom moet het allemaal zo groots en meeslepend? Waaorm moet ZFSguru een soort van Zwitsers zakmes worden dat alles kan maar uiteindelijk nergens 'echt' goed voor is?

Waarom zou je je niet gewoon richten op de core functionaliteit van het NAS-zijn voor niet-technici en je daar op focussen? En de huidige beta naar een 1.0 brengen?

^^ DAT dus! ^^

FireDrunk schreef op zondag 05 januari 2014 @ 18:27:
Als jullie webinterface echt mobiel / portable / klein was, dan hadden we die gewoon los kunnen installeren zonder dependencies...

Wat ik eigenlijk verwacht van zfsguru is dat ik de webinterface gewoon met pkg kan installeren.

Waarom wil ik pkg? Omdat ik dan gewoon kan upgraden. Willen jullie zelf services installeren? Prima gebruik pkg. Waarom zou je niet de reeds bestaande infrastructuur gebruiken om services te implementeren?

Of je nou een serivce bouwt voor ZFSguru of je maakt een pkg package, dat maakt geen kont uit.
Tuurlijk krijg je je eigen pkg's niet zomaar in de BSD repo's. Prima, dan host je je eigen pkg server.

Ik vind het niet meer dan normaal dat als ik jullie webinterface gebruik, ik mijn pkg even naar jullie server verwijs voor de sources.

Wat jullie willen kan dan nog steeds, maar dan heb ik de vrijheid om alles zelf te kiezen. Of ik nou de zfsguru webinterface los gebruik, of zelfs meer icm services. Het kan allemaal... via pkg...

^^ dat dus ^^
Ik wil iets à la apt-get install ipv afhankelijk van jullie te zijn.

Nog zoiets! Ik installeer Sabnzbd, komt ZFSguru neuten dat ik een nieuwere versie kan installeren. "oh lekker denk ik, want jaaaaaa, die gasten van Brein doen af en toe wel eens ruk waardoor de scene gekke dingen met NZB's moet uithalen die anders falen, dus ik wil wel updaten, doe maar ZFSguru". Zfsguru: "Weeeell fuck no Bart, dan ga je eerst even moet upgraden naar 10.huppeldepup"

Verwijderd schreef op zondag 05 januari 2014 @ 18:45:
Maar je kan toch even updaten? Dat doe ik zelf ook? Enige waar je mee moet oppassen is genoemd BSD-issue dat je geen nieuwe ports moet installeren met een up-to-date portstree voordat je de huidige ports hebt geupdate. Dan is er een tweede ZFSguru specifiek issue dat je ná het updaten van je ports geen ZFSguru services moet installeren, althans de installatie daarvan kan falen, dus is tricky.

Dus het advies is heel simpel:
- Installeer ZFSguru
- Installeer alle services die je ooit wilt gebruiken (optioneel)
- Installeer de officiële portstree (optioneel)
- Installeer de manual ports die je wilt (optoneel)
- Update de portstree (portsnap fetch && portsnap extract)
- Update alle packages met portupgrade of portmaster
- Installeer nieuwe ports met up-to-date portstree

Dat is allemaal mogelijk. Je kunt ports-mgmt/portaudit installeren zodat je security vulnerabilities in installed packages kunt tracken, dat gebruik ik zelf veelvuldig.

Kortom, ZFSguru is geen dichtgelaste auto waar je niet bij de motor mag komen. Je kunt alles wat BSD ook kan, inclusief een eigen kernel installeren e.d. Enige is wel dat je compatibiliteit met de services kan slopen. In het ergste geval eventjes nieuwe install, reboot en je kan een nieuwe poging wagen. Best wel geinig platform toch? Niet enkel een saaie web-UI die wat ZFS dingen kan en een samba/nfs share aanmaken. ZFSguru wilt toch echt wat meer zijn.

De truc is om zoveel mogelijk gebruikers tevreden te houden. Een modulaire opzet daarbij is cruciaal. En volgens mij werkt dat beter zowel nu als in de toekomst dan jullie denken. Denk aan alle gebruikers die blij zijn met de service addons. Dat hier in een relatief vroeg stadium voorrang aan is gegeven komt natuurlijk voort uit wensen va gebruikers met een andere achtergrond dan die van jullie. Jason heeft op die wensen ingespeeld en ervoor gezorgd dat zij met een paar muisklikken toegang kregen tot de speelgoedjes waar zij blij mee zijn. Hier en daar werkt het nog niet goed en veel services doen weinig meer dan packages installeren. Maar het is een goed begin van een brede addon infrastructuur in de toekomst, waarbij het uitdrukkelijk de bedoeling is dat de community zelf ook services beheert, toevoegt en verbetert.

Kortom, ik zie niet waar jullie precies bang voor zijn. ZFSguru wordt geen bloated monster met allemaal onzin dingen. Centraal staat dat iedere gebruiker zoveel flexibiliteit moet kunnen krijgen als mogelijk is, zonder dat het de gebruiksvriendelijkheid of veiligheid in geding brengt. Ook geavanceerde gebruikers die alle poespas niet willen maar wel een paar dingen van ZFSguru kunnen potentiële gebruikers worden. De toekomst is dus modulair en als het ene af is, werken we aan het andere.

Ik ben geen IT-leek, laat dat heel duidelijk zijn, maar in UNIX land ben ik niet zo sterk als FD of anderen hier. Maar ik snap eeeeeecht niet, dat ZFSguru (de webinterface) zo gevoelig is aan een simpel upgrade'je of een portstreesnapfetchtrallaweetikveelupdate. Of uberhaupt een gewone upgrade van een versie van OS. Ik denk maar even aan Ubuntu waar je gewoon inline lekker upgrade (dist-upgrade) en alles blijft relatief goed draaien, misschien nog even apt-get update en een upgrade en huppa. Welke magie gebruiken die gasten dat ZFSguru/FreeBSD/whatever niet kan gebruiken? De Cruciatusvloek? Neen, dependencies en packages, maar dat lijkt mij nog niet goed te zitten bij ZFSguru?

FireDrunk schreef op zondag 05 januari 2014 @ 18:54:
[...]

Dus nogmaals, waarom encapsuleer je de webinterface niet in PKG en publiceer je die los, dan kan men vrolijk zelf kiezen wat ze willen hebben. Of het nou een complete ISO is, of alleen de webinterface.

ZFSguru is voor mij dus WEL een dichtgelaste auto, want het krakt als ik PHP upgrade.. En hoezo 'even' een herinstallatie? Ik wil echt niet mijn hele configuratie opnieuw doen... 'even' opnieuw installeren is bij mij zo een paar uur werk... De hele configuratie van SabNZBd, Sickbeard, CouchPotato, upsd, en nginx moet ik opnieuw doen.

Oh god, doe me dat niet terug opnieuw aan.

Jij zegt alleen een 'saaie' webinterface.. Dat is *juist* wat ik FD en ik alleen maar wilwillen.. De rest kan ik zelf wel...
En die paar muisklikken (SabNZBd, Sickbeard, Couchpotato) hebben bij mij nog nooit goed gewerkt... Vooral omdat ik het niet eens ben met het security model (ik wil niet onder de share user werken). Ik moet dus handmatig al die services herconfigureren.

Wat je nu doet, is een extra community willen die *nog* weer een extra package formaat moet gaan onderhouden voor services... Waarom niet gewoon pkg gebruiken met daarbovenop wat installer scriptjes? Nu moeten eventuele software bouwers voor *nog* weer een extra platform packages gaan maken.


[...]


Dat zeg ik dus, ik schaar mijzelf onder de noemer 'geavanceerde gebruiker' en kan dus geen ZFSguru gebruiken. Easy as that..

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 19:55:
Waarom zou je zo'n pkg repo willen gebruiken?
Zonder die jus zouden ZFSguru services inderdaad weinig meer zijn dan pkgNG-packages.

Dat lijkt me juist handig. Dat het aansluit bij FreeBSD aangezien je geen nieuw server OS bouwt. Maar goed, verschillen we hier toch van mening

[Verwijderd]

CurlyMo schreef op zondag 05 januari 2014 @ 19:49:
Omdat je dan alle bestanden onder beheer van pkgNG en daarbij native FreeBSD houdt. Ook gebruik je de kracht van dit programma.

Dat is toch ook zo? Als je de Apache-service installeert via de ZFSguru web-interface, dan heb je een ZFSguru service geïnstalleerd en die wordt als zodanig herkend als geïnstalleerd via de web-interface. Maar ook via 'pkg' zie je dat packages geregistreerd zijn, en die kun je vervolgens ook weer met gangbare BSD-utilities updaten. Dat werkt allemaal.

Het is niet zo alsof de service die je installeert, niet compatible met pkgNG zijn. Het is hooguit dat de extra dingen bovenop de pkgNG-packages, dus de tekstfiles in /services/apache directory, dat die niet in een package gestopt zijn. Maar dat is toch niet zo heel erg? Zou eventueel ook nog kunnen ja, dat je een zfsguru-service-apache.txz package krijgt zodat het helemaal gescheiden is. Maar ook weer veel werk om dit allemaal goed werkend te krijgen, met maar heel weinig voordelen. Zeker niet iets voor de korte termijn, lijkt me.

Als alles modulair dan kan zelfs die persoon toch gewoon de ZFSguru webGUI gebruiken?

De web-interface als port beschikbaar maken is wel iets leuks en op termijn is dat zeker een leuk project! Maar misschien tussen 0.4 en 0.5 in ofzo. Nu zijn er veel dringendere zaken waar we ons op moeten richten. I'm sure you understand.

[CurlyMo]

Verwijderd schreef op zondag 05 januari 2014 @ 20:01:
Het is niet zo alsof de service die je installeert, niet compatible met pkgNG zijn. Het is hooguit dat de extra dingen bovenop de pkgNG-packages, dus de tekstfiles in /services/apache directory, dat die niet in een package gestopt zijn. Maar dat is toch niet zo heel erg? Zou eventueel ook nog kunnen ja, dat je een zfsguru-service-apache.txz package krijgt zodat het helemaal gescheiden is. Maar ook weer veel werk om dit allemaal goed werkend te krijgen, met maar heel weinig voordelen. Zeker niet iets voor de korte termijn, lijkt me.

Het is vooral het punt dat er twee keer dezelfde handelingen plaatsvinden (2 en 3).
1. Je download een package.
2. Je kijkt of die package bepaalde scripts moet draaien.
3. pkg installeert de bestanden en kijkt of er bepaalde scripts moeten draaien.

Het is dan misschien wel een detail maar ik hecht wel waarde aan het "helemaal gescheiden" verhaal

[FireDrunk]

Als je echt serieus bent over security en daar stappen in wil nemen kan ik wel een daemon maken in python die xmlrpc calls accepteert. Dan ben je in een klap van een hoop problemen af.

[FireDrunk]

En ik heb dat al werkend... Ik kan in een paar regels een Python script op een http poort functies laten serveren met het XMLrpc protocol.

De enige dependancy aan de kant van php is de php55-xmlrpc library.

Hiermee kan je dus relatief veilig de webinterface onder een gewone user laten draaien en een python daemon onder root draaien.

Voorbeeldcode:

Python:

from SimpleXMLRPCServer import SimpleXMLRPCServer
import logging
import os

logging.basicConfig(level=logging.DEBUG)

server = SimpleXMLRPCServer(('192.168.1.3', 9090), logRequests=True)

def list_contents(dir_name):
        logging.debug('list_contents(%s)', dir_name)
        return os.listdir(dir_name)

server.register_function(list_contents)

try:
        print 'Use Control-C to exit'
        server.serve_forever()
except KeyboardInterrupt:
        print 'Exiting'

PHP:

<?php
$request = xmlrpc_encode_request("list_contents", "/datapool/data/");
$context = stream_context_create(
        array('http' =>
                array(
                        'method'        => "POST",
                        'header'        => "Content-Type: text/xml\r\nUser-Agent: PHPRPC/1.0\r\nHost: 192.168.1.3\r\n",
                        'content'       => $request
                )
        )
);

$server = "http://192.168.1.3:9090";
$file = file_get_contents($server, false, $context);

$response = xmlrpc_decode($file);
echo "<table>";
if (is_array($response) and xmlrpc_is_fault($response))
{
        echo "Failed";
}
else
{
        foreach ($response as $item)
        {
                echo "<tr><td>".$item."</td></tr>";
        }
}
echo "</table>";

Deze code is natuurlijk puur een voorbeeld, want dit is nog redelijk onveilig

[Q]

Wel mooi voorbeeld, maar wat user input sanitation in de python daemon lijkt mij wel wenselijk

[FireDrunk]

Uiteraard, het is ook meer een Proof-of-Concept. Dit haalt het hele webserver onder root draaien principe onderuit.

[CurlyMo]

Zoals eerder aangegeven. Gebruik sudo als je een gebruiker maar beperkte root rechten wilt geven. Ga daar niet het wiel opnieuw voor uitvinden.

---

PS. als je vanuit een C programma push berichten wilt versturen naar een http socket, dan is httplib daar geschikt voor. Al zie ik het voordeel daarvan niet in ten opzichte van websockets / of directe socket connecties.

[ Voor 51% gewijzigd door CurlyMo op 06-01-2014 15:46 ]

[Verwijderd]

Heel interessant, FireDrunk!

Die PHP-dependency erbij zou het probleem niet mogen zijn. Sudo kan er dan immers uit en dat is waar het allemaal om draaide; sudo die root aan www user geeft.

En je proof-of-concept valt bij mij heel goed. Wel denk ik dat het verstandig is om voorlopig een 'wildcard' te maken waarmee er ruwe commando's als root worden uitgevoerd. Op een gegeven moment is de meeste code aangepast naar 'stored procedure' approach zoals jouw voorbeeld met list_contents. Als laatste kan dan de wildcard / carte blanche weg en is ZFSguru geheel over op een nieuw securitymodel.

En de 'eigen oplossing' is uiteindelijk wellicht veel minder werk geweest dan andere bestaande oplossingen gebruiken.

[CurlyMo]

Kan iemand me uitleggen waarom je geen sudo wilt?

[Verwijderd]

Omdat dan de webserver onder 'www' user draait, maar in feite draait het onder 'root' omdat met sudo zonder authenticatie root kan worden verkregen. Dus van een echte separatie tussen 'unprivileged commands' en 'super-user commands' is er dan niet, ook al heeft ZFSguru die scheiding in de web-interface wel aangebracht (super_execute).

Uiteindelijk kan sudo eruit, draait de webserver unprivileged onder www user account en is de backend die onder root draait het enige wat bepaalt welke commando's als root worden uitgevoerd. De web-interface is dan unprivileged en kan alleen variabelen opgeven. Dus bijvoorbeeld: ik wil disk X formatteren, met deze bootcode en dit label. Maar de backend beslist over het exacte commando. Dit is natuurlijk een goed idee vanuit security perspectief.

[CurlyMo]

Verwijderd schreef op maandag 06 januari 2014 @ 15:50:
Omdat dan de webserver onder 'www' user draait, maar in feite draait het onder 'root' omdat met sudo zonder authenticatie root kan worden verkregen.

Je beslist dan toch zelf voor welke commando's dit is. www krijgt niet zomaar volledige root rechten.

[Verwijderd]

Daarnaast had sudo het probleem dat pipe characters in commando's problemen gaven. sudo echo "Z" | whoami bijvoorbeeld geeft niet 'root' maar 'www' omdat het laatste whoami niet meer met sudo wordt uitgevoerd. Hier zijn workarounds voor, maar het is allemaal erg 'hacky' en een oplossing zoals FireDrunk voorstelt is wel een grote stap vooruit wat mij betreft.

www krijgt niet zomaar volledige root rechten.

www user kan nu alles onder sudo uitvoeren. Dus een bug in de webserver zelf of een unprivileged onderdeel van de webUI is genoeg om het hele systeem te kapen. Niet erg veilig, dus wil ZFSguru verder gaan dan alleen bescherming tegen zusje en vrouwlief, dan moet het security model zich ook aanpassen aan een andere realiteit met een andere mentaliteit. Volgens mij is dat ook wat FireDrunk bedoelde toen hij vroeg of ik serieus stappen wilde maken met security.

[CurlyMo]

Verwijderd schreef op maandag 06 januari 2014 @ 15:53:
www user kan nu alles onder sudo uitvoeren.

Dan heb je toch echt iets niet goed ingesteld gehad:

code:

xbian ALL=(ALL) NOPASSWD: /usr/local/sbin/xbian-config, /sbin/halt, /sbin/reboot, /usr/bin/splash

User xbian kan écht alleen die vier programma's zonder wachtwoord draaien. Datzelfde zou gelden voor gebruiker www die alleen halt en/of reboot zou moeten kunnen doen.

[Verwijderd]

Bovendien is het zo dat de apache service ook 'www' user gebruikt. En je begrijpt het al, als mensen daarmee aan de slag gaan vergeten ze misschien dat sudo de 'www' in feite carte blanche geeft. Als ZFSguru aan het internet wilt, moet dat sudo probleem gewoon opgelost zijn. Dat is gewoon een zwak punt in de keten van beveiliging.

Dan heb je toch echt iets niet goed ingesteld gehad:

We kunnen niet van te voren alle commando's daarin proppen. De padnamen zijn niet allemaal van te voren bekend en sommige ook dynamisch (met random string).

[CurlyMo]

Verwijderd schreef op maandag 06 januari 2014 @ 15:57:
Bovendien is het zo dat de apache service ook 'www' user gebruikt. En je begrijpt het al, als mensen daarmee aan de slag gaan vergeten ze misschien dat sudo de 'www' in feite carte blanche geeft. Als ZFSguru aan het internet wilt, moet dat sudo probleem gewoon opgelost zijn. Dat is gewoon een zwak punt in de keten van beveiliging.

Dan draai je de zfsguru webserver toch gewoon onder gebruiker zfsguru?

We kunnen niet van te voren alle commando's daarin proppen. De padnamen zijn niet allemaal van te voren bekend en sommige ook dynamisch (met random string).

Klopt, maar per package kan je toch dat bestand aanpassen? Dat is met een beetje bash-scripting echt niet moeilijk. Daarnaast accepteert dat sudoers bestand ook regex dus dynamische argumenten zijn ook het probleem niet.

Maak het anders een concreet. Vertel eens wat precies je wensen zijn. FireDrunk komt nu met een python voorbeeld en je bent gelijk enthousiast. Had ik met een C voorbeeld op een geheel andere manier opgelost was je misschien ook enthousiast geweest, komt iemand met een... Dan weten we nog steeds niet wat precies de eisen zijn aan de oplossing die je zoekt.
- Via welke talen wil je werken.
- Via welke protocollen dient de communicatie plaats te vinden.
- Hoe wil je de rechten geregeld hebben.
- enz.

---

Ik was me er dus ook niet bewust van dat user "www" volledige root rechten had. Nu gelijk even lokaal aangepast. Een tweede apache draait nu onder user "zfsguru". Dat is de enige gebruiker die root rechten heeft via sudo (ipv www). Die apache draait daarbij op poort 81 die geen internet rechten heeft. De zfsguru webGUI map is alleen toegankelijk voor de zfsguru gebruiker:

code:

drwxr-x---  11 zfsguru  zfsguru        24 Sep 11  2012 zfsguru

[ Voor 14% gewijzigd door CurlyMo op 06-01-2014 16:27 ]

[Verwijderd]

Voordat je een oplossing verkent moet je eerst de problemen identificeren. Nog even daarover:

• Op dit moment is er een onveilige oplossing in gebruik met sudo. Je hebt wat suggesties om dat te verbeteren, maar behalve dat dat ook redelijk complex en omslachtig kan zijn, blijft het bepaalde nadelen houden.
• Je zegt draai het onder zfsguru user, maar afgezien van het Apache-probleem ben je dan nog niet af van het kernprobleem dat unprivileged eigenlijk super-rechten heeft, en dat zou niet moeten kunnen.
• Het dichttimmeren van sudoers file zou kunnen maar is onpraktisch door de vele wijzigingen en lang niet zo flexibel als met een server-side daemon bereikt kan worden. Die kan per 'stored procedure' meerdere commando's draaien en verificatie toepassen en zelf commando's draaien en opmaak verbeteren/escapen en ga zo maar verder.
• Alles kost tijd en energie. Dus bij een bestaande situatie die niet ultraslecht is maar wel aan vervanging toe is, willen we of dit nog lekker in de vrieskast zetten, of gelijk de beste oplossing ontwerpen en zoals FireDrunk zegt, in één klap van alle problemen af zijn.

Bovendien is zo'n serverside daemon een goede basis, wellicht kan ooit ook een unprivileged python webservertje de taken van lighttpd overnemen. Dat is voor de toekomst, zijwegen noem ik dat maar, maar als we tijd investeren in FireDrunk's idee is het mooi dat dit voor de toekomst ook goed aan kan sluiten.

Wat voor oplossing zoeken we?
Het liefst zoveel zaken de deur uit. Sudo met lelijke www-allgrant moet eruit. CurlyMo heeft suggesties om Sudo dicht te timmeren en ik denk inderdaad dat je een eind kan komen, maar de perfecte oplossing is het zeker niet.

De taal; liever Python dan C althans dat geldt voor mijzelf.
Protocollen? XML-RPC is prima hooguit dat de overhead best groot is, dus misschien iets met minder overhead.
Rechten? gewoon de daemon draait onder root, die krijgt commando's te verwerken die onder root-rechten uitgevoerd dienen te worden. Unprivileged commands doet ZFSguru dan gewoon zelf; dat kan zelfs een 'nobody' account doen.

In elk geval lijkt het niet te lastig om eens te beginnen met zo'n proof of concept, waarbij ZFSguru al op een paar plaatsen ervan gebruik kan maken. Als het dan goed bevalt kan ZFSguru wellicht helemaal over. Dan zou ook de daemon wel moeten worden uitgebreid.

[CurlyMo]

Zit je met zo'n "open source" taal ook niet met rechten te klooien? Zo'n bestand is makkelijker te hacken dan een gecompileerd C programma.

[Verwijderd]

Ik snap je niet helemaal? Als Python daemon onder root draait, wat voor problemen zouden er dan zijn met rechten? Dan kan die daemon in principe alles.

Het idee is van de daemon een soort 'Stored Procedure' approach te volgen. De web-interface zegt ik wil disk X formatteren en de daemon die voert de commando's uit met de variabelen van toepassing, die het streng zal controleren.

Bovendien is het ook leuk eigen daemon, kun je ook zien hoeveel CPU-tijd het nou gebruikt in relatie tot webserver e.d.

[CurlyMo]

Ik bedoel, als iemand toegang krijg tot de server is een python script makkelijker aan te passen dan een C programma.

[Verwijderd]

Iemand met root-rechten kan ook de daemon aanpassen, maar als je root rechten hebt dan kun je toch al alles. Zonder root rechten kom je natuurlijk niet aan de daemon, hooguit via socket dat je ermee kunt interacteren.

[FireDrunk]

XML-RPC is al heel minimalistisch volgens mij, ik zou het eens moeten capturen, maar volgens mij hoeven we ons wat dat betreft niet echt druk te maken.

Ik kan bijvoorbeeld een voorbeeld je maken als het om die disk usage gaat, en een voorbeeld PHP script schrijven, dan hebben we een leuke basis om te beginnen.

Lijkt je dat wat CiPHER?

[CurlyMo]

Het valt me op dat er nu ipv het discussiëren over probleem van het betrekken van community en het voortduren van het project al aan oplossingen van details wordt gewerkt. Lijkt me niet echt het doel van dit topic.

[FireDrunk]

Helemaal correct, maar omdat er nog niet echt een goede andere plek is om dit te bediscussiëren doe ik het maar hier

Je hebt uiteraard wel gelijk

[CurlyMo]

Ik zou zeggen, neem het voortouw en open een ZFSguru github account. Gooi daar je voorbeelden neer. Dwing je gelijk CiPHER eraan te wennen

[Verwijderd]

Dwang lijkt mij niet de beste optie, vragen en overtuigen wel. En wat betreft dat laatste moet ik nog reageren op je twee berichten met inzichten over jouw ervaringen met pilight. Want die hebben mij in elk geval deels overtuigd dat we nu mogelijk toch kansen laten liggen en ook in een vroeger stadium het al voordelen kan hebben.

Ik heb nog geen rapportage aan Jason gemaakt sinds zijn brief, maar wat FireDrunk e.d. voorstelt lijkt me ook interessant hierin op te nemen. Dus in die context vind ik het niet off-topic.

[CurlyMo]

pilight <-- zonder hoofdletter.

Beetje sarcasme in een toch al zo'n serieus topic

[Wouter.S]

Ik denk dat bovenstaande korte uitwijding over het veiligheidsprobleem met de deamon als mogelijke oplossing inderdaadd perfect illustreert wat de waarde is van meer dan twee personen die nadenken over concepten. Je bereikt immers zooooveel meer kennis door mensen met verschillende achtergronden te laten discussiëren.

Je kan je dus wel inbeelden wat er gebeurt als je een internationale github account aanmaakt... inderdaad alles wordt er beter/veiliger/etc... van

[EnerQi]

CiPHER heeft duidelijk gemaakt dat github nu niet echt gaat helpen. Overigens twijfel ik ook of Jason dat ziet zitten (misschien in de toekomst). Wat CiPHER en Jason eigenlijk meer moeten doen, is discussieren of de gekozen oplossing wel de beste is.

Jason en CiPHER gaat in de toekomst tegen meer problemen aanlopen en ik hoop daarbij dat ze dit soort topics dan ook maken waarin de Firedrunks van deze wereld input aan kunnen geven . Nu heeft het weinig zin om ieder service/bestandje etc te bediscusseren omdat dit de motivatie van beide enorm naar beneden brengt. In mijn ogen moeten we gewoon wachten op punten die hun nog niet lekker kunnen verwerken danwel tijd voor hebben. Ik zou namelijk gestoord worden als mensen steeds zouden roepen dat x de betere manier is dan y terwijl manier y ook werk of visa versa.

[CurlyMo]

EnerQi schreef op maandag 06 januari 2014 @ 19:32:
CiPHER heeft duidelijk gemaakt dat github nu niet echt gaat helpen.

Kan je daar dan een samenvatting van geven...

[Verwijderd]

Ik heb me er nog niet expliciet over uitgesproken, voor zover ik weet.

Ik ben bezig met een reactie op CurlyMo's posts over dit onderwerp.
Edit: eerst bikken, duurt nog even.

[ Voor 12% gewijzigd door Verwijderd op 06-01-2014 21:09 ]

[EnerQi]

CurlyMo schreef op maandag 06 januari 2014 @ 19:58:
[...]

Kan je daar dan een samenvatting van geven...

Dan heb ik iets te fanatiek tussen de regels gelezen. Sorry.

Mijn gevoel zegt me dat Jason dan het idee heeft dat het niet meer zijn project is . Ik ben geen vrouw dus kan het niet aan mijn water voelen

[vso]

erhm:
ZFS = Zetabyte File System toch ? + Guru vertaalt voor mij naar "simpel en snel install van ZFS file server"

waarom (zelf) bashing van ...
- Project website
- packages (add-ons)
- niet gerelateerde meuk.

Chipher .. eigenlijk sla ik je om je oren de tijd die je verkwist met dit is zinloos, als je achter het project ZFS guru staat .. filter de postieve punten & move on .. anders quit now ..

De tijd die je aan deze discussie versplilt is verloren, een roadmap + (future)wishlist waarnaar je had kunnen verwijzen had vele malen nuttiger geweest .. in mijn optiek ben je het hoofdoel uit het oog verloren.

Verwijderd schreef op zondag 05 januari 2014 @ 01:32:

deze post is een uur ? wat je verloren hebt ? met als resultaat dat 90% niet gelezen word .. of niet op gereageerd word..


Een project staat en valt vaak met "eind resultaat" oftewel is het simpel voor de (eind) gebruiker.
Hoe "user friendly" is het? vaak is dit het grootste probleem in de opensource community. maar belangrijker is: K.I.S.S. aka Keep It Stupid & Simple
de volgorde waar je op let (voor gebruikers)
1) website
2) installatie
3) gebruik
4) issues (report bug & response)
Veel minder belangrijk is "performance" en addons enzv .. hoewel je die mogelijkheden wel wilt hebben.

Maar vergeet zeker nooit de "Out Of the Box Experiance" (OOB), het feit dat je bv 4 klikken een zfsguru systeem life is het beste, wil je meer ? bied elke "extra" aan als aparte wizard .Hiermee win je meer dan dat je verliest.
Discussie voeren over hoe iets beter kan heeft alleen effect als iets het eind doel bereikt is. Je kan wel tegen de programmeur over zijn Beta fase gaan zeuren effect is dat hij nooit zijn einddoel haalt.
Dat wil niet zeggen dat je punt direct invalide is, echter het is aan de programmeurs welke prioriteit hier aan geeft.

Daarnaast Code ? al is het compleet in de meest brakke taal geschreven ooit, if it works it aint stupid dit kan je namelijk later herschrijven en tegelijkertijd optimaliseren.
Zelfde geld voor de BSD versie, een nieuwe versie voegt wellicht veel nieuwe verbeteringen toe, maar ook veel bugs die je als gebruiker niet snel zal zien.

Synology & Android lossen dit mooi op door alternatieve "community driven" marketplaces te kunnen enablen oftewel garantie tot aan de deur.. terwijl de apps die ze via hunzelf ter download zetten zijn veel makkelijker te vinden.. maar niet hun hoofddoel.

Ik zou dus ook de makers van ZFSguru adviseren hun "thirdparty" add-ons onder desnoods een alias te posten. deze addons zijn "getest" en voldoen aan de eisen die voor ZFSguru addon nodig zijn. of dit nu eigen of community makelij is. 4th party is net zo "simpel" maar enige hoop op garantie ligt bij de maker ..


Oftewel wat is de hoofdprijs bij ZFS Final release? (het einddoel) en wat zijn nu de main "addons"
de rest is nice to have...

---

SABNZB, Transmission, Sickbeard etc etc .. boeit geen ruk, sterker nog als je een simple instructie geeft hoe je een eigen "addon" toevoegt is er vast wel ooit iemand die dat toevoegt ..

hoe meer je "default" houd hoe meer je dit mogelijk maakt, bv een eigen Samba die goed met diverse MS AD servers (out of the box installs van MS AD) praat.. of eigen SAMBA bassed AD waarop windows clients zonder aanpassing op kunnen joinen. .

Een fout die de opensource community vaak maakt is pas waarde x.y.z in de registy aan o.i.d .. nee ZFSguru moet compliant zijn met OS/NAs type X . Y of Z enige wat je als admin van ZFSguru aan moet passen is welk type "NAS" je hebt .. voor bv de juiste Rsync settings ..
Advanced settings ---> terminal of als je zin hebt een speciale wizard .. (let wel dat de user zijn config kan bewaren/exporteren.. in dit geval ..

---

of te wel reageer aub niet met 40 lines of text just "engage warp engine" en ga alle punten in de ZFS topic's verzamelen .. verwerk deze in de roadmap, whislist, bug reports en prioritizeer ze ..en ga ze werkelijkheid maken.

zoek je een web app(site) die dit voor je doet .. pick 1 dat 50 tot 75% aan je eisen voldoet .. na 6 maanden kan je herevalueren of dit het veranderen waard is.. maar geloof me deze werkwijze zal meer resultaat boeken .. omdat je elke keer een stap verder komt

[Verwijderd]

Kort en bondig:

• Verspilde tijd? Een beetje misschien. Maar er komen ook goede dingen uit zoals je ziet. Bovendien kan het mij tot veranderde inzichten brengen, en daarover heb ik me nog niet uitgesproken. Dat komt nog.
• KISS-principe is ook wel van toepassing op ZFSguru. Het concept, systeemversies, services en de web-interface. Jason zelf spreekt van een 'Just works' mentaliteit. Gebruikers willen laagdrempeligheid en dat als ze iets installeren het ook gelijk werkt zonder er heel veel moeite voor te doen of dat het ze helemaal niet lukt. Jij zegt SABnzbd is onzin, maar veel mensen waarderen de manier hoe dat op ZFSguru geïntegreerd is. Ongeveer 800-1000 downloads per maand voor deze service zijn ook een indicatie dat hij veel gebruikt wordt.
• Fijn dat je zegt dat de programmeurs/ontwikkelaars hun doelen mogen bepalen. Soms leek het alsof de community die moesten bepalen. Een sturende rol van de community zou wel kunnen, bijvoorbeeld het aandringen op bepaalde features. Dat heeft Jason ook gedaan in meerdere gevallen.
• Verhaal over XYZ snap ik geen bal van; waar gaat dat over?
• Je laatste punt is duidelijk: ga aan de slag maar blijf niet eindeloos discussiëren en herkauwen. Dat gaat ten koste van ontwikkeltijd. En je hebt gelijk, al wilde ik met mijn aandacht ook laten zien dat ik de kritiek/feedback/suggesties wel degelijk serieus neem. En met veel mensen die posten is het onvermijdelijk dat er lange posts uitkomen.

Nadat ik mijn post of CurlyMo klaar heb, kunnen we een balans maken wat de discussie heeft opgeleverd en concretere resultaten/verzoeken melden aan Jason. Dan kan er ook iets concreets uit naarvoren komen en kunnen we dan inderdaad weer verder. Want dat beta9 nu iets later gereleased wordt door de discussie is goed mogelijk. Jason zegt daar niets over, maar hij begrijpt denk ik ook wel dat de community nu even gemasseerd moet worden.

[base_]

vso schreef op maandag 06 januari 2014 @ 21:44:
Maar vergeet zeker nooit de "Out Of the Box Experiance" (OOB), het feit dat je bv 4 klikken een zfsguru systeem life is het beste, wil je meer ? bied elke "extra" aan als aparte wizard .Hiermee win je meer dan dat je verliest.

En diegenen die maar een gedeelte kunnen of willen gebruiken dan?
Volgens mij is al wel duidelijk dat de LiveCD's ideaal zijn voor die "Out Of the Box Experience", maar er is daarnaast ook genoeg animo voor alleen de webGUI (vooral bij de wat meer ervaren FreeBSD gebruikers (die draaien desnoods wel ff lokaal een aparte webserver (met root rechten) voor de ZFSGuru GUI).
Verder heeft FreeBSD een prima ports systeem waarmee je iig de webgui en diverse andere services incl dependencies eenvoudig installeerbaar en configureerbaar kan maken.
Dus zowel de ISO's als installeerbare packages hebben nut i.m.h.o., als je die toegankelijk maakt kunnen diegenen die interesse hebben in een bepaald gedeelte daar ook zelf aan meewerken.
Hiervoor is het nodige werk nodig en niemand verwacht (hopelijk) dat dit vanzelf gaat, maar voor extra steun van andere developers is minimaal een versiebeheer incl bugtracker noodzakelijk denk ik.
Ik stem overigens ook voor GitHub In principe blijven Jason en Cipher gewoon eigenaar en beheerders van dat project, dus ik zie niet in hoe het daarmee "minder" hun project is, zij bepalen nog steeds wat wel en niet gecommit wordt.
En wat betreft wennen aan Git en/of GitHub: in het begin is het even wennen maar al snel gebruik je liever Git als ftp/scp/samba voor broncode, helemaal als verschillende werkplekken/personen met dezelfde code moeten werken.

[Compizfox]

Ik heb niet het hele topic doorgelezen, maar het trok wel mijn aandacht omdat ik zelf eigenlijk ook benieuwd ben naar de voortgang van ZFSGuru. Ik gebruik het zelf al een hele tijd, maar vind het ook jammer dat "die nieuwe web interface" nog steeds niet uit is.

Ik zou eigenlijk ook liever zien dat er minder aandacht werd besteed aan de services, en meer aan de web-interface. De web-interface samen met de installatieprocedure is de voornaamste reden dat ik ZFSGuru gebruik: ik volg de ontwikkelingen rondom Nas4Free niet echt maar een tijdje geleden was het nog uniek. Ik snap ook niet echt hoe de services samenhangen met de FreeBSD ports. Er is mij (en anderen) wel eens verteld dat ze je zelf ports niet zou mogen updaten. Waarom dat niet zou mogen is mij nog steeds een raadsel (ik wil mijn systeem toch echt up-to-date houden en dat gaat ook prima op die manier) en ik vind het ook een slecht idee om het FreeBSD ports systeem te willen vervangen.

Als laatste: het irriteert mij dat het elke keer nodig is om een reinstall te doen om FreeBSD te updaten, bijvoorbeeld om van FreeBSD 9.1 naar 9.2 te gaan. Sommige configfiles worden wel bewaard (die van Samba bijvoorbeeld) maar heel veel ook niet. Elke nieuwe release van FreeBSD moet ik dus m'n users opnieuw aanmaken (en toevoegen in smbpasswd), m'n software opnieuw installeren, m'n rc.conf terugzetten (die wordt ook niet bewaard) en ga zo maar door. Beetje omslachtig imho. Maar ik moet toegeven dat ik niet genoeg weet van vanilla FreeBSD om te weten of dit een quirk is van ZFSGuru, of dat dit heel normaal is met FreeBSD... (ik heb vooral ervaring met GNU/Linux)

[Verwijderd]

maar vind het ook jammer dat "die nieuwe web interface" nog steeds niet uit is.

Straks ben je misschien weer heel enthousiast over de nieuwe features in de komende releases.

Ik zou eigenlijk ook liever zien dat er minder aandacht werd besteed aan de services, en meer aan de web-interface.

Dat had ik begrepen, maar afgezien van de netwerk-functionaliteit en wat gaat komen in beta9, wat mis je nou echt?

Er is mij (en anderen) wel eens verteld dat ze je zelf ports niet zou mogen updaten.

Dat is een misverstand, alleen de volgorde is belangrijk. Installeer je eerst alle ZFSguru services en daarna ports updaten, dat werkt prima. Maar andersom niet.

en ik vind het ook een slecht idee om het FreeBSD ports systeem te willen vervangen.

Ook dat is een misverstand. ZFSguru services zijn in feite ports met een extra jus eroverheen. Icoon, scripts, manier van starten, manier van automatisch starten, huidige runstatus bepalen en natuurlijk de panel interface die specifiek voor ZFSguru is.

Kortom, het is een extra bovenop de portstree, geen vervanging. Dat laatste zou idioot zijn. Het is juist zo dat de kracht van FreeBSD ports wordt gebruikt om in ZFSguru makkelijk Service addons te kunnen toevoegen.

Elke nieuwe release van FreeBSD moet ik dus m'n users opnieuw aanmaken (en toevoegen in smbpasswd), m'n software opnieuw installeren, m'n rc.conf terugzetten (die wordt ook niet bewaard) en ga zo maar door. Beetje omslachtig imho.

Klopt en dat gaat veranderen als de Migration Manager er komt. Dat is al heel snel. Want na beta9 zijn de twee resterende features aan de beurt: GuruDB (beta10?) en Migration Manager (beta11) is ongeveer de planning. Daarna zou 0.2 final in zicht komen en werken we aan 0.3 (netwerk functionaliteit).

Kortom, het gaat allemaal beter worden. Vooral in 2014 kun je meer web-interface releases verwachten. En beta9 ga je misschien wel hele mooi vinden, nog even geduld!

[Compizfox]

Verwijderd schreef op maandag 06 januari 2014 @ 22:54:
[...]

Straks ben je misschien weer heel enthousiast over de nieuwe features in de komende releases.

Ik ben zeker enthousiast, maar wat ik bedoelde is dat de ontwikkeling langer duurt dan verwacht. Zijn vast goede redenen voor hoor, en ik ben natuurlijk helemaal niet in een positie om ook maar iets te eisen, maar het was gewoon een vaststelling.

[...]

Dat had ik begrepen, maar afgezien van de netwerk-functionaliteit en wat gaat komen in beta9, wat mis je nou echt?

D'r zijn uiteraard enkele bugs. Zo kan de webinterface niet overweg met ZFS v5000 (feature flags) en LZ4-compressie. Geen breaking bug natuurlijk, maar persoonlijk zou ik dit soort bugs in de webinterface meer prioriteit geven.

[...]

Dat is een misverstand, alleen de volgorde is belangrijk. Installeer je eerst alle ZFSguru services en daarna ports updaten, dat werkt prima. Maar andersom niet.


[...]

Ook dat is een misverstand. ZFSguru services zijn in feite ports met een extra jus eroverheen. Icoon, scripts, manier van starten, manier van automatisch starten, huidige runstatus bepalen en natuurlijk de panel interface die specifiek voor ZFSguru is.

Kortom, het is een extra bovenop de portstree, geen vervanging. Dat laatste zou idioot zijn. Het is juist zo dat de kracht van FreeBSD ports wordt gebruikt om in ZFSguru makkelijk Service addons te kunnen toevoegen.

Duidelijk Het is wel duidelijk dat er in de community misverstanden/onduidelijkheden hangen rondom dit onderwerp, maar ik ben blij met je antwoord.

[...]

Klopt en dat gaat veranderen als de Migration Manager er komt. Dat is al heel snel. Want na beta9 zijn de twee resterende features aan de beurt: GuruDB (beta10?) en Migration Manager (beta11) is ongeveer de planning. Daarna zou 0.2 final in zicht komen en werken we aan 0.3 (netwerk functionaliteit).

Kortom, het gaat allemaal beter worden. Vooral in 2014 kun je meer web-interface releases verwachten. En beta9 ga je misschien wel hele mooi vinden, nog even geduld!

Klinkt nice

[vso]

Verwijderd schreef op maandag 06 januari 2014 @ 22:22:
Kort en bondig:

• Verspilde tijd? Een beetje misschien. Maar er komen ook goede dingen uit zoals je ziet. Bovendien kan het mij tot veranderde inzichten brengen, en daarover heb ik me nog niet uitgesproken. Dat komt nog.
• KISS-principe is ook wel van toepassing op ZFSguru. Het concept, systeemversies, services en de web-interface. Jason zelf spreekt van een 'Just works' mentaliteit. Gebruikers willen laagdrempeligheid en dat als ze iets installeren het ook gelijk werkt zonder er heel veel moeite voor te doen of dat het ze helemaal niet lukt. Jij zegt SABnzbd is onzin, maar veel mensen waarderen de manier hoe dat op ZFSguru geïntegreerd is. Ongeveer 800-1000 downloads per maand voor deze service zijn ook een indicatie dat hij veel gebruikt wordt.
• Fijn dat je zegt dat de programmeurs/ontwikkelaars hun doelen mogen bepalen. Soms leek het alsof de community die moesten bepalen. Een sturende rol van de community zou wel kunnen, bijvoorbeeld het aandringen op bepaalde features. Dat heeft Jason ook gedaan in meerdere gevallen.
• Verhaal over XYZ snap ik geen bal van; waar gaat dat over?
• Je laatste punt is duidelijk: ga aan de slag maar blijf niet eindeloos discussiëren en herkauwen. Dat gaat ten koste van ontwikkeltijd. En je hebt gelijk, al wilde ik met mijn aandacht ook laten zien dat ik de kritiek/feedback/suggesties wel degelijk serieus neem. En met veel mensen die posten is het onvermijdelijk dat er lange posts uitkomen.

Nadat ik mijn post of CurlyMo klaar heb, kunnen we een balans maken wat de discussie heeft opgeleverd en concretere resultaten/verzoeken melden aan Jason. Dan kan er ook iets concreets uit naarvoren komen en kunnen we dan inderdaad weer verder. Want dat beta9 nu iets later gereleased wordt door de discussie is goed mogelijk. Jason zegt daar niets over, maar hij begrijpt denk ik ook wel dat de community nu even gemasseerd moet worden.

Zorg eerst dat ZFSguru core goed draait en bv een SDK hebt voor addons .. dat je addons als tussendoortje doet .. is een + maar desalniet temin verlies je de focus ..

De lage drempel is IMHO belangrijker .. belangrijker dat een bugvrij product, juist planning wanneer je welke bug/upgrade/addon/web of andere code op focust zorgt ervoor dat je niks uit het oog verliest dat is de roadmap.

base_ schreef op maandag 06 januari 2014 @ 22:30:
En diegenen die maar een gedeelte kunnen of willen gebruiken dan?
Volgens mij is al wel duidelijk dat de LiveCD's ideaal zijn voor die "Out Of the Box Experience", maar er is

OOB experiance wil zeggen dat je alles zeer laagdrempeling houd, dit is bv waarom Iphone, android en synology NAS zo populair is,

Juist omdat de software die jij wilt gebruiken zo lekker simpel kant en klaar is, nauwelijks config, dat is dus pure OOB. En waar hierboven Chiper & Jason naar "lage drempel" verwijzen.

daarnaast ook genoeg animo voor alleen de webGUI (vooral bij de wat meer ervaren FreeBSD gebruikers (die draaien desnoods wel ff lokaal een aparte webserver (met root rechten) voor de ZFSGuru GUI).
Verder heeft FreeBSD een prima ports systeem waarmee je iig de webgui en diverse andere services incl dependencies eenvoudig installeerbaar en configureerbaar kan maken.

kweet, maar BSD is nu niet de meest gebruiks vriendelijke teminste de community heeft nu niet echt wizards gemaakt daar ben je bv weer afhankelijk van anderen. zoals de GUI die Jason heeft gemaakt.

maar het maken van addons mits het in de ports zit, of ander methode is inderdaad zeer makkelijk zeker als je een framework/sdk hiervoor hebt .. (html?)

Dus zowel de ISO's als installeerbare packages hebben nut i.m.h.o., als je die toegankelijk maakt kunnen diegenen die interesse hebben in een bepaald gedeelte daar ook zelf aan meewerken.
Hiervoor is het nodige werk nodig en niemand verwacht (hopelijk) dat dit vanzelf gaat, maar voor extra steun van andere developers is minimaal een versiebeheer incl bugtracker noodzakelijk denk ik.
Ik stem overigens ook voor GitHub In principe blijven Jason en Cipher gewoon eigenaar en beheerders van dat project, dus ik zie niet in hoe het daarmee "minder" hun project is, zij bepalen nog steeds wat wel en niet gecommit wordt.
En wat betreft wennen aan Git en/of GitHub: in het begin is het even wennen maar al snel gebruik je liever Git als ftp/scp/samba voor broncode, helemaal als verschillende werkplekken/personen met dezelfde code moeten werken.

ach github of andere techniek who cares .. als het maar werkt .. vergeet niet dat code reviewen van anderen ook tijd kost .. soms meer tijd dan eigen code.

[base_]

vso schreef op maandag 06 januari 2014 @ 23:09:
De lage drempel is IMHO belangrijker .. belangrijker dat een bugvrij product, juist planning wanneer je welke bug/upgrade/addon/web of andere code op focust zorgt ervoor dat je niks uit het oog verliest dat is de roadmap.
[...]
OOB experiance wil zeggen dat je alles zeer laagdrempeling houd

Dat weet ik, maar dat werkt niet voor iedereen, juist diegenen met wat meer ervaring met FreeBSD (die dus ook potentieel meer kunnen helpen bij dev/bugfixen), hebben vaak een prima BSD draaien. Ik draai een filesystem OS niet graag in een virtual machine in ieder geval.

ach github of andere techniek who cares .. als het maar werkt .. vergeet niet dat code reviewen van anderen ook tijd kost .. soms meer tijd dan eigen code.

Ja maar vaak ook minder als zelf bugfixen

[Verwijderd]

Compizfox schreef op maandag 06 januari 2014 @ 23:01:
D'r zijn uiteraard enkele bugs. Zo kan de webinterface niet overweg met ZFS v5000 (feature flags) en LZ4-compressie. Geen breaking bug natuurlijk, maar persoonlijk zou ik dit soort bugs in de webinterface meer prioriteit geven.

Die zijn allang gefixed in beta9, dus als die over x dagen gereleased wordt is de interface in één klap ook weer 'up-to-date' met ZFS v5000. Het had inderdaad eerder gekund, maar is nu eenmaal zo gelopen. In 2013 zijn een hoop dingen gebeurd die nu nog niet tot resultaat leiden, maar in 2014 kan dat tot een inhaalslag leiden met juist veel releases.

Duidelijk Het is wel duidelijk dat er in de community misverstanden/onduidelijkheden hangen rondom dit onderwerp, maar ik ben blij met je antwoord.

Begrijpelijk; er is geen documentatie. Dat gaat allemaal goedkomen in de toekomst. Nieuwe website is daarbij ook een belangrijk punt. Daar zijn ook wilde ideeën over, maar we moeten ook realistisch zijn. Binnen enkele maanden willen we de nieuwe site up hebben.

[FireDrunk]

V2 van mijn Python daemon is al af, ik heb een plugin architectuur gemaakt die automatisch werkt.
hierdoor kan iedereen een plugin schrijven voor de python api daemon en wordt deze automatisch bij het starten geinclude. De plugin kan zelf kiezen welke methodes gepubliceert worden in de api (je kan dus nog steeds private methodes maken voor eigen gebruik binnen de plugin).

Ik heb momenteel 3 plugins:
Files (ophalen file attributen, hernoemen, verwijderen)
Directories (ophalen directory inhoud, groottes)
System (ophalen load, uptime)

_{Uiteraard moet hier een grote ZFS plugin komen, maar daar brand ik mij nog even niet aan}

Leuk begin?

[ Voor 8% gewijzigd door FireDrunk op 07-01-2014 11:39 ]

[CurlyMo]

Geef hem nou eens tijd om eerst op mij te reageren

[Verwijderd]

Klinkt allemaal heel mooi FireDrunk. Ik denk dat we na beta9 al een begin kunnen maken door de ZFSguru web-interface aan te passen.

Concreet zou het volgende kunnen gebeuren:

• Een nieuwe includes/zfsguru-daemon.php library die de toegang regelt tot de daemon die jij hebt geschreven.
• Aanpassing van enkele functies in ZFSguru op bepaalde pagina's naar de nieuwe 'stored procedure approach'.

Dan zou het in beta10 kunnen testen in het wild, waarbij sudo ook nog gebruikt wordt. Of misschien nog beter, en kan er gekozen worden tussen sudo of daemon security model. Of dat veel werk is durf ik nu nog niet te zeggen.

Maar voordat het zover is wil ik het eerst aan Jason laten zien, uiteraard.

En ja... ik moet opschieten. Komt eraan, CurlyMo!

[CurlyMo]

Eventueel laat je tot die tijd 2 apache profielen draaien. 1 als zfsguru (poort x) en 1 als www (poort 80). Dan heb je niet het probleem dat gelijk alle www scripts root toegang hebben. Toen ik hier gisteren achter kwam heb ik dit gelijk thuis even omgezet. FreeBSD ondersteund deze profielen vanuit nature.

[Verwijderd]

ZFSguru gebruikt standaard geen Apache maar Lighttpd. Apache is een addon service package. Maar 'zfsguru' user gebruiken zodat 'www' helemaal gevrijwaard blijft is wel een goed issue. Maar de WebUI en systeemversies zijn onderling uitwisselbaar, dus zomaar veranderen kan ook weer niet. Dan is het wellicht beter te wachten tot FireDrunk zijn daemon goed geïntegreerd is, dan kan de default setting om en wordt sudo standaard niet meer gebruikt.

[CurlyMo]

Het enige wat ik heb hoeven veranderen is in includes/procedure.php:

code:

 if (trim(`whoami`) != 'www')

naar

code:

 if (trim(`whoami`) != 'zfsguru')

en

code:

 super_execute('/usr/sbin/chown www:www'.$filename);

naar
[code]

code:

 super_execute('/usr/sbin/chown zfsguru:zfsguru'.$filename);

includes/common.php:

code:

super_execute('/usr/sbin/chown www:www '.$guru['docroot'].'/config/cache.bin');

naar

code:

super_execute('/usr/sbin/chown zfsguru:zfsguru'.$guru['docroot'].'/config/cache.bin');

includes/samba.php:

code:

 super_execute('/usr/sbin/chown root:www'.$filepath);

naar

code:

 super_execute('/usr/sbin/chown root:zfsguru '.$filepath);

Kan zijn dat ik iets over het hoofd heb gezien, maar voor nu werkt het prima. Ik zou dus gewoon z.s.m. een zfsguru gebruiker invoeren en dan de webgui een check laten doen of het een oud systeem is met www als root of een nieuwe met zfsguru als root.

In vind het met alle respect wel een beetje amateuristisch dat niet vanaf het begin voor een aparte gebruiker is gekozen.

[ Voor 31% gewijzigd door CurlyMo op 07-01-2014 15:43 ]

[DXaroth]

FireDrunk schreef op dinsdag 07 januari 2014 @ 11:39:
V2 van mijn Python daemon is al af, ik heb een plugin architectuur gemaakt die automatisch werkt.
hierdoor kan iedereen een plugin schrijven voor de python api daemon en wordt deze automatisch bij het starten geinclude. De plugin kan zelf kiezen welke methodes gepubliceert worden in de api (je kan dus nog steeds private methodes maken voor eigen gebruik binnen de plugin).

Ik heb momenteel 3 plugins:
Files (ophalen file attributen, hernoemen, verwijderen)
Directories (ophalen directory inhoud, groottes)
System (ophalen load, uptime)

_{Uiteraard moet hier een grote ZFS plugin komen, maar daar brand ik mij nog even niet aan}

Leuk begin?

heb je toevallig iets van een github repo ervoor?

(iets verder terug lezend; dit is geen suffe grap mbt de github discussie (al ben ik een voorstander van github), ik programmeer python zelf, en verveel me nog wel eens )

[ Voor 9% gewijzigd door DXaroth op 07-01-2014 15:40 ]

[FireDrunk]

Nee nog niet, maar dat kan wel. Zal eens kijken wat ik kan doen.

[EnerQi]

Een verzoekje dan: Is het mogelijk om een soort windows verkenner op FreeBSD/ZFSguru te krijgen? Voorheen werd hiervoor "Ajax file explorer" voor gebruikt maar deze service wordt niet meer geupdate (ook niet op sourceforge denk ik ).

Ik wil 'm namelijk gebruiken om files te verplaatsen binnen 2 Pools. Nu gaat dit via het netwerk wat betekend dat de snelheid halveerd (gegevens ophalen en wegschrijven).

Geen idee of dit geadresseerd is in verdere versies van ZFSguru. Ik werd getriggerd door het werk wat Firedrunk gemaakt heeft

[ Voor 6% gewijzigd door EnerQi op 07-01-2014 18:43 ]