Upgrade to 1.9.17 strftime() and date() Problem

Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -
Number of replies: 40

After Upgrade to 1.9.17+ of 20120329, I get a lot of similar errors, in every module where strftime() function is called:

Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /myMoodle/lib/moodlelib.php on line 1261

And also

Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /myMoodle/lib/phpmailer/class.phpmailer.php on line 1476

It is on my test-server where debugging is active, but I want to be sure before I upgrade my production site.

Rosario

Average of ratings: -
In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Actually I have two test servers and it appears only on the VMware virtual machine. So I will have to investigate there but any hints are welcome. SLES 11 SP 2 for VMware.

Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

You can set the time-zone under Admin -> Location. You just need to do that.

In reply to Tim Hunt

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Thanks Tim but the settings were correct before and I just checked them again.  Server local time and Switzerland as default country.

I just removed the one and only entry in the latest news forum and the warnings disappeared. I will try to insert another post now.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

It seems to be only the latest news block. If I remove it, the warnings disappear and if I add it back, they are displayed again.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

I can not add back any post. I get other errors now, as if code or database had gone mad. If needed I will reset the whole instance as it is only a test-server.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
it seems to me you're using PHP 5.3 and your php.ini is actually missing to properly define a default time zone e.g.:

# vi /etc/php.ini
...
[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
;date.timezone =
date.timezone = 'Europe/Zurich'

HTH,
Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Heiiiii, that's true, on the VM I am using the latest SUSE SLES 11 SP2 for VMware, because I want to test it (like I did 2009 when it turned to an absolute nightmare).

And I have another physical test-server (my first Moodle server from 2007) where I installed SP 2, but of the normal SLES 11 distro. So I will repeat the upgrade to 1.9.17+ also on this machine.

I will have a look at it and report back. Rosario

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Matteo, I need your advice on this:

- on my production Server, php 5.2.14 date.timezone is commented out and not defined

- on my test Server, php 5.3.8 I have two php.ini files, one for apache2 and one for /etc/php5/cli command-line execution of php-scripts. In the apache php.ini it was not defined. And in the /cli it was set to

date.timezone = 'UTC'

So what do you suggest is the best setting? Rosario

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

The PHP manual says before PHP 5.4 the timezone was "guessed" and read from the OS environment variable TZ:

date.timezone: The default timezone used by all date/time functions. Prior to PHP 5.4.0, this would only work if the TZ environment variable was not set. The precedence order for which timezone is used if none is explicitly mentioned is described in the date_default_timezone_get() page.

And here it says we should set it correctly and that default is UTC anyway:

http://www.php.net/manual/en/function.date-default-timezone-get.php

Only to be complete, here is the list of Abbreviations: http://ch.php.net/manual/en/timezones.php

So I will try with Europe/Zurich.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
sorry for this late reply (I can do it in my spare time...): you can define "any" timezone you want, see the hyperlinks in my posts, extra text link included but... you've already found infos by yourself.

I'm used to define it according to the timezone used to define the clock in the server assuming that the clock is consistent with the services delivered. Moodle will do its job considering the server time according to this definition too but it will work with "any" definition: it's a PHP (required in 5.3+) definition before being something related with the Moodle instance.

Refs: MDL-22625.

HTH,
Matteo

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

After correcting timezone settings I get no date/time errors but if I add a new post into the latest news forum on the frontpage I get another couple of errors:

Notice: Undefined index: tmp_name in /myMoodle/lib/uploadlib.php on line 171
Notice: Undefined index: error in /myMoodle/lib/uploadlib.php on line 368
Notice: Undefined index: size in /myMoodle/lib/uploadlib.php on line 370
Notice: Undefined index: error in /myMoodle/lib/uploadlib.php on line 110
Notice: Undefined index: error in /myMoodle/lib/formslib.php on line 239

No matter if I do or do not choose a file for upload. Very strange.

I will repeat the upgrade now on my old physical server, just to see whether it is an issue with my Virtual Maschine rather than with this latest upgrade.

Bytheway I had to edit a big number of php-files because the cvs upgrade placed its

>>>>>>> and <<<<<<< and ======= lines in them.

This is very inconvenient, as you do not see any errors in apache-access and apache-error logs if compilation is broken this way. I guess it would be better to track if an undefined function or function-call would be placed there instead, or a function call with wrong parameters.

Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Adding a new course works fine. But adding a news post or a new user, where you can choose a file to upload, I get the above errors. It is as if the form asking for an optional file to upload would fail.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
these errors are something bad: the PHP upload subsystem is not properly working. Take a look at post_max_size, upload_max_filesize, max_input_time to see if they are misconfigured.

Please, look also at the PHP info (even from Moodle) to see if everything is OK with PHP Files upload: nothing related with Moodle 1.9.15+ code VS potential issues with 5.3+.

I'll check if I've a server running 5.3.8 and enough spare time to try a new fresh install of Moodle 1.9.17+ but I'm pretty sure that it is a "pure PHP configuration" issue rather than a "Moodle 1.9.17+ running on PHP 5.3+" issue.

HTH,
Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Basically I copied the existing php.ini or there was already the one used before upgrade to Service Pack 2. And I checked all settings when I checked date.timezone. But anyway here are my settings:

post_max_size = 200M
upload_max_filesize = 200M
max_input_time = 60
max_execution_time = 30
memory_limit = 1024M (Should I write 1G or keep it below 1024M?? No problems on the production server with PHP 5.2.14 though)

Everything as it is configured on my production server.

I remember there are also apache-configs that should match more or less the above settings. I'll have a look there also, but again, I copied also my apache config files from the production site.

And why IS THE uploadlib.php producing errors, no matter if I choose to upload a file or not? I will check also in the file-upload.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Unfortunately file-upload behaves the same. No idea what I could check now.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
I'm still searching for a server with PHP 5.3.8 even if I'm pretty sure that it's something related with your server... but what/where?!? The very first rough suggestion is to lower the PHP error_reporting by excluding notices:

error_reporting = E_ALL & ~E_NOTICE

which is not the solution but it mitigates the issue being a possible workaround.

BTW, I guess your errors appear whenever you submit a Moodle form: the reason of my guessing is within lib/formslib.php::validate_defined_fields() which always call $file_val = $this->_validate_files($files);.

Question 1: did you enable Moodle debugging messages?

Question 2: what about adding 1 line to debug your $_FILES being not empty even when no file has been uploaded?

    function _validate_files(&$files) {
        $files = array();
        print_object($_FILES);
        if (empty($_FILES)) {
            // we do not need to do any checks because no files were submitted
            // note: server side rules do not work for files - use custom verification in validate() instead
            return true;
        }

Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Thanks Matteo, I am just back in the office.

Q1: Yes, on testservers I enable all possible Error-reporting. I will cross-check the PHP error-reporting. I doubt, there was E_ALL on some systems and E_ALL & ~E_NOTICE on some others. But one thing is to report errors and another thing is that Moodle Code breaks there without adding the new post or user which is my case.

Q2: OK, I am willing to track this down further with you, just give me some hours to do it.

Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Here is the output of print_object when I simply edit a latest news post without attaching a file:

Array (
  [attachment] => Array (
        [name] =>
  )
)

Notice: Undefined index: tmp_name in /mymoodle/lib/uploadlib.php on line 171
Notice: Undefined index: error in /mymoodle/lib/uploadlib.php on line 368
Notice: Undefined index: size in /mymoodle/lib/uploadlib.php on line 370
Notice: Undefined index: error in /mymoodle/lib/uploadlib.php on line 110
Notice: Undefined index: error in /mymoodle/lib/formslib.php on line 242

And the same occurs, if I select a file to upload:

Array (
  [attachment] => Array (
        [name] => Curriculum.pdf
  )
)

And still the form is rejected and stalls with the red Moodle-Error: No file was found - are you sure you selected one to upload? and the same PHP-Errors/Notices as above.


In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
at least now we've the proof for your issue. It seems your HTTP POST:

  1. to submit always something related with a file upload even if no file has been submitted, see the empty name key in the array;
  2. to break the file upload due to the missing of the expected keys for a valid PHP file upload. Without (1) I could say that it could be related with a misconfigured upload_tmp_dir (UPLOAD_ERR_NO_TMP_DIR).

Never seen before, (1) sounds something like a filter always adding enctype="multipart/form-data"  to any Moodle form but preventing a real file upload to be finalized by PHP. Lacking of ideas:

Q3: is there any filter in your App Server setup? I'm wondering for something like Suhosin, mod_security, ...
Q4: is this issue related with a given theme?

Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Matteo, could it really be such a banal setting? I left or changed the settings to be equal to those on my production server with PHP 5.2.14:

;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
;upload_tmp_dir = "/tmp"

; Maximum allowed size for uploaded files.
upload_max_filesize = 200M

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20

No temp directory was specified as it says it will use the system's default one... And I thought Moodle would anyway use its own temp directory in moodle/data/1

And specifying /tmp would be anyway the OS' default. But lets try.

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Q3: safe mode is off, as we checked already in phpinfo:

;
; Safe Mode
;
safe_mode = Off

; By default, Safe Mode does a UID compare check when
; opening files. If you want to relax this to a GID compare,
; then turn on safe_mode_gid.
safe_mode_gid = Off

Suhosin settings: nothing is enabled except shosin.mail.protect = 1 but I am seeing that there were a lot more enabled on the production server, like:

; Defines the maximum length of variable names for variables registered through
; the COOKIE. For array variables this is the name in front of the indices.
suhosin.cookie.max_name_length = 256

; Defines the maximum length of the total variable name when registered through
; the COOKIE. For array variables this includes all indices.
suhosin.cookie.max_totalname_length = 256

; Defines the maximum length of variable names for variables registered through
; the URL. For array variables this is the name in front of the indices.
suhosin.get.max_name_length = 256

; Defines the maximum length of the total variable name when registered through
; the URL. For array variables this includes all indices.
suhosin.get.max_totalname_length = 256

; Defines the maximum length of variable names for variables registered through
; a POST request. For array variables this is the name in front of the indices.
suhosin.post.max_name_length = 256

; Defines the maximum length of the total variable name when registered through
; a POST request. For array variables this includes all indices.
suhosin.post.max_totalname_length = 256

; Defines the maximum length of variable names for variables registered through
; the COOKIE, the URL or through a POST request. This is the complete name
; string, including all indicies. This setting is also an upper limit for the
; separate GET, POST, COOKIE configuration directives.
suhosin.request.max_totalname_length = 256

; Defines the maximum name length (excluding possible array indicies) of
; variables that may be registered through the COOKIE, the URL or through a
; POST request. This setting is also an upper limit for the variable origin
; specific configuration directives.
suhosin.request.max_varname_length = 256

So I am trying with these now.

Q4: Theme is standard_white

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Unfortunatelely no avail. So where is the BUG? If you need access to my test server, let me know.

https://moodle.test.fhnw.ch/

I hope it's not rather an apache2 config related to https or http. But again, I copied the settings from the production server. And the certificates are not correct on both test servers affected, but if needed I could produce and sign own ones.

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

But we are very close nevertheless: if I change the line in formslib.php to

if ( ! empty($_FILES)) {

the code continues correctly, but of course, without uploading any files...

And are you sure it's related to the http post and not rather to the function I mentioned at the end of this thread:

 function preprocess_files() {
        global $CFG;

        foreach ($_FILES as $name => $file) {
In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
well, frankly speaking I'm lost in the space so I'd like to start from the basics. I've attached a very simple test case, to be deployed in your server. I've a PHP 5.3.8 powered VM in my laptop at home and this is the output on submitting the form just typing "Test 1":

Linux vm-centos5.scaramuccia.home 2.6.18-308.1.1.el5 #1 SMP Wed Mar 7 04:17:30 EST 2012 i686
PHP version: 5.3.8

Submitted the form by entering this HTTP POSTed name: 'Test 1'

Filename: 'attachment1'
Array
(
[name] =>
[type] =>
[tmp_name] =>
[error] => 4
[size] => 0
)
No file has been provided: go further w/o problems :)

Filename: 'attachment2'
Array
(
[name] =>
[type] =>
[tmp_name] =>
[error] => 4
[size] => 0
)
No file has been provided: go further w/o problems :)

You can play with it: error code 4 is "UPLOAD_ERR_NO_FILE" i.e. no file was upload as expected and Moodle code - both lib/uploadlib.php::preprocess_files() and lib/formslib.php::_validate_files() - manages it correctly. Please play with it: we need to discover the reason why at least error is not provided by your App Server environment,

I'm downloading a plain Moodle 1.9.17+ using git right now...

HTH,
Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Back again: plain Moodle 1.9.17+ (Build: 20120412) installed on a CentOS 5.8 w/ PHP 5.3.8 and w/o Suhosin.
It runs fine as expected: instead of adding a new user I've just updated the password of the administrator to test your scenario (a Moodle form with file upload).

Q5: could you post the whole of the Suhosin configuration? Just the table related output of phpinfo()

Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
no news is good news?

Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

No, no, I just was busy with other things... but today is fine to track this down.

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

There you are...

Sorry, you wanted the phpInfo-output. Here it is:

Additional .ini files parsed /etc/php5/conf.d/bcmath.ini, /etc/php5/conf.d/bz2.ini, /etc/php5/conf.d/calendar.ini, /etc/php5/conf.d/ctype.ini, /etc/php5/conf.d/curl.ini, /etc/php5/conf.d/dba.ini, /etc/php5/conf.d/dom.ini, /etc/php5/conf.d/exif.ini, /etc/php5/conf.d/fileinfo.ini, /etc/php5/conf.d/ftp.ini, /etc/php5/conf.d/gd.ini, /etc/php5/conf.d/gettext.ini, /etc/php5/conf.d/gmp.ini, /etc/php5/conf.d/iconv.ini, /etc/php5/conf.d/intl.ini, /etc/php5/conf.d/json.ini, /etc/php5/conf.d/ldap.ini, /etc/php5/conf.d/mbstring.ini, /etc/php5/conf.d/mcrypt.ini, /etc/php5/conf.d/mysql.ini, /etc/php5/conf.d/mysqli.ini, /etc/php5/conf.d/odbc.ini, /etc/php5/conf.d/openssl.ini, /etc/php5/conf.d/pcntl.ini, /etc/php5/conf.d/pdo.ini, /etc/php5/conf.d/pdo_mysql.ini, /etc/php5/conf.d/pdo_odbc.ini, /etc/php5/conf.d/pdo_pgsql.ini, /etc/php5/conf.d/pgsql.ini, /etc/php5/conf.d/pspell.ini, /etc/php5/conf.d/shmop.ini, /etc/php5/conf.d/snmp.ini, /etc/php5/conf.d/soap.ini, /etc/php5/conf.d/suhosin.ini, /etc/php5/conf.d/sysvmsg.ini, /etc/php5/conf.d/sysvsem.ini, /etc/php5/conf.d/sysvshm.ini, /etc/php5/conf.d/tokenizer.ini, /etc/php5/conf.d/wddx.ini, /etc/php5/conf.d/xmlreader.ini, /etc/php5/conf.d/xmlrpc.ini, /etc/php5/conf.d/xmlwriter.ini, /etc/php5/conf.d/xsl.ini, /etc/php5/conf.d/zip.ini, /etc/php5/conf.d/zlib.ini

 

This server is protected with the Suhosin Extension 0.9.32.1

DirectiveLocal ValueMaster Value
suhosin.apc_bug_workaround Off Off
suhosin.cookie.checkraddr 0 0
suhosin.cookie.cryptdocroot On On
suhosin.cookie.cryptkey [ protected ] [ protected ]
suhosin.cookie.cryptlist no value no value
suhosin.cookie.cryptraddr 0 0
suhosin.cookie.cryptua On On
suhosin.cookie.disallow_nul 1 1
suhosin.cookie.disallow_ws 1 1
suhosin.cookie.encrypt Off Off
suhosin.cookie.max_array_depth 50 50
suhosin.cookie.max_array_index_length 64 64
suhosin.cookie.max_name_length 256 256
suhosin.cookie.max_totalname_length 256 256
suhosin.cookie.max_value_length 10000 10000
suhosin.cookie.max_vars 100 100
suhosin.cookie.plainlist no value no value
suhosin.coredump Off Off
suhosin.disable.display_errors Off Off
suhosin.executor.allow_symlink Off Off
suhosin.executor.disable_emodifier Off Off
suhosin.executor.disable_eval Off Off
suhosin.executor.eval.blacklist no value no value
suhosin.executor.eval.whitelist no value no value
suhosin.executor.func.blacklist no value no value
suhosin.executor.func.whitelist no value no value
suhosin.executor.include.allow_writable_files On On
suhosin.executor.include.blacklist no value no value
suhosin.executor.include.max_traversal 0 0
suhosin.executor.include.whitelist no value no value
suhosin.executor.max_depth 0 0
suhosin.filter.action no value no value
suhosin.get.disallow_nul 1 1
suhosin.get.disallow_ws 0 0
suhosin.get.max_array_depth 50 50
suhosin.get.max_array_index_length 64 64
suhosin.get.max_name_length 256 256
suhosin.get.max_totalname_length 256 256
suhosin.get.max_value_length 512 512
suhosin.get.max_vars 100 100
suhosin.log.file 0 0
suhosin.log.file.name no value no value
suhosin.log.phpscript 0 0
suhosin.log.phpscript.is_safe Off Off
suhosin.log.phpscript.name no value no value
suhosin.log.sapi 0 0
suhosin.log.script 0 0
suhosin.log.script.name no value no value
suhosin.log.syslog no value no value
suhosin.log.syslog.facility no value no value
suhosin.log.syslog.priority no value no value
suhosin.log.use-x-forwarded-for Off Off
suhosin.mail.protect 1 1
suhosin.memory_limit 0 0
suhosin.mt_srand.ignore On On
suhosin.multiheader Off Off
suhosin.perdir 0 0
suhosin.post.disallow_nul 1 1
suhosin.post.disallow_ws 0 0
suhosin.post.max_array_depth 50 50
suhosin.post.max_array_index_length 64 64
suhosin.post.max_name_length 256 256
suhosin.post.max_totalname_length 256 256
suhosin.post.max_value_length 1000000 1000000
suhosin.post.max_vars 1000 1000
suhosin.protectkey On On
suhosin.request.disallow_nul 1 1
suhosin.request.disallow_ws 0 0
suhosin.request.max_array_depth 50 50
suhosin.request.max_array_index_length 64 64
suhosin.request.max_totalname_length 256 256
suhosin.request.max_value_length 1000000 1000000
suhosin.request.max_varname_length 256 256
suhosin.request.max_vars 1000 1000
suhosin.server.encode On On
suhosin.server.strip On On
suhosin.session.checkraddr 0 0
suhosin.session.cryptdocroot On On
suhosin.session.cryptkey [ protected ] [ protected ]
suhosin.session.cryptraddr 0 0
suhosin.session.cryptua Off Off
suhosin.session.encrypt On On
suhosin.session.max_id_length 128 128
suhosin.simulation Off Off
suhosin.sql.bailout_on_error Off Off
suhosin.sql.comment 0 0
suhosin.sql.multiselect 0 0
suhosin.sql.opencomment 0 0
suhosin.sql.union 0 0
suhosin.sql.user_postfix no value no value
suhosin.sql.user_prefix no value no value
suhosin.srand.ignore On On
suhosin.stealth On On
suhosin.upload.disallow_binary 0 0
suhosin.upload.disallow_elf 1 1
suhosin.upload.max_uploads 25 25
suhosin.upload.remove_binary 0 0
suhosin.upload.verification_script no value no value
In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Matteo, sei un genio. Quando vado giù in Sicilia dai miei genitori, mi piacerebbe ringraziarti con un paio di bottiglie di vino (Svizzero, bè sì c'è anche buon vino qui...) oppure vieni a trovarci tu qui in Svizzera, la camera degli ospiti è sempre a disposizione.

But lets first see the output of your test code, without selecting any file to upload:

Linux moodle 3.0.13-0.27-pae #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) i686
PHP version: 5.3.8

Submitted the form by entering this HTTP POSTed name: 'Test Rosario'

Filename: 'attachment1'
Array ( [name] => ) File has been uploaded! :)

Filename: 'attachment2'
Array ( [name] => ) File has been uploaded! :)


Same thing if I select a file:

Linux moodle 3.0.13-0.27-pae #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) i686
PHP version: 5.3.8

Submitted the form by entering this HTTP POSTed name: 'Test Rosario with selected File 1'

Filename: 'attachment1'
Array ( [name] => Curriculum.pdf ) File has been uploaded! :)

Filename: 'attachment2'
Array ( [name] => ) File has been uploaded! :)

Rosario
In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

And if I do a print_r($_FILES) in your script I get:

$_FILES: Array ( 
[attachment1] => Array (
 [name] => Curriculum.pdf )
[attachment2] => Array (
[name] => Kurzportraet.pdf )
 )
In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
thanks, really appreciated... but unfortunately for you I've just given you the possibility to see that the issue must be found in your PHP configuration rather than to be a Moodle code related issue wide eyes.

The main issue here is that your PHP configuration prevents you to have the whole of the given keys in the $_FILES array as expected: see my previous post for details about the expected right response: especially the missing of the error key will give my test code the possibility to wrongly say that everything is fine.

Could you disable Suhosin by commenting out the extension in you php.ini? We need to get closer to the reason why your PHP is acting so bad regarding with file uploading: never seen something like that and I could only suppose something wrong with php.ini OR with extensions OR with the PHP compilation itself (!) OR <__holy mistery__>.

EDIT @14:29 CEST: you're not alone, http://www.spinics.net/lists/php/msg222339.html, libmm seems to be optional (http://www.spinics.net/lists/php/msg222358.html)...

EDIT @14:39: already updated with http://lists.opensuse.org/opensuse-security-announce/2012-04/msg00001.html?

Matteo

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

oh, oh... must be related to my SUSE SP 2 version of PHP 5.3.8, I feared... ok now do I understand correctly that this was already solved with SP 2??

I will try to do the latest online upgrades or use the indicated command

zypper in -t patch slessp2-apache2-mod_php53-5958

And I will try without suhosin and report back.

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Heeeeiiii, we did it!! There was really a whole bunch of patches released only on April 6th after SP 2 was released End of February and me thinking it was the best SP ever seen because it contained PHP 5.3.8 I had been waiting for in the last two years. I downloaded the patches manually because I did not receive them through yasts' online download, and now it works:

Linux moodle 3.0.13-0.27-pae #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) i686
PHP version: 5.3.8
PHP_SELF: /admin/test_file_upload.php
--------------------------------------------------------------------------------
Submitted the form by entering this HTTP POSTed name: 'test'
$_FILES: Array
(
    [attachment1] => Array
        (
            [name] => Curriculum.pdf
            [type] => application/pdf
            [tmp_name] => /tmp/phpxfQng9
            [error] => 0
            [size] => 105823
        )

    [attachment2] => Array
        (
            [name] => Kurzportraet.pdf
            [type] => application/pdf
            [tmp_name] => /tmp/php9eZbf7
            [error] => 0
            [size] => 41218
        )

)
Filename: 'attachment1'Array
(
    [name] => Curriculum.pdf
    [type] => application/pdf
    [tmp_name] => /tmp/phpxfQng9
    [error] => 0
    [size] => 105823
)
File has been uploaded!

smile

Filename: 'attachment2'Array
(
    [name] => Kurzportraet.pdf
    [type] => application/pdf
    [tmp_name] => /tmp/php9eZbf7
    [error] => 0
    [size] => 41218
)
File has been uploaded!

smile

It is mainly apache2-mod_php53-5.3.8-0.23.1 and all related rpms versus 0.19.6

Now I will have to check all other Moodle functionalities, I guess?? before upgrading my production server??

Matteo, how to thank you? You saved me from my last month's frustration. Pleas feel free to contact me by eMail any time you want (rosario.carco[ATourdomain]fhnw.ch

BTW next thing to do for me is to test WEBDAV repositories, so I'll come back to you in the other thread.

Yours, Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Matteo Scaramuccia -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Ciao Rosario,
all's well that ends well, they say cool.
Never used SLES - I'm a RedHat-ish user since 1996 - but every Linux distro has its own skeletons in the closet and sometime you need to fight with them...

BTW your publicly thankfulness has been really appreciated Yes.

Have a nice Moodle 2.2 play,
Matteo

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

AHAaaa, $_FILES is a SUPERGLOBAL of PHP when uploading files... I start to understand that... So it is definitively in the http POST, as you stated...

In reply to Matteo Scaramuccia

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

As I said before, creating a new course works. Only Forms with a file upload field seem to be affected. Tipically posts, users, what else?

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Tim, Matteo, H E L P, the old physical Server is still at 1.9.16+ and behaves exactly the same. I was not aware because I do not really work with them.

So it MUST BE SUSE SLES SP2 or its PHP 5.3.8 causing this. (I have been using SLES 11 SP1 with PHP 5.2.14 for years now without problems)

How could we track this further down? I wanted to upgrade my production server to SP 2 and PHP 5.3.8 to be able to upgrade to Moodle 2.x on a longer term, for example until end of this year.

Without this I am stuck in my migration plans.

Should I post this in the Installation thread or can anyone move this whole thread there? And possibly change the title to something else?

Thanks, Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

I found Tim's advice here:

http://moodle.org/mod/forum/discuss.php?d=192310

to install the php-sources into a fresh clean directory. If I am not mistaken, I did a clean install in 2007 when I installed Moodle 1.7x And since I have been using cvs update -dP to 1.8/1.9 upwards.

And here they say also, that 5.3.8 is a problem, even for 2.x

http://moodle.org/mod/forum/discuss.php?d=193467

So I am really stuck. What a frustration to have PHP 5.3.8 and not being able to run Moodle 1.9.17+

This means I must leave my production server either on 1.9.12+ with PHP 5.2.14 (never touch a running system), unless I might upgrade to 1.9.17+ without breaking anything.

As my Moodle 2.07 Test-Server runs as a parallel instance on the same production server, I was waiting for PHP 5.3.8 to upgrade the whole physical server and to upgrade the Moodle 2.x Server to its latest version.

To test whether 1.9.17+ runs fine with PHP 5.2.14 I will have to downgrade either the virtual machine or my old old physical server.

AND I must investigate first, whether my MoodleDir was containing old files, but I hoped cvs update -dP would do the necessary cleanup. I think I had old 1.9.9+ (Build: 20100713) on both my test-servers where I installed first PHP 5.3.8 before upgrading to 1.9.16 and 1.9.17 in two steps.

Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

I am very sorry and sad, but even a clean fresh install of the 1.9.17+ sources, as adviced by Tim did not help. I get still the same errors and behaviours.

I need your help to track this down, should we open a PHP 5.3.8 tracker issue?

Rosario

In reply to Rosario Carcò

Re: Upgrade to 1.9.17 strftime() and date() Problem

by Rosario Carcò -

Please have a look at this code in uploadlib.php:

    /** 
     * Gets all entries out of $_FILES and stores them locally in $files and then
     * checks each one against {@link get_max_upload_file_size()} and calls {@link cleanfilename()}
     * and scans them for viruses etc.
     * @uses $CFG
     * @uses $_FILES
     * @return boolean
     */
    function preprocess_files() {
        global $CFG;

        foreach ($_FILES as $name => $file) {
 

Could it be there is a global $_FILES missing?? On the production server 1.9.12+ the code is the same and the same version and works fine. So where is the difference?