Unable to install Akkoma with "Permission Denied" error

My YunoHost server

Hardware: VPS bought online / OS: Debian 11 (64-bit) / Processor: **2 x 2.6 GHz / Memory: 4096 MB / Storage: 40 GB
YunoHost version: 11.0.10.2 (stable)
I have access to my server : 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: I turned off XMPP and Mail for this domain because Akkoma doesnt require it.

Description of my issue

I tried installing Akkoma from the catalogue, but get an error halfway the script: “/bin/bash: line 1: /var/www/akkoma/live/bin/pleroma_ctl: Permission denied”. After that the install reverts.

The full log is here: https://paste.yunohost.org/raw/oretuninuv

1 Like

Thank you for the detailed bug report.

What is really strange is that running pleroma_ctl executable as akkoma user (yes, pleroma for akkoma, that’s the way it is) gives you a permission denied error, while here in the installation script we give this user full right over that repository…

I don’t get it.
Any more advanced packager here with more clue ? :sweat_smile:

1 Like

Yeah it’s quite weird … maybe this could have something to do with umask or other subtile stuff …

@joeldebruijn : if you’re willing to give us a hand debugging this (we can’t easily reproduce the issue), I would try to :

# Install the app, this will fail but we ask to not autoremove the failed install 
sudo yunohost app install akkoma --no-remove-on-failure

# Then let's look at what are the permissions on the relevant files:
sudo namei -l /var/www/akkoma/live/bin/pleroma_ctl

# And remove the app considering it's just gonna be broken anyway:
sudo yunohost app remove akkoma
2 Likes

By the way, it’s broken anyway, you can’t login… I wasn’t able to debug this already :sweat_smile:

Thanks for helping me out!
Its my first server in a decade and a first Linux one ever. Took me a while to figure out I can use my admin credentials for Yunohost Webadmin also for SSH access.

sudo yunohost app install akkoma --no-remove-on-failure
Error: The installation of akkoma failed, but was not cleaned up as requested by --no-remove-on-failure.
As expected.

sudo namei -l /var/www/akkoma/live/bin/pleroma_ctl
f: /var/www/akkoma/live/bin/pleroma_ctl
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-x— akkoma akkoma akkoma
drwxr-x— akkoma akkoma live
drwxr-x— akkoma akkoma bin
-rwxr-x— akkoma akkoma pleroma_ctl

sudo yunohost app remove akkoma
Info: Removing akkoma…
Info: [+…] > Loading settings…
Info: [#++…] > Stopping and removing the systemd service…
Info: [###++…] > Removing the PostgreSQL database…
Info: [#####+…] > Removing app main directory…
Info: [######++…] > Removing NGINX web server configuration…
Info: [########++…] > Removing dependencies…
Info: [##########+…] > Removing various files…
Info: [###########++…] > Removing the dedicated system user…
Warning: userdel: user ‘akkoma’ does not exist
Warning: /usr/sbin/deluser: /sbin/userdel akkoma' returned error code 6. Exiting. Warning: /usr/sbin/delgroup: akkoma’ still has `akkoma’ as their primary group!
Info: [####################] > Removal of akkoma completed
Success! akkoma uninstalled

I wonder if it was created correctly… could you maybe run the installation command again, then sudo users to list the users, then remove it again (if you want) ?

1 Like

If I run the installation again, without removing and type at the prompt sudo users it mentions “admin” only.

Come to think of it:
I also tried installing Pleroma, Mastodon and Wordpress.
Only the last one succeeded, Pleroma and Mastodon gave also kinds of “permission denied” errors.

@Lapineige @joeldebruijn : ugh now i see what the issue is … apparently Joel created the “akkoma” as a yunohost user and selected it as admin for this app … so it’s an LDAP/YunoHost user but not a regular unix user and this creates funky stuff …

2 Likes

@joeldebruijn : I’m not sure why you thought you had to create an “Akkoma” user in YunoHost … the admin you choose for this app should correspond to an actual human being

This is the feedback I’m looking for because I dont know whats a best practice and what not, so to say. :grin:

I was thinking app-specific admins must not be the Yunohost admin. To scope their capabilities or in the case of an hack and someone gets hold of the credentials, the damage is limited to only that app. So I created users with the same name as the app.

In my WordPress install I assigned a users with an actual name and the install went flawlessly.
All the other ones I named the user according their app. :rofl:

Will try again with ‘normal’ users.

YunoHost already scope stuff, basically a rule of thumb is that you should expect all the boring technical details to be handled by YunoHost automagically, otherwise this is to be considered as a bug (though sometimes some technical stuff are too difficult to automatize)

1 Like

I tried with a normal user, made progress anyway, but error in installation script, albeit something completely different. Went through the logs and saw a user created but the mentioned password was ‘cut off’.
Also at certain special characters it splits the processing of the password string, so it seems.

At 1 I saw it cut off, and 2, 3 and 4 show parts of the password string.

Do I have to enter a simpeler password (instead of 64 characters with ^, $, # etc)?
Forgive me for nagging. :pray:

Yes, even though we recommended using special chars, there are non trivial interaction with bash …

Should we add a check to avoid this ?

There was a bug with the Pleroma App (Akkoma app is based on it), with accents in password I believe… But it was fixed. ping @aris
Maybe this could explain why we can’t logging afterwards…

Anyway, @joeldebruijn maybe try a simpler password and after install reset it to use a better one, and tell me if this works better :slight_smile:
(And yet a 64 character-long password is already pretty strong even with just letters :wink: )

1 Like

Yes we should probably

The bug is still present I think…

1 Like

Yes, thnx everybody!

So there were 2 flaws in my setup:

  • Naming a Yunohost user the same as the application which complicate things with users at the OS level, with the same name.
  • Using passwords with special characters like %, $ and ^ which causes bash to do other things than processing the entire string.

Reflecting on my personal understanding:

  • On a conceptual level I placed Yunohost somewhere between the OS and application ‘layer’. But Yunohost is ‘just’ an application like any other, albeit a very handy one to configure a multi-purpose host.
  • I thought Yunohost was ‘special’, meaning a user in Yunohost isnt ‘just’ a user in the appllication but also a OS user.
  • I also expected to only need to see the CLI for setting up, Yunohost. And to not need it ever again. Maybe better to not be afraid of it. :sunglasses:

Having little experience with Linux and stopped doing my own webservers 10 years ago on WAMP I am a bit cautious. In the past I felt I couldnt keep up with the needed security expertise so I stopped. With Yunohost I see a new chance to have my own server once again.

Last question:
Does Yunohost take care of Debian upgrades/updates as well or do I have to maintain that as well, outside YunoHost?

1 Like

That’s the idea. But there’s a but :slight_smile:
In that case we might say that is an use case that was not anticipated by Yunohost contributors/devs, hence the issue. But you could have waited for it to be resolved (with the command line stuff) by others, it would just have taken much more time :wink:
And anyway it will automate a lot of things for you - yeah, that’s security part too, even if it won’t do everything for you (good passwords, that kind of stuff :slight_smile: ).

Also it’s a work in progress app in fact, as I did not solve all the installation issues. (Yes, it’s marked as working, I was a bit hasty :sweat_smile:)
Or rather, the app in the sense of a Yunohost app is working (install/remove/backup/restore/upgrade), it’s just that… apparently you can’t login :laughing:

It does in its way. Via the administration panel you can do normal upgrades (and with the app unattended upgrades it can also do it automatically for you), and regarding Debian major version upgrades, it does but with this own timing as the tools need to be adapted. Then a migration process is available.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.