| Re: Can't change upload_max_filesize [message #183193 is a reply to message #183190] |
Sat, 12 October 2013 02:32   |
Fiver
Messages: 35
Registered: July 2013
Karma:
|
Member |
|
|
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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]