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.
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 ?
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
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.
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) ?
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 …
@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.
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.
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)
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.
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
(And yet a 64 character-long password is already pretty strong even with just letters )
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.
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?
That’s the idea. But there’s a but
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
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 ).
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 )
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
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.
)
