-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
[Bug]: suspicious_login app dependencies require a 64-bit build of PHP #43157
Comments
Cc @come-nc |
hi, same issue here with a 32bits armbian after the upgrade to 27.1.6 from 27.1.5. ( |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as spam.
This comment was marked as spam.
@bcutter :
Happy system administration 🥳 |
This comment was marked as off-topic.
This comment was marked as off-topic.
Define "special". Expectation is to have the updater doing pre-checks to discover potential dependency or platform issues. But anyway, content of
|
This is my app-list (after update to 27.1.6):
|
That is my app list, also post-update to 27.1.6:
|
The 32bit CI runs look okay. 28.0.2 RC4 https://github.com/nextcloud/server/actions/runs/7645486630/job/20832184863?pr=43095 27.1.6 https://github.com/nextcloud/server/actions/runs/7645492980/job/20832205423?pr=43096 The oauth2 apps does not have any dependencies as per: https://github.com/nextcloud/server/blob/master/apps/oauth2/composer/composer.json |
suspicious_login has darsyn/ip as dependency which requires a 64bit php. |
Yes indeed there were no changes in that app. Absolutely no app got updated (except OAuth2 from 1.5.1 to 1.5.2 for my 27 channel), that's why I suspected this dependency conflict to happen somehwere in core/server itself. I'm a bit tired (and lacking discovery skills due to not available dev glasses) of parsing https://github.com/nextcloud/server/releases/tag/v27.1.6 a 3rd time. Do you spot anything there? |
Was the breaking change introduced by Composer on its own maybe? Looks like https://github.com/composer/composer/releases/tag/2.6.0 This same parameter is how In hindsight, this should have broken installs with that app before. But never would have triggered failures if it wasn't really being enforced by Composer. This would explain why it's never been a problem until now. If we're lucky it's just I think disabling that app (and restarting mod_php/fpm) should be enough to confirm. |
Disabling the suspicious_login app solved the issue for me: |
As well as enabling it in my case raised the issue on my installation:
Disabled again and the issue is gone. |
Maybr the following line should be added to the app as well? Not sure if that actually helps though: https://github.com/nextcloud/news/blob/46cc276cbdecb47d48c28855f0177387d9bf5b3b/appinfo/info.xml#L46 |
At least it prevents the app from being enabled on my 32bit system, so that the issue doesn't arise:
I have no idea whats gonna happen during an upgrade, if the app was enabled prior to the upgrade. |
Summary so far:
For the record:
My inclination is:
What to do about current environments in between, say, v27.1.7 and v28.0.2/v28.0.3?
And what about adjusting the app to support 32-bit?
I believe it'll throw the exception you saw and stop. So in 32-bit environments that have previously enabled this app, manually disabling will be required. I don't see a good way around that unless we want to hard code something in Footnotes[2] I suspect, but have not confirmed that the app will function fine as long as it doesn't encounter an IPv6 connection (useful to know if someone has it installed in a <27.1.6 environment already) [3 Even though the app could theoretically operate in an IPv4 only environments, enabling the app at the moment in 32-bit environments would make it fragile due to the potential to trigger the IPv6 code path [4] I'm hesitant to suggest it would be critical enough since it's a sensitive code path to change at the last minute + easy workaround exists + does not actually impact all 32-bit environments since not enabled by default + shouldn't be all that necessary after we prevent the app from being enabled again going forward Tasks
|
@joshtrichards wow, that's an amazing work. You invested quite some time, really outstanding post and great research work. In two words: thank you. Seems like this is another case where NC apps create issues for core/server:
Back on-topic:
Two cents over, developers the stage is yours. |
Since a dependency (used for IPv6 handling) requires a 64-bit environment, prevent this app from being installed in 32-bit environments in order to avoid Composer's `php-64bit` enforcement from kicking in and triggering nextcloud/server#43157. While `php-64bit` has always been place, Composer only recently started enforcing it in composer/composer#11334 apparently so this wasn't a problem until now. This fix provides a proper preventative measure we can control until when/if this app is okay for 32-bit environments. Signed-off-by: Josh <josh.t.richards@gmail.com>
Fixes nextcloud/server#43157 Signed-off-by: Josh <josh.t.richards@gmail.com>
Fixes app store entry potion of nextcloud/server#43157 Signed-off-by: Josh <josh.t.richards@gmail.com>
@joshtrichards Thank you very much for the excellent summary. We are currently investigating what is required to restore and keep the compatibility of suspicious_login with 32 bit systems. |
Can you give an estimation / brief update on the current status (for those not used to cross-check all linked issues, PRs etc.) please? |
@ChristophWurst could you please elaborate a bit on your action? Was the issue being resolved? |
Read the linked pull request. The 64bit dep has been dropped. |
I see it now, thanks |
Bug description
Upgrading to v28.0.2rc4 on a 32 bit armhf system yields the error
Steps to reproduce
Expected behavior
Nextcloud updates cleanly to v28.0.2rc4
Installation method
None
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Other
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 22.1 to 22.2)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Log entry
Additional info
No response
The text was updated successfully, but these errors were encountered: