Apache web server administration. Apache Server Administration and E-Commerce Guide

So far our narrative has been limited to the simplest cases. This is when one instance is installed on one node machine Apache server and it only serves one IP address to handle user requests coming to a single Web site. In real practice, this option is unlikely. More likely, there are dozens if not hundreds of nodes, each with specific resource and configuration requirements.

The Apache server can be configured to support multiple IP addresses (see the BindA address and Listen directives). For each IP address, it can support multiple ports1. Each combination of attended IP addresses and ports has one or more nodes. This chapter details three methods for setting up an Apache server to host multiple nodes:

1. User home pages.

2. Virtual hosting by name.

3. Virtual hosting by IP address.

The first method - custom home pages - is the simplest, but it is unlikely to satisfy users who want to pay money for this service. This method creates user subdirectories in the User directory, and Apache redirects all requests for home pages to the user directories.

1 The terms IP address and port are discussed in detail in Appendix A, General Guidelines.

Shared hosting is an Apache server feature that allows one server to handle requests to many different Web sites. The server is configured in such a way as to distinguish requests for virtual nodes by name, IP address, or both. The Apache server can be configured so that different nodes are affected by different directives (and therefore behave differently). For these purposes, the virtualHost directive is used. By default, virtual nodes inherit the properties of the main server instance. However, almost all basic server directives can be either ignored or supplemented by the virtualHost directive.

Shared hosting is very popular for economic reasons. Tens to thousands of nodes with low to moderate traffic can be supported with just one physical node. It is recommended to register domain names. There is usually a charge for multiple names. Virtual hosting is carried out by name or IP address.

The second method, virtual hosting by name, involves associating multiple server names with a single IP address. As the shortage of IP addresses increases, the likelihood of using this method increases.

You probably already guessed that the third method, in shared hosting by IP address, is that one machine is a host for many IP addresses. Previously, this was the only method for multiple hosting and now it is still the only solution for handling traffic coming from older versions of browsers2. IP addresses can be associated with multiple network interface cards (NICs). On the other hand, modern operating systems allow you to support multiple IP addresses using a single network card.

For configuration changes to take effect, the Apache server must be rebooted as usual.

5.2. User Home Pages

This method uses the UserDir directive to place the URL in some directories on the system, as shown in Fig. 5.1.

5.2.1. UserDir some_directory directive

This directive is intended to indicate that Web content will be found in a specific subdirectory of the user's root directory. When this directive is running, the Apache server accepts requests in the form:

http://www.example.com/~userguy

and uses system resources to determine userguy's root directory. Let's say it is in the /home directory, so the path to root directory userguy will be /home/userguy. If a directive similar to

UserDir some_directory,

the Apache server will look for web content to be displayed in the some_directory subdirectory of the /home/userguy 3 directory. According to the logic of our example, this will lead to the directory

/home/userguy/some_directorу

2 Browsers that implement HTTP standards less than 1.1, for reasons that we will discuss later, cannot support hosting by name.

3 Default value public_html

Rice. 5.1. User Home Pages

5.2.2. Directive UserDir /an/absolute/path

There is a way to set the absolute path to a specific directory in which the Web content of all users is stored. This method assumes that each user has their own subdirectory in the directory specified by the UserDir directive. For example, if the Apache server receives a URL

http://www.example.com/~timmy/x flies.html,

when the UserDir /var/user/webspace directive is in effect,

then the server returns /var/user/webspace/timmy/x files.html

5.2.3. Directive UserDir /an/absolute/*/with/wildcard

Of all three options for the UserDir directive, this option is the most likely candidate for use. This method specifies the absolute path to the directory where users store their Web documents. Here, instead of the username, an asterisk “*” is indicated. And when the Apache server receives a request to a specific user

http://www.example.com/~susie,

it parses the username (indicated by the "~" character) and replaces the asterisk with the username. For example, if in currently The UserDir directive is valid:

UserDir /home/*/public_html,

the Apache server will redirect this URL to the /home/susie/public_html directory

5.3. IP addresses and ports

Before configuring shared hosting, you need to configure the server to listen on the appropriate ports. By default, the Apache server monitors the IP

port 80 for all IP addresses available on the server. Depending on the tasks facing the server, this may be sufficient. The directives described in this section will allow you to configure your addresses and monitor the port.

5.3.1. Determining IP addresses:

BindAddress address directive

The BindAddress directive tells the Apache server to monitor a specific IP address or a range of addresses. The following directive sets the Apache server to listen to the address 192.168.1.10:

BindAddress 192.168.1.10

To listen to all active IP addresses, you need to specify the command

5.3.2. Defining one IP$port: Port portnum directive

By default, the Apache server listens on IP port 80 of the given IP address. This is correct since port 80 is " standard port", defined by the HTTP protocol, and will therefore be accessed greatest number Web browsers.

On the other hand, you may need to change this standard installation and thus limit access to only those browsers that know the listening port. A typical example of such use of the Apache server is its use as a proxy server, and this mode of operation can also be useful for setting up a corporate intranet. Note that unlike the Listen directive (which will be discussed in the next section), only one Port directive can be applied at a time. For example, in order for the Apache server to start listening on port 4444, you need to set the directive

5.3.3. Defining one or more IP$ports: Listen directive

Unlike the Port directive, the Listen directive does not override other Listen directives. To have the Apache server listen on port 80 (HTML standard) and port (hypothetical local port), we will use a sequence of directives

In addition, the Listen directive can be used to determine IP addresses. Let's assume that the above example is listening on the IP address 192.168.1.2. The following Listen commands will have a similar effect:

Listen 192.168.1.2:80

Listen 192.168.1.2:

5.3.4. Configuring Multiple IP Ports

Two methods can be proposed to support multiple IP addresses on one system:

Buy and install several interface boards.

On some operating systems, you can use the ifconf ig command to set up monitoring of one interface card for multiple IP addresses.

It is quite obvious that the idea of ​​​​buying many interface cards does not need comment. The same cannot be said for using the ifconfig command. The ifconfig command (interface configuration) performs two functions:

Displays configuration information for an existing interface.

Change or add interface configuration information.

The first function has undeniable benefits, but does not relate directly to the server. To do this, just use the ifconfig command to determine the name of the required card.

/home/root> ifconfig eth0

The result will be the following response (depending on the system type, of course):

eth0 Link encap:Ethernet HWaddr 0 0: 2 0: 7 8: 1 7: 9 A: E B

inet addr:192.168.1.1 Beast:192.168.1.255 mask:255 . 255. 255. 0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:!

RX packets:260652 errors:0 dropped:0 overruns:0 frame:0

TX packets:565370 errors:0 dropped:0 overruns:0 carrier:0 collisions:0

On the other hand, the ifconfig command can sometimes be used to enter new information. Here is the team that creates virtual device eth0:l. It will monitor different IP addresses (192.168.100.2).

/home/root> ifconfig eth0:1 192.168.1.2 netmask 255 . 255. 255. 0

If configured successfully, et h0:1 behaves as if it were actually there, responding to pings and user requests as if you had actually spent $50 on a new card.

5.4. Shared hosting by name

Shared hosting by name is relatively new revision HTTP standard. With this method, many different domain names are associated with a single IP address. All domain names are registered and all requests are redirected to the same IP address. The server distinguishes one request from another by using the HOST header configured for each virtual host configured on the server.

This is without any doubt good decision somewhat reduced the rate of depletion of Internet address space. The only problem is that only browsers that comply with the HTTP 1.1 standard work with the HOST header. Therefore, accessing such virtual nodes using outdated browsers will be quite problematic.

The process of setting up such hosting can be divided into three stages:

Informing DNS that an existing IP address is also relevant to the name of the new virtual host.

Communicates to the Apache server how requests are routed to the virtual host.

5.4.1. Domain Name System and Name Registration

The Domain Name System (DNS) is a kind of analogue of the Inter net yellow pages. This is a distributed database of IP addresses and associated domain names. Without the domain name system or something similar, the Internet could not exist. Without a DNS database, a URL set in the browser is completely useless until the corresponding IP address is found in the DNS database.

Given the ongoing Internet extension, there are fewer and fewer good domain names left. All possible three-letter domain name combinations have already been exhausted, so there is no need to even worry about this. Most English words have already been used. Requests for new domain names can be sent to http://www.networksolutions.com (see Figure 5.2).

Rice. 5.2. Domain name registration

If you have Domain name which satisfies you in everything, then the worst is behind you. In common practice ordinary user It is not at all necessary to register your domain name yourself. For most, registering a DNS involves filling out a form and sending it to the appropriate ISP agents.

DNS is a distributed database, i.e. it cannot be found all at once on one server. A user's request may go through many servers before a match is found. A side effect is that registering a new domain name through the worldwide DNS network takes hours, and sometimes even days.

5.5. Setting up shared hosting by name on the Apache server

It’s good that virtual hosting by name is relatively painless. To do this, you only need to do two steps, although, frankly speaking, the second one can be difficult.

1. Using the NameVirtualHost directive, determine the IP address that will be used for virtual hosting.

2. Using a pair of Vir tualHost directives, select directives that will be relevant only to a specific virtual Web node.

5.5.1. IP assignment for virtual hosting named: NameVirtualHost

Using the NameVirtualHost directive, set the IP address of the virtual host in the httpd.conf configuration file. For example, a directive like

NameVirtualHost 192.168.1.1

will alert the Apache server that there is a possibility of receiving a request at 192.168.1.22 to servers other than standard server. In order for Apache to benefit from this information, virtualhost-specific directives must be specified using the VirtualHost parentheses.

The port number can be set using the NameVirtualHost directive.

NameVirtualHost 192.168.1.1:80

Virtual hosting by name only works for Web browsers that comply with the HTTP 1.1 standard or higher. The reason for this is that the HTTP 1.1 standard has a HOST directive that specifies the host name (and port). This is where the Web browser gets its information. Without this directive, the server will not be able to determine which Web site can be associated with the IP address requested by the user.

5.5.2. Starting virtual hosting: the VirtualHost directive

The VirtualHost directive is a "bracket operator". It is applied only in pairs and limits the beginning and end of directives that deal with virtual hosting. Continuing with the example, we have:

ServerName www.examplel.org

DocumentRoot/some/other/directory

Please note that directives inside parentheses , apply only to the virtual host specified by the ServerName directive. Directives enclosed in parentheses , cancels the default settings for that IP address. Limits on the number of directives that can be enclosed in operator brackets , No. But there are certain reasonable limits (see Table 5.1).

Table 5.1. Directives not applicable in shared hosting

5.5.3. Default virtual host

Usage keyword _default_ instead of an IP address indicates that the configuration information you specify will be used by default in the event that incoming requests cannot find the desired virtual node among the existing nodes. You don't have to do this, but once you do, you won't regret it. The current server configuration may be so simple that this is not needed at all, but still such standard approach may be quite useful.

Standard Directives...

5.5.4. IP$address or domain name?

If you take a closer look at the commands described in this chapter (VirtualHost, BindAddress, etc.), you will notice that many of them are more likely to resolve domain names than IP addresses. For example a set of directives

Various directives...

technically correct and indeed more readable than using an IP address. Unfortunately, this has a negative impact on performance. When hosting by name, the Apache server, each time it receives a request, will be forced to look for the given name in DNS, and this significantly slows down the work.

5.6. Virtual hosting by IP$address

IP-based virtual hosting does not expect user browsers to send a Host header (this is only true for HTTP 1.1 compliant browsers) and therefore, depending on the host's requirements, may not claim exclusivity. Here are the stages of the virtual hosting process by IP address:

1. Create and register a new virtual host name.

2. Configuring the system so that it can monitor new IP addresses (see the “IP Addresses and Ports” section in this chapter).

3. Setting the DNS connection between the new IP address and the host name.

4. A message to the Apache server about how to handle requests directed to the virtual host.

Most of these requirements have already been discussed. For information about how new hostnames are created and registered, see the "Shared Hosting by Name" section in this chapter. The procedure for creating a new name is similar. However, when registering a new virtual host name with using DNS you need to create a new IP address.

Configuring the system so that it can monitor new IP addresses is discussed in the “IP Addresses and Ports” section earlier in this chapter.

The main difference between configuring an Apache server for virtual hosting by name and virtual hosting by IP address is that in the second case you do not need to resort to the services of the NameVirtualHost directive. To create a node named www.example2.com at 192.168.1.2, you need to:

ServerNamewww.example2.com

5.6.1.Combining virtual nodes based on names and IP addresses

There is no reason that could prevent the combination of both approaches on one system. First, create all the required virtual hosting by address, and then match the addresses for the virtual hosting by name. If the NameVirtualHost directive has been applied at least once to a specific IP address, then this address will already be lost for the virtual hosting at that address.

5.7. What you need to configure for shared hosting

In all examples, directives are enclosed in parentheses intentionally. Technically, it is not at all necessary to indicate anything in parentheses, although it is completely pointless to specify them in the case when they do not contain anything. Several directives described in this section can be said to be specific only to shared hosting.

When configuring directives, you need to remember that virtual nodes do not follow the properties of the main Apache server. The virtual host configuration must override, extend, or replicate the master server configuration.

At a minimum, you must specify a ServerName directive for each virtual node:

ServerName www. site2. com

Another necessary element is the Docum entRoot directive, which specifies the starting point for any search. I think that in a situation where Web documents once personal clients separate directories are allocated, this will undoubtedly be appropriate.

DocumentRoot /home/site2

The Serve rAdmin directive allows you to specify the exact email address of the administrator of each virtual node. This is the address where mail will be sent with messages about problems that arise during the operation of the server.

ServerAdmin [email protected]

We can also mention the ErrorLog and TransferLog files, since their analysis simplifies debugging and traffic analysis. However, keep in mind that Unix systems (including Linux OSes) usually impose a limit on the number of files that individual processes can open. Assigning a separate log file to each virtual host can quickly exceed this limit. Unfortunately, I must ask you to consult your system documentation to find out how you can influence the restrictions imposed on each particular system. If you have any such suspicions, check your system's syslog file. Unix OS is very good at detecting this type of violation.

Summary

This book is intended to be a fairly comprehensive reference guide to the Apache Web server. The material presented in it assumes a certain level computer literacy, but knowledge network technologies it is not required. Despite the fact that the main issue of the book lies in the area ecommerce, the applications cover a wide variety of issues and information needed to create and operate a Web server. This is the problem of matching names and IP addresses, TCP/IP protocol details and syntax regular expressions. In addition, from the perspective of Web administration, the topics of creating a system are touched upon electronic payments and interaction with databases.

Apache

The Apache Web server has been called the crown jewel of the open source software movement. You can get it completely free. It has excellent performance and is therefore more widely used than all other Web servers combined. Currently, 61.5 percent of all Web sites in the world are built using the Apache server.

The proliferation of "open source systems" is much like the process of natural biological selection - all the Linux OSes and sendmail utilities of the world gradually fill the cover of Time magazine and are crushed by the advertising machine while legions of DOS utilities slowly but inexorably approach the /dev/ device. null history. Apache would never have been so popular if it didn't work reliably.

The Apache server has one more advantage that is not inherent in the others open systems: It is so simple that any sufficiently skilled user can master it in its entirety. God knows, I'm not a big Microsoft fan, but if I were given the task of choosing between Linux OS and Windows 2000 OS, I would instantly choose Windows before you could blink an eye. And, by the way, this should not be considered as disrespect for Linux: operating systems, in particular multi-user ones, are very complex. The only way to make them accessible to the average user is to simplify them.

Fortunately, the set of tasks that can be solved using the Apache server is not so wide. Those of you who begin learning a server with uncertainty and a sense of fear of new things will be relieved to know that the server configuration and maintenance procedures themselves are not very difficult. The essence of mastering a server, depending on your experience level, is to master the basic concepts of the operating system, master the commands that will help make the machine do what you want, and master the lingo. If you are an expert in one of these issues, you will find really a pleasant surprise.

Short story

The Apache server originates from the httpd server created by Rob McCall (Rob McCool) at the National Center for Supercomputing Applications (NCSA). In 1995, httpd was the most popular Web server then in existence, but when in 1994 McCall left NCSA, the development of the program froze. Therefore, to support and develop it, a small group of Web administrators rallied and formed the nucleus of an organization that is now well known as the "Apache group." Its members are

Brian Behlendorf (Brian Behlendorf)

Roy T. Fielding(Roy T. Fielding)

Rob Hartill (Rob Hartill)

David Robinson (David Robinson)

Clif Skolnik (Cliff Skolnick)

Randy Terbush (Randy Terbush)

Robert Thau (Robert S. Thau)

Andrew Wilson (Andrew Wilson)

In close cooperation with Eric Hagberg (Eric Hagberg), Frank Peters (Frank Peters) And Nicholas Pioch (Nicolas Pioch), "Apache group incorporated" published bug fixes for httpd 1.3, added several new features and in April 1995 released the next version of the server under the name Apache 0.6.2.

Since then, the "Apache group", as they soon became known, have devoted themselves to customizing and improving the software. There are now versions for almost all major operating systems, although the Unix platform is the undisputed leader among them.

At its core, the Apache Web server is end result grandiose joint work of a group of highly qualified programmers. A natural question arises as to what prompted them to work on Apache instead of developing regular commercial software for good money. You can quote the website here apache.org:

"The Apache server exists to provide reliable, commercial-grade solutions using HTTP protocol. It provides a platform on which individuals and organizations can build reliable systems for both experimental and mission-critical applications. We believe that the tools published on the Internet, falling into the hands of anyone or companies involved in the development of software products, will be able to help make money by creating Additional services to create specialized modules and provide services for technical support. We understand that "owning" the market is an economic advantage, and in the software industry this means that it is enough to control the receipt of payments from users of the software product. Typically, this state of affairs can be achieved by "owning" the protocol with which companies conduct their business. Because the protocols used on the Internet are "no man's land," it is still the domain of companies large and small. In this way, it seems possible to prevent "private ownership" of the protocol and ensure the existence of a reliable software product that uses the protocol, available absolutely free to all companies, and this cannot be underestimated."

Open source software

The Apache web server can easily be classified as one of the galaxy of so-called open source software products. Traditionally supplied archived application programs usually contain only executable object code, not source, from which the program was compiled. Apache and other similar products include in their distributions not only the executable object code, but also the source code from which the object code was created.

From the end user's point of view, this makes sense. For example, while working on this book, a lot of problems arose in our office. Large commercial software that ran on a large commercial operating system became unresponsive. It stopped responding to input. We tried to trace the stack and some other things, but, due to lack of source text, were unable to take any significant steps. Therefore, all possible diagnostics were removed and, together with the software, transferred to the supplier for analysis. Quite naturally, the problem was solved, but it took two weeks.

Therefore, it is a very complex procedure. If we worked with open software, then a solution would definitely be found much faster. And in this particular case, it was not clear what exactly the problem was, and even if we knew the reason, we definitely would not be able to fix it. We were completely at the mercy of our supplier.

Of course, working with “open systems” is somewhat unusual. Indeed, in the case of working with open source software, there is no one who would be directly responsible for maintaining the open version of the Apache server, no toll free number, which you can call at 2 a.m. if something happened to the server and you don’t know what to do. Support exists in the form of newsgroups and Web sites, but it comes when it is convenient for the person providing the support, not for the person who needs it.

Apache web server, like others software products class of "open source software" only benefit from their constant availability to the programming community. Because there are many more developers working on each "open source" project than even the richest corporation could hire, buggy code is discovered and fixed much faster.

Let me suggest that the quality plaintext usually higher than commercial products. After all, the main motivation of developers working on “open” products is the love of programming as a creative process. Thus, when working with “open products” you can get the most best samples programs. This is in stark contrast to a commercial product where the majority of work time is spent in meetings, telephone conversations and, ultimately, inventory of balances.

Structure of this book

The book is intended for Apache server administrators of various qualifications. Familiarity with the basic concepts used in the computer industry is expected. Special training not required for Web administration. For those who are completely new to the Apache server, there is a fairly large introductory section in which you can find everything you need to get up to speed as quickly as possible.

After familiarizing yourself with the basic concepts, you may be tempted to quickly implement a server feature or two (such as shared hosting). The chapters of this book are organized into independent individual essays devoted to the most various topics. And you can read them in any order.

Due to its openness to the world, the Apache server is constantly being improved. New features are offered and added every day. Sometimes it's an improvement basic functions servers, but most often - new or improved modules. For this reason, even experienced administrators must expand their areas of expertise from time to time. I hope this book has something of value to offer even seasoned Apache administrators.

Finally, the appendices discuss a variety of networking and programming topics. Many of these are not directly related to the Apache server, but since the Apache server requires a working network, your career as a Web administrator will likely require some knowledge of general network administration and programming. The apps aren't all-inclusive, but they can be very useful.

Part I, "Basics"

Part I covers basic concepts and techniques for administering the Apache server. It will walk you through the process of obtaining and installing an Apache server configured to suit your needs. If you are new to the Apache server, you will most likely need to read all four chapters in sequence, especially Chapter 1, “Basic Concepts.” The information contained in Chapters 1 through 4, along with the appendices, is enough to get any beginner started.

Part II, "Web Server Administration"

Part II describes more advanced features of the Apache server. And if you have mastered the basic server concepts, you can skip the chapters contained in this part. Each chapter was conceived as a self-contained essay on a topic that is evident from the chapter title itself.

Part III, "Electronic Commerce"

Part III discusses issues that are directly related to electronic commerce, interaction with databases, and mechanisms for making money using the Internet. The final chapter of this part is a case study on creating a commercial hub infrastructure.

Part IV, "Appendices"

The appendices contain information that is too specialized to be included in the rest of the book (such as directive syntax) or that could be described as related information (such as Appendix E, "Unix Concepts"). Some of them are presented in the form of short educational essays, others - as simple reference material.

How to use this book

In the material presented in the book, you can find examples of commands and configuration directives, usually accompanied by explanations and sometimes printouts. Detailed information There is no discussion about the syntax of directives and system commands in the main chapters. Such information can be found in the appendices, in particular in appendix A, “General Directives”, and B, “Other Directives”. Hopefully, by looking at a command that is unfamiliar to you, you can determine its use.

The success or failure of any given Apache server transaction depends on the server's internal configuration, the content being transferred, the operating system configuration, and the vagaries of network support services. Therefore, it is impossible to say with complete certainty whether the examples presented here will work on a specific machine. The author can only swear with full responsibility that they all worked for him.

In some cases, the initial theme of a particular chapter was established in the previous chapter. For example, the virtual hosts discussed in Chapter 8, “Security,” were discussed in Chapter 4, “Starting, Restarting, and Stopping.” If the meaning of a particular configuration directive is unclear, you may be advised to consult subject index or read about its purpose in previous chapters.

It should be emphasized that in the operating system command examples, preference is given to Unix OS commands in general and Linux OS commands in particular. There is no coincidence in this, because when writing this book, it was a Linux machine that was used as a test server, some of the work was carried out on Windows NT, Windows 95 and Mac OS X.

One of the Unix conventions that I am very proud of, but which cannot be found anywhere in the Apache server documentation, is the practice of declaring an environment variable. It can store a long way to the catalogue. In the book you can see the Unix OS system variable $APACHE, which stores the name of the directory in which the Apache Web server is installed. (This directory is referred to as ServerRoot in the configuration files.)

Typographical conventions

To display commands, directives, names and messages in Unix system a special font is used:

Example of a directive with parameters

Great examples configuration files usually allocated separately.

DirectiveA

DirectiveB

DirectiveC

DirectiveD

Finally, I have tried to subdivide the description of the directives using headings that make sense. While most Apache server directives have names that give enough experienced user a hint about their functions (for example, AddModule and Port), others relate to capabilities unique to the Apache Web server and are difficult to describe in twelve characters (for example, DocumentRoot).

All questions, comments, corrections or suggestions for improvements can be sent to: [email protected] .

Hydra

In lieu of an afterword, please accept my thoughts on the significance of the creature depicted on the cover of this book. This is a hydra, it was drawn by a guy named Tom Post (Tom Post). Mythological beasts have become a traditional theme for the cover design of books on open systems published by Prentice Hall. So Hydra is a pretty appropriate personification of Apache. After all, numerous Apache instances running simultaneously on one computer are very reminiscent of numerous hydra heads. Isn't that right? For such a successful choice of a mythological image with sharp teeth, I would like to thank my editor Miles Williams (Miles Williams), and also because he didn’t bother me with all sorts of unicorns, nymphs and other evil spirits.

HTTPS (HyperText Transfer Protocol Secure) is not an independent protocol, but a development of HTTP (HyperText Transfer Protocol) towards security. That is, a mechanism for encrypting transmitted data was added to regular HTTP. Encryption is implemented with using SSL(Secure Sockets Layer). How does this work in practice?

When connecting to the server via HTTPS protocol(standard TCP port 443), the browser and the server first say hello, exchange supported encryption algorithms, and agree on which algorithm they will use. The server gives it to the browser public key(certificate) that will be used for encryption. They agree on mutually beneficial cooperation in short. Usually they manage to come to an agreement and establish a secure connection. All this happens at layer six of the OSI model. And only after this does HTTP come into effect, which operates at the seventh application level.

To activate HTTPS support on an already installed Apache, you need: , , and (Or ).

Generating a self-signed certificate

We go to the Apache directory where the keys are stored.

# cd /etc/apache2/ssl

Create a self-signed certificate and new key servers without password:

# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
" \
-out citename-CA.crt

Command arguments:

We set access rights to the keys.

# chmod 600 /etc/apache2/ssl/*.crt

Setting up an apache server

Enable SSL support in the server options line. To do this, add -D SSL there

Virtual Host Configuration

Configure the virtual host file. A default virtual host is also possible if its support is enabled in Apache.

All that remains is to restart Apache

# /etc/init.d/apache reload

Configuring multiple virtual hosts to work with SSL

For example, there are three hosts with the same IP address: citename.ru, shop.citename.ru, cite-name.ru. For them, you need to create three sites with different content and access to them via HTTPS.

We create self-signed certificates for them.

# cd /etc/apache2/ssl
# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Sales/CN=citename.ru/emailAddress= This email address is being protected from spambots. You must have JavaScript enabled to view it. " \
-out citename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout shop-citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Sales/CN=shop.citename.ru/emailAddress= This email address is being protected from spambots. You must have JavaScript enabled to view it. " \
-out shop-citename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout cite-name-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=IT/CN=cite-name.ru/emailAddress= This email address is being protected from spambots. You must have JavaScript enabled to view it. " \
-out cite-name-CA.crt
# chmod 600 /etc/apache2/ssl/*.crt
# chmod 600 /etc/apache2/ssl/*.key

And we configure virtual hosts.

Apache Web Server Administration and E-Commerce Tutorial - Hawkins S. - 2001

This book was intended to be a fairly comprehensive Apache Web Server Reference Guide. The material presented in it assumes a certain level of computer literacy, but knowledge of network technologies is not required. Despite the fact that the main focus of the book lies in the field of electronic commerce, the appendices touch on a wide variety of problems and information necessary for creating and operating a Web server. These are the problem of name and IP address matching, TCP/IP protocol details and regular expression syntax. In addition, in the perspective of Web administration, the topics of creating an electronic payment system and interaction with databases are touched upon.

Hawkins, Scott.
Apache Web Server Administration and E-Commerce Guide.
Per. from English M.: Publishing house "William", 2001. - 336 p. : silt, - Paral. tit.eng.
ISBN 5-8459-0212-6 (Russian)
ISBN 0-13-089873-2 (English)
BBK 32.973.26-018.2.75
UDC 681.3.07
X68

PART I. BASICS
Chapter 1. BASIC CONCEPTS
Chapter 2. INSTALLING THE APACHE WEB SERVER
Chapter 3. CONFIGURING THE APACHE WEB SERVER
Chapter 4. STARTING, RESTARTING AND STOPPING THE SERVER

PART II. WEB-CEPBEPA ADMINISTRATION
Chapter 5. HOSTING MULTIPLE WEB NODES
Chapter 5. PROXT SERVERS AND CACHING
Chapter 7. REGISTRATION AND MONITORING
Chapter 8. SAFETY
Chapter 9. DYNAMIC WEB PAGES
Chapter 10. CONFIGURING SERVER PERFORMANCE
Chapter 11. ADDRESS REASSIGNMENT
Chapter 12. COMPOSITION OF THE MODULE

PART III. E-COMMERCE
Chapter 13. CASH PAYMENTS
Chapter 14. INTERACTION WITH DATABASES
Chapter 15. EXAMPLE OF A COMMERCIAL NODE

PART IV. APPLICATIONS
Appendix A. BASIC DIRECTIVES
Appendix B. OTHER DIRECTIVES
Appendix B. TCP/IP PROTOCOL CONCEPT
Appendix D. CONVERTING NAMES TO IP ADDRESSES
Appendix E. SOLVING PROBLEMS ARISING DURING NETWORK OPERATION
Appendix E. UNIX CONCEPT
Appendix G. WINDOWS NT CONCEPT
Appendix 3. HTTP STATUS CODES
Appendix I. REGULAR EXPRESSIONS
Appendix K. MOD_PERLAPI INTERFACE
Appendix L. PHP LANGUAGE OPERATORS

Subject index

Free download e-book V convenient format, watch and read:
Download the book Apache Web Server Administration and E-Commerce Guide - Hawkins S. - 2001 - fileskachat.com, fast and free download.

Download pdf
You can buy this book below best price at a discount with delivery throughout Russia.Buy this book