Hello, Lately I've been thinking of ways to improve the chroot creation process for LTSP fat clients. The standard ltsp-build-client uses a set of plugins that are shell scripts and those are run when the image is generated. For example the --fat-client option just installs ubuntu-desktop or other meta-desktop package. More complicated setups require writing a plugin script or tweaking the chroot manually after generation.
We've been now using Puppet to do the tricky parts when packages require configuration changes after being installed. Puppet is a configuration management tool that ensures that the machine in question has the specified packages and configurations in place. Of course one could also use CFEngine/Chef/something else instead of Puppet. [http://docs.puppetlabs.com/learning/] E.g. one could create a firefox module that installs firefox and firefox extensions and does system-wide configuration for them. Having repeatable recipes for tasks would make it also possible to share desktop setups between LTSP users. chroot updating would also get easier as one could always just recreate the image with all the customisations in the Puppet rules. Also normal desktop machines can be installed with the same rules. Puppet configuration could be an optional plugin for ltsp-server's ltsp-build-client so that one can create desktop configuration that gets configured automatically on top of generated chroot. There would be no need to do customisations on the chroot after chroot creation making the process repeatable. Also sharing chroot customisations and desktop settings would be easier among LTSP users. How do you feel about this? Is someone using something like this for chroot generation? Here's an example how it would work e.g. on Ubuntu: /usr/share/ltsp/plugins/ltsp-build-client/Ubuntu/plugins/045-puppet: ------------------------------------------------------------------------------ case "$MODE" in commandline) add_option "puppet-sources-dir" \ "`eval_gettext "a directory of puppet sources"`" "advanced" "true" add_option "puppet-use-classes" \ "`eval_gettext "a comma-separated list of puppet classes to use"`" \ "advanced" "true" ;; configure) if [ -n "$option_puppet_sources_dir_value" ]; then PUPPET_SOURCES_DIR=$option_puppet_sources_dir_value fi if [ -n "$option_puppet_use_classes_value" ]; then PUPPET_USE_CLASSES=$(echo $option_puppet_use_classes_value \ | tr ',' ' ') fi if [ -n "$PUPPET_SOURCES_DIR" -a -n "$PUPPET_USE_CLASSES" ]; then # we need a puppet interpreter to use puppet classes LATE_PACKAGES="$LATE_PACKAGES puppet-common" fi ;; finalization) if [ -n "$PUPPET_SOURCES_DIR" -a -n "$PUPPET_USE_CLASSES" ]; then cp -a $PUPPET_SOURCES_DIR $ROOT/etc/puppet/ltsp-build-client # should also use --detailed-exitcodes and behave accordingly chroot $ROOT puppet apply \ --modulepath=/etc/puppet/ltsp-build-client \ --execute "include $(echo $PUPPET_USE_CLASSES | tr ' ' ',')" fi ;; esac ------------------------------------------------------------------------------ Under the specified puppet directory one can create normal puppet modules that get included based on the classes defined on the command line, e.g.: ------------------------------------------------------------------------------ class testmod { package { [ 'chromium-browser', 'gnome-session-fallback', ]: ensure => present; } file { '/etc/testfile_from_testmod': content => "This is host $hostname", ensure => present; } } ------------------------------------------------------------------------------ If one now runs ltsp-build-client with new options --puppet-sources-dir=puppet --puppet-use-classes=testmod, Puppet should show something like this: notice: /Stage[main]/Testmod/Package[gnome-session-fallback|gnome-session-fallback]/ensure: ensure changed 'purged' to 'present' notice: /Stage[main]/Testmod/File[]/content: content changed '{md5}d41d8cd98f00b204e9800998ecf8427e' to '{md5}c0ec52b3f9db1099c6f64d86e3c50e4d' notice: /Stage[main]/Testmod/Package[chromium-browser|chromium-browser]/ensure: ensure changed 'purged' to 'present' notice: Finished catalog run in 129.50 seconds This makes it quite easy to see what gets changed and also sharing desktop setups should be easier. I hacked together a quick version of ltsp-chroot to do the same when a chroot exists already. No need to recreate the whole chroot to test new rules: https://gist.github.com/4002703 You can run it like this: sudo ltsp-chroot -m -b /opt/ltsp -a i386 --puppet-use-classes=testmod --puppet-sources-dir=puppet While thinking of this I wrote down some plusses and minuses vs. using shell scripts. Pros: * Templating system * Extensible - e.g. inheritance, modules * Settings are testable without running the whole chroot creation process from beginning everytime * Static error checking, two conflicting rules cause an error instead of depending on running order * Existing Puppet rules around the internets can be reused * Logging Cons: * Sometimes Puppet syntax use can be cumbersome and additional scripts may be needed * Learning curve needed to learn Puppet in top of shell scripting * Is Puppet available in all distributions using LTSP? Any ideas? Happy hacking! Veli-Matti ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
