Redirect All HTTP Traffic To HTTPS (Port 443)

Redirecting website HTTP (port 80) traffic to HTTPS (port 443) is very easy under Apache.

  1. Open the website’s HTTP VirtualHost file.
  2. Inside the VirtualHost block, near the very end, add line (with your website’s primary domain name substituted in):
    Redirect / https://www.example.com/
  3. Also make sure the HTTPS VirtualHost file does not have a similar line in it that redirects back to HTTP, or your Browser will go into a loop.
  4. Save VirtualHost files. Restart Apache.
    1. For this to work correctly, without any Browser warnings, your website will need to have the proper SSL Certificates installed. Most Browsers will not allow you into a website that is using self-signed certificates (nor mismatched “Common Name” / domain name certs).

Installing WAMP on Windows Server 2012

Windows Server 2012 has several different installation types (the minimal “Server Core”, “Minimal Server Interface”, “Server with a GUI”, “Full”), and different options/features to select from.

Some features are required to run WAMP, while others have to be removed.

To be able to install and run Apache, MySQL, and PHP (i.e., WAMP) on Windows Server 2012, these are the minimal options/roles/features:

* .NET 3.5 is not absolutely required, as most .NET 3.5 applications can be ran under .NET 4.5 (i.e., the Windows Server 2012 default .NET verison).

If you have installed “Server Core”, you will need to switch/convert it to “Server with a GUI” (which can be done with a number of commands).

It is best to not have additional Roles installed, such as: “Web Server (IIS)”. As these Roles and Features will have Services and processes that take port 80 and 443, which Apache needs to run (check Disable Services that Interfere with Apache).

You will also need to install the “C++ Re-distributable for Visual Studio 2012″ which contains the DLLs that Apache and PHP are compiled against (check Required Microsoft VC++ Redistributable Packages).

WampDeveloper Pro’s Web-app Auto-Installer Internals

If you are interested in creating your own web-app packages (such as a custom package of WordPress with various themes and plugins integrated and enabled) that are then “one-click” easily (for deployment) and repeatably (for testing) installable to any website and URL, WampDeveloper Pro provides its own web-app packaging format and installation mechanism…

The web-app installer reads and executes commands (that it understands) from an XML file – performing the task of placing, importing, editing, and manipulating web-app assets (files, configuration, database entries). This process creates an “installation” that is [ideally] identical and indistinguishable from a regular install.

The principle difference between WampDeveloper’s web-app installer and the web-app’s native setup/installation process is:

Native setup/installation – runs through the web-app’s PHP code, which forms the database, populates that database, and updates the configuration file.

WampDeveloper’s web-app installer – bypasses the above native process completely by placing the web-app’s files, importing the already formed database, and using the install-to path and URL, updating the configuration and database entries to reflect the new location.

To create a web-app package:

Web-app Assets

Create the needed assets for the installer to start with…

1. Manually install a web-application using these default values:

website: www.example.com
username: admin
password: passadmin
email: admin@example.com
mail: mail.example.com
DB name: webapp
DB user: webapp
DB host: 127.0.0.1

Technically you can use any values you’d like, but the above will be considered as standard. These values will later be changed by the auto-installer using the selected website, URL, and the generated DB name + user and Admin password.

When installing the web-app, try not to go pass the finish of the installation process – by accessing the home page and/or performing a login. If you do so, the web-app will likely create sessions, caches, temporary files, and database entries, that might need to then be cleaned up.

2. Perform a clean up by deleting any created:

A. Sessions - e.g., truncate table "sessions"
B. Caches - e.g., truncate tables "cache_*"
C. Watchdog (log) - e.g., truncate table "watchdog"
D. Any cache and temps files - e.g.,  files in web-app's "temp" sub-folder

This step is not necessary, but it is considered good to not leave any residual fingerprints and data.

3. Export the web-app’s database into an SQL file, and zip the file as: \database\database.sql.zip

4. Select all the web-app’s files (but not the containing folder), and zip the selection as: \files\files.zip

5. Copy the web-app’s configuration file(s) into: \configs

Package Format (Example)

All the web-app packages are stored in folder:
\WampDeveloper\WebApps

If you take a look into folder \WampDeveloper\WebApps\wordpress-4.0.0.0-r1\ , next to the base assets, there are three XML files that define and control the installation of WordPress.

All other files/folder within are just things referenced and used by tasks.xml (WampDeveloper only knows about the 3 XML files).

1) tasks.xml: which defines what to do to install the package (and move it to another URL, delete it, etc).

2) parameters.xml: which defines the variables and defaults (such as “db_host” is to be “127.0.0.1” / localhost by default), that will be used later in tasks.xml.

3) profile.xml: which just defines the name, version, and some other “info” data about the web-app and package.

Installation Tasks

The way it works is tasks.xml:

a) Imports \database\wordpress.sql(.zip) into MySQL.
b) Imports \files\files(.zip) into the install-to directory.
c) Imports \configs\wp-config.php into the install-to directory (or where WordPress expects to find it).
d) Performs SQL queries to create the proper database name, database user, and update the database with the proper values for the new URL, path, etc.
e) Performs file edits to update wp-config.php with the proper values for DB name + user + host, keys and salts, etc.
f) Runs a script (scripts\setPassword.php) that uses WP’s API (functions) and a passed-in command-line parameter to set the admin password.

Creating Web-app Package

If you have the time to study the format/syntax of the above XML files, you can create your own packages. The difficulty of it is that none of this is fully documented for the moment, as it’s all still evolving. And if it’s not done correctly, it’s just going to fail without providing any type of useful error message.

If you wanted to create your own WordPress package with your additional configuration, content, themes, and plugins included, just install WordPress (and additions) into: www.example.com\blog. Then, as shown above: export and zip the database, copy the wp-config.php file, zip up the files, and replace those assets within a duplicate of the already provided WP package (i.e., in a copy of the provided webapp-version package – with the folder name updated for version and release number). Afterwards make some minor edits to profile.xml and tasks.xml to reflect the new version and possibly any new changes.

Uses

Create auto-installer for the latest version of web-apps such as Wordress.
Create auto-installer for any PHP Framework such as CakePHP, CodeIgniter, Zend.
Create auto-installer for any Frontend HTML + CSS Framework / Template such as Bootstrap.
Create auto-installer for any Javascript MVC Framework or Library such as AngularJS.
Create auto-installer for executable (binary) applications such as Node.JS.
Create auto-installer for an entire website (including its databases).
Create auto-installer for full Windows applications, including IDEs (editors).
Create auto-installer for Mobile Frameworks such as Ionic.

Quick WordPress Multisite (MU) Installation and Setup for Different Domains and Sites

WordPress Multisite (or Network) is 1 wordpress installation that enables hosting of multiple different websites and domain names.

WordPress Multisite uses the same wordpress base (including the themes and plugins), wordpress database, and wp-config.php configuration file – for all sites in the network.

To install and use WP MU (Multisite), you would:

  1. Install WordPress on a base website and domain. This installation will provide for all your MU sites.
  2. Activate (turn on) Multisite / Network:
    1. Edit wp-config.php
      define( 'WP_ALLOW_MULTISITE', true );
    2. Go to Tools > Network Setup, select to use: sub-domains, and provide the asked “network” details (primary: domain, title, mail address). Install.
    3. Make sure the displayed wp-config.php and .htaccess changes are made (and if not made automatically, make edits manually).
  3. Install the “WordPress MU Domain Mapping” plugin to be able to use separate domain names for different sites (otherwise you’ll only be able to use sub-domains for sites, such as: site1.example.com, site2.example.com, site3.example.com).
  4. In the website’s settings (or directly in the HTTP and SSL VirtualHost files), add your list of sub-domains and full-domains into the ServerAlias field. Make sure redirects are turned off.
  5. If hosting (i.e., not local dev), you’ll need to make sure that you have proper DNS set up for:
    • Each site’s domain name with a “CNAME” record resolving to the base (primary) domain name.
    • Wildcard (*) on the base (primary) domain’s host (sub-domains) with a “A” record resolving to the server’s IP address.
    • And of course the base domain name resolved to the server’s IP address.
  6. Make sure to clear your Browser’s cookies and cache.

http://codex.wordpress.org/Create_A_Network

Rotating Apache Logs Daily With RotateLogs.exe

By default, access requests, errors, and some other segmented data, is written into separate log files, which are not rotated by Apache.

These log files grow in size as new log data is appended with each additional access request made. And it’s left to the user to (once in a while) stop Apache, and rotate (i.e., rename) or delete the log files, so everything starts from size-zero again.

Rotating logs is important because once log file sizes reach the 500MB to 1GB range, this can create issues for: Apache (e.g., slow downs), for file editors/readers (such as Notepad), and also for some statistics/analytic programs (such as AWStats).

Standard Logging Configuration

The standard logging configuration can usually be found in each website’s HTTP and SSL VirtualHost files:

ErrorLog "C:/WampDeveloper/Logs/Websites/www.example.com/http.errorlog.txt"
CustomLog "C:/WampDeveloper/Logs/Websites/www.example.com/http.accesslog.txt" combinedtrueout_host
CustomLog "C:/WampDeveloper/Logs/Websites/www.example.com/http.deflatelog.txt" deflate

The last part of each line is the name of the log format definition to use. WampDeveloper Pro's log format characteristics are more advanced than the "common" LogFormat, and the definitions are located in configuration file: C:\WampDeveloper\Config\Apache\extra\wampd-logformats.conf

Each line simply creates the specified file, and appends data to it (there is no rotation).

Rotating Logging Configuration

To automatically rotate a website's access.log (and other log files such as the error.log) every 24 hours (daily), Apache's included rotatelogs.exe tool can be used...

With rotatelogs.exe, instead of writing to log files directly, Apache will "pipe" the log data into specific rotatelogs processes. And these rotatelogs processes will keep track of the elapsed time and/or growing file size - and once the specified limit is reached - will rotate their assigned log files (and start new log files).

Replace the standard logging configuration with:

ErrorLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/www.example.com/http.errorlog.%Y-%m-%d.txt 86400"
CustomLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/www.example.com/http.accesslog.%Y-%m-%d.txt 86400" combinedtrueout_host
CustomLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/www.example.com/http.deflatelog.%Y-%m-%d.txt 86400" deflate

If you are not using WampDeveloper Pro, but some other WAMP server, replace the LogFormat part (end part) of the access.log CustomLog line with "common".

This will create daily log files:

  • With filename format of http.accesslog.2015-03-14.txt (logfile.year-month-day.txt)
  • Using the computer's local time (not UTC).
  • And a rotation time of midnight.

Caveats

1. RotateLogs will start 2 processes per log file. With at least 3 log files per VirtualHost (access.log, error.log, deflate.log), and 2 VirtualHosts per website, this can add 12 "rotatelogs.exe" processes to your system for each website that you set up RotateLogs with.

You should only use RotateLogs on your high traffic website, and perhaps only for the access.log file, as otherwise your might run out of memory due "problems when running many piped logger processes on Windows".

2. RotateLogs limits are not exact... It will not make a new log file exactly at midnight, and it can also go over whatever the set file size limit is - due to the way these limits are handled.

3. RotateLogs will only create a log file after the first request is made.

4. Some older Apache versions came with a buggy RotateLogs implementation that would not die after Apache restarted.

5. Apache start error (in error.log):

(OS 2)The system cannot find the file specified. AH00104: unable to start piped log program 'bin/rotatelogs -l C:/WampDeveloper/Logs/Websites/www.example.com/http.accesslog.%Y-%m-%d.txt 86400'

The standard documentation and examples for RotateLogs are no longer correct... On Windows, and with Apache 2.4, you have to specify the full file name of rotatelogs: rotatelogs.exe... CustomLog "|bin/rotatelogs.exe ...

This is not a problem for the above instructions, but is something that you should be aware of for older ones.

Binding Apache to a Specific Or Secondary IP Address

Apache, by default, will attempt to bind to and listen on these interfaces:

0.0.0.0:80
0.0.0.0:443

[::]:80
[::]:443

1. “0.0.0.0” means ALL IPv4 addresses that the system has (including 127.0.0.1).

2. “::” means ALL IPv6 addresses that the system has (including ::1).

When started, Apache will try to take all the IP addresses of the system, and if you are already running another web-server (such as IIS, Tomcat, Nginx, Jetty, Domino, etc) on that same system, Apache will not be able to bind to “0.0.0.0” and “::”, and will fail to start. Or, if started first, after binding to all the available IP addresses, it will prevent the other web-server form starting.

To bind Apache to a specific or secondary IP address:

Edit file –
C:\WampDeveloper\Config\Apache\httpd.conf

Find and replace these two lines (one is at the beginning, the other at the end) –

Listen 80
...
Listen 443

With –

Listen ip.address.here:80
...
Listen ip.address.here:443

You can specify multiple IP addresses with multiple lines.

If this is a public server, make sure that the IP addresses you are using, are either the resolvable IP addresses of your Apache hosted domain names (e.g., the Public IP address), or the LAN IP addresses that the Router is port-forwarding outside port 80 and 443 traffic to.

If this is a intranet server, you can just bind Apache to the LAN IP.

If this is a localhost server, you can just bind Apache to 127.0.0.1.

Also make sure that your other web-server is binding only to a specific IP address, and not to “0.0.0.0”.

After making changes, if Apache won’t start, check the configuration by running (from the command line):

httpd -t -n "Apache2"
httpd -k start -n "Apache2"

Upgrading WampDeveloper Simplified

The upgrade process for 95% of WampDeveloper users involves (for the most part) just copying and replacing a few folders and files to keep your previous websites and databases.

The process in the larger WampDeveloper Upgrade guide appears more complicated because it includes additional explanations, takes care of special cases, and describes possible issues (with solutions provided).

This is the simple version of the WampDeveloper Upgrade guide. If you are upgrading between versions within the same major version or branch, and have not made any significant changes to the configuration and the platform, this guide is for you.

Upgrading WampDeveloper

  1. Click uninstall (bottom of Components Tab), proceed.
  2. Rename folder C:\WampDeveloper to C:\WampDeveloper.old
  3. Install new version as C:\WampDeveloper
  4. If you have websites and databases to keep:
    1. Using the Websites Tab, re-create your extra (new) websites (by inputting the same domain name and domain aliases for each website). Then stop Apache and MySQL.
    2. Delete and replace (with previous) folder: \Database
    3. Overwrite / copy-over (with previous) folder: \Websites
    4. Re-install the phpmyadmin database by using (i.e., copy-paste + update for drive letter) and running the 4 commands listed in the section “Re-Install phpMyAdmin’s Database” of the larger guide.
  5. If you used WampDeveloper to auto-install web-apps (via Webapps Tab), to see those web-app installations listed in the Webapps Tab, replace (with previous) file: \Webapps\apps.xml
  6. If you have made custom changes to the website VirtualHost files, website AWStats configuration files, and/or the general Apache, MySQL, and PHP configuration files – those changes should be made again in the new installation.