nginx: 413 Request Entity Too Large – File Upload Issue

I got above error message in nginx. Stackoverflow post 413 Request Entity Too Large – File Upload Issue had all information to resolve the issue. The solution was written by User Arun.

One has to edit /etc/nginx/nginx.conf and add in http{...}

client_max_body_size 15900M ;

and /etc/php/php.ini

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 15900M

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 6900M

; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
post_max_size = 25900M

Besides editing /etc/nginx/nginx.conf and /etc/php/php.ini I had to stop nginx and php-fpm:

systemctl stop nginx
systemctl stop php-fpm

so the changes take effect.

After starting the two services then check with phpinfo().

Suppressing Advertisement on Web-Pages a.k.a. Ad-Blocking

Advertisements on web-pages is ubiquitous. Without advertisement even this blog could not be offered free of charge. But advertisement can be a real nuisance with its blinking, flickering, moving, and distracting appearance. Sometimes they even contain malware.

There are two simple remedies for this problem:

  1. use an adblocker plug-in for your browser
  2. modify your /etc/hosts file

The first one is easy to accomplish, but sometimes web-pages no longer work as expected. The second approach is in some ways more direct and more brutal, and leaves visual clues on the web-pages that brute force has been applied.

Editing /etc/hosts on your Linux desktop is easy. On Android you connect via adb shell, switch to root user with su, then

mount -o remount,rw /system

i.e., remount the /system directory from read-only to write-enabled, then edit /etc/hosts. Either reboot your smartphone, or

mount -o remount,ro /system

I use the following list of hosts in my /etc/hosts, which has a somewhat German felling: Continue reading

Migrating from delicious.com to WordPress

I have been a loyal user of delicious.com since 2006. I have written on this in my post Saving URLs in del.icio.us Still Troublesome. But now enough is enough. Here is a list of annoyances:

  1. You can neither export nor import your data anymore.
  2. The service is generally slow, i.e., it takes a lot of time to just load the site in your browser.
  3. The service is sometimes not available.
  4. You cannot change URLs without deleting the entire post.
  5. The company behind the service does not answer any inquires.
  6. The site is blocked by a number of company firewalls because it is marked as “social”.

Continue reading

On Password Security and Cracking

Six months ago Bruce Schneier posted an article on “Choosing Secure Passwords”. Some of the key points are (mostly copied verbatim from mentioned post):

  1. The best way to explain how to choose a good password is to explain how they are broken.
  2. Password crackers do not brute force all 8 character combinations, but rather they brute force all 6 character passwords, then they check for common passwords.
  3. A typical password consists of a root plus an appendage. The root isn’t necessarily a dictionary word, but it’s usually something pronounceable. An appendage is either a suffix (90% of the time) or a prefix (10% of the time). One cracking program I saw started with a dictionary of about 1,000 common passwords. Continue reading

Google Chrome Became a Performance Hog

I own a single-core laptop with 1 GB of memory. Google Chrome version 34 for Linux 64 bit (ArchLinux) is completely unusable on this machine. I own another single-core laptop with 512 MB of memory. Google Chrome version 12 for 32 bit (Ubuntu 10.04) works just fine on this machine. Both machines are considered somewhat old and underpowered according todays standard. Nevertheless they should be able to browse the web at least as fast as any smartphone or tablet.

As has already been said in other posts (here and here): Newer is not better.

I checked my old downloads: I have copies of Google Chrome 64 bit Debian packages which have size 13 MB in 2010. At end of 2011 it climbed to 24 MB, in 2012 to 36 MB, in 2013 to 43 MB. Now Chrome 64 bit Debian packages are 49 MB. This tremendous increase cannot be explained by security fixes.

ChromeFatter

See Blackduck: Google Chrome for a lines-of-codes against time chart.
GoogleChromeLOC1

On that occasion I searched for alternatives which can replace Google Chrome and its memory obesity. Two possible contenders might be QupZilla and Midori. QupZilla just worked out of the box, while Midori crashed repeatedly on Ubuntu 14.04. Unfortunately I did not get Flash to work with QupZilla. i.e., no YouTube with QupZilla.