Hello,
I’ve just update my Rapsberry Pi 3 B from testing 4.2.0 to testing 4.2.1.
I’ve some apps installed and i’ve added mumble without any problem.
The problem is :
I don’t have this for my other applications.
Excuse my poor English … so the best is an image 
ppr
On this slapd issue: if I stop the service (to avoid perpetual auto-restarts), and run by hand as root slapd -d 16383 (debug mode), the process starts well, and answers various requests (but same LUA error).
Yet, YunoHost commands check for the service status, then try to restart it… and we fall again the failure loop…
EDIT: reverted my LDAP configuration (as changed above to put my main domain), and changed /etc/default/slapd to empty SLAPD_USER and SLAPD_GROUP so that the service starts as root. The service starts OK. I could start yunohost app ssowatconf (doesn’t output anything); /etc/ssowat/conf.json is still well generated (was initially already there).
Yet I still have the same initial symptoms (500 errors and same nginx log).
# yunohost tools regen-conf -d -n
Attention : Le fichier de configuration '/etc/default/slapd' a été modifié manuellement et ne sera pas mis à jour
Attention : Le fichier de configuration '/etc/nginx/conf.d/yunohost_admin.conf' a été modifié manuellement et ne sera pas mis à jour
Attention : Le fichier de configuration '/etc/postfix/main.cf' a été modifié manuellement et ne sera pas mis à jour
Traceback (most recent call last):
File "/usr/lib/moulinette/yunohost/log.py", line 380, in func_wrapper
result = func(*args, **kwargs)
File "/usr/lib/moulinette/yunohost/regenconf.py", line 259, in regen_conf
_get_files_diff(system_path, pending_path, True) if with_diff else None
File "/usr/lib/moulinette/yunohost/regenconf.py", line 484, in _get_files_diff
orig_file = orig_file.readlines()
File "/usr/lib/python3.7/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfd in position 57: invalid start byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/yunohost", line 72, in <module>
parser=parser
File "/usr/lib/moulinette/yunohost/__init__.py", line 25, in cli
ret = moulinette.cli(args, output_as=output_as, timeout=timeout, top_parser=parser)
File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 120, in cli
args, output_as=output_as, timeout=timeout
File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 502, in run
ret = self.actionsmap.process(args, timeout=timeout)
File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 600, in process
return func(**arguments)
File "/usr/lib/moulinette/yunohost/tools.py", line 404, in tools_regen_conf
return regen_conf(names, with_diff, force, dry_run, list_pending)
File "/usr/lib/moulinette/yunohost/log.py", line 382, in func_wrapper
operation_logger.error(e)
File "/usr/lib/moulinette/yunohost/log.py", line 628, in error
return self.close(error)
File "/usr/lib/moulinette/yunohost/log.py", line 640, in close
error.log_ref = self.name
File "/usr/lib/moulinette/yunohost/log.py", line 579, in name
name = [self.started_at.strftime("%Y%m%d-%H%M%S")]
AttributeError: 'NoneType' object has no attribute 'strftime'
Could not open input file: /var/www/ttrss/update_daemon2.php so again a rights problemEDIT2: found out the source of problems 1 (ldap/portal) and 3 (ttrss): the ACL added in this commit are causing the trouble for slapd, metronome, nginx and ttrss.
I used setfacl -b on /etc/yunohost /etc/ssowat and /var/www (and could also revert /etc/default/slapd) and everything is back to normal.
So there is definitely an issue to dig there with that security fix (maybe only on my setup? LXC container on a QNAP NAS)…
Eeeeeh okay I don’t understand why that would be the cause … the ACL are supposed to be only for all_users (= all regular yunohost users), shouldn’t affect slapd or ttrss …
If you re-add the acl (just a yunohost tools regen-conf yunohost should do the trick), are you able to run for example
su admin -c "ls /etc/yunohost/"
or
su ttrss -s /bin/bash -c "ls /var/www/ttrss"
Nope:
# su admin -c "ls /etc/yunohost/"
ls: impossible d'ouvrir le répertoire '/etc/yunohost/': Permission non accordée
# su ttrss -s /bin/bash -c "ls /var/www/ttrss"
ls: impossible d'accéder à '/var/www/ttrss': Permission non accordée
Eh okay … and if you run ls -ld /etc/yunohost, do you see as permissions: rwxr-xr-x+ ?
Maybe your system or filesystem doens’t support ACL for some reason …
E.g. if you run lsblk -f, do you see you main filesystems as ext4 ?
# ls -ld /etc/yunohost
drwxr-xr-x+ 6 root root 4096 avril 10 19:51 /etc/yunohost
(and I can use get/setfacl)
In lsblk -f output, the FSTYPE column is empty…
Hmmmokay … Let’s dig the hole then,
let’s run getfacl /etc/yunohost
# getfacl /etc/yunohost
getfacl : suppression du premier « / » des noms de chemins absolus
# file: etc/yunohost
# owner: root
# group: root
user::rwx
group::r-x
group:all_users:---
mask::r-x
other::r-x
Meh … that makes no sense … apart if su admin -c "groups" show all_users for some reason (on my side it just complains to group ID 1007 actually exists but whatever)
admin ain’t in all_users group, so perms for that user should be r-x …
Same here:
# su admin -c "groups"
groups: impossible de trouver le nom pour le GID 1007
1007
Maybe that’s a shitty ACL implementation by QNAP…? I don’t seem to find that as a known problem on their forum…
You can try the following (maybe you need to install e2fsprogs if tune2fs ain’t there):
/sbin/tune2fs -l /dev/your_main_rootfs_device | grep acl
# On my side it show:
#Default mount options: user_xattr acl
And supposedly if it ain’t here, this should enable it :
/sbin/tune2fs -o acl /dev/your_main_rootfs_device
Also, as an alternative to lsblk -f, we can try df -T to check the fstype
OK, df -T confirms the file system is ext4, but I can’t use tune2fs inside the LXC container. If I use tune2fs from the host (custom QNAP Linux), I don’t get the acl keyword. What I know is that I had activated ACLs through the QNAP web interface a long time again (and thus getfacl/setfacl don’t generate errors), and that I’ll carefully check before executing the command you proposed 
Thanks for your help anyway! Btw are ACL mandatory for YunoHost? I remember there used to be OVH (or other cloud provider) setup which didn’t support it.
Well so far they were only used in specific case (e.g. the multimedia folders)
But that sounded like an easy and elegant solution to the security issues spotted recently … but of course it sounds like nothing is never that easy with computers …
Naively I’d think on any regular setup with ext4 filesystem, ACL should just work …
I’ll maybe look deeper into it, but QNAP kernel seems to really implement sh*tty ACL if this old post is still true…
EDIT: Unfortunately, looking at the latest QNAP kernel source code, the “custom” ACL algorithm hasn’t changed since that aforementioned forum post… In my case above, any --- entry in the ACL list (which is the very case in that 4.2.1 fix) denies access to all 
I still have the issue with services with 4.2.1. (I don’t know if this version was supposed to address this issue…).
I also get an error while closing ports…
@ericg : no it did not, but as we discussed on the chat, considering that there are several important small bugs with fixes pending, I’m making an hotfix release in 4.2.1.1 before the next big iteration:
Builds are ongoing, should be available in a couple minutes 
And here’s another big iteration on both the core and the new webadmin !
UI/UX fixes and improvements in the new webadmin thanks to the feedback of the testers 
. This include new human-readable descriptions of what’s going on each time an operation is triggered.
SFTP and SSH permissions. This will allow to grant SSH/SFTP access to users using the permission system. This also comes with a rework of the SSH configuration. Note that, by design, you can’t grant this permission to all users. You must grant it to individual users, or create a group and grant the permission to this group. We also recommend to be careful and not grant this permission to random people that you don’t really trust.
Many improvements on backups, including a significant rework of the content of system backups which should now be more sensible and prevent inconsistencies.Thanks to all contributors 
! (axolotle, Bram, C. Wehrli, cyxae, D. Vasilev, Daniel, Éric G., grenagit, Josué, Kay0u, K. Nowakowski, lapineige, ljf, Scapharnaum)
Annnnnd the usual “bug I noticed after releasing” : for some reasons all my backup archives containing only apps are displayed as empty (but pretty sure they are not). Will investigate later.
Hello,
Upgrading to 4.2.2 testing version solve the problem of “blank app”.
Thanks to the team <3
ppr
