The Apache web server has a convenient feature called Name-based Virtual Hosting. This function allows us to have a single LAMP Stack server configured on one IP address, but serve a different set of files depending on which domain is being requested.
This sounds more complicated than it is. Say we had example1.com and example2.com, both of which are to be separate websites, but both domains point to the same IP address. Apache’s Name-based Virtual hosting makes this possible. In fact, this feature forms the basis of 90% of this planet’s shared hosting business.
Sometimes we must know what web server is running on a particular domain. Usually web hosts should be able to tell a client this, but if the client is afraid to ask, there is a way to ask the web server directly for this information.
Just to clarify: the web server is the process that serves files (HTML, PHP, ASP, images, etc) from a remote machine to your local web browser. The most likely choices in this day and age (2017) are Apache, NGINX or IIS. The latter is used by Windows servers, and the two former are used by Linux servers. There are other web servers too, such as lighttpd, but they’re used less commonly.
By asking the web server for this information, we can tell exactly who’s serving those files.
Sometimes I have to work on WordPress sites that are too busy to display the admin interface. This can happen if there’s more traffic than the server can cope with. In such cases, we may need to tell every visitor to come back later while we carry out some maintenance.
But how? Thanks to an Apache command to block all IP addresses, except for our own. We can even display a “maintenance” page while we’re hard at work behind the scenes.
Let’s see how. Add the following to your .htaccess file in the web root directory, replacing 126.96.36.199 with your own IP address:
Save the file on the server and see the site speed up as of by magic. No more requests but your own shall be processed henceforth.
Thanks to MickeyRush and b101101011011011 for this solution on Stack Overflow:
I have worked on a server recently and I came across a problem (again) that I meant to write about, and include a solution should you suffer from a similar problem. It was a Plesk server running CentOS, but this particular issue can also happen on plain LAMP stacks.
Trying to start Apache, I got the following error message:
httpd not running,trying to start
(98)Addressalready inuse: make_sock: couldnot bind to address[::]:80
(98)Addressalready inuse: make_sock: couldnot bind to address0.0.0.0:80
nolistening sockets available,shutting down
Unableto open logs
The port number may be different depending on which port Apache is supposed to listen on (80 is the default, but depending on your system it may be something different, for example 7080). What this error is saying is that the Apache config file says the service is supposed to use a specific port, and another service is already using it. Hence, Apache can’t start or restart.
If your server has worked fine before, then it’s likely that the config file is not the problem – so don’t go messing with it unless you absolutely know what to tweak.
Let’s find out what service (or process) is listening on our port. We can do this using the lost command:
Replace the port number (80 in the above example) with your own. In this example, Apache is in fact listening but something isn’t quite right and it’s unable to restart. We can go and kill each of these processes using the following command:
Do this with every process ID (PID) from the list you get from the lsof command. As soon as they’re all dead (verify with lsof), try to restart apache once again:
Some of my servers have a weird habit of throwing an Apache error after a restart: NGINX is running fine, but Apache can’t start and all websites are down. I have no idea why some servers do it and some do not. But when they do, it’s just plain annoying.
Here are two ways to fix this problem.
Restart Apache gracefully
The quickest option is to shutdown NGINX, restart Apache, tell it to shutdown gracefully and then bring up NGINX again. Here are the commands that will work on CentOS 7:
systemctl stop nginx.service
systemctl restart httpd.service
systemctl restart nginx.service
Likewise, on CentOS 6 we can use the service command to do the same:
service nginx stop
service httpd restart
service nginx restart
Note that Apache doesn’t always like a restart – in which case, stop the service first, give it a moment and then restart it. Quirks and habits I guess.
If you find yourself doing this a lot, consider writing a quick script with the above commands, or restart your server less often (sometimes it’s enough to restart Plesk, or not reboot the machine at all). Alternatively, you can remove NGINX altogether and avoid such problems in the future.
Removing NGINX from Plesk
NGINX is not necessary – Apache will do a good job by itself. If you want to get rid of it completely, head over to Tools and Settings (or the Server Tab if you’re in Power User Mode) and select Updates and Upgrades. You’ll be taken to the Parallels Installer. Select Add/Remove Components.
Scroll down to the NGINX section under Web Hosting Features and untick both NGINX options. Now click Continue at the bottom and NGINX will be removed, leaving Apache in charge for all website connections. There’s no need to restart Plesk.
Why would anyone want to use both NGINX and Apache together?
Very good question indeed. Both are excellent web servers, and logic dictates that you should use one or the other. Using two web servers together is a certain sign of trouble.
From what I understand, NGINX is not designed to be a replacement web server in Plesk (even though NGINX can be used in this way on a LAMP Stack). Instead it is implemented as an enhancement to Apache, sitting in front of it. Static files are therefore served from NGINX via Apache, and NGINX acts as a reverse proxy server.
The benefits are faster connections and a smaller memory footprint. Read more about how NGINX and Apache are implemented in Plesk in the following articles:
Trackbacks are a great way for other blogs to notify your blog about a link back to you. Many blogging platforms support this feature, including WordPress.
But sometimes it’s very obvious that those trackbacks aren’t coming from a legitimate source, especially when you get several dozen of them every day from the same source.
No one loves you that much.
The most recent two examples are semalt.com and buttons-for-website.com, the latter can’t even properly mix a plural with a singular. But that’s not for here.
To make sure those trackbacks don’t bother our WordPress site anymore, we can add a bit of code to your re-reite rule file. If your host is using Apache then this will be your .htaccess file, famously in use for Pretty Permalinks and some cache plugins.
A typical .htaccess file is either empty or contains a block of code courtesy of WordPress. It’s a simple text file. If we add this little snippet to the bottom of the file, friendly trackbacks from semalt.com will no longer notify our website:
# Block Semalt Trackbacks
This rather strange looking code is a rewrite rule. It says “if you encounter a link or a visitor from semalt.com, then forbid them access to anywhere on this site”.
Notice the backslash, followed by the domain extension in semalt\.com. This is necessary to escape the dot character, otherwise Apache would interpret it as an instruction. In our other example, buttons-for-website.com, we need to deal with the slashes in the domain name in the same way:
You can stack these rules in your .htaccess file and add as many as you like for your very own Trackback Spammers. Simply replace the URL in the code with your own, escaping special characters as seen above (a special character is anything that isn’t “a to z” or “0 to 9”).
Note that these rules do not prevent such websites from linking to you. However as soon as someone from the offending website clicks a link to your website, they will be denied access. On the other hand, when the same visitor would type in your URL, or come from a different website, they will be able so see your content without problems.
mod_pagespeed is an open source project which speeds up page loads without having to change the code of the actual page. mod_pagespeed does this by adding filters before pages are served. For example it will resize images and minify CSS/JS files, which can speed up page load considerably. The project is hosted on Google Code:
Let’s see how we can install it on CentOS, test to see if it works and how to manage it in Plesk.
We’re currently on our way to Kissimmee, FL to join Parallels Summmit, an annual conference from the people who make Plesk. We’re also taking exams in Plesk 10.4.4 so we’re studying it in-depth – I’ve been using the software for over two years now but never had formal training in it. Well here goes!
In preparation for the exam tomorrow I’ve come across something the instructor mentioned: namely the benefits of running PHP as a FastCGI application instead of an Apache module. Sadly I’ve also come across some drawbacks when using this option in regards to WordPress. I thought I’d mention those here, alongside how to avoid those.
UPDATE: Thanks to Boldock this problem can be fixed 😉
I was working on a secure site with sensitive video material that we needed strict members access to. Even though many plugins can make sure your direct permalinks can only be seen by logged in members, direct links to files in your wp-content directory are still accessible to others. They can even be hotlinked from other sites.
One way around this is to move the wp-content directory outside the web visible portion of your directory on the server, but even so WordPress can always link to such files. A better way is to tell your server not to give access to certain files (say ending with mp4 or mp3) and only allow access from your own domain.
We can use Apache Mod Rewrite for this – it’s a complex language that you can utilise in your .htaccess file within the wp-content folder.
Let me show you how to keep prying eyes out of your content.