New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inability to automate/pre-configure user.ini prior to Owncloud's "1st run end-user setup" #25773

Closed
Fourdee opened this Issue Aug 11, 2016 · 13 comments

Comments

Projects
None yet
5 participants
@Fourdee

Fourdee commented Aug 11, 2016

Fourdee/DietPi#468 (comment)

Steps to reproduce

  1. Install Owncloud and run sed -i "/upload_max_filesize=/c\upload_max_filesize=2048M" /var/www/owncloud/.user.ini prior to 1st run web end user setup.
    Fourdee/DietPi@e5b1950

Expected behaviour

Allow for changes to this file, prior to 1st run end user setup, so it can be automated and pre-configured.

Actual behaviour

[INVALID_HASH] => Array [.user.ini] => Array

Server configuration

Operating system:
Debian 8

Web server:
Lighttpd

Database:
MySQL

PHP version:
5.6.24

ownCloud version: (see ownCloud admin page)
9.1.0

Updated from an older ownCloud or fresh install:
No

Where did you install ownCloud from:
http://download.owncloud.org/download/repositories/stable/Debian_8.0

Signing status (ownCloud 9.0 and above):

Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [.user.ini] => Array
                        (
                            [expected] => 0a557e3cdca4c2e3675deed761d79d109011dcdebbd9c7f6429f1d3476938ec95729543d7384651d1d0c48e26c5024cc5f517445920915a704ea748bdb903c5f
                            [current] => 9356992f77ce50f997578814e797de8f88124e83ef10ca2eee2144bef0c6aa55ae46505038cf0c4255ef00649a7f2e9086c01852d81a2a5fddf504edd29d1f1e
                        )

                )

        )

)

List of activated apps:
Default

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
No

Client configuration

Chrome

Operating system:
Win 10

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 11, 2016

Why not configure it in the global php.ini if you have access to the base system?

ghost commented Aug 11, 2016

Why not configure it in the global php.ini if you have access to the base system?

@Fourdee

This comment has been minimized.

Show comment
Hide comment
@Fourdee

Fourdee Aug 12, 2016

@RealRancor

I was simply following the Owncloud installation documentation. This does not mention that changing the .user.ini will cause a integrity failure, when set prior to 1st run web interface wizard setup.

https://doc.owncloud.org/server/9.1/admin_manual/installation/source_installation.html#php-fpm-configuration-notes

.htaccess notes for Apache
ownCloud comes with its own owncloud/.htaccess file. Because php-fpm can’t read PHP settings in .htaccess these settings and permissions must be set in the owncloud/.user.ini file.

Fourdee commented Aug 12, 2016

@RealRancor

I was simply following the Owncloud installation documentation. This does not mention that changing the .user.ini will cause a integrity failure, when set prior to 1st run web interface wizard setup.

https://doc.owncloud.org/server/9.1/admin_manual/installation/source_installation.html#php-fpm-configuration-notes

.htaccess notes for Apache
ownCloud comes with its own owncloud/.htaccess file. Because php-fpm can’t read PHP settings in .htaccess these settings and permissions must be set in the owncloud/.user.ini file.

@Fourdee

This comment has been minimized.

Show comment
Hide comment
@Fourdee

Fourdee Aug 12, 2016

@RealRancor

Why not configure it in the global php.ini if you have access to the base system?

We already apply upload_max_filesize = 2G and post_max_size = 2G to know php.ini files during installation. Has no effect on Owncloud, unless its set specifically in .user.ini.

root@DietPi:~# find / -type f -name php.ini
/etc/php5/cli/php.ini
/etc/php5/cgi/php.ini
/etc/php5/fpm/php.ini

image

Fourdee commented Aug 12, 2016

@RealRancor

Why not configure it in the global php.ini if you have access to the base system?

We already apply upload_max_filesize = 2G and post_max_size = 2G to know php.ini files during installation. Has no effect on Owncloud, unless its set specifically in .user.ini.

root@DietPi:~# find / -type f -name php.ini
/etc/php5/cli/php.ini
/etc/php5/cgi/php.ini
/etc/php5/fpm/php.ini

image

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 12, 2016

@Fourdee Well, thats probably something for https://central.owncloud.org/ i guess as the phpinfo.php is showing the correct values and oC is just using those.

The integrity check itself probably was never designed to allow to edit the .htaccess and .user.ini before the setup. This needs another implementation / complexity for a single one-shot task which can be done after the installation by the user.

ghost commented Aug 12, 2016

@Fourdee Well, thats probably something for https://central.owncloud.org/ i guess as the phpinfo.php is showing the correct values and oC is just using those.

The integrity check itself probably was never designed to allow to edit the .htaccess and .user.ini before the setup. This needs another implementation / complexity for a single one-shot task which can be done after the installation by the user.

@Fourdee

This comment has been minimized.

Show comment
Hide comment
@Fourdee

Fourdee Aug 12, 2016

@RealRancor

i guess as the phpinfo.php is showing the correct values and oC is just using those.

Just to clarify, oC is NOT using those values. It still limits upload size to 513MB, regardless of what phpinfo.php is displaying, and what we set in all known php.ini files:
image
image

The integrity check itself probably was never designed to allow to edit the .htaccess and .user.ini before the setup. This needs another implementation / complexity for a single one-shot task which can be done after the installation by the user.

Yep, although not ideal solution for us (we like to simplify as much as possible for the user), seems the only way to keep oC "happy" 👍

Fourdee commented Aug 12, 2016

@RealRancor

i guess as the phpinfo.php is showing the correct values and oC is just using those.

Just to clarify, oC is NOT using those values. It still limits upload size to 513MB, regardless of what phpinfo.php is displaying, and what we set in all known php.ini files:
image
image

The integrity check itself probably was never designed to allow to edit the .htaccess and .user.ini before the setup. This needs another implementation / complexity for a single one-shot task which can be done after the installation by the user.

Yep, although not ideal solution for us (we like to simplify as much as possible for the user), seems the only way to keep oC "happy" 👍

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 12, 2016

I'm still suggesting to use central.owncloud.org for such configuration issues. oC is using the lowest value of both for the upload limit. If you're getting the yellow banner it means those are not correctly passed to oC by your webserver / php environment.

ghost commented Aug 12, 2016

I'm still suggesting to use central.owncloud.org for such configuration issues. oC is using the lowest value of both for the upload limit. If you're getting the yellow banner it means those are not correctly passed to oC by your webserver / php environment.

@Fourdee

This comment has been minimized.

Show comment
Hide comment
@Fourdee

Fourdee Aug 12, 2016

@RealRancor

I'm still suggesting to use central.owncloud.org for such configuration issues.

I'd personally consider:

  • oC ignoring current system php upload size values.
  • oC only acknowledges its own .user.ini for php upload sizes.
  • Inability to change .user.ini prior to 1st run setup, without causing a non-removable integrity failure.

Borderline bug, or at the very least, an area that really needs improvement.

Fourdee commented Aug 12, 2016

@RealRancor

I'm still suggesting to use central.owncloud.org for such configuration issues.

I'd personally consider:

  • oC ignoring current system php upload size values.
  • oC only acknowledges its own .user.ini for php upload sizes.
  • Inability to change .user.ini prior to 1st run setup, without causing a non-removable integrity failure.

Borderline bug, or at the very least, an area that really needs improvement.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 12, 2016

Hi,

points 1 and 2 are not not the case from my years of experience with oC. Every issue i had faced in the past (trust me there where tons) with upload limits where wrong configured settings on user side (either picked the wrong file, placed the phpinfo.php into the wrong place to check the current values and similar)

ghost commented Aug 12, 2016

Hi,

points 1 and 2 are not not the case from my years of experience with oC. Every issue i had faced in the past (trust me there where tons) with upload limits where wrong configured settings on user side (either picked the wrong file, placed the phpinfo.php into the wrong place to check the current values and similar)

@Fourdee

This comment has been minimized.

Show comment
Hide comment
@Fourdee

Fourdee Aug 12, 2016

points 1 and 2 are not not the case from my years of experience with oC. Every issue i had faced in the past (trust me there where tons) with upload limits where wrong configured settings on user side (either picked the wrong file, placed the phpinfo.php into the wrong place to check the current values and similar)

Looks like oC is overriding the local php settings (and therefore the global master settings in php.ini) to what ever the value is in .user.ini

So no matter what value I set in php.ini, only the .user.ini value is active.
image

Fourdee commented Aug 12, 2016

points 1 and 2 are not not the case from my years of experience with oC. Every issue i had faced in the past (trust me there where tons) with upload limits where wrong configured settings on user side (either picked the wrong file, placed the phpinfo.php into the wrong place to check the current values and similar)

Looks like oC is overriding the local php settings (and therefore the global master settings in php.ini) to what ever the value is in .user.ini

So no matter what value I set in php.ini, only the .user.ini value is active.
image

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 12, 2016

Ahh, yes. That makes sense. So we're at the beginning with the integrity issue if the .user.ini is edited before the installation.

ghost commented Aug 12, 2016

Ahh, yes. That makes sense. So we're at the beginning with the integrity issue if the .user.ini is edited before the installation.

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Jan 31, 2017

Contributor

Groan. I just upgraded ownCloud to 9.1 with my Docker image where I remove .user.ini so that global PHP settings apply and of course I triggered integrity error. Can that file simply not be integrity protected?

Contributor

mitar commented Jan 31, 2017

Groan. I just upgraded ownCloud to 9.1 with my Docker image where I remove .user.ini so that global PHP settings apply and of course I triggered integrity error. Can that file simply not be integrity protected?

@MichaIng

This comment has been minimized.

Show comment
Hide comment
@MichaIng

MichaIng Oct 13, 2017

€: Huuuh, just realized that I am on owncloud github and not on dietpi anymore. Anyway, occ installation should be the solution for this, thus issue can be closed after testing. Sorry for other unrelated spam here 😆.

@Fourdee
Same as for Nextcloud you could kinda do the first run setup by occ command: https://doc.owncloud.org/server/latest/admin_manual/configuration/server/occ_command.html#command-line-installation
After that integrity checks should not occur until next nextcloud update or by manual occ execution. But as these checks can be done any time and the integrity check errors stay on admin panel until resolved, I think it is not a good idea to change whether .user.ini nor .htaccess. Also those files get overwritten on e.g. occ maintenance:update:htaccess if you want to enable pretty URLs without /index.php/ inside.

As every user can change the maximal upload size from within ownCloud (and Nextcloud) admin settings, I guess it is okay that it starts at 512M.


If you're anyway going to update that part of ownCloud installation: The occ installation should also produce the config.php, thus allows configuration of APCu afterwards.


About memory_limit:
All these settings are by the way for apache set in .htaccess, while .user.ini should just be valid for other webservers, php-fpm, php-cgi etc.
memory_limit is automatically adjusted together with upload_max_filesize (and post_max_size), so will be overwritten whenever the admin changes max upload size in ownCloud/Nextcloud admin panel. There it is limited to 2G.
I don't know how this is handled: Does it mean that, if you allow uploading files of up to 2G and you upload such a file, 2G of RAM will be used?? This would be indeed a problem and worth an issue/report on their github pages. If this is really the case, maybe we should find a way to somehow force PHP/webserver to use a temp hard drive location for large file, at least for systems that have not significantly more than 2G of RAM.
Maybe just setting memory_limit to a lower value, as you already do now, resolved it already? Or does it lead to problems while large file upload? Worth trying.

MichaIng commented Oct 13, 2017

€: Huuuh, just realized that I am on owncloud github and not on dietpi anymore. Anyway, occ installation should be the solution for this, thus issue can be closed after testing. Sorry for other unrelated spam here 😆.

@Fourdee
Same as for Nextcloud you could kinda do the first run setup by occ command: https://doc.owncloud.org/server/latest/admin_manual/configuration/server/occ_command.html#command-line-installation
After that integrity checks should not occur until next nextcloud update or by manual occ execution. But as these checks can be done any time and the integrity check errors stay on admin panel until resolved, I think it is not a good idea to change whether .user.ini nor .htaccess. Also those files get overwritten on e.g. occ maintenance:update:htaccess if you want to enable pretty URLs without /index.php/ inside.

As every user can change the maximal upload size from within ownCloud (and Nextcloud) admin settings, I guess it is okay that it starts at 512M.


If you're anyway going to update that part of ownCloud installation: The occ installation should also produce the config.php, thus allows configuration of APCu afterwards.


About memory_limit:
All these settings are by the way for apache set in .htaccess, while .user.ini should just be valid for other webservers, php-fpm, php-cgi etc.
memory_limit is automatically adjusted together with upload_max_filesize (and post_max_size), so will be overwritten whenever the admin changes max upload size in ownCloud/Nextcloud admin panel. There it is limited to 2G.
I don't know how this is handled: Does it mean that, if you allow uploading files of up to 2G and you upload such a file, 2G of RAM will be used?? This would be indeed a problem and worth an issue/report on their github pages. If this is really the case, maybe we should find a way to somehow force PHP/webserver to use a temp hard drive location for large file, at least for systems that have not significantly more than 2G of RAM.
Maybe just setting memory_limit to a lower value, as you already do now, resolved it already? Or does it lead to problems while large file upload? Worth trying.

@ownclouders

This comment has been minimized.

Show comment
Hide comment
@ownclouders

ownclouders Dec 21, 2017

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.

ownclouders commented Dec 21, 2017

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment