So my Last.fm records plugin that is built-in or implemented with this amazing theme broke after I upgraded it, so I checked and it seems the whole plugin is now using jQuery. I have had to do some modifications to make it work, I hope this helps.

FIrst, you need to add this in your wp-content/themes/absynthe/header.php right after <![endif]-->.

<script type='text/javascript' src='/wp-includes/js/jquery/jquery.js'></script>

After that, you need to edit wp-content/themes/absynthe/footer.php and replace this:

if (function_exists('lastfmrecords_display')) {
lastfmrecords_display();
}
?>

By this:

<div id="lastfmrecords"></div>

Once you’ve made those changes, go to Settings > Last.fm Records, make sure that the CSS is disabled else it won’t look pretty and make sure the placeholder is set to “lastfmrecords”.

Enjoy

I will let the developer of this theme know so he can fix this too.

This little script disables mod_security on specific domains that you pick, mod_security2 does not allow disabling it from .htaccess and it’s pretty annoying to do the same work all over and over again, why not make it one line only.

Introducing, disable_modsec — Enjoy lazy cPanel server admins.

#!/usr/bin/perl

# Enable vHost includes
system ('/scripts/ensure_vhost_includes --user='.$username);
} else {
print("Usage: disable_modsec [domain]\n");
}

First of all, telnet to your switch, these instructions are for Cisco switches, that’s all I ever worked with anyways, heh. All those instructions use IOS.

First of all you need to pick the port that you’ll be working on, make sure you have physical access to the server you’re going to be working with, I’m not responsible for some settings going poof and you having to drive down to your data center to fix the issue.

So, the interface that I will be working with is FastEthernet1/8 — Enter configuration mode and go to the port

conf t
int FastEthernet1/8

Enable trunking and 801q capsulation

switchport mode trunk
switchport trunk encapsulation dot1Q
switchport trunk native vlan 1000

Make sure the native VLAN is the same VLAN that the network was running on previously, read more information why here:

To establish 802.1q trunking both sides must be in the same native VLAN this is because the encapsulation is not setup yet and the 2 switches must talk over an un-encapsulated link (native VLAN) to setup the encapsulation in the first place. Why this works is because neither side is encapsulating packets with its VLAN tag since they are both talking over their native VLAN, basicly neither side knows that the other side is in a different VLAN to begin with and they are just sending unencapsulated packets back and forth. So if you set a port on the core switch as native vlan 5 for example and connected a dumb switch to it vlan 5 traffic would go un encapsulated to the dumb switch and it can understand it but it will put it in its VLAN 1 ports there is no actual trunking going on. No 802.1q or ISL!
juniperr @ DevShed

Alert: not_in_list_of_allowed_ip [xx.xx.xx.xx]

The IP of the client is located at the “xx.xx.xx.xx” part, this is easily fixed by clearing the block list on the server with this command (on the main node), you must replace the user.vm part by the username of the client at HyperVM (most of the time, something.vm).

/script/clearallowedblockedip --class=client --name=user.vm

It should return something like the following:

AllowedIp Sucessfully cleared for client:user.vm

Afterwards, the client/you should be able to login with no problem at all.

/usr/local/cpanel/bin/update-horde --force

Also, this might be useful to run hourly, I leave this on our servers “just in case”.

(mysqlcheck --auto-repair eximstats ; mysqlcheck --auto-repair horde) >/dev/null 2>/dev/null

The only small modification is that now, it deletes all sess_* files that have not been accessed for 5 days therefore are probably just sitting there and never going to be used again, the rest remain deleted because it’s failed uploads/etc that will never be used again.


#!/bin/bash

# Clean up failed ImageMagick conversions.
ls | grep 'magick*' | xargs rm -fv


Thanks!

Why? Because MySQL leaves and uses it’s temporary files in /tmp, and if there is no space in there, queries will start failing. Uploads from PHP or Perl are placed in there till the upload process is over, they cannot be further placed there because there is no more space left. So far, we have failing MySQL & inability to upload complete PHP files, system administrator hell.

Easy fix, you might say? Just a simply rm -rf / should take care of it? Nope. Try that, have fun trying to fix the sockets you deleted, specifically applications that depend on the mysql.sock placed in your /tmp directory, things just got worse. In case you actually did delete everything, just restart the services, they should re-appear, if they don’t, they should be somewhere else and you have to create a symbolic link using li, MySQL’s socket is usually located at /var/lib/mysql/mysql.sock.

The best way is to either have a script that cleans it up hourly if you know what usually fills it up or manually run ls -alhS /tmp | head and looking what’s causing the problem and how to avoid it in the future, I have developed a script that I run on multiple servers with no problems at the moment. It takes care of the most trash caused on a cPanel server

#!/bin/bash

# Clean up failed ImageMagick conversions.
ls | grep 'magick*' | xargs rm -fv

That usually is enough, my suggestion is to have that run as a cronjob every hour, but I’m not going in detail on how to do that, because if you don’t know how to setup a cronjob, perhaps you shouldn’t be messing around in /tmp directories and deleting stuff on the first place!

Update: This script is faulty and will cause you a lot of problems with PHP sessions, please read more information and read the new one here

On this other side, Adaptec has been great.  We’ve been using them for a while now and see no problems at all, however there is just a small catch, Linux usually has a SCSI subsystem timeout of less than 30 seconds which results in a small difference between the controller timeout (at 35 seconds) versus the Linux timeout (at 30 seconds).  This usually brings a server to a halt for a couple of seconds (and minutes in cases) till the server recovers, errors like this are thrown in the console:

aacraid: Host adapter abort request (0,1,3,0)
aacraid: Host adapter abort request (0,1,1,0)
aacraid: Host adapter abort request (0,1,2,0)
aacraid: Host adapter abort request (0,1,1,0)
aacraid: Host adapter abort request (0,1,2,0)
aacraid: Host adapter reset request. SCSI hang ?

The best method that usually works best is to increase the timeout higher than 45 to ensure that the Linux timeout does not occur before the RAID controller timeout, this is done per device / array.

echo '45' > /sys/block/sda/device/timeout
echo '45' > /sys/block/sdb/device/timeout
echo '45' > /sys/block/sdc/device/timeout

This should be done to every device, 45 is a good number however you can use what you’d like as long as it’s over 35. If you’re experiencing issues with loads going sky-high with no apparent reason, this might very well be the reason, to check if this is a possible cause, you can run the following

dmesg | grep aacraid

If you see errors like the ones that I have up there, then I suggest using that small workaround, if even after using the workaround, you’re still facing these problems, here are the suggestions/checklist that Adaptec suggests:

• Check for any updated firmware for the motherboard, controller, targets and enclosure on the respective manufacturer’s web sites.
• Check per-device queue depth in SYSFS to make sure it is reasonable.
• Engage disk drive manufacturer’s technical support department to check through compatibility or drive class issues.
• Engage enclosure manufacturer’s technical support department to check through compatibility issues.

Anyhow, just like with every Linux issue, your mileage may vary, so if you know of any other fixes or figured out a way how to fix this, feel free to post it as a comment to help others.

So I decided to change it, I get the monitor & keyboard and start messing. It sounded pretty simple, we have a service called ifaliases that activates all the other IPs by creating aliases (duh!). I edited that file to make the main interface eth0 instead of eth1, unplug from Port 2, plug in Port 1, wait a couple of minutes, …, still unpingable, ugh.

I tried to ping other servers in the same subnet, I was able to ping them. I checked the route table and it seems there was no default route for all traffic, I created a custom route and the network started to work, but the problem is that every time the interface is restarted, the route table would need to be recreated, blah blah, it’s a dumb idea.

I looked everywhere until I found the magical file: /etc/sysconfig/network — The contents of it look something like this:

NETWORKING=yes
GATEWAY=the.gw.ip.here
GATEWAYDEV=eth1
HOSTNAME=host.domain.com
DOMAINNAME=domain.com

It was pretty simple from there, change the GATEWAYDEV to the new port and voilà. So the next time you are trying to change ports or the default route won’t stick, I hope I helped!

With every cPanel installation, there is a binary located at /usr/local/cpanel/bin/cpuwatch, what cpuwatch does is that it executes the command and monitors the load, if the load goes past the set limit, it will stop the application and resume it after the load averages are below the threshold for a few seconds, the usage for it is very simply

cpuwatch (<-p PID>| [arguments])
maxload : system load at which throttling should commence
command : command to run under cpuwatch
-p PID : monitor and throttle the existing process PID

Another neat feature is that it can fork a new process or attach itself to a running process, here is an example of deleting an account using SSH and setting the load average threshold to 4.0

/usr/local/cpanel/bin/cpuwatch 4.0 /scripts/killacct username

The load average will go past 4 however the process will stop running as it goes past that limit, if you already have a process running and you do not want to restart it all, you can run the following command to attach it to the process, in this case, the process ID of my process is 18274.

/usr/local/cpanel/bin/cpuwatch 4.0 -p 18274

It’s a very simple but very neat utility that has saved me a few times where I had to do major file operations and did not want the server to have high load averages, this same binary is also used when the logs are running for cPanel and as well as when the cPanel backups are running.