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

Groups > comp.lang.php > #11328 > unrolled thread

Can't change upload_max_filesize

Back to article view | Back to comp.lang.php

Contents

  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

Page 1 of 2  [1] 2  Next page →

#11328 — Can't change upload_max_filesize

I set upload_max_filesize, and post_max_size in my
php.ini to very large values, and restarted apache.  I still can't upload
files larger than about 1MB.  They just silently fail.
I check phpinfo() and both of the limits are listed
as the small defaults (2M and 8M).  Why do the php.ini
settings have no effect?  I Googled and found at least
one person with the exact same complaint.

PHP 5.3.10

Thanks for any help!

Tobiah

[toc] | [next] | [standalone]

#11330

Tobiah wrote:

> I set upload_max_filesize, and post_max_size in my
> php.ini to very large values, and restarted apache.  I still can't upload
> files larger than about 1MB.  They just silently fail.
> I check phpinfo() and both of the limits are listed
> as the small defaults (2M and 8M).  Why do the php.ini
> settings have no effect?  I Googled and found at least
> one person with the exact same complaint.
> 
> PHP 5.3.10

Have you checked that this php.ini is actually in use?  See phpinfo()'s
"Configuration File (php.ini) Path" and the following entries.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#11349

On 10/09/2013 02:49 PM, Christoph Michael Becker wrote:
> Tobiah wrote:
>
>> I set upload_max_filesize, and post_max_size in my
>> php.ini to very large values, and restarted apache.  I still can't upload
>> files larger than about 1MB.  They just silently fail.
>> I check phpinfo() and both of the limits are listed
>> as the small defaults (2M and 8M).  Why do the php.ini
>> settings have no effect?  I Googled and found at least
>> one person with the exact same complaint.
>>
>> PHP 5.3.10
>
> Have you checked that this php.ini is actually in use?  See phpinfo()'s
> "Configuration File (php.ini) Path" and the following entries.
>

That's a great idea, but it seems that I was editing the
correct file:

/etc/php5/apache2/php.ini

as reported by phpinfo()

In that file, I've changed upload_max_filesize and post_max_size
to 200M, also tried 200000000 but phpinfo still reports their
values at 2M and 8M, and large uploads still fail.

Thanks,

Tobiah	

[toc] | [prev] | [next] | [standalone]

#11350

Tobiah wrote:

> On 10/09/2013 02:49 PM, Christoph Michael Becker wrote:
>> Have you checked that this php.ini is actually in use?  See phpinfo()'s
>> "Configuration File (php.ini) Path" and the following entries.
> 
> That's a great idea, but it seems that I was editing the
> correct file:
> 
> /etc/php5/apache2/php.ini
> 
> as reported by phpinfo()
> 
> In that file, I've changed upload_max_filesize and post_max_size
> to 200M, also tried 200000000 but phpinfo still reports their
> values at 2M and 8M, and large uploads still fail.

Configuration values can be set in various ways.  RTFM.

We have also discussed this recently.

Please post using your real (full) name.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#11351

On Thu, 10 Oct 2013 13:32:49 -0700, Tobiah wrote:

> That's a great idea, but it seems that I was editing the correct file:

Are you restarting the apache server after saving the edited php.ini?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#11360

On 10/10/2013 2:26 PM, Denis McMahon wrote:
> On Thu, 10 Oct 2013 13:32:49 -0700, Tobiah wrote:
>
>> That's a great idea, but it seems that I was editing the correct file:
>
> Are you restarting the apache server after saving the edited php.ini?
>

Yes, I'm restarting apache, but thanks for that.  I even do
a full stop then start just to be sure ;)

[toc] | [prev] | [next] | [standalone]

#11378

On Thu, 10 Oct 2013 17:28:33 -0700, Tobiah wrote:

> On 10/10/2013 2:26 PM, Denis McMahon wrote:
>> On Thu, 10 Oct 2013 13:32:49 -0700, Tobiah wrote:
>>
>>> That's a great idea, but it seems that I was editing the correct file:
>>
>> Are you restarting the apache server after saving the edited php.ini?

> Yes, I'm restarting apache, but thanks for that.  I even do a full stop
> then start just to be sure ;)

cd /etc

sudo grep -R upload_max_filesize *

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#11381

On 10/11/2013 08:18 AM, Denis McMahon wrote:
> sudo grep -R upload_max_filesize *

php5/cli/php.ini:upload_max_filesize = 200M
php5/apache2/php.ini:upload_max_filesize = 200000000

I tried short hand and the long version in
desperation.

Tobiah

[toc] | [prev] | [next] | [standalone]

#11385

Denis McMahon wrote:

> On Thu, 10 Oct 2013 17:28:33 -0700, Tobiah wrote:
>> On 10/10/2013 2:26 PM, Denis McMahon wrote:
>>> On Thu, 10 Oct 2013 13:32:49 -0700, Tobiah wrote:
>>>> That's a great idea, but it seems that I was editing the correct file:
>>> Are you restarting the apache server after saving the edited php.ini?
>> Yes, I'm restarting apache, but thanks for that.  I even do a full stop
>> then start just to be sure ;)
> 
> cd /etc
> 
> sudo grep -R upload_max_filesize *

  sudo grep --color -Irwe upload_max_filesize /etc/

is infinitely more useful.  But it will only help if the configuration files 
are located in or below that directory (this need not be the case for 
example on an Amazon server), and if no .htaccess or .user.ini in any 
directory in and below the DOCUMENT_ROOT, and no PHP source file that is 
used when accessing the Web site, interferes.

In general, phpinfo() shows *all* relevant files (short of PHP source 
files), so there is hardly a need for a recursive fulltext search.

<http://php.net/manual/en/configuration.php> pp. (AISB)

That said, I prefer ack(1) for recursive text search instead.  It is 
tailored to configuration and source files which is why it is a lot faster 
than grep(1).


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#11391

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).

-I
  skips all files detected as binary; probably makes no difference in
  this case, but might hide information you're looking for
-r
  skips symlinked files that the GP would have included with -R;
  definitely a bad choice when searching for a mystery config setting
-w
  pointless, unless you expect upload_max_filesize to be part of a
  longer word
-e
  pointless, unless you're using a regex, which you're not

> 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. 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.

regards,
5er

[toc] | [prev] | [next] | [standalone]

#11393

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.
 
> -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.  [Which is why ack(1) does not do that by default.]

> -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.]

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

> -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.

> -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 “-”.
 
>> 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.  “upload_max_filesize” is a PHP_INI_PERDIR directive since PHP 4.2.4; 
it can be set in the Virtual Host configuration as well.   (As far as PHP is 
concerned, the Virtual Host configuration is the same as httpd.conf because 
those files are merely includes of that file or its distribution adjunct, 
apache2.conf.  It *cannot* be set with ini_set() or in the Windows registry 
anymore.  That is what RTFM gives you, for free.)

> 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.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#11395

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.

[toc] | [prev] | [next] | [standalone]

#11396

On 10/11/2013 10:32 PM, Fiver wrote:
>
> 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.
>

Pointed head is a well-known troll in this and several other newsgroups. 
  He will argue with you from a position of ignorance until you give up.

For the sake of the rest of the us - please don't feed the troll. 
Besides, this is off topic for comp.lang.php.  If you feel you 
absolutely HAVE to try to prove him incorrect (he'll NEVER admit it), 
please take this to email.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11397

On 2013-10-12 04:47, Jerry Stuckle wrote:
> On 10/11/2013 10:32 PM, Fiver wrote:
>> 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.

> Pointed head is a well-known troll in this and several other newsgroups. 
>   He will argue with you from a position of ignorance until you give up.

He's not well-known to me, and as far as I can recall, he hasn't
directly insulted me before (more than I'm willing to absorb). I realize
I'm a newcomer in this group, but in my blessed state of ignorance I
don't see him as a troll.

> For the sake of the rest of the us - please don't feed the troll. 
> Besides, this is off topic for comp.lang.php.  If you feel you 
> absolutely HAVE to try to prove him incorrect (he'll NEVER admit it), 
> please take this to email.

Yeah, the grep details are getting a little off-topic now, but the
general topic (finding where a PHP config setting originates) is still
relevant. I know for a fact that I've had trouble in this regard with
some fairly complex server setups. Who knows, something interesting and
worthwhile might be discovered in this subthread.

For example, TL's mention of "ack" could be a lifesaver for those who
didn't already know it (or have written their own version, like me).

I'm not planning on continuing Usenet conversations per email. My
address is valid; anybody who wants to can contact me privately, but
will most likely be ignored as a matter of principle (if it's not personal).

regards,
5er

[toc] | [prev] | [next] | [standalone]

#11400

Fiver wrote:

> 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.

We'll see about that.
 
>>> -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.

For what purpose?  Do you even know what a *binary* is?
 
> 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.

On a current Ubuntu Linux system, /etc/alternatives/php is a symlink to 
/usr/bin/php5 (try “sudo update-alternatives --config php”):

$ ls -l /etc/alternatives/php
lrwxrwxrwx 1 root root 13 Aug  8 09:50 /etc/alternatives/php -> 
/usr/bin/php5

What sense does it make to search that binary, or any other binary?
*None* *at* *all*.

>>> -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.

Well, *I* am having a _technical discussion_ with you.

>> “-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.

So you do not care about the consequences of your actions.  Very 
professional, indeed :->

You would *honestly* recommend that to the OP?  No, I don't think so.

> 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)

Liar.

> 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).

Where have you learned to lie so badly?  In a *standard Ubuntu setup*,

1. you would not be root (“#”) as Ubuntu does not set a password for root by
   default.  You would be using sudo(8) instead.

2. a recursive search would search in /etc/apache2/sites-available as well,
   and would find *duplicate* results with “-R” because of symlinks

/etc/apache2/sites-enabled/040-redacted1 → /etc/apache2/sites-available/040-
redacted1

aso.

Example:

$ cat /etc/apache2/sites-available/zf2-tutorial 
<VirtualHost *:80>
    ServerName zf2-tutorial.localhost
    DocumentRoot /var/www/zf2-tutorial/public
    SetEnv APPLICATION_ENV "development"
    SetEnv ZF2_PATH "/opt/php/ZendFramework/library"
    <Directory /var/www/zf2-tutorial/public>
        DirectoryIndex index.php
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

$ grep -Inrwe ZF2_PATH /etc 2>/dev/null
/etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
"/opt/php/ZendFramework/library"

$ grep -InRwe ZF2_PATH /etc 2>/dev/null
/etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
"/opt/php/ZendFramework/library"
/etc/apache2/sites-enabled/zf2-tutorial:5:    SetEnv ZF2_PATH 
"/opt/php/ZendFramework/library"

Because:

$ ls -l /etc/apache2/sites-enabled/zf2-tutorial
lrwxrwxrwx 1 root root 31 Jul 23 06:13 /etc/apache2/sites-enabled/zf2-
tutorial -> ../sites-available/zf2-tutorial

And you need that “2>/dev/null” primarily because of *all* *the* *useless* 
*searches* in and below /etc/:

$ grep -InRwe ZF2_PATH /etc
grep: /etc/rc2.d/S22hal: No such file or directory
grep: /etc/rc2.d/S23saned: No such file or directory
grep: /etc/rc2.d/S21clamav-daemon: No such file or directory
grep: /etc/rc2.d/S25stop-bootlogd: No such file or directory
grep: /etc/rc2.d/S20foldingathome: No such file or directory
grep: /etc/rc2.d/S01portmap: No such file or directory
grep: /etc/auto.cifs.[…]: Permission denied
/etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
"/opt/php/ZendFramework/library"
/etc/apache2/sites-enabled/zf2-tutorial:5:    SetEnv ZF2_PATH 
"/opt/php/ZendFramework/library"
grep: /etc/default/cacerts: Permission denied
grep: /etc/gshadow-: Permission denied
grep: /etc/rc3.d/S22hal: No such file or directory
grep: /etc/rc3.d/S23saned: No such file or directory
grep: /etc/rc3.d/S21clamav-daemon: No such file or directory
grep: /etc/rc3.d/S25stop-bootlogd: No such file or directory
grep: /etc/rc3.d/S20foldingathome: No such file or directory
grep: /etc/rc3.d/S01portmap: No such file or directory
grep: /etc/.pwd.lock: Permission denied
grep: /etc/boinc-client/gui_rpc_auth.cfg: Permission denied
grep: /etc/polkit-1/localauthority: Permission denied
grep: /etc/rc6.d/K02clamav-daemon: No such file or directory
grep: /etc/rc6.d/K01saned: No such file or directory
grep: /etc/rc6.d/K01foldingathome: No such file or directory
grep: /etc/rc6.d/K01portmap: No such file or directory
grep: /etc/rc6.d/K01fuse: No such file or directory
grep: /etc/ppp/chap-secrets: Permission denied
grep: /etc/ppp/pap-secrets: Permission denied
grep: /etc/auto.smb.[…]: Permission denied
grep: /etc/rc5.d/S22hal: No such file or directory
grep: /etc/rc5.d/S23saned: No such file or directory
grep: /etc/rc5.d/S21clamav-daemon: No such file or directory
grep: /etc/rc5.d/S25stop-bootlogd: No such file or directory
grep: /etc/rc5.d/S18foldingathome: No such file or directory
grep: /etc/rc3.d/S01portmap: No such file or directory
grep: /etc/.pwd.lock: Permission denied
grep: /etc/boinc-client/gui_rpc_auth.cfg: Permission denied
grep: /etc/polkit-1/localauthority: Permission denied
grep: /etc/rc6.d/K02clamav-daemon: No such file or directory
grep: /etc/rc6.d/K01saned: No such file or directory
grep: /etc/rc6.d/K01foldingathome: No such file or directory
grep: /etc/rc6.d/K01portmap: No such file or directory
grep: /etc/rc6.d/K01fuse: No such file or directory
grep: /etc/ppp/chap-secrets: Permission denied
grep: /etc/ppp/pap-secrets: Permission denied
grep: /etc/auto.smb.amarone: Permission denied
grep: /etc/rc5.d/S22hal: No such file or directory
grep: /etc/rc5.d/S23saned: No such file or directory
grep: /etc/rc5.d/S21clamav-daemon: No such file or directory
grep: /etc/rc5.d/S25stop-bootlogd: No such file or directory
grep: /etc/rc5.d/S18foldingathome: No such file or directory
grep: /etc/rc5.d/S01portmap: No such file or directory
grep: /etc/dbconfig-common/phpmyadmin.conf: Permission denied
grep: /etc/dbconfig-common/config: Permission denied
grep: /etc/news/leafnode/config.0: Permission denied
grep: /etc/news/leafnode/config: Permission denied
grep: /etc/authbind/byuid/115: Permission denied
grep: /etc/exim4/passwd.client: Permission denied
grep: /etc/apt/trusted.gpg~: Permission denied
grep: /etc/apt/trusted.gpg: Permission denied
grep: /etc/X11/Xwrapper.config: Permission denied
grep: /etc/mtab.fuselock: Permission denied
grep: /etc/shadow: Permission denied
grep: /etc/ati/inst_path_override.backup-62: Permission denied
grep: /etc/ati/inst_path_default.backup-63: Permission denied
grep: /etc/ati/inst_path_default.backup-62: Permission denied
grep: /etc/ati/inst_path_override.backup-63: Permission denied
grep: /etc/group-: Permission denied
grep: /etc/sudoers.d/README: Permission denied
grep: /etc/rc1.d/K02clamav-daemon: No such file or directory
grep: /etc/rc1.d/K01saned: No such file or directory
grep: /etc/rc1.d/K01foldingathome: No such file or directory
grep: /etc/rc1.d/K01portmap: No such file or directory
grep: /etc/rc1.d/K01hal: No such file or directory
grep: /etc/sudoers: Permission denied
grep: /etc/rcS.d/S21microcode.ctl: No such file or directory
grep: /etc/rcS.d/S04bootlogd: No such file or directory
grep: /etc/rcS.d/S22stop-bootlogd-single: No such file or directory
grep: /etc/rcS.d/S21fuse: No such file or directory
grep: /etc/rcS.d/S13pcmciautils: No such file or directory
grep: /etc/rcS.d/S07hibernate: No such file or directory
grep: /etc/rcS.d/S09mtab.sh: No such file or directory
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleL_en_US_months_: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleL_en_US_days_: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/wpa_ctrl_10002-1: No such device or address
grep: /etc/dosemu/drives/d/tmp/qtsingleapp-homepe-d03a-3e8: No such device 
or address
grep: /etc/dosemu/drives/d/tmp/zend_cache---internal-metadatas---
Zend_LocaleC_en_US_pm_: Permission denied
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_field_week: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_am_: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_relative_0: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/.ICE-unix/5439: No such device or address
grep: /etc/dosemu/drives/d/tmp/ksocket-pelinux/klauncherMT5363.slave-socket: 
No such device or address
grep: /etc/dosemu/drives/d/tmp/ksocket-[…]/kdialogtQ8548.slave-socket: No 
such device or address
grep: /etc/dosemu/drives/d/tmp/ksocket-[…]/kdeinit4__0: No such device or 
address
grep: /etc/dosemu/drives/d/tmp/.X11-unix/X0: No such device or address
grep: /etc/dosemu/drives/d/tmp/zend_cache---internal-metadatas---
Zend_LocaleL_en_US_days_: Permission denied
grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_pm_: 
Permission denied
grep: /etc/dosemu/drives/d/tmp/akonadi-[…].wX8VmV/akonadiserver.socket: No 
such device or address
grep: /etc/dosemu/drives/d/tmp/akonadi-[…].wX8VmV/mysql.socket: No such 
device or address
grep: /etc/dosemu/drives/c/tmp/pulse-QUlSey7aLUGn/native: No such device or 
address
grep: /etc/dosemu/drives/c/tmp/pulse-QUlSey7aLUGn/dbus-socket: No such 
device or address
grep: /etc/dosemu/drives/c/tmp/ssh-tPv9ysn5Pz7x/agent.4909: No such device 
or address
grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
Zend_LocaleC_en_US_am_: Permission denied
grep: /etc/dosemu/drives/c/tmp/.wine-1000/server-803-1ac271/socket: No such 
device or address
grep: /etc/dosemu/drives/c/tmp/pulse-2L9K88eMlGn7: Permission denied
grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
Zend_LocaleC_en_US_relative_0: Permission denied
grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
Zend_LocaleC_en_US_field_week: Permission denied
grep: 
/etc/dosemu/drives/c/tmp/.org.chromium.Chromium.50SQiV/SingletonCookie: No 
such file or directory
grep: 
/etc/dosemu/drives/c/tmp/.org.chromium.Chromium.50SQiV/SingletonSocket: No 
such device or address
grep: /etc/dosemu/drives/c/tmp/pulse-PKdhtXMmr18n: Permission denied
grep: /etc/dosemu/drives/c/tmp/.winbindd/pipe: No such device or address
grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
Zend_LocaleL_en_US_months_: Permission denied
grep: /etc/dosemu/drives/c/tmp/.esd-1000/socket: No such device or address
grep: /etc/cups/classes.conf.O: Permission denied
grep: /etc/cups/printers.conf.O: Permission denied
grep: /etc/cups/ssl: Permission denied
grep: /etc/cups/classes.conf: Permission denied
grep: /etc/cups/printers.conf: Permission denied
grep: /etc/auto.smb.amarone.dys.ch: Permission denied
grep: /etc/rc4.d/S22hal: No such file or directory
grep: /etc/rc4.d/S23saned: No such file or directory
grep: /etc/rc4.d/S21clamav-daemon: No such file or directory
grep: /etc/rc4.d/S25stop-bootlogd: No such file or directory
grep: /etc/rc4.d/S18foldingathome: No such file or directory
grep: /etc/rc4.d/S01portmap: No such file or directory
grep: /etc/shadow-: Permission denied
grep: /etc/auto.smb.gentoo.dys.ch: Permission denied
grep: /etc/auto.smb.gentoo: Permission denied
grep: /etc/at.deny: Permission denied
grep: /etc/sudoers.dpkg-old: Permission denied
grep: /etc/websvn/svn_deb_conf.inc: Permission denied
grep: /etc/phpmyadmin/htpasswd.setup: Permission denied
grep: /etc/phpmyadmin/config-db.php: Permission denied
grep: /etc/gshadow: Permission denied
grep: /etc/mtab~24839: Permission denied
grep: warning: /etc/alternatives/libGL.so-master/libGL.so-master: recursive 
directory loop
grep: /etc/alternatives/pluginappletviewer: No such file or directory
grep: /etc/ssl/certs/TC_TrustCenter_Universal_CA_III.pem: No such file or 
directory
grep: /etc/ssl/certs/Equifax_Secure_eBusiness_CA_2.pem: No such file or 
directory
grep: /etc/ssl/private: Permission denied
grep: /etc/security/opasswd: Permission denied
grep: /etc/mysql/debian.cnf: Permission denied
grep: /etc/ssh/ssh_host_dsa_key: Permission denied
grep: /etc/ssh/ssh_host_rsa_key: Permission denied
grep: /etc/rc0.d/K02clamav-daemon: No such file or directory
grep: /etc/rc0.d/K01saned: No such file or directory
grep: /etc/rc0.d/K01foldingathome: No such file or directory
grep: /etc/rc0.d/K01portmap: No such file or directory
grep: /etc/rc0.d/K01fuse: No such file or directory
grep: /etc/passwd-: Permission denied

>>> -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.

IYVHO.  Since we are matching an expression *in* *any* *case* (unless we use 
“-F”), we might as well do it *properly* to *avoid* *false* *positives*.

Especially when we are – *unnecessarily* – searching a whole subtree, and – 
by *disadvantage* of “-R” instead of “-r” – maybe even *the* *whole* 
*system* *or* *LAN* (across filesystems even as allowed for symlinks).

>>> -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.

This time.  Next time you want to refine the search and then it may become 
necessary.

What you apparently do not get is that in *any* case (“-F” aside) a regular 
expression will be matched (an unescaped “.” even *without* “-e” – and 
without “-F” – means *any character* except newline; _not_ a literal dot.  
Quoted, but unescaped “[foo]” means the *character class* consisting of “f” 
and “o”, aso.)
 
>>> 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.

No, either you are lying or you are not running a standard Ubuntu Apache 
setup (set up with a2ensite(8)).

> 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.

No, you do not have to do such utter nonsense.  In fact, on a *real* server 
you might get in *real* *trouble* that way, causing that much system/disk 
load, and taking that unnecessarily long to fix the problem.

The *correct* and *responsible* approach is – after grepping 
httpd.conf/apache2.conf and the php.ini for Apache – to use grep(1) or 
ack(1) to find the Virtual Host configuration file (usually by domain name), 
inspect it with a text editor (I would suggest Vim because it can navigate 
with gf or C-w,f), check its includes, and check in and below its document 
root (since you *know* the path, you *know* where to look).
 

PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#11401

I'm afraid I have to full-quote that whole vitriolic nonsense...

On 2013-10-12 07:00, Thomas 'PointedEars' Lahn wrote:
> Fiver wrote:
>> 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.
> 
> We'll see about that.
>  
>>>> -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.
> 
> For what purpose?  Do you even know what a *binary* is?
>  
>> 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.
> 
> On a current Ubuntu Linux system, /etc/alternatives/php is a symlink to 
> /usr/bin/php5 (try “sudo update-alternatives --config php”):
> 
> $ ls -l /etc/alternatives/php
> lrwxrwxrwx 1 root root 13 Aug  8 09:50 /etc/alternatives/php -> 
> /usr/bin/php5
> 
> What sense does it make to search that binary, or any other binary?
> *None* *at* *all*.
> 
>>>> -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.
> 
> Well, *I* am having a _technical discussion_ with you.
> 
>>> “-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.
> 
> So you do not care about the consequences of your actions.  Very 
> professional, indeed :->
> 
> You would *honestly* recommend that to the OP?  No, I don't think so.
> 
>> 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)
> 
> Liar.
> 
>> 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).
> 
> Where have you learned to lie so badly?  In a *standard Ubuntu setup*,
> 
> 1. you would not be root (“#”) as Ubuntu does not set a password for root by
>    default.  You would be using sudo(8) instead.
> 
> 2. a recursive search would search in /etc/apache2/sites-available as well,
>    and would find *duplicate* results with “-R” because of symlinks
> 
> /etc/apache2/sites-enabled/040-redacted1 → /etc/apache2/sites-available/040-
> redacted1
> 
> aso.
> 
> Example:
> 
> $ cat /etc/apache2/sites-available/zf2-tutorial 
> <VirtualHost *:80>
>     ServerName zf2-tutorial.localhost
>     DocumentRoot /var/www/zf2-tutorial/public
>     SetEnv APPLICATION_ENV "development"
>     SetEnv ZF2_PATH "/opt/php/ZendFramework/library"
>     <Directory /var/www/zf2-tutorial/public>
>         DirectoryIndex index.php
>         AllowOverride All
>         Order allow,deny
>         Allow from all
>     </Directory>
> </VirtualHost>
> 
> $ grep -Inrwe ZF2_PATH /etc 2>/dev/null
> /etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
> "/opt/php/ZendFramework/library"
> 
> $ grep -InRwe ZF2_PATH /etc 2>/dev/null
> /etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
> "/opt/php/ZendFramework/library"
> /etc/apache2/sites-enabled/zf2-tutorial:5:    SetEnv ZF2_PATH 
> "/opt/php/ZendFramework/library"
> 
> Because:
> 
> $ ls -l /etc/apache2/sites-enabled/zf2-tutorial
> lrwxrwxrwx 1 root root 31 Jul 23 06:13 /etc/apache2/sites-enabled/zf2-
> tutorial -> ../sites-available/zf2-tutorial
> 
> And you need that “2>/dev/null” primarily because of *all* *the* *useless* 
> *searches* in and below /etc/:
> 
> $ grep -InRwe ZF2_PATH /etc
> grep: /etc/rc2.d/S22hal: No such file or directory
> grep: /etc/rc2.d/S23saned: No such file or directory
> grep: /etc/rc2.d/S21clamav-daemon: No such file or directory
> grep: /etc/rc2.d/S25stop-bootlogd: No such file or directory
> grep: /etc/rc2.d/S20foldingathome: No such file or directory
> grep: /etc/rc2.d/S01portmap: No such file or directory
> grep: /etc/auto.cifs.[…]: Permission denied
> /etc/apache2/sites-available/zf2-tutorial:5:    SetEnv ZF2_PATH 
> "/opt/php/ZendFramework/library"
> /etc/apache2/sites-enabled/zf2-tutorial:5:    SetEnv ZF2_PATH 
> "/opt/php/ZendFramework/library"
> grep: /etc/default/cacerts: Permission denied
> grep: /etc/gshadow-: Permission denied
> grep: /etc/rc3.d/S22hal: No such file or directory
> grep: /etc/rc3.d/S23saned: No such file or directory
> grep: /etc/rc3.d/S21clamav-daemon: No such file or directory
> grep: /etc/rc3.d/S25stop-bootlogd: No such file or directory
> grep: /etc/rc3.d/S20foldingathome: No such file or directory
> grep: /etc/rc3.d/S01portmap: No such file or directory
> grep: /etc/.pwd.lock: Permission denied
> grep: /etc/boinc-client/gui_rpc_auth.cfg: Permission denied
> grep: /etc/polkit-1/localauthority: Permission denied
> grep: /etc/rc6.d/K02clamav-daemon: No such file or directory
> grep: /etc/rc6.d/K01saned: No such file or directory
> grep: /etc/rc6.d/K01foldingathome: No such file or directory
> grep: /etc/rc6.d/K01portmap: No such file or directory
> grep: /etc/rc6.d/K01fuse: No such file or directory
> grep: /etc/ppp/chap-secrets: Permission denied
> grep: /etc/ppp/pap-secrets: Permission denied
> grep: /etc/auto.smb.[…]: Permission denied
> grep: /etc/rc5.d/S22hal: No such file or directory
> grep: /etc/rc5.d/S23saned: No such file or directory
> grep: /etc/rc5.d/S21clamav-daemon: No such file or directory
> grep: /etc/rc5.d/S25stop-bootlogd: No such file or directory
> grep: /etc/rc5.d/S18foldingathome: No such file or directory
> grep: /etc/rc3.d/S01portmap: No such file or directory
> grep: /etc/.pwd.lock: Permission denied
> grep: /etc/boinc-client/gui_rpc_auth.cfg: Permission denied
> grep: /etc/polkit-1/localauthority: Permission denied
> grep: /etc/rc6.d/K02clamav-daemon: No such file or directory
> grep: /etc/rc6.d/K01saned: No such file or directory
> grep: /etc/rc6.d/K01foldingathome: No such file or directory
> grep: /etc/rc6.d/K01portmap: No such file or directory
> grep: /etc/rc6.d/K01fuse: No such file or directory
> grep: /etc/ppp/chap-secrets: Permission denied
> grep: /etc/ppp/pap-secrets: Permission denied
> grep: /etc/auto.smb.amarone: Permission denied
> grep: /etc/rc5.d/S22hal: No such file or directory
> grep: /etc/rc5.d/S23saned: No such file or directory
> grep: /etc/rc5.d/S21clamav-daemon: No such file or directory
> grep: /etc/rc5.d/S25stop-bootlogd: No such file or directory
> grep: /etc/rc5.d/S18foldingathome: No such file or directory
> grep: /etc/rc5.d/S01portmap: No such file or directory
> grep: /etc/dbconfig-common/phpmyadmin.conf: Permission denied
> grep: /etc/dbconfig-common/config: Permission denied
> grep: /etc/news/leafnode/config.0: Permission denied
> grep: /etc/news/leafnode/config: Permission denied
> grep: /etc/authbind/byuid/115: Permission denied
> grep: /etc/exim4/passwd.client: Permission denied
> grep: /etc/apt/trusted.gpg~: Permission denied
> grep: /etc/apt/trusted.gpg: Permission denied
> grep: /etc/X11/Xwrapper.config: Permission denied
> grep: /etc/mtab.fuselock: Permission denied
> grep: /etc/shadow: Permission denied
> grep: /etc/ati/inst_path_override.backup-62: Permission denied
> grep: /etc/ati/inst_path_default.backup-63: Permission denied
> grep: /etc/ati/inst_path_default.backup-62: Permission denied
> grep: /etc/ati/inst_path_override.backup-63: Permission denied
> grep: /etc/group-: Permission denied
> grep: /etc/sudoers.d/README: Permission denied
> grep: /etc/rc1.d/K02clamav-daemon: No such file or directory
> grep: /etc/rc1.d/K01saned: No such file or directory
> grep: /etc/rc1.d/K01foldingathome: No such file or directory
> grep: /etc/rc1.d/K01portmap: No such file or directory
> grep: /etc/rc1.d/K01hal: No such file or directory
> grep: /etc/sudoers: Permission denied
> grep: /etc/rcS.d/S21microcode.ctl: No such file or directory
> grep: /etc/rcS.d/S04bootlogd: No such file or directory
> grep: /etc/rcS.d/S22stop-bootlogd-single: No such file or directory
> grep: /etc/rcS.d/S21fuse: No such file or directory
> grep: /etc/rcS.d/S13pcmciautils: No such file or directory
> grep: /etc/rcS.d/S07hibernate: No such file or directory
> grep: /etc/rcS.d/S09mtab.sh: No such file or directory
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleL_en_US_months_: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleL_en_US_days_: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/wpa_ctrl_10002-1: No such device or address
> grep: /etc/dosemu/drives/d/tmp/qtsingleapp-homepe-d03a-3e8: No such device 
> or address
> grep: /etc/dosemu/drives/d/tmp/zend_cache---internal-metadatas---
> Zend_LocaleC_en_US_pm_: Permission denied
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_field_week: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_am_: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_relative_0: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/.ICE-unix/5439: No such device or address
> grep: /etc/dosemu/drives/d/tmp/ksocket-pelinux/klauncherMT5363.slave-socket: 
> No such device or address
> grep: /etc/dosemu/drives/d/tmp/ksocket-[…]/kdialogtQ8548.slave-socket: No 
> such device or address
> grep: /etc/dosemu/drives/d/tmp/ksocket-[…]/kdeinit4__0: No such device or 
> address
> grep: /etc/dosemu/drives/d/tmp/.X11-unix/X0: No such device or address
> grep: /etc/dosemu/drives/d/tmp/zend_cache---internal-metadatas---
> Zend_LocaleL_en_US_days_: Permission denied
> grep: /etc/dosemu/drives/d/tmp/zend_cache---Zend_LocaleC_en_US_pm_: 
> Permission denied
> grep: /etc/dosemu/drives/d/tmp/akonadi-[…].wX8VmV/akonadiserver.socket: No 
> such device or address
> grep: /etc/dosemu/drives/d/tmp/akonadi-[…].wX8VmV/mysql.socket: No such 
> device or address
> grep: /etc/dosemu/drives/c/tmp/pulse-QUlSey7aLUGn/native: No such device or 
> address
> grep: /etc/dosemu/drives/c/tmp/pulse-QUlSey7aLUGn/dbus-socket: No such 
> device or address
> grep: /etc/dosemu/drives/c/tmp/ssh-tPv9ysn5Pz7x/agent.4909: No such device 
> or address
> grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
> Zend_LocaleC_en_US_am_: Permission denied
> grep: /etc/dosemu/drives/c/tmp/.wine-1000/server-803-1ac271/socket: No such 
> device or address
> grep: /etc/dosemu/drives/c/tmp/pulse-2L9K88eMlGn7: Permission denied
> grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
> Zend_LocaleC_en_US_relative_0: Permission denied
> grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
> Zend_LocaleC_en_US_field_week: Permission denied
> grep: 
> /etc/dosemu/drives/c/tmp/.org.chromium.Chromium.50SQiV/SingletonCookie: No 
> such file or directory
> grep: 
> /etc/dosemu/drives/c/tmp/.org.chromium.Chromium.50SQiV/SingletonSocket: No 
> such device or address
> grep: /etc/dosemu/drives/c/tmp/pulse-PKdhtXMmr18n: Permission denied
> grep: /etc/dosemu/drives/c/tmp/.winbindd/pipe: No such device or address
> grep: /etc/dosemu/drives/c/tmp/zend_cache---internal-metadatas---
> Zend_LocaleL_en_US_months_: Permission denied
> grep: /etc/dosemu/drives/c/tmp/.esd-1000/socket: No such device or address
> grep: /etc/cups/classes.conf.O: Permission denied
> grep: /etc/cups/printers.conf.O: Permission denied
> grep: /etc/cups/ssl: Permission denied
> grep: /etc/cups/classes.conf: Permission denied
> grep: /etc/cups/printers.conf: Permission denied
> grep: /etc/auto.smb.amarone.dys.ch: Permission denied
> grep: /etc/rc4.d/S22hal: No such file or directory
> grep: /etc/rc4.d/S23saned: No such file or directory
> grep: /etc/rc4.d/S21clamav-daemon: No such file or directory
> grep: /etc/rc4.d/S25stop-bootlogd: No such file or directory
> grep: /etc/rc4.d/S18foldingathome: No such file or directory
> grep: /etc/rc4.d/S01portmap: No such file or directory
> grep: /etc/shadow-: Permission denied
> grep: /etc/auto.smb.gentoo.dys.ch: Permission denied
> grep: /etc/auto.smb.gentoo: Permission denied
> grep: /etc/at.deny: Permission denied
> grep: /etc/sudoers.dpkg-old: Permission denied
> grep: /etc/websvn/svn_deb_conf.inc: Permission denied
> grep: /etc/phpmyadmin/htpasswd.setup: Permission denied
> grep: /etc/phpmyadmin/config-db.php: Permission denied
> grep: /etc/gshadow: Permission denied
> grep: /etc/mtab~24839: Permission denied
> grep: warning: /etc/alternatives/libGL.so-master/libGL.so-master: recursive 
> directory loop
> grep: /etc/alternatives/pluginappletviewer: No such file or directory
> grep: /etc/ssl/certs/TC_TrustCenter_Universal_CA_III.pem: No such file or 
> directory
> grep: /etc/ssl/certs/Equifax_Secure_eBusiness_CA_2.pem: No such file or 
> directory
> grep: /etc/ssl/private: Permission denied
> grep: /etc/security/opasswd: Permission denied
> grep: /etc/mysql/debian.cnf: Permission denied
> grep: /etc/ssh/ssh_host_dsa_key: Permission denied
> grep: /etc/ssh/ssh_host_rsa_key: Permission denied
> grep: /etc/rc0.d/K02clamav-daemon: No such file or directory
> grep: /etc/rc0.d/K01saned: No such file or directory
> grep: /etc/rc0.d/K01foldingathome: No such file or directory
> grep: /etc/rc0.d/K01portmap: No such file or directory
> grep: /etc/rc0.d/K01fuse: No such file or directory
> grep: /etc/passwd-: Permission denied
> 
>>>> -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.
> 
> IYVHO.  Since we are matching an expression *in* *any* *case* (unless we use 
> “-F”), we might as well do it *properly* to *avoid* *false* *positives*.
> 
> Especially when we are – *unnecessarily* – searching a whole subtree, and – 
> by *disadvantage* of “-R” instead of “-r” – maybe even *the* *whole* 
> *system* *or* *LAN* (across filesystems even as allowed for symlinks).
> 
>>>> -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.
> 
> This time.  Next time you want to refine the search and then it may become 
> necessary.
> 
> What you apparently do not get is that in *any* case (“-F” aside) a regular 
> expression will be matched (an unescaped “.” even *without* “-e” – and 
> without “-F” – means *any character* except newline; _not_ a literal dot.  
> Quoted, but unescaped “[foo]” means the *character class* consisting of “f” 
> and “o”, aso.)
>  
>>>> 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.
> 
> No, either you are lying or you are not running a standard Ubuntu Apache 
> setup (set up with a2ensite(8)).
> 
>> 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.
> 
> No, you do not have to do such utter nonsense.  In fact, on a *real* server 
> you might get in *real* *trouble* that way, causing that much system/disk 
> load, and taking that unnecessarily long to fix the problem.
> 
> The *correct* and *responsible* approach is – after grepping 
> httpd.conf/apache2.conf and the php.ini for Apache – to use grep(1) or 
> ack(1) to find the Virtual Host configuration file (usually by domain name), 
> inspect it with a text editor (I would suggest Vim because it can navigate 
> with gf or C-w,f), check its includes, and check in and below its document 
> root (since you *know* the path, you *know* where to look).

You've got to be joking, right?

@Jerry, I take it all back. I'm afraid you were right. I recently read
something about the inability of some people to admit to mistakes; it's
a classical symptom of narcissistic personality disorder.

Thomas, are you ill or something? I didn't attack you in any way.
There's no need to be so absurdly aggressive and hostile.

And calling me a liar, several times. It just shows that you seriously
lack understanding of the Ubuntu/Debian file layout. The results I gave
you were pasted word-for-word from the box I'm typing on, with only two
minor modifications:
 - I replaced the actual project and host names with "redacted"
 - I added some artificial line breaks for Usenet

The directory /etc/apache2/sites-enabled usually contains links, but
*nothing* says that the source of those links has to be
/etc/apache2/sites-available. I tend to place a new vhost config file
into its project's SVN directory, where it belongs, and then link it
into sites-enabled. a2ensite/a2dissite are not used here. Think about
it; this should explain the misconceptions making up the largest part of
your post.

What else was there... oh yes, "I could not be root in Ubuntu". You need
to do some serious studying before you try to go lecturing others. Try
"sudo -s" for a start. If you managed to miss that in "13 years of
professionally maintaining GNU/Linux systems", I feel sorry for your
clients.

The rest of your "arguments", as far as I can see, was just you trying
to belittle somebody who knows what they're doing a whole lot better
than you.

I had some hope that we would manage to come up with a more generic way
of locating PHP config settings, but... this was truly pathetic. You
should be ashamed.

Yes, I'm angry now.

And I have better things to do than quarrel with arrogant upstarts like
you. If you don't have anything valuable to add, I won't be replying to
your garbage anymore.


regards,
5er

[toc] | [prev] | [next] | [standalone]

#11411

Fiver wrote:

> I'm afraid I have to full-quote that whole vitriolic nonsense...

Thanks, but no, thanks.
 
> And calling me a liar, several times.

I called you a liar one time, with the provision that it is also possible 
that you simply may not know what you are talking about.  That you do not 
know what you are talking about is indicated by several facts, for example 
that you consider it worthwhile to search binaries for plain text to solve 
the problem at hand.

> It just shows that you seriously lack understanding of the Ubuntu/Debian
> file layout.

YMMD.

> The results I gave you were pasted word-for-word from the box I'm typing
> on, with only two minor modifications:
>  - I replaced the actual project and host names with "redacted"
>  - I added some artificial line breaks for Usenet
> 
> The directory /etc/apache2/sites-enabled usually contains links, but
> *nothing* says that the source of those links has to be
> /etc/apache2/sites-available.

a2ensite(8) does.  That is the tool you use in Debian-based systems like 
Ubuntu to manage Virtual Hosts.  If you are a responsible server 
administrator anyway.

> I tend to place a new vhost config file into its project's SVN directory,
> where it belongs,

No, it does not.  Not everybody checking out the project needs to have the 
same paths.  In fact, it is rather very unlikely that they have the same 
paths on their local servers as on the remote server, and including the VH 
configuration in the repository could be viewed as both as a hassle for 
committers and a security risk.  Those files or their contents should be 
distributed via other means, for example in a secured team wiki.

> and then link it into sites-enabled. a2ensite/a2dissite are not used here.

Your problem.  It bears no relevance to the OP's problem with a vintage 
Ubuntu Linux, though.

> Think about it; this should explain the misconceptions making up the
> largest part of your post.

There are no misconceptions on my part here.  You are comparing apples and 
oranges, taking an arbitrary Linux-based system as basis for your fallacious 
arguments.
 
> What else was there... oh yes, "I could not be root in Ubuntu".

I did not say that, for I *know* how one can be root on Ubuntu despite the 
defaults (BTDT).  I said you *would* not *be* root *by default* on Ubuntu.  
Big difference.

> And I have better things to do than quarrel with arrogant upstarts like
> you. If you don't have anything valuable to add, I won't be replying to
> your garbage anymore.

One must wonder if you posted this way if you had to stand by your position 
and your postings with your real name like people taking responsibility for 
their actions would.

Score adjusted

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#11402

On 2013-10-11 10:32 PM, Fiver wrote:
> 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/
>>>>
...
>
>
> 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.
>

I didn't either and I suspect most didn't. And you're best off ignoring 
suckle, I mean, stuckle; he's always looking to extend a convo off 
topic, and sometimes even actually makes his trolling obvious. I don't 
read his posts; pretty much just ignore them. I know what he's said just 
by what he replies to anymore. He's improved lately but still has a long 
ways to go.

It's all good!

Twayne`

[toc] | [prev] | [next] | [standalone]

#11403

On 10/12/2013 10:08 AM, Twayne wrote:
> On 2013-10-11 10:32 PM, Fiver wrote:
>> 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/
>>>>>
> ...
>>
>>
>> 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.
>>
>
> I didn't either and I suspect most didn't. And you're best off ignoring
> suckle, I mean, stuckle; he's always looking to extend a convo off
> topic, and sometimes even actually makes his trolling obvious. I don't
> read his posts; pretty much just ignore them. I know what he's said just
> by what he replies to anymore. He's improved lately but still has a long
> ways to go.
>
> It's all good!
>
> Twayne`

Another troll speaks out. You can tell by the name calling.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11394

On 10/11/2013 6:27 PM, 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).
>
> -I
>    skips all files detected as binary; probably makes no difference in
>    this case, but might hide information you're looking for
> -r
>    skips symlinked files that the GP would have included with -R;
>    definitely a bad choice when searching for a mystery config setting
> -w
>    pointless, unless you expect upload_max_filesize to be part of a
>    longer word
> -e
>    pointless, unless you're using a regex, which you're not
>
>> 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. 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.
>
> regards,
> 5er
>

Please don't feed the troll.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web