summaryrefslogtreecommitdiffstats
path: root/proto/PACKAGE_README.html
blob: 2350f5f1f92676f745aaaae9413c9ea22246eacd (plain)
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>Guidelines for Package Builders</title>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>

</head>

<body>

<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Guidelines for Package Builders</h1>

<hr>

<h2>Purpose of this document</h2>

<p> This document has hints and tips for those who manage their
own Postfix binary distribution for internal use, and for those who
maintain Postfix binary distributions for general use.  </p>

<h2>General distributions: please provide a small default main.cf
file</h2>

<p> The installed main.cf file must be small. PLEASE resist the
temptation to list all parameters in the main.cf file.  Postfix
is supposed to be easy to configure. Listing all parameters in main.cf
defeats the purpose. It is an invitation for hobbyists to make
random changes without understanding what they do, and gets them
into endless trouble.  </p>

<h2>General distributions: please include README or HTML files</h2>

<p> Please provide the applicable README or HTML files. They are
referenced by the Postfix manual pages and by other files.  Without
README or HTML files, Postfix will be difficult if not impossible
to configure. </p>

<h2>Postfix Installation parameters</h2>

<p> Postfix installation is controlled by a dozen installation
parameters.  See the postfix-install and post-install files for
details.  Most parameters have system-dependent default settings
that are configurable at compile time, as described in the INSTALL
file. </p>

<h2>Preparing a pre-built package for distribution to other
systems</h2>

<p> You can build a Postfix package on a machine that does not have
Postfix installed on it. All you need is Postfix source code and
a compilation environment that is compatible with the target system.
</p>

<p> You can build a pre-built Postfix package as an unprivileged
user. </p>

<p> First compile Postfix. After successful compilation, execute:
</p>

<blockquote> <pre> % <b>make package</b> </pre>
</blockquote>

<p> With Postfix versions before 2.2 you must invoke the post-install
script directly (<tt>% <b>sh post-install</b></tt>). </p>

<p> You will be prompted for installation parameters.  Specify an
install_root directory other than /.  The mail_owner and setgid_group
installation parameter settings will be recorded in the main.cf
file, but they won't take effect until the package is unpacked and
installed on the destination machine. </p>

<p> If you want to fully automate this process, specify all the
non-default installation parameters on the command line: </p>

<blockquote> 
<pre> % <b>make non-interactive-package install_root=/some/where</b>...  
</pre> </blockquote>

<p> With Postfix versions before 2.2 you must invoke the post-install
script directly (<tt>% <b>sh post-install -non-interactive
install_root...</b></tt>). </p>

<p> With Postfix 3.0 and later, the command "make package name=value
..." will replace the string MAIL_VERSION in a configuration parameter
value with the Postfix release version. Do not try to specify
something like $mail_version on this command line. This produces
inconsistent results with different versions of the make(1) command.
</p>

<h2>Begin Security Alert</h2>

<p> <b> When building an archive for distribution, be sure to
archive only files and symbolic links, not their parent directories.
Otherwise, unpacking a pre-built Postfix package may mess up
permission and/or ownership of system directories such as / /etc
/usr /usr/bin /var /var/spool and so on. This is especially an
issue if you executed postfix-install (see above) as an unprivileged
user. </b> </p>

<h2>End Security Alert</h2>

<p> Thus, to tar up the pre-built package, take the following steps:
</p>

<blockquote> <pre>
% cd INSTALL_ROOT
% rm -f SOMEWHERE/outputfile
% find . \! -type d -print | xargs tar rf SOMEWHERE/outputfile
% gzip SOMEWHERE/outputfile </pre> </blockquote>

<p>This way you will not include any directories that might cause
trouble upon extraction. </p>

<h2>Installing a pre-built Postfix package</h2>

<ul>

<li> <p> To unpack a pre-built Postfix package, execute the equivalent
of: </p>

<pre>
# umask 022
# gzip -d &lt;outputfile.tar.gz | (cd / ; tar xvpf -) </pre>

<p> The umask command is necessary for getting the correct permissions
on non-Postfix directories that need to be created in the process.
</p>

<li> <p> Create the necessary mail_owner account and setgid_group
group for exclusive use by Postfix. </p>

<li> <p> Execute the postfix command to set ownership and permission
of Postfix files and directories, and to update Postfix configuration
files. If necessary, specify any non-default settings for mail_owner
or setgid_group on the postfix command line: </p>

<pre>
# postfix set-permissions upgrade-configuration \
       setgid_group=xxx mail_owner=yyy
</pre>

<p> With Postfix versions before 2.1 you achieve the same result
by invoking the post-install script directly. </p>

</ul>

</body>

</html>