Discussie over de toekomst van ZFSguru

[Verwijderd]

Dit is in elk geval waar ik blijf haken met GitLab, na een aantal dagen allerlei dingen proberen. De service is gereed; het werkt bijna out of the box. Apache wordt ingesteld, MySQL database wordt gegenereerd en alle dependencymeuk wordt ook geïnstalleerd. Alleen faalt de serverside javascript 'V8' library, die kennelijk ook nooit ontworpen is om op een ander platform te draaien dan Linux, omdat Apple-gebruikers ongeveer dezelfde problemen tegenkomen. Sommige BSD-gebruikers melden succes met specifieke instructies, maar die werken niet voor mij. Momenteel neem ik even een pauze in het proberen werkend te krijgen van deze service.

De installscript output:

code:

* installing service gitlab
* installing packages
* package redis
* package libxslt
* package ruby
* package ruby19-gems
* package rubygem-builder
* package rubygem-charlock_holmes
* package rubygem-activerecord
* package rubygem-acts-as-taggable-on
* package rubygem-asciidoctor
* package rubygem-awesome_print
* package rubygem-bootstrap-sass
* package rubygem-capybara
* package rubygem-carrierwave
* package rubygem-chosen-rails
* package rubygem-coffee-rails
* package rubygem-colored
* package rubygem-d3_rails
* package rubygem-devise
* package rubygem-devise-async
* package rubygem-enumerize
* package rubygem-fog
* package rubygem-font-awesome-rails
* package rubygem-foreman
* package rubygem-gemoji
* package rubygem-github-markup
* package rubygem-gitlab-gollum-lib
* package rubygem-gitlab-grack
* package rubygem-gitlab-pygments.rb
* package rubygem-gitlab_git
* package rubygem-gitlab_meta
* package rubygem-gitlab_omniauth-ldap
* package rubygem-gon
* package rubygem-grape
* package rubygem-grape-entity
* package rubygem-guard-rspec
* package rubygem-haml-rails
* package rubygem-hipchat
* package rubygem-httparty
* package rubygem-jquery-atwho-rails
* package rubygem-jquery-rails
* package rubygem-jquery-turbolinks
* package rubygem-jquery-ui-rails
* package rubygem-kaminari
* package rubygem-launchy
* package rubygem-minitest
* package rubygem-modernizr
* package rubygem-mysql2
* package rubygem-omniauth-github
* package rubygem-omniauth-google-oauth2
* package rubygem-omniauth-twitter
* package rubygem-pg
* package rubygem-pry
* package rubygem-rack-attack
* package rubygem-rails
* package rubygem-raphael-rails
* package rubygem-rb-inotify
* package rubygem-redcarpet
* package rubygem-redis-rails
* package rubygem-sanitize
* package rubygem-sass-rails
* package rubygem-seed-fu
* package rubygem-select2-rails
* package rubygem-settingslogic
* package rubygem-shoulda-matchers
* package rubygem-simplecov
* package rubygem-sinatra
* package rubygem-six
* package rubygem-slim
* package rubygem-stamp
* package rubygem-state_machine
* package rubygem-thin
* package rubygem-tinder
* package rubygem-turbolinks
* package rubygem-uglifier
* package rubygem-underscore-rails
* package rubygem-unicorn
* package rubygem-webmock
* executing post-installation script

GitLab: creating user account
pw: group name `git' already exists
pw: login name `git' already exists

GitLab: downloading GitLab
Cloning into 'gitlab'...
Switched to a new branch '6-5-stable'
Branch 6-5-stable set up to track remote branch 6-5-stable from origin.

GitLab: downloading GitLab-shell
Cloning into 'gitlab-shell'...
Note: checking out 'v1.7.9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 9e00fb4... 1.7.9

GitLab: copying GitLab-shell configuration file

GitLab: installing GitLab-shell
mkdir -p /home/git/repositories: true
mkdir -p /home/git/.ssh: true
chmod 700 /home/git/.ssh: true
touch /home/git/.ssh/authorized_keys: true
chmod 600 /home/git/.ssh/authorized_keys: true
chmod -R ug+rwX,o-rwx /home/git/repositories: true
find /home/git/repositories -type d -print0 | xargs -0 chmod g+s: true

GitLab: configuring GitLab
mkdir: /home/git/repositories: File exists

GitLab: installing Gems
GEMFILES:
-rw-r--r--  1 git  git   4344 Feb 13 08:31 /home/git/gitlab/Gemfile
-rw-r--r--  1 git  git  15377 Feb 13 08:31 /home/git/gitlab/Gemfile.lock

GitLab: installing gem bundler
Successfully installed bundler-1.5.3
1 gem installed
Installing ri documentation for bundler-1.5.3...
Installing RDoc documentation for bundler-1.5.3...

GitLab: installing gem charlock_holmes
Building native extensions.  This could take a while...
Successfully installed charlock_holmes-0.6.9.4
1 gem installed
Installing ri documentation for charlock_holmes-0.6.9.4...
Installing RDoc documentation for charlock_holmes-0.6.9.4...

GitLab: bundle install
Fetching source index from https://rubygems.org/
Fetching https://github.com/gitlabhq/markup.git
Cloning into bare repository '/home/git/gitlab/vendor/bundle/ruby/1.9/cache/bundler/git/markup-90fc906fa26d94a7fadd7f38abd24089954ab2f7'...
Cloning into '/home/git/gitlab/vendor/bundle/ruby/1.9/bundler/gems/markup-61ade389c1e1'...
done.
Installing rake (10.1.0)
Installing i18n (0.6.9)
Installing minitest (4.7.5)
Installing multi_json (1.8.4)
Installing atomic (1.1.14)
Installing thread_safe (0.1.3)
Installing tzinfo (0.3.38)
Installing activesupport (4.0.2)
Installing builder (3.1.4)
Installing erubis (2.7.0)
Installing rack (1.5.2)
Installing rack-test (0.6.2)
Installing actionpack (4.0.2)
Installing mime-types (1.25.1)
Installing polyglot (0.3.3)
Installing treetop (1.4.15)
Installing mail (2.5.4)
Installing actionmailer (4.0.2)
Installing actionpack-action_caching (1.1.0)
Installing actionpack-page_caching (1.0.2)
Installing activemodel (4.0.2)
Installing activerecord-deprecated_finders (1.0.3)
Installing arel (4.0.1)
Installing activerecord (4.0.2)
Using bundler (1.5.3)
Installing thor (0.18.1)
Installing railties (4.0.2)
Installing hike (1.2.3)
Installing tilt (1.4.1)
Installing sprockets (2.10.1)
Installing sprockets-rails (2.0.1)
Installing rails (4.0.2)
Installing acts-as-taggable-on (2.4.1)
Installing asciidoctor (0.1.4)
Installing descendants_tracker (0.0.3)
Installing ice_nine (0.10.0)
Installing axiom-types (0.0.5)
Installing bcrypt-ruby (3.1.2)
Installing sass (3.2.12)
Installing bootstrap-sass (3.0.3.0)
Installing json (1.8.1)
Installing carrierwave (0.9.0)
Installing timers (1.1.0)
Installing celluloid (0.15.2)
Installing charlock_holmes (0.6.9.4)
Installing coercible (1.0.0)
Installing coffee-script-source (1.6.3)
Installing execjs (2.0.2)
Installing coffee-script (2.2.0)
Installing coffee-rails (4.0.1)
Installing colored (1.2)
Installing connection_pool (1.2.0)
Installing d3_rails (3.1.10)
Installing orm_adapter (0.5.0)
Installing warden (1.2.3)
Installing devise (3.0.4)
Installing devise-async (0.8.0)
Installing diff-lcs (1.2.5)
Installing dotenv (0.9.0)
Installing email_validator (1.4.0)
Installing enumerize (0.7.0)
Installing equalizer (0.0.8)
Installing escape_utils (0.2.4)
Installing eventmachine (1.0.3)
Installing multipart-post (1.2.0)
Installing faraday (0.8.8)
Installing faraday_middleware (0.9.0)
Installing font-awesome-rails (3.2.1.3)
Installing foreman (0.63.0)
Installing gemoji (1.3.1)
Installing github-markdown (0.5.5)
Using github-markup (0.7.6) from https://github.com/gitlabhq/markup.git (at 61ade38)
Installing posix-spawn (0.3.6)
Installing gitlab-grit (2.6.3)
Installing gitlab-flowdock-git-hook (0.4.2.2)
Installing yajl-ruby (1.1.0)
Installing gitlab-pygments.rb (0.5.4)
Installing nokogiri (1.5.10)
Installing sanitize (2.0.6)
Installing stringex (1.5.1)
Installing gitlab-gollum-lib (1.0.2)
Installing gitlab-grack (2.0.0.pre)
Installing gitlab-linguist (2.9.6)
Installing gitlab_git (4.0.0)
Installing gitlab_meta (6.0)
Installing net-ldap (0.3.1)
Installing hashie (2.0.5)
Installing omniauth (1.1.4)
Installing pyu-ruby-sasl (0.0.3.3)
Installing rubyntlm (0.1.1)
Installing gitlab_omniauth-ldap (1.0.3)
Installing gon (5.0.1)
Installing multi_xml (0.5.5)
Installing rack-accept (0.4.5)
Installing rack-mount (0.8.3)
Installing virtus (1.0.1)
Installing grape (0.6.1)
Installing grape-entity (0.3.0)
Installing haml (4.0.4)
Installing haml-rails (0.5.1)
Installing httparty (0.12.0)
Installing hipchat (0.14.0)
Installing http_parser.rb (0.5.3)
Installing httpauth (0.2.0)
Installing jquery-atwho-rails (0.3.3)
Installing jquery-rails (2.1.3)
Installing turbolinks (2.0.0)
Installing jquery-turbolinks (2.0.1)
Installing jquery-ui-rails (2.0.2)
Installing jwt (0.1.8)
Installing kaminari (0.15.1)
Installing kgio (2.8.1)

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

        /usr/local/bin/ruby19 extconf.rb
creating Makefile
Compiling v8 for x64
Using python 2.7.6
Unable to find a compiler officially supported by v8.
It is recommended to use GCC v4.4 or higher
Using compiler: g++
Unable to find a compiler officially supported by v8.
It is recommended to use GCC v4.4 or higher
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 43: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 45: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 46: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 48: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 50: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 52: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 54: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 56: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 58: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 60: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 62: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 64: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 66: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 68: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 70: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 72: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 74: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 76: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 78: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 79: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 81: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 83: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 85: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 87: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 89: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 91: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 93: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 95: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 97: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 99: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 101: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 103: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 105: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 107: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 109: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 111: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 113: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 115: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 117: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 119: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 121: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 123: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 125: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 127: Missing dependency operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 129: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 280: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 281: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 283: Need an operator
make: "/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8/Makefile" line 284: Need an operator
make: Fatal errors encountered -- cannot continue/home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/ext/libv8/location.rb:36:in `block in verify_installation!': libv8 did not install properly, ex
        from /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/ext/libv8/location.rb:35:in `each'
        from /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/ext/libv8/location.rb:35:in `verify_installation!'
        from /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/ext/libv8/location.rb:26:in `install!'
        from extconf.rb:7:in `<main>'

make: stopped in /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/vendor/v8


Gem files will remain installed in /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3 for inspection.
Results logged to /home/git/gitlab/vendor/bundle/ruby/1.9/gems/libv8-3.16.14.3/ext/libv8/gem_make.out
An error occurred while installing libv8 (3.16.14.3), and Bundler cannot
continue.
Make sure that `gem install libv8 -v '3.16.14.3'` succeeds before bundling.

GitLab: Initialize Database and Activate Advanced Features
/usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/spec_set.rb:92:in `block in materialize': Could not find libv8-3.16.14.3 in any of the sources (Bundler::GemNotFound)
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/spec_set.rb:85:in `map!'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/spec_set.rb:85:in `materialize'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/definition.rb:133:in `specs'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/definition.rb:178:in `specs_for'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/definition.rb:167:in `requested_specs'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/environment.rb:18:in `requested_specs'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/runtime.rb:13:in `setup'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler.rb:119:in `setup'
        from /usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.3/lib/bundler/setup.rb:17:in `<top (required)>'
        from /usr/local/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:36:in `require'
        from /usr/local/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:36:in `require'

GitLab: installing rc.d script

GitLab: configuring MySQL database

GitLab: supplying GitLab with MySQL login details

GitLab: copying GitLab web configuration to apache22 Includes directory

* done with post-installation script
* successfully installed gitlab

GCC installeren pakt hij wel en dan verdwijnt de melding dat er geen compatible compiler wordt gebruikt, maar de foutmeldingen blijven net zo goed. In plaats van libv8 zou er ook execjs met 'node.js' gebruikt kunnen worden. Echter, node.js is geen Ruby 'gem' maar wel een FreeBSD port. Maar het installeren van die port wordt niet gedetecteerd door execjs. Het doorzoeken van de code levert ook maar een paar vage references op voor nodejs.

En daar zit ik nu al een tijd op te knagen. libv8 wil niet werken en dat weerhoudt GitLab om te werken op FreeBSD. Voor de rest heb ik de service al aardig af, dus hopelijk met wat hulp dat ik het werkend kan krijgen. En eenmaal werkend weet ik door de service precies hoe het volgende keer geinstalleerd moet worden. Dat is wel het fijne van de services; eenmaal gefixed werkt het gelijk voor iedereen en dat is wel gaaf.

[FireDrunk]

Verwijderd schreef op donderdag 13 februari 2014 @ 17:42:
Zo valt er altijd wel wat te klagen, ook al hebben 'we' aan veel eisen toegegeven.

Waar? Ik zie nog geen resultaten... Enige wat ik zie zijn beloftes (en hierboven wat gepiel met een service welke op github gewoon gratis is. Het moet (weer) 'mooi' en 'voor iedereen'...

Het zal nooit genoeg zijn voor sommigen.

Tuurlijk niet, als je dat verwacht snap je er helemaal niets van Er is altijd ruimte voor verbetering... We bouwen al 10.000 jaar bruggen, en nog elke keer komt er een compleet serverpark aan te pas om plannen te bewerken / genereren voor nieuwe bruggen... Raar is dat toch? Dat zelfs na 10.000 jaar we dat kunstje nog steeds niet goed door hebben?

Als we alles openbaar maken dan is de licentie niet goed, en als we alles public domain maken dan is de code niet goed.

Klets, de licentie zal me jeuken... Zolang we er maar aan bij kunnen dragen.

Ik kan echter weinig met continu negatieve reacties, het is in elk geval weinig bevorderlijk voor het plezier wat ik in het project heb.

Dat snap ik best, ik zou het ook niet leuk vinden. Daarom moet je zo'n project ook niet in je eentje (of met z'n tweeen, maar er is er hier maar 1..) doen. Dat maakt het een stuk makkelijker om kritiek (want dat is het natuurlijk) op te vangen.

Soms denk ik ook voor wie ik het eigenlijk doe.

Ook zeker een valide gedachte, en ik ben eerlijk gezegd blij dat ik niet in jouw schoenen sta... Want als je zoveel kennis hebt van scripting en dergelijke, waarom probeer je er dan niet je werk van te maken en er geld mee te verdienen

Bijna alles wat wij doen is verkeerd volgens jou en anderen.

Ja zeg, jij opent een nieuw topic en je verwacht dat wij hier ZFSguru de hemel in gaan prijzen? Natuurlijk niet... Je moet wel een beetje achter je eigen keuzes blijven staan zeg... Kom op...

Heeft het dan wel zin om überhaupt door te gaan? Dat soort vragen stel ik mijzelf.

EN TERECHT! Je moet als mens (vind ik) je altijd af blijven vragen: Is dit wel wat ik wil, en leid dit tot hetgeen ik wil bereiken? Zo niet, stoppen...

Maar dan moet ik denken aan alle mensen die wél zo blij zijn met ZFSguru. En niet zeuren om endtags of www-user of licentie of serverhosting of gebruikte conventies, maar juist een leuk eigenwijs en uniek product willen hebben wat zij laagdrempelig kunnen gebruiken.

Je gaat mij niet vertellen, dat gebruikers voor ZFSguru kozen omdat het "uniek" is... Uniek is niet een feature die ik in mijn server kan hebben... Het is niet een stukje code wat iets doet... Het is een naampje...
(zelfde geld voor eigenwijs... Daar heb je niets aan?)

Een project met unieke features, unieke werkwijzen, eigen manier van doen.

Unieke features? Mwoh, ja, in potentie zeker ja...
Unieke werkwijzen? Yay, hebben eindgebruikers niets aan...
Eigen manier van doen? Zie boven...

Maar dat alles 'mag' niet van sommigen; althans die indruk krijg ik soms. Maar waarom? Waarom zou je een sympathiek en idealistisch project als ZFSguru iets misgunnen? Ik snap dat niet zo.

Niet mogen? Je mag alles... ik zeg niks... Wie ben ik om jou iets te verbieden? Als je dat denkt, moet je je eens sterk gaan afvragen waarom je op internet zit? Het hele internet zit vol met mensen die vanalles vinden... Daar moet je een beetje sterk tegenover staan

Ik gun het ZFSguru van harte, en ik wil er (gdvr***) zelfs aan meehelpen? Enige probleem is vooral, jullie willen niet uit je comfort-zone komen...

[CurlyMo]

@CiPHER, volgens mij probeert hij met make te compileren. In FreeBSD hoor je gmake te gebruiken ipv make. Even aanpassen in dat script en hij moet weer werken.

[Verwijderd]

@FireDrunk
Nou ik ben behoorlijk uit mijn comfortzone inmiddels; ik heb zelf het gevoel dat ik veel heb opgegeven om jullie gunstig te stemmen. Misschien daarom dat het wat verkeerd viel.

Maar, deze reactie van je kan ik in elk geval veel meer mee dan de twee voorgaande reacties. Ook laat je hier wel degelijk een positieve toon zien. Vooral dat is denk ik wat mij niet lekker zat in je vorige reacties. Dat afkraken komt iets te gevoelig van een persoon waar ik tegenop kijk en graag van wil leren. Realiseer je dat je wel degelijk veel invloed hebt op mij en de keuzes die ik maak.

En natuurlijk heb je gelijk dat alles verbetering behoeft; dat is 100% toepasbaar op ZFSguru op vrijwel alle aspecten. Maar mijn punt is ook dat ik wel degelijk grote stappen heb gezet (lees: Jason overtuigd) om op totaal andere manier te developen, omdat jullie dat beter achten. Ik stelde voor de discussie GitHub/selfhosted nog even uit te stellen, jullie wilden het nu al bespreken en afwegen. Daar is GitLab uitgekomen als zijnde iets wat eigenlijk iedereen tevreden stemt, al zouden sommigen liever gewoon GitHub hebben gezien. Dat ik nu na een week pielen nog geen werkende service heb, is natuurlijk olie op het vuur voor diegenen die mij er nog even aan wilde herinneren dat ze wel degelijk een punt hadden. En dan nog na anderhalve maand discussie de buildscripts toevoegen aan de discussie. Is dat een eerlijke reactie op mijn inspanningen? Is het niet even genoeg zo?

Zoals je in het begin van je betoog erop wijst dat er momenteel enkel plannen zijn en dus nog geen realiteit. Maar de beslissing maken is natuurlijk wel de eerste stap. Dat hebben we inmiddels achter ons en dus wil ik aan de uitvoer beginnen. Zelf dacht ik aan 1) een GitLab service maken 2) hosten op server en 3) logingegevens koppelen aan ZFSguru accounts. Dan kan hij publiek en dan zijn bijdragen e.d. ook op een deftige manier mogelijk vanuit de community. ik verwacht dan ook positieve en hulpvaardige reacties; geen discussieverbredende zijwegen zoals buildscripts wat na anderhalve maand even wordt opgetuigd. Dat vind ik iets minder chique.

Wat je zegt over dat ik achter mijn eigen keuzes moet staan, vind ik erg interessant. Want uit andere hoek in dit topic hoorde ik juist iets als 'als er uit meerdere hoeken dezelfde kritiek klinkt, moet je je aanpassen' of iets in die geest. Dat lijkt in tegenspraak met elkaar.

Ik wil je er aan herinneren dat jullie wel degelijk veel invloed hebben. Juist omdat het project zo klein is, kan flexibel en snel voor een andere (kortetermijns) strategie worden gekozen. Maar ook is het zo dat ik wel degelijk van jullie wil leren.

Komt wel bij dat ik iemand ben met afwijkende opvattingen over tal van zaken. Ik ben iemand die niet graag door de 'confectiemaat' wals wordt gehaald om zo te voldoen aan de massa. In dat licht kun je ook de eigenwijsheid soms verklaren. Maar dat mag je niet verwarren met stugheid en geslotenheid. Bereidwilligheid tot verandering is zeker aanwezig en ik wil juist ook kritische geluiden serieus nemen die tot constructieve verandering kan leiden. Echer, niet alle reacties lijken te voldoen aan dat criterium.

---

Soms denk ik ook voor wie ik het eigenlijk doe.

Ook zeker een valide gedachte, en ik ben eerlijk gezegd blij dat ik niet in jouw schoenen sta... Want als je zoveel kennis hebt van scripting en dergelijke, waarom probeer je er dan niet je werk van te maken en er geld mee te verdienen

Ja, dat is dus het hele punt, FireDrunk. Ik wil geen slaaf zijn van een grote machine (bedrijf) die dingen doet waar ik niet achtersta en visies heeft die ik niet deel. Een MKB-bedrijf kan nog sympathiek zijn, maar sympathieke grote bedrijven zijn haast een contradictio in terminis. Ik wilde niet mijn leven spenderen aan het verwezenlijken van de visies van een ander (CTO/CEO) die louter uit winstbejag zijn bedrijf leidde. Ik heb gekozen voor een leven buiten de mainstream. In plaats daarvan wil ik juist goede dingen voor de mensheid doen; mijn vrije tijd besteden aan zaken waar anderen wat aan hebben. En hopelijk ook een beetje lol daarin te beleven. Tot nu toe vind ik de techniek van potentie enorm interessant en ook de ideeën van Jason sluiten hier goed bij aan. Daar wil ik wel wat tijd van mijn leven in steken.

Maar als ik aan de zijlijn mijn 'supporters' alleen maar 'BOE' hoor roepen, dan ga ik toch twijfelen. Is dit het dan waard? Doe ik het niet gewoon fout? En: why should i care? Ik ga lekker voor Oracle werken; de duivel op queries. Schijt aan jullie allemaal!

Gelukkig denk ik er niet echt zo over, het zijn enkel gedachten die me af en toe bezigen. Dat ik mezelf ook tekort doe op veel manieren. Ook door zo als spreekbuis voor ZFSguru te fungeren en daardoor alle kritiek over me heen te krijgen. Jullie hebben mij 400 posts lang heerlijk kunnen kastijden. Af en toe was het misschien nodig, maar sommige tikken vind ik iets te ver gaan. Daar komt mijn betoog op neer.

[FireDrunk]

Nogmaals: Ik kan het niet vaak genoeg zeggen volgens mij. Stop met je er druk over maken, en er zulke lange replies over te typen... Dat kost veel te veel energie...

DOEN.... gewoon... DOEN...

Github.com -> Create login -> Create project -> Create Team -> initial Commit, commentaar

Schrijf in een uurtje wat documentatie over de code, en klaar. fini, niet nuilen, gewoon doen...

Waarom moeten zfsguru.com logins werken? Ik wil dat helemaal niet... Ik wil gewoon mijn eigen GitHub account gebruiken... Daar is dat ding toch voor? Ik vraag mij sowieso af hoe de security van dat forum geregeld is als ik niet eens mijn password kan resetten? Maar goed... Ik moet stoppen met flamen

[ Voor 28% gewijzigd door FireDrunk op 13-02-2014 20:02 ]

[Verwijderd]

Ik heb nu juist een andere weg bewandeld, want zo simpel als doen is het ook niet. Ik heb ook met Jason te maken en die is ook behoorlijk opgeschoven in zijn comfortzone door straks met Git te moeten werken. Maar ook hij staat daarvoor open, dus ik dacht eindelijk een mooie oplossing te hebben met GitLab wat ook aansluit op de belangen op langere termijn en de persoonlijke wens van Jason om het self-hosted te houden. Probeer het dan niet ingewikkelder te maken; ik snap dat GitHub de gemakkelijkere keuze was. Maar de keuze is gevallen op GitLab om genoemde redenen. En dat mag dan een paar weken langer duren dan GitHub, de belangen zijn dan wel allemaal vervuld. Iedereen happy, toch? Niet zeuren dan.

En dankzij de simpele maar doeltreffende tip van CurlyMo heb ik voorlopig voldoende aanknoping om verder te kunnen. Dus zo simpel kunnen de dingen zijn. Straks hebben we niet alleen een oplossing voor ZFSguru development, maar ook een extra service, en ook een contributie aan diegenen die GitLab op vanilla FreeBSD werkend willen krijgen. Dat vind ik leuke extra's.

Maar nog even: de reden dat ik zoveel tijd besteed aan deze discussie - wat eigenlijk niet in verhouding staat tot het project zelf - is omdat ik het zie als een opmaat voor een groter project; waar de kritiek nog veel harder zal zijn. Wat dat betreft heb ik toch nog mijn zorgen. Ik ben nu eenmaal een gevoelig mens.

FireDrunk schreef op donderdag 13 februari 2014 @ 20:01:
Waarom moeten zfsguru.com logins werken? Ik wil dat helemaal niet... Ik wil gewoon mijn eigen GitHub account gebruiken... Daar is dat ding toch voor? Ik vraag mij sowieso af hoe de security van dat forum geregeld is als ik niet eens mijn password kan resetten? Maar goed... Ik moet stoppen met flamen

Inderdaad, stoppen met en starten met ; er is altijd wel een argument voor een andere keuze te bedenken. Maar ik beschouw het nu als besloten; GitLab gaat er komen hoe dan ook en dat is wat we gaan gebruiken. En wees eerlijk: veel van de eisen zijn ingewilligd. Dat het niet helemaal naar jouw smaak is, snap ik, maar er zijn nog meer mensen die ervan moeten eten, zoals niet de minste Jason zelf.

Waarom geen GitHub zijn ook goede argumenten voor gevoerd; ZFSguru wil meer bereiken met accounts en dingen die je daarmee kunt doen, teneinde juist een community op te bouwen waarbij ZFSguru gebruikers onderling veel met elkaar kunnen doen en ook zelfstandig problemen/services/whatever kunnen verbeteren zonder tussenkomst van ons. De wiki/bugtracker/repo op dezelfde account houden is dan in lijn met deze strategie. Denk ook aan Tweakers die uiteindelijk de frontpage en GoT accounts samen heeft gevoegd. Veel leuker als je dit direct doet natuurlijk.

Wat betreft de huidige code; op dit moment wordt oude CMS-code van Jason oude projecten gebruikt. De bedoeling is dat Mesa dit kan vervangen. Mesa login code heb ik zelf geschreven en is veilig over onbeveiligde http-verbindingen; zonder gevoelig te zijn voor man-in-the-middle password hijacking. Mesa zelf is qua core wel toepasbaar, maar mist nog 'newforum' de forum rewrite die heel flexibel inzetbaar zal moeten zijn; zoals ook binnen de ZFSguru web-interface zelf. Mesa is op dit moment weinig meer dan een rewrite van de libraries van ZFSguru op een schonere en nettere manier zonder ZFSguru-specifiek te zijn dus. Dat maakt Mesa als fundering interessant en kan tegelijkertijd ook als CMS project wat ook als ZFSguru service beschikbaar zal komen om met een paar muisklikken je eigen website te kunnen hosten welke je zelf kunt aanpassen en leuke addons kan enablen. De bedoeling is dat Mesa meer dan ZFSguru nog een community project kan worden, en eigenlijk een grote test voor het grotere project wat Jason en ik voor ogen hebben, waarvan de naam nog even geheim blijft.

Kortom, leuke plannen voor de toekomst en GitLab sluit ook daar goed mee aan; beter dan GitHub. Enig voordeel van GitHub is dat het 5 minuten werk kost ipv twee weken met GitLab. Nou dat is dan maar zo.

[ Voor 49% gewijzigd door Verwijderd op 13-02-2014 20:23 ]

[EnerQi]

Dat happen is best leuk . Het lijstje vind ik ook overbodig, 540 punten kan ZFSguru gerust halen maar het klopt dat het lijstje dusdanig negatief geschreven is, dat niets goed is.

Geduld is een schone zaak en de gebruikers hebben dat geduld niet / onvoldoende. Hier kunnen we direct invloed uitoefenen op het programma wat we bij andere niet kunnen (zoals windows bijvoorbeeld). Als er dan ideeën geaccepteerd worden, willen we deze eigenlijk gisteren al hebben .

Geduld opbrengen is moeilijk maar we (als gebruikers) zullen het toch moeten leren.

[FireDrunk]

Prima, dan zie ik de login wel tegemoet (Mailtje ofzo? )

Mesa login code heb ik zelf geschreven en is veilig over onbeveiligde http-verbindingen; zonder gevoelig te zijn voor man-in-the-middle password hijacking.

Hoe doe je dat? Want je cookie is altijd te jatten...?

[dylanvana]

FireDrunk schreef op donderdag 13 februari 2014 @ 21:05:
Prima, dan zie ik de login wel tegemoet (Mailtje ofzo? )


[...]


Hoe doe je dat? Want je cookie is altijd te jatten...?

Ik gok op een IP check

[Verwijderd]

De sessie is beveiligd met IP, UserAgent en serial-number protection. Maar dat is nog geen garantie opzich dat man-in-the-middle helemaal kansloos wordt. Waar het me vooral om ging is dat er geen logingegevens konden worden gesnifft, waarmee een aanvaller zelf een nieuwe loginpoging/sessie kan wagen.

Met GitLab ben ik nu wat verder: de gems zijn geïnstalleerd en de Passenger error krijg ik niet meer. Ik zit nu bij

code:

ActionView::Template::Error (Couldn't find file 'underscore' in javascripts/application.js:30))

zoals ik bijvoorbeeld hier kan vinden: http://ruby-china.org/topics/15541.

Verder heb ik ook errors als:

code:

PassengerWatchdog (cleaning up...): environment corrupt; missing value for (cleaning up...)

[dylanvana]

Sla je de serial op (encrypted) in een session? Dan kun je beter ip + user agent + static salt encrypten tot een "hash" session. Dan hoef je niet eens iets te vergelijken uit de database maar alleen session a + session b + salt = session c (weliswaar met encryption).

Just my 2 cents

[Verwijderd]

Zodra Mesa in GitLab te vinden is kunnen we er uitgebreid naar kijken.

En hoera, ik heb de eeste GitLab loginpagina gezien!

[Verwijderd]

Welcome to GitLab!
Self Hosted Git Management application.

You don't have access to any projects right now.
You can create up to 10000 projects.

[Midas.e]

mind you, dit was het makkelijke stuk. nu moet je projecten gaan opbouwen, rechten toekennen, branches gaan onderhouden, pull requests gaan valideren etc etc.
Maar ondertussen ben ik trots. Het project kan hier alleen maar beter van worden.

[jacovn]

Zfsguru was precies goed voor mij.

Werkt voor films opslaan en afspelen zonder dat ik veel moet doen.
Standaard pool etc inrichten
Samba share erop zetten

En daarna werken, niks geen gezeur met gebruikers en rechten, gewoon direct werken.

[DXaroth]

Verwijderd schreef op vrijdag 14 februari 2014 @ 01:34:
De sessie is beveiligd met IP, UserAgent en serial-number protection. Maar dat is nog geen garantie opzich dat man-in-the-middle helemaal kansloos wordt. Waar het me vooral om ging is dat er geen logingegevens konden worden gesnifft, waarmee een aanvaller zelf een nieuwe loginpoging/sessie kan wagen.

Met GitLab ben ik nu wat verder: de gems zijn geïnstalleerd en de Passenger error krijg ik niet meer. Ik zit nu bij

code:

ActionView::Template::Error (Couldn't find file 'underscore' in javascripts/application.js:30))

zoals ik bijvoorbeeld hier kan vinden: http://ruby-china.org/topics/15541.

Verder heb ik ook errors als:

code:

PassengerWatchdog (cleaning up...): environment corrupt; missing value for (cleaning up...)

handig... op kantoor draaien wij op meerdere ip adressen, dan kan ik dus niet 'stabiel' inloggen
overigens hebben meer daar last van hor...

en grats met de gitlab installatie

[DXaroth]

Midas.e schreef op vrijdag 14 februari 2014 @ 07:53:
mind you, dit was het makkelijke stuk. nu moet je projecten gaan opbouwen, rechten toekennen, branches gaan onderhouden, pull requests gaan valideren etc etc.
Maar ondertussen ben ik trots. Het project kan hier alleen maar beter van worden.

Rechten is easy, maak een simpele boom structuur aan van groepen, en assign de juiste mensen in de juiste positie in elke groep... elke repository in die groep heeft dan de juiste rechten structuur (waarbij je eventueel mensen meer rechten kan geven mochten die nodig zijn op een per-repository basis).

Branches onderhouden is ook simpel; zet master op protected, dan kunnen enkel mensen met master of owner daar heen pushen .. alle andere mensen moeten netjes met branches werken, en daar een merge request van maken (dat werkt netjes via de web-interface, en houdt rekening met de rechten etc).

Mocht je nog advies nodig hebben qua (rechten|repository) structuur, je weet me inbox te vinden

[CurlyMo]

Was het nu het probleem van make ipv gmake?

---

PHP webserver vrijwel klaar voor testen: +/- 350.886 bytes statisch gecompileerd

[ Voor 45% gewijzigd door CurlyMo op 16-02-2014 02:57 ]

[CurlyMo]

Verwijderd schreef op vrijdag 03 januari 2014 @ 14:03:
Wat we eigenlijk willen is een ultra-ultra-ultra-lichte webserver die kan luisteren op een opgegeven poort en ALLE requests naar één .php script stuurt. Webserver doet HTTP requests en weinig meer. Want lighttpd is zo light nog niet. Het moet echt ultra-light zijn, want 6 kilobyte ofzo. Dat zou gaaf zijn!

Ultra light is niet gelukt, maar wel light
https://github.com/CurlyMoo/zfsguru-webserver

PHP al je webserver zooi laten afhandelen is wel gaaf, maar ook ontzettend zonde van je resources.

PS. websockets ondersteuning heb ik er nu niet inzitten gezien de meningen over een javascript front-end. Als jullie willen dan kan ik die alsnog toevoegen als een soort javascript - webserver - php/python pipe.

[ Voor 14% gewijzigd door CurlyMo op 16-02-2014 13:03 ]

[FireDrunk]

Goed bezig CurlyMo!

CiPHER, ik moet zeggen, ik ben trots op je Doorzetten helpt!

Misschien een idee om een semi-mass mail eruit te doen naar alle ZFSguru forum gebruikers als de GitLab online is? Zodat ook niet NL mensen er van op de hoogte gesteld worden?

Ik kan niet wachten om er eens flink met de bezem door heen te gaan

[CurlyMo]

En toen had pilight ook opeens php support in zijn webgui

[Dutch2007]

niet om dit topic te gaan "neco-en" maar is d'r nog iets van een status update? Ik las enkele weken geleden dat er die gitlabs was opgezet, dat iemand nog een effort gedaan heeft mbt een kleinere webserver...

Maar zowel hier als op het ZFSGuru project forum... is het momenteel wel erg... stil

[Verwijderd]

Haha, ik was al benieuwd wanneer het topic gekickt zou worden. Maar nog een paar dagen geduld; ik ben er bijna... De gitlab service ISO is zo goed als klaar, alleen nu problemen met de hoofdserver.

Nieuwe server ben ik softwarematig aan het inrichten, al moet de definitieve hardware nog besteld worden. Hoster zoeken in amsterdam is ook nog een openstaand puntje. Maar tot nu toe is alles wel redelijk op schema om eind maart online te kunnen, zeg over twee weken.

Problemen met GitLab heb ik nog wel. Daar zou ik opzich wel wat hulp mee kunnen gebruiken. De .iso die ik online zal zetten, installeert GitLab van het begin. Het installeren duurt wel een minuut of 15 door het downloaden en compileren; veel langer dan de paar seconden die het normaal duurt een service te installeren. Maar GitLab gebruikt Ruby on Rails en al die 'gems' worden in feite buiten de packagemanager om geïnstalleerd.

Het probleem is dat ik met het aanmaken van een project, wordt teruggestuurd naar de loginpagina. Eerst dacht ik dat dit kwam door de nieuwe secure cookie-functionaliteit in GitLab 6.5. Maar ook in 6.4.x gebeurt hetzelfde en met de onlangs uitgegeven 6.6.4 eveneens. Kortom, hier zit kennelijk nog iets in de configuratie niet lekker.

GitLab service heb ik tot nu toe alleen voor de 11.0-001 build - die zou vandaag of morgen online komen. Maar nu het een ZFSguru service is, wordt deze standaard geleverd bij alle nieuwe systeemversies. Het werk wat ik in GitLab heb gestoken blijft dus behouden voor de toekomst; dat vind ik zelf wel gaaf aan het bouwen van services. Eén keer het werk doen, meerdere keren plezier van.

[FireDrunk]

Wat is dan de ETA dat GitLab online komt op de Master Server?

[syl765]

En zo loop je van het ene probleem tegen het andere probleem.
In de tussen tijd kun je dus niet aan het project zelf werken maar ben je bezig met allerlei rand zaken. Zonde van de kostbare tijd.

[ikkeenjij36]

Nou ik ben ook wel nieuwsgierig langzamerhand

[Verwijderd]

FireDrunk schreef op dinsdag 11 maart 2014 @ 09:25:
Wat is dan de ETA dat GitLab online komt op de Master Server?

Eind maart had ik eerst genoemd. Dat is nog steeds de vroegst mogelijke datum. Maar ik denk dat April realistischer is. In elk geval voordat het toegankelijk is voor derden. Wellicht valt dat samen met de nieuwe website; dat zou leuk zijn.

syl765 schreef op dinsdag 11 maart 2014 @ 10:37:
En zo loop je van het ene probleem tegen het andere probleem.
In de tussen tijd kun je dus niet aan het project zelf werken maar ben je bezig met allerlei rand zaken. Zonde van de kostbare tijd.

Hmm, nou het lijkt misschien alsof ik afgelopen maand continu bezig ben geweest met GitLab. Maar dat is echt niet zo. Het enige wat echt tijd heeft gekost is de discussie zelf in januari.

Ik hoop ook een beetje dat anderen mij kunnen helpen GitLab goed werkend te krijgen. Dan kan ik me op andere dingen concentreren, zoals:

• Nieuwe server die in Amsterdam komt; definitieve hardware moet nog besteld worden. Ben al wel bezig met een testopstelling zodat ik alvast met het softwareonderdeel kan beginnen. En beter thuis goed testen dan remote debuggen.
• Nieuwe 11.0-001 build heeft diverse verbeteringen m.b.t. dependencies
• Fixed vbox additions icm Newcons vt(9) kernel mode setting (grafische schil).
• Nieuwe service: Webstream; download streams van uitzending gemist en youtube.
• Nieuwe service: Zabbix (server monitoring).
• Nieuwe service: Plex-plexpass (voor Plex-gebruikers met betaalde Plexpass-toegang).
• Apache service verbeterd en out of the box werkend gemaakt.
• Mesa selectors heb ik ook aan gewerkt. Mesa is wat de nieuwe website gaat draaien en ook wat als basis voor de nieuwe ZFSguru zal gaan dienen. Mesa selectors zijn page selectors die modulair werken. De plugin 'newforum' die Jason ontwikkelt, zal hierop aansluiten. De selectors, statistieken en newforum zijn de resterende items voordat de nieuwe site online kan. Ook wel op de planning voor april.
• Klein beetje gewerkt aan de web-interface.

Dat heb ik voornamelijk afgelopen maand gedaan. Maar ik heb ook niet super veel tijd gehad. En je hebt natuurlijk gelijk dat ik mijn tijd zo nuttig mogelijk wil besteden. Maar het fundament is wel belangrijk. Op een goed fundament kun je goed bouwen.

[Dutch2007]

Nu is een server in amsterdam (AMX) we nice , maar... is een grote hoster zoals OVH, en dan vooral een server in RBX (noord frankrijk) --> http://www.ovh.nl/dedicat...enterprise/2014-SP-64.xml

goed om te horen trouwens dat er wel voortgang is...

overigens.... Wellicht goede PR als je 1x in de week? maand? gewoon een status update post zodat mensen weten dat je ergens mee bezig bent?

Ik hoor bijv zooo vaak op het werk, dat 9 van de 10 mensen het niet erg vinden dat er effectief geen vooruitgang is, als ze maar op de hoogte blijven van de status.. (uiteraard "pikken" ze het niet als je 9 maanden met "geen status update" komt...)

Ik zou zeggen..laat vaker wat van je horen via een post ;-) Kan de community je ook vaker / eerder helpen op zaken waar je vast loopt.... genoeg knappe koppen hier me thinks

[ Voor 61% gewijzigd door Dutch2007 op 11-03-2014 23:12 ]

[Verwijderd]

Dutch2007 schreef op dinsdag 11 maart 2014 @ 23:10:
Nu is een server in amsterdam (AMX) we nice , maar... is een grote hoster zoals OVH, en dan vooral een server in RBX (noord frankrijk) --> http://www.ovh.nl/dedicat...enterprise/2014-SP-64.xml

Dat is dedicated; niet colocated. Bovendien een stuk duurder dan ik in gedachten had.

Ik dacht aan iets van rond de 40 euro per maand; die Jason en ik dan delen met elkaar. Dat is prima te doen. Een aantal overwegingen m.b.t. de nieuwe server:

• Nieuwe softwareinstallatie op basis van ZFSguru met jails waarin de services draaien.
• Elke service (jail) zijn eigen IP; eventueel met SSL certificaat.
• Data Security wordt steeds meer een punt; colocated heeft hier voordelen t.o.v. VPS of dedicated. Alle jailed services kunnen op een encrypted volume draaien. Met AES-NI acceleratie kost dat vrijwel geen performance.
• Kosten zijn een groot issue; 100 euro ex. per maand is echt te veel. Dan hebben we het over 1500 euro per jaar. Het moet economischer. Zo heb ik bijvoorbeeld hosters gevonden die de stroom apart afrekenen. Als ik een machine bouw met laag idle power (PicoPSU) dan zou dat voordelig kunnen uitpakken.
• Connectivity is het belangrijke punt; het gaat niet om bandbreedte maar om latency. De alpha-server zou voor de hele wereld goed toegankelijk moeten zijn. AmsIX staat bekend om goede peerings, dus dat leek mij een goede keuze. Maar ik sta open voor suggesties!
• Dicht bij huis als het zaakje onverhoopt plat gaat, is wel zo fijn! Zeker als ik voor hardware kies zonder IPMI.
• Server zou in een land moeten staan met normale wetgeving; dus USA valt af en EU heeft de voorkeur.
• Bandbreedte is een minder groot issue. De alpha-server zou niet als primaire downloadbron fungeren; daarvoor gebruiken we caching/slave servers die repliceren vanaf de masterserver.

Verder sta ik heel erg open voor feedback omtrent de server. Nu kan er nog beslist/veranderd worden. Jason heeft dit min of meer op mijn schouders gezet, dus ik heb alle vrijheid. Maar ook alle last.

goed om te horen trouwens dat er wel voortgang is...

overigens.... Wellicht goede PR als je 1x in de week? maand? gewoon een status update post zodat mensen weten dat je ergens mee bezig bent?

Ja dat zou meer moeten. Lijkt me zelf leuk om quarterly status reports te doen, zoals FreeBSD ook doet. En daarnaast geeft Jason jaarlijks zijn State of the Project met langetermijndoelen.

[CurlyMo]

Ik draai sinds kort op een volledig gesponsorde decidated server voor pilight. Weer een voorbeeld wat een community kan doen Die server draait CentOS met webmin. Als je hulp nodig hebt met inrichten, dan kan ik je wel helpen.

[Verwijderd]

Nouja het idee was dat we één alpha-server hebben helemaal onder ons eigen beheer, en dat de community met een ZFSguru service addon als slave server kan dienen. De beveiliging moet je nu nog zelf doen, maar Jason heeft ook allemaal schetsjes over de nieuwe firewall configuratie pagina die op Network->Firewall moet komen. Dus in de toekomst wordt je eigen slave server maken kinderspel.

Gezien de voorkeuren voor goede beveiliging en de bekendheid met FreeBSD maakt dat een FreeBSD jail setup het meest voor de hand ligt. Dat is voor mij uitstekend te beheren in elk geval; en aangezien ik toch min of meer de 'server admin' word, is ook dat niet onbelangrijk.

Die 40-50 euro is nog prima te doen. Als de bandbreedte van alle downloads maar gratis is. Dat kunnen we dus doen met slave servers. Dan kan de 'bravo' server op den duur weg. In plaats van zelf slave servers gedoneerd van de community te beheren - want dat kost ook tijd - is het dan misschien beter een service addon te maken en ZFSguru als basis te gebruiken. Eat your own dogfood, ofzoiets.

[base_]

Voor 39 euro krijg je bij bijvoorbeeld Transip 1U, 0,5A stroom, 250Gb data en 1 ipv4 adres voor. Echt veel goedkoper ga je niet vinden denk ik.
Misschien een stomme vraag maar wat was nou de reden om een eigen gitlab te gebruiken en niet github? Voor gesloten software is dit logisch maar ik dacht dat ZFSguru open source is?
Je haalt nogal wat extra werk op je nek door een complete server op te zetten en te colocaten . Als je dit leuk vindt om te doen juich ik dit alleen maar toe trouwens .

[Verwijderd]

Server is natuurlijk niet alleen voor gitlab; maar voor alles. De webserver, mailserver, de activatieserver, de master server, de guru database, opslag voor community databases die geïntegreerd worden in de web-interface en andere toekomstplannen. Verder dus extra services zoals GitLab en misschien nog meer sites. Voor Mesa zelf bijvoorbeeld, zodat de community daar ook aan kan meewerken.

Over hosting; ik heb ook al wat goedkopere dingen aangeboden gekregen: 29 euro ex BTW en zelf stroom afrekenen maar bijv. Extra IPs komen daar nog wel bovenop; maar dat is toch vrij goedkoop. Dus tussen de 40 en 50 euro incl. BTW per maand zou mooi zijn.

[ikkeenjij36]

Ivm de kosten,jullie weten dat er genoeg users zijn die willen sponsoren middels paypal of een andere betaal manier dus het lijkt me dat dat op zijn minst een optie zou moeten/kunnen worden?

[Verwijderd]

Donaties zijn zeker welkom, van de zomer ofzo.

Trouwens.. systeemversie 11.0-001 is al beschikbaar zie ik. LiveCDs en aankondiging volgen nog.

[CurlyMo]

base_ schreef op woensdag 12 maart 2014 @ 01:24:
Voor gesloten software is dit logisch maar ik dacht dat ZFSguru open source is?

Dat je de broncode kan lezen betekent niet dat het open source is. Zolang ZFSGuru geen duidelijke licentie toevoegt aan zijn code blijft het dus closed source.

[Afwezig]

Begrijp ik uit de naamgeving van het nieuwste systeem trouwens goed dat het draait op FreeBSD11?

[dylanvana]

Lmfao ik zat nog even in de broncode te kijken. Moest wel even grinniken hoor XD

- de eerste regel begint met het openen van een XML document, lol wtf?
- in de css staat een hele lap code die niet gebruikt wordt door de layout, ook zie ik namen als 'webshop' voorkomen XD
- geen tabs of witruimtes in de code
- onnodig tables in divs gebruiken
- gradient overlay wat erg amatauristisch overkomt
- half gebakken forum dat nergens op lijkt, wiel opnieuw uitvinden, dat gevoel heb ik overigens bij alles wat ZFSguru doet
- inconsistente naamgebruik 'ZFS guru' en 'ZFSguru'

CiPHER als ik jou was zou ik uit dat knutselproject stappen. Je hebt een naam opgebouwd op GoT en daar draagt dit project totaal niet aan bij XD

[Dutch2007]

Verwijderd schreef op woensdag 12 maart 2014 @ 00:04:
[...]

Dat is dedicated; niet colocated. Bovendien een stuk duurder dan ik in gedachten had.

Ik dacht aan iets van rond de 40 euro per maand; die Jason en ik dan delen met elkaar. Dat is prima te doen. Een aantal overwegingen m.b.t. de nieuwe server:

• Nieuwe softwareinstallatie op basis van ZFSguru met jails waarin de services draaien.
• Elke service (jail) zijn eigen IP; eventueel met SSL certificaat.
• Data Security wordt steeds meer een punt; colocated heeft hier voordelen t.o.v. VPS of dedicated. Alle jailed services kunnen op een encrypted volume draaien. Met AES-NI acceleratie kost dat vrijwel geen performance.
• Kosten zijn een groot issue; 100 euro ex. per maand is echt te veel. Dan hebben we het over 1500 euro per jaar. Het moet economischer. Zo heb ik bijvoorbeeld hosters gevonden die de stroom apart afrekenen. Als ik een machine bouw met laag idle power (PicoPSU) dan zou dat voordelig kunnen uitpakken.
• Connectivity is het belangrijke punt; het gaat niet om bandbreedte maar om latency. De alpha-server zou voor de hele wereld goed toegankelijk moeten zijn. AmsIX staat bekend om goede peerings, dus dat leek mij een goede keuze. Maar ik sta open voor suggesties!
• Dicht bij huis als het zaakje onverhoopt plat gaat, is wel zo fijn! Zeker als ik voor hardware kies zonder IPMI.
• Server zou in een land moeten staan met normale wetgeving; dus USA valt af en EU heeft de voorkeur.
• Bandbreedte is een minder groot issue. De alpha-server zou niet als primaire downloadbron fungeren; daarvoor gebruiken we caching/slave servers die repliceren vanaf de masterserver.

Verder sta ik heel erg open voor feedback omtrent de server. Nu kan er nog beslist/veranderd worden. Jason heeft dit min of meer op mijn schouders gezet, dus ik heb alle vrijheid. Maar ook alle last.


[...]

Ja dat zou meer moeten. Lijkt me zelf leuk om quarterly status reports te doen, zoals FreeBSD ook doet. En daarnaast geeft Jason jaarlijks zijn State of the Project met langetermijndoelen.

Als dat te duur is.. (zag onderaan dat je nogal veeeeeel dingen er op wilt hebben...)

http://www.kimsufi.com/nl/ (de wat meer budget servers, waar je zelfs je eigen dedicated server kan krijgen voor €8 (excl btw) de maand)

Optie 2 zou zijn: http://www.soyoustart.nl/aanbiedingen.xml

Voorbeeld: http://www.soyoustart.nl/aanbiedingen/sys-e32-1.xml
35 euro excl btw per maand
42,45 incl btw per maand

Processor Intel Xeon E3 1225v2 - http://ark.intel.com/prod...2-%288M-Cache-3_20-GHz%29
Cores/Threads 4 cores/ 4 threads
Frequentie 3.2 GHz+
RAM 32GB DDR3
Disks 2x 2 TB SATA
Raid Soft
Netwerkverbinding 1Gbps
Bandbreedte 200Mbps
IPv4 1
IPv6 /64
Failover IP tot max. 5 optioneel ( €2.00 Excl. BTW /Maand/IP (Of €2.42 Incl. BTW) )
Backupruimte 100 GB (inbegrepen)

Als je al 5 public IP's wilt, zit je op 54,55 euro (incl btw) per maand

Specs lijken mij goed zat....

[Verwijderd]

CurlyMo schreef op woensdag 12 maart 2014 @ 09:56:
Dat je de broncode kan lezen betekent niet dat het open source is.

Dat betekent het wel. Open source = open broncode. Open source betekent geen FOSS; dat is een groep licenties die liberaal zijn. Vaak wordt dat met 'open source' bedoeld. Maar FOSS is niet hetzelfde als open source. Je kunt open source code hebben die onder strenge regels is omgeven. Zonder expliciete licentie valt alle open broncode hieronder.

Afwezig schreef op woensdag 12 maart 2014 @ 13:06:
Begrijp ik uit de naamgeving van het nieuwste systeem trouwens goed dat het draait op FreeBSD11?

Inderdaad. De 11.0-001 image is gebaseerd op 11-CURRENT en dus het nieuwste wat BSD op dit moment te bieden heeft. Gecompileerd met de nieuwste Clang 3.4 dus ook de snelste binaries die BSD ooit gehad heeft; BSD gebruikte voorheen GCC 4.2 hetgeen heel oud is; omdat nieuwere GCC versies onder de restrictievere GPL3-licentie wordt gereleased. Nu met Clang is BSD minder afhankelijk van Linuxificatie en loopt het niet meer achterop qua compilers.

Op Phoronix kun je zien hoe Clang 3.4 zich verhoudt tot de nieuwste versies van GCC, maar eigenlijk is het verschil nog groter omdat op BSD platform je Clang 3.4 zou moeten vergelijken met GCC 4.2.x, in plaats van GCC 4.9.x. Dat is dus een het verschil nog groter dan op Phoronix te zien is.

Maar er zijn veel meer nieuwe dingen in 11.0. Fixes voor de kernel-implementatie van iSCSI en natuurlijk de introductie van 'Newcons' oftewel vt(9). Dit kun je direct merken bij het booten omdat het nu in grafische mode boot met grafische fonts. Ook kun je nu met de nieuwe KMS-videodrivers switchen naar de console met Ctrl+Alt+F1. Dit werkte voorheen niet als je bijvoorbeeld de Intel KMS-driver gebruikte.

ZFSguru wil graag de nieuwste grafische voorzieningen gebruiken die in FreeBSD te vinden zijn. 11.0-001 systeemversie is daar een goede demo van.

dylanvana schreef op woensdag 12 maart 2014 @ 13:17:
Lmfao ik zat nog even in de broncode te kijken. Moest wel even grinniken hoor XD

Welke broncode bekijk jij dan? Een andere die ik bekijk lijkt het wel. Bekijk je misschien de code van de huidige website van ZFSguru? Dat is inderdaad een misbaksel uit kliekjes van Jason's verleden. Daar ga ik ook niet aan werken; als CMS platform gaat Mesa dienen als schone basis voor alles. De broncode van ZFSguru zelf is prima in orde.

CiPHER als ik jou was zou ik uit dat knutselproject stappen. Je hebt een naam opgebouwd op GoT en daar draagt dit project totaal niet aan bij XD

En dan? Voor Oracle gaan werken? Dan werk ik toch liever voor een sympathiek underdog-project.

Ondanks al het negativisme denk ik dat ik met een klein project veel meer kan verwezenlijken dan anoniem voor een groot bedrijf werken. In dat laatste geval zou ik geen echt leuke dingen doen, maar enkel geld verdienen. Ik vind het wel opvallend dat mensen zoals jij dit als negatief interpreteren in plaats van positief. Dat kan ik zelf niet zo verklaren.

[CurlyMo]

Verwijderd schreef op woensdag 12 maart 2014 @ 15:03:
Dat betekent het wel. Open source = open broncode. Open source betekent geen FOSS; dat is een groep licenties die liberaal zijn. Vaak wordt dat met 'open source' bedoeld. Maar FOSS is niet hetzelfde als open source. Je kunt open source code hebben die onder strenge regels is omgeven. Zonder expliciete licentie valt alle open broncode hieronder.

Je kunt open op verschillende manieren interpreteren. Degene die je door de war haalt zijn:
1. Having no protecting or concealing cover
2. Available for use
3. Free from limitations, boundaries, or restrictions

Openbare broncode valt onder 1 & 2, maar niet 3. Dat komt door het gebrek aan licentie. Open Source valt in de strikte zin ook niet onder 3, daarvoor zou je Free in plaats van als "vrij" moeten lezen als "vrijer".

Broncode is standaard onderhevig aan copyright. Deze ligt bij de maker van de code. Zonder licentie mag je dus niks met deze code doen zonder dat je toestemming krijgt van de maker. Om deze copyright te verruimen zijn Open Source licenties ingesteld. Deze geven aan welke mogelijkheden je als derden hebt om met de onder copyright onderhevige code dingen te doen. Daarom is open broncode dus niet hetzelfde als Open Source.

[Verwijderd]

We kunnen er heel lang over praten, maar ik blijf erbij dat het feit of broncode open toegankelijk is of niet, los staat van de licentie; de voorwaarden waarbij je de code mag gebruiken. Dat lijkt Wikipedia ook te bevestigen:

Free and open-source software (FOSS) is computer software that can be classified as both free software and open source software.

En zoals het GNU-project zegt, is open source letterlijk genomen iets anders, namelijk:

Linux is “open source” software meaning, simply, that anyone can get copies of its source code files.

Verder vind ik deze discussie niet zo interessant. De licentie is tot nu toe geen probleem geweest door gebrek aan contributies. Nu dat binnenkort mogelijk gaat worden nu er aan GitLab en consorten is gewerkt, zal ook de roep om een echte licentie luider worden. Hopelijk is dat van de zomer geregeld en kan ZFSguru verder met een bredere opzet en contributies van buitenaf.

[CurlyMo]

Ik ga in ieder geval niks aan de code doen zolang er geen Open Source licentie is.

[Verwijderd]

De licentie is altijd een ondergeschoven kind geweest. Met twee vaste developers is dat ook geen groot issue. Het idee was een open source project waarbij ook inkomsten uit support konden worden gehaald, evenals (betaalde) integratie in commerciële producten. Daarom is het niet zo simpel om voor GPL of MIT te kiezen qua licentie.

Door de discussie in dit topic is ook de discussie over de licentie opgelaaid. Daar hebben Jason en ik ook diverse keren over gesproken. Er moet nog wat juridisch advies worden ingewonnen, maar de hoofdlijnen staan wel vast. De kern is dat de licentie je alle vrijheid biedt, inclusief commerciëel gebruik, behalve wanneer deze in combinatie met hardware wordt aangeboden. Dus een fysieke NAS verkopen met ZFSguru erop; dan moet je betalen. Zelf ZFSguru installeren voor eigen gebruik of je eigen bedrijf (commerciëel gebruik) blijft natuurlijk gewoon toegestaan.

Een dergelijke licentie zou je van de zomer kunnen verwachten.

[ikkeenjij36]

Begrijp ik goed dat ik dus ook via de webgui kan updaten naar 11.0.1 zonder mijn instellingen kwijt te raken?
En dus nog een betere server eraan over houdt?

[danedaniel]

Ik lees een paar keer over mainstream en voor bedrijven werken en Oracle, maar wel eens aan gedacht om hiervan je werk te maken? En ik denk dat meerdere reacties hier op doelen. En hiervan je werk maken, bedoel ik, ZFSGuru. Misschien eens kijken wat IndieGoGo en/of Kickstarter opleveren qua donaties en het een community project maken eventueel om de ontwikkeling en juist de beveiliging omhoog te tillen. Daarnaast kun je dan meteen hier full-time mee aan de slag in plaats van vrije-tijds werk. Ideetje?

[Dutch2007]

ikkeenjij36 schreef op woensdag 12 maart 2014 @ 18:11:
Begrijp ik goed dat ik dus ook via de webgui kan updaten naar 11.0.1 zonder mijn instellingen kwijt te raken?
En dus nog een betere server eraan over houdt?

Nee, je begint helaas wederom met een schone lei, als je wilt wat jij wilt, moet je het via de commandline doen --> http://www.freebsd.org/do...rading-freebsdupdate.html

Als je dit echter doet, kunnen dingen (helaas) breken in zfsguru....

[tweedebas]

Dutch2007 schreef op woensdag 19 maart 2014 @ 00:49:
[...]


Nee, je begint helaas wederom met een schone lei, als je wilt wat jij wilt, moet je het via de commandline doen --> http://www.freebsd.org/do...rading-freebsdupdate.html

Als je dit echter doet, kunnen dingen (helaas) breken in zfsguru....

Zit zelf hierdoor te denken aan installs van het OS op USB stick, kan je de boel even naast elkaar draaien (switchen tussen welke instantie je boot) totdat je de nieuwe install dezelfde functionaliteit hebt gegeven als de oude.

(Zoek alleen nog naar een goede guide om alle swap en i/o van de usb af te halen. en de config saves wel op de stick)

[CurlyMo]

http://zfsguru.com/forum/zfsgurudevelopment/147

Met wat kleine aanpassingen draai ik het zo al een aantal jaar in een USB RAIDZ1 opstelling met twee sandisk cruzer fits.

[EnerQi]

Verwijderd schreef op woensdag 12 maart 2014 @ 02:07:
Donaties zijn zeker welkom, van de zomer ofzo.

Trouwens.. systeemversie 11.0-001 is al beschikbaar zie ik. LiveCDs en aankondiging volgen nog.

Ik mis nog de aankondigingen en LiveCDs . Niet dat mensen 'm niet kunnen downloaden, maar het is wel handig om te weten wat er nu veranderd (of juist niet). Het geeft ook wat meer "leven" op ZFSguru.com.

[Verwijderd]

SABnzbd 0.7.17 wordt gepacked en hopelijk ben ik vandaag ook klaar met de laatste wijzigingen aan Webstream; waarmee je streams van Uitzendinggemist naar .mp4 bestand kunt downloaden.

Zodra de nieuwe packages zijn geupload zal Jason de 11.0-001 aankondigen.

[fluppie007]

Check ook even waarom de Nvidia drivers niet downloaden voor 11.0-001 .

[FireDrunk]

http://xkcd.com/619/

[Verwijderd]

Die doen het niet voor de 11.0 release; dat is een probleem van BSD zelf, niet van ZFSguru.

Edit: maar er zijn wel de 'nv' open source drivers voor nVidia. Die zijn alleen niet zo snel als de proprietary binary drivers van nVidia zelf. Dat is wat die drivers in de nvidia-drivers service zijn. Zonder dat te installeren, draai je de normale open source drivers. Voor kaarten die door de open source nv-driver niet worden ondersteunt, krijg je dan een trage VESA driver als laatste redmiddel.

Ben wel blij dat Newcons nu goed lijkt te werken. Nu nog AMD 7000/8000-series ondersteuning evenals Intel Haswell graphics, en BSD zit op een redelijk goed niveau voor desktop graphics. Newcons is nu ook naar 10-STABLE geport en zou dus in 10.1 moeten komen.

[ Voor 78% gewijzigd door Verwijderd op 26-03-2014 12:19 ]

[Verwijderd]

Ik verplaats vanaf nu reacties die over ZFSguru in het algemeen gaan, zoals supportvragen, naar het ZFS topic. De bedoeling van dit topic is juist de discussie over de toekomst van ZFSguru en developmentmodel, en niet de werking en of gebruiksvragen van ZFSguru zelf. Daar leent het ZFS topic zich het beste voor.

Dit topic houd ik liever stil totdat er echt nieuws is, zoals dat de GitLab service online is. Elke keer als deze thread weer omhoog gekicked wordt, denken mensen misschien dat het zover is.

[Compizfox]

Deze kwestie zal misschien al eens eerder in dit topic ter sprake zijn gekomen, maar ik heb de laatste tijd dit topic niet actief gevolgd, noch heb ik zin 19 pagina's door te lezen, dus ik vraag het maar even opnieuw:

Hoe zit het nu met het upgraden van ZFSGuru? Met upgraden bedoel ik de FreeBSD-versie, zoals van FreeBSD 9.2 naar 10.0.

Zoals dit nu gaat is dit eigenlijk geen upgrade te noemen, maar eerder een verkapte reinstall. Bepaalde dingen zoals de smb.conf worden wel overgenomen, maar ik heb zelf veel meer aanpassingen gedaan aan het systeem, zoals allerlei software die niet standaard geïnstalleerd staat, configuratie van die software (denk aan uitbreidingen aan SNMP e.d.), extra users en groups, hacks om oudere HDDs lekker te laten werken (mijn oude 750 GB Samsung's moeten TCQ uithebben, anders lopen ze vast), cronjobs, VMXNET3 drivers, dingen in rc.conf en ga zo maar door.

Al die dingen maken het zacht gezegd een rotklus om een update van ZFSGuru uit te voeren en het weerhoudt me er ook zeker van om dat te doen. Zo zit ik nu al een flinke poos op 9.2 terwijl 10.0 al lang uit is.

Mijn vragen zijn: Is er écht geen manier om een upgrade uit te voeren ipv een reinstall? Hoe zit dit met 'vanilla' FreeBSD? Ik heb de ontwikkelingen rondom alternatieven zoals Nas4Free e.d. niet gevolgd, maar is er misschien een ander OS waarna ik beter kan overstappen als ik deze feature wil?

[Verwijderd]

Nu ga ik toch afwijken van het verplaatsen van reacties, maargoed.. vooruit.

De algemene filosofie van ZFSguru is dat je de systeemdisk/installatie eigenlijk nooit nodig hebt. Alles is erop gebouwd dat je met een nieuwe install zo weer verder kunt. Alles behalve de cruciale feature die dat ook echt doet: de migration manager. Die kopiëert wat bestanden zoals smb.conf (Samba configuratie) en maakt daar een enkel ingepakt bestand van; een migration pack. Die kun je downloaden en zelf op je desktop neerpleuren. Kan heel klein zijn zoals een paar kilobytes. Alle configuratie die je nodig hebt zit dan daarin. Bij een nieuwe installatie kun je dan die file meegeven (uploaden via HTML form) en poef, je hebt na reboot weer exact dezelfde installatie.

Ik weet niet hoe het zit met NAS4Free en FreeNAS op dit gebied. Maar ik denk dat ze niet zoiets hebben voor addons in elk geval; iets waar de migration manager ook voor gaat werken. Deze functionaliteit kun je na beta10 verwachten en is de laatste feature die 0.2 blockt. Ik denk dat je na de zomer moet denken, want voorlopig zijn we nu met andere dingen bezig. Maar het staat allemaal al in de startblokken, dus het gaat er wel komen.

Pas met deze feature is ZFSguru 'af' in die zin dat installaties en upgraden lekker makkelijk verloopt. Nu nog kun je lang doen met dezelfde systeemversie. Maar zodra je meer services gebruikt is updaten wel prettig. En straks met geautomatiseerde builds waarbij je om de paar dagen een nieuwe versie kunt installeren, is het niet leuk als je elke keer je configuratie kwijt bent of dat handmatig moet herstellen.

Met vanilla FreeBSD heb je geen feature die dit verzorgt. Je kunt wel het systeem updaten (freebsd-update), maar dan zit je met oude geïnstalleerde software en ook oude configuratiefiles. Ik vind de aanpak van ZFSguru veel netter omdat je elke keer wel met een kersverse installatie begint waarin alles 'puur en eerlijk' nieuw is geïnstalleerd, waarbij je dan vervolgens wat configuratiebestanden naartoe schrijft die je wilt migreren. Dat is een betere aanpak IMO.

VMXNET3 zit vanaf FreeBSD 10 standaard in de kernel, dus dat is een probleem minder.

[Compizfox]

Verwijderd schreef op zondag 06 april 2014 @ 19:05:
Nu ga ik toch afwijken van het verplaatsen van reacties, maargoed.. vooruit.

De algemene filosofie van ZFSguru is dat je de systeemdisk/installatie eigenlijk nooit nodig hebt. Alles is erop gebouwd dat je met een nieuwe install zo weer verder kunt. Alles behalve de cruciale feature die dat ook echt doet: de migration manager. Die kopiëert wat bestanden zoals smb.conf (Samba configuratie) en maakt daar een enkel ingepakt bestand van; een migration pack. Die kun je downloaden en zelf op je desktop neerpleuren. Kan heel klein zijn zoals een paar kilobytes. Alle configuratie die je nodig hebt zit dan daarin. Bij een nieuwe installatie kun je dan die file meegeven (uploaden via HTML form) en poef, je hebt na reboot weer exact dezelfde installatie.

Ik snap dat dat het idee is, maar dat gaat helaas niet zo werken. Als je deze filosofie aanhangt ga je ervan uit dat gebruikers alleen de software gebruiken waar je als developer ondersteuning voor biedt. De werkelijkheid is echter juist dat gebruikers andere software installeren uit de Ports en wijzigingen doen aan het systeem waar je als developer niet op kunt en daarom niet op moet willen anticiperen.

Dit zorgt voor precies het probleem wat ik al aangaf: ja, smb.conf wordt wel weer teruggezet, maar ik heb een enorme waslijst aan dingen die ik weer opnieuw moet aanpassen, installeren of toepassen bij elke 'upgrade' van ZFSGuru.

Daarnaast is er geen mogelijkheid om alle software die geïnstalleerd was weer opnieuw te installeren.

Ik weet niet hoe het zit met NAS4Free en FreeNAS op dit gebied. Maar ik denk dat ze niet zoiets hebben voor addons in elk geval; iets waar de migration manager ook voor gaat werken. Deze functionaliteit kun je na beta10 verwachten en is de laatste feature die 0.2 blockt. Ik denk dat je na de zomer moet denken, want voorlopig zijn we nu met andere dingen bezig. Maar het staat allemaal al in de startblokken, dus het gaat er wel komen.

Het punt is dat ik geen addons wil gebruiken. Ik wil gebruik kunnen maken van de softwarebase die FreeBSD al heeft, en niet afhankelijk zijn van een (veel kleinere) selectie software die óók door ZFSGuru wordt ondersteunt.

Met vanilla FreeBSD heb je geen feature die dit verzorgt. Je kunt wel het systeem updaten (freebsd-update), maar dan zit je met oude geïnstalleerde software en ook oude configuratiefiles. Ik vind de aanpak van ZFSguru veel netter omdat je elke keer wel met een kersverse installatie begint waarin alles 'puur en eerlijk' nieuw is geïnstalleerd, waarbij je dan vervolgens wat configuratiebestanden naartoe schrijft die je wilt migreren. Dat is een betere aanpak IMO.

Ik vind het juist absurd dat er in ZFSGuru geen manier is om te upgraden. Ja, alles is wel puur en nieuw, maar het is gewoonweg ondoenlijk om alles te moeten terugzetten. Bij de gemiddelde gebruiker zijn het misschien 'wat configuratiebestanden' maar ik heb mijn installatie aardig customized, zelfs zo erg dat ik niet eens alles kan onthouden en na een reinstall telkens tegen dingen aanloop die ik dan weer vergeten ben opnieuw toe te passen, natuurlijk tot mijn irritatie.

Ik heb helemaal geen ervaring met vanilla FreeBSD, maar ik neem toch aan dat je na een systeemupgrade toch gewoon de 'oude' software kunt updaten uit de Ports?

VMXNET3 zit vanaf FreeBSD 10 standaard in de kernel, dus dat is een probleem minder.

Ah, dat scheelt, dat wist ik niet

[ Voor 3% gewijzigd door Compizfox op 06-04-2014 22:32 ]

[CurlyMo]

Ik vind een migratie manager eigenlijk niet iets voor een OS.

- Als OS moet je zorgen voor een goede upgrade mogelijkheid. Door gewoon een package repository op te zetten kan dit prima voor elkaar te krijgen zijn. Kijk opnieuw naar hoe ik dit voor XBian heb gedaan, zodat XBian goed samenwerkt met de standaard Raspbian paketten.
- Als gebruiker heb je zelf de verantwoordelijkheid om alles zelf goed te documenteren. Welke packages heb je geïnstalleerd, welke aanpassingen aan de standaard configuraties, welke custom scripts enz. Ik heb dit allemaal dus goed gedocumenteerd zodat ik in no time een nieuwe versie kan installeren.

Een package lijst is zo opgevraagd en opgeslagen zodat je ze allemaal weer kan installeren:

code:

pkg info | awk '{print $1}' | sed 's/\n//' | xargs echo -n > list

later

code:

pkg install $(cat list)

[ Voor 7% gewijzigd door CurlyMo op 06-04-2014 23:09 ]

[Verwijderd]

Ik snap je punt wel: upgraden is lastig. Maar..... mis ik iets? Zijn er andere operating systems die dit wel heel makkelijk kunnen?

Ik weet niet beter dan:


Windows
Enorm gekut altijd. Users directory moet je de profielmap plunderen en omdat je er geen chaos van wilt maken handmatig tussen al die Roaming LocalNow bullshit browsen om je Mozilla mapje te vinden en die naar je backup-map te kopiëren zodat je dat hebt voor je nieuwe installatie. Enorm veel gekut dus.


Ubuntu
Er zal vast allerlei utilities voorhanden zijn, maar ik weet niet beter dan de home directory van je standaard gebruiker te plunderen, inclusief die irritante dotfiles (beginnende met een punt zoals .mozilla) die normaal onzichtbaar zijn, en je dus soms kunt vergeten als je een directory alt+A en control+C doet. Verder hetzelfde als Windows maar dan iets makkelijker omdat alle meuk tenminste in één directory staat. Jeeeej!


FreeBSD
Tja.. hetzelfde als Ubuntu maar omdat BSD vaker als server in gebruik is, zul je ook handmatig alle extra meuk moeten backuppen van wat je gebruikt. Gebruik je apache, dan je apache configuratie directory, logs, www-directory en php.ini en ga zo maar door. Het blijft enorm veel werk als je dat elke keer handmatig moet doen.


NAS4Free / FreeNAS
??? geen idee


ZFSguru
ZFSguru heeft tenminste een plan - een die ik ken althans - om dit probleem goed op te lossen.

Je hebt met de Migration Manager controle over wát je precies meeneemt. Dat kun je zien als een lijstje van dingen die je kunt aanvinken of uitvinken:
[X] Samba configuratie
[X] PHP configuratie
[_] Extra gebruiker: compizfox
[X] Wachtwoord voor gebruiker: ssh
[X] Service: apache (+www dir en configuratie)

Daar maak je een bestandje van die je kunt downloaden en kunt opslaan waar je wilt, om later een server mee te restoren. Diezelfde migration pack kun je gebruiken voor upgrades. Dus bij de 4e stap van de installatie kun je dan de optie vinden om je migration pack te uploaden.

Zo heb je de voordelen:

• Extreem gemakkelijk gebruik; newbie-proof
• Extreem snel je systeem updaten naar nieuwe versie met behoud van settings
• Backup van je configuratie op locale desktop is handig mocht je server crashen heb je alle configuratie ook gelijk op een andere machine.
• Services kunnen eenvoudig met een lijst worden voorzien van configuratie files of directories die moeten worden opgenomen voor migratie.
• Je kunt zelf zien welke bestanden in je migration pack afwijken van de default files, zodat je weet wat je precies meeneemt ipv alleen bestandnamen te zien.
• Je kunt zelf kiezen wat je meeneemt; je kunt een boel 'rommel' achterlaten en zo problemen uitsluiten die je misschien hebt door naar de default configuratie terug te gaan.
• Door het ontwerp van ZFSguru kun je na zo'n nieuwe installatie ook heel eenvoudig weer terug naar je vorige installatie, mocht het niet werken. Dat is toch heerlijk flexibel?

Als jij een beter idee hebt, is dit het slechtste moment om te zwijgen.

[CurlyMo]

Wat @Compizfox zegt en ik ook eerder, is dat je niet alle configuratie bestanden kunt dekken op jullie manier. Dat zijn sommige systemen gewoon te customized voor.

I.p.v. nieuwe installaties zou de ideale manier dus bestaan uit een eigen ZFSGuru pkg repo die het mogelijk maakt om zonder gedonder te upgraden. Nooit meer herinstalleren dus. Wat je dus voorstelt is nog steeds de Windows manier (herinstalleren en backup van bestanden terugzetten), wat ik voorstel is de XBian manier. Die maakt het mogelijk om vanaf Alpha 5 door te knallen naar de laatste versie RC 1.

Draai je dus Alpha 5 dan gaat het dus: Alpha 5 --> Beta 1 --> Beta 1.1 --> Beta 2 --> RC 1.
Draai je dus al Beta 1.1 dan doet die alleen: Beta 1.1 --> Beta 2 --> RC 1.

Allemaal zonder opnieuw te hoeven installeren of bestanden te backuppen.

[ Voor 41% gewijzigd door CurlyMo op 06-04-2014 23:28 ]

[Verwijderd]

Wat @Compizfox zegt en ik ook eerder, is dat je niet alle configuratie bestanden kunt dekken op jullie manier. Dat zijn sommige systemen gewoon te customized voor.

En hoe weet je wat je precies allemaal hebt gecustomized? Ik vergeet dat, en houd dat ook niet bij zoals eigenlijk moet. De ZFSguru-manier is juist heel goed omdat het je dwingt te weten wat je precies als customization gebruikt. Elke upgrade mis je iets of niet, dan werk je je migration pack bij.

Zo kun je ook je eigen script schrijven waarin je installatie van extra packages allemaal verzorgt. Gebruik je dan de migration pack met een nieuwe installatie en alles werkt zoals je dat wilt hebben, dan weet je dat je migration pack goed gelukt is en je die veilig kunt opslaan. Gaat je server stuk heb je binnen no-time een installatie uitgevoerd met de migration pack op je desktop pc. Wil je upgraden, dan kun je eenvoudig aanvinken wat je wilt meenemen. Heb je problemen met een service/app dan kun je er juist voor kiezen met een testinstallatie om niets mee te nemen of minder dingen om zo problemen proberen uit te sluiten.

Kortom, ik zou zeggen dat je juist heel veel controle hebt over je configuratie en customizations, terwijl newbies er nog steeds heel gemakkelijk mee kunnen werken. Dus.. wat is precies de kritiek?

Allemaal zonder opnieuw te hoeven installeren of bestanden te backuppen.

Dat is juist het probleem: zo behoud je ook alle zooi en dat kan verkeerd gaan. Een nieuwe installatie garandeert dat oude dingen die je wellicht hebt verprutst geen oorzaak kunnen zijn van dat iets niet werkt. Dus als je ZFSguru box een keer 'vreemd' doet, is het lekker makkelijk om een nieuwe install erop te knallen met migratie van basale dingen die je gebruikt en nodig hebt. En klaar, probleem opgelost. Je hoeft het niet te weten wat het was, maar je bent binnen een paar minuutjes weer online and kickin'. Dat is wat ik sexy vind.

[Dadona]

Compizfox schreef op zondag 06 april 2014 @ 22:30:
Ik vind het juist absurd dat er in ZFSGuru geen manier is om te upgraden. Ja, alles is wel puur en nieuw, maar het is gewoonweg ondoenlijk om alles te moeten terugzetten. Bij de gemiddelde gebruiker zijn het misschien 'wat configuratiebestanden' maar ik heb mijn installatie aardig customized, zelfs zo erg dat ik niet eens alles kan onthouden en na een reinstall telkens tegen dingen aanloop die ik dan weer vergeten ben opnieuw toe te passen, natuurlijk tot mijn irritatie.

Als je die nu eens op een plek zou neerzetten, bijvoorbeeld in een topic?

[Verwijderd]

Straks staat dat dus lekker in je migration pack.

[CurlyMo]

Verwijderd schreef op zondag 06 april 2014 @ 23:37:
Wil je upgraden, dan kun je eenvoudig aanvinken wat je wilt meenemen. Heb je problemen met een service/app dan kun je er juist voor kiezen met een testinstallatie om niets mee te nemen of minder dingen om zo problemen proberen uit te sluiten.

Het doel van een geslaagde upgrade is juist dat je hier geen zorgen om hoeft te maken. Alles wordt al meegenomen. Als er conflicten ontstaan dan hoort de upgrade je de diff te tonen en vragen wat te doen.

Kortom, ik zou zeggen dat je juist heel veel controle hebt over je configuratie en customizations, terwijl newbies er nog steeds heel gemakkelijk mee kunnen werken. Dus.. wat is precies de kritiek?

Dat de migration manager wordt ingezet als een manier om het falen van passende upgrade mogelijkheden op FreeBSD te omzeilen. Dat vind ik de verkeerde oplossing voor het probleem van het niet kunnen installeren van een nieuwe versie zonder herinstallatie.

Dat is juist het probleem: zo behoud je ook alle zooi en dat kan verkeerd gaan.

Rare aanname dat mijn (of wie dan ook zijn) installatie nu een zooi is Als ik nieuwe programma's nodig heb of bijv. een cross-compiler maak (waar je een zooi programma's voor nodig heb alleen voor het proces), dan maak ik een snapshot. Als de cross-compiler eenmaal werkt, dan maak ik de installatie van al die (inmiddels) overbodige programma's weer ongedaan. Zo kan je dus prima experimenteren zonder ooit een zooi van je installatie te maken.

Een nieuwe installatie garandeert dat oude dingen die je wellicht hebt verprutst geen oorzaak kunnen zijn van dat iets niet werkt. Dus als je ZFSguru box een keer 'vreemd' doet, is het lekker makkelijk om een nieuwe install erop te knallen met migratie van basale dingen die je gebruikt en nodig hebt. En klaar, probleem opgelost. Je hoeft het niet te weten wat het was, maar je bent binnen een paar minuutjes weer online and kickin'. Dat is wat ik sexy vind.

Dat is dus jouw interpretatie van het probleem. Mijn probleem is juist dat ik niet kán upgraden zonder herinstallatie.

[Verwijderd]

Dat de migration manager wordt ingezet als een manier om het falen van passende upgrade mogelijkheden op FreeBSD te omzeilen. Dat vind ik de verkeerde oplossing voor het probleem van het niet kunnen installeren van een nieuwe versie zonder herinstallatie.

Je kunt toch upgraden? make buildkernel/buildworld/installkernel/installworld. Je sluit dan alleen een grote groep newbies uit en hebt alle nadelen van een upgrade van je huidige installatie. Wat als je problemen hebt en om die reden opnieuw wilt installeren? Kortom, wat jij wilt is er al maar is totaal geen oplossing voor 99% van alle ZFSguru gebruikers.

Je hebt het over 'passende upgrade mogelijkheden' maar ik ken dergelijke oplossingen niet. Windows heeft het niet, Linux heeft het niet, FreeBSD heeft het niet, ZFSguru heeft het niet. ZFSguru heeft wel iets wat in de buurt komt, in elk geval heel gemakkelijk te gebruiken en een aantal andere voordelen zoals het voorkomen van problemen.

Rare aanname dat mijn (of wie dan ook zijn) installatie nu een zooi is

Zo raar is dat niet; er is een discussie binnen de BSD-gemeenschap om de hele (directory) structuur om te gooien en af te stappen van het model waarbij systeem en applicaties zich mengen. Bijvoorbeeld een app installeert dingen in /etc en in /usr en in /var. Er gaan stemmen op om dit uit elkaar te trekken, en apps hun eigen gedeelte te geven en het systeem niet meer te vervuilen.

Een nieuwe verse installatie is dus al gelijk een zooi. Zomaar alles meenemen naar je nieuwe installatie, betekent ook dat je de problemen meeneemt van je vorige installatie.

En leuk dat jullie voor de zoveelste keer kritiek hebben op alles. Maar doe zelf eens een suggestie over hoe het dan wel zou moeten? Zoals ik zeg heeft ZFSguru tenminste een oplossing voor dit probleem. Ik heb van jullie nog niets gehoord wat nu niet al in BSD zit.

[ Voor 6% gewijzigd door Verwijderd op 07-04-2014 08:06 ]

[FireDrunk]

Linux heeft iets soortgelijks maar dan door middel van BTRFS integratie in YUM en APT. Deze tools zijn verbouwd zodat ze een snapshot nemen zodra ze een update/upgrade uitvoeren.
Leuke bij BTRFS is dat snapshots bootable zijn. Je kan dus gerust upgraden, en mocht het niet werken, even naar de vorige versie booten, en de upgrade terugdraaien (wat er dus op neer komt dat je een snapshot terugzet).

[Verwijderd]

Nog maar als aanvulling: ik begrijp niet zo goed waarom jullie de beoogde functionaliteit niet juist heel goed vinden.

Je behoudt namelijk de standaard upgradefunctionaliteit van het OS:

• Systeem updaten naar nieuwe BSD versie, handmatig via 'make installworld'
• Systeem updaten naar nieuwe BSD versie, binary via 'freebsd-update'
• Software updaten via portstree
• Software updaten via binary packages (pkg install <pkg>)

Als dat is wat je wilt - zoals CurlyMo waarschijnlijk - dan biedt het OS dit standaard al. Maar voor veel gebruikers is dit niet voldoende:

• Ze willen iets makkelijks wat ze in de ZFSguru web-interface kunnen gebruiken
• Ze willen iets wat werkt voor nieuwe installaties
• Ze willen een backup kunnen maken van hun configuratie/installatie.
• Ze willen iets wat snel werkt; geen urenlange compilaties e.d. maar gewoon een nieuwe install van een paar minuutjes, gevolgd door een reboot.

Bovendien biedt het gelijk een oplossing voor:

• Probleem van vervuilde installaties; je kunt straks een verse installatie doen en toch je dingen meenemen naar je nieuwe installatie.
• Probleem met software (Virtualbox, Transmission) kunnen uitsluiten door met een default installatie te testen. Je kunt straks kiezen wat je gebruikt van je migration pack.
• Je vergeet vaak welke customization je gebruikt; dat heb je straks netjes in je migration pack vastgelegd en je komt er vanzelf achter als die niet meer up-to-date is als je iets mist in je nieuwe installatie.

Als jullie een betere oplossing weten, kom maar op. Maar anders snap ik de fuzz niet zo.

[FireDrunk]

Ik zou het een mooie functie vinden hoor, (geen idee of je mij bedoeld met je 'fuzz')

Het maakt testen een stuk makkelijker. Wel zou ik het echt _HEEL_ duidelijk inzichtelijk maken welke functionaliteit wel en niet in je migration pack zit (dus echt lijsten met applicaties en files).

Anders gaan gebruikers verwachten dat dingen meegenomen worden, terwijl ze dat niet worden.

[CurlyMo]

Ik vind het nogal baud om de huidige unix structuur te beschouwen als:

Een nieuwe verse installatie is dus al gelijk een zooi.

Ik vind de huidige structuur wel prettig, maar dat is een heel andere discussie.

Laat ik duidelijk zijn. De functionaliteit die je wil bieden met de "migration manager" vind ik mooi. Het probleem is alleen dat je hem bouwt vanuit de insteek "migration manager". Het moet gewoon een "settings backup/restore" heten. Op dit moment wordt het een oplossing voor het verkeerde probleem, namelijk dat van het naadloos upgraden van je systeem.

Dat ik FreeBSD kan upgraden weet ik natuurlijk. Het probleem is dat ik niet zomaar ZFSGuru + FreeBSD als geheel kan upgraden. Daarvoor moet ik nogal een reinstall doen.

[Compizfox]

Verwijderd schreef op zondag 06 april 2014 @ 23:14:
Ik snap je punt wel: upgraden is lastig. Maar..... mis ik iets? Zijn er andere operating systems die dit wel heel makkelijk kunnen?

Ik weet niet beter dan:


Windows
Enorm gekut altijd. Users directory moet je de profielmap plunderen en omdat je er geen chaos van wilt maken handmatig tussen al die Roaming LocalNow bullshit browsen om je Mozilla mapje te vinden en die naar je backup-map te kopiëren zodat je dat hebt voor je nieuwe installatie. Enorm veel gekut dus.

Daar heb je gelijk in. Ook Windows is niet te upgraden, maar dat is eigenlijk veel minder een issue omdat je (ik, tenminste) Windows dagelijks gebruikt. Dat betekent dat je na een reinstall binnen een paar dagen alles weer hebt wat je nodig had omdat je tijdens het gebruik alles weer installeert.

Bij een server-OS heb ik dat veel minder en kan ik nog wel weken later dingen tegenkomen waarvan ik denk: fuck, vergeten te installeren. Of: fuck, dit en dat werkt niet. Hoe had ik dat ook al weer opgelost in m'n vorige install?

Ubuntu
Er zal vast allerlei utilities voorhanden zijn, maar ik weet niet beter dan de home directory van je standaard gebruiker te plunderen, inclusief die irritante dotfiles (beginnende met een punt zoals .mozilla) die normaal onzichtbaar zijn, en je dus soms kunt vergeten als je een directory alt+A en control+C doet. Verder hetzelfde als Windows maar dan iets makkelijker omdat alle meuk tenminste in één directory staat. Jeeeej!

Eh nee. Ubuntu kun je gewoon upgraden, met behoud van alles packages e.d.

FreeBSD
Tja.. hetzelfde als Ubuntu maar omdat BSD vaker als server in gebruik is, zul je ook handmatig alle extra meuk moeten backuppen van wat je gebruikt. Gebruik je apache, dan je apache configuratie directory, logs, www-directory en php.ini en ga zo maar door. Het blijft enorm veel werk als je dat elke keer handmatig moet doen.

Jij zei toch in een vorige post toch dat je freeBSD kunt updaten met

freebsd-update

? Nou, dat + Ports updaten en je bent er toch?

Wat jij hierboven beschrijft is weer een reinstall + backups. Je beseft toch wel dat een echte upgrade iets heel anders is?

NAS4Free / FreeNAS
??? geen idee


ZFSguru
ZFSguru heeft tenminste een plan - een die ik ken althans - om dit probleem goed op te lossen.

Je hebt met de Migration Manager controle over wát je precies meeneemt. Dat kun je zien als een lijstje van dingen die je kunt aanvinken of uitvinken:
[X] Samba configuratie
[X] PHP configuratie
[_] Extra gebruiker: compizfox
[X] Wachtwoord voor gebruiker: ssh
[X] Service: apache (+www dir en configuratie)

Daar maak je een bestandje van die je kunt downloaden en kunt opslaan waar je wilt, om later een server mee te restoren. Diezelfde migration pack kun je gebruiken voor upgrades. Dus bij de 4e stap van de installatie kun je dan de optie vinden om je migration pack te uploaden.

Zo heb je de voordelen:

• Extreem gemakkelijk gebruik; newbie-proof
• Extreem snel je systeem updaten naar nieuwe versie met behoud van settings
• Backup van je configuratie op locale desktop is handig mocht je server crashen heb je alle configuratie ook gelijk op een andere machine.
• Services kunnen eenvoudig met een lijst worden voorzien van configuratie files of directories die moeten worden opgenomen voor migratie.
• Je kunt zelf zien welke bestanden in je migration pack afwijken van de default files, zodat je weet wat je precies meeneemt ipv alleen bestandnamen te zien.
• Je kunt zelf kiezen wat je meeneemt; je kunt een boel 'rommel' achterlaten en zo problemen uitsluiten die je misschien hebt door naar de default configuratie terug te gaan.
• Door het ontwerp van ZFSguru kun je na zo'n nieuwe installatie ook heel eenvoudig weer terug naar je vorige installatie, mocht het niet werken. Dat is toch heerlijk flexibel?

Als jij een beter idee hebt, is dit het slechtste moment om te zwijgen.

Ik heb in mijn vorige post al uitgelegd waarom dit systeem, hoe mooi ook bedacht, voor gebruikers zoals mij niet werkt.

Je vergeet trouwens nog een belangrijk os: Debian. Dat is zelfs rolling release. Je zult snappen dat ik dat helemaal geweldig vind

[Compizfox]

Verwijderd schreef op maandag 07 april 2014 @ 07:55:
[...]
Je hebt het over 'passende upgrade mogelijkheden' maar ik ken dergelijke oplossingen niet. Windows heeft het niet, Linux heeft het niet, FreeBSD heeft het niet, ZFSguru heeft het niet. ZFSguru heeft wel iets wat in de buurt komt, in elk geval heel gemakkelijk te gebruiken en een aantal andere voordelen zoals het voorkomen van problemen.

Veel Linux-distributies hebben dat dus wel.

[...]
En leuk dat jullie voor de zoveelste keer kritiek hebben op alles. Maar doe zelf eens een suggestie over hoe het dan wel zou moeten? Zoals ik zeg heeft ZFSguru tenminste een oplossing voor dit probleem. Ik heb van jullie nog niets gehoord wat nu niet al in BSD zit.

Je hebt gelijk: alles maar kritiek is ook niet terecht. Ik wil in elk geval graag complimenten geven voor de nieuwe versie van de webinterface: vooral dat filesharing-gedeelte is erg mooi. Dit zijn de dingen waarom ik ZFSGuru gebruik. Met de beslissingen aan de andere kant van ZFSGuru (services en de manier van updaten dus) ben ik helaas niet altijd mee eens.

[Compizfox]

Verwijderd schreef op maandag 07 april 2014 @ 09:43:
Nog maar als aanvulling: ik begrijp niet zo goed waarom jullie de beoogde functionaliteit niet juist heel goed vinden.

Je behoudt namelijk de standaard upgradefunctionaliteit van het OS:

• Systeem updaten naar nieuwe BSD versie, handmatig via 'make installworld'
• Systeem updaten naar nieuwe BSD versie, binary via 'freebsd-update'
• Software updaten via portstree
• Software updaten via binary packages (pkg install <pkg>)

Als dat is wat je wilt - zoals CurlyMo waarschijnlijk - dan biedt het OS dit standaard al. Maar voor veel gebruikers is dit niet voldoende:

Dat werkt ook gewoon in ZFSGuru? Daar was ik niet vanop de hoogte, ook omdat ik geen ervaring heb met vanilla FreeBSD.

Als ik met die methode ZFSGuru niet sloop, ben ik daarmee al erg geholpen!
Had dat dan eerder gezegd

[Verwijderd]

Compizfox schreef op maandag 07 april 2014 @ 15:58:
Daar heb je gelijk in. Ook Windows is niet te upgraden, maar dat is eigenlijk veel minder een issue omdat je (ik, tenminste) Windows dagelijks gebruikt. Dat betekent dat je na een reinstall binnen een paar dagen alles weer hebt wat je nodig had omdat je tijdens het gebruik alles weer installeert.

Bij een server-OS heb ik dat veel minder en kan ik nog wel weken later dingen tegenkomen waarvan ik denk: fuck, vergeten te installeren. Of: fuck, dit en dat werkt niet. Hoe had ik dat ook al weer opgelost in m'n vorige install?

Je beschrijft hier het probleem dat je vergeet welke customization je gebruikt. En daar biedt ZFSguru als enige een oplossing voor. Want als je je systeem handmatig update, maar in de toekomst om wat voor reden toch opnieuw moeten installeren, weet je niet meer precies wat je allemaal qua customization had, laat staan recente backups hiervan. Met ZFSguru is dat allemaal veel beter geregeld vind ik, althans de plannen/design van de migration manager zoals die er nu ligt.

Ubuntu kun je gewoon upgraden, met behoud van alles packages e.d.

Ja, dat kan elk OS. Maar dan heb je geen schone installatie, maar een gebruikte installatie met alle oude troep. Dan heb je geen van de voordelen die ZFSguru biedt, zoals het kunnen uitsluiten van problemen. Bovendien erg gebruikersonvriendelijk; je moet best wat UNIX-ervaring hebben om succesvol een make buildworld/install en vooral mergemaster af te ronden. En dan zit je nog met al je configuratie van oude software, brrrrrrr. Het kan werken maar schoon en netjes is het niet echt.

Hetzelfde met Windows, die kun je ook upgraden van Windows 2000 naar XP naar Vista naar 7 en weer naar 8. Maar zeg eens eerlijk Compizfox; wil jij dat? Of wil je liever een verse installatie direct Windows 8 (als je dat gebruikt). Waarom zou een upgrade van 2000 naar XP naar Vista naar 7 naar 8 minderwaardig zijn aan een verse kale installatie direct met Windows 8? Juist; al die meuk, alles wat fout kan gaan; alle mogelijke oorzaken van vage problemen en issues. DAAROM doe je toch een herinstallatie?

ZFSguru pakt in één klap een hoop extra voordelen mee. Het is helemaal niet fijn om een 'custom' install te hebben. Als je er gezeik mee hebt, waar ligt het dan aan? Het is fijner om bepaalde snapshots/versies/releases te gebruiken, zoals met ZFSguru de systeemversies en services. Dan gebruik je één versie die voor iedereen geldt. En zodra de geïntegreerde community via de web-interface werkt, is het fijn om te lezen dat versie X nog problemen heeft. Mooi, scheelt weer veel tijd blijf je bij versie Y.

Al die voordelen verlies je als je handmatig gaat upgraden. Voor CurlyMo en andere UNIX-veteranen wellicht geen groot issue. Maar dat vertegenwoordigt wel minder dan 1% van de userbase van ZFSguru. Dat zijn mensen die allang blij zijn dat ze dingen een keer werkend hebben. En als ze met prutsen hun ZFSguru verknallen, hebben ze met de migration manager binnen enkele minuutjes alles weer zoals het was. Heerlijk newbie-vriendelijk en toch veel kracht voor de gevorderde gebruiker die een minder stijle learning curve wilt. Met ZFSguru kun je een beetje prutsen zonder gelijk te moeten huilen als je install niet meer werkt. Zo kun je rustiger dingen uitproberen.

Flashbacks: vroeger in de goede oude tijd ('94) stond ik wel elke week met een nieuwe Windows-installatie te kloten, of weer terug naar de winkel.... Dat probleem is eigenlijk nog steeds niet gefixed. ZFSguru zou het eerste systeem hebben wat dit effectief aanpakt, althans waarvan ik weet van heb. Ik ken immers niet alle OS.

Jij zei toch in een vorige post toch dat je freeBSD kunt updaten met

freebsd-update

? Nou, dat + Ports updaten en je bent er toch?

Als dat is wat je wilt, ja.

Maar dat is niet wat de meeste ZFSguru gebruikers willen. Voorbeeld: wat heb je aan die utilities als je installatie niet meer werkt, door handmatig prutsen of whatever? Mensen willen niet uren kloten in een UNIX-shell waar ze geen drol van begrijpen. Dan is de lol er snel vanaf als je 'gewoon toegang tot je data' wilt hebben. Dat moet gewoon werken, punt. Zonder uren gekloot. Klik klik klik en het werkt, dát is de mentaliteit van ZFSguru. Werkt het niet? Poef, nieuw alles vers, settings restore, werkt weer. Hebben meer mensen dit probleem met een specifieke versie? Dan een uitroeptekentje bij die ene versie, zodat andere mensen een hoop gedoe bespaard kan blijven.

Dat vind ik echt veel beter dan de traditionele upgrade meuk die elk OS wel heeft, de een iets beter dan de ander. Maar als je aan de traditionele utilities genoeg hebt; prima dan heb je de Migration Manager ook niet nodig. Maar ik denk dat dit een heel populaire feature gaat worden die ZFSguru juist een uniek selling point geeft versus andere ZFS platforms.

[CurlyMo]

Het voordeel van unix ten opzichte van windows is dat je paketten volledig kan verwijderen. Je moet als een beetje ervaren unix gebruiker toch wel erg veel moeite doen om je configuratie te verknallen. Dat lukt je eigenlijk alleen door bijv. een kapotte kernel te installeren of je boot loader te verknallen.

En dan zit je nog met al je configuratie van oude software, brrrrrrr.

Je blijft dit herhalen en sinds dit topic begon ben ik het hier wel het minst mee eens. Ja, echte linux newbies en noobs verneuken het op deze manier. Een beetje huis, tuin en keuken sysadmin krijgt het prima voor elkaar om een nette configuratie te maken die ook prima te upgraden is. Daarnaast leven we ook niet meer in de slackware tijd waarin inderdaad alles handmatig geconfigureerd en gecompileerd moest worden.

De huidige yum en apt package managers zijn gewoon geniale tools die de situatie die jij beschrijft gewoon prima opgelost hebben.

En ik blijf het zeggen, dit is niet iets wat alleen Ubuntu of CentOS dagelijks bewijst, maar ook een klein community project als XBian (maar ook OpenElec met hun upgrade mogelijkheden hetzij iets beperkter).

[ Voor 18% gewijzigd door CurlyMo op 07-04-2014 20:23 ]

[Compizfox]

Verwijderd schreef op maandag 07 april 2014 @ 17:42:
[...]

Je beschrijft hier het probleem dat je vergeet welke customization je gebruikt. En daar biedt ZFSguru als enige een oplossing voor. Want als je je systeem handmatig update, maar in de toekomst om wat voor reden toch opnieuw moeten installeren, weet je niet meer precies wat je allemaal qua customization had, laat staan recente backups hiervan. Met ZFSguru is dat allemaal veel beter geregeld vind ik, althans de plannen/design van de migration manager zoals die er nu ligt.

Ik vraag me af of dat met alles gaat werken. Bij dingen die een kwestie zijn van config files aanpassen natuurlijk wel, maar kan de migration manager ook software installeren uit de ports? Software die je handmatig gedownload en gecompileerd hebt opnieuw compileren?

We vallen een beetje in herhaling, want zoals al heb gezegd krijg je met dit idee het probleem dat je niet alles zal kunnen in zo'n migration manager. Een OS is te complex en te customizable voor zoiets.

[...]

Ja, dat kan elk OS. Maar dan heb je geen schone installatie, maar een gebruikte installatie met alle oude troep. Dan heb je geen van de voordelen die ZFSguru biedt, zoals het kunnen uitsluiten van problemen. Bovendien erg gebruikersonvriendelijk; je moet best wat UNIX-ervaring hebben om succesvol een make buildworld/install en vooral mergemaster af te ronden. En dan zit je nog met al je configuratie van oude software, brrrrrrr. Het kan werken maar schoon en netjes is het niet echt.

Hetzelfde met Windows, die kun je ook upgraden van Windows 2000 naar XP naar Vista naar 7 en weer naar 8. Maar zeg eens eerlijk Compizfox; wil jij dat? Of wil je liever een verse installatie direct Windows 8 (als je dat gebruikt). Waarom zou een upgrade van 2000 naar XP naar Vista naar 7 naar 8 minderwaardig zijn aan een verse kale installatie direct met Windows 8? Juist; al die meuk, alles wat fout kan gaan; alle mogelijke oorzaken van vage problemen en issues. DAAROM doe je toch een herinstallatie?

Dat verschilt heel erg per OS.

Ik moet toegeven, een upgrade van Windows heb ik nog nooit gedaan. Maar toen ik Ubuntu op de desktop gebruikte heb ik het wel regelmatig gedaan (ga niet elk half jaar een reinstall doen), en op mijn server doe ik het met Debian regelmatig.
En dat gaat zonder problemen, omdat de package manager (apt/dpkg) daar juist voor gemaakt is. Ik weet niet of je ervaring hebt met apt, dus ik zal het maar even uitleggen.
Met apt kunt je verschillende release-kanalen volgen. Ubuntu is niet rolling release, dus elk half jaar komt er een nieuwe versie uit. Om dat te upgraden naar de volgende versie van Ubuntu, point je apt naar het nieuwe releasekanaal en laat je alles updaten (apt-get dist-upgrade). Hiermee wordt de hele userland geüpdatet.
Linux (als in de kernel, niet GNU/Linux) wordt los van de rest van het OS geüpdatet. In het geval van Ubuntu komen er vaak wel zo'n 5 kernelupdates per Ubuntu-release.
Debian stable werkt net zo, maar testing is rolling release. Dat betekent dat je in Debian het kanaal testing kunt volgen, die altijd verwijst naar de huidige testing-release. Daardoor hoef je nooit up te daten naar een nieuwe versie: je bent altijd up-to-date.
dpkg houdt trouwens rekening met het feit dat de configuratiefiles van software soms verandert. Als de default config van een pakket verandert, en je hebt zelf aanpassingen gemaakt, zal dpkg je vragen wat er moet gebeuren. Bij erg grote wijzigingen (zoals van Apache 2.2 naar 2.4) krijg je nog extra waarschuwingen en info.

En dat werkt allemaal fantastisch. TLDR: Je overdrijft.

Maar goed, deze hele discussie begon ik eigenlijk met de gedachte dat het in ZFSGuru überhaupt niet mogelijk zou zijn om op de vanilla FreeBSD-manier te upgraden. Nu ik beter weet, is het eigenlijk een non-issue waar we over discussiëren

[Verwijderd]

CurlyMo schreef op maandag 07 april 2014 @ 20:16:
Het voordeel van unix ten opzichte van windows is dat je paketten volledig kan verwijderen.

Nou dan valt FreeBSD daarbuiten denk ik?! Ik bedoel, je kunt packages verwijderen ja, maar als de files niet conform de originele checksum maar aangepast zijn zoals zo vaak het geval, blijft die meuk achter. En dan moet je nog het geluk hebben dat die knuppel die de port heeft onderhouden de pkg-plist accuraat en up-to-date heeft gehouden. Nee kom... UNIX is nog steeds een zooitje.. Maargoed dat is inderdaad een heel andere discussie.

Overigens wel interessant dat zelfs het conservatieve UNIX-bolwerk als FreeBSD nu om lijkt te gaan in dit verband, m.b.t. de indeling van /var /usr en /etc.

Je moet als een beetje ervaren unix gebruiker toch wel erg veel moeite doen om je configuratie te verknallen.

Ervaren UNIX-gebruiker ja. Voordat je jezelf 'ervaren' mag noemen op UNIX-gebied, moet je bijna Godlike-status hebben en vele tientallen jaren ervaring. Nou misschien overdrijf ik, maar je kunt heel lang met UNIX werken en eigenlijk nog steeds geen flauw idee hebben hoe het hele zooitje werkt.

Maar nu weet ik waar ik alle help-requests over packages e.d. naartoe kan verwijzen, bedankt voor je aanbod.

Je blijft dit herhalen en sinds dit topic begon ben ik het hier wel het minst mee eens. Ja, echte linux newbies en noobs verneuken het op deze manier. Een beetje huis, tuin en keuken sysadmin krijgt het prima voor elkaar om.....

Precies mijn punt?!!!

En als het om mijn eigen systemen gaat, ben ik een vrij luie sysadmin. Dat is inherent aan het beroep, zou ik haast zeggen.

Daarnaast leven we ook niet meer in de slackware tijd waarin inderdaad alles handmatig geconfigureerd en gecompileerd moest worden.

Nouja goed, FreeBSD is wel aardig die kant op. Je hebt inderdaad binary packages en freebsd-update voor binary upgrades, maar dat werkt alleen vanaf 'pointreleases' zoals 10.0 of 9.2, niet voor 11-CURRENT of 10-STABLE bijvoorbeeld, wat ZFSguru ook draait. Dan is freebsd-update dus geen optie meer en moet je zelf compileren. En ports wil je vaak ook zelf compileren althans ik heb daar altijd de voorkeur aan gegeven. Ook omdat je dan zelf de opties kunt selecteren voor de ports.

De huidige yum en apt package managers zijn gewoon geniale tools die de situatie die jij beschrijft gewoon prima opgelost hebben.

Zijn allemaal prima package tools, maar dat dekt niet de functionaliteit en usability die de Migration Manager gaat bieden, dus ik ben het niet eens met je stelling dat deze utilities het probleem ook 'gewoon prima opgelost' zou hebben. Deze utilities zijn een no-go voor >95% van de ZFSguru gebruikers. De Migration Manager biedt ze veel meer zekerheid en controle over iets wat ze niet begrijpen, althans niet onder de motorkap. Maar dat hoeft toch ook niet? Je kunt toch ook autorijden zonder te weten hoe de auto werkt van binnenin? Een systeem wat jou dwingt ook monteur/sysadmin te zijn om je eigen auto/server te onderhouden, is geen volwaardig systeem. Technologie is er om ons te bevrijden van problemen en taken, niet om ons te knechten aan onderhoud van die krengen.

[Verwijderd]

Compizfox schreef op maandag 07 april 2014 @ 21:39:
Ik vraag me af of dat met alles gaat werken. Bij dingen die een kwestie zijn van config files aanpassen natuurlijk wel, maar kan de migration manager ook software installeren uit de ports? Software die je handmatig gedownload en gecompileerd hebt opnieuw compileren?

Nee, maar natuurlijk wel de officiële services. Als je daarnaast nog ports/packages extra gebruikt/nodig hebt dan kun je dat in je user script stoppen. simpelweg een paar regels met 'pkg install <pkgnaam>' wat van internet wordt gedownload als binary package.

Door je Migration Pack uit te proberen, met daarin jouw user script, kun je zien na een installatie of hij goed werkt, en alles is zoals je wilt. Zo niet, werk je je script bij totdat alles wél goed werkt out of the box. Hartstikke gaaf toch dat je dat allemaal lekker in één file hebt?

Ik moet toegeven, een upgrade van Windows heb ik nog nooit gedaan. Maar toen ik Ubuntu op de desktop gebruikte heb ik het wel regelmatig gedaan (ga niet elk half jaar een reinstall doen), en op mijn server doe ik het met Debian regelmatig.

Er zit natuurlijk wel verschil tussen Windows en Linux, akkoord. Maar mijn punt is toch ook vooral dat je met een oude installatie mogelijke problemen kan veroorzaken. Ik hou ervan dat dingen gewoon werken. Dat ik een appliatie in een bepaalde beschermde omgeving stabiel heb zodat het gewoon zonder gezeik WERKT. Ik loop mijn halve leven al problemen op te lossen en het is fijn als iemand dat maar één keer hoeft te doen. Vandaar mijn liefde voor die services. Heb ik eenmaal een service - GitLab *kuch* - werkend dan heb ik dat wel gelijk voor altijd.

Zo is het ook met de Migration Manager. Het grote voordeel is wel dat je dan een archief hebt van alle configuratie en script die nodig is om een kale installatie te veranderen in een door jou gewenste situatie, volledig out of the box met alleen die ene file en verder kale liveCD of whatever. Dat is toch juist goed?

Verder, is mijn punt ook dat een 'rolling release' of zelf compileren of whatever ervoor kan zorgen dat jij de enige bent met een vaag probleem. Dat haat ik altijd... Ik heb liever een probleem wat ik kan googlen en dat de eerste hit gelijk dé oplossing is, eventjes dit of dat doen, klaar. Fijn, scheelt me weer een half uur en een kuthumeur, thank you Google! Maar die problemen die alleen jij schijnt te hebben; brrrrrr.... Daar ga je uren in stoppen zonder enig resultaat, is mijn ervaring. Ik heb er een fobie voor.

Beter is dus om iets te gebruiken wat 'iedereen' ook gebruikt, zodat als het voor jou niet werkt, je zou denken dat ook anderen die probleem wel eens gehad hebben. En dat kunnen best bugs in de applicatie zelf zijn. Stel bij Virtualbox versie X crashen de VMs elke 0:00 door een stomme bug. Fijn als je dit weet dat je deze versie moet mijden. Maar ik heb het niet persé over een versie van Virrtualbox, maar juist ook over de exacte installatieprocedure. Met ZFSguru gebruik je officiële releases van systeem en services. Nu stelt het nog niet super veel voor, dat klopt. Maar als dit uitbreid en vooral als de community integratie er komt, dan is het wel degelijk een groot voordeel dat je snel geholpen bent met issues, omdat je exact dezelfde software en configuratie draait - in elk geval out of the box - als alle andere gebruikers. Hebben zij een probleem, dan hoor je dat vast wel van in de berichten specifiek over die service.

En dat werkt allemaal fantastisch. TLDR: Je overdrijft.

Bullshit.

[CurlyMo]

CiPHER schreef op zondag 08 april laat in de nacht:
Nou dan valt FreeBSD daarbuiten denk ik?! Ik bedoel, je kunt packages verwijderen ja, maar als de files niet conform de originele checksum maar aangepast zijn zoals zo vaak het geval, blijft die meuk achter.

Nee hoor, dat is precies het verschil tussen bijv. apt-get purge en apt-get remove. De eerste verwijderd echt alles wat van het pakket is. De tweede laat je instellingen staan.

De reden waarom dit fout gaat ligt ergens anders en dat heb ik al eerder met je bediscussieerd:

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.

Zodra je via apt een pakket installeert, dan weet het precies welke bestanden op je schijf bij welk pakket horen. Als een ander pakket een bestand probeert te overschrijven behorend tot een dit eerste pakket dat zal apt zit weigeren. Dat komt omdat het anders geen notie meer heeft welke bestanden bij welk pakket hoort. Dat levert vervolgens dus het probleem op dat een pakket zijn eigen bestanden dus niet meer kan opruimen bij verwijderen.

Als ik dus bijv. mijn pilight pakket bestanden ga zitten aanmaken via mijn postinstall script, dan omzeil ik daarmee o.a. deze functionaliteit van apt en wordt het geheel een zooitje omdat er geen centraal pakket meer is dat precies weet wat pakketten qua bestanden aan het doen zijn. Mijn kritiek was dus ook eerder dat je niet native de BSD packages aan het maken bent, maar er een stap aan toegevoegd heb. Zo ontstaat dus je "zooi".

Maar nu weet ik waar ik alle help-requests over packages e.d. naartoe kan verwijzen, bedankt voor je aanbod.

Ik heb mijn kritiek over jullie manier van packages aanbieden allang gegeven zoals hierboven aangegeven.

CiPHER schreef op zondag 08 april laat in de nacht:
Voordat je jezelf 'ervaren' mag noemen op UNIX-gebied, moet je bijna Godlike-status hebben en vele tientallen jaren ervaring. [...] En als het om mijn eigen systemen gaat, ben ik een vrij luie sysadmin. Dat is inherent aan het beroep, zou ik haast zeggen.

Jammer dat je hier beetje niet dikgedrukt maakt. Ik krijg tijdens de discussie over dit punt inderdaad steeds meer het idee dat je je eigen ervaring als norm gebruikt.

Precies mijn punt?!!!

Alsof ZFSGuru zo'n laag instapniveau heeft?

Verder, is mijn punt ook dat een 'rolling release' of zelf compileren of whatever ervoor kan zorgen dat jij de enige bent met een vaag probleem.

Bij een rolling release is dat zeker niet meer het geval hoor. Je trekt nu compileren er veel te makkelijk mee samen.

Maar die problemen die alleen jij schijnt te hebben; brrrrrr.... Daar ga je uren in stoppen zonder enig resultaat, is mijn ervaring. Ik heb er een fobie voor.

Dan blijft het voor mij echter nog altijd onduidelijk waarom ZFSGuru het 2.5 jaar oude samba recycle bin probleem nog niet heeft opgelost waardoor ik toch nog altijd zelf een oude samba versie moet compileren:
CurlyMo in "Het grote ZFS topic"

Zo is het ook met de Migration Manager. Het grote voordeel is wel dat je dan een archief hebt van alle configuratie en script die nodig is om een kale installatie te veranderen in een door jou gewenste situatie, volledig out of the box met alleen die ene file en verder kale liveCD of whatever. Dat is toch juist goed?

Klopt, dat is het enige wat bijv. apt en yum niet aanbieden, maar daar zijn ze ook niet voor bedoeld. Het zijn inderdaad geen tools om je instellingen op te slaan en terug te kunnen zetten.

Zijn allemaal prima package tools, maar dat dekt niet de functionaliteit en usability die de Migration Manager gaat bieden, dus ik ben het niet eens met je stelling dat deze utilities het probleem ook 'gewoon prima opgelost' zou hebben. Deze utilities zijn een no-go voor >95% van de ZFSguru gebruikers.

Dat komt omdat ze een ander stukje van het door jouw geschetste probleem oplossen: het naadloos kunnen installeren, upgraden en verwijderen pakketten met daarbij rekening te houden met afhankelijkheden. Deze pakketten zijn juist een reden waarom bijv. Ubuntu geschikt is geworden om zelfs door mijn moeder gebruikt te worden. Dat is eigenlijk ook wat je hier zelf beschrijft:

Ik loop mijn halve leven al problemen op te lossen en het is fijn als iemand dat maar één keer hoeft te doen. Vandaar mijn liefde voor die services. Heb ik eenmaal een service - GitLab *kuch* - werkend dan heb ik dat wel gelijk voor altijd. [...] Beter is dus om iets te gebruiken wat 'iedereen' ook gebruikt, zodat als het voor jou niet werkt, je zou denken dat ook anderen die probleem wel eens gehad hebben.

Eigenlijk zou een groot deel van het probleem opgelost kunnen worden door een eigen pkg repository, maar dat wil je jammer genoeg niet. Wat je dan krijgt is dit:

code:

ii  update-inetd                                          4.43                            all                             inetd configuration file updater
ii  update-notifier-common                                0.99.3debian11                  all                             Files shared between update-notifier and adept
ii  upstart                                               1.6.1-1                         armhf                           event-based init daemon
ii  usbutils                                              1:005-3                         armhf                           Linux USB utilities
ii  util-linux                                            2.20.1-5.3                      armhf                           Miscellaneous system utilities
ii  valgrind                                              1:3.7.0-6+rpi1                  armhf                           instrumentation framework for building dynamic analysis tools
ii  vim-common                                            2:7.3.547-7                     armhf                           Vi IMproved - Common files
ii  vim-tiny                                              2:7.3.547-7                     armhf                           Vi IMproved - enhanced vi editor - compact version
ii  watchdog                                              5.12-1                          armhf                           system health checker and software/hardware watchdog handler
ii  wget                                                  1.13.4-3+deb7u1                 armhf                           retrieves files from the web
ii  whiptail                                              0.52.14-11.1                    armhf                           Displays user-friendly dialog boxes from shell scripts
ii  wireless-tools                                        30~pre9-8                       armhf                           Tools for manipulating Linux Wireless Extensions
ii  wpasupplicant                                         1.0-3                           armhf                           client support for WPA and WPA2 (IEEE 802.11i)
ii  xbian-package-cec                                     1.1-4                           armhf                           libcec 2.1.4 for XBian.
ii  xbian-package-config-shell                            2.1.6-68                        armhf                           Configuration utility for XBian.
ii  xbian-package-config-xbmc                             1.1.7-1a                        armhf                           Configuration utility for XBian.
ii  xbian-package-firmware                                1.4.14-0                        armhf                           Firmware for XBian. (Mar 19 2014 23:26:47 Copyright (c) 2012 Broadcom version 98eb97cd0061f2fcff808fe5f32f851d5
ii  xbian-package-initramfs-tools                         1.3.4-6                         armhf                           Initramfs handling tools.
ii  xbian-package-kernel                                  1.3-6.11b                       armhf                           Latest XBian kernel for the Raspberry Pi (3.12.13+)
rc  xbian-package-libshairport                            1.0-1                           armhf                           libshairport for XBian
ii  xbian-package-libtag                                  1.0-2                           armhf                           libtag for XBian
ii  xbian-package-lirc                                    1.4-8.8                         armhf                           Remote controller deamon.
ii  xbian-package-samba                                   2.0.0-4                         armhf                           Windows <--> linux filesharing.
ii  xbian-package-shairplay                               1.0.2-1                         armhf                           libshairplay for XBian
ii  xbian-package-splash                                  2.0.2-5                         armhf                           Splash screen.
ii  xbian-package-upstart-xbmc-bridge                     1.1.0-6b                        armhf                           Bridge between xbmc event and upstart
ii  xbian-package-usbmount                                1.0.5-6                         all                             automatically mount and unmount USB mass storage devices
ii  xbian-package-vnc-server                              1.0.2                           armhf                           VNC Server for Raspberry PI using dispmanx https://github.com/hanzelpeter/dispmanx_vnc.git
ii  xbian-package-xbianhome                               1.0.0-4                         armhf                           default user xbian home dir
rc  xbian-package-xbmc                                    2.9-10.19a                      armhf                           Frodo nightly.
ii  xbian-package-xbmc-gotham-nightly                     2.9-10.32                       armhf                           Gotham nightly
ii  xbian-package-xbmc-scripts                            1.0.5-1                         armhf                           XBian XBMC upstart scripts.
ii  xbian-package-zram-swap                               1.0.5                           armhf                           zram-swap custom xbian package
ii  xbian-update                                          1.0.2-19c                       armhf                           Updater package to XBian 1.0 RC1

Of vertaald naar ZFSGuru zou het er zo uitzien:

code:

tdb-1.2.12,1                   Trivial Database
tiff-4.0.3                     Tools and library routines for working with TIFF images
valgrind-3.8.1_1,1             Memory debugging and profiling tool
vde2-2.3.2                     User-mode virtual ethernet infrastructure
videoproto-2.3.2               Video extension headers
zfsguru-virtualbox-ose-4.3.8           A general-purpose full virtualizer for x86 hardware
zfsguru-virtualbox-ose-kmod-4.3.8_1    VirtualBox kernel module for FreeBSD

Wat er dan bij elke upgrade gebeurt is dat FreeBSD geen virtualbox gaat updaten zolang er geen nieuwe versie in de ZFSGuru repository staat. Pas wanneer gebruikers zelf virtualbox-ose-4.3.8 gaan installeren wordt de officiële versie gebruikt, maar wel eerst de zfsguru-virtualbox-ose-4.3.8 verwijdert, omdat er anders conflicten ontstaan. De gebruiker krijgt dan dus de keus om de ZFSGuru weg te volgen of de FreeBSD.

Als een bepaalde samba versie niet werkt, dan kan ZFSGuru dus een oudere versie blijven aanbieden zonder in conflict te komen met de laatste versie in het officiële kanaal. Als je de zfsguru-samba-x.x.x laat conflicteren met samba-x.x.x, zal je als gebruiker gedwongen worden om één van de twee te gebruiken.

Ook kan je zorgen dat je ZFSGuru kan upgraden net als FreeBSD door via een eigen repository nieuwe versies van je pakketten aan te bieden en daarmee zonder herinstallatie naar nieuwe versies kan upgraden.

Als je de native pkg manier gebruikt los je ook het probleem op dat bepaalde bestanden blijven staan als je een pakket wil verwijderen. pkg weet dan namelijk precies welke bestanden bij welk pakket hoort. Iets dat je nu omzeilt door je extra stap in je service.

De migration manager biedt dan de inderdaad verwelkome aanvullig dat het je bestanden kan backuppen en terugzetten, maar dat hoort dus mijns inziens los te staan van wat de native package managers in welke distro dan ook al aanbieden.

[EnerQi]

CurlyMo schreef op dinsdag 08 april 2014 @ 06:22:
[...]

De migration manager biedt dan de inderdaad verwelkome aanvullig dat het je bestanden kan backuppen en terugzetten, maar dat hoort dus mijns inziens los te staan van wat de native package managers in welke distro dan ook al aanbieden.

Je verwoordt precies wat ik denk dat de migration manager is. Het simpelweg clean beginnen met daarin wat configuratie bestanden is leuk maar niet zaligmakend. Een upgrade van win xp en win 7 gaat ook gepaard met compatibiliteits problemen van software (win 7 heeft een andere kennel bijvoorbeeld of een andere security model). Of sabnzbd veranderd van scriptlanguage, oude config files zijn dan nutteloos.

[FireDrunk]

Die Migration Manager zal zeker een leuke feature zijn, maar juist bij zoiets valt of staat het bij het feit dat gebruikers zelf scripts/tools moeten kunnen bouwen die data meeneemt. Elke installatie is anders, en elke gebruiker heeft andere wensen.

Het moet dus een op plugins gebaseerd systeem zijn waarin gebruikers zelf plugins kunnen maken.
Als je dat niet maakt ga je jouw eigen manier van migreren forceren aan gebruikers.

En forceren is nooit goed...

[Verwijderd]

CurlyMo:

Je begrijft hoe apt-get enzo werken, maar dat zijn Linux-utilities; BSD heeft pkgNG. En het probleem van vervuilde installaties is daarmee echt niet opgelost. Bovendien geef je zelf ook toe dat deze utilities eigenlijk heel andere functionaliteit hebben dan de migration manager, exact mijn punt natuurlijk. De functionaliteit van de migration manager is er voor ZFSguru-gebruikers, de functionaliteit van pkgNG en andere low-level utilities is er voor sysadmins.

Je hebt het over het instapniveau van ZFSguru; die is inderdaad een stuk lager dan het 'beetje sysadmin' waar jij het over hebt. ZFSguru-gebruikers kun je zien als Windows gebruikers die voor de eerste keer een non-Windows OS uitproberen. Voor velen is dit de eerste ervaring met UNIX. Hoe fijn dan om te ervaren dat je geen 'beetje sysadmin' hoeft te zijn en 10-20 jaar ervaring in je broekzak, maar dat je ZFSguru ook kunt bedienen als je kennis niet verder gaat dan Firefox, Word en een IP adres.

Voor hen is pkgNG helemaal geen optie. Is dat wat FreeNAS hun gebruikers ook aanraad? Oh ja gebruik maar gewoon pkgNG als je wilt updaten; al die versies die wij uitbrengen zijn ook gewoon onzin. Als dat zou gebeuren, zou FreeNAS een hoop gebruikers kwijtraken omdat het project niet meer geschikt is voor een groot deel gebruikers door de verlegde moeilijkheidsgraad.

Kortom, ik denk dat je onderschat hoe veel problemen mensen kunnen hebben met hun BSD-systeem als je ze in het diepe gooit, en ook dat je onderschat hoe gemakkelijk gebruikers dingen kunnen slopen. Die klikken op dingen waar jij nooit klikt, denken op manieren hoe jij nooit denkt, doen dingen die jij nooit doet.

Verder ben je voor een rolling release; precies het tegenovergestelde wat ZFSguru wilt. Ik heb al uitgelegd waarom: als jij dezelfde software en configuratie draait als anderen, is dat enorm nuttig bij het detecteren en oplossen van problemen. Bekende problemen van software - zoals Samba 3.6 die geen prullenbak wilt in jouw geval - kun je zo rapporteren en zijn voor anderen enorm veel hulp als ze kunnen zien dat versie X nog wat problemen heeft en je nog het beste bij de vorige stable kunt blijven, of iets in dit richting.

Verder kom je met een eigen pkg repository. Enorm veel tyfuswerk, hele infrastructuur moet daarvoor worden opgezet ook voor het compileren e.d. Zijn we zeker in de herfst beland als ik daar nu aan zou beginnen. En wat is dan de winst? Dat een paar textfiles nu ook in de packages pkg-plist gedekt zit. Daar is het dan om te doen.

Opzich heb je gelijk dat ZFSguru zomaar een eigen filesystem aanmaakt en daar zijn spul in gooit, buiten de pkg-tree om. Maar:
1. Dat is wel allemaal in één specifieke directory; niet in systeemdirs zoals /usr/local/etc.
2. Zelfs niet hetzelfde filesystem, maar op een apart filesystem.
3. Bestaande uit textfiles en persoonlijke data die de service genereert.

Andere applicaties genereren ook bestanden in /tmp en waar dan ook. Het is niet alsof ieder bestand op je systeem tot een pkg toebehoort. Zelfs bij de meest spartaanse systemen waar het 'netjes' geregeld is, is dat niet van toepassing.

Bovendien wilt ZFSguru helemaal niet van pkgNG packages afstappen, maar juist compatible mee blijven. Nu kun je gewoon de FreeBSD pkg repository gebruiken om snel even 'pkg install <x>' mee te doen. Als ik jouw advies volg dan kun je straks maar heel weinig software installeren omdat ZFSguru niet alles heeft gecompileerd op de build server.

Kortom, ik krijg sterk het gevoel dat jullie iets willen wat volgens mij juist de doodsteek zou zijn voor ZFSguru. Als ZFSguru niet anders mag zijn dan de overige projecten en net als overige projecten zou moeten werken, dan vervalt daarmee ook de unique selling point voor het project. Dan zijn we 'gewoon' nog een kloon van FreeNAS en dan nog minder goed ook omdat FreeNAS verder is. Op dit manier concurreren zou het einde van het project betekenen.

Maar juist die unieke features maken dat ZFSguru bestaansrecht heeft. Een eigen kijk op dingen, een eigen stijl, veel mogelijkheden en flexibiliteit, veel problemen waar gebruikers tegenaan lopen een oplossing kunnen bieden. Kortom, ZFSguru doet de dingen die andere projecten niet doen. Dat allemaal opgeven en 'in de pas' gaan lopen zal mijns inziens betekenen dat ZFSguru zijn glans zal verliezen en op den duur ook zal verdwijnen. Firefox is ook niet zo populair geworden omdat het zoveel filosofie deelde met het oudere Mozilla Suite-project.

EnerQi schreef op dinsdag 08 april 2014 @ 08:04:
Je verwoordt precies wat ik denk dat de migration manager is. [..] leuk maar niet zaligmakend.

Als je er zo over denkt als CurlyMo, dan heb je al wat je wilt: pkg. Veel plezier!

De Migration Manager zal een populaire feature gaan worden.

[CurlyMo]

Verwijderd schreef op dinsdag 08 april 2014 @ 13:56:
De functionaliteit van de migration manager is er voor ZFSguru-gebruikers, de functionaliteit van pkgNG en andere low-level utilities is er voor sysadmins.

Ik vind het zo jammer dat je het over twee verschillende dingen blijft hebben terwijl het één het ander kan complementeren.

Voor hen is pkgNG helemaal geen optie.

Dat ligt er maar net aan hoe je het aanbiedt. Voor Ubuntu is de CLI apt in zijn desktop ook geen optie en daarom hebben ze er een GUI omheen gemaakt, maar die nog altijd apt blijft gebruiken voor het installeren van pakketten. Als je pkgNG in een mooie webGUI giet, dan wordt het opeens een stuk gebruikersvriendelijker.

[...] Als jij dezelfde software en configuratie draait als anderen, is dat enorm nuttig bij het detecteren en oplossen van problemen.

Opnieuw zet je twee zaken tegen elkaar af terwijl ze elkaar opnieuw kunnen complementeren. Het gebruik maken van een rolling release maakt het nog steeds mogelijk om eigen versie af te dwingen via je eigen pakketten. Daarvoor zijn conflicten in het leven geroepen.

Als ik jouw advies volg dan kun je straks maar heel weinig software installeren omdat ZFSguru niet alles heeft gecompileerd op de build server.

Opnieuw, je draait en een repo naast, niet in plaats van.

Verder kom je met een eigen pkg repository. Enorm veel tyfuswerk, hele infrastructuur moet daarvoor worden opgezet ook voor het compileren e.d. Zijn we zeker in de herfst beland als ik daar nu aan zou beginnen. En wat is dan de winst?

Ik betwijfel of dat zoveel werk is, maar goed ik heb alleen kennis van het opzetten van een apt repo. Ik ben best bereid om op je aanbod in te gaan om uit te zoeken hoe moeilijk het is en er een makkelijke tutorial over te schrijven. Dan zal ik mijn eigen samba probleem eens als referentie nemen.

Als ZFSguru niet anders mag zijn dan de overige projecten en net als overige projecten zou moeten werken, dan vervalt daarmee ook de unique selling point voor het project.

Ga je dit nu elke keer zeggen als er een stevige discussie is

Volgens mij zeggen velen hier gewoon (net als ik) dat die migration manager prima is, maar dan als aanvulling op de standaard BSD pkg functionaliteit.

Als je nu eens concreet reageert op de volgende punten:
1. Een eigen ZFSGuru repo naast de FreeBSD repo draaien. Gebruiken kunnen dan gewoon gebruik blijven maken maken van alle FreeBSD pakketten.

code:

deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
deb http://xbian.brantje.com stable main
deb http://xbian.brantje.com devel main
deb http://xbian.brantje.com staging main
deb http://apt.pilight.org stable main

2. In de eigen ZFSGuru repo eigen versies van bepaalde pakketten aanbieden (en die voorkomen dat je dezelfde FreeBSD versie kan installeren via conflicten). Zoals ik in het voorbeeld heb laten zien met zfsguru-virtualbox-x.x.x t.o.v. virtualbox-x.x.x. Newbies gebruiken alleen de zfsguru paketten (via de webGUI). Geavanceerdere gebruikers kunnen ook de FreeBSD repo induiken.

code:

root@pi:~# apt-cache search lirc
lirc - infra-red remote control support
xbian-package-lirc - Remote controller deamon.

root@pi:~# apt-cache show xbian-package-lirc
[...]
Conflicts: lirc, iguanair
Replaces: lirc, iguanair
[...]

3. Native pkg pakketten (geserveerd vanuit de ZFSGuru repo) gaan maken i.p.v. je eigen smaak (waarmee je probeert het wiel opnieuw uit te vinden).
4. En dan inderdaad de migration manager een tool maken die je bestanden kan backuppen en terugzetten, maar dan wel modulair zoals FireDrunk voorstelt.

Zoals aangegeven wil ik best een proof-of-concept opzetten.

[Verwijderd]

Volgens mij zeggen velen hier gewoon (net als ik) dat die migration manager prima is, maar dan als aanvulling op de standaard BSD pkg functionaliteit.

Oke, zo had ik het niet helemaal begrepen. Ik dacht juist dat je stelde dat de pkg-utilities ook met een web-interface flansje de functionaliteit van de migration manager overbodig maakte.

En natuurlijk: je hebt zowel de BSD package utilities als de extra functionaliteit die ZFSguru biedt: de migration manager. Je kunt ze prima beide gebruiken, ze hoeven elkaar zeker niet te bijten.

Ook heb je gelijk dat je zowel rolling release kunt combineren met ZFSguru; je begint met een snapshot van een officiële systeemversie en je kunt via de BSD-utilities updaten naar wat je wilt, en daarmee afwijken van de door ZFSguru aangeboden systeemversies als je dat wilt.


Appliance versus Systeem
Maar we draaien hier om een heel belangrijk issue heen: appliance vs. systeem. Wat jij beschrijft is een systeem wat goed onderhouden kan worden door een sysadmin. Met allerlei utilities is dat goed te doen en heb je controle over wat er gebeurt over je systeem. Precies wat jij wilt.

Maar begrijp dat ZFSguru juist ook iets wilt bieden wat FreeBSD en alle vanilla OS niet van zichzelf bieden: een appliance. Daaronder versta ik iets wat voor eindgebruikers als gereedschap voorhanden is, en het beoogt ook altijd te doen. Denk aan je auto waarin software zit. Je wilt niet voor het wegrijden eerst de software moeten updaten of eventjes pkg dit of repo dat. Dat wil je toch niet?

Hetzelfde geldt voor een NAS. ZFSguru erop en je hebt een NAS draaien, dat is de insteek. Niet dat je met ZFSguru een systeem hebt waar jij als sysadmin mag onderhouden. Dat kán, als je dat wilt. Maar dan wijk je af van de ZFSguru appliance filosofie en maak je van een ZFSguru appliance eigenlijk een BSD server.

De BSD server krijg je er min of meer gratis bij; dat is er al. ZFSguru werkt aan het verwezenlijken van het Appliance-gevoel. Dat iets eigenlijk altijd werkt na wat resetten of rammelen. Geen systeem waar je uren onderhoud en configuratie in hoeft te steken. Dat is nu juist de reden dat ik ZFSguru zo goed vind.

Wat je voorstelt met een eigen repo is opzich wel haalbaar, maar het blijft toch redelijk wat werk. Ik blijf erbij dat ik niet echt heel goed zie wat de meerwaarde is. Netter opzich, maar er zijn meer manieren. Er kunnen ook ports van alle ZFSguru services worden gemaakt. Of een eigen portstree. Of een git repo met alle service blueprints; alles behalve de packages zelf dus. Beter zoiets dan packages maken met daarin packages, dat vind ik niet heel netjes.

Dus concluderend:

• ZFSguru biedt straks een Migration Manager in de web-interface, die functionaliteit biedt die de package-functionaliteit van het operating system niet kan bieden.
• De Migration Manager geldt als extra functionaliteit die naast de standaard pkg utility kan worden gebruikt.
• ZFSguru wil niet alleen een server OS zijn maar ook vooral een server appliance; dat vereist een andere kijk op hoe het systeem wordt gemanaged om eindgebruikers de voordelen te geven van een appliance: iets wat 'altijd' werkt heel laagdrempelig werkt en geen/nauwelijks onderhoud nodig heeft. Het 'onderhoud' bestaat vaak uit een reset - wat neerkomt op een nieuwe installatie met de migration manager, iets wat op een SSD binnen 60 seconden te doen is vanaf stap 1.
• ZFSguru bedient niet alleen sysadmins (heel weinig vermoed ik) maar vooral mensen die een laagdrempelig NAS of server appliance willen, omdat ze geen kennis van UNIX hebben of omdat ze dat wel hebben maar een appliance achtig iets willen waar ze niet elke keer tijd en energie in hoeven te steken.

[CurlyMo]

We beginnen elkaar langzaam te begrijpen

Verwijderd schreef op dinsdag 08 april 2014 @ 15:53:
Ik blijf erbij dat ik niet echt heel goed zie wat de meerwaarde is.

Dat ZFSGuru en FreeBSD naadloos in elkaar samengaan. In jouw woorden (wat zwart / wit): FreeBSD als het Systeem en ZFSGuru als de Appliance. Hierin heeft echter ZFSGuru de touwtjes in handen. Die bepaald of sommige pakketten van (de) ZFSGuru (repository) moeten komen of niet.

Beter zoiets dan packages maken met daarin packages, dat vind ik niet heel netjes.

Dat is precies mijn probleem met je huidige aanpak Een service met zijn eigen pre en post installatie scripts met daarin een pkgNG package die ook weer (mits aanwezige) pre en post installatie scripts draait.

[Verwijderd]

Dat ZFSGuru en FreeBSD naadloos in elkaar samengaan. In jouw woorden (wat zwart / wit): FreeBSD als het Systeem en ZFSGuru als de Appliance. Hierin heeft echter ZFSGuru de touwtjes in handen.

Oke, klinkt goed. Je punt is eigenlijk dat je een vervanger wilt zien van de huidige service structuur. Dat wil je 'netter integreren' met de standaard systeem utilities, begrijp ik je zo goed? Zo ja, dan valt daar natuurlijk best wat voor te zeggen.

Dat is precies mijn probleem met je huidige aanpak Een service met zijn eigen pre, en post installatie scripts met daarin een pkgNG package die ook weer pre en post installatie scripts draait.

Ik snap je punt hier, maar begrijp dat ZFSguru als een laag boven de normale packages gezien kan worden. Dus alles in één package integreren vind ik niet mooi, omdat het dan niet meer standaard op de pkgNG-packages is gebaseerd. ZFSguru gebruikt normale pkgNG-packages zoals je die zelf ook geïnstalleerd kunt hebben via de portstree of remote repo. Daar bovenop zijn er scripts om een en ander te configureren.

Voorbeelden genoeg: VirtualBox had eerst geen VNC integratie in phpVirtualBox. Dus heeft ZFSguru een workaround/hack gemaakt om dat mogelijk te maken. En veel services hebben aangepaste config files. Dan kun je zowel de default config als de ZFSguru provided config gebruiken; beide heb je.

Waar ik niet zo voor ben is het versmelten van beide werelden; zodat je met een ZFSguru service eigenlijk geen normale package meer hebt. Dat betekent namelijk ook dat je niet meer b.v. Virtualbox opnieuw kunt compileren met extra opties maar wel gewoon de ZFSguru service blijven gebruiken. Nu kan dat, omdat ZFSguru services gewoon normale pkgNG-packages gebruiken. Zou ZFSguru zijn eigen packages met alles daarin, dus de ZFSguru installscripts + van de pkg zelf allebei in één tarball.

Daarnaast: we zijn klein, we moeten onze kansen benutten. Het omploegen van de service architectuur met iets wat wellicht net iets beter is, maar weinig tot geen concrete verbetering biedt aan de eindgebruiker, is niet iets wat hoog op het lijstje staat.

Het bieden van geautomatiseerde builds samen met de migration manager, is veel belangrijker. Daarmee kan ZFSguru zijn ambities verwezenlijken om van ZFSguru een server appliance te maken. Dat staat logisch dan ook hoger op de lijst. Maar er zal inderdaad heus wel een opvolger komen van de huidige service infrastructuur. Maar voor nu werkt het eigenlijk prima met veel voordelen en flexibiliteit.

Begrijp me niet verkeerd: je hebt zeker wel goede punten gemaakt en iets in de richting van wat je voorstelt zal er ooit ook wel komen. Maar ik moet ook realistisch zijn en naar de haalbaarheid en prioriteit kijken. Zou je nu energie in een proof-of-concept steken, zal dat waarschijnlijk niet direct leiden tot een implementatie die ZFSguru op korte termijn gaat gebruiken. Dus dan vind ik het ietwat zonde.

Sommige discussies over ZFSguru moeten we denk ik over een jaar voeren. Laten we nu beginnen met het laaghangend fruit; daar valt genoeg te plukken. Zoals een keer de GitLab service afbouwen, ik hoop vandaag de final version te uploaden. Dat goed werkend krijgen (er zijn nog wat issues) is denk ik een energie die beter besteed is op dit moment.

[CurlyMo]

Verwijderd schreef op dinsdag 08 april 2014 @ 17:05:
Oke, klinkt goed. Je punt is eigenlijk dat je een vervanger wilt zien van de huidige service structuur. Dat wil je 'netter integreren' met de standaard systeem utilities, begrijp ik je zo goed? Zo ja, dan valt daar natuurlijk best wat voor te zeggen.

Precies.

Ik snap je punt hier, maar begrijp dat ZFSguru als een laag boven de normale packages gezien kan worden. Dus alles in één package integreren vind ik niet mooi, omdat het dan niet meer standaard op de pkgNG-packages is gebaseerd. ZFSguru gebruikt normale pkgNG-packages zoals je die zelf ook geïnstalleerd kunt hebben via de portstree of remote repo. Daar bovenop zijn er scripts om een en ander te configureren.

Dat moet je dus niet doen. Dat configureren kan je gewoon in je pkgNG-package integreren. Dat is volgens mij iets wat niet echt bij je binnenkomt .

Voorbeelden genoeg: VirtualBox had eerst geen VNC integratie in phpVirtualBox. Dus heeft ZFSguru een workaround/hack gemaakt om dat mogelijk te maken. En veel services hebben aangepaste config files. Dan kun je zowel de default config als de ZFSguru provided config gebruiken; beide heb je.

Packages:
- zfsguru-virtualbox
* Conflicteert met virtualbox
- zfsguru-phpvirtualbox
* Afhankelijk van zfsguru-virtualbox
* Conflicteert met phpvirtualbox

Nu kan dat, omdat ZFSguru services gewoon normale pkgNG-packages gebruiken.

Ik weet niet hoe ik je dit nu eindelijk eens duidelijk kan maken. Het zijn services met daarin pkgNG-packages. In stel dus de hele tijd voor om het helemaal een pkgNG-package te maken.

Begrijp me niet verkeerd: je hebt zeker wel goede punten gemaakt en iets in de richting van wat je voorstelt zal er ooit ook wel komen. Maar ik moet ook realistisch zijn en naar de haalbaarheid en prioriteit kijken. Zou je nu energie in een proof-of-concept steken, zal dat waarschijnlijk niet direct leiden tot een implementatie die ZFSguru op korte termijn gaat gebruiken. Dus dan vind ik het ietwat zonde.

Ik weet zeker dat jullie huidige systeem méér werk is dan wanneer je echte pkgNG-package maakt van die ZFSGuru services.

Ik zal eens proberen om jullie virtualbox package om te zetten naar een native pkgNG package.

---

Op een schone ZFSGuru installatie:

code:

[root@zfsguru /home/ssh]# pkg install zfsguru-virtualbox
Updating repository catalogue
digests.txz                         100%  308     0.3KB/s   0.3KB/s   00:00
packagesite.txz                     100%  788     0.8KB/s   0.8KB/s   00:00
Incremental update completed, 2 packages processed:
0 packages updated, 0 removed and 2 added.
The following 130 packages will be installed:

        Upgrading pcre: 8.33 -> 8.34 [FreeBSD]
        Installing libgpg-error: 1.12 [FreeBSD]
        Installing expat: 2.1.0 [FreeBSD]
        Installing gnome_subr: 1.0 [FreeBSD]
        Upgrading python27: 2.7.6_1 -> 2.7.6_4 [FreeBSD]
        Upgrading png: 1.5.17 -> 1.5.18 [FreeBSD]
        Reinstalling jpeg-8_4 [FreeBSD] (options changed)
        Installing virtualbox-ose-kmod: 4.3.10 [FreeBSD]
        Installing xproto: 7.0.25 [FreeBSD]
        Installing xineramaproto: 1.2.1 [FreeBSD]
        Installing xextproto: 7.2.1 [FreeBSD]
        Installing libXdmcp: 1.1.1 [FreeBSD]
        Installing libXau: 1.0.8 [FreeBSD]
        Installing libpthread-stubs: 0.3_4 [FreeBSD]
        Installing kbproto: 1.0.6 [FreeBSD]
        Installing renderproto: 0.11.1 [FreeBSD]
        Installing fixesproto: 5.0 [FreeBSD]
        Installing randrproto: 1.4.0 [FreeBSD]
        Installing inputproto: 2.3 [FreeBSD]
        Installing libICE: 1.0.8,1 [FreeBSD]
        Installing libfontenc: 1.1.2 [FreeBSD]
        Upgrading freetype2: 2.5.2 -> 2.5.3 [FreeBSD]
        Installing fontconfig: 2.11.0_1,1 [FreeBSD]
        Installing font-util: 1.3.0_1 [FreeBSD]
        Installing dejavu: 2.34_3 [FreeBSD]
        Installing fontcacheproto: 0.1.3 [FreeBSD]
        Installing hicolor-icon-theme: 0.12 [FreeBSD]
        Installing icu: 52.1 [FreeBSD]
        Installing perl5: 5.16.3_9 [FreeBSD]
        Installing libffi: 3.0.13_1 [FreeBSD]
        Installing libiconv: 1.14_3 [FreeBSD]
        Installing graphite2: 1.2.4 [FreeBSD]
        Installing pixman: 0.32.4 [FreeBSD]
        Installing cdrtools: 3.00_2 [FreeBSD]
        Installing ca_root_nss: 3.15.5 [FreeBSD]
        Installing xf86vidmodeproto: 2.3.1 [FreeBSD]
        Installing damageproto: 1.2.1 [FreeBSD]
        Installing dri2proto: 2.8 [FreeBSD]
        Installing pciids: 20140312 [FreeBSD]
        Installing compositeproto: 0.4.2 [FreeBSD]
        Installing gnomehier: 3.0 [FreeBSD]
        Installing jbigkit: 1.6 [FreeBSD]
        Installing jasper: 1.900.1_12 [FreeBSD]
        Installing curl: 7.36.0 [FreeBSD]
        Installing aalib: 1.4.r5_9 [FreeBSD]
        Installing videoproto: 2.3.2 [FreeBSD]
        Installing orc: 0.4.18 [FreeBSD]
        Installing qt4-doc: 4.8.5 [FreeBSD]
        Installing sqlite3: 3.8.4.1 [FreeBSD]
        Installing py27-setuptools27: 2.0.1 [FreeBSD]
        Upgrading php5: 5.4.23 -> 5.4.26 [FreeBSD]
        Installing php5-xml: 5.4.26 [FreeBSD]
        Installing php5-simplexml: 5.4.26 [FreeBSD]
        Installing php5-json: 5.4.26 [FreeBSD]
        Installing libgcrypt: 1.5.3_1 [FreeBSD]
        Installing vde2: 2.3.2 [FreeBSD]
        Installing libvncserver: 0.9.9_5 [FreeBSD]
        Installing libxcb: 1.9.3 [FreeBSD]
        Installing libX11: 1.6.2,1 [FreeBSD]
        Installing libXrender: 0.9.8 [FreeBSD]
        Installing libXfixes: 5.0.1 [FreeBSD]
        Installing libSM: 1.2.2,1 [FreeBSD]
        Installing libXt: 1.1.4,1 [FreeBSD]
        Installing mkfontscale: 1.1.1 [FreeBSD]
        Installing mkfontdir: 1.0.7 [FreeBSD]
        Installing font-misc-ethiopic: 1.0.3_1 [FreeBSD]
        Installing font-bh-ttf: 1.0.3_1 [FreeBSD]
        Installing encodings: 1.0.4_1,1 [FreeBSD]
        Installing glib: 2.36.3_2 [FreeBSD]
        Installing libXft: 2.3.1 [FreeBSD]
        Installing xcb-util: 0.3.9_1,1 [FreeBSD]
        Installing libXdamage: 1.1.4 [FreeBSD]
        Installing libpciaccess: 0.13.2 [FreeBSD]
        Installing shared-mime-info: 1.1 [FreeBSD]
        Installing atk: 2.8.0 [FreeBSD]
        Installing gobject-introspection: 1.36.0_2 [FreeBSD]
        Installing libIDL: 0.8.14_1 [FreeBSD]
        Installing dbus: 1.6.18 [FreeBSD]
        Upgrading php5-session: 5.4.23 -> 5.4.26 [FreeBSD]
        Installing php5-soap: 5.4.26 [FreeBSD]
        Installing libxslt: 1.1.28_1 [FreeBSD]
        Installing libXext: 1.3.2,1 [FreeBSD]
        Installing libXcursor: 1.1.14 [FreeBSD]
        Installing libXrandr: 1.4.2 [FreeBSD]
        Installing libXi: 1.7.2,1 [FreeBSD]
        Installing font-misc-meltho: 1.0.3_1 [FreeBSD]
        Installing libXmu: 1.1.2,1 [FreeBSD]
        Installing libXfontcache: 1.0.5 [FreeBSD]
        Installing xprop: 1.2.2 [FreeBSD]
        Installing qt4-corelib: 4.8.5_3 [FreeBSD]
        Installing xcb-util-renderutil: 0.3.8 [FreeBSD]
        Installing qt4-network: 4.8.5 [FreeBSD]
        Installing libXxf86vm: 1.1.3 [FreeBSD]
        Installing libdrm: 2.4.17_1 [FreeBSD]
        Installing libXcomposite: 0.4.4,1 [FreeBSD]
        Installing qt4-xml: 4.8.5 [FreeBSD]
        Installing qt4-xmlpatterns: 4.8.5 [FreeBSD]
        Installing qt4-script: 4.8.5 [FreeBSD]
        Installing qt4-sql: 4.8.5 [FreeBSD]
        Installing libXv: 1.0.10,1 [FreeBSD]
        Installing gstreamer: 0.10.36 [FreeBSD]
        Installing qt4-clucene: 4.8.5 [FreeBSD]
        Installing qt4-sqlite-plugin: 4.8.5 [FreeBSD]
        Installing phpvirtualbox: 4.3.1_1 [FreeBSD]
        Installing libXinerama: 1.1.3,1 [FreeBSD]
        Installing xorg-fonts-truetype: 7.7_1 [FreeBSD]
        Installing xset: 1.2.3_1 [FreeBSD]
        Installing cairo: 1.10.2_7,2 [FreeBSD]
        Installing libGL: 7.6.1_4 [FreeBSD]
        Installing libGLU: 9.0.0 [FreeBSD]
        Installing freeglut: 2.8.1 [FreeBSD]
        Installing sdl: 1.2.15_3,2 [FreeBSD]
        Installing gstreamer-plugins: 0.10.36_3,3 [FreeBSD]
        Installing zfsguru-phpvirtualbox: 4.3.1_1 [ZFSGuru]
        Installing xdg-utils: 1.0.2.20130919_1 [FreeBSD]
        Installing harfbuzz: 0.9.25_1 [FreeBSD]
        Installing tiff: 4.0.3 [FreeBSD]
        Installing qt4-gui: 4.8.5 [FreeBSD]
        Installing pango: 1.34.1_2 [FreeBSD]
        Installing qt4-opengl: 4.8.5 [FreeBSD]
        Installing gdk-pixbuf2: 2.28.2 [FreeBSD]
        Installing qt4-svg: 4.8.5 [FreeBSD]
        Installing qt4-help: 4.8.5 [FreeBSD]
        Installing gtk-update-icon-cache: 2.24.22 [FreeBSD]
        Installing qt4-declarative: 4.8.5 [FreeBSD]
        Installing qt4-webkit: 4.8.5_1 [FreeBSD]
        Installing qt4-assistant: 4.8.5_1 [FreeBSD]
        Installing qt4-linguist: 4.8.5_1 [FreeBSD]
        Installing virtualbox-ose: 4.3.10 [FreeBSD]
        Installing zfsguru-virtualbox: 4.3.8_1 [ZFSGuru]

The installation will require 822 MB more space

214 MB to be downloaded

Proceed with installing packages [y/N]:

[ Voor 63% gewijzigd door CurlyMo op 08-04-2014 23:38 ]

[CurlyMo]

Ik heb een proof-of-concept gemaakt met pilight. Dan zul je zien hoe ontzettend simpel het is om een pkgNG repo op te zetten. Het is zelfs makkelijker dan een apt repo

http://www.pilight.org/repository.tar.gz

This example shows how to easily create a FreeBSD pkgNG repository
You can savely run the example and install the pilight package,
because it will remove itself completely afterwards.

Server:
1. Run the './update.sh' script

Client:
1. Create a new file '/etc/pkg/pilight.conf' with the following content:
pilight: {
url: "pkg+http://x.x.x.x/pkgrepo",
mirror_type: "srv",
enabled: yes
}
2. Edit the url to match the url of your repository.
3. Run 'pkg install pilight' to install the pilight package
4. Run 'pkg remove pilight' to fully remove the pilight package
5. Run 'pkg autoremove' to also remove the dummy dependency to lzlib

code:

[root@zfsguru /home/ssh]# pkg install pilight
Updating repository catalogue
The following 2 packages will be installed:

        Installing lzlib: 1.5 [FreeBSD]
        Installing pilight: 3.0 [pilight]

The installation will require 1 MB more space

274 KB to be downloaded

Proceed with installing packages [y/N]:

Paar aanvullende opmerkingen:

1. Het gen.package.sh script gooit de +MANIFEST leeg vanaf de lijn:

code:

categories: utilities

Daarna genereert hij automatisch een lijst met folders en bestanden en berekent hij de sha checksums. Zorg dus dat je onder die regel niks meer neerzet.

2. De flatsize wordt automatisch door pkg create uitgerekend. Deze kan je dus gewoon op 0 laten.

3. Verander ook even de verschillende informatie bovenaan de +MANIFEST.

4. Vul het update.sh script aan met je eigen pakketten.

5. Het gen.package.sh script werkt op dit moment alleen met /etc en met /usr. Als je andere root mappen gebruikt dan moet je dat scriptje even aanvullen.

---

Als je interesse hebt, dan kan ik voor dit systeem wel een samba package maken waarin de recylce bin gewoon werkt. Op deze manier kan ook de community zeer makkelijk aanvullende pakketten bouwen.

[ Voor 43% gewijzigd door CurlyMo op 09-04-2014 12:39 ]

[FireDrunk]

CurlyMo, petje af, dit opent deuren naar het gebruiken van ZFSguru onderdelen (zoals de webinterface) op een non-ZFSguru installatie (wat ik persoonlijk erg fijn zou vinden).

Nu nog een logische scheiding tussen web interface, services en platform, en ik ben blij!

[ Voor 7% gewijzigd door FireDrunk op 09-04-2014 12:02 ]

[CurlyMo]

@FireDrunk, heb je het ook getest?

Ik hoop vooral dat het kwartje nu valt waarom de huidige services in zijn geheel te integreren zijn in een pkgNG pakket. Dat scheelt tevens een hele hoop bandbreedte. In de virtualbox service wordt nu ook voor een 25mb aan andere pakketten meegestuurd, terwijl die via de dependency structuur gewoon van de FreeBSD servers te downloaden zijn.

[FireDrunk]

Nee, ik draai momenteel Ubuntu, anders had ik het wel voor je willen testen

[CurlyMo]

VirtualBox

Ik ga niet op mijn NAS bak 100x pilight installeren en deïnstalleren

[FireDrunk]

In virtualbox zfsguru installeren, en daarna het package zfsguru-virtualbox installeren....


No sure if inception, or inception in inception

[CurlyMo]

, die optie heb je alleen niet omdat ik pilight als proof-of-concept heb gebruikt.

[tweedebas]

Die Migration Manager die er hier wordt beschrijven lijkt volgens mij exact op de FreeNas methode.

Schrijf een image naar een USB stick, boot deze op je server.
Nu draait FreeNas al op een read-only USB stick.

Dan maak je / importeer je volumes. Veranderd settings en of installeert plugins(de variant van services in ZFS-Guru) deze plugins worden fysiek op de volumes gezet, en draaien via een Jail.

Als je wilt dat deze settings en plugins na een reboot ook aanwezig moeten blijven zul je een bestand moeten bewaren op de volumes waar je wel op kan schrijven, of externe pc (download een bestand via de webgui). Dit is te regelen door ergens in de webgui op "save" te drukken.
De USB namelijk blijft Read-only gemount.
Bij een reboot zal ergens vanaf een volume het bestand worden ingelezen en de instellingen worden toegepast.

Bij een nieuwe versie FreeNas zet je de nieuwe image op de USB en kun je booten, vervolgens naar het bestand verwijzen/importeren wat dan ook. (Vanuit de webgui updaten is ook mogelijk)

Wat ze daar doen is dus eigenlijk bij elke boot de "migration package" importeren.

Als je wilt aanpassen buiten de web-gui om, zul je de usb rw moeten mounten en vervolgens aanpassen.
Bij een update via webgui of uiteraard nieuwe image op de usb schrijven worden die wijzigingen echter niet meegenomen.

Dus alles wat binnen de web-gui is in te stellen, installeren etc word rekening mee gehouden bij een boot, alles daarbuiten wordt keihard vergeten. (tenzij je rw op de usb hebt aangepast)

Dat is mijn inziens een keus die je moet maken bij omzeilen van de gebaande paden.

[ Voor 5% gewijzigd door tweedebas op 09-04-2014 13:38 . Reden: De tekst iets verduidelijkt, hoop ik ]

[Midas.e]

@CurlyMo, Dit is echt perfect, hiermee wordt Freebsd ook upgradable onder ZFSguru. Aangezien het eigelijk alleen maar packages zijn.

[CurlyMo]

Wat we toen met XBian hebben gedaan is een apart pakket maken dat heet xbian-update. De upgrade van XBian wordt geleid door dit pakket. Deze zegt dus welke pakketten niet geïnstalleerd mogen worden en welke juist wel. Het bepaalt welke versies van XBian pakketten een nieuwe XBian release maken en het pakket regelt het patches van standaard Raspbian bestanden.

[Dutch2007]

CurlyMo schreef op woensdag 09 april 2014 @ 15:19:
Wat we toen met XBian hebben gedaan is een apart pakket maken dat heet xbian-update. De upgrade van XBian wordt geleid door dit pakket. Deze zegt dus welke pakketten niet geïnstalleerd mogen worden en welke juist wel. Het bepaalt welke versies van XBian pakketten een nieuwe XBian release maken en het pakket regelt het patches van standaard Raspbian bestanden.

hulde

[CurlyMo]

Zo, de samba package is ook klaar (voor lokaal gebruik).

Voorbeeld van hoe pkgNG bestanden tracked en hoe je daarmee (ook) met conflicten kan werken:

code:

[root@zfsguru /home/ssh]# pkg install samba35
Updating repository catalogue
The following 1 packages will be installed:

        Installing samba35: 3.5.11 [ZFSGuru]

The installation will require 143 MB more space

0 B to be downloaded

Proceed with installing packages [y/N]: y
Checking integrity...pkg: WARNING: locally installed samba36-3.6.23 conflicts on /usr/local/bin/eventlogadm with:
        - samba35-3.5.11

pkg: WARNING: locally installed samba36-3.6.23 conflicts on /usr/local/bin/findsmb with:
        - samba35-3.5.11

Ik moet dus eerst samba36-3.6.23 verwijderen voordat ik mijn eigen versie kan installeren

[ Voor 87% gewijzigd door CurlyMo op 11-04-2014 20:54 ]

[CurlyMo]

Ondertussen begin ik wel nieuwsgierig te worden naar de reactie van CiPHER.