| Can't change upload_max_filesize [message #183118] |
Wed, 09 October 2013 21:27  |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183120 is a reply to message #183118] |
Wed, 09 October 2013 21:49  |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183145 is a reply to message #183120] |
Thu, 10 October 2013 20:32 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183146 is a reply to message #183145] |
Thu, 10 October 2013 21:01 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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(at)94(dot)75(dot)214(dot)39>
|
|
|
|
|
|
| Re: Can't change upload_max_filesize [message #183149 is a reply to message #183145] |
Thu, 10 October 2013 22:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/10/2013 4:32 PM, Tobiah wrote:
> 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 t his 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
In addition to restarting Apache as Dennis said, do you have the one or
both values defined anywhere else? grep might help you here. It might,
for instance, be in an Apache configuration file, a .htaccess file or
even a local php.ini file.
P.S. Don't concern yourself with T.L. It isn't his ears that are pointed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183156 is a reply to message #183147] |
Fri, 11 October 2013 00:28 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
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 ;)
|
|
|
|
| Re: Can't change upload_max_filesize [message #183157 is a reply to message #183149] |
Fri, 11 October 2013 00:32 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 10/10/2013 3:07 PM, Jerry Stuckle wrote:
> On 10/10/2013 4:32 PM, Tobiah wrote:
>> 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 t his 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
>
> In addition to restarting Apache as Dennis said, do you have the one or
> both values defined anywhere else? grep might help you here. It might,
> for instance, be in an Apache configuration file, a .htaccess file or
> even a local php.ini file.
Well, I haven't been too concerned about that, because this is just
a straight Ubuntu install on my own machine. Do you think it's possible
that Ubuntu did something so horrible as to hide overrides to these
configuration options somewhere other than the php.ini? Also, I tried
a .htaccess in the directory I'm running from, and it didn't work.
Wouldn't that take precedence over the httpd.conf? I'm not sure.
Anywhere else I should look?
Thanks for your help,
Tobiah
> P.S. Don't concern yourself with T.L. It isn't his ears that are pointed.
Thanks for that. Why is he so abrasive?
Tobiah
|
|
|
|
| Re: Can't change upload_max_filesize [message #183165 is a reply to message #183157] |
Fri, 11 October 2013 02:46 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/10/2013 8:32 PM, Tobiah wrote:
> On 10/10/2013 3:07 PM, Jerry Stuckle wrote:
>> On 10/10/2013 4:32 PM, Tobiah wrote:
>>> 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 t his 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
>>
>> In addition to restarting Apache as Dennis said, do you have the one or
>> both values defined anywhere else? grep might help you here. It might,
>> for instance, be in an Apache configuration file, a .htaccess file or
>> even a local php.ini file.
>
> Well, I haven't been too concerned about that, because this is just
> a straight Ubuntu install on my own machine. Do you think it's possible
> that Ubuntu did something so horrible as to hide overrides to these
> configuration options somewhere other than the php.ini? Also, I tried
> a .htaccess in the directory I'm running from, and it didn't work.
> Wouldn't that take precedence over the httpd.conf? I'm not sure.
> Anywhere else I should look?
>
OK, let's start at the beginning. You said you have a stock Ubuntu
installation, so /etc/php5/apache2/php.ini would be the correct
configuration file. However, what about other configuration files being
parsed? They will be done after the php.ini file. Any one of them
could override it.
As to whether you can use .htaccess or not depends Apache options. The
default for Ubuntu is to not allow overrides from .htaccess, which is
why it didn't work (see the AllowOverrides Apache command).
I installed Apache and PHP on a test Ubuntu system I have here, and made
the following changes to the /etc/php5/apache2/php.ini file
post_max_size=16M
upload_max_filesize=8M
and restarted Apache. The changes were reflected in the phpinfo() page,
so it does work. Please check your changes again. Exactly what did you
enter in the file?
BTW, standard Ubuntu and Debian operation is to NOT change the default
configuration files. Rather, you add the parameters you want to a new
file in a directory reserved for it - in this case,
/etc/php5/apache2/conf.d. That way when you update a package, your
customized changes don't get lost. Placing these same changes in
/etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
> Thanks for your help,
>
> Tobiah
>
>> P.S. Don't concern yourself with T.L. It isn't his ears that are
>> pointed.
>
> Thanks for that. Why is he so abrasive?
>
> Tobiah
>
>
That's just "Pointed Head". He has his own rules for usenet, and thinks
the rest of the world should follow them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183174 is a reply to message #183156] |
Fri, 11 October 2013 15:18 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)gmail(dot)com
|
|
|
|
| Re: Can't change upload_max_filesize [message #183177 is a reply to message #183174] |
Fri, 11 October 2013 17:05 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183178 is a reply to message #183165] |
Fri, 11 October 2013 17:16 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
> BTW, standard Ubuntu and Debian operation is to NOT change the default configuration files. Rather, you add the parameters you want
> to a new file in a directory reserved for it - in this case, /etc/php5/apache2/conf.d. That way when you update a package, your
> customized changes don't get lost. Placing these same changes in /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
Ding ding ding!
I put the to lines in question:
post_max_size = 200M
upload_max_filesize = 200M
into a new file in conf.d, and php.ini immediately
reflected the changes, and large uploads work now. Yay.
Thanks for your help,
Tobiah
|
|
|
|
| Re: Can't change upload_max_filesize [message #183179 is a reply to message #183178] |
Fri, 11 October 2013 17:28 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Tobiah wrote:
>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>> configuration files. Rather, you add the parameters you want
>> to a new file in a directory reserved for it - in this case,
>> /etc/php5/apache2/conf.d. That way when you update a package, your
>> customized changes don't get lost. Placing these same changes in
>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>
> Ding ding ding!
>
> I put the to lines in question:
>
> post_max_size = 200M
> upload_max_filesize = 200M
>
> into a new file in conf.d, and php.ini immediately
> reflected the changes, and large uploads work now. Yay.
As no doubt phpinfo() has told you to do.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
| Re: Can't change upload_max_filesize [message #183180 is a reply to message #183178] |
Fri, 11 October 2013 17:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/11/2013 1:16 PM, Tobiah wrote:
>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>> configuration files. Rather, you add the parameters you want
>> to a new file in a directory reserved for it - in this case,
>> /etc/php5/apache2/conf.d. That way when you update a package, your
>> customized changes don't get lost. Placing these same changes in
>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>
> Ding ding ding!
>
> I put the to lines in question:
>
> post_max_size = 200M
> upload_max_filesize = 200M
>
> into a new file in conf.d, and php.ini immediately
> reflected the changes, and large uploads work now. Yay.
>
> Thanks for your help,
>
> Tobiah
>
That's great.
I don't know why it didn't work in your php.ini file, unless you added
the lines at the beginning of the file (and didn't delete the later
entries).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183181 is a reply to message #183174] |
Fri, 11 October 2013 17:23 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: Can't change upload_max_filesize [message #183182 is a reply to message #183180] |
Fri, 11 October 2013 17:34 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 10/11/2013 10:29 AM, Jerry Stuckle wrote:
> On 10/11/2013 1:16 PM, Tobiah wrote:
>>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>>> configuration files. Rather, you add the parameters you want
>>> to a new file in a directory reserved for it - in this case,
>>> /etc/php5/apache2/conf.d. That way when you update a package, your
>>> customized changes don't get lost. Placing these same changes in
>>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>>
>> Ding ding ding!
>>
>> I put the to lines in question:
>>
>> post_max_size = 200M
>> upload_max_filesize = 200M
>>
>> into a new file in conf.d, and php.ini immediately
>> reflected the changes, and large uploads work now. Yay.
I meant that phpinfo() reflected the changes.
>> Thanks for your help,
>>
>> Tobiah
>>
>
> That's great.
>
> I don't know why it didn't work in your php.ini file, unless you added the lines at the beginning of the file (and didn't delete the
> later entries).
>
No, I just edited the values in place, and
the values don't exist anywhere else in the
file, or anywhere else in /etc for that matter.
Anyway, it seems that the conf.d method is
superior for reasons that you mentioned, so
I'm happy.
Tobiah
|
|
|
|
| Re: Can't change upload_max_filesize [message #183183 is a reply to message #183179] |
Fri, 11 October 2013 17:36 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 10/11/2013 10:28 AM, Thomas 'PointedEars' Lahn wrote:
> Tobiah wrote:
>
>>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>>> configuration files. Rather, you add the parameters you want
>>> to a new file in a directory reserved for it - in this case,
>>> /etc/php5/apache2/conf.d. That way when you update a package, your
>>> customized changes don't get lost. Placing these same changes in
>>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>>
>> Ding ding ding!
>>
>> I put the to lines in question:
>>
>> post_max_size = 200M
>> upload_max_filesize = 200M
>>
>> into a new file in conf.d, and php.ini immediately
>> reflected the changes, and large uploads work now. Yay.
>
> As no doubt phpinfo() has told you to do.
It mentions the conf.d directory, but it doesn't
tell me that changes in the php.ini won't take effect.
Always a pleasure...
Tobiah
|
|
|
|
| Re: Can't change upload_max_filesize [message #183184 is a reply to message #183182] |
Fri, 11 October 2013 18:20 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/11/2013 1:34 PM, Tobiah wrote:
> On 10/11/2013 10:29 AM, Jerry Stuckle wrote:
>> On 10/11/2013 1:16 PM, Tobiah wrote:
>>>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>>>> configuration files. Rather, you add the parameters you want
>>>> to a new file in a directory reserved for it - in this case,
>>>> /etc/php5/apache2/conf.d. That way when you update a package, your
>>>> customized changes don't get lost. Placing these same changes in
>>>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>>>
>>> Ding ding ding!
>>>
>>> I put the to lines in question:
>>>
>>> post_max_size = 200M
>>> upload_max_filesize = 200M
>>>
>>> into a new file in conf.d, and php.ini immediately
>>> reflected the changes, and large uploads work now. Yay.
>
> I meant that phpinfo() reflected the changes.
>
>>> Thanks for your help,
>>>
>>> Tobiah
>>>
>>
>> That's great.
>>
>> I don't know why it didn't work in your php.ini file, unless you added
>> the lines at the beginning of the file (and didn't delete the
>> later entries).
>>
>
> No, I just edited the values in place, and
> the values don't exist anywhere else in the
> file, or anywhere else in /etc for that matter.
>
> Anyway, it seems that the conf.d method is
> superior for reasons that you mentioned, so
> I'm happy.
>
> Tobiah
>
I don't know why it didn't work in your php.ini file, then. It did when
I made the change to my file.
But as long as you got it working, that's good.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183185 is a reply to message #183183] |
Fri, 11 October 2013 20:01 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Tobiah wrote:
> On 10/11/2013 10:28 AM, Thomas 'PointedEars' Lahn wrote:
>> Tobiah wrote:
>>>> BTW, standard Ubuntu and Debian operation is to NOT change the default
>>>> configuration files. Rather, you add the parameters you want
>>>> to a new file in a directory reserved for it - in this case,
>>>> /etc/php5/apache2/conf.d. That way when you update a package, your
>>>> customized changes don't get lost. Placing these same changes in
>>>> /etc/php5/apache2/conf.d/zzzmyconfig.ini also worked.
>>>
>>> Ding ding ding!
>>>
>>> I put the to lines in question:
>>>
>>> post_max_size = 200M
>>> upload_max_filesize = 200M
>>>
>>> into a new file in conf.d, and php.ini immediately
>>> reflected the changes, and large uploads work now. Yay.
>>
>> As no doubt phpinfo() has told you to do.
>
> It mentions the conf.d directory, but it doesn't
> tell me that changes in the php.ini won't take effect.
Because that is _not_ what happens.
> Always a pleasure...
Likewise.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: Can't change upload_max_filesize [message #183186 is a reply to message #183118] |
Fri, 11 October 2013 20:21 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-10-09 5:27 PM, 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
>
> Thanks for any help!
>
> Tobiah
>
No time to read every post, but ... is it possible your servers are
imposing the 1M limit? Some do.
Twayne`
|
|
|
|
| Re: Can't change upload_max_filesize [message #183188 is a reply to message #183181] |
Fri, 11 October 2013 22:27 |
Fiver
Messages: 35
Registered: July 2013
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183190 is a reply to message #183188] |
Sat, 12 October 2013 00:45 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183191 is a reply to message #183188] |
Sat, 12 October 2013 01:48 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| 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: 0
|
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.
|
|
|
|
| Re: Can't change upload_max_filesize [message #183194 is a reply to message #183193] |
Sat, 12 October 2013 02:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183195 is a reply to message #183194] |
Sat, 12 October 2013 03:19 |
Fiver
Messages: 35
Registered: July 2013
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183200 is a reply to message #183193] |
Sat, 12 October 2013 05:00 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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[url=:space:]:space:[/url]*=',
>> '\<php_\(admin_\)\?value[url=:space:]:space:[/url]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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183203 is a reply to message #183200] |
Sat, 12 October 2013 07:15 |
Fiver
Messages: 35
Registered: July 2013
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Can't change upload_max_filesize [message #183207 is a reply to message #183193] |
Sat, 12 October 2013 14:08 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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`
|
|
|
|
| Re: Can't change upload_max_filesize [message #183208 is a reply to message #183207] |
Sat, 12 October 2013 14:12 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Can't change upload_max_filesize [message #183216 is a reply to message #183203] |
Sat, 12 October 2013 17:51 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]