Install Awstats in Centos Web Panel (CWP) with Varnish+APACHE2

The domain we use is yourdomainname.com
login to shell as root

cd /usr/local/src
wget http://prdownloads.sourceforge.net/awstats/awstats-7.4.tar.gz
tar zxvf awstats-7.4.tar.gz
mv awstats-7.4 /usr/local/apache/htdocs
cd /usr/local/apache/htdocs/awstats-7.4/tools
perl awstats_configure.pl


-----> Running OS detected: Linux, BSD or Unix
Warning: AWStats standard directory on Linux OS is '/usr/local/awstats'.
If you want to use standard directory, you should first move all content
of AWStats distribution from current directory:
/usr/local/apache/htdocs/awstats-7.4
to standard directory:
/usr/local/awstats
And then, run configure.pl from this location.
Do you want to continue setup from this NON standard directory [yN] ? y

-----> Check for web server install
  Found Web server Apache config file '/usr/local/apache/conf/httpd.conf'

-----> Check and complete web server config file '/usr/local/apache/conf/httpd.conf'
  Add 'Alias /awstatsclasses "/usr/local/apache/htdocs/awstats-7.4/wwwroot/classes/"'
  Add 'Alias /awstatscss "/usr/local/apache/htdocs/awstats-7.4/wwwroot/css/"'
  Add 'Alias /awstatsicons "/usr/local/apache/htdocs/awstats-7.4/wwwroot/icon/"'
  Add 'ScriptAlias /awstats/ "/usr/local/apache/htdocs/awstats-7.4/wwwroot/cgi-bin/"'
  Add '<Directory>' directive
  AWStats directives added to Apache config file.


Do you want me to setup Apache to write 'combined' log files [y/N] ? --> N
(No, because we use custom varnish+Apache2+CloudFlare installed, so keep using varnishcombined as log format)
see this posting about varnish+cloudflare+apache2 before


-----> Update model config file '/usr/local/apache/htdocs/awstats-7.4/wwwroot/cgi-bin/awstats.model.conf'
  File awstats.model.conf updated.

-----> Need to create a new config file ?
Do you want me to build a new AWStats config/profile
file (required if first install) [y/N] ? y

-----> Define config file name to create
What is the name of your web site or profile analysis ?
Example: www.mysite.com
Example: demo
Your web site, virtual server or profile name:
> yourdomainname.com

-----> Define config file path
In which directory do you plan to store your config file(s) ?
Default: /etc/awstats
Directory path to store config file(s) (Enter for default): Enter!
>

-----> Create config file '/etc/awstats/awstats.yourdomainname.com.conf'
 Config file /etc/awstats/awstats.yourdomainname.com.conf created.

-----> Restart Web server with '/sbin/service httpd restart'
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]

-----> Add update process inside a scheduler
Sorry, configure.pl does not support automatic add to cron yet.
You can do it manually by adding the following command to your cron:
/usr/local/apache/htdocs/awstats-7.4/wwwroot/cgi-bin/awstats.pl -update -config=yourdomainname.com
Or if you have several config files and prefer having only one command:
/usr/local/apache/htdocs/awstats-7.4/tools/awstats_updateall.pl now
Press ENTER to continue...

A SIMPLE config file has been created: /etc/awstats/awstats.yourdomainname.com.conf
You should have a look inside to check and change manually main parameters.
You can then manually update your statistics for 'yourdomainname.com' with command:
> perl awstats.pl -update -config=yourdomainname.com
You can also read your statistics for 'yourdomainname.com' with URL:
> http://localhost/awstats/awstats.pl?config=yourdomainname.com

Press ENTER to finish...

cd /usr/local/apache/htdocs
chown -R nobody:nobody awstats-7.4

mkdir -p /home/roy/awstats
chown roy:roy /home/roy/awstats

cd /etc/awstats
nano awstats.yourdomainname.com.conf

Find DirData="/var/lib/awstats" and replace this with DirData="/home/roy/awstats"

Find LogFile="/var/log/httpd/mylog.log" and replace it with LogFile="/usr/local/apache/logs/access_log"

Find LogFormat, we use varnish modified apache logs (varnishcombine), so change this to:
LogFormat = "%host, %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

rm -rf /usr/local/apache/logs/access_log
service httpd restart

perl /usr/local/apache/htdocs/awstats-7.4/wwwroot/cgi-bin/awstats.pl -update -config=yourdomainname.com

check :
http://yourserverip/awstats/awstats.pl?config=yourdomainname.com
http://118.199.118.61/awstats/awstats.pl?config=yourdomainname.com

SSD server with 2GB of RAM and 50GB of storage for $3.40 per month (€2.99)

Online.net’s Scaleway is an interesting beast in the cloud hosting world. Instead of building a virtual cloud hosting infrastructure that competes directly with Amazon Web Services, DigitalOcean and other VPS providers, the company designed its own ARM-based servers.

And that’s why the company can drive the prices down so much. You can now get a BareMetal SSD server with 2GB of RAM and 50GB of storage for $3.40 per month (€2.99) — that’s 70 percent cheaper than Scaleway’s previous pricing of €9.99 per month.

The company has stated on Twitter that the new pricing applies to existing users as well. As a reminder, as ARM v7 chipsets were first designed for smartphones, it’s very easy to run many of them with very little power, cooling and space. Scaleway managed to squeeze 912 separate computers in a single server rack.

The company also kept the best of both worlds — dedicated servers with the flexibility of virtualization as you get 4 dedicated ARM cores, a dedicated IP and 200Mbit/s of unmetered bandwidth. Contrarily to many popular VPS providers, you won’t share your CPU raw power with other users.

Get Real IP Address in server traffic from CLOUDFLARE-->VARNISH-->APACHE2

How can I log the client IP address on the backend?

All I see is the IP address of the varnish server. How can I log the client IP address?

We will need to add the IP address to a header used for the backend request, and configure the backend to log the content of this header instead of the address of the connecting client (which is the varnish server).

Varnish configuration:

sub vcl_recv {
  # Add a unique header containing the client address
  remove req.http.X-Forwarded-For;
  set    req.http.X-Forwarded-For = client.ip;
  # [...]
}

For the apache configuration, we copy the “combined” log format to a new one we call “varnishcombined”, for instance, and change the client IP field to use the content of the variable we set in the varnish configuration:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishcombined

And so, in our virtualhost, you need to specify this format instead of “combined” (or “common”, or whatever else you use):

<VirtualHost *:80>
  ServerName www.example.com
  # [...]
  CustomLog /var/log/apache2/www.example.com/access.log varnishcombined
  # [...]
</VirtualHost>

Getting Varnish, CloudFlare and Apache to play nicely with X-Forwarded-For can be a pain. However not setting this up right can cause serious PHP session problems with HTTPS requests passed through Varnish and CloudFlare to Apache. It also makes it hard to consistently get the real IP of users connecting via HTTP. This tutorial is a quick run-down on getting all of these things to play nicely and relay the real IP.

Now lets move on the Varnish. Edit your /etc/varnish/default.vcl to contain the following:

sub vcl_recv {
remove req.http.X-Forwarded-For;
if (req.http.cf-connecting-ip) {
    set req.http.X-Forwarded-For = req.http.cf-connecting-ip;
    } else {
            set req.http.X-Forwarded-For = client.ip;
        }

Those two simple steps will get Varnish to relay the real IP from CloudFlare to Apache in the form of X-Forwarded-For or X-Real-IP consistently over either the HTTP or HTTPS protocol whether or not CloudFlare is enabled for a given website on the server. If you have any thoughts, leave them in the comments below.

Disable Wordpress Auto Update In the Middle of The Night

In case you haven’t noticed, WordPress auto-updates its core files by default. Neat but not always desired. Here is how to disable auto-updates with a few lines of code.

Rationale

Although WP’s auto updates are real neat, such functionality is not always desired. Like in the dead of night some script is changing stuff on your site with no humans to verify proper results. If something goes awry, it could leave your site down or even vulnerable for who knows how long until someone actually checks in to see what’s up. Avoid this scenario? Yes please. Read on to learn how (without a plugin)..

Disable auto-updates for the WordPress core

Add the following line to your site’s wp-config.php file:

define('WP_AUTO_UPDATE_CORE', false);
add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');