Apache configuration file. Apache Configuration Files
"a and SharePoint" in the context of this term. It all started when Bert Boerland stated in his blog that in the next 3 years (entry dated December 22, 2006) CMS will stand for “Community Management System”. Content ceases to be the key element of a successful website (both on the Internet and, with some delay, on the intranet).
This seems very logical to me. Now it’s not enough to “stuff” a website with useful, high-quality information. It is necessary to create a community around this information, thus increasing the involvement of site visitors in the process of creating content. An ideal system built on the principle of “content + community” will have positive feedback. The more people get involved in the community, the more content they generate, the more visitors the site attracts, the more people get involved in the community... the circle is complete. I intentionally leave quality issues outside the scope of this post. information content site, because they require separate discussion.
The topic of a new look at deciphering the abbreviation CMS was developed in his blog by Droui Buite, the leader of the Drupal project. From his point of view, CMS is a “Collaboration Management System”, i.e. collaboration management system. As an example, he cites SharePoint and its closest analogue with open source code– Alfresco system (the latter, however, lacks “portal” functions). Dree also complains that, unlike those two systems, Drupal does not support integration with office software such as MS Office and OpenOffice. The discussion continues in the comments to the post, but gradually slides into a banal holy war between SharePoint and Drupal lovers.
So what, in fact, is the difference between a content management system and a community management system or collaboration management system (the latter, to some extent, is a special case of the latter, most typical in a business environment)? In my opinion, the difference lies in the direction information flows. Traditional CMSs provide essentially unidirectional information transfer - from editor(he can be both the author and the “collector” of information) to to the reader(to the site visitor). The editor, among other things, must have the skills to enter and change information in the CMS used. As web applications using DHTML develop, the process of entering text into the system, even with complex markup, is greatly simplified, but the capabilities still fall short of full-fledged desktop office suites. What can we say about tabular data and graphical diagrams, which are very often used in the business environment. Manual page layout is often too difficult a task for most users.
All this does not allow us to establish a full reverse flow of information - from the reader to the site editor. As soon as we give the reader the opportunity (in this case, he already becomes participant) make your own changes, supplement and expand the content of the site using his usual means(and for most users this is, whatever one may say, an office suite), we will get a system collaboration, suitable for business needs. The casket, as you can see, opens simply.
So, to summarize:
- The content management system must ensure the flow of information from editor To to the reader. The collaboration system should provide a two-way flow of information - from the site to the participant, and from the participant to the site. Wherein technical means, with the help of which the user enters information into the system must, on the one hand, have wide functionality, and on the other hand, to be simple and/or familiar to the user.
- In order to make a “SharePoint killer”, you must first of all implement a simple, bug-free, transparent integration of the system with one or another (or better yet, both) office suite.
Configuring Apache
There are two ways to configure a Web server: change the variables that control the functioning of the main server, or create a virtual server. In our case, the second method is preferable. But more on this a little later, but for now let’s look at the basic directives that control the behavior of the server. Apache's main configuration is contained in the httpd.conf file, located in the directory:
C:\usr\local\apache\conf\
This is a regular text file, and any text editor is suitable for editing it - the same Notepad, for example. I will not talk in detail about every line in this file, but only about the most necessary and necessary directives for us. Note that the '#' sign is a comment, and if you read English well, you can easily decipher them, which, however, will not be very helpful if you do not at least have general idea about the principles of operation of Web servers and about the Internet in general. So let me offer you my help in setting up Apache. Together we will succeed faster and, most importantly, correctly.
The Apache configuration file consists of three large sections:
- Global Environment - directives that control Apache settings in general;
- Main server configuration - directives that control the main server settings;
- Virtual Hosts - directives that control virtual servers.
Section general settings we are not interested, since you are unlikely to ever have to change the values specified there, but we will examine the other two sections in more detail. More precisely, one of them - I will talk about useful directives used when configuring the parameters of the main server, since the same commands are used when configuring virtual hosts. The only difference is that undefined parameters are inherited from the main server settings. So, let's begin…
ServerName - name of the running Web server. It is returned to the client in the HTTP header and identifies the Web server that made the request. When the server actually operates on the Internet, the name must already exist and be registered in DNS. When installing a Web server locally for debugging and testing sites, this is not important - the name can be anything. By the way, this is the name that the installer requested before installation, so if you wish, you can edit it now. The parameter value must be defined for at least the master server. Otherwise Apache simply won't start.
ServerAdmin [email protected] - email address administrator, used in some automatically generated messages about Web server errors, such as a missing page, for example. The parameter must be defined for at least the main server, otherwise Apache will also refuse to start.
ServerRoot “c:/usr/local/apache” is the directory where Apache was located during installation. If you want to move it to another location, then this line will need to be adjusted, as well as all other lines in the file pointing to this directory. If you installed Apache as I described above, then this line will already be configured correctly and will point to c:/usr/local/apache.
Port 80 is the port on which Apache will monitor HTTP requests. By default, it is the default value for Web servers, and you are unlikely to need to change it.
DocumentRoot “c:/usr/local/apache/htdocs” - the address of the directory used to store HTML pages. Default this parameter points to the Apache documentation supplied with the distribution and located in the above directory.
UserDir “c:/usr/local/apache/users/” - directory used to store user pages, which can be accessed at:
Http://www.domain.com/~user/
Since we are installing a Web server for local debugging of sites, and not for actual work on the Internet, you do not need to change this line.
DirectoryIndex index.html index.htm is a parameter that specifies the name of the file that Apache will look for if an incomplete URL is specified. That is, one that ends with the name of the directory, and not the address of a specific page. This also applies to the file that opens by default when you type the main URL. For example, if you typed in address bar:
http://www.domain.com/links/,
then in fact Apache will open the page:
Http://www.domain.com/links/index.htm
The complete list of files that can be found in the directory is determined by this parameter. File names are separated from each other by a space. The order in which the alternative names are listed matters: if the directory contains files named both index.htm and index.html, then Apache will open the second page, since index.html is listed earlier than index.htm.
Alias /icons/ “c:/usr/local/apache/icons/” - a command for creating aliases, that is, links, for any directories. For example, the above command makes the contents of the directory “c:/usr/local/apache/icons/” available at:
http://www.domain.com/icons/
In this case, the directory itself can be located anywhere file structure and does not have to be a subdirectory of a previously defined directory for hosting HTML documents.
ScriptAlias /cgi-bin/ “c:/usr/local/apache/cgi-bin/” - this command is similar to the previous one with the only difference being that it determines the actual location of the directory with executed CGI scripts.
AddType text/html .html .htm - a command that determines the mime type for a file with a given extension. IN in this case we give the extensions.html and .htm the type of normal hypertext, and Apache will interpret it as html code. More precisely, the browser will have to interpret it - the Web server will only give it an indication that this is hypertext. But if this line is not there, then Apache will pass off pages with this extension as ordinary text files.
AddHandler server-parsed .shtml - a command that defines a handler (an automatically launched program) for a file with the specified extension. In this case, we associate the .shtml extension with the built-in SSI directive handler. And therefore, all files having this extension, before giving the page to the user, they will go through pre-treatment. More specifically, Apache will replace all SSI inserts with their corresponding values.
ErrorDocument 404 /error404.html - a directive that defines the page that will be sent to the user when an error occurs. In this case, a page was defined for the most common 404 error. This directive is optional, and if it is missing, Apache will generate a standard page. But you must agree that defining your own error page and, moreover, making it in uniform style the site is much more attractive. The path to the error page can be specified either locally (in which case it must start from the root of the site), or with the full URL of the page.
ErrorLog logs/error.log - a command that defines the name of the file where all errors that occur when loading pages or executing CGI scripts will be recorded. When debugging Web sites locally, this is an extremely useful thing. So if something goes wrong - Apache won't start, Perl scripts won't work, graphics on pages won't load - this file can help you figure out the problem.
CustomLog logs/access.log common - a directive similar to the previous one, but with the difference that it is used to log all requests to the Web server. Based on its analysis, you can get a full report on site traffic and the popularity of individual sections.
Now let's look at the settings of access rights to files and directories included in the structure of the Web site. For security reasons, we need to set a certain set of rights for any file or directory used to store pages or CGI programs. But first, let's look at how we can specify the folder or file(s) to which we assign rights. This is done using one of the following structures:
For the catalogue:
This lists all the directives that control directory access and options.
For file(s):
This lists all directives that control access to the file(s)
Directory and filename are substituted required values. Can be used regular expressions, which allows you to set rights for an entire group of files and/or directories.
The rights defined for a directory apply to all subdirectories included in it, unless the rights have been overridden for any of the subdirectories. Now we are considering a way to define rights in the main configuration file, but for the same purposes you can use local .htaccess files, which are located in the folder for which you want to restrict access. In some cases this is much more convenient. The syntax for writing commands in the .htaccess file is completely similar to the command syntax in the httpd.conf file.
It is important to note that configuring the behavior of the Web server using .htaccess is only possible if it is allowed in the rights of the parent directory. But I’ll say more about this when we get to the appropriate team. In the meantime, let's start by examining in order all the main directives used to determine rights:
- Options option_list - a directive that defines additional options for a specific directory. Options are separated from each other by spaces. The main ones are the following:
- None - no additional options are defined for this directory.
- All - all possible options are defined, with the exception of MultiViews.
- Indexes - an option that allows you to use default files if the address is incomplete. The default list of files is specified by the DirectoryIndex directive, which was described a little higher in this article. If there is no default file in this directory, Apache will return the contents of the directory to the browser.
- Includes is an option related to the functioning of SSI and allows the use of the Include directive. For SSI to function fully, the option must be enabled.
- IncludesNOEXEC - an option similar to the previous one, but prohibiting the use of SSI commands for launching a CGI script in inclusionsAnd.
- ExecCGI is an option that allows this catalog launching CGI programs.
- FollowSymLinks - an option that allows Apache to follow symbolic links in UNIX systems. That is, the page may be located outside the main tree defined for storing HTML documents.
- AllowOverride - a directive that allows you to override access parameters for underlying directories. What I talked about earlier. This command must be followed by a list of directives allowed to be overridden. For example, AllowOverride All - allows override of any rights, AllowOverride Options - allows override of options for a directory, AllowOverride None - prohibits override of rights.
- Order allow, deny - the order of imposing access rights to a file or directory from certain IP addresses or domain names. A mask can be used to filter out entire network segments. In this case, the sites to which access is allowed are first determined, and then those to which are denied. In the case of the Order deny, allow command, the opposite is true.
- Allow from - list of IP addresses or domain names from which access is allowed. A mask can be used to allow access to the site to a whole group of domains. For example, Allow from .com - allows access from all domains ending in .com. Allow from all - allows access to the site from anywhere on the Internet.
- Deny from - list of IP addresses or domain names from which access is denied. Just as in the previous case, a group of domains or an IP address mask can be specified.
These are, perhaps, all the main directives that are used when configuring Apache. If you want to know what everyone else is doing, then everything is in your power - the configuration file is perfectly commented and with a little diligence you will figure it out.
Now that Apache is configured and running in its basic configuration, and we are armed with knowledge of the basic directives, we are free to add support for other technologies - in particular SSI. If you carefully read the description of the commands for configuring Apache, then you probably already guessed that this technology SSI is enabled by specifying the following two directives:
AddType text/html .shtml AddHandler server-parsed .shtml
Add these two lines to the Document type section of the configuration file (or simply uncomment them) and adjust the default list of files by adding the name index.shtml there:
DirectoryIndex index.htm index.html index.shtml
Additionally, we need to define for the document directory the rights to use SSI inclusions in pages. To do this, you need to find and adjust the section that defines the rights for the root directory of documents. It should look like this:
Nothing else is required to support SSI technology, so let's move on to configuration virtual server.
As I said earlier, virtual servers are more convenient for creating and debugging sites on a local Web server than using the settings of the main Web server for this purpose. Firstly, it is very easy to add new virtual servers, and secondly, all settings related to this server, are located in one place, and thirdly, it is very easy to organize simultaneous support for several projects.
But before we configure the virtual server, let's create all the necessary directories. I recommend using the directory structure below for Internet projects. You can choose any other drive as your primary drive, but I will still use drive C for explanations.
- c:\web\ - directory used for Internet projects;
- c:\web\project\ - directory for our project, which we will call project;
- c:\web\project\website\ - site pages will be located here;
- c:\web\project\cgi-bin\ - CGI scripts in Perl can be placed here;
- c:\web\project\logs\ - this directory will contain the Web server log files.
As mentioned above, directives defined in the virtual host section override global values. But first you need to figure out how to determine yourself virtual host. This is done using the VirtualHost directive of the same name. Below is a snippet describing the virtual server for our project. Add it to the very end of the configuration file - this is where the section for defining virtual hosts is located. And then I'll give detailed explanations for each line:
Done? Great, let's move on to the comments! So, in the first line I defined the IP address through which the virtual host will be accessed. Since the local Web server is bound to the IP address 127.0.0.1, it is logical for virtual hosts to use the following IP addresses in order: 127.0.0.2, 127.0.0.3, 127.0.0.4, etc.
In the second and third lines, the administrator's e-mail and server name are redefined. It is not necessary to specify these directives, but they allow us to more conveniently organize work with the Web server, in particular, to make it so that the server can be accessed not by its IP address, but by the host name defined in this section, but I’ll tell you about this a little bit later.
Next comes an important line that defines the location of documents for our site. The recording format is completely similar to the base server. In the same way, aliases to CGI scripts and paths to log files have been redefined. Note that we used the directories we created a few paragraphs above as values.
After adding virtual Apache host You must restart for the changes to take effect. Our virtual host will now be available at 127.0.0.2. If something goes wrong and the server refuses to start, then look at what is written in the error.log file. Most likely, it will indicate an error in the syntax of the configuration file.
Remember, I promised to talk about how to make it so that you can also access the server by name? Now the time has come. We don’t need to change anything in the Web server configuration, but we will have to correct the internal Windows file, which determines the correspondence between local IP addresses and domain names. Depending on what system you are working on, this file may be in different places or may not exist at all (in which case you will need to create it manually). The file is called hosts and is located in the directory:
C:\windows\ - for machines with Win9x/Me system
C:\windows\system32\driver\etc\ - for machines with WinNT/2000 system
This directory may also contain a file hosts.sam (extension from the word sample - “example”), which can be renamed to hosts if the latter is missing. The hosts file is a regular ASCII text file and has a very simple format: each line consists of a local IP address and its corresponding domain name. For our case this file should look like this:
127.0.0.1 localhost apache 127.0.0.2 project
Notice that in the first line I defined two names for one IP address. Such a server can be accessed by any of these names. Alternative names must be separated by spaces.
To test our virtual server and configured SSI technology, we need to write a test page. To do this, in any text editor, create a file with the following content:
and save it as index.shtml. Also create a test.inc file with the following content:
Congratulations, SSI technology works!
Copy both files into the directory c:\web\project\website\, which is configured as the directory for our project documents, and type in the browser address bar:
http://project/
If you see a congratulations message in the browser, then everything is in order: SSI is working, and in addition, the new default extension - index.shtml - is also functioning. If something is not working correctly for you, carefully re-read the last few paragraphs again and make sure that you did everything correctly.
Apache is installed and configured - let's move on to installing and configuring PHP.
Installing PHP4 on Windows
We will install the latest version of PHP available at the time of writing this article, namely PHP4.0.4pl1. The address where it can be downloaded is indicated at the end of this article. The archive with this PHP distribution is also located on the CD included with the magazine.
The distribution is a regular ZIP archive, and you just need to unpack it into the desired folder. Guided by the same considerations that I gave when creating the Apache installation directory, let’s unpack the PHP distribution into the folder:
C:\usr\local\php4\
Go to the specified directory, find the php.ini-dist file there and, renaming it to php.ini, copy it to the root Windows directory(usually c:\windows). This file contains all the settings that control PHP behavior and is a plain text file. Since the default configuration is quite suitable for us, then this moment There is no need to change anything in this file.
Now you need to configure Apache and PHP to work together. There are two main ways to install PHP - as a regular CGI program and as an Apache module. We'll look at both and start by configuring PHP like a regular CGI program.
Installing PHP as a CGI program
The main configuration work will have to be done on the Apache configuration file. If you have already closed the httpd.conf file, then open it again and add a few lines related to the functioning of PHP. First we need to define a new file type and map it to the extensions used by PHP. To do this, add the following line to the “Document types” section:
Now you need to assign a handler for of this type files, so add the following snippet right after the type definition:
Finally, we will add the value index.php to the list of index files. To do this, find and correct the following line:
Everything you need PHP settings completed, and you can test the functionality of PHP. To do this, create a test file with the following content:
and save it as test.php in the directory c:\web\project\website\, which we previously defined to store our project's HTML files. Now, by typing the line in the browser:
http://project/test.php
Http://127.0.0.2/test.php,
we should see the congratulation text. If everything is in order, then you can finish configuring PHP. Otherwise, carefully check the above directives in the httpd.conf file. And don't forget to restart Apache before checking.
Installing PHP as a regular CGI program is quite simple, but it does not allow us to use some of the functions related to user authorization, permanent connection to databases, and a number of other features. Therefore, now we will look at a more preferable installation method - as an Apache module. This method provides noticeably faster performance due to the absence of overhead costs for launching an external CGI program. However, for our case - using a local Web server to test sites - execution speed is not critical.
Installing PHP as an Apache module
First of all, we need to find the compiled PHP module to connect it to Apache. If you installed PHP as I described earlier, then the file we need is located at:
C:\usr\local\php4\sapi\php4apache.dll
Copy this file one level up to the main PHP directory:
C:\usr\local\php4\
Now we need to configure some variables in the Apache configuration file. As with PHP installation in the form of a CGI program, you need to add a definition of a new document type to the Document types section:
AddType application/x-httpd-php .phtml .php
And also correct the line containing the list of index files:
DirectoryIndex index.html index.htm index.shtml index.php
Now the most important thing is to configure the loading of the module. Find the “Dynamic Shared Object (DSO) Support” section in the configuration file and add the following line to it:
LoadModule php4_module “from:/usr/local/php4/php4apache.dll”
Configuration can be considered complete. All that remains is to test the functionality of PHP. Just remember to save the file first and restart Apache. For testing, you can use the previously written test.php script. Type the line in your browser:
http://project/test.php
and make sure PHP is running successfully. If something is wrong, then carefully check the accuracy of the paths to the module you specified and whether it is actually located in the specified directory.
And a quick note for those who have already configured PHP as a CGI program and are now trying to install it as a module, do not forget to remove the section from the Apache configuration file that associates the file type handler with the CGI program. Indeed, in this case, all processing of php files is already handled by external module. I mean this snippet:
ScriptAlias “/__php_dir__/” “c:/usr/local/php4/” Action application/x-httpd-php “/__php_dir__/php.exe”
This is where we will end our article, leaving the description of the main PHP constructs until next time. I am of the opinion that it is easier to learn from real examples rather than from abstract constructions, so next time we will combine business with pleasure and, while studying PHP constructs, we will write a fully functional script - a guest book.
ComputerPress 7"2001
Apache is the most popular web server on the Internet, serving more than half of active sites.
In this article we will look at common configuration files and basic Apache settings on Ubuntu/Debian system
Note: Apache files differ depending on the distribution, so this article is not suitable for RHEL users.
Installing Apache on Ubuntu/Debian
If the Apache web server is not yet installed, use the commands:
sudo apt-get update
sudo apt-get install apache2
To verify that the installation was successful, open your browser to the IP address of your server. The Apache welcome page should appear on your screen:
It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.
Apache File Hierarchy
On Ubuntu and Debian, Apache stores configuration files in the /etc/apache2 folder.
cd /etc/apache2
ls -F
apache2.conf envvars magic mods-enabled/sites-available/
conf.d/ httpd.conf mods-available/ ports.conf sites-enabled/
This folder contains a number of simple text files and subdirectories. The most important of them:
- apache2.conf: main server configuration file. Almost all configurations can be performed in it.
- ports.conf: This file specifies the ports that virtual hosts listen on. Check this file when setting up SSL.
- conf.d/: This directory controls certain aspects of Apache configuration. For example, it is often used to define SSL configuration and standard security policies.
- sites-available/: This directory stores all available virtual hosts, which determine what content will be served on the site. These hosts are not active.
- sites-enabled/: This directory defines active virtual hosts. Typically it contains symbolic links to files defined in the sites-available directory.
- mods-/: These directories work in the same way as sites-available and sites-enabled. They store modules.
As you can see, Apache configurations are not limited to the main configuration file, but are distributed across several files and directories. This configuration structure can be expanded with new files.
Apache configuration file
Basic Apache settings are stored in /etc/apache2/apache2.conf.
This file contains three main sections: Apache global settings, default server settings, and virtual host configurations.
On Ubuntu and Debian, most of the file is dedicated to global settings, and the default server configuration and virtual host settings are handled at the end of the file using the Include directive.
At the end of the file you will find many Include settings. They define modules, add a ports.conf document, certain files from the conf.d/ directory and setting up virtual hosts from the sites-enabled/ directory.
Let's focus on the global settings of the Apache web server.
Apache Global Settings
This section examines important parameters global Apache settings.
Timeout
By default, this parameter is set to 300. This means that the server has a maximum of 300 seconds to complete each request. In most cases, this value is very large, and it is recommended to reduce it to 30-60 seconds.
KeepAlive
If this setting is On, the server will allow the client to request multiple objects within a single connection. If the parameter is set to Off, then each new request will create a custom connection. This behavior can lead to overload of a site with high traffic.
MaxKeepAliveRequests
This parameter allows you to define maximum amount requests for one connection. This allows you to increase Apache performance.
A value of 0 will allow the web server to process an unlimited number of requests within a single connection.
KeepAliveTimeout
This parameter sets the time interval between requests. If the client has not created another request within the specified time. The web server will terminate the connection. If this client subsequently makes a request, the server will create a new connection.
MPM Settings
To find out which modules Apache was compiled with, open a terminal and type:
apache2 -l
Compiled in modules:
core.c
mod_log_config.c
mod_logio.c
prefork.c
http_core.c
mod_so.c
As you can see, in this case the web server is compiled with the prefork.c module and the apache2.conf file.
Virtual Host Configurations
The default virtual host is located in the default file in the sites-available directory.
To see the general virtual host format, open this file:
sudo nano /etc/apache2/sites-available/default
ServerAdmin webmaster@localhost
DocumentRoot /var/www
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
. . .
By default, the virtual host processes requests on port 80.
This does not mean that the web server will necessarily process every request on that port. Apache can override configurations.
Top Level Virtual Host Settings
These settings are set in the Virtual Host section and apply to the entire virtual host.
The ServerAdmin parameter specifies the contact address Email, which will be used in case of problems on the server. This address can be pasted into the error page. To do this, the ServerSignature parameter (in the /etc/apache2/conf.d/security file) must be set to Email.
The ServerName directive specifies the domain name or IP address of the server. This is a per-virtual host setting that can override the default settings if it matches the ServerName value.
The ServerAlias parameter allows you to add site aliases - alternative names and paths leading to the same content. For example, a domain alias is often set to www.
DocumentRoot specifies the directory in which the web server stores the content of this virtual host. On Ubuntu, the default for this is /var/www.
Directory settings
The virtual host configuration has a special section for configuring the processing of individual file system directories. These settings can also be overridden.
First, the virtual host proposes a set of rules for the / directory (root directory). This section will provide basic virtual host configuration as it relates to all files that are served on the file system.
By default, Ubuntu does not impose any restrictions on the file system. Apache recommends adding a few standard access restrictions, for example:
Options FollowSymLinks
AllowOverride None
Order Deny,Allow
Deny from All
This will block access to all content unless subsequent directory definitions indicate otherwise.
The AllowOverride parameter allows you to override configurations using .htaccess files. To override settings, the .htaccess file must be in the content directory. By default this feature is disabled.
Alias and ScriptAlias settings
Sometimes the Alias and ScriptAlias parameters appear before the Directory section.
The Alias directive allows directories outside of DocumentRoot to be added to the content being served.
ScriptAlias works in a similar way, but contains the path to the directories with executable files.
For example, such a line in the virtual host for example.com will allow access to content in the /path/to/content/ directory when requesting example.com/content/.
Alias /content/ /path/to/content/
Remember that when opening access to additional directories, you need to set limited privileges on them.
Enabling Sites and Modules in Apache
Once you have created the virtual host file, you can enable it. To do this, you need to create a symbolic link to a file in the sites-enabled directory:
sudo a2ensite virtualhostfile
Once your site is enabled, restart Apache to allow the web server to re-read the configurations:
sudo service apache2 reload
To disable the virtual host, you need to remove the symbolic link from sites-enabled:
sudo a2dissite virtualhostfile
After this you need to restart the web server again:
sudo service apache2 reload
You can enable and disable the Apache module using the following commands (respectively):
a2enmod
a2dismod
They work the same as the previously mentioned a2ensite and a2dissite commands. After enabling or disabling the module, you need to restart the web server.
Conclusion
This article only covers the basic configuration of Apache web server files. Apache's feature set can be greatly expanded using modules.
If you need Additional Information about the web server, please contact
Apache is the most used Internet server on Linux systems. Internet servers are used to serve Internet pages upon request from client computers. Clients typically request and view Internet pages using Internet browser applications such as Firefox, Opera, Chromium or Mozilla.
Users enter a uniform resource locator (URL) to identify an Internet server by its fully qualified domain name (FQDN) and the path to the desired resource. For example, to see the home page of the Ubuntu website, the user must enter only the FQDN:
www.ubuntu.com
SymLinksIfOwnerMatch- Follows symbolic links if the target file or directory has the same owner as the link.
httpd settings
This section covers some basic configuration settings service httpd.
LockFile- The LockFile statement sets the path to the lockfile when the server is compiled with the USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT option. It must be saved on a local disk. It is worth leaving the default value unless the log directory is located on an NFS share. Otherwise, the original value should be changed to a local disk directory with read permissions only for root.
PidFile- the PidFile instruction sets a file in which the server writes its process ID (pid). This file should only be readable by root. In most cases, this parameter should be left unchanged.
User - User instructions sets the userid used by the server to respond to requests. This setting determines the server's access rights. Any files that are inaccessible to this user will also be inaccessible to visitors to your site. The default user is "www-data".
Group- the Group instruction is similar to the User directive. Group sets the group under which the server will respond to requests. The default value is also "www-data".
Apache2 modules
Apache2 is a modular server. This means that only the most basic functionality is included in the core of the server. Advanced features are available through modules that can be loaded into Apache2. Default basic set modules are included in the server at the compilation stage. If the server is compiled to use dynamically loaded modules, then the modules can be compiled separately and added at any time using the instruction LoadModule. Otherwise Apache2 must be recompiled to add or remove modules.
Ubuntu compiles Apache2 with the ability to load modules dynamically. Configuration directives can be included based on the presence of the corresponding module in the block
You can install additional Apache2 modules and use them with your Internet server. For example, run next command in the terminal to install the MySQL authorization module:
Sudo apt-get install libapache2-mod-auth-mysql
Look for additional modules in the /etc/apache2/mods-available directory.
Use the a2enmod utility to enable the module:
Sudo a2enmod auth_mysql sudo service apache2 restart
Similarly, a2dismod will disable the module:
Sudo a2dismod auth_mysql sudo service apache2 restart
Setting up HTTPS
Module mod_ssl adds an important feature for the Apache2 server - the ability to encrypt connections. So when your browser connects using SSL, the https:// prefix is used at the beginning URLs in the navigation bar.
Module mod_ssl available in the apache2-common package. Run the following command in a terminal to enable this module:
Sudo a2enmod ssl
The default settings for HTTPS are in the file /etc/apache2/sites-available/default-ssl. For Apache2 to provide HTTPS, key and certificate files are also required. Initial setting up HTTPS uses the certificate and key generated by the ssl-cert package. These are fine for testing, but must be replaced with a certificate that matches your site or server. For information on creating keys and obtaining certificates, see the Certificates section.
To configure Apache2 for HTTPS, enter the following:
Sudo a2ensite default-ssl
The /etc/ssl/certs and /etc/ssl/private directories are used by default. If you installed the certificate and key in other directories, be sure to change the SSLCertificateFile and SSLCertificateKeyFile options accordingly.
With Apache2 now configured to HTTPS, let's restart the service to allow the new settings:
Sudo service apache2 restart
Depending on how you issued your certificate, you may need to enter passphrase when Apache2 starts.
You can access the pages of the secure server by typing https://your_hostname/url/ in the address bar of your browser.
Record Sharing Rights
In order for more than one user to have write access to the same directory, you must grant write access to the group that unites them. Next example Grants write permission to the /var/www directory for the "webmasters" group.
Sudo chgrp -R webmasters /var/www sudo find /var/www -type d -exec chmod g=rwxs "()" \; sudo find /var/www -type f -exec chmod g=rws "()" \;
If access must be granted to more than one group per directory, use Lists controlled access(ACL).
Configuration files Apache
In most packages, Apache's main configuration file is named httpd.conf. Depending on the system version, this file may be located in different directories, but its format remains unchanged. On Caldera and SuSE systems, the httpd.conf file is located in the /etc/httpd directory; on Debian and Slackware it is located in /etc/apache (Slackware provides a sample file /etc/apache/httpd.conf.default; to ensure the server works, you just need to rename this file and make the necessary changes to it); On Red Hat and TurboLinux, the httpd.conf file is located in the /etc/httpd/conf/ directory.
As usual, lines in the httpd.conf file that begin with the # symbol contain comments. Options that define the server configuration are specified as follows:
Directive Meaning
A directive is a name that can have some value associated with it. The value can be a number, a file name, or an arbitrary character string. Some directives allow you to specify multiple suboptions. In this case, the directive name is placed in angle brackets. An example of such a directive is given below.
Options FollowSymLinks
AllowOverride None
IN last line contains the name of the same directive that is specified at the beginning, but no value is given for it. The name of a directive that ends a block is preceded by a slash.
In some cases, additional configuration files listed below are used to configure Apache. They are usually placed in the same directory as httpd.conf.
Access.conf. The link to this file is formed using the AccessConfig directive and is contained in the httpd.conf file. The access.conf file most often contains directives
Mime.types. To tell the Web browser how data should be processed, the Web server uses the MIME (Multipurpose Internet Mail Extensions) standard. For example, the MIME type text/plain means that the data is plain text, while image/jpeg specifies graphic data in JPEG (Joint Photographic Experts Group) format. The mime.types file contains information about the mapping between MIME types and file extensions. For example, filenames ending in .txt and .asc are associated with the MIME type text/plain . If this mapping is not set correctly, the Web browser will have difficulty processing some types of files. The file supplied as part of the package allows processing of almost any type of data that can be placed on a Web page. If you need to use rare types, you will have to add new entries to this file.
Magic. This file also allows you to define mappings between MIME types and data. When analyzing information, you can discover specific signs of one type or another. For example, many files contain special keys- "magic" byte sequences. These sequences, converted to text form, are specified in the magic file. Unless you have thoroughly studied the format of this file, it is not recommended to make changes to it. The structure of the magic file will not be discussed in this chapter.
From the Linux for the User book author Kostromin Viktor Alekseevich8.2.2. Basic configuration files If you have read Sect. 8.2.1 (or if you looked at the /etc/inittab file), then imagine that in a normal situation the init process, in addition to launching getty processes, performs 2 main actions: launches the rc.sysinit script from the /etc/rc.d directory; runs the rc script
From the book DIY Linux server author12.5. SSL and Apache 12.5.1. Installing SSL SSL (Secure Sockets Layer) is an encryption method developed by Netscape to provide Internet security. This method supports multiple encryption methods and provides both client-level and client-level authentication.
From the book Asterisk™: The Future of Telephony Second Edition author Meggelen Jim Wang From book Network tools Linux by Smith Roderick W. From the Linux book: Complete Guide author Kolisnichenko Denis NikolaevichDHCP Configuration Files Most Linux distribution packages include a DHCP server developed by the Internet Software Consortium (http://www.isc.org/products/DHCP/). The Internet Software Consortium (ISC) released version 3.0 of DHCP in late 2000, but in early 2002 many versions of Linux still shipped with old version 2.0
From the book Ubuntu 10. Quick Start Guide author Kolisnichenko D. N. From the book The C Language - A Guide for Beginners by Prata StevenExim Configuration Files Exim's main configuration file is called exim.conf. It is usually located in the /etc directory. This file contains entries in the following format: option = value As usual, lines containing comments begin with a # character.
From the book Linux through the eyes of a hacker author Flenov Mikhail Evgenievich From the book Development Linux kernels by Love Robert16.1. Installing Apache Depending on the distribution, the package from which the Apache web server is installed may be called apache or httpd, and the documentation package may be called apache-docs or httpd-manual, respectively. In the first case, you will need to install the apache-common package containing
From the author's book16.2. Apache setup. Configuration Files After installing Apache, you should edit the following files:? /etc/httpd/conf/httpd.conf - main configuration file. For Apache 2.x. this file may also be called httpd2.conf;? /etc/logrotate.d/apache or /etc/logrotate.d/httpd (in version 2.0) - rotation file
From the author's book16.10. SSL and Apache 16.10.1. Installing SSL SSL (Secure Sockets Layer) is an encryption method developed by Netscape to ensure secure data transmission. This method supports multiple encryption methods and provides authentication at both the client and client level.
From the author's book19.2. Bootloader Configuration Files Listing 19.1 shows the main GRUB2 configuration file - /boot/grub/grub.cfg. It cannot be edited manually. To create it, use the /usr/sbm/grub-mkconfig utility, which generates this configuration file on based on templates,
From the author's book26.2.3. Server Configuration Files Server configuration files are located in the /etc/apache2 directory. The main configuration file is called apache2.conf. Its default settings will suit most users. If you plan to use the Web server not only locally (for
From the author's bookSource files and executable files Our wonderful program, despite its brevity and simplicity, is a completely meaningless set of symbols for a computer, since it “does not understand” directives like #include or printf. He only understands a special language,
From the author's book5.3.1. Configuration files All SSH protocol configuration files are located in the /etc/ssh directory. Here you can see the following list:? SSH server configuration file - sshd_config;? SSH client configuration file - ssh_config;? key files for various
From the author's bookKernel Debugging Configuration Options There are several configuration options that assist in debugging and testing kernel code that are enabled at compile time. These options are available in the Kernel hacking item in the kernel configuration editor menu. All these