Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #11395

Re: Can't change upload_max_filesize

From Fiver <numeralfive@gmail.com>
Newsgroups comp.lang.php
Subject Re: Can't change upload_max_filesize
Date 2013-10-12 04:32 +0200
Organization A noiseless patient Spider
Message-ID <l3acbs$cml$1@dont-email.me> (permalink)
References (4 earlier) <OCH5u.48477$K71.37672@fx21.iad> <l394s1$hql$1@dont-email.me> <3017330.KgCX0VFtND@PointedEars.de> <l39u1g$f34$1@dont-email.me> <2033215.bEuLlM5jFn@PointedEars.de>

Show all headers | View raw


On 2013-10-12 02:45, Thomas 'PointedEars' Lahn wrote:
> Fiver wrote:
>> On 2013-10-11 19:23, Thomas 'PointedEars' Lahn wrote:
>>> Denis McMahon wrote:
>>>> cd /etc
>>>> 
>>>> sudo grep -R upload_max_filesize *
>>> 
>>>   sudo grep --color -Irwe upload_max_filesize /etc/
>>> 
>>> is infinitely more useful.
>> 
>> Maybe for your personal definition of "useful" (or infinity).
> 
> … which is currently based on more than 13 years of *professionally* 
> maintaining GNU/Linux systems, including Debian and Ubuntu based ones, 
> running PHP-powered Web sites.  You would do well to listen to that.

Thanks for the admonition. 13 years is nothing to scoff at, and good for
you, but age does not a wise man make. I still have a few years of
experience on you, and in this case, I think, it shows.

>> -I
>>   skips all files detected as binary; probably makes no difference in
>>   this case, but might hide information you're looking for
> 
> Nonsense.  This is a full-*text* search; it does not make sense to search in 
> binaries at all.

When you can't find a specific setting, and you've exhausted all of the
obvious candidates, you will eventually include binaries in your search.
At least you should, IMHO.

Let's just compare the findings on my current box:

# first, try it your way: with -I
root@redacted-host:/ # grep -lIRwe upload_max_filesize etc 2>/dev/null
/etc/apache2/sites-enabled/040-redacted1
/etc/apache2/sites-enabled/011-redacted2
/etc/apache2/sites-enabled/020-redacted3
/etc/apache2/sites-enabled/012-redacted4
/etc/apache2/sites-enabled/080-redacted5
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini

# now without -I
root@redacted-host:/ # grep -lRwe upload_max_filesize etc 2>/dev/null
/etc/apache2/sites-enabled/040-redacted1
/etc/apache2/sites-enabled/011-redacted2
/etc/apache2/sites-enabled/020-redacted3
/etc/apache2/sites-enabled/012-redacted4
/etc/apache2/sites-enabled/080-redacted5
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/alternatives/php

You'll notice an additional result when we're not skipping binaries.
This file is very unlikey to be the root of the problem, but I'd still
like to be aware of it, because it does contain the search string. If
all else fails, we'll get back to it.

>> -r
>>   skips symlinked files that the GP would have included with -R;
>>   definitely a bad choice when searching for a mystery config setting
> 
> [Only wannabes talk about computer technology in terms of mysticism and 
> incantations.  There is no “mystery config setting” here.  It is simply 
> binary logic instead: either there is something causing this behavior, then 
> this problem can be solved by changing the configuration; or there is not, 
> then this problem can only be solved by exchanging the software.]

Oh dear, you got hung up on the word "mystery". May I suggest consulting
a dictionary? Also, "wannabes? It's too soon for ad hominems, we're
still having a pleasant chat.

> “-r” instead of “-R” prevents grep(1) from going into an endless loop (which 
> is allowed for symlinks).

Pff, fuck the potential endless loops here. I've never seen that happen
in practice, and while it may be technically possible, it's easy enough
to abort with Ctrl-C.

Look what happens if you don't dereference symlinks (this is still the
same box as before):

    root@redacted-host:/ # grep -r upload_max_filesize /etc 2>/dev/null
       Result: (zilch, nada, nil)

Okay, now when we follow the the symlinks...

    root@redacted-host:/ # grep -R upload_max_filesize /etc 2>/dev/null
    /etc/apache2/sites-enabled/040-redacted1:
        php_value  upload_max_filesize   100M
    /etc/apache2/sites-enabled/011-redacted2:
        #php_value  upload_max_filesize  100M
    /etc/apache2/sites-enabled/020-redacted3:
        #php_value  upload_max_filesize  100M
    /etc/apache2/sites-enabled/012-redacted4:
        php_value  upload_max_filesize   10M
    /etc/apache2/sites-enabled/080-redacted5:
        php_value  upload_max_filesize   100M
    /etc/php5/apache2/php.ini:
        ; [note] -- yes, leave this at 10M! see upload_max_filesize
        ;upload_max_filesize = 2M
        upload_max_filesize = 10M
    /etc/php5/cli/php.ini:
        ; [note] -- yes, leave this at 10M! see upload_max_filesize
        ;upload_max_filesize = 2M
        upload_max_filesize = 10M
    Binary file /etc/alternatives/php matchesa

Much more relevant, don't you think? And look! None of these files are
actually under /etc, they're linked in from their separate project
directories. Without -R, you won't be able to see them.

Case rested for -R vs -r (unless you're terrified of unstoppable loops).

>> -w
>>   pointless, unless you expect upload_max_filesize to be part of a
>>   longer word
> 
> “-w” searches for *words*, not just for substrings.  No, that is _not_ 
> pointless here.  It might be even better to search for 
> '\<upload_max_filesize[[:space:]]*=', 
> '\<php_\(admin_\)\?value[[:space:]]upload_max_file\>' (or its egrep 
> equivalent instead.

Wtf, we're just searching for a plain text string here, don't
artificially overcomplicate it. A substring search is fine. There's no
need for word boundaries here, and thus -w is unnecessary.

>> -e
>>   pointless, unless you're using a regex, which you're not
> 
> Nonsense.  GNU grep(1) as in Ubuntu uses POSIX Basic Regular Expressions
> *by default* (“-F” searches for fixed strings).  “-e” is merely used so that 
> expressions starting with “-” are not considered options.  I am using it out 
> of good habit; it is not strictly necessary *here* because the pattern does 
> not start with “-”.

Glad we agree on that: -e wasn't necessary.

>>> In general, phpinfo() shows *all* relevant files (short of PHP source
>>> files), so there is hardly a need for a recursive fulltext search.
>> 
>> That's not true: phpinfo() doesn't show the Apache config files.
> 
> True.  [...]
> 
>> For example, with a default Ubuntu setup, there are vhost config files
>> linked from /etc/apache2/sites-enabled, where PHP config settings can be
>> made with the "php_value" directive.
> 
> I am aware of that (the OP is not, because they would not RTFM); the link 
> targets are in /etc/apache2/sites-available/ (the a2ensite and a2dissite 
> commands then make it easy to enable and disable Virtual Hosts by just 
> adding and removing those symlinks).  That makes this recursive search even 
> more a waste of time.  The *exact* config file for the *used* Virtual Host, 
> its includes, and the server/PHP configuration files in and under its 
> DOCUMENT_ROOT should be consulted instead.

The vhost configs would have been found had you had used the -R option
for grep, instead of -r. As for the various INI_PER_DIR settings in
.htaccess files, and the PHP files themselves, yeah, you'd have to add
more tree roots than just /etc.


regards,
5er


PS: @Jerry, I didn't see that as a troll post. TL made a suggestion, I
disagreed, we're talking about it. No damage done.

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-09 14:27 -0700
  Re: Can't change upload_max_filesize Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-09 23:49 +0200
    Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-10 13:32 -0700
      Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-10 23:01 +0200
      Re: Can't change upload_max_filesize Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-10 21:26 +0000
        Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-10 17:28 -0700
          Re: Can't change upload_max_filesize Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-11 15:18 +0000
            Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-11 10:05 -0700
            Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-11 19:23 +0200
              Re: Can't change upload_max_filesize Fiver <numeralfive@gmail.com> - 2013-10-12 00:27 +0200
                Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-12 02:45 +0200
                Re: Can't change upload_max_filesize Fiver <numeralfive@gmail.com> - 2013-10-12 04:32 +0200
                Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-11 22:47 -0400
                Re: Can't change upload_max_filesize Fiver <numeralfive@gmail.com> - 2013-10-12 05:19 +0200
                Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-12 07:00 +0200
                Re: Can't change upload_max_filesize Fiver <numeralfive@gmail.com> - 2013-10-12 09:15 +0200
                Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-12 19:51 +0200
                Re: Can't change upload_max_filesize Twayne <nobody@spamcop.net> - 2013-10-12 10:08 -0400
                Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-12 10:12 -0400
                Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-11 21:48 -0400
      Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-10 18:07 -0400
        Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-10 17:32 -0700
          Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-10 22:46 -0400
            Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-11 10:16 -0700
              Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-11 19:28 +0200
                Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-11 10:36 -0700
                Re: Can't change upload_max_filesize Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-11 22:01 +0200
              Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-11 13:29 -0400
                Re: Can't change upload_max_filesize Tobiah <toby@tobiah.org> - 2013-10-11 10:34 -0700
                Re: Can't change upload_max_filesize Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-11 14:20 -0400
  Re: Can't change upload_max_filesize Twayne <nobody@spamcop.net> - 2013-10-11 16:21 -0400

csiph-web