Apache2 Ubuntu Default Page: It works Apache2 Ubuntu Default Page

 

Apache2 Debian Default Page

It works!

This is the default welcome page used to test the correct operation of the Apache2 server after installation on Debian systems. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server.

If you are a normal user of this web site and don't know what this page is about, this probably means that the site is currently unavailable due to maintenance. If the problem persists, please contact the site's administrator.

Configuration Overview

Debian's Apache2 default configuration is different from the upstream default configuration, and split into several files optimized for interaction with Debian tools. The configuration system is fully documented in /usr/share/doc/apache2/README.Debian.gz. Refer to this for the full documentation. Documentation for the web server itself can be found by accessing the manual if the apache2-doc package was installed on this server.

The configuration layout for an Apache2 web server installation on Debian systems is as follows:

/etc/apache2/
|-- apache2.conf
|       `--  ports.conf
|-- mods-enabled
|       |-- *.load
|       `-- *.conf
|-- conf-enabled
|       `-- *.conf
|-- sites-enabled
|       `-- *.conf
          

• apache2.conf is the main configuration file. It puts the pieces together by including all remaining configuration files when starting up the web server.
• ports.conf is always included from the main configuration file. It is used to determine the listening ports for incoming connections, and this file can be customized anytime.
• Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/ directories contain particular configuration snippets which manage modules, global configuration fragments, or virtual host configurations, respectively.
• They are activated by symlinking available configuration files from their respective *-available/ counterparts. These should be managed by using our helpers a2enmod, a2dismod, a2ensite, a2dissite, and a2enconf, a2disconf . See their respective man pages for detailed information.
• The binary is called apache2. Due to the use of environment variables, in the default configuration, apache2 needs to be started/stopped with /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not work with the default configuration.

Document Roots

By default, Debian does not allow access through the web browser to any file apart of those located in /var/www, public_html directories (when enabled) and /usr/share (for web applications). If your site is using a web document root located elsewhere (such as in /srv) you may need to whitelist your document root directory in /etc/apache2/apache2.conf.

The default Debian document root is /var/www/html. You can make your own virtual hosts under /var/www. This is different to previous releases which provides better security out of the box.

Reporting Problems

Please use the reportbug tool to report bugs in the Apache2 package with Debian. However, check existing bug reports before reporting a new bug.

Please report bugs specific to modules (such as PHP and others) to respective packages, not to the web server itself.

AdSense and SSL

Ad code SSL Review implementation

Does SSL negatively affect Adsense revenue?

Recently, I discovered that bloggers saw a significant hit to their Adsense revenue after switching over to SSL. This is because Adsense requires that SSL web sites also support SSL-compliant ads. Google maintains that most ads are compliant, but users across the Internet have reported widespread reductions to Adsense revenue.

Financial Samurai reported on this issue earlier in January: “I spoke to the folks at Adthrive, and they said they’ve seen publishers experience a 30% to 90% decline in ad revenue.” Ouch.

This used to be an issue in the past. I have no hard data that indicates one way or another whether this problem continues to exist.

My personal beef with the SSL rankings signal

I vehemently oppose using SSL as a rankings signal, for several key reasons:

1. It seems arbitrary. To reward or penalize a web site based on unrelated qualifiers to the search query and content quality seems wrong.
2. I reject the notion that SSL makes web sites safer. Like I mentioned in this blog post, SSL only encrypts data in transmission from Point A to Point B, which is a relatively tiny element of overall web site security. Developing secure web sites is a blindingly complex and sophisticated subject and cannot possibly be solved by slapping a certificate on to a web site. If only it were that easy.
3. It makes bloggers spend money for no practical benefit. Trusted SSL certificates are not free. Prices range from around $60 a year to hundreds of dollars (or thousands!) depending on the certificate’s capabilities. For bloggers who don’t transfer sensitive information, this is completely wasted money on a capability that provides very little benefit.
4. Encryption and SSL isn’t automatically “better”. I find it curious that many resources flatly state that SSL is nearly always better than non-SSL. Why? Because data is encrypted. Okay, so what? The vast majority of blogs do not require encryption and the overhead necessary to provide it. Whether this article was encrypted before it was sent to YOU is of very little concern to either of us!
5. Encryption takes CPU resources. Although the impact has been minimized with the influx of inexpensive high-powered computer hardware, SSL web sites require additional processing power to support encryption. For blogs that don’t need encryption, these are wasted resources.

Moreover, I find it shocking that people find it shocking that the large majority of web sites do not support SSL. The majority of web sites don’t support SSL because the majority of web sites simply do not need it, and the additional CPU resources it takes to establish and maintain the encrypted pathway for data that does not need encryption is simply not worth the price of admission.

 

AdSense ad code support for SSL

Next: AdSense code for dynamically generated pages AdSense ad code supports secure ad serving through Secure Sockets Layer (SSL) on all pages, including Hypertext Transfer Protocol Secure (HTTPS) pages. This means that publishers with secure sites, i.e., sites that are served over the HTTPS protocol, can use AdSense ad code to serve SSL-compliant ads. All sites should be secured with HTTPS — HTTPS provides critical security and data integrity both for your sites and for the people who entrust your sites with their personal information.

Some important things to know about the SSL-compatible ad code:

• HTTPS-enabled sites require that all content on the page, including the ads, be SSL-compliant. For most users, AdSense ad requests are always SSL-compliant and always served over HTTPS, even when the surrounding site is HTTP. The same ads compete in the auction, so switching your site to HTTPS will have no effect on the ads most users see, or on auction pressure. The only exception is for users located in countries that block or otherwise degrade HTTPS traffic.
  
• If your site can be accessed over HTTPS, then you may need to update older versions of AdSense ad code to avoid the AdSense script being blocked as mixed content. If your AdSense ad code has a script starting with "http://", then you should update it to "https://" instead:
  
  1. <script src="https://pagead2.googlesyndication.com/pagead/show_ads.js">
  2. <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js">
  The HTTPS version of the ad code is also safe for HTTP pages; you don't need to serve two different versions.
  
• The SSL-compatible ad code also works on HTTP sites and doesn’t change how ads are served on these sites.
  

How to use the SSL-compatible ad code

To use the new ad code on your HTTPS-enabled pages, use either of the options outlined here:

Option 1: Create new ad code

Generate your ad code, and then copy and paste the ad code into the HTML source code of your page where you'd like the ad to appear.

Option 2: Modify your existing ad code

To do this you'll need to make the following code change:

• Synchronous ad code
  <script>
  google_ad_client=“ca-pub-xxxxxxxxxxxxxx”;
  google_ad_slot=“yyyyyyyyyyy”;
  google_ad_width=300;
  google_ad_height=250;
</script>
<script src="//pagead2.googlesyndication.com/pagead/show_ads.js"></script>
• Asynchronous ad code
  <script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle"
  style="display:inline-block;width:300px;height:250px"
  data-ad-client="ca-pub-xxxxxxxxxxxxxx"
  data-ad-slot="yyyyyyyyyyy">
</ins>
<script>
  (adsbygoogle=window.adsbygoogle || []).push({});
</script>

In the examples above, “http” has been removed from both script sources. The source URLs now begin with two forward slashes, like this:

• Synchronous ad code: "//pagead2.googlesyndication.com/pagead/show_ads.js"
• Asynchronous ad code: "//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"