Alpha-stage testing for YunoHost 12.0 on Debian Bookworm (but not yet for the Bullseye→Bookworm migration)

OVH VPS, IPv6 enabled, upgraded to Bookworm.

YunoHost install went smoothly.

Just tried to install Streams for the moment, it works as expected.



Thanks a lot for works by all Yunohost team :tada:

Did some test (mainly with SOGo) on bookworm and I detected some breaking changes or issues about authentications header passed to applications.

On debian bullseye I have something like that for authentication header

some other headers
Authorization: Basic am9zdWU6cHdk  (base64 decoded: 'josue:pwd')
Remote-User: josue
Email: josue@domain.tld
Name: =?utf-8?b?Sm9zdcODwqkgam9zdWU=?=
Auth-User: josue

But on debian bookworm I have this

some other headers
Authorization: Basic am9zdWU6LQ== (base64 decoded: 'josue:-')

So there are missing some element and the password are not passed correctly, so apps like SOGo which need auth header to retrieve the password to pass to IMAP server are broken.

Note that I used this tools to analyse this, which is really great: simple python http server to dump request headers · GitHub

1 Like

3 posts were split to a new topic: Au sujet de l’écriture inclusive dans YunoHost

Hi all, I have a small issue on Yunohost 12. Every time I enable UPnP on the firewall parameters, after some time UPnP is disabled again. Is that by default ? I don’t know where to look for any logs for debug if it’s a big. I don’t know how to disable that feature if it’s a feature. Thanks !

Sounds like my issue on 11.x Yunohost Firewall keeps closing/removing Home Assistant port - #7

Seems like the issue observed before on CI with private install test failures is not phony at all.
Limesurvey flat out denies access to admin panel because ‘user is not authorized’ (302 to SSO, message from ssowat.log) despite belonging to Admins group and having permission to limesurvey.admin explicitly granted to them.

auth_header should be set to user-with-password for that to work (True defaults to user-without-password), but not sure if it’s a valid entry in manifest.toml.

Hi jwqos, and all XMPP users/admins,
i have a first working version of Prosody for Yunohost 12 (to fill the gap of Metronome and hopefully finally provide a better XMPP experience!): GitHub - anubister/prosody_ynh: Prosody package for YunoHost
Feel free to test (as YNH12, it is alpha and will be improved in the next days), report or comment on or here on the announcement post : [prosody] XMPP server for Yunohost 12 :slight_smile:


Naively I’d say that the same stuff as for SOGo and other (iirc the ‘private install’ test on the CI fails all the time because it expects the result page to be the yunohost portal, which it checks from the HTML title (or similar stuff), which changed in Bookworm - totally unrelated from actual ACL, but I’m only 90% sure of this)

Long story short, I was hoping we would be able to not send the password inside the Basic auth header, hence I made this the default behavior, but then realized at least a few apps don’t just trust the $remote_user part but also need the password, so I started hardcoding a temporary list, but it looks like way many apps are affected so maybe we need to re-change the policy to auth-with-password by default but meh, that just means we’re stuck with the password issue until somehow some day we figure out all apps that do require it >_>

Related piece of code: yunohost/src/ at bookworm · YunoHost/yunohost · GitHub

I figured that one out, yunohost.portal cookie is set for domain.tld while Bullseye SSOWat issued auth cookie(s) for .domain.tld, hence matching subdomains.
Possibly we should issue cookie-per-explicit-domain-handled-by-this-instance or something?

Well the issue with with SOGo, but probably with many other webmail, is that the app need the password to be able to authenticate to the remote mail server (SMTP and IMAP) and for this there might be some other solution but it might be quite more complicated. Would be interesting to know if the issue also happen with roundcube or some other webmail and if it’s not the case how it work.

For this from my point of view, here is the solution which could be investigated:

  • Add a new app setting (into the manifest) to pass the password to the app and request that the packager add a comment why this is needed so we can limit the usage and only packager which know what he do will enable it.
    We could by example have something like this:
main.url = "/"
main.auth_header = true # Current setting
main.auth_header_password = true # New setting
main.auth_header_password_comment = "It is needed because the webmail need to pass the user and password to the SMTP and IMAP server for authentication"
  • Check by example on the SOGo doc or on some other webmail doc how we can manage the SMTP and IMAP authentication alternatively without the password from auth header and see if there are a common standard which could be used alternatively.

The following log: is considered failure, hence chain of upgrade(fail)->remove(fail)->restore does not reach the restoration phase.

EDIT: even better, the app was indeed not removed and is effectively unremovable now :confused:

Uninstall log:

~$ sudo yunohost app remove penpot --debug
168  DEBUG   acquiring lock...
182  DEBUG   lock has been acquired
194  DEBUG   loading python module took 0.012s
194  DEBUG   processing action ''
203  INFO    Removing penpot…
249  DEBUG   Executing command '['sh', '-c', '/bin/bash -x "./remove"  7>&1']'
253  DEBUG   + source
254  DEBUG   ++ nodejs_version=20
254  DEBUG   ++ current_hash=1eaf7b2b4
254  DEBUG   ++ version=1.19.3-10698-g1eaf7b2b4
254  DEBUG   ++ build_date='Mon, 18 Sep 2023 09:14:03 +0000'
255  DEBUG   + source /usr/share/yunohost/helpers
256  DEBUG   +++ set +o
256  DEBUG   +++ grep xtrace
258  DEBUG   ++ readonly 'XTRACE_ENABLE=set -o xtrace'
258  DEBUG   ++ XTRACE_ENABLE='set -o xtrace'
258  DEBUG   ++ set +x
283  DEBUG   + ynh_script_progression '--message=Removing system configurations related to penpot...'
283  DEBUG   + set +o xtrace
314  DEBUG   + set +o xtrace
343  DEBUG   + echo '! Helper used in legacy mode !'
344  DEBUG   + set +x
346  DEBUG   + echo '[+++++...............] > Removing system configurations related to penpot...'
346  DEBUG   + set -o xtrace
347  DEBUG   + ynh_exec_warn_less yunohost service status penpot-backend
347  DEBUG   + [[ 4 -eq 1 ]]
347  DEBUG   + yunohost service status penpot-backend
347  INFO    [+++++...............] > Removing system configurations related to penpot...
690  DEBUG   + ynh_exec_warn_less yunohost service status penpot-exporter
690  DEBUG   + [[ 4 -eq 1 ]]
690  DEBUG   + yunohost service status penpot-exporter
1031 DEBUG   + ynh_remove_nginx_config
1031 DEBUG   + ynh_secure_remove --file=/etc/nginx/conf.d/
1031 DEBUG   + local legacy_args=f
1032 DEBUG   + args_array=(['f']='file=')
1032 DEBUG   + local -A args_array
1032 DEBUG   + local file
1032 DEBUG   + ynh_handle_getopts_args --file=/etc/nginx/conf.d/
1032 DEBUG   + set +o xtrace
1041 DEBUG   + set +o xtrace
1051 DEBUG   + echo ''\''/etc/nginx/conf.d/'\'' wasn'\''t deleted because it doesn'\''t exist.'
1051 DEBUG   + set -o xtrace
1052 DEBUG   + ynh_systemd_action --service_name=nginx --action=reload
1052 DEBUG   + local legacy_args=nalpte
1052 DEBUG   + args_array=(['n']='service_name=' ['a']='action=' ['l']='line_match=' ['p']='log_path=' ['t']='timeout=' ['e']='length=')
1052 DEBUG   + local -A args_array
1052 DEBUG   + local service_name
1053 DEBUG   + local action
1053 DEBUG   + local line_match
1053 DEBUG   + local length
1053 DEBUG   + local log_path
1053 DEBUG   + local timeout
1054 DEBUG   + ynh_handle_getopts_args --service_name=nginx --action=reload
1054 DEBUG   + set +o xtrace
1054 INFO    '/etc/nginx/conf.d/' wasn't deleted because it doesn't exist.
1133 DEBUG   + service_name=nginx
1133 DEBUG   + action=reload
1133 DEBUG   + line_match=
1134 DEBUG   + length=20
1134 DEBUG   + log_path=/var/log/nginx/nginx.log
1134 DEBUG   + timeout=300
1135 DEBUG   + '[' reload == stop ']'
1135 DEBUG   + [[ -n '' ]]
1135 DEBUG   + '[' reload == reload ']'
1135 DEBUG   + action=reload-or-restart
1136 DEBUG   ++ date --utc --rfc-3339=seconds
1136 DEBUG   ++ cut -d+ -f1
1138 DEBUG   + local 'time_start=2024-04-19 22:44:29 UTC'
1138 DEBUG   + systemctl reload-or-restart nginx
1260 DEBUG   + [[ -n '' ]]
1260 DEBUG   + ynh_remove_logrotate
1261 DEBUG   + '[' -e /etc/logrotate.d/penpot ']'
1261 DEBUG   + ynh_secure_remove --file=/var/log/penpot
1261 DEBUG   + local legacy_args=f
1261 DEBUG   + args_array=(['f']='file=')
1261 DEBUG   + local -A args_array
1261 DEBUG   + local file
1262 DEBUG   + ynh_handle_getopts_args --file=/var/log/penpot
1262 DEBUG   + set +o xtrace
1264 DEBUG   + set +o xtrace
1276 DEBUG   + echo ''\''/var/log/penpot'\'' wasn'\''t deleted because it doesn'\''t exist.'
1276 DEBUG   + set -o xtrace
1276 DEBUG   + ynh_redis_remove_db 1
1277 DEBUG   + local db=1
1277 DEBUG   + redis-cli -n 1 flushall
1277 INFO    '/var/log/penpot' wasn't deleted because it doesn't exist.
1299 DEBUG   OK
1304 DEBUG   + ynh_script_progression '--message=Removal of penpot completed' --last
1304 DEBUG   + set +o xtrace
1362 DEBUG   + set +o xtrace
1373 DEBUG   + echo '! Helper used in legacy mode !'
1373 DEBUG   + set +x
1375 DEBUG   + echo '[####################] > Removal of penpot completed'
1375 DEBUG   + set -o xtrace
1375 INFO    [####################] > Removal of penpot completed
1487 INFO    The operation 'Remove the 'penpot' app' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20240419-224428-app_remove-penpot' to get help
1494 DEBUG   action executed in 1.300s
1494 DEBUG   lock has been released
Traceback (most recent call last):
  File "/usr/bin/yunohost", line 77, in <module>
  File "/usr/lib/python3/dist-packages/yunohost/", line 41, in cli
    ret = moulinette.cli(
  File "/usr/lib/python3/dist-packages/moulinette/", line 115, in cli
    ).run(args, output_as=output_as, timeout=timeout)
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/", line 501, in run
    ret = self.actionsmap.process(args, timeout=timeout)
  File "/usr/lib/python3/dist-packages/moulinette/", line 567, in process
    return func(**arguments)
  File "/usr/lib/python3/dist-packages/yunohost/", line 407, in func_wrapper
    result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/yunohost/", line 1454, in app_remove
    AppResourceManager(app, wanted={}, current=manifest).apply(
  File "/usr/lib/python3/dist-packages/yunohost/utils/", line 55, in apply
    todos = list(self.compute_todos())
  File "/usr/lib/python3/dist-packages/yunohost/utils/", line 127, in compute_todos
    resource = AppResourceClassesByType[name](infos,, self)
  File "/usr/lib/python3/dist-packages/yunohost/utils/", line 1399, in __init__
    super().__init__(properties, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/yunohost/utils/", line 157, in __init__
KeyError: 'version'

Zblerg yeah i think this bug was fixed in the dev branch but not yet propagated to the bookworm branch (just need to git merge é_è)


I can’t connect my nextcloud synchronisation client: error 401.

Perhaps this isn’t related to the fact that it’s the alpha version: if anyone can tell me whether they have the same problem or not. I could create another topic if necessary.

The problem seems to be the same as the one created 1 year ago here
I’ve read the whole thread… I’ve tested the suggested commands. But either what needs to be checked is ok, or it doesn’t change anything. I still get the 401 error.
The only thing I don’t have is the line "use_remote_user_var_in_nginx_conf": false, in /etc/ssowat/config.json…
I tried adding it by hand in the right place, restarting the nginx service (I didn’t see any sso service), then trying to connect again: but nothing, error 401…

I also noticed that the following libraries had not been installed: php-json php-xml php-php-gettext php-pear php-mbstring
I’m comparing this to an older installation that I have on hand, on the current stable branch of yunohost (I haven’t listed the php packages in version 7 that are installed with version 8).
Even installing them still doesn’t work…

I didn’t specify. But the rest of the installation works perfectly: I have full access (without any errors) to my nextcloud interface (well, there’s just the little error linked to sso, mentioned above, but I think that’s another problem).

I confess I don’t really know where to look for this error.

Does anyone have the same error? If not, I’ll create another thread to discuss it :wink:

There seem to be apt-keys missing for and

What I did:

  • Install Debian 12
  • Installed curl
  • Added /sbin and /bin to the PATH (mysteriously it wasn’t there for root)
  • run the “curl” command line given above
  • run the postinstal CLI command
  • Log into server via webinterface
  • go through the menu options from top (doing nothing of consequence but adding another domain; especially no App installed)
  • Clicked on the “System update” menu
  • Got the following internal server error (Sorry, no YunoPaste button on that page)

YunoHost encountered an internal error

Really sorry about that.

You should look for help on (edited link out due to forum link limit) or (edited link out due to forum link limit) to fix the situation, or report the bug on (edited link out due to forum link limit).
The following information might be useful for the person helping you:

Error: "500" Internal Server Error

Action: "PUT" /yunohost/api/update/all

The error message is not really helpful, as it simply dumps all apt sources but at the bottom there follows:

**While processing the action the server said:**

Fetching available upgrades for system packages…

W: GPG error: stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23E7166788B63E1E

E: The repository ' stable InRelease' is not signed.

W: GPG error: bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743

E: The repository ' bookworm InRelease' is not signed.

And indeed, while /etc/apt/sources.list.d/yarn.list says
deb [signed-by=/etc/apt/trusted.gpg.d/yarn.gpg] stable main
there is no /etc/apt/trusted.gpg.d/yarn.gpg file
(and the same for /etc/apt/sources.list.d/extra_php_version.list, which contains the reference).

Now, I know how to get those keys but
a) I doubt that installation should include manual key addition and
b) I wonder why I am the only one where this happened, because if it was a general error basically everyone should have noticed this.


I don’t know if this point has been raised, but at the very least for the SimpleX application, the 2 services will not start if the binaries were made on an OS with OpenSSL1 (smp-server and xftp-server).
The binaries will have to be redone on an OS with OpenSSL3 at this time for Bookworm in order to avoid this issue.