Apache httpd, "der" WEB-Server - Installation unter Arch Linux
Apache HTTP Server Project kann mit Fug und Recht von sich behaupten, der führende HTTP-Server im Internet. Im April 1995 startete das Projekt der pache-HTTP-Server („httpd“) und wird in diesem Jahr 2026 seinen 30 Geburtstag feiern! Das Ziel dieses Projekts ist es, einen sicheren, effizienten und erweiterbaren Server bereitzustellen, der HTTP-Dienste zeitgemäß den aktuellen HTTP-Standards bietet. Der freie und quelloffene Webserver wird von der Apache Software Foundation zur Verfügung gestellt, gepflegt und dort auch weiterentwickelt.
In der Apache HTTP Server Documentation findet man eine ausführliche Dokumentation des Projekts, sowie im Apache HTTP Server Wiki viele hilfreiche Tips und Anregungen für die Installation und den Betrieb des HTTP-Webservers.
Installation und Konfiguration des Apache-Webservers
Dokumentation / Man-Pages
httpd Manpage
Was uns der httpd - Apache Hypertext Transfer Protocol Server bietet und welche Optionen beim Aufruf der Daemon bietet offenbart uns die betreffende Man-Page des Programms.
HTTPD(8) httpd HTTPD(8)
NAME
httpd - Apache Hypertext Transfer Protocol Server
SYNOPSIS
httpd [ -d serverroot ] [ -f config ] [ -C directive ] [ -c directive ] [ -D parameter ] [ -e level ] [ -E file
] [ -k start|restart|graceful|stop|graceful-stop ] [ -h ] [ -l ] [ -L ] [ -S ] [ -t ] [ -v ] [ -V ] [ -X ] [ -M
] [ -T ]
On Windows systems, the following additional arguments are available:
httpd [ -k install|config|uninstall ] [ -n name ] [ -w ]
SUMMARY
httpd is the Apache HyperText Transfer Protocol (HTTP) server program. It is designed to be run as a standalone
daemon process. When used like this it will create a pool of child processes or threads to handle requests.
In general, httpd should not be invoked directly, but rather should be invoked via apachectl on Unix-based sys‐
tems or as a service on Windows NT, 2000 and XP and as a console application on Windows 9x and ME.
OPTIONS
-d serverroot
Set the initial value for the ServerRoot directive to serverroot. This can be overridden by the Server‐
Root directive in the configuration file. The default is /usr/local/apache2.
-f config
Uses the directives in the file config on startup. If config does not begin with a /, then it is taken
to be a path relative to the ServerRoot. The default is conf/httpd.conf.
-k start|restart|graceful|stop|graceful-stop
Signals httpd to start, restart, or stop. See Stopping Apache httpd for more information.
-C directive
Process the configuration directive before reading config files.
-c directive
Process the configuration directive after reading config files.
-D parameter
Sets a configuration parameter which can be used with <IfDefine> sections in the configuration files to
conditionally skip or process commands at server startup and restart. Also can be used to set certain
less-common startup parameters including -DNO_DETACH (prevent the parent from forking) and -DFOREGROUND
(prevent the parent from calling setsid() et al).
-e level
Sets the LogLevel to level during server startup. This is useful for temporarily increasing the ver‐
bosity of the error messages to find problems during startup.
-E file
Send error messages during server startup to file.
-h Output a short summary of available command line options.
-l Output a list of modules compiled into the server. This will not list dynamically loaded modules in‐
cluded using the LoadModule directive.
-L Output a list of directives provided by static modules, together with expected arguments and places
where the directive is valid. Directives provided by shared modules are not listed.
-M Dump a list of loaded Static and Shared Modules.
-S Show the settings as parsed from the config file (currently only shows the virtualhost settings).
-T (Available in 2.3.8 and later)
Skip document root check at startup/restart.
-t Run syntax tests for configuration files only. The program immediately exits after these syntax parsing
tests with either a return code of 0 (Syntax OK) or return code not equal to 0 (Syntax Error). If -D
DUMP_VHOSTS is also set, details of the virtual host configuration will be printed. If -D DUMP_MODULES
is set, all loaded modules will be printed.
-v Print the version of httpd, and then exit.
-V Print the version and build parameters of httpd, and then exit.
-X Run httpd in debug mode. Only one worker will be started and the server will not detach from the con‐
sole.
The following arguments are available only on the Windows platform:
-k install|config|uninstall
Install Apache httpd as a Windows NT service; change startup options for the Apache httpd service; and
uninstall the Apache httpd service.
-n name
The name of the Apache httpd service to signal.
-w Keep the console window open on error so that the error message can be read.
Apache HTTP Server 2018-07-06 HTTPD(8)
apachectl Manpage
Mit Hilfe des Befehls apachectl, dem Apache HTTP Server Control Interface können wir unseren HTTP-Daemon administrieren oder auch die Konfigurations auf syntaktische Fehler überprfüfen.
PACHECTL(8) apachectl APACHECTL(8)
NAME
apachectl - Apache HTTP Server Control Interface
SYNOPSIS
When acting in pass-through mode, apachectl can take all the arguments available for the httpd binary.
apachectl [ httpd-argument ]
When acting in SysV init mode, apachectl takes simple, one-word commands, defined below.
apachectl command
SUMMARY
apachectl is a front end to the Apache HyperText Transfer Protocol (HTTP) server. It is designed to help the administrator control
the functioning of the Apache httpd daemon.
The apachectl script can operate in two modes. First, it can act as a simple front-end to the httpd command that simply sets any
necessary environment variables and then invokes httpd, passing through any command line arguments. Second, apachectl can act as a
SysV init script, taking simple one-word arguments like start, restart, and stop, and translating them into appropriate signals to
httpd.
If your Apache installation uses non-standard paths, you will need to edit the apachectl script to set the appropriate paths to the
httpd binary. You can also specify any necessary httpd command line arguments. See the comments in the script for details.
The apachectl script returns a 0 exit value on success, and >0 if an error occurs. For more details, view the comments in the
script.
OPTIONS
Only the SysV init-style options are defined here. Other arguments are defined on the httpd manual page.
start Start the Apache httpd daemon. Gives an error if it is already running. This is equivalent to apachectl -k start.
stop Stops the Apache httpd daemon. This is equivalent to apachectl -k stop.
restart
Restarts the Apache httpd daemon. If the daemon is not running, it is started. This command automatically checks the config‐
uration files as in configtest before initiating the restart to make sure the daemon doesn't die. This is equivalent to
stop Stops the Apache httpd daemon. This is equivalent to apachectl -k stop.
restart
Restarts the Apache httpd daemon. If the daemon is not running, it is started. This command automatically checks the config‐
uration files as in configtest before initiating the restart to make sure the daemon doesn't die. This is equivalent to
apachectl -k restart.
fullstatus
Displays a full status report from mod_status. For this to work, you need to have mod_status enabled on your server and a
text-based browser such as lynx available on your system. The URL used to access the status report can be set by editing the
STATUSURL variable in the script.
status Displays a brief status report. Similar to the fullstatus option, except that the list of requests currently being served is
omitted.
graceful
Gracefully restarts the Apache httpd daemon. If the daemon is not running, it is started. This differs from a normal restart
in that currently open connections are not aborted. A side effect is that old log files will not be closed immediately. This
means that if used in a log rotation script, a substantial delay may be necessary to ensure that the old log files are
closed before processing them. This command automatically checks the configuration files as in configtest before initiating
the restart to make sure Apache doesn't die. This is equivalent to apachectl -k graceful.
graceful-stop
Gracefully stops the Apache httpd daemon. This differs from a normal stop in that currently open connections are not
aborted. A side effect is that old log files will not be closed immediately. This is equivalent to apachectl -k graceful-
stop.
configtest
Run a configuration file syntax test. It parses the configuration files and either reports Syntax Ok or detailed information
about the particular syntax error. This is equivalent to apachectl -t.
The following option was available in earlier versions but has been removed.
startssl
To start httpd with SSL support, you should edit your configuration file to include the relevant directives and then use the
normal apachectl start.
Apache HTTP Server 2018-07-06 APACHECTL(8)
htpasswd Manpage
Mit Hilfe des Befehls passwd können wir eine einfache Datei mit unsername und password erstellen und somit einen einfachen Zugriffsschutz realisieren.
HTPASSWD(1) htpasswd HTPASSWD(1)
NAME
htpasswd - Manage user files for basic authentication
SYNOPSIS
htpasswd [ -c ] [ -i ] [ -m | -B | -2 | -5 | -d | -s | -p ] [ -r rounds ] [ -C cost ] [ -D ] [ -v ] passwdfile username
htpasswd -b [ -c ] [ -m | -B | -2 | -5 | -d | -s | -p ] [ -r rounds ] [ -C cost ] [ -D ] [ -v ] passwdfile username password
htpasswd -n [ -i ] [ -m | -B | -2 | -5 | -d | -s | -p ] [ -r rounds ] [ -C cost ] username
htpasswd -nb [ -m | -B | -2 | -5 | -d | -s | -p ] [ -r rounds ] [ -C cost ] username password
SUMMARY
htpasswd is used to create and update the flat-files used to store usernames and password for basic authentication of HTTP users.
If htpasswd cannot access a file, such as not being able to write to the output file or not being able to read the file in order
to update it, it returns an error status and makes no changes.
Resources available from the Apache HTTP server can be restricted to just the users listed in the files created by htpasswd. This
program can only manage usernames and passwords stored in a flat-file. It can hash and display password information for use in
other types of data stores, though. To use a DBM database see dbmmanage or htdbm.
htpasswd hashes passwords using either bcrypt, a version of MD5 modified for Apache, SHA-1, or the system's crypt() routine.
SHA-2-based hashes (SHA-256 and SHA-512) are supported for crypt(). Files managed by htpasswd may contain a mixture of different
encoding types of passwords; some user records may have bcrypt or MD5-hashed passwords while others in the same file may have
passwords hashed with crypt().
This manual page only lists the command line arguments. For details of the directives necessary to configure user authentication
in httpd see the Apache manual, which is part of the Apache distribution or can be found at http://httpd.apache.org/.
OPTIONS
-b Use batch mode; i.e., get the password from the command line rather than prompting for it. This option should be used with
extreme care, since the password is clearly visible on the command line. For script use see the -i option. Available in
2.4.4 and later.
-i Read the password from stdin without verification (for script usage).
-c Create the passwdfile. If passwdfile already exists, it is rewritten and truncated. This option cannot be combined with the
-n option.
-n Display the results on standard output rather than updating a file. This is useful for generating password records accept‐
able to Apache for inclusion in non-text data stores. This option changes the syntax of the command line, since the passwd‐
file argument (usually the first one) is omitted. It cannot be combined with the -c option.
-m Use MD5 hashing for passwords. This is the default (since version 2.2.18).
-2 Use SHA-256 crypt() based hashes for passwords. This is supported on most Unix platforms.
-5 Use SHA-512 crypt() based hashes for passwords. This is supported on most Unix platforms.
-B Use bcrypt hashing for passwords. This is currently considered to be very secure.
-C This flag is only allowed in combination with -B (bcrypt hashing). It sets the computing time used for the bcrypt algorithm
(higher is more secure but slower, default: 5, valid: 4 to 17).
-r This flag is only allowed in combination with -2 or -5. It sets the number of hash rounds used for the SHA-2 algorithms
(higher is more secure but slower; the default is 5,000).
-d Use crypt() hashing for passwords. This is not supported by the httpd server on Windows and Netware. This algorithm limits
the password length to 8 characters. This algorithm is insecure by today's standards. It used to be the default algorithm
until version 2.2.17.
-s Use SHA-1 (160-bit) hashing for passwords. Facilitates migration from/to Netscape servers using the LDAP Directory Inter‐
change Format (ldif). This algorithm is insecure by today's standards.
-p Use plaintext passwords. Though htpasswd will support creation on all platforms, the httpd daemon will only accept plain
text passwords on Windows and Netware.
-D Delete user. If the username exists in the specified htpasswd file, it will be deleted.
-v Verify password. Verify that the given password matches the password of the user stored in the specified htpasswd file.
Available in 2.4.5 and later.
passwdfile
Name of the file to contain the user name and password. If -c is given, this file is created if it does not already exist,
or rewritten and truncated if it does exist.
username
The username to create or update in passwdfile. If username does not exist in this file, an entry is added. If it does ex‐
ist, the password is changed.
password
The plaintext password to be hashed and stored in the file. Only used with the -b flag.
EXIT STATUS
htpasswd returns a zero status ("true") if the username and password have been successfully added or updated in the passwdfile.
htpasswd returns 1 if it encounters some problem accessing files, 2 if there was a syntax problem with the command line, 3 if the
password was entered interactively and the verification entry didn't match, 4 if its operation was interrupted, 5 if a value is
too long (username, filename, password, or final computed record), 6 if the username contains illegal characters (see the Restric‐
tions section), and 7 if the file is not a valid password file.
EXAMPLES
htpasswd /usr/local/etc/apache/.htpasswd-users jsmith
Adds or modifies the password for user jsmith. The user is prompted for the password. The password will be hashed using the modi‐
fied Apache MD5 algorithm. If the file does not exist, htpasswd will do nothing except return an error.
htpasswd -c /home/doe/public_html/.htpasswd jane
Creates a new file and stores a record in it for user jane. The user is prompted for the password. If the file exists and cannot
be read, or cannot be written, it is not altered and htpasswd will display a message and return an error status.
htpasswd -db /usr/web/.htpasswd-all jones Pwd4Steve
Encrypts the password from the command line (Pwd4Steve) using the crypt() algorithm, and stores it in the specified file.
SECURITY CONSIDERATIONS
Web password files such as those managed by htpasswd should not be within the Web server's URI space -- that is, they should not
be fetchable with a browser.
This program is not safe as a setuid executable. Do not make it setuid.
The use of the -b option is discouraged, since when it is used the plaintext password appears on the command line.
When using the crypt() algorithm, note that only the first 8 characters of the password are used to form the password. If the sup‐
plied password is longer, the extra characters will be silently discarded.
The SHA-1 hashing format does not use salting: for a given password, there is only one hashed representation. The crypt() and MD5
formats permute the representation by prepending a random salt string, to make dictionary attacks against the passwords more dif‐
ficult.
The SHA-1 and crypt() formats are insecure by today's standards.
The SHA-2-based crypt() formats (SHA-256 and SHA-512) are supported on most modern Unix systems, and follow the specification at
https://www.akkadia.org/drepper/SHA-crypt.txt.
RESTRICTIONS
On the Windows platform, passwords hashed with htpasswd are limited to no more than 255 characters in length. Longer passwords
will be truncated to 255 characters.
The MD5 algorithm used by htpasswd is specific to the Apache software; passwords hashed using it will not be usable with other Web
servers.
Usernames are limited to 255 bytes and may not include the character :.
The cost of computing a bcrypt password hash value increases with the number of rounds specified by the -C option. The apr-util
library enforces a maximum number of rounds of 17 in version 1.6.0 and later.
Apache HTTP Server 2024-04-02 HTPASSWD(1)
htdigest Manpage
Mit Hilfe des Befehls htdigest können wir eine einfache Datei mit unsername und password erstellen und somit einen einfachen Zugriffsschutz realisieren.
HTDIGEST(1) htdigest HTDIGEST(1)
NAME
htdigest - manage user files for digest authentication
SYNOPSIS
htdigest [ -c ] passwdfile realm username
SUMMARY
htdigest is used to create and update the flat-files used to store usernames, realm and password for digest authentication of HTTP
users. Resources available from the Apache HTTP server can be restricted to just the users listed in the files created by htdi‐
gest.
This manual page only lists the command line arguments. For details of the directives necessary to configure digest authentication
in httpd see the Apache manual, which is part of the Apache distribution or can be found at http://httpd.apache.org/.
OPTIONS
-c Create the passwdfile. If passwdfile already exists, it is deleted first.
passwdfile
Name of the file to contain the username, realm and password. If -c is given, this file is created if it does not already
exist, or deleted and recreated if it does exist.
realm The realm name to which the user name belongs. See http://tools.ietf.org/html/rfc2617#section-3.2.1 for more details.
username
The user name to create or update in passwdfile. If username does not exist is this file, an entry is added. If it does ex‐
ist, the password is changed.
SECURITY CONSIDERATIONS
This program is not safe as a setuid executable. Do not make it setuid.
Apache HTTP Server 2018-07-06 HTDIGEST(1)
Paketinstallation
Die Installation und Konfiguration HTTP-Servers apache gestaltet sich relativ einfach. Zur Installation des Paketes verwenden wir unter Arch Linux den Paketmanager pacman.
Als User:
$ sudo pacman -S apache
Als Nutzer mit Root-Rechten entsprechend:
# pacman -S apache
Neben dem Grundpaket werden noch als Abhängigkeit die beiden Pakete apr und apr-utilinstalliert.
Bei Bedarf können wir auch abfragen was die beiden Pakete rund um die The Apache Portable Runtimeaprt oder die anderen Anbängigkeiten, die mit installiert wurden, mitbringen:
# pacman -Qi <-paketname->
bzw.
# pacman -Qil <-paketname->
Grund-Konfiguration
Firewall/Paketfilter - firewalld
Bevor wir nun unseren httpd konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind.
Wie auch schon früher bei CentOS ab Release 7 bzw. den nachfolgenden Release-Kandidaten Stream von RHEL nutzen wir auch unter Arch Linux den dynamischen firewalld Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.
Damit unsere http-Daemon Anfragen aus dem Netz auf den Ports 80/TCP- und 443/TCP-Ports annahmen kann, müssen wir für diese noch Änderungen am Paketfilter firewalld vornehmen.
Zunächst installieren wir uns das betreffende firewalld-Paket.
# pacman -S firewalld
bzw. als Admin-User:
$ sudo pacman -S apache
Anschließend starten wir den Firewall-Daemon.
# systemctl start firewalld.service
Damit der Firewall-Daemon beim Neustart des Systems automatisch gestartet wird, enablen wir diesen nun auch noch.
# systemctl enable firewalld.service
Mit Hilfe des Programms firewall-cmd konfigurieren wir nun den Daemon:
idmz (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: net0
sources:
services: http https ssh
ports:
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
httpd-Konfigurationsverzeichnis und -Dateien
Die Konfiguration des Apache-Webservers httpd erfolgt nicht mit Hilfe einer großen Konfigurationsdatei, sondern ist aufgeteilt in kleinere spezielle Konfigurationsdateien, jeweils auf die einzelnen Anwendungsfälle abgestimmt.
Im Verzeichnis /etc/httpd finden wir all diese Dateien.
Im Abschnitt httpd-Konfigurationsverzeichnis und -Dateien hatten wir bereits einen Blick in das Konfigurationsverzeichnis /etc/httpd geworfen. In folgendem Kapitel wollen wir nun auf die einzelnen Unterverzeichnisse und Dateien eingehen und unseren Bedürfnissen entsprechend anpassen.
/etc/httpd/conf :
Konfigurationsverzeichnis mit den wesentlichen Konfigurationsdateien httpd.conf, magic und mime.types, sowie den beiden Unterverzeichnissen conf und modules.
/etc/httpd/conf/httpd.conf :
Dies ist die Hauptkonfigurationsdatei des Apache-HTTP-Daemon. Sie enthält die Konfigurationsanweisungen, die dem Server seine Anweisungen geben. Detaillierte Informationen über den Aufbau und den Directiven finden sich in der zugehörigen Dokumentation.
/etc/httpd/conf/magic :
Dieses Modul bestimmt den MIME-Typ von Dateien auf die gleiche Weise wie der Unix-Befehl file. Es untersucht die ersten Bytes der Datei. Dieses Modul ist nur aktiv, sofern diese durch die Directive MimeMagicFile angegeben ist.
/etc/httpd/conf/mime.types :
Datei für die Zuordnung von Internet-Medientypen zu eindeutigen Dateierweiterungen. Obwohl sie für httpd erstellt wurde, wird diese Datei von vielen Softwaresystemen verwendet und wurde zur uneingeschränkten Weiterverbreitung in die Public Domain gestellt. Internet-Medientypen sollten gemäß RFC 4288 registriert werden.
/etc/httpd/conf/extra/ :
Verzeichnis für gruppierte Themenbezogene Konfigurationsoptionen.
/etc/httpd/conf/extra/httpd-autoindex.conf :
Direktive zur Steuerung der Anzeige von serverseitig generierten Verzeichnislisten.
/etc/httpd/conf/extra/httpd-dav.conf :
Einstellungen zum verteilten Authoring und Versionierung (WebDAV)
/etc/httpd/conf/extra/httpd-default.conf :
Diese Konfigurationsdatei enthält die Standardeinstellungen für den Apache HTTP Server.
/etc/httpd/conf/extra/httpd-info.conf :
Einstellungen zu Status-Rückmeldungen und -Informationen des Servers, abrufbar unter speziellen URL-Ergänzungen /server-status sowie /server-info.
/etc/httpd/conf/extra/httpd-languages.conf :
Konfigurationsoptionen für das Hosting verschiedener Sprachen.
/etc/httpd/conf/extra/httpd-manual.conf :
Definitionen zur Einbindung der Apache HTTP Server-Dokumentation, welche bei entsprechender Konfiguration unter der URL-Ergänzung /manual erreicht werden kann.
/etc/httpd/conf/extra/httpd-mpm.conf :
Konfiguratione für das Server-Pool Management.
/etc/httpd/conf/extra/httpd-multilang-errordoc.conf :
Die folgende Konfiguration implementiert mehrsprachige Fehlerdokumente mit Hilfe der content-negotiation.
/etc/httpd/conf/extra/httpd-ssl.conf :
Dies ist die Apache-Serverkonfigurationsdatei, die SSL-Unterstützung bietet. Sie enthält die Konfigurationsanweisungen, die dem Server mitteilen, wie Seiten über eine verschlüsselte HTTPS-Verbindung bereitgestellt werden sollen. Ausführliche Informationen zu den einzelnen Anweisungen finden Sie unter in der zugehörigen Dokumentationsseite.
/etc/httpd/conf/extra/httpd-userdir.conf :
Konfigurationsdatei für Einstellungen von benutzerdefinierter Web-Seiten.
/etc/httpd/conf/extra/httpd-vhosts.conf :
Definitionen zu virtual Hosts für das Hosting mehrere Domains/Hostnamen (VirtualHost-Container) auf einem Server.
/etc/httpd/conf/extra/proxy-html.conf :
Konfigurationsdatei mit den Einstellungen für das Apache HTTP Server-Modul mod_proxy_html.
Wichtig:
Die folgenden Konfigurationsdateien sind standardmäßig bereits inkludiert und die darin enthaltenen Definitionen werden beim Start und Betrieb des HTTPD verwendet:
Die Konfiguration des Daemon erfolgt über die Datei /etc/httpd/conf/httpd.conf die uns bei der Paketinstallation mitgeliefert wurde. Damit wir Änderungen, die beim Updaten des installierten Paketes ggf. neu hinzukommen oder wegfallen, besser von der Originaldatei unterscheiden können kopieren wir uns als erstes diese Datei.
Die Hupt-Konfigurationsdatei des Apache Web Servers ist außerordentlich gut dokumentiert. Werfen wir einen kurzen Blick mal in diese Konfigurationsdatei.
│ File: /etc/httpd/conf/httpd.conf
─────┼────────────────────────────────────────────────────────────────────────────────
1 │ #
2 │ # This is the main Apache HTTP server configuration file. It contains the
3 │ # configuration directives that give the server its instructions.
4 │ # See <URL:http://httpd.apache.org/docs/2.4/> for detailed information.
5 │ # In particular, see
6 │ # <URL:http://httpd.apache.org/docs/2.4/mod/directives.html>
7 │ # for a discussion of each configuration directive.
8 │ #
9 │ # Do NOT simply read the instructions in here without understanding
10 │ # what they do. They're here only as hints or reminders. If you are unsure
11 │ # consult the online docs. You have been warned.
12 │ #
13 │ # Configuration and logfile names: If the filenames you specify for many
14 │ # of the server's control files begin with "/" (or "drive:/" for Win32), the
15 │ # server will use that explicit path. If the filenames do *not* begin
16 │ # with "/", the value of ServerRoot is prepended -- so "logs/access_log"
17 │ # with ServerRoot set to "/usr/local/apache2" will be interpreted by the
18 │ # server as "/usr/local/apache2/logs/access_log", whereas "/logs/access_log"
19 │ # will be interpreted as '/logs/access_log'.
20 │
21 │ #
22 │ # ServerRoot: The top of the directory tree under which the server's
23 │ # configuration, error, and log files are kept.
24 │ #
25 │ # Do not add a slash at the end of the directory path. If you point
26 │ # ServerRoot at a non-local disk, be sure to specify a local disk on the
27 │ # Mutex directive, if file-based mutexes are used. If you wish to share the
28 │ # same ServerRoot for multiple httpd daemons, you will need to change at
29 │ # least PidFile.
30 │ #
31 │ ServerRoot "/etc/httpd"
32 │
33 │ #
34 │ # Mutex: Allows you to set the mutex mechanism and mutex file directory
35 │ # for individual mutexes, or change the global defaults
36 │ #
37 │ # Uncomment and change the directory if mutexes are file-based and the default
38 │ # mutex file directory is not on a local disk or is not appropriate for some
39 │ # other reason.
40 │ #
41 │ # Mutex default:/run/httpd
42 │
43 │ #
44 │ # Listen: Allows you to bind Apache to specific IP addresses and/or
45 │ # ports, instead of the default. See also the <VirtualHost>
46 │ # directive.
47 │ #
48 │ # Change this to Listen on specific IP addresses as shown below to
49 │ # prevent Apache from glomming onto all bound IP addresses.
50 │ #
51 │ #Listen 12.34.56.78:80
52 │ Listen 80
53 │
54 │ #
55 │ # Dynamic Shared Object (DSO) Support
56 │ #
57 │ # To be able to use the functionality of a module which was built as a DSO you
58 │ # have to place corresponding `LoadModule' lines at this location so the
59 │ # directives contained in it are actually available _before_ they are used.
60 │ # Statically compiled modules (those listed by `httpd -l') do not need
61 │ # to be loaded here.
62 │ #
63 │ # Example:
64 │ # LoadModule foo_module modules/mod_foo.so
65 │ #
66 │ LoadModule mpm_event_module modules/mod_mpm_event.so
67 │ #LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
68 │ #LoadModule mpm_worker_module modules/mod_mpm_worker.so
69 │ LoadModule authn_file_module modules/mod_authn_file.so
70 │ #LoadModule authn_dbm_module modules/mod_authn_dbm.so
71 │ #LoadModule authn_anon_module modules/mod_authn_anon.so
72 │ #LoadModule authn_dbd_module modules/mod_authn_dbd.so
73 │ #LoadModule authn_socache_module modules/mod_authn_socache.so
74 │ LoadModule authn_core_module modules/mod_authn_core.so
75 │ LoadModule authz_host_module modules/mod_authz_host.so
76 │ LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
77 │ LoadModule authz_user_module modules/mod_authz_user.so
78 │ #LoadModule authz_dbm_module modules/mod_authz_dbm.so
79 │ #LoadModule authz_owner_module modules/mod_authz_owner.so
80 │ #LoadModule authz_dbd_module modules/mod_authz_dbd.so
81 │ LoadModule authz_core_module modules/mod_authz_core.so
82 │ #LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
83 │ #LoadModule authnz_fcgi_module modules/mod_authnz_fcgi.so
84 │ LoadModule access_compat_module modules/mod_access_compat.so
85 │ LoadModule auth_basic_module modules/mod_auth_basic.so
86 │ #LoadModule auth_form_module modules/mod_auth_form.so
87 │ #LoadModule auth_digest_module modules/mod_auth_digest.so
88 │ #LoadModule allowmethods_module modules/mod_allowmethods.so
89 │ #LoadModule file_cache_module modules/mod_file_cache.so
90 │ #LoadModule cache_module modules/mod_cache.so
91 │ #LoadModule cache_disk_module modules/mod_cache_disk.so
92 │ #LoadModule cache_socache_module modules/mod_cache_socache.so
93 │ #LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
94 │ #LoadModule socache_dbm_module modules/mod_socache_dbm.so
95 │ #LoadModule socache_memcache_module modules/mod_socache_memcache.so
96 │ #LoadModule socache_redis_module modules/mod_socache_redis.so
97 │ #LoadModule watchdog_module modules/mod_watchdog.so
98 │ #LoadModule macro_module modules/mod_macro.so
99 │ #LoadModule dbd_module modules/mod_dbd.so
100 │ #LoadModule dumpio_module modules/mod_dumpio.so
101 │ #LoadModule echo_module modules/mod_echo.so
102 │ #LoadModule buffer_module modules/mod_buffer.so
103 │ #LoadModule data_module modules/mod_data.so
104 │ #LoadModule ratelimit_module modules/mod_ratelimit.so
105 │ LoadModule reqtimeout_module modules/mod_reqtimeout.so
106 │ #LoadModule ext_filter_module modules/mod_ext_filter.so
107 │ #LoadModule request_module modules/mod_request.so
108 │ LoadModule include_module modules/mod_include.so
109 │ LoadModule filter_module modules/mod_filter.so
110 │ #LoadModule reflector_module modules/mod_reflector.so
111 │ #LoadModule substitute_module modules/mod_substitute.so
112 │ #LoadModule sed_module modules/mod_sed.so
113 │ #LoadModule charset_lite_module modules/mod_charset_lite.so
114 │ #LoadModule deflate_module modules/mod_deflate.so
115 │ #LoadModule xml2enc_module modules/mod_xml2enc.so
116 │ #LoadModule proxy_html_module modules/mod_proxy_html.so
117 │ #LoadModule brotli_module modules/mod_brotli.so
118 │ LoadModule mime_module modules/mod_mime.so
119 │ #LoadModule ldap_module modules/mod_ldap.so
120 │ LoadModule log_config_module modules/mod_log_config.so
121 │ #LoadModule log_debug_module modules/mod_log_debug.so
122 │ #LoadModule log_forensic_module modules/mod_log_forensic.so
123 │ #LoadModule logio_module modules/mod_logio.so
124 │ #LoadModule lua_module modules/mod_lua.so
125 │ LoadModule env_module modules/mod_env.so
126 │ #LoadModule mime_magic_module modules/mod_mime_magic.so
127 │ #LoadModule cern_meta_module modules/mod_cern_meta.so
128 │ #LoadModule expires_module modules/mod_expires.so
129 │ LoadModule headers_module modules/mod_headers.so
130 │ #LoadModule ident_module modules/mod_ident.so
131 │ #LoadModule usertrack_module modules/mod_usertrack.so
132 │ #LoadModule unique_id_module modules/mod_unique_id.so
133 │ LoadModule setenvif_module modules/mod_setenvif.so
134 │ LoadModule version_module modules/mod_version.so
135 │ #LoadModule remoteip_module modules/mod_remoteip.so
136 │ #LoadModule proxy_module modules/mod_proxy.so
137 │ #LoadModule proxy_connect_module modules/mod_proxy_connect.so
138 │ #LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
139 │ #LoadModule proxy_http_module modules/mod_proxy_http.so
140 │ #LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
141 │ #LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
142 │ #LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so
143 │ #LoadModule proxy_fdpass_module modules/mod_proxy_fdpass.so
144 │ #LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
145 │ #LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
146 │ #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
147 │ #LoadModule proxy_express_module modules/mod_proxy_express.so
148 │ #LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so
149 │ #LoadModule session_module modules/mod_session.so
150 │ #LoadModule session_cookie_module modules/mod_session_cookie.so
151 │ #LoadModule session_crypto_module modules/mod_session_crypto.so
152 │ #LoadModule session_dbd_module modules/mod_session_dbd.so
153 │ LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
154 │ #LoadModule slotmem_plain_module modules/mod_slotmem_plain.so
155 │ #LoadModule ssl_module modules/mod_ssl.so
156 │ #LoadModule dialup_module modules/mod_dialup.so
157 │ #LoadModule http2_module modules/mod_http2.so
158 │ #LoadModule proxy_http2_module modules/mod_proxy_http2.so
159 │ #LoadModule md_module modules/mod_md.so
160 │ #LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
161 │ #LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so
162 │ #LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
163 │ #LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so
164 │ LoadModule unixd_module modules/mod_unixd.so
165 │ #LoadModule heartbeat_module modules/mod_heartbeat.so
166 │ #LoadModule heartmonitor_module modules/mod_heartmonitor.so
167 │ #LoadModule dav_module modules/mod_dav.so
168 │ LoadModule status_module modules/mod_status.so
169 │ LoadModule autoindex_module modules/mod_autoindex.so
170 │ #LoadModule asis_module modules/mod_asis.so
171 │ #LoadModule info_module modules/mod_info.so
172 │ #LoadModule suexec_module modules/mod_suexec.so
173 │ <IfModule !mpm_prefork_module>
174 │ #LoadModule cgid_module modules/mod_cgid.so
175 │ </IfModule>
176 │ <IfModule mpm_prefork_module>
177 │ #LoadModule cgi_module modules/mod_cgi.so
178 │ </IfModule>
179 │ #LoadModule dav_fs_module modules/mod_dav_fs.so
180 │ #LoadModule dav_lock_module modules/mod_dav_lock.so
181 │ #LoadModule vhost_alias_module modules/mod_vhost_alias.so
182 │ LoadModule negotiation_module modules/mod_negotiation.so
183 │ LoadModule dir_module modules/mod_dir.so
184 │ #LoadModule imagemap_module modules/mod_imagemap.so
185 │ #LoadModule actions_module modules/mod_actions.so
186 │ #LoadModule speling_module modules/mod_speling.so
187 │ LoadModule userdir_module modules/mod_userdir.so
188 │ LoadModule alias_module modules/mod_alias.so
189 │ #LoadModule rewrite_module modules/mod_rewrite.so
190 │
191 │ <IfModule unixd_module>
192 │ #
193 │ # If you wish httpd to run as a different user or group, you must run
194 │ # httpd as root initially and it will switch.
195 │ #
196 │ # User/Group: The name (or #number) of the user/group to run httpd as.
197 │ # It is usually good practice to create a dedicated user and group for
198 │ # running httpd, as with most system services.
199 │ #
200 │ User http
201 │ Group http
202 │
203 │ </IfModule>
204 │
205 │ # 'Main' server configuration
206 │ #
207 │ # The directives in this section set up the values used by the 'main'
208 │ # server, which responds to any requests that aren't handled by a
209 │ # <VirtualHost> definition. These values also provide defaults for
210 │ # any <VirtualHost> containers you may define later in the file.
211 │ #
212 │ # All of these directives may appear inside <VirtualHost> containers,
213 │ # in which case these default settings will be overridden for the
214 │ # virtual host being defined.
215 │ #
216 │
217 │ #
218 │ # ServerAdmin: Your address, where problems with the server should be
219 │ # e-mailed. This address appears on some server-generated pages, such
220 │ # as error documents. e.g. admin@your-domain.com
221 │ #
222 │ ServerAdmin you@example.com
223 │
224 │ #
225 │ # ServerName gives the name and port that the server uses to identify itself.
226 │ # This can often be determined automatically, but we recommend you specify
227 │ # it explicitly to prevent problems during startup.
228 │ #
229 │ # If your host doesn't have a registered DNS name, enter its IP address here.
230 │ #
231 │ #ServerName www.example.com:80
232 │
233 │ #
234 │ # Deny access to the entirety of your server's filesystem. You must
235 │ # explicitly permit access to web content directories in other
236 │ # <Directory> blocks below.
237 │ #
238 │ <Directory />
239 │ AllowOverride none
240 │ Require all denied
241 │ </Directory>
242 │
243 │ #
244 │ # Note that from this point forward you must specifically allow
245 │ # particular features to be enabled - so if something's not working as
246 │ # you might expect, make sure that you have specifically enabled it
247 │ # below.
248 │ #
249 │
250 │ #
251 │ # DocumentRoot: The directory out of which you will serve your
252 │ # documents. By default, all requests are taken from this directory, but
253 │ # symbolic links and aliases may be used to point to other locations.
254 │ #
255 │ DocumentRoot "/srv/http"
256 │ <Directory "/srv/http">
257 │ #
258 │ # Possible values for the Options directive are "None", "All",
259 │ # or any combination of:
260 │ # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
261 │ #
262 │ # Note that "MultiViews" must be named *explicitly* --- "Options All"
263 │ # doesn't give it to you.
264 │ #
265 │ # The Options directive is both complicated and important. Please see
266 │ # http://httpd.apache.org/docs/2.4/mod/core.html#options
267 │ # for more information.
268 │ #
269 │ Options Indexes FollowSymLinks
270 │
271 │ #
272 │ # AllowOverride controls what directives may be placed in .htaccess files.
274 │ # AllowOverride FileInfo AuthConfig Limit
275 │ #
276 │ AllowOverride None
277 │
278 │ #
279 │ # Controls who can get stuff from this server.
280 │ #
281 │ Require all granted
282 │ </Directory>
283 │
284 │ #
285 │ # DirectoryIndex: sets the file that Apache will serve if a directory
286 │ # is requested.
287 │ #
288 │ <IfModule dir_module>
289 │ DirectoryIndex index.html
290 │ </IfModule>
291 │
292 │ #
293 │ # The following lines prevent .htaccess and .htpasswd files from being
294 │ # viewed by Web clients.
295 │ #
296 │ <Files ".ht*">
297 │ Require all denied
298 │ </Files>
299 │
300 │ #
301 │ # ErrorLog: The location of the error log file.
302 │ # If you do not specify an ErrorLog directive within a <VirtualHost>
303 │ # container, error messages relating to that virtual host will be
304 │ # logged here. If you *do* define an error logfile for a <VirtualHost>
305 │ # container, that host's errors will be logged there and not here.
306 │ #
307 │ ErrorLog "/var/log/httpd/error_log"
308 │
309 │ #
310 │ # LogLevel: Control the number of messages logged to the error_log.
311 │ # Possible values include: debug, info, notice, warn, error, crit,
312 │ # alert, emerg.
313 │ #
314 │ LogLevel warn
315 │
316 │ <IfModule log_config_module>
317 │ #
318 │ # The following directives define some format nicknames for use with
319 │ # a CustomLog directive (see below).
320 │ #
321 │ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
322 │ LogFormat "%h %l %u %t \"%r\" %>s %b" common
323 │
324 │ <IfModule logio_module>
325 │ # You need to enable mod_logio.c to use %I and %O
326 │ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
327 │ </IfModule>
328 │
329 │ #
330 │ # The location and format of the access logfile (Common Logfile Format).
331 │ # If you do not define any access logfiles within a <VirtualHost>
332 │ # container, they will be logged here. Contrariwise, if you *do*
333 │ # define per-<VirtualHost> access logfiles, transactions will be
334 │ # logged therein and *not* in this file.
335 │ #
336 │ CustomLog "/var/log/httpd/access_log" common
337 │
338 │ #
339 │ # If you prefer a logfile with access, agent, and referer information
340 │ # (Combined Logfile Format) you can use the following directive.
341 │ #
342 │ #CustomLog "/var/log/httpd/access_log" combined
343 │ </IfModule>
344 │
345 │ <IfModule alias_module>
346 │ #
347 │ # Redirect: Allows you to tell clients about documents that used to
348 │ # exist in your server's namespace, but do not anymore. The client
349 │ # will make a new request for the document at its new location.
350 │ # Example:
351 │ # Redirect permanent /foo http://www.example.com/bar
352 │
353 │ #
354 │ # Alias: Maps web paths into filesystem paths and is used to
355 │ # access content that does not live under the DocumentRoot.
356 │ # Example:
357 │ # Alias /webpath /full/filesystem/path
358 │ #
359 │ # If you include a trailing / on /webpath then the server will
360 │ # require it to be present in the URL. You will also likely
361 │ # need to provide a <Directory> section to allow access to
362 │ # the filesystem path.
363 │
364 │ #
365 │ # ScriptAlias: This controls which directories contain server scripts.
366 │ # ScriptAliases are essentially the same as Aliases, except that
367 │ # documents in the target directory are treated as applications and
368 │ # run by the server when requested rather than as documents sent to the
369 │ # client. The same rules about trailing "/" apply to ScriptAlias
370 │ # directives as to Alias.
371 │ #
372 │ ScriptAlias /cgi-bin/ "/srv/http/cgi-bin/"
373 │
374 │ </IfModule>
375 │
376 │ <IfModule cgid_module>
377 │ #
378 │ # ScriptSock: On threaded servers, designate the path to the UNIX
379 │ # socket used to communicate with the CGI daemon of mod_cgid.
380 │ #
381 │ #Scriptsock cgisock
382 │ </IfModule>
383 │
384 │ #
385 │ # "/srv/http/cgi-bin" should be changed to whatever your ScriptAliased
386 │ # CGI directory exists, if you have that configured.
387 │ #
388 │ <Directory "/srv/http/cgi-bin">
389 │ AllowOverride None
390 │ Options None
391 │ Require all granted
392 │ </Directory>
393 │
394 │ <IfModule headers_module>
395 │ #
396 │ # Avoid passing HTTP_PROXY environment to CGI's on this or any proxied
397 │ # backend servers which have lingering "httpoxy" defects.
398 │ # 'Proxy' request header is undefined by the IETF, not listed by IANA
399 │ #
400 │ RequestHeader unset Proxy early
401 │ </IfModule>
402 │
403 │ <IfModule mime_module>
404 │ #
405 │ # TypesConfig points to the file containing the list of mappings from
406 │ # filename extension to MIME-type.
407 │ #
408 │ TypesConfig conf/mime.types
409 │
410 │ #
411 │ # AddType allows you to add to or override the MIME configuration
412 │ # file specified in TypesConfig for specific file types.
413 │ #
414 │ #AddType application/x-gzip .tgz
415 │ #
416 │ # AddEncoding allows you to have certain browsers uncompress
417 │ # information on the fly. Note: Not all browsers support this.
418 │ #
419 │ #AddEncoding x-compress .Z
420 │ #AddEncoding x-gzip .gz .tgz
421 │ #
422 │ # If the AddEncoding directives above are commented-out, then you
423 │ # probably should define those extensions to indicate media types:
424 │ #
425 │ AddType application/x-compress .Z
426 │ AddType application/x-gzip .gz .tgz
427 │
428 │ #
429 │ # AddHandler allows you to map certain file extensions to "handlers":
430 │ # actions unrelated to filetype. These can be either built into the server
431 │ # or added with the Action directive (see below)
432 │ #
433 │ # To use CGI scripts outside of ScriptAliased directories:
434 │ # (You will also need to add "ExecCGI" to the "Options" directive.)
435 │ #
436 │ #AddHandler cgi-script .cgi
437 │
438 │ # For type maps (negotiated resources):
439 │ #AddHandler type-map var
440 │
441 │ #
442 │ # Filters allow you to process content before it is sent to the client.
443 │ #
444 │ # To parse .shtml files for server-side includes (SSI):
445 │ # (You will also need to add "Includes" to the "Options" directive.)
446 │ #
447 │ #AddType text/html .shtml
448 │ #AddOutputFilter INCLUDES .shtml
449 │ </IfModule>
450 │
451 │ #
452 │ # The mod_mime_magic module allows the server to use various hints from the
453 │ # contents of the file itself to determine its type. The MIMEMagicFile
454 │ # directive tells the module where the hint definitions are located.
455 │ #
456 │ #MIMEMagicFile conf/magic
457 │
458 │ #
459 │ # Customizable error responses come in three flavors:
460 │ # 1) plain text 2) local redirects 3) external redirects
461 │ #
462 │ # Some examples:
463 │ #ErrorDocument 500 "The server made a boo boo."
464 │ #ErrorDocument 404 /missing.html
465 │ #ErrorDocument 404 "/cgi-bin/missing_handler.pl"
466 │ #ErrorDocument 402 http://www.example.com/subscription_info.html
467 │ #
468 │
469 │ #
470 │ # MaxRanges: Maximum number of Ranges in a request before
471 │ # returning the entire resource, or one of the special
472 │ # values 'default', 'none' or 'unlimited'.
473 │ # Default setting is to accept 200 Ranges.
474 │ #MaxRanges unlimited
475 │
476 │ #
477 │ # EnableMMAP and EnableSendfile: On systems that support it,
478 │ # memory-mapping or the sendfile syscall may be used to deliver
479 │ # files. This usually improves server performance, but must
480 │ # be turned off when serving from networked-mounted
481 │ # filesystems or if support for these functions is otherwise
482 │ # broken on your system.
483 │ # Defaults: EnableMMAP On, EnableSendfile Off
484 │ #
485 │ #EnableMMAP off
486 │ #EnableSendfile on
487 │
488 │ # Supplemental configuration
489 │ #
490 │ # The configuration files in the conf/extra/ directory can be
491 │ # included to add extra features or to modify the default configuration of
492 │ # the server, or you may simply copy their contents here and change as
494 │
495 │ # Server-pool management (MPM specific)
496 │ Include conf/extra/httpd-mpm.conf
497 │
498 │ # Multi-language error messages
499 │ Include conf/extra/httpd-multilang-errordoc.conf
500 │
501 │ # Fancy directory listings
502 │ Include conf/extra/httpd-autoindex.conf
503 │
504 │ # Language settings
505 │ Include conf/extra/httpd-languages.conf
506 │
507 │ # User home directories
508 │ Include conf/extra/httpd-userdir.conf
509 │
510 │ # Real-time info on requests and configuration
511 │ #Include conf/extra/httpd-info.conf
512 │
513 │ # Virtual hosts
514 │ #Include conf/extra/httpd-vhosts.conf
515 │
516 │ # Local access to the Apache HTTP Server Manual
517 │ #Include conf/extra/httpd-manual.conf
518 │
519 │ # Distributed authoring and versioning (WebDAV)
520 │ #Include conf/extra/httpd-dav.conf
521 │
522 │ # Various default settings
523 │ Include conf/extra/httpd-default.conf
524 │
525 │ # Configure mod_proxy_html to understand HTML4/XHTML1
526 │ <IfModule proxy_html_module>
527 │ Include conf/extra/proxy-html.conf
528 │ </IfModule>
529 │
530 │ # Secure (SSL/TLS) connections
531 │ #Include conf/extra/httpd-ssl.conf
532 │ #
533 │ # Note: The following must must be present to support
534 │ # starting without SSL on platforms with no /dev/random equivalent
535 │ # but a statically compiled-in mod_ssl.
536 │ #
537 │ <IfModule ssl_module>
538 │ SSLRandomSeed startup builtin
539 │ SSLRandomSeed connect builtin
540 │ </IfModule>
541 │
542 │ IncludeOptional conf/conf.d/*.conf
─────┴────────────────────────────────────────────────────────────────────────────────
Wir werden nun die relavanten Einträge von Oben nach unten in der Konfigurationsdatei Schritt für Schritt unseren Bedürnissen nach anpassen. Dazu öffnen wir die Datei mit dem Editor unserer Wahl. Wie immer dokumentieren wir entsprechende Änderungen mit einem Kommentar in der Form Adminname : Datum sowie der Angabe der Defaultkonfigurationsoption so dass für andere Admins besser ersichtlich ist, wer nun eine Option geändert hat und wann dies erfolgte.
# vim /etc/httpd/conf/httpd.conf
Im ersten Schritt beschränken wir uns erst einmal auf wenige Konfigurationsparameter, die wir unserer Umgebung nach entsprechend anpassen:
ServerAdmin : Hier definieren wir die eMail-Adresse des Administrator des Apache HTTP Daemons für automatisch generierte Fehlermeldungensseiten. Wenn der Apache HTTP Server bei der Beantwortung von Client-Anfragen auf Probleme stösst, wird eine angepasste Fehlermeldungsseite erzeugt, die ggf. einen link mit der eMail-Adresse des Apache HTTP Server-Administrators enthält.
#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed. This address appears on some server-generated pages, such
# as error documents. e.g. admin@your-domain.com
#
# Django : 2026-02-07
# default: ServerAdmin you@example.com
ServerAdmin webmaster@nausch.org
ServerName : ServerName gibt den Namen und den Port an, mit denen sich der Server identifiziert. Um Probleme beim Start zu vermeiden, ist es ratsam den Hostnamen und den verwendeten Port hier explizit anzugeben!
#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
# Django : 2026-02-07
# default: #ServerName www.example.com:80
ServerName vml000081.idmz.nausch.org:80
httpd-userdir.conf : Da wir keine Unterstützung der $Home-Verzeichnisse des bzw. der Admin-Nutzer benötigen, deaktivieren wir diese Option in dem wir sie auskommentieren.
# User home directories
# Django : 2026-02-07
# default: Include conf/extra/httpd-userdir.conf
Options im definierten <Directory „/srv/http“> : Konfigurationsoptionn mit der festgelegt wird, welche Eigenschaften bzw. Funktionen in einem bestimmten Verzeichnis verfügbar sind. Mögliche Werte für die Options-Direktive sind none, all oder eine beliebige Kombination aus: Indexes, Includes, FollowSymLinks, SymLinksifOwnerMatch, ExecCGI sowie MultiViews. Weitere Informationen zur Options -Directive findet man in der zugehörigen Dokumentation.
Somit haben wir nun alle für unseren Einsatz relevanten Optionen gesetzt. Eine Zusammenfassung aller Optionen ohne die Kommentare können wir mit Hilfe eines grep Befehls mit den Optionen -Ev uns ausgeben lassen.
In dem vorgenannten Konfigurationsbeispiel hatten wir definiert, dass unser DocumentRoot das Verzeichnis /srv/http den DirectoryIndex index.html (aus der Default-Paketinstallation) einschließt. Was wir nun noch brauchen ist diese Startseite index.html, welche wir nun noch anlegen.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>Apache httpd, "der" WEB-Server - Installation unter Arch Linux</title></head><body><p>Unserer erste <b>html</b>-Testseite!<br><br> Weiter Informationen zum Apache-Webserver unter Arch-Linux finden wir im <ahref="https://dokuwiki.nausch.org/doku.php/linux:webserver:start">Djangos Dokuwiki</a> ;)
</p></body></html>
Nun ist es an der Zeit, unseren Webserver von der Konfigurationsanpassung in Kenntnis zu setzen. Bevor wir dies aber tun, überprüfen wir noch, ob die Konfigurationsdateien unseres web-Servers noch irgendwelche syntaktischen Fehler haben. Hierzu benutzen wir folgenden Aufruf.
# apachectl -t
Syntax OK
Da kein Syntax-Fehler gefunden wurde, führen wir einen Reload unseres Apache-WEB-Servers durch.
# systemctl reload httpd.service
Im Journal wird uns der Neustart entsprechend dokumentiert.
Feb 07 17:10:29 vml000081 systemd[1]: Stopping The Apache HTTP Server...
Feb 07 17:10:29 vml000081 systemd[1]: httpd.service: Deactivated successfully.
Feb 07 17:10:29 vml000081 systemd[1]: Stopped The Apache HTTP Server.
Feb 07 17:10:29 vml000081 systemd[1]: httpd.service: Consumed 1.032s CPU time over 5h 59min 5.170s wall clock time, 7.6M memory peak.
Feb 07 17:10:29 vml000081 systemd[1]: Starting The Apache HTTP Server...
Feb 07 17:10:29 vml000081 systemd[1]: Started The Apache HTTP Server.
Rufen wir zum Testen die Adresse vml000081.idmz.nausch.org auf, damit wir unsere zuvor angelegte Startseite zu Gesicht bekommen.
Im Zugriffs-Log/var/log/httpd/access_log sehen wir dann auch den Zugriff auf unsere Startseite index.html.
Der HTTP-Statuscode404 (Not Found) besagt, dass die Ressource favicon.ico nicht gefunden und somit übermittelt werden konnte. Dies ist natürlich in unserem Beispiel korrekt, da wir diese Datei nicht angelegt bzw. in das betreffende Verzeichnis kopiert hatten.
Im nächsten Beispiel rufen wir eine nicht existierende Datei oder Verzeichnis im Browser auf unserer Homepage auf.
Hinter dem link Webmaster versteckt sichg dabei die von uns definierte Adresse bei der Konfigurationsoption ServerAdmin webmaster@nausch.org.
Unter der URLvml000081.idmz.nausch.org wird uns die Apache Version und das Betriebssystem unseres HTTP-Daemon angezeigt. Dies wollen wir so natürlich in unserer Produktivumgebung nicht sehen. Wir werden das nun im nächsten Schritt entsprechend deaktivieren.
default settings des Apache HTTP Server httpd-default.conf
In unserer Produnktionbsumgebung wollen wir nicht relevante Details verbergen, so z.B. welche Version wir beim Apache Webserver verwenden. Dies kann z.B. auch mit folgendem Test verifiziert werden:
# curl -I http://vml000081.idmz.nausch.org
HTTP/1.1 200 OK
Date: Sat, 07 Feb 2026 17:33:11 GMT
Server: Apache/2.4.66 (Unix)
Last-Modified: Sat, 07 Feb 2026 16:01:49 GMT
ETag: "1cb-64a3e05fe539f"
Accept-Ranges: bytes
Content-Length: 459
Content-Type: text/html
Dies stellen wir nun ab, indem wir die Option ServerTokens Prod setzen.
# vim /etc/httpd/conf/extra/httpd-default.conf
#
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minor | Minimal | Major | Prod
# where Full conveys the most information, and Prod the least.
#
# Django : 2026-02-07
# default: ServerTokens Full
ServerTokens Prod
Bevor wir nun die Änderungen scharf schalten, prüfen wir vorab noch, ob sich nicht doch beim Bearbeiten der Konfigurationsdatei ein Fehler eingeschlichen hat.
# apachectl -t
Syntax OK
Wir können also getrost den HTTP-Daemon neu stzarten.
# systemctl restart httpd.service
Nun fragen wir erneut ab:
# curl -I http://vml000081.idmz.nausch.org
HTTP/1.1 200 OK
Date: Sat, 07 Feb 2026 17:38:30 GMT
Server: Apache
Last-Modified: Sat, 07 Feb 2026 16:01:49 GMT
ETag: "1cb-64a3e05fe539f"
Accept-Ranges: bytes
Content-Length: 459
Content-Type: text/html
Es wir ab sofort nur noch Server: Apache ausgegeben, also ohne die Versionsabgabe.
erster (named based) vHOST
Unser Web-Sever soll später für unterschiedliche (Sub-)Domains Seiten ausliefern. Wir werden hierzu Name based virual Hosts oder kurz vHOSTs einsetzen. Eine detaillierte Beschreibung hierzu findet man unter anderem auch in der Beschreibung zu Unterstützung namensbasierter virtueller Hosts.
Im folgendem Konfigurationsbeispiel wollen wir für den Hostnamen vhost-beispiel.nausch.org und vml000081.idmz.nausch.org unseren Webserver so konfigurieren, dass dieser unterschiedliche Inhalte ausliefert für die beiden vHosts ausliefert.
Zunächst legen wir uns auf unserem Server zwei Verzeichnisse für die beiden vHosts an.
# mkdir /srv/http/vhost1
# mkdir /srv/http/vhost2
In das erste Unterverzeichnis verschieben wir nun die in diesem Beispiel erstellte Datei index.html.
# mv /srv/http/index.html /srv/http/vhost1/
Im anderen Unterverzeichnis legen wir eine neue Index-Datei an.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>Apache httpd, "der" WEB-Server - Installation unter Arch Linux</title></head><body><p>Dies ist die <b>index.html</b>-Startseite unseres zweiten vHosts unseres Web-servers.<br><br>
Weiter Informationen zum Apache-Webserver unter Arch-Linux finden wir im <ahref="https://dokuwiki.nausch.org/d </p></body></html>
Über unseren eigenen DNS-Server haben wir bereits gesorgt, dass beide Testdomains im DNS gefunden und eine Adresse dazu ausgegeben wird.
# dig +short vhost-beispiel-1.nausch.org
10.0.0.81
und
# dig +short vhost-beispiel-1.nausch.org
10.0.0.81
Was wir nun brauchen, ist die entsprechende Konfiguration(sdatei) für dieses Beispiel. Durch die Directive IncludeOptional am Ende der Konfigurationsdatei /etc/httpd/conf/httpd.conf werden alle Dateien mit der Erweiterung .conf in alphabetischer Reihenfolge eingebunden.
Ob wir nun eine Datei mit allen vHost-Definitionen anlegen, oder ob diese in einzelne Dateien aufgesplittet werden, ist letztendlich egal. Die Trennung in einzelne Konfigurationsdateien hat den Vorteil, dass man so leichter den Überblick bei vielen vHosts behält und man so leicht einzelne vHosts schnell deaktivieren kann, in dem man die Konfigurationsdatei umbenennt, oder in ein anderes Verzeichnis verschiebt. Der Namensteil 80 symmbolisiert dabei auch den HTTP-Port 80.
Wir legen uns also für unseren ersten Host eine Datei an.
# vim /etc/httpd/conf/conf.d/80_vhost_beispiel_1.conf
Nun ist es an der Zeit, unseren Webserver von der Konfigurationsanpassung in Kenntnis zu setzen. Bevor wir dies aber tun, überprüfen wir noch, ob die Konfigurationsdateien unseres web-Servers noch irgendwelche syntaktischen Fehler haben. Hierzu benutzen wir folgenden Aufruf.
# apachectl -t
Syntax OK
Da kein Syntax-Fehler gefunden wurde, führen wir einen Reload unseres Apache-WEB-Servers durch.
# systemctl reload httpd.service
Da jeder vHOST die Zugriffe bzw. die Fehler in separate Logdateien schreibt, haben wir es bei der Fehlersuche oder Auswertung der einzelnen Kunden-vHOSTS einfacher, als bei großen Dateien, in die jeder einzelne vHOST schreiben würde.
Eine ausführliche Beschreibung und Dokumentationder einzelnen Konfigurations-Directiven und -Optionen findet man in der Apache-Dokumentation zu virtuellen Hosts.
named based default vHOST
Setzen wir name-based-virtual-hosts ein, überprüft unser Webserver, ob im Request die IP-Adresse des Servers verwendet wurde. Anschließend werden dann alle <VirtualHost>-Abschnitte mit der benutzten IP-Adresse verglichen und geprüft, ob der gewählte Hostname zu einem ServerName oder der ServerAlias-Anweisung übereinstimmt. Bei einem positiven Ergebnis wird dann die konfiguration dieses vHOSTs verwendet, wie. z.B. in dem vorherigen Konfigurationsbeispiel. Wird jedoch kein passender vHOST gefunden, so wird die Konfiguration des ersten vHOSTS verwendet!
Wichtig
Da wir alle unsere vHOSTs in jeweils eigenen Dateien konfigurieren, ist es notwendig, dass wir dafür sorgen, dass die Konfigurationsdatei ganz am Anfang des Verzeichnisses steht, da der Apache-Webserver, die einzelnen Konfigurationsdateien im Verzeichnis /etc/httpd/conf.d/ in alphabetischer Reihenfolge einliest. Wir erreichen das ganz einfach, in dem wir dem vHOST eingfach eine 10 im Dateinamen vorne an stellen.
Für diesen speziellen Fall können wir auch eine eigene spezielle vHOST-Konfiguration definieren, nämlich den _default_-vHOST. Nähere Hinweise hierzu findet man in der Beschreibung zuUsing _default_ vhosts.
Wir legen uns also hierzu einen speziellen vHOST an.
# vim /etc/httpd/conf/conf.d/10_default_vhost.conf
Auch hier testen wir, o sich nicht irgendwo ein Schreibfehler eingeschlichen hat.
# apachectl -t
Syntax OK
Anschließend führen wir einen reload unseres Servers durch, damit dieser die Konfigurationsdateien neu einliest.
# systemctl reload httpd.service
Authentifizierung für geschützte Bereiche
Nicht immer wollen wir Inhalte die unser WEB-Server zur Verfügung stellt, allen Besuchern zugänglich machen. Bestimmte vertrauliche Daten, sollen oft nur einem gewissen Teilnehmerkreis angeboten werden. Diese Besucher müssen sich dann mit Hilfe eines Namens und eines zugehörigen Passwortes zu erkennen geben.
Basic Authentifikation
Die einfachste Variante zum Anmeldevorgang ist die Variante PasswordBasicAuth. Die berechtigten Nutzer und die zugehörigen Passwörter sind in einer Konfigurationsdatei, die sich außerhalb des Webserverspeicherbereichs kurz DocumentRoot befindet.
Mit Hilfe des Befehls htpasswd aus dem Archlinux-Paket apache verwalten wir die entsprechenden Userdaten.
Haben wir noch keine Passwort-Datei angelegt, generieren wir dies mit folgendem Aufruf. Ob man nun einen Usernamen oder eine eMail-Adresse zur Authentifizierung verwenden ist egal.
Das Passwort, welches wir 2x eingegeben hatten, wird standardmäßig als MD5-digest mit einem 32 salt gespeichert. Man erkennt dies an der Zeichenfolge $apr1$.
Legt man Wert auf höhere Sicherheit nutzt man statt MD5-gehashten Passwörtern z.B. die sicherere die bcrypt-Verschlüsselung der Passwörter.
Die Option -c kennen wir bereits, sie besagt dass eine neue .htpasswd-Datei angelegt werden soll. Mit den Parametern B geben wir an, dass zum Hashen der Passwörter die bcrypt-Verschlüsselung verwendet werden soll. Der Parameter C 7 wiederum definiert die für den bcrypt-Algorithmus verwendete Berechnungszeit, je höher der Wert um so sicherer, was aber bedeutet dass dies entsprechend länger dauert. Der Standard ist der Wert 5, gültige Angaben finden sich zwischen 4 bis 17.
Haben wir alle Benutzer angelegt, geht es nun weiter mit der Konfiguration unseres vHOSTs. Wir sorgen nun dafür, dass für den Besuch unseres zuvor eingerichteten vHost vhost-beispiel-2.nausch.org sich der Besucher outen muss, laso sich mit Benutzernamen und Passwort anmelden muss.
Wir tragen hierzu nun folgende Zeilen nach.
# vim /etc/httpd/conf/conf.d/80_vhost_beispiel_2.conf
Richtig, wie immer prüfen wir unsere Konfiguration auf mögliche Tippfehler bevor wir unseren Apache Webserver neu starten, damit dieser von den Konfigurationsänderungen erfährt!
# apachectl -t
Syntax OK
Damit unsere Änderungen aktiv werden bedarf es noch eines Reloads unseres HTTP-Daemon.
# systemctl reload httpd.service
WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!
Rufen wir erneut unsere Testseite auf unserem vHost auf, werden wir nun aufgefordert uns anzumelden.
Fehleingaben werden dabei im Error-Log des betreffenden vHosts protokolliert.
# less /var/log/httpd/vhost-beispiel-2.nausch.org_error.log
[Sat Feb 07 21:25:23.199843 2026] [auth_basic:error] [pid 10129:tid 10182] [client 10.0.0.110:54730] AH01617: user django: authentication failure for "/error/HTTP_UNAUTHORIZED.html.var": Password Mismatch
Digest Authentifikation
Eine weitere und erheblich sicherere Methode, gegenüber der Basic Authentifizierung mit Hilfe einer .htpasswd-Datei ist die Digest Authentifizierunghtdigest.
Bei der Benutzerauthentifizierung .htpasswd werden die zur Anmeldung nötigen Daten in Klartext übermittelt, also z.B. für den Nutzer django auch das Passwort 12qwasyx!
Im Gegensatz dazu wird bei der Authentifizierung mit Hilfe von htdigestKEINE Anmeldedaten in Klartext übermittelt, sondern ein MD5-Hashwert, der mit den Anmeldedaten erzeugt wird.
Wir erstellen und nun zuerst einmal die nötige Datei /etc/httpd/conf/.htdigest' mit folgendem Befehl. Dabei benutzen wir folgende Optionen:
-c : Erstellt eine neue Passwort-Datei mit dem nachfolgenden Dateiname.
nausch.org : Dies beschreibt den realm (weitere Informationen findet man u.a. dazu bei Wikipedia)
django : Benutzername der bei der Anmeldung verwendet wird.
-rw-r----- 1 http http 71 Feb 7 21:18 /etc/httpd/conf/.htdigest
Damit unser Apache HTTP Server die Digest Authentifizierung auch anbieten und nutzen kann, müssen wir jetzt noch dafür sorgen, dass das Apache HTTP Server-Modul mod_auth_digest geladen und verwendet wird.
Auch in diesem Beispiel kontrollieren wir noch, ob sich nicht doch unter Umständen ein Tippfehler in unserer Konfiguration versteckt hat.
# apachectl -t
Syntax OK
Nun brauchen wir zum Schluß nur noch unseren HTTP-Daemon einmal durchstarten, damit er von unserer Konfigurationsänderung Bescheid weiß.
# systemctl reload httpd.service
Rufen wir erneut unsere Testseite auf unserem vHost auf, werden wir nun aufgefordert uns anzumelden.
LDAP(s) Authentifikation
… coming soon!
Logging
Ausnahme eines Hosts/IP-Adresse
Soll eine IP-Adresse bzw. ein Host vom Logging ausgeschlossen werden, verwenden wir folgendes Konfigurationsbeispiel, welches wir beim betreffenden vHost eintragen.
# vim /etc/httpd/conf/conf.d/80_vhost_beispiel_1.conf
Greifen nun Hosts aus dem Intranet auf unseren Test-vHost zu, werden diese nicht mehr im zugehörigen access-Log keine Einträge mehr protokolliert, da als Quell-IP hier die IP-Adresse der internen Firewall FWC|FWI verwendet wird!
Server-Status und Server-Info
Im Abschnitt Konfigurationsverzeichnisse und -dateien hatten wir unter anderem die Konfigurationsdatei /etc/httpd/conf/extra/httpd-info.conf kurz betrachtet. Mit Hilfe dieser Konfigurationsdatei können wir über die URL-Ergänzungen /server-status und /server-info Status-Rückmeldungen und -Informationen des Servers, abrufbar machen. Dies wollen wir uns nun genauer ansehen.
Um Änderungen an der Konfigurationsdatei /etc/httpd/conf/extra/httpd-info.conf bei einem Update des Pakets apache besser verfolgen zu können, sichern wir zunächst diese Date, in dem wir eine Kopie davon erstellen.
Nun passen wir die Datei unseren Bedürfnissen nach an, folgende Anpassungen nehmen wir dabei vor.
Als erstes sorgen wir dafür, dass zum Auf- und Abruf der Informationen die dafür nötigen Module geladen und auch die Konfigurationsdatei /etc/httpd/conf/extra/httpd-info.conf includioert wird.
# vim /etc/httpd/conf/httpd.conf
...
# Django : 2026-02-08
# default: #LoadModule info_module modules/mod_info.so
LoadModule info_module modules/mod_info.so
...
...
# Real-time info on requests and configuration
# Django : 2026-02-08
# default: #Include conf/extra/httpd-info.conf
Include conf/extra/httpd-info.conf
...
Anschließend sorgen wir dafür, dass zum Auf- und Abruf der Informationen sich der Webmaster entsprechend authentifizieren muss. Hier greifen wir auf das Beispiel mit der Digest Authentifikation zurück.
## Get information about the requests being processed by the server# and the configuration of the server.## Required modules: mod_authz_core, mod_authz_host,# mod_info (for the server-info handler),# mod_status (for the server-status handler)## Allow server status reports generated by mod_status,# with the URL of http://servername/server-status# Change the ".example.com" to match your domain to enable.# Django : 2026-02-08# default: <Location /server-status># SetHandler server-status# Require host .example.com# Require ip 127# </Location>
<Location /server-status>
SetHandler server-status
AuthType Digest
AuthName nausch.org
AuthDigestDomain"/""http://.nausch.org/"AuthDigestProvider file
AuthUserFile conf/.htdigest
Require valid-user django
</Location>
## ExtendedStatus controls whether Apache will generate "full" status# information (ExtendedStatus On) or just basic information (ExtendedStatus# Off) when the "server-status" handler is called. The default is Off.## Django : 2026-02-08# default: #ExtendedStatus OnExtendedStatusOn## Determine if mod_status displays the first 63 characters of a request or# the last 63, assuming the request itself is greater than 63 chars.# Django : 2026-02-08# default: SeeRequestTail OffSeeRequestTailOn## Allow remote server configuration reports, with the URL of# http://servername/server-info (requires that mod_info.c be loaded).# Change the ".example.com" to match your domain to enable.## Django : 2026-02-08# default: <Location /server-info># SetHandler server-info# Require host .example.com# Require ip 127# </Location>
<Location /server-info>
SetHandler server-info
AuthType Digest
AuthName nausch.org
AuthDigestDomain"/""http://.nausch.org/"AuthDigestProvider file
AuthUserFile conf/.htdigest
Require valid-user django
</Location>
Damit unser laufender HTTP Daemon von der Änderung unserer Konfiguration Kenntnis erlangt, ist es notwendig diesen einmal zum Reload der Konfiguration zu veranlassen. Zuvor prüfen wir aber wie immer, ob sich etwaige Fehler bei der Konfiguration eingeschlichen haben.
# apachectl -t
Syntax OK
Anschließend reloaden wir den Pache Webserver neu.
# systemctl reload httpd.service
Bei Aufruf der URL-Erweiterungen können wir nun nach der Authentifizierung folgende Informationen erlangen:
/server-status : Statusinformationen zum Server bzw. virtuellen Host
/server-status?auto Erzeugen einer maschinell lesbare Ausgabe
/server-status?refresh=n : automatische Aktualisierung der Ausgabe alle n Sekunden
/server-info : Anzeige von Informationen zu Modulnamen, Konfigurationen, Hooks, Modulen und dem Server selbst
/server-info?config : Anzeige der Konfiguration inklusive aller inkludierten Konfigurationsdateien
/server-info?hooks : Anzeige nur der einzelnen Hooks, mit denen die Module verknüpft sind
/server-info?list : Anzeige einer einfachen Liste aller geladenen Module
/server-info?Modulname : Einschränkung der Anzeige von Informationen zu einem Modul mit dem angegeben Namen
/server-info?server : Anzeige von Grundinformationen des Apache HTTP Servers
Mit Hilfe des Apache-Moduls mod_http2 wurde diese Weiterentwicklung von HTTP, des weltweit erfolgreichsten Protokolls der Anwendungsschicht, implementiert. Es konzentriert sich dabei auf die effizientere Nutzung der Netzwerkressourcen und ändert nichts an den Grundlagen von HTTP, der Semantik. Es gibt immer noch Requests und Antworten, Kopfzeilen und die weiteren Grundlagen des HTTP-Protokolls. Weitere Informationen hierzu findet man auf der Howto-Seite der Apache Organisation.
Die Konfigurationsanpassung zu HTTP/2 werden in der Hauptkonfigurationsdatei /etc/httpd/conf/httpd.conf des HHTP-Daemon vorgenommen. Diese Erweitern wird nun wie folgt:
# vim /etc/httpd/conf/httpd.conf
...
# Django : 2026-02-08# default: #LoadModule http2_module modules/mod_http2.soLoadModule http2_module modules/mod_http2.so
...
...
# Django : 2026-02-08 # default: unset
<IfModule http2_module>
# Allows HTTP/2 negotiation (h2) via TLS ALPN for secure <VirtualHost>.# Allows HTTP/2 cleartext negotiation (h2c) upgrading from an initial # HTTP/1.1 connection or via HTTP/2 preamble checking (Direct mode, # see H2Direct: # https://httpd.apache.org/docs/current/mod/mod_http2.html#h2direct).
Protocols h2 h2c http/1.1# There is one more thing to ordering: the client has its own # preferences, too. If you want, you can configure your server to # select the protocol most preferred by the client:
ProtocolsHonorOrder Off
</IfModule>
...
Die Aktivierung erfolgt wie immer dem gleichen Schema, als erstes wird die Konfiguration des Apache HTTP Servers auf Vertipper gecheckt und anschließend erfolgt ein Reload des Daemon.
# apachectl -t && systemctl reload httpd.service
Syntax OK
Im Internet finden Sie viele (kostenlose) Tools, mit denen man nun schnell und einfach testen kann, ob eine Webseite per HTTP/2 aufgerufen werden kann, ein Beispiel hierzu ist die Seite von keycdn.com.
Komprimierte Kommunikation - mod_deflate
Konfiguration
Mit Hilfe des Apache HTTPD Server-Modul mod_deflate wird der DEFLATE-Ausgabefilter realisiert, der es erlaubt die Auslieferung von Inhalten zu komprimieren, bevor diese zum anfordernden Client gesendet werden.
Zum Aktivieren des Moduls ergänzen wir unsere Hauptkonfigurationsdatei unseres Apache Daemon wie folgt.
# vim /etc/httpd/conf/httpd.conf
...
# Django : 2026-02-08# default: #LoadModule deflate_module modules/mod_deflate.so LoadModule deflate_module modules/mod_deflate.so
...
...
# Django : 2026-02-08 # default: unset
<IfModule deflate_module>
# Compression is implemented by the DEFLATE filter. The following # directive will enable compression for all outgoing content.SetOutputFilter DEFLATE
# Exclude uncompressible browser via part of user-agent stringBrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Exclude compression of content that cannot be further compressed# based on the file type.
<IfModule setenvif_module>
SetEnvIfNoCase Request_URI \.(?:png|jpe?g|gif|tar|gz|zip)$ no-gzip
</IfModule>
<IfModule headers_module>
# The mod_deflate module sends a Vary: Accept-Encoding HTTP # response header to alert proxies that a cached response should# be sent only to clients that send the appropriate Accept-# -Encoding request header. This prevents compressed content# from being sent to a client that will not understand it.Header append Vary User-Agent
</IfModule>
</IfModule>
...
Die Aktivierung folgt auch hier wie immer dem gleichen Schema:
# apachectl -t && systemctl reload httpd.service
Syntax OK
Anpassung Logging
Beim Apache HTTPD Server-Modul mod_deflate können dem Logging Daten zu den ausgelieferten Bytes und den jeweiligen Komprimierungsgrad mitgegeben werden. Wir wollen also nun unser Logging entsprechend ergänzen. Hierzu erweitern wir die bestehende LOG-Direktive des Apache HTTPD Server wie folgt.
# vim /etc/httpd/conf/httpd.conf
<IfModulelog_config_module>
## The following directives define some format nicknames for use with# a CustomLog directive (see below).#LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\"" combined
LogFormat"%h %l %u %t \"%r\" %>s %b" common
<IfModulelogio_module>
# You need to enable mod_logio.c to use %I and %O LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\" %I %O" combinedio
</IfModule>
## The location and format of the access logfile (Common Logfile Format).# If you do not define any access logfiles within a <VirtualHost># container, they will be logged here. Contrariwise, if you *do*# define per-<VirtualHost> access logfiles, transactions will be# logged therein and *not* in this file.## Django : 2026-02-08# default: CustomLog "/var/log/httpd/access_log" common# CustomLog "/var/log/httpd/access_log" common## If you prefer a logfile with access, agent, and referer information# (Combined Logfile Format) you can use the following directive.## Django : 2026-02-08# default: #CustomLog "/var/log/httpd/access_log" combinedCustomLog"/var/log/httpd/access_log" combined_deflate
# Django : 2026-02-08# default: unset
<IfModule deflate_module>
# You need to enable mod_deflate.c to use instream, outstream and ratio.DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\" %b %{outstream}n/%{instream}
</IfModule>
</IfModule>
Auch gilt, erst checken, dann reloaden!
# apachectl -t && systemctl reload httpd.service
Syntax OK
Ermittlung von remote IP-Adressen - mod_remoteip
Konfiguration
Mit dem Apache HTTPD Server-Modul mod_remoteip versetzen wir unseren Apache Webserver in die Lage, die ursprüngliche IP-Adresse eines Clients für die Verbindung durch die IP-Adressenliste des Useragenten zu ersetzen, die von einem Load Balancer oder einem HTTP-Proxy über die Anfrage-Header übermittelt wird.
Hierzu erweitern wir nun die Hauptkonfigurationsdatei unseres HTTP Daemon wie nachfolgend aufgezeigt.
# vim /etc/httpd/conf/httpd.conf
...
# Django : 2028-02-08 # default: #LoadModule logio_module modules/mod_logio.so # This module provides the logging of input and output number of bytes # received/sent per request. The numbers reflect the actual bytes as # received on the network, which then takes into account the headers and# bodies of requests and responses. The counting is done before SSL/TLS# on input and after SSL/TLS on output, so the numbers will correctly# reflect any changes made by encryption. LoadModulelogio_module modules/mod_logio.so
...
...
# Django : 2026-02-08 # default: #LoadModule remoteip_module modules/mod_remoteip.so # This module is used to treat the useragent which initiated the request# as the originating useragent as identified by httpd for the purposes# of authorization and logging, even where that useragent is behind a# load balancer, front end server, or proxy server. # The module overrides the client IP address for the connection with the# useragent IP address reported in the request header configured with# the RemoteIPHeader directive. LoadModule remoteip_module modules/mod_remoteip.so
...
Die Aktivierung folgt auch hier wie immer dem gleichen Schema:
# apachectl -t && systemctl reload httpd.service
Syntax OK
Logging
Wie auch schon beim Beispiel mod_deflate erfolgt die Anpassung beim Logging mit Hilfe der Konfigurationsdatei /etc/httpd/conf/httpd.conf im Abschnitt log_config_module.
# vim /etc/httpd/conf/httpd.conf
...
<IfModulelog_config_module>
## The following directives define some format nicknames for use with# a CustomLog directive (see below).#LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\"" combined
LogFormat"%h %l %u %t \"%r\" %>s %b" common
# Django : 2026-02-08# default: <IfModule logio_module># # You need to enable mod_logio.c to use %I and %O# LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio # </IfModule>
<IfModulelogio_module>
# This module provides the logging of input and output number of bytes received/sent per request.LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x %I %O" combined_ssl
LogFormat"%h %l %u %t \"%r\" %>s %b %{SSL_PROTOCOL}x %{SSL_CIPHER}x %I %O" common_ssl
</IfModule>
<IfModule setenvif_module>
# The mod_setenvif module allows you to set internal environment variables# according to whether different aspects of the request match regular# expressions you specify. These environment variables can be used by# other parts of the server to make decisions about actions to be taken,# as well as becoming available to CGI scripts and SSI pagesSetEnvIF User-Agent "HAProxy" dontlog=yes
</IfModule>
<IfModule remoteip_module>
# This module is used to treat the useragent which initiated the request# as the originating useragent as identified by httpd for the purposes of# authorization and logging, even where that useragent is behind a load# balancer, front end server, or proxy server.# The module overrides the client IP address for the connection with the# useragent IP address reported in the request header configured with the# RemoteIPHeader directive.# Additionally, this module implements the server side of HAProxy's PROXY# Protocol when using the RemoteIPProxyProtocol directive.
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.0.0.80
RemoteIPInternalProxy fd00::3:10:0:0:80
</IfModule>
<IfModulelogio_module>
CustomLog /var/log/httpd/access.log combined_deflate_ssl "expr=(reqenv('dontlog') != 'yes')"
</IfModule>
## The location and format of the access logfile (Common Logfile Format).# If you do not define any access logfiles within a <VirtualHost># container, they will be logged here. Contrariwise, if you *do*# define per-<VirtualHost> access logfiles, transactions will be# logged therein and *not* in this file.## Django : 2026-02-08# default: CustomLog "/var/log/httpd/access_log" common# CustomLog "/var/log/httpd/access_log" common## If you prefer a logfile with access, agent, and referer information# (Combined Logfile Format) you can use the following directive.## Django : 2026-02-08# default: #CustomLog "/var/log/httpd/access_log" combinedCustomLog"/var/log/httpd/access_log" combined_deflate
# Django : 2026-02-08# default: unset
<IfModule deflate_module>
# The mod_deflate module provides the DEFLATE output filter that allows# output from your server to be compressed before being sent to the# client over the network. You need to enable mod_deflate.c to use# instream, outstream and ratio.DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\" %b %{outstream}n/%{instream}n (%{ratio}n%%)" combined_deflate
LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x %b %{outstream}n/%{instream}n (%{ratio}n%%)" combined_deflate_ssl
</IfModule>
</IfModule>
...
Wie soll es anders sein, auch gilt, erst checken, dann reloaden!
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
Apache HTTP Server Project kann mit Fug und Recht von sich behaupten, der führende HTTP-Server im Internet. Im April 1995 startete das Projekt der pache-HTTP-Server („httpd“) und wird in diesem Jahr 2026 seinen 30 Geburtstag feiern! Das Ziel dieses Projekts ist es, einen sicheren, effizienten und erweiterbaren Server bereitzustellen, der HTTP-Dienste zeitgemäß den aktuellen HTTP-Standards bietet. Der freie und quelloffene Webserver wird von der Apache Software Foundation zur Verfügung gestellt, gepflegt und dort auch weiterentwickelt.
… coming soon! 
django