Jun 082017
 

Howdy!

I won’t be going into a whole lot of detail about sar as this has been documented elsewhere multiple times but basically, SAR stands for System Activity Report and as its name suggests, the sar command is used to collect,report & save CPU, Memory, I/O usage in Unix like operating systems. The SAR command produces reports on the fly and can also save the reports in the log files as well. The sar man page states:

The sar command writes to standard output the contents of selected cumulative activity counters in the operating system. The accounting system, based on the values in the count and interval parameters, writes information the specified number of times spaced at the specified intervals in seconds. If the interval parameter is set to zero, the sar command displays the average statistics for the time since the system was started. If the interval parameter is specified without the count parameter, then reports
are generated continuously.

Continue reading »

 Posted by at 9:57 am
Jun 062017
 

As a request comes in, it is denoted in the scoreboard. The scoreboard itself is basically a way to keep track of each incoming, waiting, and completing connections. These connections are broken down into the following types:

  1. “_” Waiting for Connection
  2. “S” Starting up
  3. “R” Reading Request
  4. “W” Sending Reply
  5. “K” Keepalive (read)
  6. “D” DNS Lookup
  7. “C” Closing connection
  8. “L” Logging
  9. “G” Gracefully finishing
  10. “I” Idle cleanup of worker
  11. “.” Open slot with no current process

Here is an example of the apache scoreboard in WHM:
Continue reading »

 Posted by at 4:24 pm
Dec 072016
 

Recently I came upon an issue on a cPanel server with suPHP as the handler in that, when the cPanel user SSH’s into the server (or connects via sFTP) any file or directory created will have incorrect permissions.

  • Files: 664
  • Directories 775
  •  
    I found this was due to a setting in /etc/profile that sets the umask value as such

    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
    else
    umask 022
    fi

     
    It has been confirmed by cPanel that this is an internal bug already known that affects suPHP servers.
    Quoted from cPanel

    I found that we have internal case EA-4868 about the same issue you are describing, which is problems with suphp and the umask permissions. I am not able to provide an ETA on when a fix for that will be released, however it will be pushed to our changelog once it is.
    changelog.cpanel.net

    So… if you have a customer that has files that were created via SSH or upload over sFTP, that are getting 664 and 775 incorrect permissions errors? First, check the PHP handler
    /usr/local/cpanel/bin/rebuild_phpconf --current

    If that setting is set to suPHP, then the workaround for this, as recommended by cPanel, is the following:
    Change /etc/profile
    vim /etc/profile
    Locate the if/else statement setting the umask, most likely around line 64

    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
    else
    umask 022
    fi
    to
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 022
    else
    umask 022
    fi

    Save the file, then connect as the user with
    su - $user

    Reload the profile; the new files and directories should be set with the correct permissions.
    As always, back up all the things first!
    Hope this helps!

    Oct 312016
     

    Hi!

    Do you have a client who says that they cannot access their sites/server and insists it’s a network issue, but their IP addresses does not seem to be blocked by csf.deny and their sites are not loading in several parts of the world with a site checker like https://www.site24x7.com/check-website-availability.html or others?

    Well do I have quite the solution for you!

    This morning, we verified an issue regarding a CSF/Spamhaus update in which CSF blocks any IP address that is over 128.0.0.0. This is due to a subnet that does not exist in the official list, 172.103.64.0/1:

    https://www.spamhaus.org/drop/drop.lasso

    Unfortunately, CSF will round the 172.103.64.0/1 down to 128.0.0.0/1 which will block all IP addresses above that range. To remedy this, after verifying the subnet issue is present, remove the SPAMDROP list file:

    rm /var/lib/csf/csf.block.SPAMDROP

    And restart CSF

    csf -r

    Restarting CSF will generate a new (and correct) SPAMDROP list without the wonky subnet.

    Now, verify the sites on the server can load now throughout the world without issue:

    https://www.site24x7.com/check-website-availability.html

    Enjoy!!!

    Sep 182016
     
    Hi all,

     

    I have been noticing quite a few issues relating to the cPanel p0f service crashing and sending e-mail notices to customers. This appears to be related to a recent cPanel update based on early reports. Fortunately, the fix is quite simple and should only require you to run the following commands:

    /scripts/check_cpanel_rpms --fix
    /scripts/restartsrv_p0f

    What is the PoF service you ask? Well cpanel says this is the Passive OS Fingerprinting Daemon

    If you are on a CentOS7 server, you also need to create an extra entry to the yum.conf excludes, I have checked and confirmed that this fix does work and should be a permanent solution.

    Edit:
    /etc/yum.conf, add p0f*
    to the exclude line. You can add it to the end if you want. It will automatically sort it in alphabetical order.
    Change:
    exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* mysql* nsd* php* proftpd* pure-ftpd* spamassassin* squirrelmail*
    to
    exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* mysql* nsd* p0f* php* proftpd* pure-ftpd* spamassassin* squirrelmail*
    and then you can run /scripts/upcp and /scripts/check_cpanel_rpms without triggering the issue again. Otherwise at the next upcp the issue will reoccur again and send out more emails about being broken.

    cPanel’s official fix to this is slightly different. They state:  “The issue happens when the EPEL yum repo is enabled. A yum update installs the p0f package from EPEL instead of the cPanel provided p0f package. To correct this, you should added p0f*.el7.* to the excludes line in /etc/yum.conf, and ran /scripts/check_cpanel_rpms –fix to get the cPanel provided p0f package installed. Then you shouldn’t have this issue again.

    So please add “p0f*.el7.*” to the excludes line instead of just “p0f*” as this will prevent this from ever updating at all, while the former entry “p0f*” should only prevent it from updating from non-cPanel sources.