Yunohost is a bleeding mess of file permissions and locations

Discuss
1

Pardon the title, I need to vent. I installed my first public facing app, and I am ready to format my system and never touch Yunohost again.

I’ve used YNH on my server for almost a month now. From the outset I setup a few apps that are just meant to sit in the background and do their thing: Radarr, Sonarr, Transmission are just for me and my household and for what they are they work. I’ve been SSHing in and transferring files with SFTP, no problem. Then I started tinkering with a public facing website, and here my frustrations began.

I installed the unofficial microblog.pub app to try out a self-hosted ActivityPub site. I’ve been setting up websites for decades, ranging from CMSes to plain HTML/CSS - I even managed to maintain a Nextcloud instance for eight years - but the shared hosting I’ve used prohibited command line access so YNH opens new opportunities for me. In theory, that is, because when I set up a new site, the first thing I do is crack open the CSS and config files to customise it.

At this time there are no detailed YNH web admin configurations for Microblog.pub, but it is a fairly simple setup with straightforward configuration instructions: Open and edit a TOML file, save, restart. Cool, I assumed all of the files needed should be in /var/www/. Rather than dig around with SSH I opened Filezilla to edit them with SFTP, but… my admin account doesn’t have access to /var/www/ ? Wouldn’t it be intuitive that a web admin should have access to that folder?

So I enter the folder as root with SSH, and there is nothing there but the standard NGINX HTML file. Okay, I may not be used to the inner workings of a web server, but I’ve run Debian for several years, so I dig around the usual locations to find where the app is actually installed. There is no sign in either my user’s or the yunohost-app ~/ folders. In fact, out of the six YNH apps I have installed, only two have subdirectories in ~/yunohost-app/. Transmission is its own user with a separate home directory; the three others are nowhere to be seen.

No sign of Microblog.pub in /usr/share, /usr/local/, /etc/default, either. /etc/yunohost/ looks salient, but I don’t have access. The microblog.pub-ynh uninstall instructions give a hint that at least some app profile information should be in /opt/yunohost/microblogpub/. But my “admin” account is denied access.

At this point I begin to suspect something is wrong with the YNH user permissions. If this were a plain Debian system I would consult the support pages. The same approach with YNH leads me to a page that says In YunoHost permission management web admin interface, you can specify which user can access your system through SFTP. No further instructions given, but I still manage to find the user permission settings interface. The only user that I can add SFTP to is my admin account, so that’s what I do. I reconnect with Filezilla, and where I could access the entire file system before, now I can only read the /home directory.

So granting permissions to my account in the web admin UI actually limited my access. What the hell? Back in that permissions interface, app permissions for Micropub.blog are already granted to all users, so I get error messages when I try to explicitly grant them to individual accounts. Now, I still want to believe that Yunohost has some semblance of logic despite the absolute state of the documentation and irrational permissions policies, and despite the fact that app files are tucked away in corners of my system that I’m apparently not allowed to access.

The YNH documentation also gives an example of granting SFTP edit permissions using CLI, but this includes binding a /var/www/ subdirectory to one in ~/apps/ … Once again, there are no directories whatsoever in my /var/www/.

Let me remind you that through all of this all I needed was to edit a config file and customise some CSS! It is only with an SSH search as root for any TOML files that I realise that yes, the files I need are really in /opt/yunohost/microblogpub/microblogpub/ (great nesting of identically named directories, there!) and /etc/yunohost/microblogpub/ … ie, directories that I - a flipping admin - cannot access in a visual way through SFTP, and need root to access in SSH.

In other words, Yunohost makes it really easy to set up server software that I couldn’t install on my previous shared hosting, but with the density of user permissions and labyrinthine file locations makes it almost impossible to perform simple tasks like editing a CSS file. It did occur to the developers that people want to also tinker with the web apps we install?

Before installing YNH I quite happily hosted Transmission and a few media NFS shares on my home network using bare Debian. YNH does set up a firewall and NGINX for you, but the overbearing handholding past that point is utterly frustrating. I find myself spending more time accommodating to the restrictions and forced workflows of YNH than I do actually using the apps I install. After spending a day trying to find files that should have been up front and accessible to me, the person who installed them, I can’t say that the benefits of Yunohost outweigh the complete black box that it has made of my system.

Hardware: Old laptop or computer
YunoHost version: 5.10.0-23-amd64
I have access to my server : Through SSH | through the webadmin | direct access via keyboard / screen | Through SFTP
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

4 Likes
2

It would have made sens to complain about an application that is part of the official catalog… For microblog.pub path issue, you should be complaining to the microblog.pub app upstream maintainer.
We tend to discourage the use of /opt/yunohost/$app for Web applications (var/www/$app is to be used ).

5 Likes
3

What you are reporting is more an individual (but not that uncommon) packaging issue for a specific app than a Yunohost issue: Yunohost packaging guidelines are here to keep things consistent, but then it relies on 1) each packaged app specific setup and easy to adapt to Yunohost situation/guidelines 2) benevolent efforts to adapt it to such guidelines. And here we have a 3rd point : 3) benevolent efforts to document the specific steps to configure an app (here it’s an advanced use case so I would understand it wasn’t a priority, yet it’s a legitimate customization).
That is the drawbacks that comes with a (benevolent) community-run packaging system, with various packaging quality and so on.

Here it sounds like this package would benefit from some improvements on these points (if you are willing to report them, go ahead :slight_smile: ), to hopefully allow future users to have an easier time than what you experienced :confused:

3 Likes
4

Yeah, I knew it would be low hanging fruit to use an unofficial app for an example. Let’s talk Transmission then, from the catalog. Its RPC is currently so crippled that every time I change an app or domain setting, the SSO file is borked and I have to manually re-add the RPC setting to the config.

Let’s talk about the web admin where you cannot add Let’s Encrypt certs to a new domain without first running diagnostics. If that were a feature it would be implemented on the same page.

And both you kind apologists fail to address the permissions fuckery that makes SFTP access to one’s own server useless. It’s shit like that that just doesn’t work, and that, my friends, is the answer to “DUUD Y U NO HOST”

5

Congrats!, you have reached the first level of self-hosting

  • Frustration :white_check_mark:
  • Contribution :white_large_square:
11 Likes
6

What’s an RPC ?

I was simply trying to explain what might be the issue in that app specific case, and how hopefully one might help to improve it someday.
I’m not trying to say Yunohost is perfect, it has obvious drawbacks and it is not 100% ready to roll flawlessly for every (± advanced) use cases. With a lot of these issues coming from the limited benevolent time available to work on it. Then it’s up to you to figure out if it’s an useful tool for you or not.

That’s definitely something to improve, as from what I understand that diagnosis step is here to check if its DNS is properly setup or not - so it has to run first. Isn’t the web admin at least telling your it has to be done first ? That’s not ideal, but still something.

7

Also in einem kann ich ihnen recht geben, dennoch nur in einem Punkt. Wenn man Yunohost in einem kleinen Unternehmen einsetzen will, sollte man doch etwas mehr auf dem Kasten haben als Akten zu wälzen.

Doch hierbei kann ich ihnen überhaupt nicht zustimmen! Ich finde das Prüfen klasse und nicht schlimm, auch bei Lets and Crypt . Sie als doch erfahrener Mensch, der sie nun mal zu scheinen sind, laut Ihrer Aussage müsste es doch kurzfristig herausfinden können, und das ohne Probleme. Egal, wie frustrierend manche Dinge sind, doch alles in allem mag ich mein Yunohost und finde ihre Aussage komplett Schwachsinn und überzogen. Vielleicht nehmen Sie sich noch einmal einen PC Computer und üben mal eine Runde. Auf meinem Server läuft das System mit 24 Domains und nur ein Teil spinnt. Wie immer, die Synapse. Doch alles andere läuft recht gut und schnell.
Daher noch einmal eine Runde üben und es mal auf einer richtigen Maschine Probieren :wink:

8

I don’t think answering “it’s pretty easy, you should try harder” is a good way to welcome someone complaining about a bad experience with the software.

3 Likes
9

I did. But then you have to take a closer look at his comments and go into them. I would rather see this as an attack on the Yunohost system.
I also have my problems, especially since I don’t speak English, but I still support the system and I wanted to express that with it.

habe ich doch getan. Doch muss man dann auch näher auf seinen Anmerkungen doch schon näher schauen und eingehen. Ich würde das als Angriff auf das Yunohostsystem eher sehen.
Ich habe auch meine Probleme, besonders da ich kein Englisch beherrsche, trotzdem stehe ich hinter dem System und das habe ich damit zum Ausdruck bringen wollen.

10

obraz

There is ‘Ignore Diagnosis checks’ radio. If you check this You can Install SSL without diagnosis.

5 Likes
11

@Halmo I exactly feel you. YNH is a freaking mess. Not only permissions/locations wise; whole thing is one huge mess.

12

Then there is a couple of options : either provide a detailed feedback of the issues encountered so people can improve the software to fix them - and beyond constructive feedback feedback that is already useful and a form of contribution, possibly contribute to these adjustments ; or not use it if it doesn’t fit your needs.

2 Likes
13

Comments in the linked issues are only welcome if they are technically relevant or if you want to contribute. “+1” are discouraged, use :+1: reactions.

To summarize:

With an open source software? Did you mean “it changes my habits and I don’t like it?” :upside_down_face:

Welcome! If you have any specific grievance, we are all ears. :clown_face:

11 Likes
14

About the SFTP access and the use case to edit files of a CMS, i think we could probably improve things. Indeed, it’s a common usecase (a lot of webmaster just know how to edit files with SFTP).

This tuto Give SFTP permission to edit an app | Yunohost Documentation could help but it stays a bit difficult. For example here it was not /var/www/APP but /opt/yunohost/APP …

I 'm not sure the way use in the tuto (i think it’s me who provided those instructions) is the best (but that’s the way i found when i needed to give access to an app to a specific user = a webmaster).

2 Likes
15

It still seems to be that way unfortunately. I am very much trying to like yunohost, and it’s the best out there for my needs. But I still haven’t found a way to easily give SFTP access and permissions to who needs it and that has had me give up on yunohost several times in the last days. (I’m one day into a complete reinstall because I f*d up file permissions so badly.

If there are workarounds (something with git maybe?) to get my stuff from my home computer to my remote server and make backups, please let me know and eli5, because I’m new to server administration (or I would not use yunohost).

I’m also happy to help with tutorials once I find my way around.

16

Unfortunately there’s no easy, straightforward solution for the whole SFTP thing (or if there is, i’ll be glad to learn about it)

The reason is that Unix permissions are very minimalist, and to have a secure setup we usually end up with :

  • the app should own its own file
  • regularly, app files should have www-data as group such that nginx can server them
  • nobody else should be able to read (and even less write) those files, because priviledge minimization principle

Yet of course, if you connect as a admin (non-root) user, you can’t read nor write files.

And even if you could read/write files, then you end up with the second part of the issue which is :

  • to be able to effectively use those files, the app should own them and/or www-data should be the group owning them, but because they were created by an admin, the admin owns them. (that’s a rule of thumb, not all this may be necessary for all apps or folders…)

So regular Unix permissions are not enough for this … So let’s say we use the acl package. We can define additional permissions for the admins group such that they can read / write folders … but apps may create files or folders after these ACLs are defined … But maybe that’d be already good enough … though that’ll create other headaches like “I can edit files in folder X but not in folder Y, why ???”. And then that only solves the first half of the problem.

So we’d need to magic way to have ACL automatically applied to every new file/folder inside the app’s install folder … Maybe we could use some magic systemd service that monitor changes inside a folder and automatically trigger some recursive ACL (and also re-set the proper $app:www-data ownership). Feels a bit wonky though … Or maybe only enable this for very specific folders ?

Or we could have some sort of yunohost app reapply-chown-and-ACL $app command that could be triggered manually each time somebody wants to perform stuff with SFTP

In the meantime, two immediate workarounds I can think of are:

  • mount the local folder inside Nextcloud, that way you can sync your stuff via Nextcloud (but maybe that fixes only the first half of the problem)
  • connect to SFTP as root (assuming you’re on the same local network as the machine)
17

There is a default permission and owner with ACL mechanism that does exactly that.

If needed, it’s possible to connect as root through an ssh tunnel with the admin user…