Describe the bug

Since a few days our ecko installation is working fine for some hours but suddenly loses connection and shows an error screen on the web interface. The issue seems to be related to losing connection to the DNS nameserver (please see logs below) but there is also an issue with redis-server which is unable to save data due to lack of space but there is actually plenty of space on disk (please see redis-server log below).

Context

• Hardware: VPS bought online
• YunoHost version: 11.1.6
• I have access to my server: Through SSH | through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: yes
  • If yes, please explain: Splitting sidekiq queues into different ones and configuring static IP according to this

Logs

ecko-streaming log

ecko-web log

redis-server log after restart

Some diagnosis

I have checked for potential issues by looking at the following:

# sudo service postgresql status
● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2023-02-09 06:25:40 UTC; 23min ago
   Main PID: 1607 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 18703)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/postgresql.service

Feb 09 06:25:40 apps.niboe.info systemd[1]: Starting PostgreSQL RDBMS...
Feb 09 06:25:40 apps.niboe.info systemd[1]: Finished PostgreSQL RDBMS.


# ping google.com
PING google.com(par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e)) 56 data bytes
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=1 ttl=58 time=35.2 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=2 ttl=58 time=35.1 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=3 ttl=58 time=35.2 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=4 ttl=58 time=35.1 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=5 ttl=58 time=35.1 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=6 ttl=58 time=35.1 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=7 ttl=58 time=35.1 ms
64 bytes from par21s22-in-x0e.1e100.net (2a00:1450:4007:819::200e): icmp_seq=8 ttl=58 time=35.2 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7005ms
rtt min/avg/max/mdev = 35.079/35.138/35.221/0.043 ms


# tail syslog
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4]
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4] ActiveRecord::ConnectionNotEstablished (could not connect to server: Connection refused
Feb  9 06:51:09 apps bundle[1639]: #011Is the server running on host "localhost" (127.0.0.1) and accepting
Feb  9 06:51:09 apps bundle[1639]: #011TCP/IP connections on port 5432?
Feb  9 06:51:09 apps bundle[1639]: ):
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4]
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4] app/models/ip_block.rb:31:in `block in blocked?'
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4] app/models/ip_block.rb:31:in `blocked?'
Feb  9 06:51:09 apps bundle[1639]: [1548b7e4-82dc-4706-ab14-bd65090bc9b4] config/initializers/rack_attack.rb:62:in `block in <class:Attack>'
Feb  9 06:51:09 apps bundle[1846]: 2023-02-09T06:51:09.704Z pid=1846 tid=29f2 ERROR: heartbeat: MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.



# status ecko-sidekiq-pull-2.service
● ecko-sidekiq-pull-2.service - ecko-sidekiq-pull-2
     Loaded: loaded (/etc/systemd/system/ecko-sidekiq-pull-2.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-02-09 06:26:03 UTC; 25min ago
   Main PID: 1852 (bundle)
      Tasks: 71 (limit: 18703)
     Memory: 427.8M
        CPU: 2min 17.232s
     CGroup: /system.slice/ecko-sidekiq-pull-2.service
             └─1852 sidekiq 6.4.0 live [0 of 65 busy]

Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/api.rb:783>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/api.rb:776>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/scheduled.>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/scheduled.>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/scheduled.>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/scheduled.>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/scheduled.>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/util.rb:56>
Feb 09 06:51:47 apps.niboe.info bundle[1852]: /var/www/ecko/live/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.4.0/lib/sidekiq/util.rb:65>
Feb 09 06:51:50 apps.niboe.info bundle[1852]: 2023-02-09T06:51:50.094Z pid=1852 tid=6c48 ERROR: heartbeat: MISCONF Redis is configu>


# resolvectl status
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1

Link 2 (eth0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Describe the bug

Cannot update because the size of the media folder is too large and there is no space left for ynh's backup previous to update.

Context

• Hardware: *VPS bought online *
• YunoHost version: 4.3.6.3
• Ecko version: 2022.02.03~ynh1
• I have access to my server: *Through SSH | through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no

Expected behavior

The cron job should be able to remove old media. Otherwise, a way to remove it manually should be available.

Describe the bug

YunoHost App CI reports Ecko as broken. Checked with YunoHost App dev support and they say to look at the full logs, the problem likely being in the ruby commands.

Logs

Job: https://ci-apps.yunohost.org/ci/job/13266
Full logs: https://ci-apps.yunohost.org/ci/logs/ecko_amd64_stable_complete.log

Describe the bug

After ecko app installation, I can create just ordinary user, so I can't manage admin activities such writing policy instance or upload logo instance.

Context

• Hardware: *VPS bought online - Debian 10
• YunoHost version: 4.3.6.2
• I have access to my server: Through SSH | through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no
• If upgrading, current package version: 2022.02.03~ynh1

Steps to reproduce

WebAdmin Home Page --> Application --> search ecko app --> click Install
WebAdmin Home Page --> User --> New User
WebAdmin Home Page --> User --> Manage Groups and permission --> Add permission to all user to mastodon application

NOTE: There is no admin permission to add to groups or to users

Expected behavior

Log in in to the mastodon instance, edit profile and see admin setting

Describe the bug

There's no way to configure the sending of email through the web interface. This still requires manual editing of .env.production which is not as simple as what should be possible on a YunoHost installation.

Context

General admin UX

Steps to reproduce

Install Ecko and wonder why no emails will be sent out

Expected behavior

Email server settings are asked for during instance setup or are possible to configure through Ecko's administrative interface

Logs

n/a

Please see magicstone-dev/ecko#373

Describe the bug

The first installable version 20211126~ynh1 won't be considered eligible for any upgrade using the new and correct versioning scheme (yyyy.mm.dd~ynh1). This was seen on YunoHost version 4.3.4.1.

Describe the bug

SSO doesn't work, as mentioned in the README

Proposed solution

The patch from YunoHost-Apps/mastodon_ynh#294

As the app has potential for upgrades across many versions it's good to use the capability of the CI to test one such upgrade.

#21 (comment)

Describe the bug

It seems there is a bunch of data being accumulated and not deleted by cron jobs as it should be?

Context

• Hardware: VPS bought online
• YunoHost version: 4.3.6.3
• I have access to my server: Through SSH / webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no

Steps to reproduce

ncdu will show you how much disk space is used (10 GB in my case)
df -h shows that folder /dev/sda1 is using 110 GB.
It is not clear where the extra 100 GB come from.

There are only few apps installed, being ecko the largest and most used one.

Expected behavior

HD space used should be less.

Describe the bug

Ecko is installed on YunoHost using Ruby v2.7.2 but according to https://www.ruby-lang.org/en/downloads/ 2.7 will reach end-of-life soon.

Context

This applies to all Ecko installations through YunoHost

Describe the bug

The services ecko-sidekiq and ecko-web are down after a ynh upgrade.

Context

• Hardware: VPS bought online
• YunoHost version: 11.0.9.13
• I have access to my server: Through SSH | through the webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no

Steps to reproduce

The services ecko-sidekiq and ecko-web are failing to start/restart. I have tried via SSH and webadmin, both failing. This is happening since a yunohost upgrade. It seems to be a ruby environment error as I have read in another post. Restarting the VPS did not help either.

Expected behavior

Services should start and run without issues

Logs

Here are the service logs for ecko-sidekiq and ecko-web.

Issue: LDAP users not able to authenticate via OAuth
Ecko version: 3.4.9001

This is a know issue that was fixed on Mastodon back in 2019: mastodon/mastodon#7999

I am not sure why it is affecting ecko_ynh but it should be working since we are using a later version of mastodon after the issue was fixed.

How to reproduce:
Quite a complicated way, but that is how I found it out:

• Install nextcloud on yunohost server.
• Instal nextcloud's mastodon plugin.
• Try authenticating on ecko via nextcloud's plugin using any LDAP account on your server.
• You will get the following error message: {"error":"Host violates local access rules"}

Describe the bug

Configuration files shouldn't be overwritten by upgrade.

Steps to reproduce

1. Have an installation at 20211126~ynh1 and upgrade it with yunohost app upgrade -F ecko.
2. Notice the upgrade process mentions it is overwriting .env.production and saving a backup copy.

Expected behavior

Manually modified configs are not overwritten and if they are it's only after some confirmation.

Bump version script creates versions based on date which are discouraged by the package linter.

Some useful developments have happened since the Ecko commit included in this package so it would be good to update. I believe YunoHost has the ability to update based on tags so this may be the reason driving Ecko to tag a commit periodically.

Describe the bug

There are many warnings that show up during upgrade which are not warnings but simply improperly captured output.

Context

During upgrade of Ecko and probably during installation a series of warnings pops up.

Steps to reproduce

Install or upgrade Ecko on a YunoHost server.

Expected behavior

There should be no warnings unless something is actually out of the ordinary.

Logs

Example semi-scary image during upgrade.