One of the problems we have with OptimumCache is that it is hard for us to know just how much it helps in production environment. It is not like all the pages would instantly start loading faster, or CPU usage would drop by 50%. The benefits are much more subtle, yet can be quite significant.
To better understand the benefits, we have created a way to collect memory, CPU & IO usage from the server. We want to collect such data for a week from a server before OptimumCache is started... and then after.
Once we have two datasets, we can compare and see where, and how much OptimumCache helps in real life settings.
We are looking for a 'stable' environment for that, where no other changes are planned for the next month, and where the server is filled up with customers, and you don't plan to add large number of customers any time soon.
Something that had been in production for a year or so.
If you have such servers, and willing to help, please, contact me direct at [email protected]
New version of OptimumCache 0.2-23 comes out with major fix for ploop issue - namely, for ploop unclean unmount problem.
OptimumCache 0.2-23 brings ‘optimumcache-collect’ package with it. ‘optimumcache-collect’ is a daemon to accumulate statistics about OptimumCache and system load for further analysis with data mining tools. 'optimumcache-collect' spawns ‘collectl’ daemon instance, which differs from default one in ‘collectl’ package, as far as it has separate config, pid file and custom plugins. Thus, if ‘collectl’ has been already used to collect system statistics, there shall be no interference with it.
Happy to announce that lvemanager (version 0.9-3.2), cagefs (version 5.3-6), pam_lve version 0.3-8, python-cllib (version 1.1-10), alt-mod-passenger (version 4.0.50-10, ClouLinux 6 only), alt-ruby, alt-python and alt-python-virtualenv are updated and available from our production repository.
"Python Ruby Selector" feature added to selectorctl utility;
"Setup Python App" and "Setup Ruby App" plugins added for cPanel;
LVEMAN-293: selectorctl works in CageFS (for Python and Ruby interpreters);
LVEMAN-309: cronjob cache_rubygems.py sends email if no alt-ruby installed;
LVEMAN-308: broken "/usr/bin/cl-selector --update-backup" as it takes first found link - fixed;
LVEMAN-328: fixed creation of /var/lve/rubygems and /var/lve/pypindex;
LVEMAN-324: prevented entering 'system' or public_html directories in application path;
LVEMAN-325: added the ability to remove ruby module in firefox.
CAG-339: cagefsctl --disable, --disable-all, --disable-cagefs do destroy_lve/apply_lve;
CAG-337: removed cron dependency;
CAG-338: /var/passenger and /opt mounts added to /etc/cagefs/cagefs.mp by default.
Does not call init_lvetoken twice;
PAMLVE-3: removed cron dependency removed.
Fixed blank lines handling in setup_mount_dir_cagefs();
CageFS present more reliably;
Feature setup_mount_dir_cagefs() with prefix argument;
PTCLLIB-24: added ability to get e-mail address for admin via cpapi (for CPanel);
Added function to setup mount dir for CageFS;
PyYAML fixed for 'native' and 'alternative' packages;
PTCLLIB-23: universal spec file developed for python-cllib & alt-python27-cllib;
PTCLLIB-21: added the ability to attach custom plugins for CloudLinux control panel api (clcommon.cpapi).
alt-mod-passenger 4.0.50-10 (CL6 only)
enter_lve_flags for Ruby app default spawn method added;
enter_lve_flags in PassengerHelperAgent added;
Added PassengerLveMinUid to Apache config;
Added missed alt-ruby21-devel dependency;
Once CageFS is installed - run client application in jail;
Spec file fixed (added /opt/passenger to %files section);
Added pre-creating dir for apache conf files in handle_module.py;
Added dependencies for alt-ruby21-rubygem-rake and alt-ruby21-rubygem-rack;
Added 'AutoReq: 0' to avoid automatic dependencies;
Ruby interpreter changed to an alternative one.
alt-python27, 33, 34
created cache of extensions for Selector while install or update of alt-python packages.
alt-ruby 18, 19, 20, 21
created cache of extensions for Selector while install or update of alt-ruby packages;
updated patchlevel to 551, 598 and 2.1.5 respectively (fix CVE-2014-8090).
yum install lvemanager alt-python-virtualenv alt-mod-passenger
To use Python Selector, please run:
yum groupinstall alt-python
To use Ruby Selector, please run:
yum groupinstall alt-ruby
After install of the packages please execute
New update for liblve (version 1.3-1.7) is available from our production repository.
revert lve_setup_enter function behaviour;
changed way in which lve_setup_enter treats ls_cpu limit from higher back to lower; to save the ability to use higher limits LIBLVE_SETTINGS_LS_CPU_HIRES flag is added. This flag has meaning only for lve_setup_enter function, lve_setup accepts ONLY high resolution limit;
First beta of CloudLinux 7 is available. Please, note that it should not be used on production machines. While majority of functionality is working, there are still some critical issues that need to be fixed.
In particular: cagefsctl --remount/--remount-all and lvectl --destroy will cause soft CPU lockup.
We expect to have a fix for it within 2 weeks.
We expect production version to be ready early in April 2015
Features missing from Beta and their ETA:
/proc security -> Feb 20th
secure links -> Feb 20th
alt-php 5.2/5.1 -> March 10th (5.3+ are already ported)
alt-php 4.4 -> No ETA
OptimumCache -> Q2 2015
yum-fastestmirror plugin -> March 15, 2015
secure uefi boot -> Q2 2015
Upgrade from CL6 to CL7 -> April 2015
All other functionality, including MySQL governor, mod_lsapi & PHP/Ruby/Python sectors should work
I see a lot of confusing information is making rounds on the need to reboot due to GLIBC GHOST bug. Do you really need to restart 'vulnerable services' or reboot the server?
Well, of course you have to restart vulnerable services, yet there is no need to restart the whole server - if you know what it is running (and in shared hosting - we actually do).
First of all - not all services that use glibc need to be restarted. Only services that use gethostbyname. That function is used to resolve internet host name to IP address.
Now, to exploit this function, attacker needs to be able to able to feed specially crafted 'host name' to the service. And service needs to process it without validating it first.
That is not a common condition. For example /sbin/init, while using glibc will not be exploitable at all using such bug. So, no need to restart it.
So, what can be potentially exploitable, and should be restart:
1. Exim: only when it is configured to resolve remote host name. Restart it.
2. Apache - apache itself is not exploitable, but some modules might be checking remote hosts - so, why not restart it. You should also restart php FPM, mod_lsapi daemon if you are running it in self_starter mode. Restart it just in case
3. LiteSpeed - restart it just in case.
4. Nginx - it is not vulnerable, and most common configurations I have seen on shared hosts will not be vulnerable as well - but given how cheap it is to restart it -- restart it.
5. cPanel (or your favorite brand of control panel) - yes, worth it, including cpHulkd. They might be not vulnerable at all - but with closed source software -- you never know, and such restart is once again - cheap.
6. PostgreSQL - we don't really know, so restart it just in case.
7. OpenSSH -- it is considered safe, but if you want to be really safe -- restarting openssh doesn't require any server downtime.
8. Postfix/sendmail - most likely it is safe, but same as with OpenSSH -- restarting it doesn't take much.
Proftpd, pure-ftpd,vsftpd,xinetd, tcp_wrappers, rsyslogd,mysql/mariadb --> are all considered safe - but should be easy to restart if you feel like it.
So, why so many people are coming out with advise to reboot the server? Unlike shared hosting servers -- generic servers run wide range of software -- and it is really hard to predict which software vulnerable and which are not. So, for them - best way to go is to reboot.
In shared hosting -- not as important.
To add to that: As it is not a kernel level vulnerability -- KernelCare will not help with it today. Yet, we are starting to work on ability to patch such vulnerabilities using KernelCare in the future.