Skip to content

Implement first time setup mechanism for modules

Created by: SunilMohanAdapa

We should have a mechanism in Plinth where in modules can setup themselves for the first time.

Motivation:

  • Move a lot of freedombox-setup/firstrun.d stuff to Plinth #34 (closed).
  • Proper unified code for handling all the setup and configuration for each module.
  • Easier testing with Plinth compared to freedombox-setup.

The following are details on how it should work:

Basics:

  • Each module declares a setup() function that is called by the module manager when the module is enabled.
  • The setup() function has be to idempotent so that calling it multiple times does not lead to errors. Installing required packages, first time configuration setup and enabling operations should happen here.
  • The key/value model shall be used to store the state of whether a module has been enabled.
  • Each module also implements a disable()

Plinth setup operation:

  • During installation of Plinth, plinth --setup will be executed. During this setup, all the modules which are essential (for FreedomBox operations such as DNS, DHCP, firewall) will be automatically setup().
  • Each module can suggest if it is an essential module.
  • All optional modules such as ownCloud and XMPP wait until Plinth first run to be setup.

Plinth first run:

  • During Plinth's first run wizard, all modules which are not yet enabled (optional modules) will be displayed as a list and user can select which ones to enable.
  • When the first run wizard is executed, each selected module's setup() will be called.

Version management: for smooth upgrades

  • Each module will declare a version number.
  • Version number for which setup() has been executed will be stored in key/value model.
  • When Plinth starts, if it finds that the enabled version number is lower than the current code version, it calls setup() again.
  • setup() will have arguments telling what the previously enabled version number.