Final touches included php8 and ClassicPress compatibility along with ongoing code maintenance and refinements. We also configured the Plugins helper to be off by default (the helper can notify on the dashboard about the plugins we used to enable certain features and functionality during our testing of Blue Haze).
Before discussing how to self host, you should decide if that is really the right option. If you already have or need something well beyond a basic website, then a Managed Solution might be worth a look. From a technical aspect, getting a website online is not exceptionally complicated, but does require someone comfortable with computers and configuring applications. You will also need some basic hardware, but if you have a computer connected to the internet, that is probably enough to at least get started.
There are a number of ways you can self host your website, the article Build a Server Lab goes into more detail regarding a setup designed for hosting websites, but also gives a lot of general information that would be helpful for even a simple self hosted situation. At a minimum, you will need a computer to install the hosting software on and the ability to make changes to your router’s configuration if you want to provide internet connectivity.
There is no one size fits all solution for this, Linux servers and software options are very popular, but unless you have an extra machine and experience with Linux, being able to use a Windows based machine to get started will usually be the easiest. There are plenty of hosting software options for Windows as well, but if the plan is to get a website you can configure yourself running with the least amount of work, our suggestion would be to start with WAMP or XAMPP, both can be installed on any Windows computer.
Download the Windows installer from Apache Friends. When the download finishes, run the XAMPP installer. Navigate through any prompts until at the installer screen:
Click Next to choose which components to install.
In addition to the required components, you should also select:
Unless you need other options installed, set the screen so it looks like this and click Next.
You can select the folder to install XAMPP, but we suggest you leave it as the default:
Next you can choose your preferred language.
Then you get a prompt asking to install Bitnami for XAMPP.
You do not need this, so feel free to uncheck the box.
Click Next and you are ready to run the installer…
When the install finishes, launch the control panel to start working with XAMPP.
Start & Test your XAMPP Server
For everything to work, you need to run the two modules shown below:
Start the modules using the XAMPP Control Panel:
Once running, you should see the status change to green:
Test that your server is working locally by going to
http://localhost/ in a browser.
If you see a page similar to the one above, you have a functioning XAMPP Server.
The question now would be how does this become your website…
Adding a Content Management System
Content Management Systems are software programs that assist with the creation, editing, and publication of digital content like web pages and blog posts. We will install WordPress since it is one of the most popular CMS platforms out there and has tons of information and documentation available at your fingertips on the internet. I do want to quickly mention that ClassicPress is a drop in replacement for WordPress being developed for those who want to be sure they will never lose the ability to use the WordPress Classic Editor. Since you can convert an existing WordPress installation it is not a decision you need to make now, but something to keep in mind, so let’s continue.
First, you need to visit WordPress.org and download the latest version of WordPress.
Now in Windows, navigate to the folder where you installed XAMPP. If you stayed with the installation default that should be
C://xampp. In that folder, find the htdocs subfolder and extract the WordPress.zip file you downloaded from wordpress.org into it.
Create a database for WordPress
You need to create a database for WordPress to use.
Launch PHPMyAdmin by using your XAMPP Control Panel:
Then click Databases at the top of the PHPMyAdmin Page:
Enter a logical name for your database and click Create.
For a Live Web Server, there are security concerns we discuss later in this article, but for local testing with XAMPP, creating a WordPress database user is not required. It is also important to be aware that the XAMPP Server currently has no root database user password and that needs to be corrected if the server is connected to the internet.
Run the WordPress Installer
You should be able to visit your site at
http://localhost/ and be presented with the WordPress installer. When you get to the database details, enter them like this:
- Database Name = Name of the database created with PHPMyAdmin
- Username = root
- Password = leave blank
Once the installation is complete you should have a working Self Hosted WordPress Website running at
http://localhost/ that you can start to develop.
Putting your Website Online
Address Security Issues
XAMPP is a quick and easy way to get started self hosting and developing websites, but it is not really the most secure way to publish a public facing / internet connected website. There are also considerations like bandwidth restrictions and the speed of your connection that you need to be aware of once your website is connected to the internet.
Many options exist to migrate your self hosted website to more secure, dedicated equipment; but you can opt to simply upgrade your test server, especially if your website is still fairly basic and does not even contain sensitive data that could be stolen.
That said, there are many articles on the internet that explain how to secure or harden your XAMPP installation. The main issues include the lack of a database root user password and PHPMyAdmin being in a public and predicable location. I must stress the importance of using strong passwords that are unique to each application or login, machine security is also important, if someone can just walk up to your webserver or browse to it on your local network, it is not secure. Beyond that, you can get security plugins like WordFence for WordPress that provide another layer of protection.
Once you put your website online you are also going to need to look at obtaining an SSL Certificate (allowing https). A search of how to setup a Certificate for your XAMPP Server using Let’s Encrypt / CertBot or SSLforFree should put you on the right track though.
Domain, IP & Port Forwarding
The final steps in getting online involve configuration changes so computers on the internet can access your server. This can end up being a bit involved, most websites use a Domain Name and DNS to point web traffic at the IP Address of the server. You can just determine what your IP Address is and use that to access your website, but in most cases your IP Address is Dynamic, meaning your Internet Service Provider may issue you a new IP at any time, requiring additional configuration to update your setup when the IP Address changes. This might sound confusing, so let’s try to break it down some:
You can get a free Domain Name, but you might be better off with a .com name, which can easily be obtained for under $20 a year and I think they are worth that minimal expense. Some domain providers may include or offer an upgrade that includes DNS settings for your domain. If not, free options are out there for that also; However, like a Domain, having a reliable Dynamic DNS provider might also be worth the price as very reasonable options exist for that as well. So, while you can operate a website using just the IP Address, for the sake of this article, we are going to assume you have decided to get a Domain Name and Dynamic DNS provider for your website.
Now it is time to configure your router and server computer. Most likely, in a situation similar to how your Internet Provider issues a Dynamic IP Address to you, your Router probably uses DNS on your local network to provide the IP Address for your computer(s). Of course, that also means it is possible for your Server to be issued a new IP Address, to avoid that, we should set up a Persistent or Static IP Address somehow. Also, the WordPress General Settings for WordPress Address and Site Address may need to be changed to your Domain Name if still set to localhost or the Server IP Address. This can also be done by editing or adding the following wp-config.php file entries:
define( 'WP_HOME', 'https://your_domain.com' );
define( 'WP_SITEURL', 'https://your_domain.com' );
The issue now is that there are so many router/firewall devices and applications out there that trying to assemble generic instructions is not realistic. You will need to determine the exact model of your router and figure out how to login and make changes. Some routers will have features that easily allow setting the IP of computers on your local network, others will require that you set a range for Static IP’s, then make the change at the Server Computer. Another handy feature many routers have is a way to keep your Dynamic IP updated, usually called Dynamic DNS or something similar. Once you know what router you have and are able to login, here is that basic outline of how you set all this up so people visiting your domain will be directed to your website on the server computer.
The provider where you obtained your Domain Name should have a control panel where you can configure the DNS Server for your Domain. Usually they will have a DNS option, but unless they have the ability to handle Dynamic DNS / IP Updates, you may need to set up a separate DNS Service that handles your Dynamic IP Address Updates. This is where some checking around for price and features when getting your Domain Name is worth the time spent. I will mention though, that we use one service for Domain Names, and another for DNS; let price, features and ease of use be your guide.
The way you handle a Dynamic IP will also vary based on your DNS Service and Router. A best case would be that your Domain or DNS Provider has the option and instructions to help you set this up. The other end of the equation is your Router, many have the settings needed to take care of alerting your DNS Service that the IP has changed. Searching how to set up Dynamic DNS with your Router and DNS Service may be required. If your equipment or provider(s) do not have the options or clear instructions, it can be tricky to get Dynamic IP Updates working, but you can still set everything up to use your current WAN IP Address and circle back to this later Until your IP Address actually changes everything will work even if Dynamic DNS is not properly configured.
Now that your Domain has a DNS configured to point at your WAN IP Address, the final step is to set your Router to send website traffic to your server. This is usually done using Port Forwarding, which is why the IP Address of your Server should not change – you also need to know what the Server IP is during these steps. You might need to search on setting up an IP Address if this not something you have done before. For this example, I am going to say our Server Computer is assigned an IP of 192.168.0.10
As you can expect, different routers will have the Port Forwarding Settings configured in different ways, the goal is to Forward ALL Traffic from WAN Ports 80 & 443 to your Server (192.168.0.10). You will also need to insure that neither the Router nor the Server has a Firewall blocking those ports. If you can visit your website from a different computer than the Server by using the Domain Name, then it is configured properly. If you cannot, try to use another computer on the same local network to access the website using the IP Address (http://192.168.0.1 in our example). If you can only access the website from the Server, double check that a firewall on the Server is not blocking, If you can access from the local network by IP, but not from the internet using the Domain Name, then you will need to check and troubleshoot any Router, DNS Service or Domain Settings.
Blue Haze v0.9.9.8 is essentially production ready, feature testing on a variety of sites and configurations is complete, so in that respect things are in good shape. However, the plan to incorporate a level of plugin management into the theme has been set aside and instead we are developing a separate suite of tools for Plugin Management. We will provide details about that project in another post, but are sort of holding off on backing some of the plugin related code out of the theme until we are further along with the Plugin Tools. Since other changes made enhance functionality for sites using the blog features of WordPress, we decided to release what we hope might be the last Beta Version of the Blue Haze Theme.
Development continues on Blue Haze and v0.9.9.6 cleans up some of the issues we wanted to work out before an official release version is assigned. The main items left to cover include additional testing on a few more sites and configurations along with how to properly handle plugin requirements and/or suggestions – this has been difficult to work out due to endless variations desired by developers and publishers. Our suggestions could easily be overwhelming or bothersome for some, while others may enjoy knowing how we made use of plugins to achieve functionality for certain features. The further we push into trying to work out a theme driven solution, the more it seems that offering a plugin might be the better choice, as it could provide the basics regarding what plugins we find useful and compatible with Blue Haze, while potentially becoming a plugin manager to use across multiple sites.
Whether for hobby use, as a development platform / testbed / sandbox, or for live hosting, a server lab or home server allows you to create a setup specific to your needs. Since the requirements for that server lab can vary widely, so might the hardware and software used to create them. A home server can be as simple as a single computer or even a single virtual machine used to host some videos or files that are shared on your home network, up to a full scale server farm hosting live websites or more. Most will fall someplace in between those two points though and can share many things in common. For our example, the goal is to end up with a server lab that can host a variety of virtual machines and provide applications for both local and internet use. This guide does expect that you have some level of comfort with computer hardware and software, our intention is to provide a basic guide on assembling a functional small scale server lab.
Before we move on to building a system though, lets look at the internet connection and service provider in use. If you plan to connect with the outside world for more than just some quick file transfers, things like speed and monthly bandwidth limits may come in to play. Another thing to consider is that unless you are set up with a static IP (something you would probably know because it costs more and is sometimes not even offered for residential accounts), you will need a method to update your dynamic IP when your provider assigns a new address to you. Additionally, some providers do not like home users hosting websites and most do block the standard mail server ports. While not nearly as common for them to block other services, it does create a problem if they do.
Now that you have verified enough speed and bandwidth are available for your needs and that your provider does not block services, let’s look at your connection hardware. This is the modem and/or router your provider normally gives you, but is also a key part of your setup, especially if you plan to make your applications available on the internet. Most times you pay a monthly fee to rent the device or devices, so upgrading to something you own may be worth looking at as part of the project. Unless you are more comfortable continuing to use the wireless / router capabilities of the hardware your ISP gave you, I would look at either converting that router to gateway mode, or trying to set yourself up with a dedicated modem.
Cable providers are more likely to offer integrated devices, where the modem, router and wireless are one unit. This may seem convenient, but usually results in a device that might lack the features you need for a more complex network. Fiber internet more often already has a separate modem and router, making it easier to keep the modem and use your own hardware from that point. Regardless of the method used, you want to end up with a WAN port that provides unrestricted internet to your system.
As mentioned, a server could be as simple as one computer, but most times your lab will consist of at least a few pieces of hardware. The configuration we use for our guide consists of four computers and at least one switch. Of course your final setup will likely also include other hardware such as wireless access, additional switches, plus the computers and devices in your home that already connect to the local network and internet. The computers used can vary in price and configuration also, based on the tasks they are expected to perform. Since we will create a small server cluster for a virtualization environment, having as much memory and CPU power available as you can for the main workhorse machines is your goal. In our example two of the machines are ‘servers’, one is the firewall and another is a dedicated backup server.
You will need to determine how much power is enough for your needs, but a good starting point for the two servers would be at least 64G of memory and as much CPU as you can afford. You can often get commercial servers that are a couple generations old for a fair price if on a budget. The other two machines can be a scaled back, with 16 or maybe even 8GB being enough memory and a CPU based on what that machine needs to do. In our case the backup server may not need to be extremely powerful, but since we are going to virtualize the firewall, we want enough power for additional applications we might include. You also need to think about where this equipment will go and that you need to have enough power in a battery backup / uninterruptable power supply setup to safely shut down in the event of power loss and handle short term power problems.
I separated this from hardware because there is a bit more involved when planning out storage / drive requirements. You can just plop a good sized drive in each machine and go, so long as you make sure to keep everything safely backed up. However, each machine will probably have different drive requirements based on the applications you run and countless other factors, making it difficult to discuss every option you have. We will suggest a viable setup for each machine, and you can always change this later, but starting off with a pretty good idea what you need is better than throwing something together that you have to reconfigure right away.
I didn’t want to get ahead of myself and start talking too much about backups now since we have a section on that later, but a primary factor that should be worked out now is what and how things get backed up. In an ideal situation, you would back everything up every day and then push a copy of those backups to off-site storage, and we do cover that aspect of it in more detail later. For now though, you could identify things that might become too large or that we want to handle in a different way. Examples of this would be storage for your NAS, security video or other datasets that can be expected to become very large. Again, the safest bet is to have a daily off-site backup for everything, but using a portable drive or modifying the schedule, configuration or backup method for large stores of data are all options to make sure your daily backups are quick and efficient.
Another solution for large storage pools is to use a disc array of some type, there are several software and hardware solutions to create disc mirroring. This sounds like a backup since the design of an array is that a disc can fail without losing data – you simply replace the bad disc and rebuild the array without losing data or even needing to take the machine offline in many cases. However, you need to be aware that disc mirroring is not a backup at all, it is redundancy; if a file becomes corrupt, a virus is introduced or an attack takes place, every disc change is immediately replicated on the array with no way of going back to what you had before. Knowing that, you may still decide that for large pools, an array may be an acceptable trade-off verses daily backups for huge amounts of data, especially if syncing with a remote storage location.
I just want to touch on the fact that almost everything we are discussing can be accomplished using countless combinations of software. Certainly when selecting software, personal preference is often as much of a consideration as functionality. In this guide we suggest software that we know works because we have used it ourselves, it can also be legally downloaded and used at no cost, but the basic principles are generally the same if you choose different software than we discuss in our guide.
We have mentioned virtualization, but here is a quick explanation of what that means in our case. Virtualization software allows us to set up an environment where we can create multiple ‘virtual computers’, usually called VM’s (virtual machines). Each VM we create ends up acting like a stand-alone computer that we can load an operating system and software on, this is very convenient and in many ways is also the primary function of the server lab. Virtualization software provides the means to create, host, backup and administer these VM’s. Many versions of virtualization software are available, but we have tested several and found ProxMox VE to be the best for our needs because it is easy to install, is administered through a web GUI, has a lot of online support and allows us to create server clusters. A cluster is 2 or more physical machines tied together by the hypervisor (virtualization software) so they act and can be controlled as one unit.
Before we start loading software it is a good idea to have a basic idea how you plan to map out the network. The two recommended LAN IP layouts are the 192.168.x.x network and the 10.x.x.x network. The 192.168 setup is intended for home use and actually provides plenty of subnet / address capability for most situations; even so, we prefer using the 10. IP setup.
When we say network mapping, we are talking about how you plan to set the IP addresses of network devices. When using the ISP provided hardware you often just plug in a device or connect to wireless, the router then assigns an IP address using the DHCP service and you never really notice this is taking place. You can still have your own DHCP service running once everything is set up, but most of the hardware in your server lab, including our VM’s, will have a static IP address assigned so you can use those addresses when setting up a web server or many of the other possible machines and applications later.
To get started, you could decide the primary network devices will use the configuration 10.0.0.x and that your firewall will have the LAN port set with an IP address of 10.0.0.1 and the subnet will be 255.0.0.0 or /8. You will also need to decide on the IP address configuration the ProxMox cluster, for simplicity you can use 10.0.10.x for that.
As mentioned in the connection discussion, there are plenty of options for a firewall/router, you can stick with your ISP provided hardware, buy something better, or build your own, which is what we will do here because it allows us a lot more flexibility and control. With that said, the next step is to prepare the hardware you intend to use as the firewall. This machine must have at least 2 networks cards, I would suggest good quality cards because all data to and from the internet passes through these cards, so skimping here can affect the performance of your entire network. A good option, especially if you plan to place this in the same location as your current internet connection hardware, is something in a quiet, compact case. A modern i3 or comparable CPU, perhaps 16G of memory and a modest SSD (250~500GB) should work well here.
For the installation of software I have decided to offer the URL to more in depth installation and configuration information, usually on the software authors website or to a known good walkthrough. It is beyond the scope of this guide to provide step by step instructions for the software installations, but this should insure you are getting the most recent software and information, plus this guide can be kept a bit shorter.
Keep your IP / network configuration notes nearby because you will probably need to substitute your configuration in place of what is being used in the various instructions. If you use our suggestions, the first ProxMox node will use IP 10.0.10.1 and the subnet will be 255.0.0.0 or /8. Another thing to keep in mind as you configure the new firewall is making sure not to set up an IP conflict that will cause a loss of internet connectivity or prevent internet access for the new hardware. OK, here is the ProxMox VE installation link, you will need to install that first, before you can install firewall software:
Once your first ProxMox node is installed and you can access the web GUI, it is time to install firewall / router software. Here again there are a lot of choices out there but we are recommending pfSense while mentioning that OPNsense might be an alternative to consider. We have used pfSense for many years and it is rock solid, there is a lot of online support and it is very reliable when virtualized in ProxMox. pfSense can handle the tasks of updating your dynamic IP address and providing DHCP services, it also has VPN support and strong firewall functions. The author of pfSense has even published the documentation we point you to on how to install pfSense on ProxMox:
Virtualizing pfSense on ProxMox
At this point you should have a working virtualized firewall. If you have been providing the machine internet from your existing router during setup, and it is now connected to your existing router using the WAN port, you should be able to access the internet with a computer connected to the LAN port. If that is the case then make copy of any changes to ports and other settings modifications you might have made to your existing router, then transfer them over to pfSense. When you are comfortable that all appropriate settings from your existing router have been duplicated in pfSense, it is time to swap in the new router. Power everything down and connect the new router directly to the modem or gateway, then power on and make sure everything comes up and you can get online, occasionally it is necessary to to refresh the WAN settings in pfSense if it is misbehaving after being connected to your old router during setup. Depending on your existing hardware you may need a network switch to get all your equipment hooked back up.
Before moving on, you might be wondering why did we virtualize the router software? It seems like it would be easier to just install pfSense on this machine and forget about virtualization. This will make more sense as we get further into the guide, but you will probably want to install a couple more applications on this machine once everything else is set up and working. Beyond that, the ability to easily backup and restore virtual machines makes it a better and safer alternative, you also want three machines in your cluster due to the way those machines interact with each other.
Now it is time to work on the main, or more powerful of the two servers. Before this gets skipped over though, you probably want your router’s LAN port to run directly to a hub, or main switching point. For this, we suggest a 24 port layer 2 switch, but I am mentioning it more because it is best to centralize as much as you can, verses jumping from switch to switch. You might also want to modify how your servers are configured based on your needs, but our suggested configuration will be adequate to host a fair number of applications. For this machine, we are aiming for maximum performance and minimal latency for our internet / public facing applications. This would mean devoting the best hardware you can afford to this machine, but here are a few tips on that.
We always leaned toward using a commercial server in the past, and they are a great choice, but the price for well equipped new servers is up there and if you opt for a used machine even a couple generations old, the performance of newer consumer grade hardware is well above what you end up with. There are possible downsides to this, but to be honest, you are probably better off going with the best performance specifications you can and don’t worry about it if not using commercial server hardware. So, in this regard we think the AMD Ryzen chips are something to consider, pair that up with 64 or 128G of memory and perhaps a 2 or 4TB SSD for a very respectable server.
As with the firewall machine, if you use our suggestion, this node will be IP 10.0.10.2 and the subnet will be 255.0.0.0 or /8. The installation procedure for ProxMox VE is otherwise the same as the firewall machine, move on once you are able to access the web GUI:
In contrast to the main server, the plan it to set this one up as more of a workhorse and file server. Also unlike the main server, for this machine considering a commercial server a couple generations old is the better choice simply due to storage capabilities. Here the idea is to find a machine that can support at least 4 drives, 8 would leave plenty of room to expand down the road. Raw CPU power is not as important here, but I would still go with the fastest dual CPU rig you can afford and like the main server, 64 or 128G of memory to finish it off.
Configuration for this machine is a little different as well. Our example uses four drives, starting with a 1 or 2TB SSD as the main drive to install ProxMox, just like the other machines. The remaining drives can be installed now but will be set up later, in our example one is used for security video storage and the other two are configured as an array for NAS storage. Since those virtual machines have not yet been created we can take care of drive setup when we install and configure those services. You may have a better idea of your requirements, but three server quality 8TB HDD’s is a good start.
As with the previous machines, if you use our suggestion, this node will be IP 10.0.10.3 and the subnet will be 255.0.0.0 or /8. Move on when you can access the web GUI:
Configure Updates & Create Cluster
At this point you should have three independent ProxMox nodes, one with your operational router and two that are a fresh install. Unless you have done some extra reading you might be wondering why you are getting this “no valid subscription” warning. ProxMox is free to use, but in order to receive official support, you need a subscription. I think there is a hack to get rid of that box, but if I remember right, every time the software upgrades you need to apply the modification again. Speaking of upgrades, the default ProxMox installation comes with configuration files for updates / upgrades that only work if you have a subscription. To configure the repositories for use without the need for a subscription, ProxMox provides instructions here:
Repositories for Proxmox VE
Now we are ready to create a cluster and add all nodes to it:
Create Proxmox VE Cluster
Once complete, verify all nodes can be administered from any node web GUI.
Another advantage of using ProxMox VE as the Hypervisor is that ProxMox also provides software for a dedicated backup server. This solution integrates with your ProxMox VE cluster and provides all the features you would expect in a backup server, including the ability to act as a remote backup server. Our setup will use the ProxMox Backup Server for local daily backups though, and an alternate option to use one of the popular cloud services to store off-site backups will be outlined a bit later in the guide.
This machine does not need to be the most powerful in terns of CPU power, though it does need enough storage to comfortably hold all your backups. We currently use a single CPU low power commercial server, but as with the firewall machine, something using a modern i3 or similar CPU and 8 or 16G of memory will do the trick. This machine will need 2 drives, one small SSD (128~250GB) and another drive for storage, for the setup we have built, using an 8TB server grade HDD should be sufficient. The backup server will certainly allow the creation of a disc array and other options, but our system will have a secondary set of backups, so we considered that to be overkill.
The installation procedure for the backup server is very similar to the virtual environment, to leave room for a few more nodes, a suggested IP address for the backup server could be 10.0.10.10 with the same /8 subnet as everything else. As with the ProxMox nodes, you will also need to modify the ‘/etc/apt/sources.list’ file to activate the proper upgrade repositories when no subscription is in use. Once you have the backup server installed and integrated with the server cluster you are mostly done with the initial configuration and should have a operational server lab with a working router and backup server.
Integrate ProxMox Backup Server with Proxmox VE
Repositories for the Proxmox Backup Server
Reverse Proxy & CertBot
If you plan to offer multiple applications over the internet, then you will almost certainly need a reverse proxy. In short, what a reverse proxy does in this situation is redirect traffic intended for a specific web application to the proper machine for that application, allowing any number of applications, websites or whatever to use the same primary connection (WAN IP). Our suggested reverse proxy server is Nginx, which when properly configured can handle your certificates (we use CertBot for this) and make the translation from standard http protocol on the local network, to ssl/https over the internet. The internet has countless examples on how to install and configure Nginx and CertBot, if you made it this far through our guide you will be able to work out the best way to handle a reverse proxy by doing a little searching easy enough, our only bit of advice is that we installed nginx on the firewall machine using a new virtual machine running Debian Linux and it works extremely well that way.
After discussing a reverse proxy server, could we just skip over the main use case for that setup? The number of possible methods and applications that can be used to provide web services makes it a rough subject to cover in a generic guide. However, if you have not already started down this path, here is some information you might find helpful.
Since we do a lot of testing different applications, we have assembled some default servers that we simply clone when we want a new virtual machine, which is much quicker and easier than loading everything each time. This includes a LAMP stack (Linux / Apache / MariaDB – MySQL / PHP) built using APT, so all components stay up to date with current Debian repositories and as we make downline improvements to active applications, we also update the default versions with any applicable changes. Plenty of walkthroughs for installing a LAMP stack exist, so if interested in this method, a quick search will get you going.
Network Attached Storage (NAS)
A very popular application with nearly as many uses and possibilities as the server lab itself is a good NAS setup. For this we suggest TrueNAS, which will allow you to set up nearly any type of storage or file sharing arrangement you can imagine, you can even run applications from within TrueNAS. When we set up the hardware for our Second Server we reserved two 8TB drives to use as the storage pool for our NAS. We set those drives up in Linux and after getting the TrueNAS virtual machine running on that server, we created an array using those drives. Just as with Nginx, there is plenty of information on the internet about TrueNAS and how to configure storage, so we won’t go into that here.
TrueNAS is also how we push our backups to an off-site storage location. To get this working you need to set up a TrueNAS NFS in ProxMox that is enabled for backup storage, then enter cloud credentials for your cloud storage (we are currently using OneDrive for this) and create a task in TrueNAS to Sync with Cloud Storage.
Here is a article on doing the same thing with Google Drive:
We also suggest installing NextCloud for TrueNAS which allows you to securely extend TrueNAS onto the internet for file sharing, cloud storage and more.
Before finishing up, I will quickly talk about running a virtualized DVR system, since we did reserve storage on the Second Server for that purpose. We use Milestone XProtect Essential+ running on a Windows Server with the remaining 8TD HDD passed through to Windows as storage for the video database. This is somewhat outside of our intended scope, since even though the free version of XProtect in use, the application only runs on Windows, which is not a free product. Regardless, we have tried more than a few VMS offerings and so far we have not found another solution we are happy with.
You can go in so many different directions with what the server can do from here that it would be futile for us try and cover the possibilities. Here are some tips you may or may not find helpful though. ProxMox is built on Debian Linux, so we generally load Debian w/LXDE on the virtual machines we create, unless another operating system is required for that application. Those who enjoy using a GUI will find LXDE very friendly and in my opinion, maintaining your virtual machines through ProxMox with the option to use a GUI is often preferred to doing it all through the command line or SSH connection. Ubuntu is also Debian based (.deb), so in most cases if you are comfortable with Ubuntu, there is not much difference and one can usually be used in place of the other. ProxMox can host any operating system though, so this is just the way we found things work best for us.
If presented with a directory listing, your .git folder is exposed to the internet and you should use one of the following methods to prevent public access to this sensitive information. These methods don’t indicate that the folders exist, they produce a 404 error.
RedirectMatch 404 /\.git
Once the .htaccess file has been created or updated, save, exit your editor and restart apache:
systemctl reload apache2
Depending on your preference or access to the server, another method is to redirect using the Apache config file.
RedirectMatch 404 /.git
Restart Apache to apply the changes and activate the redirect:
systemctl reload apache2
By default, any user can access phpMyAdmin if they visit the expected URL: https://yourdomain.com/phpmyadmin/
This poses a security risk as attackers are aware of that URL and can access it without restriction.
To avoid this, take the following actions to create a new Alias and change the URL where phpMyAdmin is found.
Alias /phpmyadmin /usr/share/phpmyadmin
It is recommended to append the phpmyadmin Alias with characters from a random string generator as shown below:
Alias /phpmyadmin-f73r862b /usr/share/phpmyadmin
Once the Alias has been updated, save, exit your editor and restart apache:
systemctl reload apache2
phpMyAdmin will now be available only at the new URL: https://yourdomain.com/phpmyadmin-f73r862b/
If it is preferred that phpMyAdmin can be accessed from the internet, you can increase security by making use of the .htaccess file password capability. This prevents access to the installation folder unless the proper credentials are provided, and is in addition to the database user login required by phpMyAdmin. Follow these steps to activate .htaccess password protection.
<Directory /usr/share/phpmyadmin> Options SymLinksIfOwnerMatch DirectoryIndex index.php AllowOverride All
Next we will need to create or edit the file /usr/share/phpmyadmin/.htaccess per the example below, then save and exit:
AuthType Basic AuthName "Stay Away" AuthUserFile /etc/phpmyadmin/.htpasswd Require valid-user
Now we must create the user and password credentials with the htpasswd utility, replacing ‘username’ with the user name of your choice. When the command is run, you will be prompted to specify a new secure password to complete the setup:
htpasswd -c /etc/phpmyadmin/.htpasswd username
Restart apache to apply the changes and activate password protection:
systemctl reload apache2
As an additional or optional security measure, you can restrict access to a specific IP address, set of IP addresses or subnet of IP addresses. This is the best option in certain situations where static IP addresses are in use or internet access is not required. However, if LAN or WAN dynamic IP addresses are in use, you may find yourself locked out if an IP address changes.
IP restriction is configured in the Directory section of the file /etc/phpmyadmin/apache.conf. To deny access for all IP addresses, then grant access to a specific IP or subnet, add the following to the file making sure to use your IP information:
Order Deny,Allow Deny from All Allow from 192.168.1.1
For referance, here is a sample version of the file /etc/phpmyadmin/apache.conf with all the security edits in place:
Alias /phpmyadmin-f73r862b /usr/share/phpmyadmin <Directory /usr/share/phpmyadmin> Options SymLinksIfOwnerMatch DirectoryIndex index.php AllowOverride All # limit libapache2-mod-php to files and directories necessary by pma <IfModule mod_php7.c> php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/: ... </IfModule> Order Deny,Allow Deny from All Allow from 192.168.1.1 </Directory> # Disallow web access to directories that don't need it <Directory /usr/share/phpmyadmin/templates> Require all denied </Directory> <Directory /usr/share/phpmyadmin/libraries> Require all denied </Directory>
Restart apache to apply the changes and activate IP based access restriction:
systemctl reload apache2
Features continue to be added and refined as Blue Haze is tested on an expanding number of sites. As of release 0.9.9.4 the functionality provided by the plugin Post Template Select has been replaced by settings integrated into the Blue Haze Options dashboard that allows selecting which post types, including any custom post types, you want to be able to use the Blue Haze Dynamic Template on.
Testing of the theme for major issues and expected feature operation is now complete and Blue Haze is ready for public use. No major issues would be expected since the theme started as a branch of the existing WordPress theme Bootstrap Basicv3. Blue Haze retains and expands on the Bootstrap compatibility, offering better FontAwesome integration and optional dataTables compatibility along with a new set of features that empower authors and developers alike to build on Blue Haze without the worry of having an upgrade cause havoc to the modifications they have made, or requiring the use of child themes and plugins solely to support trouble free theme upgrades.
If you are like me, you have downloaded and messed with countless themes only to discover that none of them fit your exact needs. I am not saying Blue Haze is that one size fits all theme, that would be an unrealistic expectation on my part, since we are all looking for what we need, not what someone else thinks we need. However, having waded through countless themes, my goal is to make the Blue Haze as functional and code friendly to as many people as possible.
Besides being designed for the Classic WordPress Editor, one of the key goals was to work towards more of a universal template. Far too many themes seem to lack true control of page layout, our Blue Haze Template Options allow you to easily pick normal or full width pages. But the real functionality comes with the ability to select virtually no formatting at all, or even substitute a php file for any page’s content, up through page by page sidebar and format control. For those who may be upgrading from Bootstrap Basic, the default template is the same in Blue Haze.
Our plan is to add features based on user requests and we welcome any who wish to make suggestions or offer improvements. Another goal is true upgrade protection for those who choose to expand on Blue Haze for their own needs. We have options for you to include your own functions and css file, both safely outside the themes folders, so upgrades do not affect them. Speaking of upgrades, our theme will upgrade through the WordPress dashboard like any other theme once installed.
Like many WordPress offerings, we do not claim the code used in our theme is entirely of our own making or that we are expert coders using only the latest approved methods, in fact nothing could be further from he truth, we used examples from themes, plugins and other existing resources along with our own code and hacks to create the final product. We believe you should be able to easily follow our code should you need it as an example of how you could implement a feature, so we include notes in our code and try to make it easy to understand.