nginx error – 413 Request Entity Too Large

I was getting an error when trying to upload and attach images larger than 2MB via WordPress.
I discovered that nginx has a configuration setting called client_max_body_size that is default set to 1M.
To change this, I altered my nginx vhost configuration and added the following line:

server {
    server_name techish.net www.techish.net;
    root /var/www/techish.net;
    include /etc/nginx/fastcgi_php;
    client_max_body_size 5M;
    location / {
        index index.php;
        if (!-e $request_filename) {
            rewrite ^(.*)$  /index.php last;
        }
    }
}

This should suffice for most of my image uploading needs.  However, if you have large uploads you perform to your server through nginx, you may need to increase that!
Reload nginx

/etc/init.d/nginx reload

Here’s nginx configuration’s HttpCoreModule documentation on this configuration value:

client_max_body_size
syntax: client_max_body_size size
default: client_max_body_size 1m
context: http, server, location
Directive assigns the maximum accepted body size of client request, indicated by the line Content-Length in the header of request.
If size is greater the given one, then the client gets the error “Request Entity Too Large” (413).
It is necessary to keep in mind that the browsers do not know how to correctly show this error.

Note: You’ll need to match your PHP value also.
/etc/php5/cgi/php.ini

upload_max_filesize = 5M

Restart php-cgi

/etc/init.d/php-cgi restart

 

Apache Segfault when Navigating to WP-Admin

width=588
Apache

Argh!
When trying to get into WordPress’ administration panel, Apache segfaults.
First troubleshooting steps involved moving all plugins/ to a temporary folder.
This didn’t produce any new results, still segfaulting.
Here are some notes on how I went about debugging this with GDB 7.3
wp-admin crashing
setup core dump in /etc/apache2.conf

CoreDumpDirectory /tmp-apache2/

Restart apache.

/etc/init.d/apache2 restart

install GDB 7.1+ for PIE support (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346409)
gdb Download: http://www.gnu.org/software/gdb/download/

root@nitrous:/tmp-apache2# wget -d http://ftp.gnu.org/gnu/gdb/gdb-7.3a.tar.bz2
root@nitrous:/tmp-apache2# bzip2 -d gdb-7.3a.tar.bz2
root@nitrous:/tmp-apache2# tar xvf gdb-7.3a.tar
root@nitrous:/tmp-apache2# cd gdb-7.3/
root@nitrous:/tmp-apache2# apt-get install gcc make ncurses-dev apache2-dbg php5-dbg
root@nitrous:/tmp-apache2/gdb-7.3# ./configure && make && make install

navigate to page, wp-admin to create crash

/usr/local/bin/gdb /usr/sbin/apache2 /tmp-apache2/core

(gdb) thread apply all bt full

root@nitrous:/tmp-apache# /usr/local/bin/gdb `which apache2` core
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/apache2...(no debugging symbols found)...done.
[New LWP 5596]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f28ad87f5f9 in _zend_hash_add_or_update () from /usr/lib/apache2/modules/libphp5.so
(gdb) bt
#0 0x00007f28ad87f5f9 in _zend_hash_add_or_update () from /usr/lib/apache2/modules/libphp5.so
#1 0x00007f28ad82cae5 in php_register_variable_ex () from /usr/lib/apache2/modules/libphp5.so
#2 0x00007f28ad6a21a9 in ?? () from /usr/lib/apache2/modules/libphp5.so
#3 0x00007f28ad826542 in sapi_getenv () from /usr/lib/apache2/modules/libphp5.so
#4 0x00007f28a3d895d4 in suhosin_log () from /usr/lib/php5/20090626/suhosin.so
#5 0x00007f28a3d84b3e in ?? () from /usr/lib/php5/20090626/suhosin.so
#6 0x00007f28ad8858a5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#7 0x00007f28ad885981 in ?? () from /usr/lib/apache2/modules/libphp5.so
#8 0x00007f28ad87d885 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so
#9 0x00007f28ad885df0 in zend_ini_deactivate () from /usr/lib/apache2/modules/libphp5.so
#10 0x00007f28ad87132f in ?? () from /usr/lib/apache2/modules/libphp5.so
#11 0x00007f28ad81cb65 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so
#12 0x00007f28ad8fe177 in ?? () from /usr/lib/apache2/modules/libphp5.so
#13 0x00007f28b16a2880 in ap_run_handler ()
#14 0x00007f28b16a621e in ap_invoke_handler ()
#15 0x00007f28b16b3e48 in ap_process_request ()
#16 0x00007f28b16b0cf8 in ?? ()
#17 0x00007f28b16aa478 in ap_run_process_connection ()
#18 0x00007f28b16b8e97 in ?? ()
#19 0x00007f28b16b91aa in ?? ()
#20 0x00007f28b16b94db in ap_mpm_run ()
#21 0x00007f28b168ea90 in main ()
(gdb) bt full
#0 0x00007f28ad868f84 in zend_cleanup_function_data_full () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#1 0x00007f28ad87d885 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#2 0x00007f28ad868f50 in zend_cleanup_class_data () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#3 0x00007f28ad87d885 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#4 0x00007f28ad8648f0 in ?? () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#5 0x00007f28ad8712a2 in ?? () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#6 0x00007f28ad81cb65 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#7 0x00007f28ad8fe177 in ?? () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#8 0x00007f28b16a2880 in ap_run_handler ()
No symbol table info available.
#9 0x00007f28b16a621e in ap_invoke_handler ()
No symbol table info available.
#10 0x00007f28b16b3c6c in ap_internal_redirect ()
No symbol table info available.
#11 0x00007f28aa9e8cb5 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
No symbol table info available.
#12 0x00007f28b16a2880 in ap_run_handler ()
No symbol table info available.
#13 0x00007f28b16a621e in ap_invoke_handler ()
No symbol table info available.
#14 0x00007f28b16b3e48 in ap_process_request ()
No symbol table info available.
#15 0x00007f28b16b0cf8 in ?? ()
No symbol table info available.
#16 0x00007f28b16aa478 in ap_run_process_connection ()
No symbol table info available.
#17 0x00007f28b16b8e97 in ?? ()
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#18 0x00007f28b16b91aa in ?? ()
No symbol table info available.
#19 0x00007f28b16b9e34 in ap_mpm_run ()
No symbol table info available.
#20 0x00007f28b168ea90 in main ()
No symbol table info available.

I have no idea where the problem is still.
Some googling found some hints at suhosin possibly, so I modified /etc/php5/apache/config.ini and commented out the extension=suhosin.so.
Restarted apache

/etc/init.d/apache2 restart

Navigated to wp-admin – everything works!
Now, why/what is causing suhosin to segfault? That is still under investigation.

WordPress: Quickly Replace Content Across All Blog Entries

I discovered I could change my image paths that were linked against www.techish.net to www.techish.net by using MySQL to REPLACE the string.
After a few minutes of thinking about this, this is a really cool thing — beyond what I just accomplished.
I can use this to update what was once static information (phone number, fax, email, contact information, etc.) quickly!
This is what the syntax looked like:

update blog_posts set post_content = REPLACE(post_content,'https://techish.net/wp-content/uploads/', 'https://techish.net/wp-content/uploads/');

Now using that as a basis, I can use REPLACE(post_content, ”,”) to create quick hacks to change emails on-the-fly that were contained in my posts.

Migrating…

Please stand-by while old blog posts are migrated to the new system.
All content has been migrated.
Notes…
Migrating WordPress to a subdomain caused images to b0rk. This was the fix instead of screwing with .htaccess and since I’m also using WordPress on the main domain:

update blog_posts set post_content = REPLACE(post_content,'https://techish.net/wp-content/uploads/', 'https://techish.net/wp-content/uploads/');

That saved me from modifying 98 posts by hand. *Phew*
And to update the media library path:

UPDATE wp_posts SET guid = REPLACE(guid,'https://techish.net/wp-content/uploads/','https://techish.net/wp-content/uploads/')