Sams Teach yourself Apache 2 in 24 hours note
1. By default Mac BigSur has the apache
run the command to verify: httpd -v
The installation path: /private/etc/apache2
The log location: /var/log/apache2
Document root: /Library/WebServer/Documents
2. httpd.conf
The ServerRoot directive takes a single argument: a directory path pointing to the directory where the server lives.
None disables per-directory files in that directory and any of its subdirectories. This improves performance and is the default Apache configuration.
1: <Directory />
2: AllowOverride none
3: </Directory>
3. control:
apachectl start/stop/restart/graceful
from the browser, http://localhost:80 will show "It works"
ErrorDocument 404 "Oops, we couldn't find your document!"
or
ErrorDocument 404 http://search.example.com
Alias /icons/ /usr/local/apache2/icons/
will cause a request for http://www.example.com/icons/image.gif to make Apache look for the /usr/local/apache2/icons/image.gif file.
4. reverse proxy
A reverse proxy is a Web server that sits in front of other Web servers, known as backend servers. The reverse proxy Web server can be configured to pass certain requests to the backend servers and return the result to the clients as if it were the reverse proxy that generated the content.
You can use the ProxyPass and ProxyPassReverse directives to map URLs in the reverse proxy to URLs in the backend servers.
In certain situations, the backend server might issue redirects. These redirects will include a Location: header that contains a reference to the backend server (backend.example.com). The ProxyPassReverse directive will intercept these headers and rewrite them so that they include a reference to the reverse proxy (rproxy.example.com) instead.
The previous examples could be rewritten as follows:
It is possible to prevent certain URLs from not being proxied by specifying an exclamation sign (!) as the remote site URL in ProxyPass directives. It is important that those directives are placed before other ProxyPass directives. For example, the following configuration will pass all requests to a backend site, except requests for images, which will be served locally:
5. SSL
If both sender and receiver share the same key, the process is referred to as symmetric cryptography. If sender and receiver have different, complementary keys, the process is called asymmetric or public key cryptography.
Public key cryptography takes a different approach. Instead of both parties sharing the same key, there is a pair of keys: one public and the other private. The public key can be widely distributed, whereas the owner keeps the private key secret. These two keys are complementary; a message encrypted with one of the keys can be decrypted only by the other key.
Anyone wanting to transmit a secure message to you can encrypt the message using your public key, assured that only the owner of the private key—you—can decrypt it. Even if the attacker has access to the public key, he cannot decrypt the communication. In fact, you want the public key to be as widely available as possible. Public key cryptography can also be used to provide message integrity and authentication. RSA is the most popular public key algorithm.
The SSL protocol uses public key cryptography in an initial handshake phase to securely exchange symmetric keys that can then be used to encrypt the communication.
SSL uses certificates to authenticate parties in a communication. Public key cryptography can be used to digitally sign messages. In fact, just by encrypting a message with your secret key, the receiver can guarantee it came from you. Other digital signature algorithms involve first calculating a digest of the message and then signing the digest.
Trust can be achieved by using digital certificates. Digital certificates are electronic documents that contain a public key and information about its owner (name, address, and so on). To be useful, the certificate must be signed by a trusted third party (certification authority, or CA) who certifies that the information is correct.
Certificates have a period of validity and can expire or be revoked. Certificates can be chained so that the certification process can be delegated. For example, a trusted entity can certify companies, which in turn can take care of certifying its own employees.
If this whole process is to be effective and trusted, the certificate authority must require appropriate proof of identity from individuals and organizations before it issues a certificate.
The main standard defining certificates is X.509, adapted for Internet usage. An X.509 certificate contains the following information:
Issuer: The name of the signer of the certificate
Subject: The person holding the key being certified
Subject public key: The public key of the subject
Control information: Data such as the dates in which the certificate is valid
Signature: The signature that covers the previous data
6.
To get a certificate issued by a CA, you must submit what is called a certificate signing request. To create a request, issue the following command:
You can also create a self-signed certificate. That is, you can be both the issuer and the subject of the certificate. Although this is not very useful for a commercial Web site, it will enable you to test your installation of mod_ssl or to have a secure Web server while you wait for the official certificate from the CA.
You need to indicate where to find the server's certificate and the file containing the associated key. You do so by using SSLCertificateFile and SSLCertificateKeyfile directives.
You can control which ciphers and protocols are used via the SSLCipherSuite and SSLProtocol commands.
The SSLMutex directive enables you to control the internal locking mechanism of the SSL engine.
asdf
a
sdfa
asdf
