yunohost-apps / akkoma_ynh Goto Github PK

This vulnerability was discovered today.

Default created account, even after password reset, as well as newly created account can't login.
I don't understand what's going on.

Also password reset from the UI is disabled (it works from CLI, but the generated link is never sent by email).

Maybe can we begin to test an upgrade to the new stable version of Akkoma
https://meta.akkoma.dev/t/akkoma-stable-2023-02-lies-verifies-and-statistics/356

After upgrading to v3.9.3 everything located at 'sub.domain.tld/media' is returning a 404 error.

I tested removing different lines from the nginx config for my instance and restarting the nginx service.

The issue seems to be directly tied to the new 'location ~ ^/media' in the nginx config.

Media always returned a 404 as long as this location matched regardless of what was in the body of the block. Even if it was empty.

Removing the location block entirely made media viewable. But this nullifies the CSP rules for the patch which is obviously not ideal.

Says akkoma package is broken

I am on YunoHost 11.1.20 (stable).

In Admin FE these tow config parameters are wrong:

Path to Upload directory

Path to Modules

/var/lib/akkoma/ must be replaced with /home/yunohost.app/akkoma/

I created a /static/static folder to be able to upload themes and the TOS file, but it wasn't being read by the front end. I noticed all the other folders are owned by the akkoma user, but I was logged into sftp with my user account so the folder I created was owned by me. I was able to assign read/write access to the akkoma user in the terminal and it's working fine now, but wanted to report it in case it's something that can be addressed to prevent manual intervention for others going forward.

At login:

Request failed with status code 500 - [object Object]

If I want to install a frontend (SB):

Request failed with status code 500 - [object Object]

Installed Fedibird FE but no way to activate...

I currently have an installation running Pleroma, and I actually managed to upgrade in-place to Akkoma, but don't know how to migrate the Pleroma database to Akkoma without losing my messages.

After updating to 2023.08 / 3.10.3, uploading images or audio attachments for posts fail with no obvious error messages when using the default pleroma-fe frontend. Using the Mangane frontend, a brief "internal server error" pops up when trying to add an attachment. The logs spit this out whenever I try to upload anything -

Aug 14 11:08:24 pleroma[1363]: 11:08:24.562 request_id=F3sakzTT8RPkDgkAAcTS [error] Internal server error: {:noproc, {:gen_statem, :call, [#PID<0.6558.5>, {:perform, "/tmp/plug-1691/multipart-1691975304-529962328-2"}, 30000]}}
Aug 14 11:08:24 pleroma[16214]: /var/www/akkoma/live/lib/majic-1.0.0/priv/libmagic_port: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /var/www/akkoma/live/lib/majic-1.0.0/priv/libmagic_port)
Aug 14 11:08:24 pleroma[1363]: 11:08:24.562 [error] #PID<0.8363.5> running Pleroma.Web.Endpoint (connection #PID<0.8362.5>, stream id 1) terminated
.......
Aug 14 11:08:24 pleroma[1363]: Request: POST /api/v1/media
Aug 14 11:08:24 pleroma[1363]: ** (exit) exited in: :gen_statem.call(#PID<0.6558.5>, {:perform, "/tmp/plug-1691/multipart-1691975304-529962328-2"}, 30000)
Aug 14 11:08:24 pleroma[1363]:     ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started

I upgraded to Akkoma 3.9.3 via the Yunohost console. Now all local images are missing from my Akkoma instance.

I can see the images are present under /home/yunohost.app/akkoma/upload, but I am getting a 404 in the browser.

Problem: After registering a non-YunoHost/LDAP Akkoma account, signing in throws a "Invalid Credentials" error.

Solution: Go to the Admin FE > Settings > Authentication > LDAP > Toggle off "Enabled".

Note: Signing in with the original LDAP connected admin account is not affected by disabling LDAP, and works as normal.

Logs here:

https://paste.yunohost.org/raw/nihawuyuna

Hi there

On YunoHost on raspberry pi 400 The installation of akkoma is failing

here is the complete log

https://paste.yunohost.org/raw/wegikofuje

My guess is ARM64 doesn't work with it, am I mistaking ? Thanks !

Hi, I recently tried installing Akkoma with YunoHost but ran into a crash. I can't guarantee it's not caused by something I did, but figured I'd share the crash report: https://paste.yunohost.org/raw/pilitehiti

My YunoHost is currently up to date as of 2/11/24 and it's an x86_64 installation running as a VM under QEMU.

Thanks

Contrary to Pleroma, Akkoma seems not to provide an URL with a dedicated version number/commit.
This means the version provided behind the URL will change after each (stable) release.

This is a trouble for Yunohost app packaging.
How do we manage it ?

Right now this means the sha2565sum will fails, and (hopefully) the installation process will stop instead of installing a newer version that might require manual intervention.
Hence, until we upgrade the package, installs will no longer be possible.

Hardware: VPS bought online ( Contabo )
YunoHost version: 11.1.6.2 (stable)
I have access to my server : Through SSH and browser
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

as per title, every time i try to install akkoma], it fails.

this is the excerpt from the log:

2023-02-11 23:50:55,805: DEBUG - ++ echo zip
2023-02-11 23:50:55,805: DEBUG - ++ tr '[:upper:]' '[:lower:]'
2023-02-11 23:50:55,806: DEBUG - + src_format=zip
2023-02-11 23:50:55,807: DEBUG - + src_extract=true
2023-02-11 23:50:55,807: DEBUG - + '[' '' = '' ']'
2023-02-11 23:50:55,807: DEBUG - + src_filename=amd64.zip
2023-02-11 23:50:55,807: DEBUG - + local local_src=/opt/yunohost-apps-src/akkoma/amd64.zip
2023-02-11 23:50:55,807: DEBUG - + mkdir -p /var/cache/yunohost/download/akkoma/
2023-02-11 23:50:55,811: DEBUG - + src_filename=/var/cache/yunohost/download/akkoma/amd64.zip
2023-02-11 23:50:55,812: DEBUG - + '[' zip = docker ']'
2023-02-11 23:50:55,812: DEBUG - + test -e /opt/yunohost-apps-src/akkoma/amd64.zip
2023-02-11 23:50:55,812: DEBUG - + '[' -n https://akkoma-updates.s3-website.fr-par.scw.cloud/stable/akkoma-amd64.zip ']'
2023-02-11 23:50:55,812: DEBUG - ++ wget --tries 3 --no-dns-cache --timeout 900 --no-verbose --output-document=/var/cache/yunohost/download/akkoma/amd64.zip https://akkoma-updates.s3-website.fr-par.scw.cloud/stable/akkoma-amd64.zip
2023-02-11 23:51:01,083: DEBUG - + out='2023-02-11 23:51:01 URL:https://akkoma-updates.s3-website.fr-par.scw.cloud/stable/akkoma-amd64.zip [20306315/20306315] -> "/var/cache/yunohost/download/akkoma/amd64.zip" [1]'
2023-02-11 23:51:01,084: DEBUG - + sha256sum --check --status
2023-02-11 23:51:01,266: DEBUG - ++ sha256sum /var/cache/yunohost/download/akkoma/amd64.zip
2023-02-11 23:51:01,267: DEBUG - ++ cut '--delimiter= ' --fields=1
2023-02-11 23:51:01,385: DEBUG - ++ du -hs /var/cache/yunohost/download/akkoma/amd64.zip
2023-02-11 23:51:01,387: DEBUG - ++ cut '--delimiter= ' --fields=1
2023-02-11 23:51:01,410: DEBUG - + ynh_die '--message=Corrupt source for /var/cache/yunohost/download/akkoma/amd64.zip: Expected c892ad17914690185196c75a728f94b639f53e00c42a194e60242fbea09e7320 but got a00b3533b39b9e6c0a72ffa94c583e1c23946ee22157254a514e9fd3c4fbb95e (size: 20M	/var/cache/yunohost/download/akkoma/amd64.zip).'
2023-02-11 23:51:01,453: DEBUG - + ynh_exit_properly
2023-02-11 23:51:01,454: WARNING - Corrupt source for /var/cache/yunohost/download/akkoma/amd64.zip: Expected c892ad17914690185196c75a728f94b639f53e00c42a194e60242fbea09e7320 but got a00b3533b39b9e6c0a72ffa94c583e1c23946ee22157254a514e9fd3c4fbb95e (size: 20M	/var/cache/yunohost/download/akkoma/amd64.zip).
2023-02-11 23:51:01,987: DEBUG - + ynh_clean_setup
2023-02-11 23:51:01,987: DEBUG - + true
2023-02-11 23:51:02,995: ERROR - Unable to install akkoma: An error occurred inside the app installation script

while here you can find the full log.

in the forum, someone suggested:

It sounds like indeed the upstream checksum changed >_> So somebody should investigate if this is expected and update the app accordingly 😐

is that the case?

Problem:

When we upgrade Akkoma the configuration is reset to default: in fact we loose all custom parameters defined directly in Admin FE. Included the choice of a custom frontend.

This is in fact a dirty side effect of running migrate_to_db at every upgrade.

Solution:

Exec migrate_to_db only at install and not at upgrade.

When changing the instances logo and thumbnail via AdminFE nothing seems to change. Any ideas what causes this and how they can be changed? I've tried to change logo via Soapbox also and it doesn't work either.

I managed to install Akkoma with Yunohost, inlog and posting works fine.
But upon entering the administrative backend (https://my-domain.tld/pleroma/admin/#/users/index) I get this error:

"Request failed with status code 400 - You must enable configurable_from_database in your config file."

I will look for a solution with Akkoma support also, but was wondering if its a flaw in the install script.

If you uninstall Akkoma, the static directory (/home/yunohost.app/akkoma/static/) is not removed or archived by the uninstall script of YNH...

This can be a problem in case of later installation of a new or clean instance of Akkoma for a new project for example.

The good idea can be to make a backup somewhere, as the static/ directory contain all the custom assets and files of the removed instance.