Yunohost on Subdomain, Mail on main domain

samuel-ynh · November 2, 2022, 9:42pm

My setup is described in this post: Yunohost on Subdomain, Mail on main domain - #4 by samuel-ynh

Hi there,

I have a question to get yunohost running.
I’m hosting a fairly big nextcloud instance on my homeserver. which has its own domain (ex. mydomain.org).

I would love to use yunohost, to manage mails on mydomain.org and access the nextcloud on mydomain.org.

Right now yunohost runs on a vps and should be accessible under yunohost.mydomain.org.
Can I achieve to manage mails through yunohost under mydomain.org?

I searched the forum and haven’t found a solution yet.

Best regards!
Samuel

wtrmln · November 19, 2022, 2:12am

Hello,

If I understand your problem well, I think I found a solution. If your main domain is registered in yunohost domains (in the administration), then you can edit an user in the administration and chose the correct domain when defining his email address, you can also edit all the aliases. You may have to tweak your DNS configuration a bit so that mails work on main domain (I used the generated DNS config in the “Domains” menu in the admin).

Hope that will solve your problem, if not I’m afraid I can’t be of any help

samuel-ynh · November 19, 2022, 3:03pm

Hi!

Thanks for your reply - I already consiedered this thread dead

Just to be sure, to understand you the right way, I would

Add my domain to the domains
Only add the DNS entries for mail and preserve the rest, so that the nextcloud remains functional
Add user(s) that have mail on the main domain

Thank you very much for your help!
Samuel

samuel-ynh · November 22, 2022, 3:34pm

Okay,

it worked, like you said.

For reference i try to describe my setup in some detail (2024-11-07 now with yunohost 12 update).

Domain

Yunohost runs under yunohost.example.com, the DNS is set up according to the generated DNS config by Yunohost
The domain example.com was added as well, but only the DNS entries corresponding to mail were added.
Additionally the mx entry for example.com points to 10 yunohost.example.com
Reverse DNS-entry for the emails should be the yunohost subdomain (yunohost.example.com). Correct rDNS setup for mail-domain

Yunohost SSO Portal

With the new SSO on yunohost 12 the login page from the subdomain redirects to the main domain. To address this I created `/etc/ssowat/conf.json.persistent’ with:

{
    "domain_portal_urls": {
        "yunohost.example.com": "yunohost.example.com/yunohost/sso",
    },
}

From: 🚀 YunoHost 12.0 (Bookworm) release / Sortie de YunoHost 12.0 (Bookworm) - #84 by ljf

Empty landing page on yunohost 12

After loggin in on yunohost 12 no apps are shown. To fix this you can create a symbolic link in /etc/yunohost/portal/ for the subdomain which points to the file of the main domain

ln -s /etc/yunohost/portal/example.com /etc/yunohost/portal/yunohost.example.com

Unfortunately the symlink gets removed rather regularly. Therefore I created a systemd unit to create the symlink (this is definitely not an elegant solution).

`/etc/systemd/system/yunohost-portal-symlink.service`

[Unit]
Description=Create a symlink to enable the portal created for example.com on yunohost.example.com
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/ln -sf /etc/yunohost/portal/example.com.json /etc/yunohost/portal/yunohost.example.com.json

[Install]
WantedBy=multi-user.target

`/etc/systemd/system/yunohost-portal-symlink.timer`

[Unit]
Description=Starts the service to create the portal symlink to yunohost.example.com

[Timer]
OnCalendar=*:0,10,20,30,40,50
Unit=yunohost-portal-symlink.service

[Install]
WantedBy=multi-user.target

Unfortunately Apps that are not accessible for visitors are still not shown. @tomdereub and @ljf found the solution to create a custom subportal in the /etc/ssowat/conf.json.

Mail with wildcard aliases

The users get wildcard aliases to their primary mail in the form of *username@example.com this is achieved by a post-user-create-hook which adds the wildcard to the postfix config.
Postfix should recognize these aliases, therefore /etc/postfix/main.cf needs to be altered, to preserve this change upon upgrades I created a conf-regen-hook. After upgrade one should execute sudo yunohost conf-regen postfix --force then the updated config can take place with the reference to the regex-aliases.
Reference: Mail alias with wildcard - #4 by Martin

/etc/yunohost/hooks.d/conf_regen/20-postfix_modifications

#!/bin/bash

action=$1
pending_dir=$4
postfix_conf=$pending_dir/../postfix/etc/postfix/main.cf

# Check if everything is in place
[[ $action == "pre" ]] || exit 0
[[ -e $postfix_conf ]] || exit 0

# Include Regex Aliases
awk -i inplace '{if (/^virtual_alias_maps = /) {$0=$0 ",regexp:/etc/postfix/aliases-regexp"}; print}' $postfix_conf

# Comment out sender mismatch verification
# To send mails from *@mydomain.org
sed -e '/reject_sender_login_mismatch/ s/^#*/#/' -i $postfix_conf

/etc/yunohost/hooks.d/post_user_create/10-new-user-postfix-regex

#!/bin/bash

echo "/.*$YNH_USER_USERNAME@example\.com/ $YNH_USER_MAIL" | cat - /etc/postfix/aliases-regexp > temp && mv temp /etc/postfix/aliases-regexp

postmap /etc/postfix/aliases-regexp
systemctl restart postfix

Backup

Okay, I’m just roughly documenting my setup here. Hence this chapter for backups.

I have a home-server running on the main domain with a working borg-backup. Therefore my backup solution is rather simple. The yunohost backup gets invoked once per day and only the 5 most recent backups are kept. Then on the home server runs a service which rsyncs the backups to the home server. This directory gets backupped with borg.

`/home/example/yunohost-daily-backup.sh`

#!/bin/bash


# Set date variable to current date
#printf -v date '%(%Y-%m-%d)T\n' -1
date=$(date '+%Y-%m-%d')
backupDir=/home/yunohost.backup/archives


# Invoke yunohost backup
yunohost backup create -n "${date}-daily"

# Remove old backups keep the newest 5 backups
# https://stackoverflow.com/questions/25785/delete-all-but-the-most-recent-x-files-in-bash
## daily backups
cd $backupDir && ls -tp | grep -v '/$' | grep  'daily' | tail -n +10 | tr '\n' '\0' | xargs -d '\n' -r rm --


## all other backups
cd $backupDir && ls -tp | grep -v '/$' | grep  -v 'daily' | tail -n +10 | tr '\n' '\0' | xargs -d '\n' -r rm --

`/etc/systemd/system/yunohost-daily-backup.service`

[Unit]
Description=Create a daily yunohost backup
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/bash /home/example/yunohost-daily-backup.sh

[Install]
WantedBy=multi-user.target

`/etc/systemd/system/daily-backup.timer`

[Unit]
Description=Starts the service to create a daily yunohost backup

[Timer]
OnCalendar=daily
Unit=yunohost-daily-backup.service

[Install]
WantedBy=multi-user.target

After all, I’m no expert in all of this, so if you find errors or wildly exotic handling of configs, I’m more than happy if you tell me.
Best regards
Samuel

samuel-ynh · November 7, 2024, 8:54am

Updated the setup to yunohost 12.

tomdereub · January 24, 2025, 8:09am

Hi, I’m in the same situation : main domain is redirected to an other website, not hosted on my yunohost, but mail are on yunohost, and the portal is on a subdomain. Like that :

domain.tld : website, not on yunohost. But mails are redirected to yunohost.
portal.domain.tld : portal, main domain for yunohost
app1.domain.tld
app2.domain.tld

After yunohost 12 migration, I added the line on /etc/ssowat/conf.json.persistent, then added the simlink, and the cron (the simlink is deleted each time a parameter changes in the webadmin).
Now I’m seeing all apps on the portal on subdomain, that’s ok.
But for some apps, if I try to access it I land on the domain with an error (domain.tld/yunohost/sso).

Apps that do not work : gitlab, mailman3, wireguard server
Apps that do work : etherpad, jitsi meet, mattermost, nextcloud, onlyoffice

It seems there is a difference in the way it interacts with the sso ? Any idea to solve this ? @ljf

tomdereub · January 24, 2025, 10:29am

So we found a workaround with @ljf :

all apps that are accessible for visitors : no problem (in example, app1 and app4)
for the other apps (example app2 and app3), I had to create a specific “subportal”, so my /etc/ssowat/conf.json.persistent looks like :

{
"domain_portal_urls": {
        "portal.domain.tld": "portal.domain.tld/yunohost/sso",
        "app1.domain.tld": "portal.domain.tld/yunohost/sso",
        "app2.domain.tld": "app2.domain.tld/yunohost/sso",
        "app3.domain.tld": "app3.domain.tld/yunohost/sso",
        "app4.domain.tld": "portal.domain.tld/yunohost/sso",
    },
 }

When you are on portal.domain.tld and clic on app2, you’ll be redirected to app2 portal. You need to login again, but then you can access the app.
For now it seems that yunohost 12 can not handle this use case better, waiting for a real fix.

ljf · January 24, 2025, 2:03pm

Issue related

github.com/YunoHost/issues

Protected apps on another domain than the portal are not reachable

opened 01:53PM - 24 Jan 25 UTC

zamentur

bug

### Describe the bug `domainB.tld` app is not reachable due to a loop redirecti…on onto `domainA.tld/yunohost/sso` when we want to have only one portal for all domains. ### Context - Hardware: old lpatop - YunoHost version: 12.0.11 - I have access to my server: In very way - Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: yes (/etc/ssowat/conf.json.persistent customized) ### To reproduce To get one portal for all domains, we tried to do like this: * we activate the option `display all apps on this portal` of a `domainA.tld` * make an app on `domainB.tld` redirected onto this portal `domainA.tld` by adding this into `/etc/ssowat/conf.json.persistent` ``` { "domain_portal_urls": { "domainB.tld": "domainA.tld/yunohost/sso", }} ``` After reload ing nginx, click on the tiles of the app redirect onto the same portal `domainA.tld/yunohost/sso` in loop. [Indeed, authentication cookies for domainA.tld can't be shared with domainB.tld...](https://github.com/YunoHost/yunohost/blob/ee82dda69630fe6710061b056b6fea47e4c9157e/src/authenticators/ldap_ynhuser.py#L274) ### Expected behavior When we click on the tiles we should reach the app. OR The webadmin should help to configure something else that could work. ### Workaround If we avoid to edit the `/etc/ssowat/conf.json.persistent`, the app is available but we have to login for each domain... ### Logs With ssowat debug mode, we get: ``` Denied unauthenticated access to gitlab ```

samuel-ynh · January 30, 2025, 8:52am

Thanks for digging deep and the writeup! I will refer to your post in the intial one, to keep a good overview.