Add a Service to School Server by Creating a Plugin

Overview

The XSCE school server is an attempt to break apart a build process centered on image generation using punji, and anaconda fedora build tools. In the new approach, the school server starts out as a minimal Fedora Core installation, and uses yum to add in functions and their dependencies.  The effort is to maximize flexibility and foster collective effort by facilitating the addition of services on an incremental basis, rather than having to start from scratch with each new feature, distribution release, architecture.

How to Create a Plugin

All of the files related to a service must be collected in a single folder, and placed as a subdirectory of the plugins.d folder. A Plugin folder  must have the following structure which includes two folders and three files (the “Makefile” is automatically generated):

[ghunt@george 13] plugins.d > tree -L 2 vnc
vnc
├── [ghunt 4096] files/
├── [ghunt 815] Makefile
├── [ghunt 61] vnc.manifest
├── [ghunt 3037] vnc.sh
└── [ghunt 4096] yum/
    ├── [ghunt 0] mod_ssl
    ├── [ghunt 0] nmap  
    ├── [ghunt 0] novnc
    ├── [ghunt 0] python-setuptools
    └── [ghunt 0] tigervnc-server

The yum/ directdory is pulled out separately so that during the install process, the list of packages can be installed all at once, either from online repos, or from local cache.

The two files that you need to generate with a text editor need to start with the name of your plugin and will be terminated with a “.manifest” or “.sh”. The “.sh” file will be executed by bash whenever the service is enabled or disabled.
There is some flexibility in the use of the “.manifest” file. At one extreme, it can list the full path to the root for each file in the “files” directory (See example 1). At the other extreme, it can be empty, and you can build a tree of folders from root to the place where they will be placed in the final target machine. Example 1 below.

EXAMPLE 1

[ghunt@george 13] vnc > cat vnc.manifest
/usr/share/xs-config/cfg/etc/httpd/conf.d/novnc.conf
/usr/share/xs-config/cfg/etc/sysconfig/vnc/self.pem
/usr/share/xs-config/cfg/etc/sysconfig/vnc/xfce4-panel.xml
/usr/share/xs-config/cfg/etc/sysconfig/vnc/xstartup
/usr/share/xs-config/cfg/etc/systemd/system/vncserver@.service
/usr/share/xs-config/cfg/etc/systemd/system/vncserverweb.service
/usr/share/xs-config/cfg/html/top/es/vnc_auto.html
/usr/share/xs-config/cfg/html/top/vnc
/usr/share/xs-config/cfg/html/top/vnc.js

And the files are all in the “files” folder, with no additional folders:

[ghunt@george 13] vnc > tree files
├── [ghunt 109] novnc.conf
├── [ghunt 3087] self.pem
├── [ghunt 503] tree.old
├── [ghunt 5191] vnc_auto.html
├── [ghunt 1346] vnc.js
├── [ghunt 1722] vncserver@.service
├── [ghunt 328] vncserverweb.service
├── [ghunt 3218] xfce4-panel.xml
└── [ghunt 432] xstartup

EXAMPLE 2

[ghunt@george 13] vnc > cat vnc.manifest
/usr/share/xs-config/cfg/etc/
/usr/share/xs-config/cfg/html/

In this instance the manifest creates a link between the tree structure in the files directory and the root (“/”).

[ghunt@george 13] vnc > tree files
files
├── [ghunt 4096] etc
│   ├── [ghunt 4096] httpd
│   │   └── [ghunt 4096] conf.d
│   │   └── [ghunt 109] novnc.conf
│   ├── [ghunt 4096] sysconfig
│   │   └── [ghunt 4096] vnc
│   │   ├── [ghunt 3087] self.pem
│   │   ├── [ghunt 3218] xfce4-panel.xml
│   │   └── [ghunt 432] xstartup
│   └── [ghunt 4096] systemd
│   └── [ghunt 4096] system
│   ├── [ghunt 1722] vncserver@.service
│   └── [ghunt 328] vncserverweb.service
└── [ghunt 4096] html
    └── [ghunt 4096] top
        ├── [ghunt 4096] en
. . .
. . .

By comparison, old structure of xs-config was as follows:

  • scripts/ — OLPC written scripts to do configuration
  • altfiles/ — config files of other packages which OLPC needs to change, but providing a clue that they are changed by changing the name to configfile.in and then copying
  • cfg/ — any files that can just be droppen in place

All of the scripts for all the the services are mingled together, and files related to a single service may be buried within the three separate trees.

Making the Makefile

The install section of the Makefile places all of the files in the package in   a very sparse tree, which mimics the standard linux tree. Generation of this Makefile is error prone, and tedious. The “./xsc_tools mkmake all” function automates this task.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s