1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
This file presents a set of simple guidelines on integrating your external
Apache HTTPD modules into the infrastructure provided by the Debian packages.
It does not cover how to build or package modules.
External modules are stored in /usr/lib/apache/1.3/, this is consistent
with the layout utilised by the Debian packages.
Looking at this directory you will notice that it contains 2 kinds of files:
- mod_x.so (the module itself).
- 500x.info (information about the module. This is required solely by the
Debian apache packages).
The .so will be generated by compiling the module (and we recommend that apxs
is used for this task).
The .info file has to be created and installed by the maintainer of
the module. Information is drawn from the name of the info file, as well as
the contents of the file.
Eg:
500mod_x.info
500 is the "priority" of the module.
If for example your module needs to be loaded before another one,
you will have to set this number to be lower than the other
module. Eg: mod_foo must be loaded before mod_bar to work
properly and mod_bar has a priority of 110. mod_foo must have
a priority of 109 or lower to be loaded correctly.
In case 2 or more modules have the same priority, alphabetic order
is considered to determine the load order (with LC_COLLATE=C).
mod_x is the name of the module that will appear to the users when
invoking apache-modconf.
The contents of the .info file have a partially dynamic layout. The only
currently required line is the first one and it has to contain the
LoadModule directive for apache.
Eg 500mod_x.info should contain:
LoadModule x_module /usr/lib/apache/1.3/mod_x.so
Please note that some info files add a ":" after LoadModule
- this is not mandatory.
We recommend that you also add a Description: entry.
You can check the actual .info files for some examples, but note that
most of them still have old entries that apache does not use anymore
(such as Directives: or Handlers:) and you can safely ignore them.
It is possible to use apache-modconf in maintainer scripts to enable/disable
a specific module. An example of the code required to do this would be:
if [ -x /usr/sbin/apache-modconf ]; then
for i in apache apache-perl apache-ssl; do
if [ -e /etc/$i/httpd.conf ]; then
apache-modconf $i enable mod_x
fi
done
fi
in postinst and:
if [ -x /usr/sbin/apache-modconf ]; then
for i in apache apache-perl apache-ssl; do
if [ -e /etc/$i/httpd.conf ]; then
apache-modconf $i disable mod_x quiet
fi
done
fi
in prerm.
It is important to note that apache-modconf uses debconf. If your maintainer
scripts also utilise debconf then you need to thoroughly test that the two
scripts work together properly.
It is known that calling db_stop before apache-modconf can cause problems in
different situations. If you must do that please triple check that everything
will work as expected.
In order to be installed properly each module must depend on apache-common.
If your module is incompatible with one of the flavours, please let us know
and we will "blacklist" the module for the specific case.
|
