Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Darkroom

Pages: [1]
1
Backup / bug in backup scripts for upgraded CWP 6 users
« on: December 07, 2017, 03:13:30 AM »
Soon, I just found out from restoring a daily backup that my backups had not been running since March 15th 2017. I went to the cron.daily/cwp script:

/usr/local/cwp/php54/bin/php -d max_execution_time=1000000 -q /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php

This throw the error:

PHP Fatal error: 
The file /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php was encoded
with the PHP 5.6 ionCube Encoder and requires PHP 5.6 to be installed.
 in Unknown on line 0

switching it to:
usr/local/cwp/php71/bin/php -d max_execution_time=1000000 -q /usr/local/cwpsrv/htdocs/resources/admin/include/cron_backup.php

fixed it. But discovering this has been most unpleasant. So if you have an older CWP system in production, check your backups.

Server:
CPU Model: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz
CPU Details: 8 Core (2500 MHz)
Distro Name: CentOS release 6.9 (Final)
Kernel Version: 2.6.32-696.13.2.el6.x86_64
Platform: x86_64 [Dedicated]
CWP version: 0.9.8.273 [Get CWPpro]

2
CentOS 6 Problems / dentry eats tons of ram.
« on: September 23, 2017, 05:56:51 PM »
Ok, I've been battling this issue for over a year and I think I've finally narrowed it down. My server just serving a couple low traffic sites (wordpress) would add about 1gb of 'used' ram per day. I switched to a different, same model Dell CS24-SC server, and the problem followed to the new server.When the server sits at home with no traffic, it's fine with traffic 1gb/day. Then I added a medium-ish traffic website and my memory usage went up to 2gb/day. And this is the memory minus cache, in cap and free -m it's showing up as in use.  I never let it use all the ram, but I would reboot the server around 40/48GB of memory used (and there's only 12gb of files on the hole server!) and it would go back down and start ramping up again.

So I was poking around in /proc for some answers and found slab to be using a ton of memory:
cat /proc/meminfo
...
Slab:           33204524 kB
SReclaimable:   33168504 kB

Then slab top showed me

slabtop --s c -o
...
165121860 165121823  99%    0.19K 8256093       20  33024372K dentry

Whoah! 30GB of directory structure cache? That doesn't even make sense. I haven't changed anything in /proc/sys/vm/ aside from a sync; echo 2 > /proc/sys/vm/drop_caches (I know next time I'll stop sol before doing this) which take my memory usage back to 1GB. my /proc/sys/vm/vfs_cache_pressure its set at the 'normal' 100, swapiness is still 60 ¯\_(ツ)_/¯ no idea dentry is eating this much ram. At least now I can fix the problem without rebooting but it'd be nice if the problem didn't occur in the first place. Anyone have any suggestions?

Server info:
Apache version: Apache/2.4.27
PHP version: 5.6.27 [PHP Switcher]
MySQL version: 5.5.54
FTP version: 1.0.36
System Info

CPU Model: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz
CPU Details: 8 Core (2500 MHz)
Distro Name: CentOS release 6.9 (Final)
Kernel Version: 2.6.32-696.10.1.el6.x86_64
Platform: x86_64 [Dedicated]
Uptime: 22 days, 15:47
Server Time: Sat Sep 23 13:30:12 EDT 2017

CWP info
CWP version: 0.9.8.267

3
Over 200 of them! Anybody else seeing this? Are they necessary? Some are created on different days but at the same time that day give or take.  ???

Code: [Select]
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.10
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.100
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.101
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.102
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.103
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.104
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.105
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.106
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.107
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.108
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.109
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.11
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.110
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.111
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.112
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.113
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.114
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.115
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.116
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.117
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.118
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.119
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.12
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.120
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.121
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.122
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.123
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.124
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.125
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.126
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.127
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.128
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.129
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.13
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.130
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.131
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.132
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.133
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.134
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.135
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.136
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.137
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.138
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.139
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.14
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.140
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.141
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.142
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.143
-rw-r--r--   1 root root 8.7M Sep 29 11:16 ioncube_loaders_lin_x86-64.tar.gz.144
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.145
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.146
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.147
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.148
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.149
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.15
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.150
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.151
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.152
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.153
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.154
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.155
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.156
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.157
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.158
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.159
-rw-r--r--   1 root root 8.7M Sep 16 09:35 ioncube_loaders_lin_x86-64.tar.gz.16
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.160
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.161
-rw-r--r--   1 root root 8.7M Oct  7 09:40 ioncube_loaders_lin_x86-64.tar.gz.162

4
E-Mail / InnoDB error in maillog
« on: September 18, 2016, 06:13:38 PM »
In /var/log/maillog I'm seeing a lot of these:
Sep 17 23:31:14 srv1 postfix/proxymap[4575]: warning: mysql query failed: Unknown table engine 'InnoDB'

A user complained it took 2hrs to receive an email and I'm wondering if this has something to do with it? I know CWP usually uses an older version of SQL that uses MySam and attempts to but InnoDB directives in my.cnf have always errored out on me.

So..... what's up with that?

5
PHP / php-cgi segfaults on libselinux?
« on: March 17, 2016, 08:03:48 PM »
I was just checking my dmesg and saw these errors:
Code: [Select]
php-cgi[28804]: segfault at 7fe02fd6005e ip 00007fe02fd6005e sp 00007fe01bc55db8 error 14
php-cgi[28806]: segfault at 7fe02fd6005e ip 00007fe02fd6005e sp 00007fe01a853db8 error 14
php-cgi[28805]: segfault at 7fe02fd60062 ip 00007fe02fd60062 sp 00007fe01b254db8 error 14 in libselinux.so.1[7fe0322ff000+1d000]
 in libselinux.so.1[7fe0322ff000+1d000] in libselinux.so.1[7fe0322ff000+1d000]
[7f5ccd468000+1d000]

Weird thing is I have SELinux set to disabled. Any ideas? I don't even know where to start, maybe yum reinstall?

6
Suggestions / Cloud Storage module?
« on: January 16, 2016, 04:45:58 PM »
I was thinking that these days its possible to have TBs of storage on your server, even in RAID configs pretty easily. It'd be awesome to use/sell some of that as a cloud storage. I was looking around and it seems like SeaFile looks like a pretty legit OS player in this field. Maybe in a future CWP?
https://www.seafile.com/

7
Postfix / How do you remove DKIM and ClamD?
« on: January 09, 2016, 08:42:41 PM »
I had to rebuild my postfix and followed the recommendations and it broke my mail service. Unchecking the boxes and rebuilding doesn't do anything and postfix still tries to use DKIM even if the service is stopped. While I suppose yum can uninstall both are there any postfix settings that would need to be changed?

8
Postfix / Postfix Won't Start
« on: January 04, 2016, 04:51:12 PM »
Or perhaps more accurately thinks it starts with an [ ok ] but dies right away. Maillot says:
Jan  4 11:30:53 localhost postfix/postfix-script[18726]: starting the Postfix mail system
Jan  4 11:30:53 localhost postfix/master[18727]: warning: could allocate space for only 100 open files
Jan  4 11:30:53 localhost postfix/master[18727]: warning: inet_addr_host: skipping address family 2: Too many open files
Jan  4 11:30:53 localhost postfix/master[18727]: fatal: /etc/postfix/master.cf: line 90: bad hostname or network address: 127.0.0.1:10025


A little back story. My server is using waaaaay too much RAM, 13.5GB not including cache and I don't think I have that much on the server including the OS and backups! (DF -h says I've got about 5GB on the drives total :o ) So I restarted cwpsrv, httpd, and postfix to see if one of them was hoarding memory for some dumb reason, that's when postfix got uncooperative. I have CWP  0.9.8.10, Apache 2.2.27, PHP 5.5.30, mysql 5.1.73 on a Xeon quad core 2.6ghz with 24gb of RAM. I'm running 2 wordpress sites, a joomla site, and a static site. I'm am running varnish from memory but that's only reporting about 160MB right now. A ps aux doesn't show who's hogging the RAM, clamd is the biggest pig at only 1.2%.

I've tried rebuilding postfix which didn't help I still get the same error message. I've tried changing it to my server's IP, localhost, and my server's hostname, all still threw the same error. I searched the error message and tried creating a /var/spool/postfix/etc/ with a few necessary files that the Gentoo forums recommend and it didn't help so I undid that "fix".

A bug I think I've found is that if you select anti spam, rDNS, DKIM, in the rebuild, then try and rebuild postfix again without them later, it won't let you even if you've unchecked the boxes.

My server is about a 2hr drive away and I have to work this afternoon so I was going to try and restart it tomorrow morning just in case I have to pay it a visit. In the mean time if anyone has any suggestions I'd appreciate it greatly.

9
Varnish / default.vcl discussion
« on: December 31, 2015, 06:29:10 PM »
Like lot's of folks I installed varnish and saw no speed increase on my site. I switched from disk cache to malloc and still, little improvement with a huge miss rate. I started looking into vanish settings and here's what I cam up with. A little background: I'm running wordpress, joomla, and static web pages. I didn't really write this, I just took the most useful stuff from a number of sources (some of their comments I left intact, some are my own). Right now my hit rate is over 50%, the sites behave like they should (including admin access), apache logging works, everything seems good! Feedback is appreciated. If you're doing something different that's working awesome I'd love to check it out.

Code: [Select]
backend default { .host = "X.X.X.X"; .port = "8181";}
include "/etc/varnish/backends.vcl";
#set IP for apache logging
sub vcl_recv { include "/etc/varnish/sites.vcl";
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Setup grace mode.
  # Allow Varnish to serve up stale (kept around) content if the backend is
  #responding slowly or is down.
  # We accept serving 6h old object (plus its ttl)
  if (! req.backend.healthy) {
   set req.grace = 6h;
  } else {
   set req.grace = 15s;
  }
 
  # If our backend is down, unset all cookies and serve pages from cache.
  if (!req.backend.healthy) {
    unset req.http.Cookie;
  }

# Drop any cookies sent to Wordpress.
if(
        req.url ~ "^/administrator" ||
        req.url ~ "^/component/banners" ||
        req.url ~ "^/component/users" ||
        req.url ~ "^/wp-admin" ||
        req.url ~ "^/wp-login.php" ||
        req.url ~ "^/any-other-url-path"
    ) {
        return (pass);
    } else {
unset req.http.cookie;
}
# As mentioned before, remove all cookies for static files, images etc
  # Varnish will always cache the following file types and serve them (during TTL).
  # Note that Drupal .htaccess sets max-age=1209600 (2 weeks) for static files.
  if (req.url ~ "(?i)\.(bmp|png|gif|jpeg|jpg|doc|pdf|txt|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$") {
    // Remove the query string from static files
    set req.url = regsub(req.url, "\?.*$", "");
 
    unset req.http.Cookie;
 
    # Remove extra headers
    # We remove Vary and user-agent headers that any backend app may set
    # If we don't do this, Varnish will cache a separate copy of the resource
    # for every different user-agent
    unset req.http.User-Agent;
    unset req.http.Vary;
 
    return (lookup);
  }


}
#####
#If something gets super popular, super cache it
sub vcl_hit {
        if (obj.hits == 500) {
                set obj.ttl = 3h;
        } elsif (obj.hits == 10000) {
                set obj.ttl = 2d;
        } elsif (obj.hits == 1000000) {
                set obj.ttl = 4w;
        }
}
#####
#shutdown backend connections so unprivileged users don’t get privileged content
sub vcl_pass { 
    set bereq.http.connection = "close";
    if (req.http.X-Forwarded-For) {
        set bereq.http.X-Forwarded-For = req.http.X-Forwarded-For;
    }
    else {
        set bereq.http.X-Forwarded-For = regsub(client.ip, ":.*", "");
    }
}
#####
#shutdown backend connections so unprivileged users don’t get privileged content
sub vcl_pipe { 
    set bereq.http.connection = "close";
    if (req.http.X-Forwarded-For) {
        set bereq.http.X-Forwarded-For = req.http.X-Forwarded-For;
    }
    else {
        set bereq.http.X-Forwarded-For = regsub(client.ip, ":.*", "");
    }
}

#####
sub vcl_fetch {
# Don't allow static files to set cookies. Cache static content for a long time
  if (req.url ~ "(?i)\.(bmp|png|gif|jpeg|jpg|doc|pdf|txt|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$") {
    unset beresp.http.set-cookie;
    # default in Drupal, you may comment out to apply for other cms as well
    set beresp.ttl = 2w;
  }
#Cache stuff you shouldn’t for a min, just bout everything else a day
if (beresp.ttl < 24h) {
            if (beresp.http.Cache-Control ~ "(private|no-cache|no-store)") {
                set beresp.ttl = 60s;
            }
            else {
                set beresp.ttl = 24h;
}
}
 if (beresp.status == 301) {
    set beresp.ttl = 1h;
    return(deliver);
  }
  # Allow items to be stale if backend goes down. This means we keep around all objects for 6 hours beyond their TTL which is 2 minutes
  # So after 6h + 2 minutes each object is definitely removed from cache
  set beresp.grace = 6h;
 
  # If you need to explicitly set default TTL, do it below.
  # Otherwise, Varnish will set the default TTL by looking-up
  # the Cache-Control headers returned by the backend
  # set beresp.ttl = 6h;

  # if you have misbehaving sites (i.e Drupal6 or cookie-setters)
  # and you have forced Varnish to cache them in vcl_recv,
  # here you can instruct Varnish about their ttl, and
  # force Varnish to strip any cookies send from backend
  #if (req.http.host ~ "(?i)^(www.)?yourURL.com") {
  # unset beresp.http.set-cookie;
  # set beresp.http.Cache-Control = "public,max-age=602";
  # set beresp.ttl = 120s;
  #}

}

10
I can build it / Cheesy varish stats page for CWP
« on: December 22, 2015, 02:57:34 AM »
Now that I tuned varnish a bit it's recommended to keep an eye on some stats. I made this little page so I could see the output of a few commands from the web panel without having to login.

<?php
if ( !isset( $include_path ) )
{
    echo "invalid access";
    exit( );
}

$vstat = shell_exec("varnishstat -1 | head -n 6");
$vhits = shell_exec("varnishtop -1 -i rxurl | head -n 10");
$vmiss = shell_exec("varnishtop -1 -i txurl | head -n 10");
$vnuke = shell_exec("varnishstat -1 | grep nuke ");
$vmem = shell_exec("ps aux | grep 'varnish' | awk '{print $6/1024 \" MB\";}'");
echo "<h3>Varnish Statistics</h3><br><br>";
echo "<h3>Varnishstat</h3><br><pre>".$vstat."</pre><br><br>";
echo "<h3>Top 10 Hits</h3><br><pre>".$vhits."</pre><br><br>";
echo "<h3>Top 10 Misses</h3><br><pre>".$vmiss."</pre><br><br>";
echo "<h3>Varnish Nukes</h3><br><pre>".$vnuke."</pre><br><br>";
echo "<h3>Varnish Memory</h3><br><pre>".$vmem."</pre><br><br>";

?>

11
Mod_Security / Disable Rules by Vhost?
« on: December 02, 2015, 04:55:22 PM »
Is it possible to ignore rules (SecRuleRemoveById 654321) by vhost instead of globally? I'm running a shared server with clients running wordpress, joomla, and static websites so removing rules for one host is unnecessary for others. What would the syntax for that look like? Any ideas?

Pages: [1]