Glump: Glue files together

Glump is a small web util that allows gluing many files together into one. It is useful when you have a number of machines and you want to distribute a file to them (such as kickstart, firewall rules, etc), but send different bits to different machines. Using glump you can make a file from many pieces, and even specify per-host tuning parameters and replace in-file variables on the fly. Its name comes from the words "glue" and "lump" stuck together.

Setup

You can use Glump either as a CGI, or together with mod_python.

As CGI

You can either install the RPM, or just grab the glump.py, whichever you prefer. The only problem with copying glump.py around is version control. If you install it as RPM, you can then just use symlinks.

Locally:
Copy glump.py into your cgi-bin directory naming it whatever you want. Copy glump.conf into the same directory then edit it. The section name should be the same as the name of the file that glump.py has become. When the CGI is invoked, it will figure out which section to read depending on by which name it is executed. So, if you renamed the file "iptables", you will need to make the section [iptables]. If you leave it named "glump.py" it will look for section '__default__'.
Globally:
Install the RPM, then symlink from the cgi-bin directory to the main file in /usr/share/glump/glump.py, naming the local link whatever you want it to be. Edit /etc/glump/glump.conf, making the name of the section the same as the name of the symlink. NOTE: You will probably need to allow "FollowSymlinks" for the cgi-bin directory in httpd.conf

As Mod_Python

Install mod_python (apache-2.0 and mod_python-3.0 or above required). Then symlink /etc/glump/apache.conf into /etc/httpd/conf.d/glump.conf. Edit /etc/glump/glump.conf and add sections you want. Once that is done, glump should be all ready to roll: request the file as:
http://yourhost/glump?app=sectionname

Configuration

Look at the default glump.conf provided with the distribution. It should be well-commented with all possible options mentioned.

Variables and Tuning Parameters

Glump supports variables and tuning parameters, which can be useful to simplify things and make them more manageable. Here are several examples of usage:

In glue.xml
<glue> <globals> <var name="var1">var1 data</var> <var name="var2">var2 data</var> </globals> <bundle id="testbundle"> <vars> <var name="var3">var3 data</var> <if param="overridevar3" value="yes"> <var name="var3">var3 overridden in glue.xml using if-matching</var> </if> </vars> <member>file1</member> <ifnot param="addfile2" value="no"> <member>file2</member> </ifnot> </bundle> <bundle id="testbundle-novars" expandvars="no"> <member missingok="yes">file1</member> <member>file2</member> </bundle> </glue>
file1
var1: %(var1)s var2: %(var2)s
file2
var3: %(var3)s
hostmatch.cfg
host1 = testbundle host2 = testbundle; addfile2=no host3 = testbundle; overridevar3=yes host4 = testbundle; addfile2=no; var1=Overriden using hostmatch.cfg tuning host5 = testbundle-novars

Results of the above requests

host1 = testbundle

Host1 has no tuning parameters, so the bundle will be formed the following way: get file1, substituting all vars in it, then, since there is no addfile2 parameter, add file2 and substitute all vars in it as well. The output for host1 will be:

var1: var1 data var2: var2 data var3: var3 data
host2 = testbundle; addfile2=no

Host2 has addfile2=no specified in its tuning parameters, so when it gets to the <ifnot> part, it will match and file2 will not be included at all. The output for host2 will be:

var1: var1 data var2: var2 data
host3 = testbundle; overridevar3=yes

Host3 has "overridevar3=yes" specified, so during variable assignation, var3 will be overridden with that specific data since it will match the <if> condition. The output will be:

var1: var1 data var2: var2 data var3: var3 overridden in glue.xml using if-matching
host4 = testbundle; addfile2=no; var1=Overridden using hostmatch.cfg tuning

Tuning parameters can also override variables, so you need to be careful and make sure they don't clash. The output for the request from host4 would be:

var1: Overridden using hostmatch.cfg tuning var2: var2 data
host5 = testbundle-novars

This bundle has expandvars="no" set, so all variables and tuning parameters will be ignored. The output for host5 will be as follows:

var1: %(var1)s var2: %(var2)s var3: %(var3)s

Variable names in files

By default variable expansion is turned on, so any source files you are using will need to watch out for %-signs, since in python they signify the beginning of a variable name. To avoid the problem, make sure all %-signs that aren't specifying the name of a variable to expand are doubled: %%. Alternatively, you can turn off variable expansion either by specifying <bundle expandvars="no"> or by setting expandvars = off in /etc/glump/glump.conf for the section for which you want this behavior off.

Variable names in <member> tags

By default the strings %hostname% and %bundleid% inside a <member> tag will be expanded out to their equivalents for that execution of glump.

Missing files in <member> tags

By default glump will abort execution if it cannot find one of the files you have included in a <member> tag. If you include: missingok="yes" as a tag property then it will continue without an error or warning.

Example:

<member>some/file</member> <member missingok="yes">some/other/file</member>

Test Runs

You can do test runs using the CGI as the command-line application. This makes error reporting much easier and more visible, plus you can fake hosts. Example:
./glump.py -c glump-test.conf --app yumconf --host login.host.com

CONFUSED?

I have working examples:

The CGI actually operates on files in the "examples" directory, so feel free to browse it to see how things are laid out and configured. The "yumconf" setup is very simple -- it just glues several files together without doing any wild stuff with variables. The "kscfg" stuff is more advanced -- it shows how you can add or remove sections and modify contents based on what host is doing the request. The "kscfg" is actually a part of the setup we use in Physics.

Maintainer

Glump is part of Linux@DUKE mini-projects and is currently maintained by Seth Vidal. For support please email the DULUG mailing list. Glump was originally written by Konstantin Ryabitsev.

License and Copyright

This software is copyright © 2006 by Duke University. It is available to you under the terms of GNU GPL version 2 or above.

Download

Latest release information:

Name        : glump                        Relocations: (not relocatable)
Version     : 0.9.11                            Vendor: (none)
Release     : 1                             Build Date: Sun Aug 27 13:44:25 2006
Install Date: (not installed)               Build Host: cutter
Group       : Applications/Internet         Source RPM: (none)
Size        : 20379                            License: GNU GPL
Signature   : (none)
Packager    : Seth Vidal <skvidal.[at].phy.duke.edu>
URL         : http://linux.duke.edu/projects/mini/glump
Summary     : A small web application to glue files from multiple sources
Description :
Glump is a simple web application that glues files from various pieces,
based on the hostname that makes the request. This is useful for large
installations that want to send different files to different hosts.