These vulnerabilities have often attacked outdated or unmaintained areas of Drupal Code. There have been Drupal security vulnerabilities associated with the CMS - some of which have been severe for site owners. It has its own unique Drupal security problems. For this reason, organizations around the world have decided to rely on Drupal, and its ability to provide the site foundation they need to remain secure. Since its creation in 2000, the web application has seen limited Drupal security vulnerabilities when compared with other popular CMS platforms. module.Drupal is a secure CMS used by almost 3% of websites worldwide. This was on a site running Drupal 7 on PHP 5.4 with approximately 3,300 files with the extensions.
#DRUPAL SECURITY KIT PRO#
These tests were performed on a MacBook Pro with 2.3Ghz i7 processor set to allow the VM access to 90% of all 4 cores and 1736M of memory. But there were some fairly significant benefits to upping the realpath_cache settings there. We haven’t tried SMB yet, which I suppose should be our next attempt.
#DRUPAL SECURITY KIT WINDOWS#
Unfortunately there isn’t a really good alternative on Windows machines. Another big takeaway is that VBoxFS is really slow. I suppose this speaks to how effective NFS is at caching files on the client.
Likewise on cache clearing and after were a slight worsening - 1.5% and 0.7% respectively - between the default realpath_cache settings and the updated ones. Using NFS there was a pretty negligible difference, just over 10% drop - from 6.935s to 6.192s - on a cold request and a tiny increase - from 0.602s to 0.617s - on a warm request. We compared them with the default realpath_cache attributes - 16k for realpath_cache_size and 120 for realpath_cache_ttl - and updated ones with realpath_cache_size set to 128k and realpath_cache_ttl set to 7200. These included a cold start request, one where we restarted nginx and PHP-FPM and timed how long it would take a warm start, which gave the average of a set of requests now that the opcode cache and Drupal cache was warmed up a cache clearing, which shows how long running “drush cc all” would take and after cache clear, which shows how long the first request with a warm opcode cache but a cold Drupal cache would take. So we ran a few tests comparing various activities you might perform in Drupal and compared how they worked out.
We all know that some virtual file systems have problems under Vagrant, caching those expensive stats might help out a little bit. Now that we had the ability to add arbitrary PHP settings one of the first ones we wanted to try out was realpath_cache_size. There were some additional changes to allow arbitrary setting of PHP.ini settings, which becomes important when talking about OpCache settings as well as other performance enhancements like realpath_cache. These changes included setting the default version of PHP to 5.5, obviously, but also switching to use OpCache instead of XCache and switching to using MySQL-ND instead of the older MySQL PHP module.
#DRUPAL SECURITY KIT UPDATE#
One of the big pushes for August was to make that the default version and get things set up to easily update to PHP 5.6 - after all we’re already out of active support for 5.5 and only have security support for another 10 months. Previously getting PHP 5.5 or higher set up using the Web Starter Kit involved quite a bit of mucking around with YAML files. So we figured it would be about time to get our tools up to speed.
There's also the teeny detail of Drupal 8 requiring PHP 5.5 or higher. PHP 5.5 adds some significant language enhancements, things like finally and generators, as well as a first-class opcode cache in the form of the OpCache module. PHP is nearing another milestone when 5.4 goes out of security updates.
0 kommentar(er)
