Show Advanced KnowledgeHide Advanced Knowledge

Concept: Setup Revision

This page is only here for documentation, the content is outdated and the general idea is followed up within the (Project) CLI-Setup.

1 Initial Problem

Introduction
The ILIAS setup is the main entry point for every new ILIAS installation. The current setup implementation provides basic requirement-checks and leads through the process of the installation. Many of the features and configurations in the setup have been implemented over a long period of time and there was little effort underdtaken for refacoring  of the code base.  
The Technical Board of the ILIAS e-Learning e.V. (TB) focusses on the sustainability and stability of the whole software. As the setup has no explicit maintainer the TB calls for bids for a setup revision concept among the ILIAS community.

Project Goals
The goal is to analyse the current setup procedure and implementation and to create a thorough specification for refactoring the setup. The setup should at least contain the functionality already provided and has some additional MUST and SHOULD criterias that have to be described in the specification as well.

Requirements
Project specific requirements

• There will be two workshops with the ILIAS community lead by the contractor. Each of these workshops should last at least 2 hours.
• A thorough specification needs to be written containing all must criteria and should criteria given below. The specification also contains technical details about the software architecture. All changes in the GUI are documented with mockups. Based on the specification any contractor should be able to implement the features and the underlying architecture. The specification also contains cost estimates for all must criterias. Additionally any should criteria has its own independent cost estimate.
• Communication is needed with the different service providers as you need to specify what part of the implementation has to be done by a specific maintainer and what part can be done by a generic contractor.

The specification for a setup-revision must address the following MUST-topics:

• The supported feature set of the setup must remain.
• The complete setup including the installation, the DB installation, the DB Upgrades (inkl. Hotfixes), the installation of language files, global cache configurations, etc. Must be available in a setup GUI similar to the already existing GUI and must be available as a command line interface.
• The command line interface must be reusable for other services in ILIAS.
• An interface and an extensible process must be defined for mandatory and optional infrastructure requirements. E.g. Read access on the ILIAS data folder is mandatory, Memcache must be installed for global cache is optional.
• An interface and an extensible process must be defined for setup steps. Each setup-step should be able to provide form elements for configuration purposes/save the settings. It should have an internal state (fullfilled or not) which should be an indicator to determine if a subsequent step can be accessed or not.
• An interface must be defined for core-modules to provide forms and configuration in the setup-workflow. It must be possible for core modules to register to the setup similarly to the current global cache configuration.
• The specfication describes a way for general release information and information for certain database update steps. There must be an abstraction of a database update step, providing methods for executing the update step, getting information for interruptive maintainer notes (if necessary) etc. This should also replace the approach of "echo/exit" in update steps (often done in migration steps).
• The specification of the implementation must be based on namespacing. All existing class name collisions must be resolved.
• The specification describes the steps that are taken to no longer use md5 for the setup login.

The concept for a setup-revision must address the following SHOULD-topics:

• The specification describes a token based auth mechanism for the cron job interface. Using cronjobs with the root user should no longer require the root user’s password.
• The setup must only use UI-Service-Elements except tables and forms. Any setup-specific UI-Element not yet available has to be specified as a new UI-Service-Element.

Acceptance Criteria

• Every must- and should- criteria is thoroughly described in the specification, including features and technical details.
• There is a description of every third party library used.
• All UI-Service elements needed are described. New UI-Services are specified.
• There must be a cost estimate for the must criteria as a bundle.
• There must be a cost estimate for every single should criteria.
• There is a description of what part of the implementaiton requires a certain maintainer and what part can be implemented by any contractor.
• There is a timeline for the implementation. The goal is a release in ILIAS 5.3.

2 Conceptual Summary

{Please add a brief summary on how you would like the problem to be solved.}

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: {Please add your name.}
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• ...

7 Discussion

I highly appreciate this idea!

I suggest to collect problems from "first-time installers" and read the forums carefully to get better knowledge about the hitches in the setup process and certain setup steps. The first things that come to my mind
- false cookie error in the first step
- db installation should be splited so the "max_execution_time" does not have to be set to an incredible high value during the setup
- use smart values (e.g. why do I need to klick on "try to evaulate the tools path automaticaly". Of course I want that!)
- which function does belong to the setup, which to the administration? E.g. search and chat server.

"An interface and an extensible process must be defined for setup steps. Each setup-step should be able to provide form elements for configuration purposes/save the settings. It should have an internal state (fullfilled or not) which should be an indicator to determine if a subsequent step can be accessed or not." 
Does that mean, that there should be a "save button" on every setup step? This is,in my opinion, one of the hitches that should be removed.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.