#160 Install failing on php 7

Closed
opened 3 years ago by murgero · 14 comments
murgero commented 3 years ago

If I remember correctly, GNU Social had PHP7 issues - is this resolved in the nightly of this project?

If I remember correctly, GNU Social had PHP7 issues - is this resolved in the nightly of this project?
Diogo Cordeiro commented 3 years ago
Owner

It is, we've in fact dropped support for PHP5.6.x. Being 7.0.0 the minimum PHP version for the 1.20.x branch.

For master and nightly it is recommended that you run PHP 7.3+ and MariaDB 10.3+.

Either nginx, apache2 and lighttpd should work fine as webserver with any release. Our changelog is available here: https://notabug.org/diogo/gnu-social/src/nightly/CHANGELOG.md

Please note, about the branches:

  • 1.20.x is the latest release (v1.20.10)
  • master is fairly stable and acceptable to be used in production
  • nightly is force pushed somewhat frequently and is intended for devs
  • experimental is for my own testing

I don't recommend using nightly in production just yet. If you want to, please disable the ActivityPub plugin.

It is, we've in fact dropped support for PHP5.6.x. Being 7.0.0 the minimum PHP version for the 1.20.x branch. For master and nightly it is recommended that you run PHP 7.3+ and MariaDB 10.3+. Either nginx, apache2 and lighttpd should work fine as webserver with any release. Our changelog is available here: https://notabug.org/diogo/gnu-social/src/nightly/CHANGELOG.md Please note, about the branches: - 1.20.x is the latest release (v1.20.10) - master is fairly stable and acceptable to be used in production - nightly is force pushed somewhat frequently and is intended for devs - experimental is for my own testing I don't recommend using nightly in production just yet. If you want to, please disable the ActivityPub plugin.
murgero commented 3 years ago
Poster

Hmm this is strange - I am on php 7.3, but I cannot install due to an "Unknown error"? This is the same on master or nightly, am I just doing something wrong?

Hmm this is strange - I am on php 7.3, but I cannot install due to an "Unknown error"? This is the same on master or nightly, am I just doing something wrong?
Diogo Cordeiro commented 3 years ago
Owner

It's indeed strange, can you add define('DEBUG_INSTALLER', true); right below the one that says <?php, try again and share a screenshot?

Also, which DBMS and WebServer are you running on?

Thanks!

It's indeed strange, can you add `define('DEBUG_INSTALLER', true);` right below the one that says [`<?php`](https://notabug.org/diogo/gnu-social/src/nightly/public/install.php#L1), try again and share a screenshot? Also, which DBMS and WebServer are you running on? Thanks!
murgero commented 3 years ago
Poster

Apache, and MariaDB/MySQL - I think I've seen this issue before, there is a configuration I have to change in MySQL isn't there?

Apache, and MariaDB/MySQL - I think I've seen this issue before, there is a configuration I have to change in MySQL isn't there?
XRevan86 commented 3 years ago
Collaborator

@murgero, for now GNU social needs zero dates, which are by default disabled in Oracle MySQL 8.0+.
So if that's the version you are using, then try adding this to the configuration file:

sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

This is equivalent to the current defaults, except without NO_ZERO_DATE. Everything else is fine.

But maybe it is not the reason for the failure. You can try copying these commands into CLI and observing the error there.

@murgero, for now GNU social needs zero dates, which are by default disabled in Oracle MySQL 8.0+. So if that's the version you are using, then try adding this to the configuration file: ```ini sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION ``` This is equivalent to the current defaults, except without ```NO_ZERO_DATE```. Everything else is fine. But maybe it is not the reason for the failure. You can try copying these commands into CLI and observing the error there.
murgero commented 3 years ago
Poster

Yes! I remember now, I think the NO_ZERO_DATE is the issue - I had a similar problem with a different PHP script about a year ago. Do you happen to know if that configuration can be changed on the fly?

Yes! I remember now, I think the NO_ZERO_DATE is the issue - I had a similar problem with a different PHP script about a year ago. Do you happen to know if that configuration can be changed on the fly?
XRevan86 commented 3 years ago
Collaborator

Do you happen to know if that configuration can be changed on the fly?

Sure, just like that:

SET @@SQL_MODE = REPLACE(@@SQL_MODE, 'NO_ZERO_DATE', '');
> Do you happen to know if that configuration can be changed on the fly? Sure, just like that: ```sql SET @@SQL_MODE = REPLACE(@@SQL_MODE, 'NO_ZERO_DATE', ''); ```
murgero commented 3 years ago
Poster

How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future.

Also, thank you for the snippet!

How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future. Also, thank you for the snippet!
XRevan86 commented 3 years ago
Collaborator

How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future.

Well, the goal is to sort all this timestamp stuff out definitively.
And we don't use that zero date mess on PostgreSQL.

> How hard would it be to streamline this into each query instead? It can be set per session as well and that may help a lot of admins in the future. Well, the goal is to sort all this timestamp stuff out definitively. And we don't use that zero date mess on PostgreSQL.
senooken commented 3 years ago

Hi [@murgero]. My GNU social nightly is running on PHP 7.3 with MySQL and Apache.

I encountered same problem in my past, but no problem now (I forgot details).

So I think this is PHP configuration problem.

If it is possible, please try following debug process.

1 Install xdebug (pecl install xdebug and so on).

2 Add following xdebug configuration in php.ini.

zend_extension = xdebug
xdebug.default_enable = true
xdebug.force_display_errors = 1
xdebug.force_error_reporting = 1
xdebug.collect_params = 4

3 Insert xdebug_print_function_stack('Your own message'); to following on extlib/DB.php.

    function __construct($code = DB_ERROR, $mode = PEAR_ERROR_RETURN,
                         $level = E_USER_NOTICE, $debuginfo = null)
    {
        xdebug_print_function_stack('Your own message');  // Insert here
        if (is_int($code)) {
            parent::__construct('DB Error: ' . DB::errorMessage($code), $code,
                $mode, $level, $debuginfo);
        } else {
            parent::__construct("DB Error: $code", DB_ERROR,
                $mode, $level, $debuginfo);
        }
    }

4 Try to install GNU social again (Unknown error). Detailed debug message will be shown with stack trace.

5 Please report it here.

Hi [@murgero]. [My GNU social nightly](https://social.senooken.jp/senooken) is running on PHP 7.3 with MySQL and Apache. I encountered same problem in my past, but no problem now (I forgot details). So I think this is PHP configuration problem. If it is possible, please try following debug process. 1 Install xdebug (`pecl install xdebug` and so on). 2 Add following xdebug configuration in php.ini. ``` zend_extension = xdebug xdebug.default_enable = true xdebug.force_display_errors = 1 xdebug.force_error_reporting = 1 xdebug.collect_params = 4 ``` 3 Insert `xdebug_print_function_stack('Your own message');` to following on `extlib/DB.php`. ``` function __construct($code = DB_ERROR, $mode = PEAR_ERROR_RETURN, $level = E_USER_NOTICE, $debuginfo = null) { xdebug_print_function_stack('Your own message'); // Insert here if (is_int($code)) { parent::__construct('DB Error: ' . DB::errorMessage($code), $code, $mode, $level, $debuginfo); } else { parent::__construct("DB Error: $code", DB_ERROR, $mode, $level, $debuginfo); } } ``` 4 Try to install GNU social again (`Unknown error`). Detailed debug message will be shown with stack trace. 5 Please report it here.
murgero commented 3 years ago
Poster

How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default.

How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default.
murgero commented 3 years ago
Poster

I moved to use PSQL for this, which is working much better than MySQL - closing for now.

I moved to use PSQL for this, which is working much better than MySQL - closing for now.
XRevan86 commented 3 years ago
Collaborator

Pushed 9a515b9234, which removes the usage of "zero dates" from GNU social for good.
I also want to point out that because of the nature of how we make connections to the database (ephemeral), PostgreSQL is not doing an efficient job. It won't make a noticeable difference for instances that don't receive many connections (or have them capped, like the default 100 simultaneous connections maximum), but generally I'd recommend wrapping it in pgbouncer.

Pushed 9a515b9234eeb2e500e88899fb31f64535b618cc, which removes the usage of "zero dates" from GNU social for good. I also want to point out that because of the nature of how we make connections to the database (ephemeral), PostgreSQL is not doing an efficient job. It won't make a noticeable difference for instances that don't receive many connections (or have them capped, like the default 100 simultaneous connections maximum), but generally I'd recommend wrapping it in *pgbouncer*.
Diogo Cordeiro commented 3 years ago
Owner

How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default.

The only branch with ActivityPub (and TheFreeNetwork module) is nightly. ActivityPub at the moment isn't perfect but works; TheFreeNetwork module isn't ready although making progress.

When you receive an activity via federation with a remote instance, either with OStatus or ActivityPub, the remote actor has to be fetched. That actor is then added to GS's profile table. We are able to tell apart which are remote and which are local due to our user table, and we're able to tell which are from Ostatus and which are from ActivityPub thanks to, respectively, ostatus_profile and activitypub_profile tables.

Hence, TheFreeNetwork module is needed to ensure only one federation protocol is used per remote Actor (i.e. a remote actor either is on ostatus_profile or in activitypub_profile and never in both simultaneously, or worst - and this is what happens at the moment - duplicated in the profile table due to being fetched by both plugins in different moments). Furthermore, ActivityPubPlugin has to support everything OStatus does, otherwise TFNM would be alternating both protocols whenever an only-OStatus-supported activity is received or has to be sent. Neither goal was fully completed yet.

Therefore, if you really want ActivityPub at every cost, you must use nightly with TheFreeNetworkModule and OStatusPlugin disabled. That will lead to an ActivityPub enabled but less-featured GNU social. On the bright side, when we finish both things, you should be able to upgrade with no struggles. Having both ActivityPub and OStatus enabled now will lead to a really ugly database.

My recommendation is to use master (or nightly with both TFNM and ActivityPub disabled) and wait a little bit longer, I know we've been failing every self-proposed ETA, but I think we're finally close of getting this done for once.

> How stable is the ActivityPub code ATM? in any of the branches? I plan on packaging this app for https://cloudron.io and wanted to know if I should disable that by default. The only branch with ActivityPub (and TheFreeNetwork module) is `nightly`. ActivityPub at the moment isn't perfect but works; TheFreeNetwork module isn't ready although making progress. When you receive an activity via federation with a remote instance, either with OStatus or ActivityPub, the remote `actor` has to be fetched. That `actor` is then added to GS's `profile` table. We are able to tell apart which are remote and which are local due to our `user` table, and we're able to tell which are from Ostatus and which are from ActivityPub thanks to, respectively, `ostatus_profile` and `activitypub_profile` tables. Hence, TheFreeNetwork module is needed to ensure only one federation protocol is used per remote Actor (i.e. a remote actor either is on `ostatus_profile` or in `activitypub_profile` and never in both simultaneously, or worst - and this is what happens at the moment - duplicated in the `profile` table due to being fetched by both plugins in different moments). Furthermore, ActivityPubPlugin has to support everything OStatus does, otherwise TFNM would be alternating both protocols whenever an only-OStatus-supported activity is received or has to be sent. Neither goal was fully completed yet. Therefore, if you really want ActivityPub at every cost, you must use `nightly` with `TheFreeNetworkModule` and `OStatusPlugin` disabled. That will lead to an ActivityPub enabled but less-featured GNU social. On the bright side, when we finish both things, you should be able to upgrade with no struggles. Having both ActivityPub and OStatus enabled _now_ will lead to a really ugly database. My recommendation is to **use master** (or nightly with both TFNM and ActivityPub disabled) and **wait a little bit longer**, I know we've been failing every self-proposed ETA, but I think we're finally close of getting this done for once.
Sign in to join this conversation.
No Milestone
No assignee
4 Participants
Loading...
Cancel
Save
There is no content yet.