Notice: If you are running version v1.7.0 or above please read this thread as well.
OpenLiteSpeed follows apache style rewrite rules but with a slight difference. However to add rewrite rules you have to go to Webadmin console which ships with OpenLiteSpeed. Inside Webadmin console you can also specify a file from where OpenLiteSpeed can pick rewrite rules for that specific virtual host (domain name). To specify the file you can use this syntax:
rewrite {
enable 1
rules <<<END_rules
rewriteFile /home/example.com/public_html/.htaccess
END_rules
}
Here rewriteFile defines the path where you will have your rewrite rules. It is not necessary to name this file .htaccess, this name is a very common practice which is why CyberPanel follows this pattern.
You have to be careful here, as LiteSpeed Enterprise web server can also read nested .htaccess files whereas OpenLiteSpeed can only read file defined using this syntax. Because of that, you need to be extra careful with your rewrite rules inside sub-directories.
How CyberPanel manages rewrite rules!
CyberPanel follows the above pattern, you can use rewrite rule guide to set up rules if you have CyberPanel installed. Please note that if you are using the File manager to manually create your .htaccess files then they will not be followed. Because once you first click Save Rewrite Rules in CyberPanel it creates the following configuration in your virtual host file:
rewrite {
enable 1
rules <<<END_rules
rewriteFile /home/example.com/public_html/.htaccess
END_rules
}
You can also manually add these entries in virtual host configuration file and then create a .htaccess file from the File manager. Remember to restart OpenLiteSpeed everytime you make changes to your rewrite rules file, otherwise they will not be followed (Saving rules from CyberPanel does not require an OpenLiteSpeed restart).
Setup access to OpenLiteSpeed Webadmin Console!
In this article we will be going to use Webadmin Console frequently so first we should set up access to Webadmin. We need to open port 7080 as it is used by Webadmin console. After installing CyberPanel, navigate to:
https://:8090/firewall/
Here 0.0.0.0/0 mean anyone can access this port, you can limit it to single IP as well. Once this port is opened in the firewall you can access WebAdmin Console at:
https://:7080/
Default login details:
Username: admin
Password: 123456
You can also change logins by running this command:
/usr/local/lsws/admin/misc/admpass.sh
Turn on extensive Rewrite rule logging!
Before we move any further it is a wise move to turn on extensive rewrite rule logs, so you know what is happening. You can do this from CyberPanel as well as WebAdmin Console.
Via WebAdmin Console
Once logged into Webadmin click Virtual Hosts from left sidebar, and then click view on the right side for a domain which you are going to turn on extensive rewrite logs for.
Select Rewrite tab and click edit.
In the Log Level box you can set the intensity of logs, set it to 9 for maximum possible logs and click save, and then restart OpenLiteSpeed for changes to be effective.
Via CyberPanel
You can also do the same thing via CyberPanel. Navigate to:
https://dev.cyberpanel.net:8090/websites/example.com
Click vHost Conf and enter logLevel 9 inside rewrite block. This will have the same effect whether you do it via WebAdmin or CyberPanel, once you click Save CyberPanel will auto restart OpenLiteSpeed in the background.
Basic Idea of Rewrite Rules in OpenLiteSpeed!
First lets read a simple paragraph from OpenLiteSpeed site
In a virtual host configuration, the rewrite rule pattern will initially be matched against the part of the URL after the hostname and port and before the query string (e.g. “/app1/index.html”). This part of the URL does not end in a forward slash, so the pattern needs to start with a forward slash. Rewrite rules in an .htaccess file are matched against the file system path, which does end in a forward slash.
Which means we just need to add a forward slash to our rewrite rules if we copy rules from apache .htaccess file. Let’s take a simple example:
http://example.com/cyber/panel → Example Domain
For above rewrite to work, apache rules will look like:
RewriteRule ^cyber/panel$ /index.html
But they will not work with OpenLiteSpeed, you need to add a forward slash at the start of your rule, your final rule for OpenLiteSpeed will be:
RewriteRule ^/cyber/panel$ /index.html
Trace Error Logs
Let see what happens on error logs when we use apache style rewrite rules, put this in your rewrite rules:
RewriteRule ^cyber/panel$ /index.html
On command line look at error logs:
tail -f /usr/local/lsws/logs/error.log
Now if you visit http://example.com/cyber/panel, you will see following line on error logs:
2018-04-07 07:27:19.292401 [INFO] [101.50.68.7:52906] [REWRITE] Rule: Match '/cyber/panel' with pattern '^cyber/panel$', result: -1
Note result: -1 at the end, request URL does not match with our rewrite rule, now lets change rewrite rule to:
RewriteRule ^/cyber/panel$ /index.html
And look at the logs now:
2018-04-07 07:30:20.749667 [INFO] [101.50.68.7:53032] [REWRITE] Rule: Match '/cyber/panel' with pattern '^/cyber/panel$', result: 1
2018-04-07 07:30:20.749692 [INFO] [101.50.68.7:53032] [REWRITE] Source URI: '/cyber/panel' => Result URI: '/index.html'
You can see result: 1 which means request matched with our rewrite rule and resulting URI is: /index.html, which is exactly what we want.
WordPress Permalinks
WordPress permalinks do not work with default .htaccess rules generated by WordPress. Default rules generated are:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
You just need to add forward slash to solve this problem, and final rules will be:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^/index\.php$ - [L] # Notice the forward slash in this rule
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Only a slight difference can make everything works.
WordPress in subdirectory
What happens if you install two WordPress applications. First in the document root and second in sub-directory. With LiteSpeed Enterprise you don’t have any problems since it follows .htaccess files in subdirectories too. But OpenLiteSpeed only follows rewrite rules in the file we defined, so if you have rewrite rules present anywhere inside other sub-directories they will not be obeyed. Let’s take an example:
First WordPress installation: http://example.com
Second WordPress installation: http://example.com/cyberpanel
Now even the default rules will not work, your rules for one WordPress site is:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
You need to modify these rules so they won’t take effect when /cyberpanel is in URL.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{ORG_REQ_URI} !/cyberpanel # Note this line
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
So your final rules for sub-directories to work is:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{ORG_REQ_URI} !/cyberpanel
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /cyberpanel/index.php [L] # This will make sub-directory works.
</IfModule>
This is a basic example of how you can play with rewrite rules and OpenLiteSpeed. You can adapt these rewrite rules to any situation. Just be careful that OpenLiteSpeed will not read rewrite rules in nested sub-directories, so you need to put all rewrite rules in one single file and adjust them accordingly.
There is also a detailed article about WordPress multisite rewrite rules on CyberPanel forums.