The fastest way to setup virtual machines for a mysql server for elexis and an Elexis client accessible via x2go
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
veewee @ 266627e


Bootstrapping an Elexis development and testing environment made easy!

Bootstrapping and testing Elexis took me (Niklaus) many hours when I started working on Elexis.
Therefore I was always looking for clever shortcuts to create a simple, reproducible build environment.
With this project I am coming much closer!

Preparing the 0.1 release took me a few days of work and confronted me (again) with all the small, pesky details I had to overcome to run my Jenkins CI under The readme is found as readme.v1.textile.

With version 0.2 is a complete rewrite using the facilities offered by Puppet 3.0. Also it is already much closer to my ideas from the Elexis-Admin project.

Useage, questions, examples are beeing maintained in the Wiki

What you can do with your fancy new virtual machine(s)

By default I only actived the node “devel” in the Vagrantfile in the variable systemsToBoot. Therefore a vagrant up will just bring up a single machine where developers. In the Vagrantfile you find also a number of ports which you can use to access the different services offered by the virtual machine.

  • Login via as user vagrant with password vagrant. The vagrant user has (via sudo) all rights.
  • Several users (you must the password first via sudo passwd myUser). E.g.
    bq. grep rgw /etc/passwd
    rgw1201:1201:Without him there would be no Elexis. Thanks a lot!:/home/rgw:/bin/bash
  • KDE
  • Juno under /opt/eclipse/eclipse-rcp-juno-SR2/eclipse/ and the Debian Eclipse-RCP via /usr/bin/eclipse
  • Jubula /opt/jubula_6.0.01011
  • elexis-bootstrap under /home/elexis/elexis-bootstrap
  • jenkins (no jobs defined)
  • Latex to build all *.tex files
  • The Opensource Elexis under /opt/elexis_opensource/2.1.7.rc2
  • The Medelexis variant under /opt/elexis/current
  • A mysql-server accessible via mysql -u elexis --password=elexisTest. Also accessible via network.
  • A postgresql-server psql -U elexis --password -h localhost
  • Both database servers have two empty databases elexis and test to play with.
  • If you know how to patch hieradata/common.yaml you may customize sending e-mal via smtp.

Feature only for server/database and with correct configuration

  • Minimal support for the elexis-cockpit
  • Daily backup of elexis database
  • X2go-server

The virtual machines are all connect to the local network via a bridge interface. Therefore a VM node server can be seen by all other machines around to test Elexis even easier.

Howto improve/extend the existing puppet receipes

From Best Practices

The classes, defined types, and plugins in a module should all be related, and the module should aim to be as self-contained as possible.

I also created for each (mini-) feature a file .pp in the tests folders of the module. This allows me to test/debug a feature like this.

cd /path/to/checkout @sudo puppet apply --confdir . modules/x2go/tests/client.pp --debug

puppet testing on the development

Test the module java on a machine where you have a working copy of this project, just call (in your own development environemnt):
cd /path/to/checkout
vagrant provision

puppet testing on the target

cd /path/to/checkout
vagrant ssh
sudo puppet apply --modulepath /tmp/vagrant-puppet/modules-0 /tmp/vagrant-puppet/modules-0/java/tests/init.pp --debug

git howto

  • See Git-Tools
  • Common usage
  • If you make changes or add a new module, fork the original module into your github account, then
  • git submodule add<yourname>/puppet-x2go modules/x2go
  • To ease pushing to your personal github account use git remote add github
  • This enables you to use cd modules/x2go && git push github
  • To update all submodules call git submodule foreach git pull origin master

create a base box

See the readme.texile in the subfolder definitions. This was used to create the which can be downloaded

Adapt for a new client

To distinguish between the various scenarios we use puppet environemnts. The following environemnts are predefined here

  • empty # minimal build
  • demoDB # create an elexis OpenSource installation with a demo database for playing
  • developer # create a developer environment (eclipse-IDE, mysql, postgres DB-Servers)
  • mustermann # a typical scenario for a medical practice

The configuration of each of these scenarios is kept as a hiera yaml file named hieradata//.yaml. To made it usable for the production scenario I add usually a soft link from .yaml to production.yaml.

The mustermann scenarios has some additional configuration for its main server under hieradata/mustermann/

When I have a new client client a usually create a configuration directory (e.g. a git repository /opt/clients/musterfrau/configuration) and create a logical link to it as hieradata/mustefrau.
On each of the machines to provision of my client I will create a clone of the configuration and link hieradata/production to it.

Using such a scenario is done add —environement=scenario to the puppet command line argument.


Goals to be achieved before declaring feature completeness

  • Integrate changes/suggestion to make the project interesting for more developpers (let it fullfill theirs and my requirements). I started with my requirements but I will happy to help others to try to find a solution which works fine for everybody!

Coming soon (aka prototypes exist and worked almost):

  • Backups/Restore Database from server/backup
  • Installation of Beta release
  • install elexis versions correctly, via apt or Elexis-installer (resolved for Linux, missing for Samba/Windows-Clients)
  • Postgres Online Backup
  • Add LibreOffice to test elexis text plugins
  • Setup mail-delivery/archiving
  • Daily backup onto an encrypted external hard disk
  • netboot

Probably for Release 0.3

  • Add support for Elexis client testing under MacOSX
  • Support 32-bit and 64-bit Jubula GUI-tests in the Jenkins
  • Minimal setup for a medical practice (DB & backup)
  • include to for a simple way configure the system

To be determined

  • Full support PostgresSQL
  • Investigate, decide/document how different developpers/OC may refine/add files/requirements
  • Adapt KDE to match some preferences (e.g. keyboard layout, tabs for the konsole application)
  • Support several javas (e.g. Sun-Java-6, OpenJDK-6, OpenJDK-7)
  • backup and anonymiser scripts/setup for MySQL/PostgresSQL, e.g.
  • os/db-user elexis (dito Arztx, MPAx,oc)
  • Deutsch als Vorgabesprache (veewee with elexisBaseBox passes validation, but cannot be used)
  • Merge project with elexis-admin
  • Have at least 2 additional developpers using at least a part of the puppet stuff
  • Have at least 5 beta installation in medical practices
  • Specify specific version of jenkins and its plugins

Move stuff to docker containers

The following services should be moved to docker containers

  • elexis-cockpit
  • mysql/postgresql server
  • wiki

Feature that might be in 1.0 or later

  • Add support for Elexis client testing under Windows (Puppet has only initial support for windows)


  • Release 0.2: April 25, 2013. Support server and backup (still some features mixing). Compiling the elexis-bootstrap project with Elexis 2.1.7
  • Release 0.1: July 15, 2012. Runs Jubula integration tests with Elexis 2.1.6 on a Debian Squeeze 32-bit machine

Ideas/comments are welcome. Use the elexis-develop mailing list or contact the author directly via