🚧 YunoHost 12.0 beta (Bookworm)

Ok sorry, I should have read this

Upgrade to Debian 12 by CLI successfully done. (Thanks to the people who made it happen)

Small issues on the way

1. After upgrade, nginx shows ‘HTTP 500’ for all requests.

  • With my daily browser or in “private mode” so no cache or SSOEven involved
  • nginx log file
==> /var/log/nginx/example.org-error.log <==
2024/08/10 18:41:46 [error] 839726#839726: *449785 lua entry thread aborted: runtime error: /usr/share/ssowat/access.lua:377: attempt to concatenate field 'portal_url' (a nil value)
stack traceback:
coroutine 0:
        /usr/share/ssowat/access.lua: in function </usr/share/ssowat/access.lua:1>, client: 2001:db8::1, server: example.org, request: "GET /yunohost/sso/ HTTP/2.0", host: "example.org", referrer: "https://example.org/yunohost/sso/?r=aHR0cHM6Ly9zYW1iYWluLm5ldC8="

==> /var/log/nginx/example.org-access.log <==
2001:db8::1 - - [10/Aug/2024:18:41:46 +0000] "GET /yunohost/sso/ HTTP/2.0" 500 170 "https://example.org/yunohost/sso/?r=aHR0cHM6Ly9zYW1iYWluLm5ldC8=" "Mozilla/5.0 XXXX"
  • After restarting nginx with systemctl restart nginx.service, it was fine. There was no related errors in journalctl

IMO, this will be confusing for people doing the migration

2. Apt warning

Found in this thread and solved too with

3. Installation of Metronome as it is from the “core”

After the migrtion, I wanted to give XMPP / Metronome a try and I could not found it in the “Apps Catalog”. I end up using the “technical github link”.

I might have missed a “simplier way” or “user friendly” of installing it.


I had to put the github link directly to install it

Tests done

  • I have a single domain with multiple sub domains
  • All my mains applications runs as before
    • Nextcloud is still there and runs fine (yeah)
    • So the PHP applications too
  • Backups runs and are listed in the webadmin (didn’t try to restore it though…)

Not a deep testing but hey, it works. Thanks

1 Like

Wow, it’s getting there. I’ve tested a fresh install following the CLI install instructions.

It went mostly smooth, with just problems already mentioned above, like blank white app icons, or metronome and rspamd only installable by URL.

However, I did managed to trigger a traceback.
It happened after either not running the diagnosis at all, or first running it in web-admin, and only then on the CLI again like this:

# yunohost diagnosis run
INFO (Cache still valid for Base system diagnosis. Won't re-diagnose it yet!)
[...a couple "won't diagnose" lines for other diagnosis parts removed...]

# Then I got this traceback error:
# (Maybe because there was no diagnosis run which reported a failure of the yet-to-be-disabled service?)

# sudo yunohost service disable yunomdns
Traceback (most recent call last):
File "/usr/bin/yunohost", line 77, in <module>
    		yunohost.cli(
File "/usr/lib/python3/dist-packages/yunohost/__init__.py", line 41, in cli
    		ret = moulinette.cli(
          		^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 115, in cli
    		).run(args, output_as=output_as, timeout=timeout)
      		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 498, in run
    		ret = self.actionsmap.process(args, timeout=timeout)
          		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 561, in process
    		return func(**arguments)
           		^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/yunohost/service.py", line 319, in service_disable
    		diagnosis_ignore(["services", f"service={name}"])
File "/usr/lib/python3/dist-packages/yunohost/diagnosis.py", line 212, in diagnosis_ignore
    		return _diagnosis_ignore(add_filter=filter, list=list)
           		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/yunohost/diagnosis.py", line 285, in _diagnosis_ignore
    		current_issues_for_this_category = current_issues_for_this_category["reports"][
                                       		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		IndexError: list index out of range
		
# It seems to have worked thereafter, by forcing a diagnosis run, and then re-trying again.

Hm, gone for good, not configurable per app? May I ask about the reason?

I’m now having trouble to see or determine if currrently logged-in to a restricted app, or not, and to easily swtich apps and log out.

How do you solve these things now?

I updated a server with quite a few apps and users. All went smooth except a single unexpected warning from the diagnosis that was not present before:

The configuration file '/etc/apt/sources.list.d/extra_php_version.list' has been manually modified and will not be updated

With details :

$ sudo yunohost tools regen-conf apt --dry-run --with-diff
Warning: The configuration file '/etc/apt/sources.list.d/extra_php_version.list' has been manually modified and will not be updated
apt: 
  applied: 
  pending: 
    /etc/apt/sources.list.d/extra_php_version.list: 
      diff: @@ -1 +1 @@
-deb https://packages.sury.org/php/ bookworm main
+deb [signed-by=/etc/apt/trusted.gpg.d/extra_php_version.gpg] https://packages.sury.org/php/ bookworm main
      status: modified

This looked benign so I went ahead and forced the change manually

$ sudo yunohost tools regen-conf apt --force

That’s all for me!

Hm, checking back into the ynh12 testing lxd instance, I’m seeing a lot of these error messages with journalctl:

ntpd[21411]: CLOCK: step_systime: Operation not permitted
ntpd[21411]: CLOCK: local_clock: ntpd/ntp_loopfilter.c line 792: ntp_adjtime: Operation not permitted

If I remember correctly, with ynh11 there had been some regen-conf diff, which needed manual application, and that removed some ntp config file with container related “can adjust time” settings.

Not sure exactly but this seems related to the whole KDE / plasma / graphical environment stack and hmpf x_x

1 Like

Sorry, redid it and it worked…

Hello,

It look like that there is an issue about the restoration on Yunohost 12 of some php apps from a Yunohost 11 archive. cf Can't restore backup on YNH12 ¡ Issue #481 ¡ YunoHost-Apps/synapse_ynh ¡ GitHub

The issue is that when the app don’t have an explicit php version (so we use de default version from debian) we end with the bug. The app try to be restored with the default php version of the Yunohost 11 instead of Yunohost 12

One solution to solve this, is to request all app to have an explicit php version (mostly does but probably not all). Or, an other solution, should be just to fix this bug ?

It is indeed what’s expected now with packaging v2. :slight_smile:

Ok maybe we could improve the doc and package linter on this side as it’s not really explicit for now.

1 Like

[EDIT: Errata: this was ynh11 with overlay disabled]
Opening a domain that is configured with a default app which is not made available to visitors I do correctly get the login screen, and then then app…

However,

  • The back button only brings me to the login screen, with no option to log out.
  • Reloading the login page now opens the app, and breaks the history, without a way back to the login URL.
  • Only way I found is to manually edit the URL bar on the login page (while it is still available in the history), and remove the ?r= parameter behind /yunohost/sso/ to open the portal and log out from there.
  • Using the app for a while makes this more and mode cumbersome, as the login page gets further and further away in the history.

[EDIT: Errata: this was ynh11 with overlay disabled]

Could the login page in the history maybe first get modified to show a logout button after successful login, before forwarding to the target URL? (And make reloads only reload that logged-in state, instead of the forwarding.)

That could still allow to have direct app URLs that do not load or show the entire portal, but with a decent basic usability.

Only optionally, maybe there could also be added a button to open the portal from the logged-in-state login page, and maybe load the portal upon a re-load of that.

EDIT:
Hm, “Only optionally,…” that might be… if the user has access to more than one app…

[EDIT: Errata: this was ynh11 with overlay disabled]

Hm, or just plain simply load the portal page, before redirecting back to the original app URL after login?

[EDIT: And this is what ynh12 seems to do.]

Oops, sorry, I had an error in my /etc/hosts and my portal “testing” actually connected me with a ynh11 instance with the overlay disabled…

Cloud-init image :tada:

We have build a cloud-init yunohost image. So if you have a proxmox (or know a vps provider who support cloud-init), we will be happy if you try to create a virtual machine with it.

The cloud-init image is here: https://image-builds.yunohost.org/

8 Likes

Hi, what are the login credentials for this cloud-init image?

Hi
A new side effect is the DNS diagnosis. No sure what is the relation with the upgrade but it exists since i switched to bookworm. The check of all domains (2) and subdomains (1 on a domain and 15 on the other) is so slow and raising many warnings that are strange :

According to the recommended DNS configuration, you should add a DNS record with the following info.

It requires me to add A and AAAA records for each domain and subdomain but they exists

Of course i did not change any DNS record since i upgraded the server and the fixed ip is still the same. I tried to clear dnsmasq, reboot, restart nginx service, etc. but still get the point and don’t know how to solve that

You have to configure it with cloudinit… So in proxmox, you have the cloudinit item menu in the virtual machine vue.

@pihomeserver Try to restart dnsmasq, DNS from dnsuncensored was down yesterday. Restarting dnsmasq should use other dns resolver first.