With WordPress the wp-login.php and as a result wp-admin pages are always under attack. To protect the backend of wordpress using an unique username (dont use admin or other simple names) and a strong password of course is the first line of defense. Next well ... keeping wordpress up to date, then well.... plugins to add in many related security items (but adds overhead), then well... moving wp-config.php. OK OK so there are many things to secure the site. This is for a simple way to protect the wp-admin and wp-login.php page from basic bot attacks.
This method will display a basic http auth page when access wp-admin or wp-login.php. This greatly cuts down on server resource usage and will greatly stop most all malicious bot activity trying to brute force login. This can be used server wide in an include to protect many sites, or used for just 1 site. (But if you want it for just 1 site, if you are using a control panel most likely it has some soft of built in tool to do this for you)
In an Include file for apache add:
This is a basic .htpasswd setup. The things to change would be where the AuthUserFile is located if you do not want to place it at /home/htpasswd . This should not be in the document root of the site.
Then the .htpasswd file needs to be generated.
For other server types you just need to find the path to the htpasswd binary if it is not in one of those locations. This will prompt for a password after the user is given. If you need to add more usernames:
Multiple people could share the same login for this, this way that aspect is simple to remember, but bots will not have much impact. This does not change the actual wp-admin or wp-login.php aspects though. After the first login a user will still have the normal login screen and have to provide a normal valid wordpress user to get in.
With cPanel offering autossl to provide any site with DNS that points to the server with a free SSL this has been great for many domains, however many people use CloudFlare as a caching service and the proxy aspect of their service the IP of the site no longer points to the server and thus will not process the request properly for the DCV verification. Just recently cPanel did add in the option for DNS verification, but the bulk many people this will not be a seamless option for them and the text file verification will be still for a long time to come the AutoSSL main verification method. This will work for either type of SSL support in cPanel, cPanle/Comodo and Letsencrypt.
In Cloudflare you will need to make these changes:
On the Crypto Tab (padlock icon) set:
Then under Page Rules (funnel icon) you will need to add 2 rules the first being one of the following:
The next rule is:
The first rule you will chose depending on which system you are on, by default this will be cPanel/Comodo. However many people do enable Letsencrypt as it can issue a SSL very quickly. The first part is the path for the DCV text file they make. Then it will disable the SSL support and keep it from rewriting as well. This will allow it to properly read the site when it has no SSL added yet. The second rule then re-enables SSL support.
This would need to be done for each domain you own and run under Cloudflare. This will allow you to run Cloudflare in Full Strict SSL support as both ends will have a valid working SSL for use with the domain.
In cPanel by default any addon domain or subdomain will share the IP of the main domain / account it was made under. But what if you wanted a dedicated IP? This can be done but not within cPanel and allow it to be cPanel friendly! This will require SSH access and some editing via the command line and a rebuild of the apache config.
First SSH into the server and browse over and edit to (replacing $user and $domain with what you wish to modify) :
In this file you can modify the IP of the subdomain or addon domain. The contents of the file will look like this:
Now you can change the IP to that of another IP on the server that is not being used (If you are doing this for SSL purposes this IS key that the IP is not already in use or else WHM will not allow you to install the cert and would have to do it manually as I described in: https://mosmostech.com/2011/09/wildcard-ssl-certs-and-cpanel/ )
After the change save the work and you will need to rebuild the apache config and restart apache (with a backup of the config to be safe):
You should be all set to use the new IP. Just update your DNS manually to point to the proper IP. Doing this will not allow cPanel to make changes for you on IP functions or DNS functions so you must keep that in mind down the road.
This is very much related to my other article on changing document roots https://mosmostech.com/2011/12/changing-a-cpanel-document-root-docroot/
Using .htaccess you can do many things. This small tidbit will focus on removing and rewriting (mask, hide) the subfolder aspect on a URL to only have the base domain present. You will want to create a .htaccess file if one is not present already in your public_html (or main doc root) for the site.
Yes I like nano! got something with it? Ha. Use whatever you like such as VIM if you prefer. Next you will add the following text to the file.
This will assume you have http://domain.com/sub as where the content you want to load is. And the resulting URL to only show http://domain.com butstill load the content in in the /sub folder. This could be modified many ways to suit the needs for the application at hand.
How to change a document root ( docroot / webroot / where you put your files so they can be seen online) for a cPanel account is something that pops up from time to time. Or in my case a few times this week already, so I decided to write a quick little post on how to do this. For whatever reason cPanel does not allow an easy way to change a docroot. However you can specify a docroot if making a subdomain, even outside the public_html for the user. But cPanel does not have this option anywhere for the main user itself. This can be needed at times for development uses, just to point to a folder and not use the normal public_html, or avoid using rewrite/redirect rules, or fixing an issue that was caused by a manual install of something like an SSL on a subdomin.
As cpanel does not have a nice way to do this you will need to SSH into the server as root and make some modifications. Many people will assume you can just edit the httpd.conf file to change the docroot for a given domain. (EA3 /usr/local/apache/conf/httpd.conf or EA4 /etc/apache2/conf/httpd.conf/) But in a cPanel environment this will cause issues down the road as the apache config file is rebuild on a regular basis for many types of updates. So doing any hand edits to httpd.conf is a very bad idea in cpanel. Remember folks it is cPanel's way or the highway!
The proper file and path to edit would be:
Replace $user and $domain.com with the proper cpanel user and domain to change. If they have an SSL there will also be a $domain.com_SSL datafile. Edit this with your fav editor. The line you are looking for is:
You can now change this to whatever is needed. Save the file and exit. To ensure all is fine we will rebuild the apache config file using this information cPanel has stored and restart apache after a backup of the config:
You should now be using the new docroot for this domain. Now some people may just say modify the .htaccess and add some redirect/rewrite rules there. This will work if you are keeping the docroot in the public_html. But if you are placing it outside this location or just dont want to mess with creating rules which for many is confusing you can just do it this way and it will play well with cPanel.
Using cPanel? Great it helps with a lot of things for a non linux admin to be up and running. But SSLs it is cPanel's way or the highway! But if you have a wildcard SSL cert you can use in it a couple of ways! One is easy if you are starting out fresh (lot more of a pain if you are not). The second requires use of SSH and the command line (CLI)
1: The best way in cPanel would be to create each subdomain as a stand alone account with a dedicated IP. Doing it this way would allow the wildcard cert to install with almost no issues just as a normal SSL install would be done via WHM (Web Host Manager). Just change the domain name field in the install section from *.domain.com to sub.domain.com. And make sure you put in the right username for the sub domain account you are currently installing for. This will be the case for the IP also usually it put just 0 for the IP field, just put the dedicated IP in.
2: Now for the tricky way. A single account with the subdomains under it sharing a dediated IP. First install the wildcard SSL cert for the main domain. Follow the method above to install it, but use just domain.com instead of *.domain.com or sub.domain.com. Make sure the IP is correct and the username is the user for the domain account (see below if the account is using the main shared IP). It should install fine. Now for the fun part. SSH into the server and navigate to:
You will be editing the apache conf file httpd.conf (yes I use nano got a problem with it mister pretty VIM?)
In here you will find the SSL based vhost you just made via WHM. Browse down to domain.com in the IP:443 (SSL port) section and copy it. It would look something like this (PROTIP: do not copy my example use the actual one from your server):
Now we will copy this to the pre_virtualhost_global.conf file.
Once copied we will need to edit this file to match the subdoain you are adding the wildcard SSL support for. Only the SSL section will not change as this is using the same cert file as it is a wildcard. Main things to get will be ServerName, ServerAlias, and DocumentRoot. You will also want to make sure the names and paths to the log files have been modified unless you hate logs.
You will also want to ensure in the main httpd.conf file under the NameVirtualHost sections there is one listed for your IP:443 . If this doesnt exist you will want to add it to the include file as well above the vhosts you created.
Restart apache and you should be all set.
The reason for adding this to the includes/pre_main_global.conf is to keep cpanel from modifying or removing the vhost. As we all know if you hand edit the apache httpd.conf file cPanel will not be happy and just undue your changes the next update and or rebuild. That is why they give us the include files options for vhosts and the config as a whole.
If The domain is on the main shared IP the process is mainly the same. The initial install will be install the cert under the "nobody" user as WHM will not allow a SSL to be installed on the main shared IP unless it is the apache user "nobody". When you then make the vhosts make sure to change all of the "nobody" references to the user of the account. This will include SUEXEC and SuPHP primarily but it can be others depending on your setup. Also you will need to edit the main httpd.conf and modify the initial install for the mina domain's 443 vhost entry and change the "nobody" references to the user in question. After that distill the apache conf:
You can then test to make sure it remembered the setting by rebuilding the conf and restarting apache:
Now check the httpd.conf to make sure the 443 vhost did not revert to having the nobody user listed.
Now this wouldn't be an issue on a non cPanel box using a wildcard SSL as in the rest of the linux world shared IPs do not matter. It is done this way in cPanel to to it being able to easily help you manage. But on the bright side once you do this you have a nice template and can inside of WHM-Apache Configuration-Included Editor-Pre VirtualHost Include
you can copy and edit to add a new subdomain. Another thing to note if your current setup could be a mix of the above to use a single wildcard SSL cert. Just install each subdomain as for what is fitting for that situation.
So you want to test an upload in linux and need a file to test with? That test also needs to be 20megs in size? Well good news everybody this can easily be done in linux. Using the command "dd" does low level coping of data. It can create a wide variety of files and can be used to destroy systems to backing up boot sectors and everything in between. Now on to the test file creation!
This will create a file called test20mb.zip It will be filled with just nothing (null/zeros). Using a block size of 1024. It will then seek for a given number of times. In this case 1024 * 20. 1 mb * 20.
200 mb .img
15 mb .doc
8 mb .jpg
Creating these on the fly or having a set already made can make it much easier to test upload and sending issues you might come across. But at times you still will need a legit working file and need to find something that fots for the size and type you are testing.
So you just updated your cPanel server to a new version of MYSQL or cPanel just decided to stop working properly. And now when you made a user in cPanel for a MYSQL database it does not appear to work. You are sure the password is correct and still getting access denied? Good chance cPanel did not set the privileges even though the check mark box was cleared selected. Just on the back end it did not assign the privileges using the GRANT command in MYSQL. So any automated scripts like Fantastico or Softaculous or manually creating a DB user will fail.
So how do i fix this? Glad you asked! Rebuild Perl on the server for cPanel!
Note this will take a long time. Could be easily over an hour. But once it is complete cPanel should be GRANTing permissions properly for MSQL DB users. If you dont want to recreate a user that was affected by this just assign them to the same DB again and it will prompt for what privileges it should have again but this time actually set them!
If you are using Django and wish to check what version it is using you can issue the following from the command line in linux.
This will launch python, and you should be at a prompt such as >>> . Enter the next 2 commands. To exit python press CTRL-D.
On a side note if you wish to know the python version also run the following:
(Update 6-12-2011: Meego 1.2 was released on 5-19-2011, and nothing has changed in this setup, so this guide still applies to getting your broadcom wireless chipset to run. Thus why it it named ".. and above" )
So you are running the newest Meego OS for your netbook, ( wait you are not? Then you should! ) and you have a netbook using a Broadcom wireless device you will see wireless does not work. Well since Meego (and Moblin before that) is in part a project of Intel, only Intel chipsets are supported out of the box (which is a very large number of netbooks). But if you are like me and own an HP netbook (1030NR) then the Broadcom chipset for wireless will not work and you need to find or build your own driver.
In the past I had looked to Slaine.org and Andy Bleaden for help with this issue. Slaine would build his own driver and provide it to users to install. While Andy, did very nice job showing how to build your own. And using this method it will always work without waiting for someone to compile some drivers and package them.
So here I am today. Meego just pushed out 1.1.4. This included a new Linux kernel also. Which means my wifi no longer works. So I am writing this as a more copy and paste (with some manual changes) to allow me to rebuild the driver and install it again quickly. (If you want pictures go see Andy Bleaden's blog).
First make sure to hook up the network for a wired ethernet connection (remember wireless doesnt work) and for good measure make sure you have the power adapter pluged in (dont want it to die on you in the middle of your work). Now open a terminal up. (Applications -> System Tools)
Next go ahead and download the Broadcom drivers from their website DRIVERS ( http://www.broadcom.com/support/802.11/linux_sta.php ) It would be useless to link to this as they will change, but as of this post the current ones are 184.108.40.206 file name hybrid-portsrc_x86_32-v5_100_82_38.tar.gz . Keep in mind where you downloaded this driver. By default it should be in /home/your-username/Downloads . If you used wget then whatever folder you were in as you ran the command.
Now for some commands (in the boxes with what the command does on the next line):
(switch to the folder you downloaded the driver in)
(make sure you are up to date)
(get the tools to be able to build the driver)
(make a folder to work in)
(move the driver to the wireless folder)
(extract the driver from the compressed archive, protip: type hyb and hit tab)
(start fresh and then create the wireless driver)
(this will give you the linux kernel number you are currently running)
(copy the new driver to the wireless folder for the kernel, ie 220.127.116.11-17.1-netbook)
(kernel dependency stuff)
You should see right away you now have wireless! (no reboot needed) Now the next time Meego updates you can quickly and easily get your wireless up and running again using the official Broadcom drivers.