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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
<!doctype linuxdoc system>
<article>
<title>Apache Web Server
<abstract>
This is the main configuration menu for the WWW-server
Apache. Apache provides many configuration options and is
extendable with third-party modules. As a result
<em/Linuxconf/ can only control some of Apache's
functionality -- the most important parts.
In this window, you control the server-wide configuration. You can also
set default values, which can be overridden, for specific parts of the
Web server contents.
</abstract>
<sect>Administrator email
<p>
This address will be included in error messages to Web clients
(browsers), for example, when pages can't be found. This email address
is usually webmaster@domain.
<sect>Domain IP address
<p>
If you want to let several virtual domains share a single IP address, you
must enter that address here.
<sect>Server name
<p>
The name of the Web server. If name resolving works (using DNS or
<TT>/etc/hosts</TT>) you should not have to enter anything here.
However, if Apache is unable to determine the hostname at startup, or if
the hostname is not the same as the official name of the Web server, you
need to provide it yourself.
<sect>Server aliases
<p>
Alias names for the Web server. Names <em/must not/ be provided
here in the main configuration; this is only for virtual domains.
<sect>Document root
<p>
The directory (in the real filesystem) from which your Web server will
be serving most of its Web pages.
For example: If you set the document root to
<tt>/home/httpd/html</tt>, then accesses to
<tt>http://your.webserver.com/index.html</tt> would return the file
<tt>/home/httpd/html/index.html</tt>. An access to
<tt>http://your.webserver.com/foo/gazonk.gif</tt> would
return <tt>/home/httpd/html/foo/gazonk.gif</tt>.
<sect>Error log
<p>
The path to the log file for error messages. Usually, it is
<tt>logs/error_log</tt>, which is relative to the ServerRoot. Often the
directory <TT>logs</TT> in ServerRoot is a symbolic link to
<tt>/var/log/httpd</tt>. Then the log path above would result in error
messages being logged to <tt>/var/log/httpd/error_log</tt>.
You should monitor this log after reconfiguring, since most
configuration errors are logged here (Linuxconf, sadly, catches
only a few of them.) Additionally, any failed accesses by
clients (non-existent pages, failed authorization and so on)
are also logged here.
<sect>Transfer log
<p>
All accesses to the Web server will be logged in this file. Usually, it
is <tt>logs/access_log</tt>. Every access is logged on a single line in
the Common Log Format (most Web logfile analyzers understand this format).
<sect>Agent log
<p>
The browsers used to access the Web server are logged in this
file.
<sect>Referer log
<p>
If an access was the result of a user following a link from
some page to the accessed page, then the other, referring
page is logged in this file.
<sect>Script Alias
<p>
Provides the location for CGI programs. This should be two paths,
separated by whitespace. The first path is the path used in URL that
triggers execution of a CGI program; the second path is where those CGI
programs are stored in the real filesystem.
For example, if the script alias is <tt>/cgi-bin/home/httpd/cgi</tt>
then a request for
<tt>http://your.webserver.com/cgi-bin/feedback.py</tt> would execute and
return the output of <tt>/home/httpd/cgi/feedback.py</tt>.
<sect>User
<p>
The user the web server should run as. This means that the Web server
can only read and write those files which that a user has rights to read
or write, respectively. Therefore, this should be set to a user with
very low privileges, for example, nobody.
An even better idea is to create a user specifically for the Web server.
This is very important, if you want to let the Web server write files in
some directory, since the user "nobody" should not have privileges to
write files anywhere except in <tt>/tmp</tt>.
<sect>Group
<p>
The group the Web server should run as. See the discussion
of User above, but apply it to groups instead of users.
<sect>Tuning
<p>
<sect1>Listen on port
<p>
The TCP port on which the Web server should listen for HTTP requests.
The standard port for HTTP is 80, so if you use another port you need to
include it in the URL. For example, if you let your Web server listen
on port 8000, then the URL to your server would be
<tt>http://your.webserver.com:8000/</tt>.
<sect1>Pid file
<p>
The Web server stores the PID of its main process in this file. You
will probably not need to modify this.
<sect1>Time out
<p>
How many seconds the Web server will wait for a request to be sent after
a client has connected to the server. If a client connects but doesn't
send any request, it will be disconnected after this amount of time.
<sect1>Host name lookups
<p>
Whether the Web server should attempt to find out the host
names of connecting clients. If this is disabled, only the IP
address of the client will be logged. If you enable it, the
host name will be logged instead, if it is possible to resolve
the IP address to a name.
There are two disadvantages of enabling host name lookups. Every access
results in network traffic to resolve the address, and the accessed page
can't be returned until after the address is resolved, so your Web
server will be slowed down. If you're interested in seeing the host
names of machines accessing your Web server, a better idea is to let a
log file analyzer resolve the addresses as it processes the log files.
<sect>Features
<p>
This controls various features beyond simply returning the
contents of a file. In most cases this is controlled by the
sub-directory specs instead.
<sect1>Server side includes
<p>
If enabled, files with the extension .shtml are processed
to expand server side includes tags before the results are
returned to the client.
<sect1>IncludesNOEXEC
<p>
Also enables server side includes, but the SSI tag
#exec and #include:ing CGI-scripts are disabled.
<sect1>May execute CGI
<p>
Allow CGI scripts. Usually only enabled in the sub-directory
spec for the CGI directory.
<sect1>Indexes
<p>
When accessing an URL ending in a directory the file index.html in that
directory is returned. If that file doesn't exist, and this option is
enabled, a directory listing is returned. If this option is disabled, a
404 Not found is returned instead.
<sect1>May follow symlinks
<p>
If an accessed directory or file is a symbolic link, the
access will only be allowed if this feature is enabled.
<sect1>Follow symlink if owner matches
<p>
As above, but additionally, the owner of the symbolic link and
its target file must be the same. This allows users to have
symbolic links to their own files, but not to sensitive system
files like /etc/passwd.
<sect1>Multiviews
<p>
Multiviews allows the client browser and the Web server to negotiate the
format and language in which data should be returned. To make the Web
server capable of doing this, you can store the various languages and
data formats in files with certain extensions and then enable
multiviews.
</article>
|
