Databases, Systems & Networks

note: increasing PHP upload size is different from increasing PHP memory limit. You can learn to increase memory limit here.

Drupal’s limits on upload file size are determined by your server’s PHP settings (as well as Drupal specified settings that can be set at Admin > Site Configuration > File Upload). The default values for PHP will restrict you to a maximum 2 MB upload file size.

On the settings page for the upload module, Drupal calculates and displays the maximum file size that you can set based upon two PHP settings: ‘post_max_size’ and ‘upload_max_filesize’. Since ‘post_max_size’ is the limit for all the content of your post, many people choose ‘post_max_size’ to be a multiple of ‘upload_max_filesize’ to allow multiple files to be uploaded, but this is not essential. The upload module limits the size of a single attachment to be less than either post_max_size, or upload_max_filesize, whichever is smaller. The default PHP values are 2 MB for upload_max_filesize, and 8 MB for post_max_size.
Lire la suite…

Source: Visser Labs Blog

When uploading a set of admittedly large images using NextGEN Gallery to my WordPress site I exceeded my web hosts default memory usage allocation for PHP applications. The error was:

Follow thumbnails could not created. sample.jpg (Error : Exceed Memory limit. Require : 80.65 MByte)

This issue can be resolved by increasing the memory usage allocation at a per-plugin level for PHP applications that require more grunt than others. It’s quick and easy!

1. Open an FTP connection to your root WordPress directory
2. Open /wp-content/plugins/nextgen-gallery/lib/gd.thumbnail.inc.php with your favourite text editor (e.g. UltraEdit, etc.)
3. On line #168 un-comment (remove the //) from before @ini_set('memory_limit', '128M');
4. Save and upload changes
5. Delete image/s that failed to generate a thumbnail and re-upload using NextGEN Gallery’s standard Upload Images feature

If you find 128MB is too ‘conservative’ this can be increased again to any figure of your liking, I find 128MB appropriate for most commercial and personal usage but if you’re a HD photographer then you’re going to hit this limit very quickly… that’s it!

Question: Whenever Apache2 web server returns error pages (e.g., 404 not found, 403 access forbidden pages), it shows web server signature (e.g., Apache version number and operating system info) at the bottom of the pages. Also, when Apache2 web server serves any PHP pages, it reveals PHP version info. How can I turn off these web server signatures in Apache2 web server?

Revealing web server signature with server/PHP version info can be a security risk as you are essentially telling attackers known vulnerabilities of your system. Thus it is recommended you disable all web server signatures as part of server hardening process.

Disable Apache Web Server Signature

Disabling Apache web server signature can be achieved by editing Apache config file.

On Debian, Ubuntu or Linux Mint:

$ sudo vi /etc/apache2/apache2.conf

On CentOS, Fedora, RHEL or Arch Linux:

$ sudo vi /etc/httpd/conf/httpd.conf

Add the following two lines at the end of Apache config file.

Then restart web server to activate the change:

$ sudo service apache2 restart (Debian, Ubuntu or Linux Mint)
$ sudo service httpd restart (CentOS/RHEL 6)
$ sudo systemctl restart httpd.service (Fedora, CentOS/RHEL 7, Arch Linux)

The first line ‘ServerSignature Off‘ makes Apache2 web server hide Apache version info on any error pages.

However, without the second line ‘ServerTokens Prod‘, Apache server will still include a detailed server token in HTTP response headers, which reveals Apache version number.

What the second line ‘ServerTokens Prod‘ does is to suppress a server token in HTTP response headers to a bare minimal.

So with both lines in place, Apache will not reveal Apache version info in either web pages or HTTP response headers.

Hide PHP Version

Another potential security threat is PHP version info leak in HTTP response headers. By default, Apache web server includes PHP version info via “X-Powered-By” field in HTTP response headers. If you want to hide PHP version in HTTP headers, open php.ini file with a text editor, look for “expose_php = On”, and change it to “expose_php = Off”.

On Debian, Ubuntu, or Linux Mint:

$ sudo vi /etc/php5/apache2/php.ini

On CentOS, Fedora, RHEL or Arch Linux:

$ sudo vi /etc/php.ini

expose_php = Off

Finally, restart Apache2 web server to reload updated PHP config file.

Now you will no longer see “X-Powered-By” field in HTTP response headers.

When phpMyAdmin is installed, the default session timeout value is too low for many users, making your phpMyAdmin session expire too soon. One could argue that a low session timeout value is a good idea from a security perspective. If you do not think this is an issue, here are a few simple steps that’ll let you change how long phpMyAdmin will keep your session(s) alive.

Open config.inc.php in the phpMyAdmin “root” directory. Look for a line that contains this: $cfg[‘LoginCookieValidity’]. Set the value to the desired number of seconds you want the session to stay alive (3600 = one hour, which is reasonable for most users). If you do not have that line in your config.inc.php file, add it like this:

$cfg[‘LoginCookieValidity’] = 3600;

Don’t forget to save the file, and then login again to phpMyAdmin. You may need to close the browser and re-open your phpMyAdmin URL.

This also assumes that the PHP session garbage collection is set-up accordingly. This can be done in a number of ways:

• php.ini; add a line (or change an existing) that contains session.gc_maxlifetime = <seconds>
• Apache configuration; add a line to the appropriate <Directory> block that says “php_admin_value session.gc_maxlifetime <seconds>”
• config.inc.php (phpMyAdmin); after the previously edited line, add a line with “ini_set(‘session.gc_maxlifetime’, <seconds>);”

The <seconds> above is the same value that you set your variable to in config.inc.php at the beginning of this post, “3600” (sans quotes) in my case. (Some of these methods may or may not work on the server you’re using.)

This isn’t the only way to circumvent phpMyAdmin sessions expiring on you in the middle of that important work; you can, of course, configure phpMyAdmin to have appropriate access directly, thus allowing you to access your MySQL database(s) without entering a username and a password. You’ll find more information about this on the phpMyAdminwebsite.