How to disable excessive resource usage alert emails?

If you have CSF firewall installed in cPanel you might noticed that you’re getting an email every time some process (usually a php script) uses more than 250MB of memory (default value) or more than 1800 secoonds (also default value).

These emails are being sent by LFD service that sends excessive resource usage alerts to the email address which is assigned to it, normally to root user account. This notification points out a particular process or service using excessive server resources and helps in identifying the resource eating process/service. We can either kill/stop the process/service to free the resource or allocate more resource to it, if necessary, increase the limits or simply do nothing and wait for it to finish it’s work.

Sample LFD email message when memory is exceeded:

—Time: Mon Nov 14 09:41:10 2016 +0530
—Account: xxxxxx
—Resource: Virtual Memory Size
—Exceeded: 205 > 200 (MB)
—Executable: /usr/bin/php
—Command Line: /usr/bin/php /home/xxxxxx/public_html/index.php
—PID: 26953 (Parent PID:24974)
—Killed: No

Sample LDF email message when execution time is exceeded:

—Time: Mon Nov 14 09:41:10 2016 +0530
—Account: xxxxxx
—Resource: Virtual Memory Size
—Exceeded: 125389 > 1800 (seconds)
—Executable: /usr/bin/php
—Command Line: /usr/bin/php /home/xxxxxx/public_html/index.php
—PID: 28429 (Parent PID:26561)
—Killed: No

Getting Started
1) Login to your WHM
2) Go to Home >> select Plugins
3) Click “ConfigServer Security & Firewall”
4) Locate and click at “Firewall Configuration” button

Method 1
This method will permanently disable the LFD excessive resource usage alert and you won’t receive any more emails. Performing this method could pose a a potential security/stability issue (you have been warned! 🙂 ).

5) Modify the value of directives PT_USERMEM and PT_USERTIME to 0.

PT_USERMEM = 0
PT_USERTIME = 0

Method 2
We will increase the values of both memory and time to stop or minimize the LFD alerts. If any process/service uses more resources than defined, you will still continue to receive the LFD alerts, but hopefully less.

5) Modify the value of directives PT_USERMEM and PT_USERTIME to desired.

PT_USERMEM = 500
PT_USERTIME = 150000

Finish
Save the changes you have made and restart CSF+LFD. By doing any of these two methods above should result in getting less or no email alerts from LFD.

Tags: 1UVL, 1WMQ, CM8M, DE4U, FXNY, KBL1, WPGR, ZY7N

How to instal s3fs-fuse on CentOS 6.8?

In case you have CentOS 6.8 server (or DigitalOcean droplet/vps) and you want to install s3fs-fuse the proposed way you’ll run into a problem: the s3fs-fuse requires fuse library version 2.8.4 or higher, but your yum install fuse fuse-devel will install you fuse 2.8.3. If you are running CentOS 7 you won’t have this problem at all, since by default, yum will install fuse 2.9.2.

To fix this problem you need to remove the fuse and install it manually.

1. Remove fuse installed by yum

yum remove fuse fuse* fuse-devel

2. Install some dependencies (for both fuse and s3fs-fuse)

yum install automake gcc-c++ git libcurl-devel libxml2-devel make openssl-devel

3. Download and install latest fuse library (version 2.9.7)

cd /usr/local/src
wget https://github.com/libfuse/libfuse/releases/download/fuse-2.9.7/fuse-2.9.7.tar.gz
tar -xzvf fuse-2.9.7.tar.gz
rm -f fuse-2.9.7.tar.gz
mv fuse-2.9.7 fuse
cd fuse/
./configure --prefix=/usr
make
make install
export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/lib64/pkgconfig/
ldconfig

4. Test that fuse is installed (should return “2.9.7″)

pkg-config --modversion fuse

5. Install the s3fs-fuse (using the default instructions from github)

git clone https://github.com/s3fs-fuse/s3fs-fuse.git
cd s3fs-fuse
./autogen.sh
./configure
make
sudo make install

6. If there were no errors along the way, this should return the s3fs-fuse version (currently 1.80)

s3fs --version

Hopefully, this will help you successfully install s3fs-fuse on your system. For details on how to use it please refer to documentation at the github page. Please do not hesitate to leave your comments below! Thank you.


Installig git on CentOS 6 fails with Requires: libcurl.so.3()(64bit)

Today I had to install git on one server running on CentOS 6, but yum install git returned the following error:

Error: Package: git-1.7.12.4-1.el5.rf.x86_64 (rpmforge)
Requires: libcurl.so.3()(64bit)

To fix this bug you have to run this command:

and then confirm the removal of that package:

Loaded plugins: fastestmirror, security
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package rpmforge-release.x86_64 0:0.5.3-1.el5.rf will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================================================================================================
 Package                                                       Arch                                                Version                                                      Repository                                              Size
=============================================================================================================================================================================================================================================
Removing:
 rpmforge-release                                              x86_64                                              0.5.3-1.el5.rf                                               @rpmforge                                               13 k

Transaction Summary
=============================================================================================================================================================================================================================================
Remove        1 Package(s)

Installed size: 13 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing    : rpmforge-release-0.5.3-1.el5.rf.x86_64                                                                                                                                                                                    1/1
  Verifying  : rpmforge-release-0.5.3-1.el5.rf.x86_64                                                                                                                                                                                    1/1

Removed:
  rpmforge-release.x86_64 0:0.5.3-1.el5.rf

Complete!
[root@hosted-by boot]#

After that the standard yum install git will work just fine!


CodeIgniter white page on cPanel

After cPanel upgrade from EasyApache3 to EasyApache4 all my CodeIgniter installations just broke on that server, returning just a white page without any error message. I spent more than one hour trying to figure out what the problem is. While testing out I noticed empty files named like these “0bce68a7a37e584ace98f0fd242a237d1662613e” or “296eed9bfb533552b0c3a9c8fdd784067eea216d”   (without any extension) started popping in my project folder. I figured out that these must be session paths so something is wrong with that.

I tried enabling php error logging but it didn’t help since it didn’t log anything since all code is right and it was working before but it just stopped after I started using EasyApache4.

So I went and enabled CodeIgniter logging that proved to be a better idea. To enable it open config.php for editing, locate

$config['log_threshold'] = 0;

And change that value to 4. That will enable internal logging system and logs will be saved in /application/logs folder. What I found out just conf

ERROR - 2016-11-29 22:36:29 --> Severity: Warning --> mkdir(): Invalid path Session_files_driver.php 117
ERROR - 2016-11-29 22:36:29 --> Severity: error --> Exception: Session: Configured save path '' is not a directory, doesn't exist or cannot be created. Session_files_driver.php 119

My session save path at config.php was set to null:

$config['sess_save_path'] = NULL;

Once I got it changed to default (alternatively you can set it up to any other folder you want locally, so you can have full control over your sessions):

$config['sess_save_path'] = sys_get_temp_dir();

everything started working again! Now this is second time I have similar quiet errors with CodeIgniter where it reports absolutely nothing – instead it just gives white screen and this can be really frustrating to debug.

 


	
			
		

How to install Git on cPanel/WHM server running CentOS

Today I wanted to install Git on a server with cPanel/WHM and have got the following result:

yum install git
Resolving Dependencies
--> Running transaction check
---> Package git.x86_64 0:1.7.1-4.el6_7.1 will be installed
--> Processing Dependency: perl-Git = 1.7.1-4.el6_7.1 for package: git-1.7.1-4.el6_7.1.x86_64
--> Processing Dependency: perl(Git) for package: git-1.7.1-4.el6_7.1.x86_64
--> Processing Dependency: perl(Error) for package: git-1.7.1-4.el6_7.1.x86_64
--> Finished Dependency Resolution
Error: Package: git-1.7.1-4.el6_7.1.x86_64 (base)
           Requires: perl-Git = 1.7.1-4.el6_7.1
Error: Package: git-1.7.1-4.el6_7.1.x86_64 (base)
           Requires: perl(Git)
Error: Package: git-1.7.1-4.el6_7.1.x86_64 (base)
           Requires: perl(Error)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Then I did some research and have found out that Gis is already installed on cPanel as of version 11.36 but the problem is – it’s installed on this path:

/usr/local/cpanel/3rdparty/bin/git

So for ease of use I advise you to make a simple symlink:

ln -s /usr/local/cpanel/3rdparty/bin/git /usr/bin/git

so you don’t have to remember the path above and you can simply use it like you got used.

Note: In order for user to be able to login to SSH, it must be allowed in WHM first at Account Functions > Manage Shell Access and there  just switch from Disabled Shell to Jailed Shell.

Happy Gitting!


How to remove old kernels on RHEL/CentOS

If your /boot partition is running out of disk space this is probably because you got bunch of old Linux kernels that got stockpiled there and are no longer in use or needed for system to function normally. If you’re running a WHM/cPanel you’ll get an email with subject:  DISKWARN blocks: Mount Point “/boot” 

Usually on a system update, if there is a new Linux Kernel it will get downloaded and initialized while the last one will be kept for just in case the first one fails for any reason. In couple of months or years you could already have 5-6 of them while only the latest Linux kernel would be in use and the previous one will be kept as  a backup. Removing these by hand is possible but an mistake could end up with a system that won’t boot.

To prevent that and free up disk space at /boot partition on Red Hat Linux or CentOS Linux all you need to do is simply to execute this command:

sudo yum install yum-utils && sudo package-cleanup --oldkernels --count=2

This will remove all your old kernels keeping just the last two (latest one and the previous one just in case) so you won’t get these emails or notifications anymore and you’ll keep your /boot partition with enough free space for a new kernel to be installed once released.


Jetpack JSON API failed to activate bug solution

So, this is actually the part 2 of my problems concerning DigitalOcean WordPress 1-click-app and JetPack (about the first issue you can read here). If you read my first post you found out what I had to do in order to activate the Jetpack. All seemed fine and I could see the stats from WordPress installed on DigitalOcean droplet on my WordPress.com account and even some of the active things were working (like Photon or Contact Form).

But, when I wanted to turn on some of the Jetpack modules that I have previously turned off (or that were turned off by default) it didn’t work. For example I wanted to turn off and then turn back on JSON API at General settings tab. When I turned it off it looked like it “worked” (no error messages) but when I wanted to turn it back on I was getting following error message (and the slider won’t go to active position):

JSON API failed to activate. SyntaxError: Unexpected toket < in JSON at position 0

jetpack-json-api-bug

When trying to activate some other Jetpack module I would also get this error:

SyntaxError: JSON Parse error: Unrecognized token ‘<‘” error

I was also unable to disconnect the Jetpack using the WordPress.com account and this was only possible if I would disable Jetpack at plugins and re-enable it again. Then I would have to re-connect it with my WordPress account and it’s a loop but the results were the same. It didn’t work!

I have contacted Jetpack support but their help was similar to Microsoft support (restart the computer and try again), or in Jetpack case: disable all plugins and try reconnecting again. Since Jetpack support was unable to help me after we have exchanged couple of emails I have decided to dig deeper into this on my own. DigitalOcean community also wasn’t helpful since I found just one comment about someone having the same problem as I do but there were no reply or solution.

So I have opened Chrome debugger and have noticed that when I try to activate the JSON API it actually tries to make a POST call to url: /wp-json/jetpack/v4/module/json-api/activate:

wp-json-jetpack-404

and the result is 404 – the standard 404 page! Since there files on that path and WordPress installation doesn’t have wp-json folder at all I figured out that this is mod_rewrite path so I knew in what direction to focus my exploration. I’d like to mention here that this also happened on brand new, zero days blogs, no plugins installed, default theme: basically on out of the box WordPress installations. Also permalinks worked so mod_rewrite was working normally (or it appeared to be working normally), and that made the situation even more confusing.

Out of pure despair I tried re-enabling mod_rewrite and restarting apache:

sudo a2enmod rewrite
sudo service apache2 restart

And it FU*KIN WORKED!!! 

I have tired this on my other 5 or 6 sites hosted on DigitalOcean and it worked on all of them! I hope that some one from Jetpack or some geeks from DigitalOcean will see this post. I’d love to hear more about this issue. How is possible that mod_rewrite is working without being enabled on Apache or if it’s enabled why it doesn’t work for Jetpack plugin? I’m puzzled and I’d like some explanation.

Also I have one more bug that I don’t know how to solve. When I login to these WordPress admins I have this error on every (admin) page I load in my debugger:

Uncaught TypeError: Cannot read property ‘type’ of undefined(…)

This traces back to https://widgets.wp.com/notifications/webpack:/webpack/bootstrap_905f… as you can see in detail on this screenshot:

cannot-read-property-type-of-undefined-bootstra-bug

Update: 05th December 2016
Now Jetpack is works normally on my DigitalOcean droplets, but on some occasions while setting up the Jetpack options I saw this message: Warning! Multibyte support missing!

wp-multibyte

This means that multi-byte support php module was not installed. To get it installed simply install package php-mbstring using apt-get (or yum in case you’re using CentOS/RHEL Linux), restart Apache and you’re good to go!

sudo apt-get install php-mbstring
sudo service apache2 restart

PHP multibyte should now be installed and these messages should no longer appear.


JetPack can’t connect to DigitalOcean WordPress 1-click app installation

You made your WordPress blog using DigitalOcean 1-click apps, you have installed Jetpack WordPress plugin but you can’t activate. Instead you’re getting this message:

Error Details: The Jetpack server was unable to communicate with your site [HTTP 500]. Ask your web host if they allow connections from WordPress.com…

jetpack

But the problem is not with the communication between WordPress.com and your DigitalOcean droplet. The problem is with the fact that following php modules were not installed: php7.0-xml and php7.0-xmlrpc.

No we can argue why these were not installed by default: it might be due the fact that this way WordPress XML-RPC will not function and this would automatically reduce the amounts of spam on your blog (more likely) or that that the system would perform (slightly) better without these two modules (less likely) but in order for JetPack to work we need to install these two modules and to restart the apache.

Here are the commands you need to execute in console in order for it to work:

sudo apt-get install php7.0-xml php7.0-xmlrpc
sudo service apache2 restart

 

After you have done this logout out of your WordPress, then login back again and try once again to connect your Jetpack plugin. I hope it will work out for you since it just did it for me on more than 10 different droplets!


How to add SSH key to existing DigitalOcean droplet

Logging in to your DigitalOcean droplets is more secure if you use SSH keys compared to using root password. Today, I had to add my key to existing droplet (running over 3 years now) and to a droplet I have just created and setup everything on it but forgot to add a SSH Key to it. And just for the record I’m using Windows computer at the moment and the key is generated by PuttyGen. You should already have your SSH key pair: private and public SSH key before you proceed with this guide. I know that doing the same thing on Mac (or Linux) is much easier and all you would have to do is just execute one line of code in Terminal, but again I’m currently using Windows and this tutorial is intended for Windows users. Also note that this same guide will also work in case you have a dedicated server or a VPS at any other provider.

So, how do you add a SSH key after creating a droplet? I went to numerous replays on DO community but haven’t found the correct answer. To make this work first you need to open your favorite text editor: Notepad++, Sublime, Atom any of these editors is just fine (as long you don’t use MS Word). Now copy/paste your public key text in it.

So here is how a Public Key looks like:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20161012
AAAAB3NzaC1yc2EAAAABJQAAAQEAkBUbfyu0amE+uld7dk9LJnJytmVf8qx4TBvT
0jCYKfNKJj2io8Jh3gB5Lyqhk2xMmPfthn2d/uRbIESmxN3DNE8NbD5Wubr0Q15i
ihAkn0qpxV8HodTONiwGP5GhFJqEe0ThHVa8w13oah/UYqH/a40/N/LaOaTcMaC/
V6hGQhCE+mCz5tmVsQm2CarNdWZffIYhHLDiSgd4DY609UKnA5LQAV1/cHK1FYVE
qiKISpoNZBJ8a0ZOn/a98fVqv7BnxHwvszDJ7Kwusx3ejJVDN2EykfT+SMXSjehX
Ly7ytRW8a7xSHwxa8yR+7lAcdgyrQryWUfBvDce1hdpk1M4sOQ==
---- END SSH2 PUBLIC KEY ----

Please note that this is not my actual public key and I have generated this one just for the purpose of creating this post. So it’s useless and don’t use it for anything.

Now you need to get rid of first two lines (—- BEGIN SSH2… and Comment …) and the last line (—- END SSH2…) and that will give us just our key but still that key is divided into 6 lines and we need it in one single line. So go now and make that a single line. If you don’t know how to do it in Notepad++ open Search and Replace by pressing CTRL+H and set search for \n, replace that with nothing, set search mode to Extended and click on Replace All. Here’s an screenshot to help you out with that:

notepad-plus-plus-seach-and-replace

The result should be a single line of code (if word wrapping is not turned on). Now before that just add rsa-ssh and one space after that word. The resulting key should look something like this:

rsa-ssh AAAAB3NzaC1yc2EAAAABJQAAAQEAkBUbfyu0amE+uld7dk9LJnJytmVf8qx4TBvT0jCYKfNKJj2io8Jh3gB5Lyqhk2xMmPfthn2d/uRbIESmxN3DNE8NbD5Wubr0Q15iihAkn0qpxV8HodTONiwGP5GhFJqEe0ThHVa8w13oah/UYqH/a40/N/LaOaTcMaC/V6hGQhCE+mCz5tmVsQm2CarNdWZffIYhHLDiSgd4DY609UKnA5LQAV1/cHK1FYVEqiKISpoNZBJ8a0ZOn/a98fVqv7BnxHwvszDJ7Kwusx3ejJVDN2EykfT+SMXSjehXLy7ytRW8a7xSHwxa8yR+7lAcdgyrQryWUfBvDce1hdpk1M4sOQ==

Now you need to copy that line of code into your ~/.ssh/authorized_keys. The absolute path is /root/.ssh/authorized_keys and you can edit that in any editor you like and just add that line below existing lines (or replacing some of your old/previous keys). You need to save the changes and you’re done! Now you can login to your droplet or your webserver with your private SSH Key.


How to safely install git on cPanel/WHM?

GIT is popular version control system for software development and it’s really common today. Installation on servers without cPanel is pretty simple but on servers that do have cPanel can be tricky because git installs it’s own Perl libraries and that can cause many problems and conflicts and often results in unusable WHM server in the end.

So whatever you do – do not install GIT!
I repeat: DO NOT INSTALL GIT ON WHM SERVER!

Because it’s already installed 🙂
It’s just not in path and you can’t use it.

There are two ways of doing this:
1. WHM/root way that will make git available to all users on the system
2. cPanel way that will make git available only for the current account

Hot to enable it in WHM?
To make git usable to all users (with ssh access) just execute this single line of code as root:

ln -s /usr/local/cpanel/3rdparty/bin/git /usr/local/bin/git

How to enable it in cPanel?
If you are using a shared (or reseller) hosting powered by cPanel (and you don’t have WHM access) than you need to login using SSH and locate your .bashrc file. It should be in your home directory. Open that file for editing and add git to your path by adding following two lines of code at the end of your .bashrc file:

PATH=$PATH:/usr/local/cpanel/3rdparty/bin 
export PATH

To edit that file enter: nano .bashrc
After you add these two lines your .bashrc file should look like this:

bashrc-git-path

To save the changes press CTRL+X , then press Y and Enter. In order for changes to be accepted it will be necessary to re-log in to your SSH command prompt.

How to check if git now works on cPanel?
Well, that’s really simple. Just login to SSH and execute: git –version
and that should return git version (currently cPanel git is version 2.6.1)

That’s it!
Nice and simple.
Happy giting…