🚀 YunoHost 12.0 (Bookworm) release / Sortie de YunoHost 12.0 (Bookworm)

[tmb]

@AxlRose1976

it´s sad that I can´t move the portal to the domain that I´d like to. It was possible with yunohost 11 when I set a subdomain as main domain and the portal showed up on this domain.

Hm, can someone maybe provide a little bit more explanation, about changes in the intented use (if any), and the available settings that remain with the new YNH 12 portal implementation? (I’m sorry, I also could not yet fully ‘grasp’ or ‘grok’ this part from the announcement.)

Here is another related use-case with (to me) unknown support state that worked really nice with YNH 11:

• Main domain set to a possibly hard-to-remember, maybe even impossible to change, reverse-DNS Domain. (Used as smtp mail-out domain by all configured domains)
• While allowing users to log in on a subdomain of their “usual” domain. (It’s much simpler to explain own users to just use e.g. to https://apps.example.org if they want or need to sign in to something. While example.org and www.example.org can just redirect/host some (public) app or website.

In YNH 11 the domain allowing the login could be configured by having a file /etc/ssowat/conf.json.persistent with:

{  "portal_domain": "apps.example.org" }

Result: Except for the button “user interface” (only present?) in the admin’s web interface, everything seems to point to the correct portal domain, and work perfectly.

1. Is this expected to break when upgrading to YNH 12?

2. Do you see an alternative solution that does not require the users to use long yunohost login url/sub-paths?

---

PS: As reference, that “portal_domain” configuration option had come up e.g. in this thread:

Users can't login after changing default page from domain.tld to sub.domain.tld

I think. In the domain menu, I clicked on make default, I thought it just changed the yunohost access domain. (to the sso page, admin page etc) I have 3 domain link to that install domain0.tld, domain1.tld and domain3.tld right now, I access to yunohost via domain0.tld, but I want to use it for other purpose, so I made default sub.domain0.tld "portal_domain": "sub.domain0.tld", "portal_path": "/yunohost/sso/", "redirected_regex": { "sub.domain0.tld/yunohost[\\/]?$": "htt…

[ljf]

@valterbarreira

I cannot change the url of an app without a subfolder, right now its forumsons[.]com/forumsons and i can’t change to forumsons[.]com.
When i click save button nothing happens

I guess you should change via a temporary fake domain first, cause the url is considered as used (yeah it seems a bug if there is only forumsons on this domain…). This temporary fake domain doesn’t need to be completely configure (no dns or let’s encrypt needed).

1. add a fake domain for example fake.local
2. Change the url og the app onto fake.local
3. Change again the url onto forumsons[.]com
4. remove the fake domain

[ljf]

@samuel-ynh

I have a nextcloud running on example.org which is on a server sitting in my home and yunohost running under yunohost.example.org. But yunohost should handle the mails for example.org as well. With yunohost 11 this worked.
But now if i try to login to yunohost I get always thrown to the IP of example.org.

@Qprq @samuel-ynh @AxlRose1976 Indeed, the portal in yunohost 12 makes some assumptions that was not made on yunohost 11. Use cases where you need to add domain.tld for managing emails without managing the web part on the yunohost (website on an other server, etc.) is not properly managed and need you to make some changes in /etc/ssowat/conf.json.persistent

I guess something like this could do the trick:

{
    "domain_portal_urls": {
        "sub1.domain.tld": "sub1.domain.tld/yunohost/sso",
        "sub2.domain.tld": "sub2.domain.tld/yunohost/sso",
    },
}

[valterbarreira]

I think it doesn’t solve because i have to set a subfolder to change to the fake domain, and then when i change back i can’t save.

[sydneyb]

Ah, so it does look like if the field “folder” is empty, the web admin is not allowing the save button to do anything then.

[valterbarreira]

yep that’s it, in yuno 11 worked

[tmb]

@ljf

the portal in yunohost 12 makes some assumptions that was not made on yunohost 11

I think it could help if yousomeone can state what is now assumed, is missing, and may optionally be manually configured? (from the user’s perspective)

In the apparently new “domain_portal_urls” dictionary setting, is the part /yunohost/sso (the path) also configurable to just /? And how does the selection between sub1/sub2 work based on the requested domain.tld?

[serversonic]

I did the upgrade this morning and there are a couple of issues:

• Home Assistant has not upgraded correctly, and the binary is not found at /var/www/homeassistant/bin/hass. Full log: hastebin
• I’m not sure if this is new, but Yunohost is assuming that subdomains have a root domain on the same server and that it is the SSO URL, which isn’t the case on my home server. In my case the root domain was on another Yunohost server. I have changed it to be on the server that I updated, but the SSO redirect is still going to the other server and seems to be caching a DNS lookup for it very aggressively.

[moppel]

Everything working good so far except for tandoor now refusing to work.

Seems like an error with “gunicorn”.

Yunohost pastbin here: hastebin

[tituspijean]

@serversonic

Home Assistant has not upgraded correctly, and the binary is not found at /var/www/homeassistant/bin/hass. Full log: hastebin

Can you try a forced upgrade of the app? sudo yunohost app upgrade homeassistant -F ?

@serversonic

I’m not sure if this is new, but Yunohost is assuming that subdomains have a root domain on the same server and that it is the SSO URL, which isn’t the case on my home server. In my case the root domain was on another Yunohost server. I have changed it to be on the server that I updated, but the SSO redirect is still going to the other server and seems to be caching a DNS lookup for it very aggressively.

To make sure I understand, your selfhosting topology is:

• foo.tld : YunoHost 1
• bar.foo.tld : YunoHost 2, but SSO redirects to foo.tld for logging in.

Is foo.tld registered as a domain on YunoHost 2?

@moppel

Everything working good so far except for tandoor now refusing to work.

Seems like an error with “gunicorn”.

Try sudo yunohost app upgrade tandoor -F

[moppel]

@tituspijean

sudo yunohost app upgrade tandoor -F

Worked. Thank you very much! <3

[samuel-ynh]

Thanks!
Now I can see the login portal and login successfully.

But with the rewritten domain portal urls, after login, there are no Apps shown. But I have definitely Apps installed.

Do you have an Idea, what that could be?

[serversonic]

Can you try a forced upgrade of the app? sudo yunohost app upgrade homeassistant -F ?

I uninstalled and reinstalled so we can ignore that, sorry.

To make sure I understand, your selfhosting topology is:

foo.tld : YunoHost 1
bar.foo.tld : YunoHost 2, but SSO redirects to foo.tld for logging in.

That’s correct.

Is foo.tld registered as a domain on YunoHost 2?

It is now, but was registered on YunoHost 1 initially, but not as the primary domain, which is a subdomain of another domain. YunoHost 1 has not been updated to Yunohost 12.0 yet.

As I suspected it might, whatever is causing the cached DNS response on YunoHost 2 has updated and it now redirects to the root domain for SSO, but again, it’s not tagged as the primary domain on the server.

[stilobique]

Migrations carried out, a few problems with several applications; resolved with a sudo yunohost app upgrade APP -F (Mastodon, Funkwhale, Photoview and Synapse).

Many thanks

@samuel-ynh : check your groups and user acces ? Have you any issue with your diagnostic dialog ?

[tituspijean]

@serversonic

Is foo.tld registered as a domain on YunoHost 2?

It is now, but was registered on YunoHost 1 initially, but not as the primary domain, which is a subdomain of another domain. YunoHost 1 has not been updated to Yunohost 12.0 yet.

As I suspected it might, whatever is causing the cached DNS response on YunoHost 2 has updated and it now redirects to the root domain for SSO, but again, it’s not tagged as the primary domain on the server.

Oh no, I was not suggesting you to add foo.tld on YunoHost 2, that would not make sense.

[chexxor]

I performed the upgrade today.

My HomeAssistant installation did not upgrade successfully.

First I tried to force-upgrade it using this command:

sudo yunohost app upgrade homeassistant -F

And here are the logs from that:
https://paste.yunohost.org/raw/afoxanadof

Though that logfile doesn’t seem to say it, the CLI log when running the command includes this:

Info: [###+++…] > Upgrading source files…
Info: Using already used python3 built version…
Warning: Error: [Errno 13] Permission denied: ‘/var/www/homeassistant/include/python3.12’
Error: Could not upgrade homeassistant: An error occurred inside the app upgrade script

After trying to manually restore from backup, because the HomeAssistant app is no longer listed as being installed, this is the log:
https://paste.yunohost.org/raw/opaforidic

with error message:

Exception: Original path for “/home/yunohost.app/homeassistant” not found

I’ll give up troubleshooting for now. I’m not very good with Python, but I hope I can find more things to try some things later.

[blodarn]

Server migrated. I installed a bunch of new apps. Thank you. New homepage is great!

[serversonic]

Oh no, I was not suggesting you to add foo.tld on YunoHost 2, that would not make sense.

That actually isn’t a problem as the domain was redundant on YunoHost 1, but the main issue is that something is assuming that the root domain of a subdomain will be the SSO domain. It appears that a similar issue is being reported up this thread by @AxlRose1976.

[AxlRose1976]

Editing the config.json.persistent worked. But I have the same problem that no apps are shown after login.

Edit:
I created a new sub.domain.tld.json in folder /etc/yunohost/portal
Now I have the same login like at domain.tld. Even public apps are shown.
But I assume if I will make changes in the GUI for domain.tld they will not be applied to sub.domain.tld.

[jarod5001]

I have a vps with :

• domain1 > app1
• domain2 > app2
• domain3 > portal
• sub1.domain3 > app3
• sub2.domain3 > app4
• and other subdomains in domain3

If I understand correctly, I need to add a subdomain in domain1 and domain2 to have a portal for that domain and app1 and app2 will not show in portal of domain3.
I don’t need portals for domain1 and domain2, so I will skip creating a subdomain, this won’t affect app1 and app2?
If I wanted to add app1 and app2 to the portal on domain3, using redirect apps?